Skip to main content

Application Publishing

How an iOS app gets onto a device shapes what you can do with it as a tester, and explains a lot about iOS malware distribution. Everything hinges on certificates and provisioning profiles.

Distribution Channels​

App Store​

  • The only fully sanctioned distribution channel. Apps are reviewed, sandboxed, signed by Apple, and cannot be installed on any other device.
  • Distribution profiles never ship inside the app; Apple signs the final product.

TestFlight​

  • Beta distribution to up to ~10,000 testers per app.
  • Requires a beta profile in the build (the app contains the TestFlight entitlements and the Apple-issued distribution profile).
  • Great for getting legitimate signed builds of target apps for analysis, but you cannot inspect arbitrary third-party binaries this way.

Ad Hoc​

  • Distribute to up to 100 registered device UDIDs.
  • The app ships with an embedded.mobileprovision that explicitly lists allowed devices.
  • Uses a distribution certificate (the profile is device-limited, not Apple-signed like App Store builds).

Enterprise​

  • For internal company distribution to employees, no device limit, no UDID enrollment, no App Store review.
  • Signed with an Enterprise distribution certificate tied to a company account.
  • Because enterprise apps can run anywhere, leaked or stolen enterprise certificates are the backbone of sideloading, malware campaigns, and "alt-store" ecosystems.

Development signing​

  • Signing with a development certificate, installing to registered development devices via Xcode.
  • The app runs on your own test devices. This is how you build custom tooling or modified targets.

Certificates​

  • Apple issues a development certificate (via your Apple ID / team) and a distribution certificate (requires a paid developer account).
  • The private key signs the app binary; iOS trusts the chain up to Apple's root.
  • A leaked private key is catastrophic: anyone can impersonate your team.

Provisioning Profiles​

A provisioning profile binds three things:

  1. A certificate (who signs it).
  2. App identifiers (which bundle IDs).
  3. Devices (which UDIDs, for development/ad-hoc).
# inspect an embedded profile
openssl smime -inform der -verify -in embedded.mobileprovision -noverify -out profile.plist
plutil -p profile.plist

For enterprise, the device list is empty. That is the whole point, and the whole risk.

Why enterprise/ad-hoc matters to pentesters​

  • No review, no device restrictions, no sandbox exception: enterprise distribution is the fastest way to get a binary onto devices at scale. This is the primary vector for both legitimate internal tools and malicious sideloaded apps.
  • Stolen enterprise certificates: let attackers sign arbitrary apps that iOS will happily install. Detecting these in a target environment (installed enterprise profiles) is a real red-team exercise.
  • Ad-hoc profiles leak UDIDs: distributing to a fixed device list means extracting embedded.mobileprovision from a captured IPA reveals the target device identifiers and certificate details.
  • TestFlight/development builds: sometimes ship with debug entitlements and looser settings (ATS relaxed, get-task-allow), giving testers an easier target than the App Store build.

Pentest checklist​

  • Pull the IPA, extract embedded.mobileprovision, and read the certificate + device list, it tells you who signed it and what devices it targets.
  • Verify the signing identity and entitlements against the intended distribution channel.
  • On a device you control, inspect installed profiles (Settings > General > VPN & Device Management) to spot unexpected enterprise provisioning.
  • Remember that "legit App Store" is the hardest channel to get a test build from; ad-hoc, enterprise, and TestFlight are where testers and attackers actually live.