Where the most interesting change is probably that they no longer blindly succeed here: github.com/apple-oss-dist but instead now have a flag that let's them fail here.
2/
Conversation
Because of the other function changing I assume it might be related to having a certificate with no EKUs matching against a policy with an empty email. But unfortunately I don't know enough of the CS flow to say it for certain.
3/3
2
2
So after a while at this I decided to also diff libmis and I also found a change in X509ChainCheckPathWithOptions which looks more like it. Full analysis pending... (but feel free to analyse it based on this info and then just let me know what you figured out :) )
1
1
3
Are you sure this is it? I don't see anything in libmis.dylib call this: it looks like this is from CoreTrust (also in the kext).
The changed code checks X509Policy* param_3, when called from CTEvaluateAMFICodeSignatureCMS param_3 = null, so none of the changed code should run?
1
1
1
I know this is reachable using a debugger. It _looks_ like/I think they miss root CA verification pre 15.5 so you have to have a valid chain with the issuer names etc being correct but the "Apple Root CA" doesn't get compared against the on device root CA
2
1
2
The chain that gets verified is the one that signs the cms in the DER-Encoded-Profile b64 blob in the provisioning profile that the app is associated with. That's all I can give you from the top of my head
1
1
4
Also (I haven't tried this) but you might wanna check out github.com/ehn-dcc-develo to create a fake chain :)
2
1
5
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
ok, that explains why my executable worked on SIP-disabled macOS, but how would you install such an executable onto iOS, where installd checks the executable via Security.framework before installing it?
1
Show replies
Really nice catch! How do they detect if it's an apple bin or not? Just by the name of the leaf certificate?
2