Apple NEVER patched ffapple, in fact they never patched anything. This is a thread on how this cert stuff all works, if you only care about your Spotify ETA scroll on. When working on TutuBox, I always wondered why some certs worked fine with ffapple, and some never.

After getting those certs to work now, it all makes sense. I can tell you why apps crash in the first place, and what happened to TutuBox for it to be “patched” by Apple. Let’s go back. Why did some certs work with ffapple while others didn’t?

Answer is simple: Apple never revoked them. You might be like WTF but you need a proxy to install the cert so that means they did? Yeah, true, but Apple never revoked them.

If you don’t know, if you own an enterprise developer/developer account, all you do is log into the developer portal, and revoke the certificate. Why these certs worked but others didn’t, was becuase the owner of the enterprise developer account revoked the cert by hand.

But how come the stores can stop this, don’t they have access to the account right? WRONG. When you’re an account owner, you can make p12 and .mobileprovision files. Those 2 files are required to sign apps. What cert dealers do, is provide these out, but not the account.

So why don’t they just buy the account? I looked, the market rate is $80 THOUSAND+. But this doesn’t explain why apps download from certs which were revoked by hand and don’t when revoked by Apple. Let me explain it.

When an app downloads, Apple requests http://oscp.apple.com  & http://ppq.apple.com/v1/authorisation. Oscp checks whether the cert is signed or not, whereas ppq checks the account status of the certificate & device info (this will come important later).

Ppq isn’t some new check like I thought, it was always there. Example? Remember the iOS 12 days with my Anti Revoke tutorial & how you had to turn off the Anti Revoke to download new apps? At the time I didn’t know what was up answer was ppq was blocked, so apps wouldn't verify.

If the dev/enterprise account is active, the cert will verify no issue.If Apple shut down the account, 1. The apps won’t install in the first place as ppq is checked while installing, and if you block ppq, you definitely can’t block it while verifying, as that’s a required check.

That’s why you get the untrusted developer after verifying from a revoked cert by Apple, as the account is gone, therefore they just block you from ever downloading again. If you block oscp, Apple atm doesn’t care at all, and just passes the check.

How does this play into tutubox? TutuBox used revoked certificates. As we know, these certificates were revoked by the cert owner, not Apple. All Apple needed to do, is revoke the account… That’s what they did.

Apple never did some server sided thing to add ppq verification, instead they just shut down the account of every cert tutubox & kosaurnag used. How can I prove Apple never outright patched ffapple? Take Xiamen, the latest certificate to be revoked.

It was revoked by the cert owner, and oh look it works with ffapple perfectly fine, and acts just like an old cert! Back on track, when you restart, if the cert was revoked by apple, it’ll break on device, and now the cert won’t download apps anymore.

I forgot to mention, but after every restart, ppq is checked again, with oscp. Now let me tell you why apps crash. There are 2 reasons: 1st caused by oscp (fixable) and 2nd caused by ppq (not so fixable). Let me explain oscp first.

If an oscp request is made, and the response shows the cert was revoked (by owner or by apple), the apps A. Show unable to verify or B. Crash on launch. This IS fixable, as all you need to do is block oscp and just open the apps again, and the crashing/unable to verify goes away.

However, ppq isn’t so easy. Remember what I said with the ppq request. Ppq requests the cert info (profile ID, uuid not to be mistaken with UDID) and the device iOS firmware & type. Notice how if you verify apps on iOS 12 crashing doesn’t exist, but on iOS 13 you can have it?

Let me explain why Tweaked Apps crash. In later 2019, Apple added this new check for enterprise developer certs. Once you reach a certain amount of downloads (about 50k from my data), if on iOS 13+, you have to manually authorise each device in order for the apps to open fine.

Just to reiterate: this feature ONLY works on iOS 13+. It’s a bit like App Attest, which works on iOS 13.5+ only. App Attest won’t run on iOS 13.4.1 & older, and this authorisation thing (tbh forgot the name it’s called something else) will only take effect on iOS 13+.

(Just to be clear, App Attest has nothing to do with certificates, just an example).

Apps crash on launch becuase of the response from http://ppq.apple.com , case closed. So how does this explain how factory resetting your device can fix tweaked apps crashing?

Honestly, I have literally no idea. It could be to do with having other certs installed onto your device in the past, but that’s a guess. So now we know why apps crash in the first place, how can we work around it?

As things stand, there is no block this link in dnscloak to make it just work. Instead, someone would need to make a ppq bypass server… yeah. I think if you spoof the response to think you’re running iOS 12, apps will work perfectly fine, but really I have no idea.

What doesn’t help, is the response is encrypted with a format I have no idea how to decrypt, so I can’t look into it. It IS possible, as iCloud activation bypass severs exist for iOS 10.2 & older (not to be mistaken with the tools which just remove http://setup.app  etc

the issue is someone has to make that bypass server, and I’m definitely not the one to be doing it. So if no one makes a bypass server, are Tweaked Apps screwed? NO. Epic Games is fighting Apple in a lawsuit. If they win, sideloading will be forced by Apple to be allowed.

This will mean NO revokes, NO unable to verify app & NO crashing! If Epic Games loses to Apple however, I think Tweaked Apps will become computer only. Let's say someone DOES make a bypass server, well Apple can always patch it with the latest iOS firmware at the end of the day.