Catalina Custom Dock Icon Changes at Launch of Application

DraconDracon
Posted:
in macOS

I changed the icon of an (third party) application (HIARCS Chess Explorer) using the usual method (SIP temporarily off, copy/paste into the get info panel icon, etc, etc.).  The icon changed to my custom one and it seems to work fine EXCEPT, unlike all my other Apple and non-Apple apps (several dozen) , the Dock icon reverts to the old, default app icon whenever the application is launched, and changes back to my custom icon whenever it is quit.  The display of the app in the folder 'Applications' and also the Dock applications launcher always shows my custom icon.  It is only the Dock icon which changes.

I found several png's as well as the icns file in the application package contents and I changed those files as well, but it did not change this strange behavior.  I also looked at the Info.plist but there did not seem to be anything odd there either.

I also did the usual killall Finder, dock, and delete of some Dock temp file with no help.

Is it possible that the application itself has hard coded its icon display at run-time?   How can I verify this?  If not, is there a way I can find where the default icon is living and change that too?  OR, what ELSE is causing this?

The developer is no help:  Insisting they have complied with all Apple requirements and signing.

Comments

  • Reply 1 of 15
    MarvinMarvin Posts: 15,322moderator
    Dracon said:

    Is it possible that the application itself has hard coded its icon display at run-time?   How can I verify this?

    They've embedded the icon in the app, either in the binary or a resource fork. You can check by opening the app's binary in a hex editor like this one:

    http://ridiculousfish.com/hexfiend/

    If you open the binary HIARCSChessExplorer in that and search for icon in the text, it will get to a link called images/icon.png. To be able to edit the binary, you need to change the permissions, you can do sudo chmod 777 on the binary in the terminal and open it in the editor. Change that link to say icob.png and save the binary, it won't load that icon and will change the Dock icon.
    Dracon
  • Reply 2 of 15
    DraconDracon Posts: 11member
    Thanks Marvin, Will editing that binary louse up the security check and signing? Of course, I probably already did that with my manual change of the icns file inside resources. I have no idea how often that would be checked - maybe just the first run. Also, I have no experience editing something like that; I am worried I could louse things up royally because all this is a level above my expertise. I think I will try that hex editor and look. Would finding icon.png be certain proof that the app is changing the icon at run-time?
  • Reply 3 of 15
    DraconDracon Posts: 11member
    Marvin,

    I tried the editor and it was surprisingly easy to edit what you said.  However,  after editing, the program crashed at launched.  I reinstalled it and all is well, but the problem with the icon persists, of course.  Any thoughts?
  • Reply 4 of 15
    MarvinMarvin Posts: 15,322moderator
    Dracon said:
    Marvin,

    I tried the editor and it was surprisingly easy to edit what you said.  However,  after editing, the program crashed at launched.  I reinstalled it and all is well, but the problem with the icon persists, of course.  Any thoughts?
    Did you change the name to one that is the same length as the original?

    images/icon.png -> images/icob.png

    Changing the binary length by adding data (like images/iconb.png) can cause stability problems but replacing characters is ok.
  • Reply 5 of 15
    DraconDracon Posts: 11member
    Marvin said:

    Did you change the name to one that is the same length as the original?

    images/icon.png -> images/icob.png

    Changing the binary length by adding data (like images/iconb.png) can cause stability problems but replacing characters is ok.
    I was quite careful and just changed icon to icob.  Then I used save in the hexfiend menu and it saved without requiring the sudo chmod 777.  Was it a mistake not to do it first?
    There were crash reports, which I really don't know how to read.  I tried to attach them here but it said the files were not allowed.
  • Reply 6 of 15
    MarvinMarvin Posts: 15,322moderator
    Dracon said:
    Marvin said:

    Did you change the name to one that is the same length as the original?

    images/icon.png -> images/icob.png

    Changing the binary length by adding data (like images/iconb.png) can cause stability problems but replacing characters is ok.
    I was quite careful and just changed icon to icob.  Then I used save in the hexfiend menu and it saved without requiring the sudo chmod 777.  Was it a mistake not to do it first?
    There were crash reports, which I really don't know how to read.  I tried to attach them here but it said the files were not allowed.
    The important part in the crash log are the lines around where it says "Thread 0 crashed". It might be a different thread than 0 that crashed but usually it's 0.

    It's generally not a good idea to be modifying the binary, the app didn't crash for me but maybe it's not the same version.

    It confirms that they are embedding the icon in the app though, it would be best if the developer allows overriding it.
  • Reply 7 of 15
    DraconDracon Posts: 11member
    Marvin said:


    It's generally not a good idea to be modifying the binary, the app didn't crash for me but maybe it's not the same version.


    Are you saying you had this same problem on the same app?  I have version 1.9.4. Deep running on the latest Catalina.  If you actually fixed this icon problem by modifying the binary, maybe there are some further details I should know about. 
    I mean, its not that big a deal - except it has the ugliest icon I have ever seen.    :)
  • Reply 8 of 15
    MarvinMarvin Posts: 15,322moderator
    Dracon said:
    Marvin said:
    It's generally not a good idea to be modifying the binary, the app didn't crash for me but maybe it's not the same version.
    Are you saying you had this same problem on the same app?  I have version 1.9.4. Deep running on the latest Catalina.  If you actually fixed this icon problem by modifying the binary, maybe there are some further details I should know about. 
    I mean, its not that big a deal - except it has the ugliest icon I have ever seen.    :)
    I just downloaded v1.9.4a to try changing the icon, I don't use the app. It is an ugly icon, I can understand the annoyance. I am using Mojave and have system integrity protection turned off and it worked ok for me but it might be a different version:



    Sometimes it's hard designing a good icon that is unique from other apps. Maybe if you could design one or suggest a design, the developer would replace it.
  • Reply 9 of 15
    DraconDracon Posts: 11member

    Where did you get 1.9.4a?  I looked all over the website and the latest is 1.9.4.  I have no problem changing the icon - even without sip disabled because it is not a system application.  The problem is that while it is running it changes back.  As you can see from the screenshots, the icon they supply is hideous.
    Do you keep sip turned off and that prevents it changing back?  Or did you do it only to change the icon?  I have Mojave installed in another partition; I am going to see if the same behavior obtains over there.

    AND, I am still wondering if the HexFiend edit was perfectly done.  If I have the same problem on Mojave, I am going to try that edit again on Catalina.




  • Reply 10 of 15
    DraconDracon Posts: 11member
    Ahah!
    1.  The installation file is 1.9.4a, but the app version calls itself 1.9.4.
    2.  I tried it on Mojave with SIP disabled.  The icon still changes at run-time.  But after carefully HexFiend editing it, the dock icon does NOT change at run-time.  HOWever, when I enable SIP again, the edited version crashes at launch.  The crash report says code signing was the reason.
    3.  I never disabled SIP in Catalina and the crash reports for the edited version look the same.

    Therefore, I am beginning to conclude that, since I am not going to run Catalina with SIP disabled, I will probably not solve the problem of getting rid of this ugly-ass icon.
    Thanks for all the ideas and pointing me to HexFiend - which may come in handy someday.
    If you have any other ideas, please let me know.


    Ciao
  • Reply 11 of 15
    MarvinMarvin Posts: 15,322moderator
    Dracon said:
    2.  I tried it on Mojave with SIP disabled.  The icon still changes at run-time.  But after carefully HexFiend editing it, the dock icon does NOT change at run-time.  HOWever, when I enable SIP again, the edited version crashes at launch.  The crash report says code signing was the reason.
    Interesting, that makes sense that SIP protects against modified binaries as it will approve the original binary. You can try removing the code signature from the app. In the terminal, you can do:

    codesign --remove-signature drag_HIARCS_here

    or another option is:

    xattr -d drag_HIARCS_here

    The second removes all extended attributes so try removing the code signature first. You might be asked to allow it to run after that.
    Dracon
  • Reply 12 of 15
    DraconDracon Posts: 11member
    I did the  codesign --remove-signature and it worked!
    What you didn't tell me was that, first, I had to do xcode-select --install.    I found it out the hard way with some internet searching.  


    Also, since I am not a developer (although I used to write code for a living a long while ago) I worry that I do not ENTIRELY understand what is going on here and it may come back to bite me someday.  For example, I am assuming editing icon to icob has turned the replace icon portion of the code into an isolated stub.  I am surprised that does not crash it, and that the only problem was that it changed the code signature hash value.  And why would removing the code signature not also crash it?  I assume OSX doesn't try to verify the signarture if there isn't any, instead of complaining that it isn't signed - seems strange.

    Anyway, barring an update, I assume it will now keep working the way I want.

    So thanks again, Marvin.      :)
  • Reply 13 of 15
    MarvinMarvin Posts: 15,322moderator
    Dracon said:
    I am assuming editing icon to icob has turned the replace icon portion of the code into an isolated stub.  I am surprised that does not crash it, and that the only problem was that it changed the code signature hash value.  And why would removing the code signature not also crash it?  I assume OSX doesn't try to verify the signarture if there isn't any, instead of complaining that it isn't signed - seems strange.
    Sometimes code checks for broken paths and skips them. I expected it to crash too as hardcoded paths are usually assumed to exist.

    OS X checks unverified/unsigned apps when they are new. Since it had already been run, it was stored as verified and allowed to run. If you removed the code signature on a new app before running it once, it would warn about it. On the following page, you can try downloading a signed Mac app:

    https://www.stclairsoft.com/Main/products.html

    If you duplicate the app and remove the signature from the copy and try running it, it will say it can't run because it's from an unidentified developer. If you run the signed one, it just warns about being downloaded from the internet but will run ok. If you then quit the app and remove the signature from the signed one, it will run again because it's already been verified.
    edited September 2020
  • Reply 14 of 15
    DraconDracon Posts: 11member
    What does this cmd do?

    sudo codesign --force --deep --sign - /Applications/app-name.app


    Would it sign any app with its current binary in such a way that OSX would consider it valid?  Even though I solved my particular problem I am finding this subject interesting.


  • Reply 15 of 15
    MarvinMarvin Posts: 15,322moderator
    Dracon said:
    What does this cmd do?

    sudo codesign --force --deep --sign - /Applications/app-name.app

    Would it sign any app with its current binary in such a way that OSX would consider it valid?  Even though I solved my particular problem I am finding this subject interesting.
    That command would usually take a developer's signing id that is in the Keychain and use it after --sign. Using - signs it with an ad-hoc identity:

    https://eclecticlight.co/2019/01/17/code-signing-for-the-concerned-3-signing-an-app/
    https://apple.stackexchange.com/questions/288291/what-are-the-restrictions-of-ad-hoc-code-signing

    Apparently that has restrictions but it seems to run apps ok. Safari extensions are treated differently if they are ad-hoc signed, they are removed after quitting Safari.

    Apple started enforcing signing in the latest OS Big Sur:

    https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-universal-apps-beta-release-notes

    "New in macOS 11 on Apple silicon Mac computers, and starting in macOS Big Sur 11 beta 6, the operating system enforces that any executable must be signed before it’s allowed to run. There isn’t a specific identity requirement for this signature: a simple ad-hoc signature is sufficient. This new behavior doesn’t change the long-established policy that our users and developers can run arbitrary code on their Macs, and is designed to simplify the execution policies on Apple silicon Mac computers and enable the system to better detect code modifications."
Sign In or Register to comment.