잠겨 있지만 잠겨 있지는 않음: 탈옥 없이 iOS 앱 침투 테스트

By Anatolii Shatylo TL;DR This post covers the core steps needed to decrypt and re-sign iOS apps so they can be tested in a non-jailbroken (jailed) environment. We'll also introduce IPAAutoDec, Anvil's CLI tool that automates remote decryption over SSH using a jailbroken device, removing most of the usual setup hassle. Finally, we'll look at how dynamic analysis tools can be used effectively within the jailed setup. Introduction Today, more than 80% of all digital time online is spent in mobile apps rather than on the web. With the Apple App Store hosting roughly 1.9 million live apps, iOS applications represent a massive portion of that usage. Despite that scale, adoption of formal mobile application security testing remains uneven. Industry reports indicate that only a small to moderate percentage of apps undergo regular security assessments, and surveys suggest that a significant portion of mobile apps are never formally tested at all. The resulting gap between widespread deployment and limited testing makes iOS applications an attractive target for researchers and attackers alike, since high-impact vulnerabilities may remain undiscovered long after release. Assessing the security of iOS applications was always challenging due to Apple's strict platform protections, including code signing, sandboxing, entitlements, and a tightly controlled runtime. Historically, researchers relied on jailbreaking as a pragmatic way to bypass those protections and gain deeper visibility into app internals. Modern apps add another layer of complexity: they target the latest iOS releases (which rarely have stable jailbreaks), and many no longer support older firmware that could be jailbroken. Jailbroken devices are still used during assessments today, but there is a growing sense that with each app update, the minimum supported iOS version will eventually be higher than what can be jailbroken, making this approach increasingly impractical. For example, it is common to see apps with a minimum iOS version set to iOS 15 or 16, while the latest iOS release that currently has a stable jailbreak is iOS 16.7.X (latest versions for iPhone X). Below are some examples of modern apps and their minimum supported iOS versions: - Netflix: The app now requires iOS 16 or later, discontinuing support for devices which cannot be upgraded to iOS 17. - WhatsApp: Starting May 5, 2024, WhatsApp no longer supports devices running iOS versions earlier than 15.1. - YouTube: The app now requires iOS 16 or later, meaning devices like iPhone 7 and iPhone 7 Plus will no longer be compatible with the app. This gap illustrates how soon new app updates may no longer run on devices that can be jailbroken, reducing the long-term feasibility of jailbreak-based testing. As a result, understanding how to assess apps on non-jailbroken (jailed) devices is becoming essential for maintaining relevant and sustainable security testing practices. Core Concept Performing penetration tests in a jailed environment requires balancing two competing realities: Apple's platform protections are strict, and modern apps are often built for iOS versions that cannot be jailbroken. One way to address this challenge is to re-sign the IPA with a development-style entitlement permitting debugger or inspector attachment. That entitlement is called get-task-allow . The entitlement has been part of iOS since the App Store first launched in 2008, introduced alongside the provisioning and code-signing system. Its purpose was simple but critical: let developers attach debuggers to their apps during development, but prevent the same access once the app is distributed to end users via the App Store. Nowadays, security researchers rely on this mechanism to enable controlled runtime inspection of the apps using tools like Frida and LLDB. With the entitlement being set for the app, Frida/LLDB can call task_for_pid() syscall with the target process ID as an argument and gain access to the task port for the app. The task port is a communication channel that provides access to the app's sandbox. It can be used to call internal functions such as ptrace() , dlopen() , and memory read/write over the process: In practice, the workflow depends on how the app is delivered. When provided as an IPA directly by the client, the app can be re-signed with one's provisioning profile that includes the get-task-allow entitlement, enabling runtime inspection. When the app is obtained through the App Store, however, the situation is more complex since the binary is encrypted with Apple's FairPlay DRM and must be decrypted before any re-signing could occur. The decryption step still requires a jailbroken device (from here on, jb), as there is currently no alternative method due to hardware constraints. However, the device's iOS version can be lower than the version supported by the target app as we won't run it on that device. Some IPAs, particularly builds targeting the latest iOS versions cannot be decrypted usi