iSign will fail after modify Info.plist

[acalatrava]

First of all thank you for this awesome utility! I would love to resign apps on Linux :)

Unfortunately either I'm doing something wrong or there is bug since if I try to modify Info.plist and resign afterwards the sign will fail validation because of the Info.plist...

[neilk]

General note: in the future, just paste in text from your terminal. Trying to read your animated gif was difficult, and I don't think it added anything.

Okay, if I understand correctly, you converted Info.plist into an XML file, and then you re-signed it with isign, and then it failed codesign -vv.

I tried doing the same operation with codesign and it succeeded, so it seems that it is allowed to have an Info.plist in the textual XML mode.

I also checked if signing was affected by the last-modified date, and it doesn't seem to be.

The same bug occurs even if you convert the Info.plist back into binary form, so it's not an issue with binary versus text. It occurs if Info.plist is modified at all.

So this is puzzling. It's almost as if there is some information about the previous Info.plist that is preserved in the signature, which we didn't properly erase when we re-signed. Like a hash of Info.plist that's lurking somewhere.

For the moment this isn't a high priority bug for me (it's not in the Sauce Labs use case) but I'll try to keep plugging away at this. Generally if we fixed issue #1 this would probably be an easy fix.

[acalatrava]

Sorry about the gif. Your are correct, I will post commands directly in the future.

I converted the plist just as an example. But you can modify something in the plist, like the CFBundleIdentifier and it will fail as well.

I'm with you, it seems you are preserving some hash somewhere. However I removed the _CodeSignature directory before resign it and it fails too... :-/ so, where is getting those "old" hashes?

[neilk]

I tried that one too. My guess, for now, is that it won't be there -- it's somewhere in the actual LC_CODE_SIGNATURE structure that's in every executable or framework.

Unfortunately isign doesn't produce exactly identical LC_CODE_SIGNATURE as apple's codesign does, so we can't just do a binary diff :(

P.S. There are also hashes of Info.plist embedded in the "special hashes", also included in every executable or framework, but I just don't see how those could be wrong.

[neilk]

Just curious - @acalatrava could you describe your use case here?

[acalatrava]

I was just playing with it to resign Kodi and I needed to change the CFBundleIdentifier so it will match the provisioning profile. I don't understand what you mean since I don't know how the signing is performed, but if LC_CODE_SIGNATURE is in every executable I don't understand why modifying a text file will fail validation...

Also, will this mean that it's not possible to modify any file on the package? So if I patch the executable to load an external dylib will it fail too?

[neilk]

In theory, that would still work. In practice it might not.

isign is not really a signing tool, only a re-signing tool.

Currently we reuse some data from the previous signing. However, bug #1 is about making it sign anything from scratch, even an unsigned app. So there wouldn't be any re-used data to contaminate the signature.

We don't really test modifying the app, except for swapping in a new mobileprovision and changing the entitlements.

[neilk]

Actually, now that I reread this, why do you have to modify the CFBundleIdentifier?

[acalatrava]

So it will match the Provisioning Profile. http://www.idownloadblog.com/2015/12/24/how-install-kodi-new-apple-tv-4/

[neilk]

You might want to try it now - we're properly resigning Info.plist now

[ViktorGal]

Hi @neilk . I need to add a load command to a binary and resign it. After resign with iSign i can install, but app is killed immediately after start. You said: "isign is not really a signing tool, only a re-signing tool. Currently we reuse some data from the previous signing. " Can you give me a tip? Which data is reused? What i need to implement to get it working?

[neilk]

What that means is, we re-use the existing load command pointing to a code signature structure. We change the length of that structure but the assumption is that the code signature is the last structure in the binary (we pad it out to a long length). If you are adding a new load command after the LC_CODE_SIGNATURE then this might be a problem.

However, in theory, if you inserted a load command before LC_CODE_SIGNATURE it should still work, so I don't know for sure that this is what's going wrong.

[ViktorGal]

What do you think, can i insert LC_LOAD_DYLIB before LC_CODE_SIGNATURE? I just neet to change dataoff of LC_CODE_SIGNATURE - right? I'm using macholib. When isign will support signing from scratch?

[cybertiger]

Great, it works, but only if you modify Info.plist via the -i flag.

If you manually modify Info.plist, then isign still produces invalid signatures.

It'd be great if you could just pass an argument to isign so it knows that Info.plist has been modified, or if it could detect the invalid signature automatically and update it.

[neilk]

@ViktorGal it's listed as issue #1. It's not one of Sauce Labs' use cases, and I don't have the time to do it. So, I'd be very happy to accept a PR on this and would help someone, but there's no roadmap for that.

[JonGabilondoAngulo]

Hi, I'm inserting a LC_LOAD_DYLIB before LC_CODE_SIGNATURE. This means adding a new file.dylib side the IPA (app). I haven't changed the LC_CODE_SIGNATURE values. Codesign on Mac does create a correct ipa that installs and loads the dylib on start. Using iSign the App does not install:

Installing 'com.hp.testapp.UICatalog-NI' Install: CreatingStagingDirectory (5%) Install: ExtractingPackage (15%) Install: InspectingPackage (20%) Install: TakingInstallLock (20%) Install: PreflightingApplication (30%) Install: InstallingEmbeddedProfile (30%) Install: VerifyingApplication (40%) ERROR: Install failed. Got error "ApplicationVerificationFailed" with code 0xe8008019: Failed to verify code signature of /private/var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.FWN9Ch/extracted/Payload/UICatalog_NI.app : 0xe8008019 (The application does not have a valid signature.)

I'd appreciate any help. Thanks.

[eric1lubow]

@JonGabilondoAngulo , I've the same issue, Have you solved this problem?