Long gone are the days of jailbreak. My first introduction to jailbreaking my iDevice was:
- To have cool themes on my phone that nobody else did
- To get in-app purchases for free
Sideloading is a really interesting concept all around. It's been having a major push all together, with the EU kind of cattle roping Apple into providing an alternative app store for their users. I honestly don't see it being much of a success, but I am probably somewhat of a hater with it, because I think the App Store is brilliant in its way of keeping apps secure on the device or keeping the device fully secure from unauthorized developers, malicious developers, and nefarious code. The Apple App Store has a moderation team that will review many details of the app and reject ones that are blatantly trying to spread malware. Obviously, I do believe many apps and things bypass these restrictions, but obviously Apple is intelligent enough to suppress these stories very well, and I don't blame them for doing so.
Interestingly enough, sideloading and alternate app stores are not a new concept. You can take a look at AppSync and iPhoneCake/AppCake (which was my all-time favorite), which you could once install via their repo on Cydia and just download pretty much every app that someone was willing strip the DRM and repack into an ipa. It was a really simple process. Nowadays, I don't want to go as far as saying it's more simple, but let's just say there are more resources and energy around such activities that allow for side loading apps with alternative app stores such as TrollStore and AltServer/AltStore.
The one thing that most people don't really realize with these alternative app stores (as I fringed upon above) is that there's no content moderation team whatsoever. Anyone can repack, strip the DRM, and upload an IPA to some random repository. You download it on your phone, and boom, you got the app, right? Cool. So, for example, very similar to the golden era of the jailbreak days when Saurik (Jay Freeman) was still the maintainer of Cydia, there are various "developers" (we'll call them that) who host large repositories of paid App Store apps available for free download via sideloading. The problem with sideloading from a security perspective is that you still don't know exactly what is inside your sideload. These "developers" can practically install any injectable into the app because a normal person is definitely going to check that, right? Nonetheless, it's pretty interesting because you will see various cracks or modded features in these apps because the developer took some time going down the binary rabbit hole to add some new features or strip protections that were once in the app that blocked paid content or paid features from being used without paying them.
We can still talk about this subject, but at a certain point the subject will just circle back to a policy discussion on whether people should be able to sideload or not. I don't think that's why you're here reading my article. I want to pivot slightly to a more technical portion of my write-up on actually bypassing in-app purchases on iOS 26 with a man-in-the-middle "blocking," let's call it.
So back in the glory days, one would just download IAP Cracker from Insanelyi, biteyourapple, SiNful iPhone, HackYouriPhone (Okay, I'll stop reminiscing now.). IAP Cracker specifically bounced around several of these names, too, like LocalIAPStore and iAPFree on some of these repos. Julioverne was the developer behind LocalIAPStore, which was essentially the successor/spiritual replacement to the original IAP Cracker. His repo was one of the go-to sources for that tweak specifically. He later merged under the HackYouriPhone umbrella. Once you had it installed on your phone, anything that was with local authentication and didn't touch a server, you could essentially get that in-app purchase on your device. So, with Angry Birds unlocking 500 Mighty Eagles or gold eagles (I forget what they're called now) was straightforward, but getting 9,000 gems on Clash of Clans was not so much.
The problem with this for developers wasn't so much that someone was rigging some local-based game like Cut the Rope to unlock all the levels, but it actually affected server-side apps as well that didn't do proper authentication and would hurt their bottom line.
The core vulnerability was real. IAP Cracker (and later tools like LocalIAPStore) worked by intercepting the communication between the app and Apple’s servers, feeding the app a fake “purchase successful” response. Any app that only validated purchases client-side — checking locally whether the App Store said “yes” — was vulnerable, regardless of whether the app had a server backend for other features.
Most developers didn’t validate server-side. Apple provided receipt validation APIs, but it wasn’t required, and implementing it meant standing up your own server and dealing with what developers at the time described as “cryptic error codes” and pain. A Hacker News thread from July 2012 captures the thinking well: developers weighed the cost of building server validation against the likely loss from pirates who “probably wouldn’t have paid anyway.”
One developer using the SOOMLA platform saw over $1,000 in reported in-app revenue after launch day, but Apple’s actual reports showed only $1–2. The entire difference was phony digital receipts.
If you remember in 2012. A Russian hacker named Alexey Borodin created a MITM proxy that let non-jailbroken devices fake IAP receipts by installing a custom SSL certificate. That was a watershed moment as it moved the problem from the small jailbroken population to potentially anyone, and it forced Apple and developers to take server-side validation seriously. I remember using this for various apps, and it worked for some time. Not every server-side app it worked on, but there were plenty. Granted, Apple did take quick action on exploiting this, but it still bypassed many client-side authentications on many apps.
The apps hit hardest were freemium games with coin/gem economies — the bread and butter of the 2011–2013 App Store. Think the wave of games modeled after Clash of Clans, Temple Run, and similar titles where you could buy currency packs. If the developer was a small studio without server infrastructure, they were essentially defenseless (or lazy - But honestly, without The privilege to just WhisprFlow into Claude to spin something up, can you blame them?). It wasn’t that server-side apps were inherently vulnerable — it’s that apps with server components often still validated purchases client-side only, because doing it properly required extra server-side work that many teams skipped.
For a long period of time, from the last true untethered jailbreak, iOS 9 (Pangu9),up until about when iOS 18, keep in mind that every iOS version was a year, so this is about nine years, the exploitation of in-app purchases was very scarce. If memory serves me well, I believe I was 13 and 14 were the true last tethered jailbreaks, which were the core of iAP Cracker worked on was still very hit-or-miss due to new OS logic and APIs from Apple on in-app purchasing as a whole.
Now let's fast forward to today. iOS 26 is out. And I have been using this method (for research purposes) since iOS 18. As a cybersecurity professional by trade and now a developer of a production iOS app, it is my duty to shed light on this subject. I definitely did not create this or design the logic for it. It is something out there in the public, or, as some say, in the wild, being used. It is important to draw attention to it for the sake of other iOS developers and Apple's team themselves that could be losing out on real-world revenue that they never even knew about was being stolen.
Okay, and now for the set up and how to:
Basically, you get started. All you need is Egern. Egern is an official non-malicious app on the App Store. Simply put, it's a network proxy app. You can use it for various things, but in this respect here, we can use it to bypass in-app purchase validation on many client-side authenticated iOS apps by using the scripts inside the YAML file config. When you add the YAML file config on Egern, it will install scripts and man-in-the-middle sources to block completely such as api.revenuecat.com and buy.itunes.apple.com.
In the AppTesters YAML that's where the targeting logic lives. The AppTesters config intercepts calls to api.revenuecat.com as its primary target. RevenueCat has become the subscription management backbone for a pretty significant portion of the App Store. Developers use it because it handles receipt validation, entitlement state, webhook events, subscriber history; it's a lot of infrastructure you'd otherwise have to build yourself. Which, in retrospect, is super helpful for solo developers or small in-house shops but The problem is that consolidation also means one predictable API endpoint covers every app running RevenueCat at once, instead of having to reverse-engineer each developer's custom IAP implementation separately.
The config also strips ETag headers off RevenueCat requests before they go out. That prevents the app from comparing a cached legitimate response against the spoofed one coming back. Then a JavaScript file, AutoRC.js, does the actual interception. When the app makes its subscriber check to RevenueCat, the script catches the response in transit and rewrites the subscriber object to show an active entitlement. App receives what looks like a real RevenueCat response, unlocks the subscription, moves on. No binary patching. No memory hooks. No touching the app at all. All textbook and in the middle traffic manipulation. Kind of similar to Borodin's 2012 SSL trick.
For the developers reading this: If you're on RevenueCat, the server-side infrastructure to fix this already exists in the platform. RevenueCat sends webhook events to your backend on subscription changes. Your entitlement check should be reading what your backend received from RevenueCat's server, not what the SDK on the client just told you. If the entitlement didn't come through your backend first, don't grant access. On StoreKit 2, Transaction.currentEntitlements carries JWS signatures verifiable server-side, and that signature chain goes back to Apple's servers, not the client. Nothing a local MITM proxy touches can fabricate a valid one. StoreKit 1's verifyReceipt still works if you're on that path. The route matters less than the principle: validation needs to reach a server before anything unlocks.
On the detection side: You can check for active VPN configurations and proxy settings at runtime and treat a subscription event that happened under a proxy as a flag worth reviewing server-side before granting access. It's not a clean block because real users run VPNs and you can't discriminate perfectly, but it's a useful signal. Certificate pinning helps as another layer, though I'd get server-side validation solid first. Pinning has enough implementation complexity and rotation risk that it should be defense-in-depth, not the primary fix.
If you're shipping a subscription app and have not thought through this threat model, go look at that hostname list and Go double check yourself what your entitlement check actually trusts.
The barrier now is lower than it has ever been in the history of iOS exploitation. Download Egern from the App Store, install a YAML file, a few minutes tapping instructions, and turning on the VPN. The interesting part too that I don't see talked about much in their community is that Egern actually works as a Mac app as well as "Designed for iPhone"/"Designed for iPad". So there are many apps as well that are MacOS specific that Egern can also bypass the in-app purchase of. AppTesters maintains which apps are currently vulnerable, notes when something gets patched, and tweaks scripts as they need to. Their community is very active on Telegram. I won't make the judgment call that they're some crazy nation-state actor, but none the less, they could fit into a threat actor bucket depending on your revenue size and user database size. Nonetheless, I've written another article on how these threat actors leverage Telegram communities for their mission.