Hopefully this question makes sense to you because I'm pretty frustrated by it right now. My team releases Enterprise-signed apps to customers very manually. No iTunes store or MDM involved. Through iOS8.4.1 this worked just fine. However, in iOS9, APPL introduced a new Verify step for each app distributed this way that checks in with https://ppq.apple.com/v1/authorization as seen in https://support.apple.com/en-ca/HT204460. That Verify step is annoying for some, but impossible to do for users that aren't permitted to connect to the Internet.

Falling down the rabbit hole at home, I have been looking at the following files on a rooted device:/Library/MobileDevice/Indeterminates.plist/usr/libexec/online-auth-agent/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64 -> /usr/lib/libmis.dylib (obtained via jtool, thanks!)/var/mobile/Library/Logs/CrashReporter/DiagnosticLogs/SoftwareUpdateServices.log.*

It seems like they are somehow related because the files change when performing the Verify check, but I can only assume I'm missing some aspect of it. (And the binaries are the ones with references to the files that changed.) Looking at the arm64 dumps of online-auth-agent and libmis.dylib haven't been very fruitful because I'm pretty much limited to TextPad and strings here. I have tried: - clearing out the contents of /Library/MobileDevice/Indeterminates.plist by using plutil -convert xml1 - creating /Library/MobileDevice/AuthListReadyCdHashes.plist with various array of string values that "should" be the app's cdhash value

Mucking with those files seemed to only be able to have a negative impact on the Verified state or Settings stability.

The new verify step introduces by Apple is a pain, definitely. It is, in part, driven by Jailbreakers using enterprise certificates (and, in particular, expired ones) to get past code signing restrictions on the device.

On a jailbroken device, this can be circumvented. But on a non jailbroken device the whole introduction of this step is expressly to force user to do the verification online, so AAPL may revoke at any time.

Re: Reversing the binaries - jtool -d actually dumps quite a bit on both. You might want to try that. The main logic IIRC is actually in libMIS. You did correctly identify the parties involved, but short of binary patching them (which, again, requires JB) I tend to think you're quite powerless here.

(Sorry.. I can't find circumventions for all of Apple's stuff. They are improving it, learning from past mistakes..)

Thank you for the confirmation of the path and all your work! I did run jtool -d on online-auth-agent and libmis.dylib, and it worked well, but there still seems to be some oddities. For example, strings reports that the string "/Library/MobileDevice/Indeterminates.plist" is within libmid.dylib, but the dissassembly doesn't reference it. There are also jumps to addresses that aren't present. I assume those are to outside library functions? Unfortunately, I'm better at looking at x86 than arm64, so it is still a bit Greek to me.

I believe the offline users would be willing to jailbreak the devices, but probably only temporarily. Disabling code-signing and encryption in general would most likely not be acceptable. I guess I was hoping I could install some kind of daemon that would detect when one of our enterprise signed apps were installed and defeat the Verify step at that time for only that app.

Is the /Library/MobileDevice/AuthListReadyCdHashes.plist a "white list" of APPL accepted apps, or was that just a bad guess? My original hope was to be able to populate that file with our app's known cdhashes and then remove the jailbreak.

If you're extracting libmis.dylib and friends from the shared library cache, you're likely seeing addresses in other libs which aren't present. The upcoming version of JTool will fix that and enable to work on the dylibs without uncaching them.

That you can't see the string in the disassembly may be one of two reasons:

A) left over from dead/removed code (unlikely)B) jtool doesn't correctly disassemble the path loading to the setting of the pointer to the string in the register, which jtool can then detect and tell you - here's that string.

If you install your daemon and then "unjailbreak" your device (e.g. removing the pguntether or other) code signing would kick in full force and your daemon would be the first to die. I'm assuming you mean for the duration of the verification purpose. That's doable, certainly, but might be complicated. For one, I never really examined enterprise apps in depth, not being part of any enterprise and thus not having an ability to check out the certs.

If you can , please send me a sample enterprise app (anything, even a hello world) and I'll look into it. It might even make it into MOXiI 2. And I'll check AuthListReadyCdHashes for refs to it..