Taking a Bite Out of the Forbidden Fruit: Characterizing Third-Party Iranian iOS App Stores

Source: arXiv:2604.26343 · Published 2026-04-29 · By Amirhossein Khanlari, Amir Rahmati

TL;DR

This paper studies a largely undocumented iOS distribution ecosystem that emerged in Iran because Apple App Store access is blocked by sanctions and local censorship. The core problem is not just “alternative app stores exist,” but that these stores operate through Apple developer-program loopholes, user-device registration, and signing workflows that let them distribute apps outside Apple’s intended channels. The authors build Havva, a crawler-and-analysis pipeline, to observe how three Iranian third-party iOS app stores register users, sign apps, and evade revocation.

The main result is a characterization of the ecosystem’s scale and composition from 1,767 collected apps over a 5.5-month observation period. They find a large Iranian-exclusive app segment, extensive cracked and paid-app redistribution, and meaningful overlap in finance, navigation, and social apps that are effectively necessary for Iranian users. They also uncover app morphing/cloaking behavior tied to Iranian IP detection, and quantify both developer revenue loss and security/privacy risks from altered binaries and embedded piracy/tracking libraries. The paper’s value is empirical: it shows the ecosystem is not a fringe curiosity but a parallel market with recurring operational patterns, economic incentives, and concrete technical abuse.

Key findings

• Across three stores, Havva collected 1,767 apps total, including 510 Iranian-exclusive apps (~29%), 308 paid apps, and 159 cracked apps.
• Over the 5.5-month study window (Apr 14, 2025 to Oct 1, 2025), the authors observed 826 new apps, 885 app updates, and >2.4M new downloads (download stats available only for two stores).
• Only 20 apps were present across all four platforms considered (the three third-party stores plus the Apple App Store), suggesting very limited universal availability.
• Store A had 558 apps, Store B 1,323 apps, and Store C 221 apps; 45% of Store A’s apps were not available in the App Store.
• Among the 45 apps common to the Iranian stores, 68% were finance apps, including Iranian banks such as Melli, Saderat, and Saman.
• Static analysis found 489 apps with unauthorized provisioning profiles and over 180 apps containing piracy libraries such as Cydia Substrate and iGameGod.
• The authors estimate piracy and unauthorized distribution in just two stores could exceed $5.26 million in lost revenue.
• Three apps that appeared in the App Store were found to be shell/morphing apps that changed behavior when the device presented an Iranian IP address.

Threat model

The effective adversary is a clandestine third-party iOS app store operator working around Apple and OFAC constraints. They can obtain Apple developer or enterprise accounts, register device UDIDs, intercept private APIs, serve and re-sign IPA files, and distribute app bundles outside the App Store to Iranian users. They cannot rely on official App Store approval, and their certificates may be revoked by Apple, forcing account rotation. The paper does not model a sophisticated remote malware actor; its main concern is unauthorized distribution, app alteration, and ecosystem-level abuse.

Methodology — deep read

Threat model and setting: the paper is not framed as a classic malware/adversary benchmark, but the implicit adversary is a third-party iOS store operator that violates Apple’s distribution rules by signing and redistributing apps for Iranian users. The operators are assumed to have access to Apple developer accounts (ad-hoc and/or enterprise), the ability to register device UDIDs, and the ability to intercept and serve IPA files through private APIs. Users are Iranian residents who cannot access the official App Store normally; the stores require an Iranian phone number, Iranian payment method, and typically an Iranian IP address. The paper’s goal is observational characterization, not active disruption, so it does not model direct attacker goals like credential theft or code injection beyond pirated/altered binaries.

Data collection and provenance: Havva is the authors’ collection system. It crawls three major Iranian third-party iOS app stores selected for popularity, app diversity, and cracked-app presence. The crawler extracts store listings and app-page metadata such as app name, version, bundle ID, category, size, download count, and update timing, storing these in per-store databases with retrieval dates. For each [app, version] pair, Havva checks whether the exact version is already in its IPA database; if not, it downloads the IPA from the store. Because the stores do not expose public download APIs, the authors place a man-in-the-middle proxy on their device to intercept private APIs. In parallel, Havva queries the iTunes API to match each app against the Apple App Store by bundle ID, and when necessary uses the NyaMisty script plus a Windows Server 2022 VM with patched iTunes v12.6.5.3 to fetch older App Store versions. Reported coverage is 1,767 apps total; however, the paper notes that 308 paid App Store apps were excluded from binary comparison because the original packages were not available, and 10 apps were excluded from static analysis because the jailbroken iPhone (iOS 16.7.12) could not decrypt apps requiring iOS 17+.

Architecture / analysis pipeline: Havva has four modules. (1) Metadata Collection scrapes listings and app pages to populate structured databases. (2) IPA Collection downloads IPA bundles from third-party stores using intercepted private APIs; this is keyed by exact app-version pairs to avoid duplicates. (3) App Store Matching uses bundle IDs and the iTunes API to identify corresponding official apps; if the Store version is older than the currently available App Store version, the authors fetch the matching older App Store binary using patched iTunes/NyaMisty. (4) Static Analysis unpacks IPA files, decrypts FairPlay-protected binaries on a jailbroken iPhone 8 using ideviceinstaller and mldecrypt, and then analyzes the decrypted binaries with MobSF. The output includes permissions, file listings, external libraries, domains/URLs, traffic-flow indicators, and Mach-O features. A concrete end-to-end example: a new app listing appears in Store B, Havva scrapes its bundle ID and version, notices the IPA is not yet in the archive, intercepts the store’s private API call to fetch the IPA, finds a matching official App Store entry by bundle ID, and if the store copy is older than Apple’s current release, retrieves the corresponding older official version for apples-to-apples static comparison before running MobSF and library/domain extraction.

Training regime and modeling: there is no ML model training in the paper. The “regime” is instead repeated crawling and analysis over a 5.5-month measurement window. The paper does not report random seeds, parameter sweeps, or statistical confidence intervals; its results are descriptive counts and overlaps, plus qualitative inspection of morphing apps. The operational process is more relevant than a training loop: repeated periodic crawls, version deduplication, version matching, and binary extraction against a constrained device environment.

Evaluation protocol and comparisons: the evaluation is essentially a measurement study. Metrics include app counts, category breakdowns, overlaps among stores and the App Store, observed new apps, observed updates, download counts, and counts of cracked/paid/Iranian-exclusive apps. The authors compare third-party-store apps against official App Store apps using bundle IDs and version matching, and they inspect binary deltas to identify altered binaries, unauthorized provisioning profiles, and embedded piracy/tracking libraries. They also estimate revenue loss from unauthorized redistribution in two stores, yielding the $5.26M figure. The paper includes figures for store overlap (Venn diagram), category distribution, growth over time, and delay distributions relative to App Store versions, but the excerpt provided does not include exact numerical values from those plots beyond the counts already listed. No formal hypothesis test or confidence interval analysis is described in the available text.

Reproducibility: the authors say the dataset will be available to other researchers upon request, subject to fair use and a data-use agreement, but it is not described as a fully public artifact. The methods rely on a jailbroken iPhone, a Windows VM with patched iTunes, private API interception, and access to the specific stores’ live infrastructure, so exact reproduction may be difficult if the stores change APIs, revoke certificates, or alter signing flows. The paper also notes operational fragility: Apple frequently revokes fraudulent certificates, forcing stores to rotate accounts and users to re-download apps. That means the measurement target itself is moving, which complicates exact replication and longitudinal comparison.

Technical innovations

• Havva: an end-to-end pipeline that automates metadata collection, IPA capture, App Store matching, and static analysis for clandestine iOS stores.
• Use of private-API interception plus exact-version IPA deduplication to track underground iOS catalogs that do not expose public download interfaces.
• Version-aligned comparison against the Apple App Store using patched iTunes and NyaMisty to recover older official binaries for apples-to-apples analysis.
• Detection of sanctions-evasion app morphing/cloaking behavior by comparing app behavior under Iranian vs non-Iranian IPs.

Datasets

• Three major Iranian third-party iOS app stores — 1,767 apps total over 5.5 months — source: non-public clandestine stores
• Apple App Store matched corpus — corresponding metadata for matching apps; IPA downloads only for free apps and older versions via patched iTunes/NyaMisty — source: Apple App Store
• Static-analysis corpus — 1,767 third-party apps plus matched official binaries, minus 308 paid App Store apps and 10 iOS-17+ incompatible apps for binary analysis — source: collected by Havva

Baselines vs proposed

• No explicit algorithmic baseline comparison reported: n/a
• App Store overlap: only 20 apps shared across all four platforms (3 third-party stores + Apple App Store) vs the much larger third-party-only catalog
• Revenue-loss estimate: two stores could exceed $5.26M in lost developer revenue due to piracy and unauthorized distribution

Figures from the paper

Figures are reproduced from the source paper for academic discussion. Original copyright: the paper authors. See arXiv:2604.26343.

Fig 3: Havva collects app metadata and IPA files from third-party

Fig 4: Venn diagram illustrating the numbers of applications

Fig 5: Distribution of apps across various categories, divided by Iranian and global apps

Fig 6: Example of a morphed Iranian application in the Apple

Fig 7: Newly added and updated apps over time.

Fig 8: CDF of the delay (in days) relative to the App Store version

Fig 9: The number of update events versus delay (in days) for

Fig 11: presents the breakdown of the number of down-

Limitations

• The study is confined to three stores; the Iranian ecosystem is broader than these selected platforms, so findings may not generalize to all clandestine stores.
• Binary analysis excluded 308 paid App Store apps and 10 apps requiring iOS 17+, so coverage is incomplete for the exact-app comparison set.
• The dataset is live and operationally unstable: certificates get revoked and stores rotate accounts, which can change availability and reproducibility.
• Revenue-loss estimates are model-based and only mentioned for two stores; the paper excerpt does not provide the full calculation assumptions in detail.
• No formal statistical testing, confidence intervals, or uncertainty estimates are reported in the provided text.
• The paper is largely descriptive; it identifies altered binaries and piracy libraries, but does not deeply attribute specific security/privacy harms to each library or modification in a controlled way.

Open questions / follow-ons

• How much of the observed ecosystem is driven by sanctions and censorship versus simple economic incentives such as piracy and subscription avoidance?
• How quickly do store contents and signing workflows change after Apple revokes certificates, and can that churn be measured systematically over time?
• Which embedded libraries or binary modifications materially increase privacy risk versus merely enabling re-signing or piracy?
• Can app morphing/cloaking be detected automatically at scale across region-sensitive apps and other sanctioned markets?

Why it matters for bot defense

For bot-defense and CAPTCHA practitioners, the paper is a reminder that access-control problems often become ecosystem problems: if a mainstream distribution channel is unavailable, users and operators build a parallel channel with its own identity proofing, payment, device fingerprinting, and verification steps. The signup flow described here resembles a custom anti-abuse funnel: phone-number verification, device-UDID collection, IP gating, subscription checks, and delayed provisioning. That means bot-defense engineers should think beyond the web front-end and consider the full supply chain—how device identity is bound, how certificates are issued and revoked, and how alternate channels can be abused to scale piracy or bypass regional policy. The app morphing cases also matter: content can be region-adaptive and look benign during review, then change behavior after IP-based geolocation. Any anti-abuse system that only inspects one execution context may miss that kind of conditional payload. For practitioners, the main takeaway is to treat regional restriction workarounds as an active adversarial environment where identity, distribution, and content integrity all need monitoring, not just login attempts.

Cite

@article{arxiv2604_26343,
  title={ Taking a Bite Out of the Forbidden Fruit: Characterizing Third-Party Iranian iOS App Stores },
  author={ Amirhossein Khanlari and Amir Rahmati },
  journal={arXiv preprint arXiv:2604.26343},
  year={ 2026 },
  url={https://arxiv.org/abs/2604.26343}
}

Read the full paper

• arXiv:2604.26343 (abstract)
• arXiv:2604.26343 (PDF)