Code signature v 20500 questions

[Orph]

I was playing with an already signed binary, having version CodeDirectory version 20500.
I noticed there are 2 more special slots, up to -7. One of them (-7) was used and the corresponding blog contained some sort of ASN.1 representation of the entitlements.
Also, it has the new magic FADE7172.

My questions are:
- is my analysis from above correct?
- what is this blob used for?
- is it somehow mandatory for 20500? I resigned the binary on Mac, which produced a code signature with version 20400 and these blobs were missing, but I just want to know if I can fiddle with this code signature and just remove the blob.

Btw, I already bought VOL 3 but if all the details for this new blob are updated in the latest version of the book, I am considering buying it again.

[morpheus]

Heya,

Yes, from what I know it's a different binary representation of the entitlements, hence the new magic, as well. I'd appreciate if you posted a link to a download of it, since I'm limited in my samples of v2.5. signatures.

Also, I am pushing one more update to Vol III - which will be v1.7 - I want to account for Darwin 19 updates, and just HAVE to account for the SockPuppet bug now that it's back with a vengeance in 12.4. But you won't have to buy it again* - I'll make that section free in the ChangeLog.



---
* - That's not to say I wouldn't mind if you did buy it again AAPL Pay preferred, too

[Orph]

It is not hard to get a sample, I just dumped a known AppStore app on iOS 12, and voyla... as long as there is no legal issue or smth, I can upload my sample somewhere and send the link to you; via email should be fine?

I am curious on what is the purpose of this new blob, I don't believe Apple introduced it just for fun. I could presume that either
a) is enforcing security in a new way
b) is preparing the road to make the old entitlement blob obsolete, as this is more compact

Btw, for the fun of it, I tried to find a way to resign, based on the isign tool, but could not find a free tool to convert from XML to ASN.1, and I feel is too much effort to consider writing my own.

[morpheus]

I'l get my hands on one and see; I'm working on reintegrating --sign into jtool2, (and finally deprecating jtool1, since the only reason it's still around is self signing), so I'll be sure to add support for this new format, too.

[Orph]

I finally managed to change the new DER blob with my new entitlements, also modified team-ID into Requirement list, but when I try to validate signature with codesign it just say Signature invalid. When I use codesign for signing, it generates a signature v 20400... is it possible that 20500 is reserved somehow for App Store only? I tried to validate an archive with XCode for a dummy test but signature is stil 20400; I only obtained 20500 when doing manual codesign with --option runtime, for a Mac app.
Besides the runtime check and hardening signature validation on Mac, what does this new format bring for iOS?

[morpheus]

so, all the instances I could find are for App Store Apps. You're correct about both counts, -7 and the DER encoding, as is corroborated from the 10.14.x sources of the security framework. I still have yet to figure out what is the benefit of using DER alongside the standard plist/bplist, unless it's transitioning before the plist form goes away.

support for this format coming really soon - I just need more samples to test on..

[Orph]

Well it seems there is a way to optain samples, provided by codesign; it seems that signing with codesign with the flag --generate-pre-encrypt-hashes is enough to force the version 20500. Also, as a bonus, --generate-entitlement-der would generate the DER blob.

Could you explain the pre encrypt hashes? I can asume that they are used as a protection mechanism to cross-check the CodeDirectory (that may explain the existence of 2 blobs, which I could not figure out why before), but against what?