1. 项目概述为什么我们需要手动脱壳在iOS开发和安全研究的圈子里“脱壳”或者说“砸壳”是一个绕不开的话题。简单来说它指的就是从App Store下载的、经过苹果加密保护的iOS应用安装包.ipa文件中提取出未经加密的、可被分析和修改的二进制文件的过程。你可能好奇为什么一个从官方渠道下载的应用还需要“脱壳”呢这就要从苹果的App Store生态说起了。苹果为了保障应用的安全性和知识产权对所有通过App Store分发的应用都会进行一项名为“FairPlay DRM”的加密操作。这项加密会作用在应用二进制文件的“代码段”__TEXT段上使得应用在下载到你的设备时其核心代码是处于加密状态的。只有当应用被安装到一台经过授权的设备即你的iPhone或iPad上并由iOS系统在运行时动态解密后代码才能正常执行。这个机制就像给应用的核心代码上了一把锁而钥匙只在你的设备和iOS系统手里。对于普通用户这完全透明且无感但对于开发者想学习优秀应用的实现、安全研究员想进行漏洞挖掘或合规审计、或者逆向爱好者想研究某个功能是如何实现的这层加密就成了一个必须跨过的门槛。因此“脱壳”就成了获取可分析二进制文件的必要步骤。市面上虽然有Clutch、frida-ios-dump等自动化工具但在高版本iOS系统、新型加密方式或特定应用保护下自动化工具常常会失效。这时掌握一套手动脱壳的方法就成了一项非常宝贵且硬核的技能。它不依赖于特定工具的更新而是直击本质——利用系统运行时解密代码这一特性直接从内存中将解密后的代码“dump”转储出来。这个过程就像在应用运行的时候趁其不备把它已经解开锁、正在使用的代码抄录一份下来。接下来我将结合自己多次在真实设备上操作的经验为你拆解手动脱壳的完整流程、核心原理以及那些工具文档里不会写的“坑”。2. 核心原理与前置知识解析2.1 FairPlay DRM与ASLR理解两道防线手动脱壳之所以可行核心在于iOS系统的两个关键机制FairPlay DRM和ASLR。我们需要先理解它们才能明白我们每一步操作在对抗什么。FairPlay DRM数字版权管理这是苹果的加密方案。它并非加密整个IPA文件而是选择性地加密了Mach-O二进制文件中__TEXT段代码段的内容。这个加密在应用静态存储时即在你的手机存储里或IPA包中是生效的。当应用启动时iOS内核的AppleMobileFileIntegrityAMFI和FairPlay子系统会进行验证并在内存中动态解密这些代码页以供CPU执行。关键点在于解密只发生在内存中。磁盘上的文件始终保持加密状态。我们的目标就是在这个“内存解密后代码执行前”的瞬间把解密后的代码抓取出来。ASLR地址空间布局随机化这是现代操作系统包括iOS普遍采用的安全缓解技术。它的目的是防止攻击者通过硬编码的内存地址进行攻击比如缓冲区溢出。ASLR会在每次应用启动时随机化应用加载到内存中的基地址image base。这意味着同一个应用两次启动其代码、数据在内存中的具体位置都是不同的。这给我们手动脱壳带来了第一个挑战我们无法预先知道解密后的代码被加载到了内存的哪个地址。我们必须先动态地找到它。2.2 Mach-O文件结构浅析我们脱壳的最终产物是一个Mach-O文件这是iOS/macOS系统的可执行文件格式。了解其基本结构有助于理解我们修复文件时在做什么。一个典型的Mach-O文件包含Header头部包含文件的基本信息如魔数、CPU架构、文件类型等。Load Commands加载命令这是一系列指令告诉内核如何加载这个文件。其中对我们最重要的两条是LC_ENCRYPTION_INFO(或LC_ENCRYPTION_INFO_64)这个命令包含了加密信息比如加密的偏移量、大小以及加密状态cryptid。未加密的文件cryptid为0App Store下载的文件cryptid为1。LC_SEGMENT(或LC_SEGMENT_64)定义了段Segment和节Section如__TEXT代码段、__DATA数据段等。Data数据实际的代码和数据内容。脱壳后我们不仅要用解密后的代码数据替换原加密数据还需要修改LC_ENCRYPTION_INFO中的cryptid为0以标记文件为未加密状态否则系统仍会尝试将其作为加密文件处理导致无法运行或分析。2.3 工具选型为什么是LLDB和debugserver工欲善其事必先利其器。手动脱壳的核心工具链非常精简但每一样都至关重要越狱iOS设备这是前提。因为我们需要获取系统的root权限才能访问其他进程的内存空间和进行调试。目前主流越狱工具如palera1nA9-A11设备、DopamineA12-A15/M1设备等。debugserver这是苹果Xcode开发工具套件的一部分是一个轻量级的调试服务器。我们需要一个经过签名并附加了get-task-allow权限的debugserver这样才能附加attach到任意进程上进行调试。通常可以从Xcode中提取并自己签名或者直接使用越狱社区提供的预签名版本如从ellekit或procursus源安装。LLDBLLDB是下一代高性能调试器macOS命令行自带。它是我们与运行在iOS设备上的debugserver进行通信并执行所有调试命令如下断点、读内存的客户端。Python脚本用于自动化内存dump和初步修复过程。虽然可以完全手动但一个脚本能极大提升效率和准确性。通常会用到frida的Stalker或纯Python的ptrace、mach_vm_read等接口但最经典直接的方式还是配合LLDB。Mach-O查看/编辑工具jtool2或joker功能强大的Mach-O分析工具可以查看加载命令、符号表修改加密标志等。otoolmacOS自带可以查看加密信息otool -l binary | grep -A 4 LC_ENCRYPTION。insert_dylib或optool用于向二进制文件中注入动态库在某些脱壳方法中会用到。注意工具的版本和兼容性非常重要。特别是debugserver必须与你的iOS设备架构和系统版本匹配。使用来自不可信源的预编译二进制文件存在安全风险建议在可控环境下从Xcode自行构建和签名。3. 环境准备与工具部署3.1 越狱环境配置首先确保你的iOS设备已经成功越狱并且安装了包管理器如Cydia、Sileo或Zebra。这是所有后续操作的基础。越狱后你需要通过SSH连接到你的设备。通常越狱工具会安装OpenSSH服务。连接设备在macOS的终端中使用ssh root[你的设备IP]进行连接。默认密码通常是alpine强烈建议首次连接后立即修改root和mobile用户的密码。安装必要依赖通过包管理器安装一些基础工具。# 以Sileo/Procursus环境为例 apt update apt install -y file ldidfile命令用于检查文件类型ldid用于对二进制文件进行伪签名在越狱环境下运行必备。3.2 部署debugserver这是最关键的一步。一个正确配置的debugserver是调试的桥梁。获取debugserver最简单的方法是从已安装的Xcode中拷贝。路径通常在/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/[你的iOS版本]/DeveloperDiskImage.dmg。挂载后在/usr/bin/下找到debugserver。或者直接从越狱源安装社区维护的版本例如在ellekit源中搜索。签名debugserver从Xcode提取的debugserver缺少附加到任意进程的权限。我们需要用ldid为其添加get-task-allow和run-unsigned-code等权限。首先创建一个名为ent.xml的权限配置文件?xml version1.0 encodingUTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd plist version1.0 dict keycom.apple.springboard.debugapplications/key true/ keyrun-unsigned-code/key true/ keyget-task-allow/key true/ keytask_for_pid-allow/key true/ keyplatform-application/key true/ /dict /plist然后使用ldid进行签名# 在macOS上操作 ldid -Sent.xml debugserver传输到设备将签名后的debugserver通过scp传输到iOS设备的/usr/bin/目录并赋予可执行权限。scp debugserver root[设备IP]:/usr/bin/ ssh root[设备IP] chmod x /usr/bin/debugserver3.3 目标应用准备确定你想要脱壳的应用。通过SSH登录设备后可以找到已安装应用的目录。App Store应用通常位于/var/containers/Bundle/Application/下的随机命名文件夹中。找到应用你可以通过ps aux | grep [应用名]找到进程ID然后通过ps -p [PID] -o comm找到可执行文件路径再层层回溯找到.app包。或者直接使用find命令搜索。find /var/containers/Bundle/Application -name \*.app\ -type d | grep -i [应用名部分关键词]备份加密二进制文件进入对应的.app目录找到与.app同名的可执行文件通常就是主二进制文件。将其拷贝一份作为备份这是我们脱壳的“原材料”。cp [可执行文件] [可执行文件]_encrypted.backup4. 手动脱壳实战步骤详解现在进入核心环节。我们将使用debugserver和LLDB通过下断点的方式在代码解密后、执行前将其从内存中导出。4.1 启动调试会话在iOS设备上启动debugserver通过SSH在设备上执行以下命令让debugserver监听某个端口例如1234并等待附加到目标进程。debugserver *:1234 -a \TargetApp\其中TargetApp是目标应用的进程名不是应用名。如果应用未启动-a参数会让debugserver启动它。你也可以先启动应用然后用-p [PID]附加。 如果一切正常你会看到类似debugserver-(#)PROGRAM:debugserver PROJECT:debugserver-... Listening to port 1234 for a connection from *...的输出表示debugserver已在等待连接。在macOS上使用LLDB连接打开一个新的终端窗口启动LLDB并连接到设备。lldb (lldb) platform select remote-ios (lldb) process connect connect://[设备IP]:1234连接成功后LLDB会暂停目标进程的执行并显示当前线程和寄存器的状态。此时应用的所有代码都已解密并加载到内存中。4.2 定位内存中的代码段由于ASLR我们需要先找到__TEXT段在本次运行中的实际加载地址Slide Address。获取模块加载信息在LLDB中使用image list命令可以列出所有已加载的模块可执行文件和动态库。找到你的目标应用的主模块它通常是列表中的第一个或名字最长的那个。记下它的加载地址例如0x0000000104a00000。这个地址就是本次运行的基地址ASLR Slide。(lldb) image list -o -f [ 0] 0x0000000104a00000 /private/var/.../TargetApp.app/TargetApp(0x0000000104a00000) ...-o参数显示偏移量即ASLR后的加载地址。计算__TEXT段虚拟地址光有基地址还不够我们需要知道__TEXT段在文件内的相对偏移File Offset。这需要分析原始的加密二进制文件。在macOS上使用otool命令otool -l [加密的二进制文件备份] | grep -A 4 \segname __TEXT\在输出中找到vmaddr的值。例如vmaddr 0x0000000100000000。这个值是__TEXT段在链接时预设的虚拟地址。内存中的实际地址 基地址 (vmaddr - 0x100000000)。对于64位ARM架构__TEXT段的vmaddr通常就是0x100000000。所以内存中__TEXT段的起始地址通常就是image list里看到的那个基地址。我们将其记为text_start。获取__TEXT段大小同样使用otool在刚才的命令输出附近找到vmsize的值。这就是__TEXT段在内存中占用的总大小。记作text_size。segname __TEXT vmaddr 0x0000000100000000 vmsize 0x0000000000a80000 # 假设这是大小 ...4.3 从内存中Dump解密代码现在我们知道了解密后代码在内存中的位置text_start和大小text_size。接下来就是将其读取并保存到本地文件。在LLDB中我们可以使用memory read命令来读取内存但更高效的方式是使用其script桥接Python API或者直接用一个Python脚本通过mach_vm_read系统调用来完成。这里介绍LLDB内联Python的方法它不需要额外的脚本文件在LLDB会话中即可完成。在LLDB中执行Python脚本(lldb) script import lldb import struct # 获取当前目标进程 target lldb.debugger.GetSelectedTarget() process target.GetProcess() # 设置起始地址和大小 (替换成你实际获取的地址和大小) text_start 0x0000000104a00000 text_size 0xa80000 # 错误检查 if text_size 0: print(\Error: Invalid text size\) exit(1) # 读取内存 error lldb.SBError() mem_data process.ReadMemory(text_start, text_size, error) if error.Success(): # 将数据写入文件 output_path \/tmp/decrypted_text.bin\ with open(output_path, \wb\) as f: f.write(mem_data) print(\Successfully dumped decrypted __TEXT segment to:\, output_path) print(\Size:\, len(mem_data), \bytes\) else: print(\Failed to read memory:\, error)执行这段脚本后解密后的代码数据就保存到了iOS设备的/tmp/decrypted_text.bin文件中。将文件传输到macOS使用scp将dump下来的文件从设备拷贝到你的macOS工作目录。scp root[设备IP]:/tmp/decrypted_text.bin .4.4 重建可执行文件现在我们有了原始的加密Mach-O文件备份和解密后的代码数据decrypted_text.bin。接下来需要将它们“缝合”起来创建一个新的、未加密的可执行文件。定位加密数据在文件中的位置再次使用otool查看加密信息。otool -l [加密的二进制文件] | grep -A 4 LC_ENCRYPTION输出中cryptoff代表加密部分相对于__TEXT段起始的文件偏移cryptsize代表加密部分的大小。通常cryptoff就是__TEXT段中第一个节如__text的偏移cryptsize覆盖了__TEXT段内大部分需要加密的节。替换数据使用dd命令或Python脚本将原始文件中从cryptoff开始、长度为cryptsize的加密数据替换为我们dump出来的解密数据。重要dump出来的decrypted_text.bin是整个__TEXT段的内存镜像而cryptoff是段内的偏移。所以我们需要用decrypted_text.bin中从cryptoff开始的数据去替换。# 假设 cryptoff0x4000, cryptsize0xa7c000 # 首先创建一个原始文件的副本作为工作文件 cp [加密的二进制文件] [解密后的二进制文件] # 使用dd进行替换 (macOS上的dd需要指定convnotrunc) # 从decrypted_text.bin的0x4000偏移处读取cryptsize大小的数据写入到新文件的cryptoff处 dd ifdecrypted_text.bin of[解密后的二进制文件] bs1 seek$((0x4000)) skip$((0x4000)) count$((0xa7c000)) convnotrunc这个dd命令参数较多容易出错。更稳妥的方法是写一个简单的Python脚本#!/usr/bin/env python3 import sys if len(sys.argv) ! 5: print(\Usage: python3 patch_bin.py encrypted_bin decrypted_data cryptoff cryptsize\) sys.exit(1) encrypted_bin sys.argv[1] decrypted_data sys.argv[2] cryptoff int(sys.argv[3], 16) cryptsize int(sys.argv[4], 16) with open(encrypted_bin, \rb\) as f_enc, open(decrypted_data, \rb\) as f_dec: # 将加密二进制文件读入内存对于大文件可能需流式处理 data bytearray(f_enc.read()) # 读取解密数据中对应部分 f_dec.seek(cryptoff) patch_data f_dec.read(cryptsize) if len(patch_data) ! cryptsize: print(\Error: Decrypted data is too small\) sys.exit(1) # 替换 data[cryptoff:cryptoffcryptsize] patch_data # 写回文件 f_enc.seek(0) f_enc.write(data) print(\Patch applied successfully.\)运行python3 patch_bin.py [解密后的二进制文件] decrypted_text.bin 0x4000 0xa7c000修改加密标志最后也是最关键的一步将Mach-O头中的加密标志cryptid从1改为0。使用jtool2或joker可以很方便地完成。# 使用jtool2 jtool2 -e arch -arch arm64 [解密后的二进制文件] # 或者直接修改Load Command (更底层的方式) # 先用otool确认cryptid位置通常紧跟在cryptsize之后 # 然后使用十六进制编辑器或Python脚本修改对应字节。 # 使用jtool2是最简单安全的方法。对于jtool2如果它提示文件已经是未加密状态那可能已经修改成功。你也可以用otool再次验证otool -l [解密后的二进制文件] | grep -A 4 LC_ENCRYPTION查看输出中的cryptid应该已经变为0。5. 验证、修复与常见问题排查5.1 验证脱壳文件脱壳并修复后必须验证生成的文件是否有效。检查加密状态如上所述使用otool查看cryptid是否为0。检查文件完整性使用file命令检查文件类型使用codesign检查签名脱壳后签名会失效这是正常的。file [解密后的二进制文件] codesign -dv [解密后的二进制文件] 21 | head -20尝试静态分析使用反汇编工具如hopper、IDA Pro、Ghidra加载脱壳后的文件。如果能正常反编译出可读的汇编代码或伪代码而不是一堆乱码或加密数据基本说明脱壳成功。尝试重签名运行在越狱设备上可以使用ldid进行伪签名然后替换原.app目录下的可执行文件记得先备份原文件尝试运行应用。如果应用能正常启动并运行核心功能那就是终极验证。5.2 常见问题与解决方案手动脱壳过程中你几乎一定会遇到下面这些问题问题1debugserver附加失败提示“failed to attach”或“connection refused”。原因debugserver权限不足、签名问题、或者目标应用有反调试保护。解决确保debugserver已用正确的ent.xml文件签名。尝试在越狱环境中安装反反调试插件如Liberty Lite屏蔽越狱检测或Alderis针对某些调试检测。对于ptrace反调试可以尝试kill -SIGSTOP [PID]暂停进程后再附加。有些应用在启动时检测调试器。可以尝试先启动应用然后在它完成启动检测后再用debugserver -p [PID]快速附加。问题2LLDB连接成功但image list找不到主模块或者基地址看起来不对。原因可能附加到了错误的进程如应用插件或者应用使用了复杂的动态加载。解决确保附加的是主应用进程。使用ps aux仔细查看进程树。对于动态加载主模块可能不是第一个。查找包含应用名的路径。也可以尝试在LLDB中br set -n main设置断点然后c继续运行程序会在main函数入口暂停此时再image list通常能看到正确模块。问题3Dump出来的数据大小不对或者替换后文件损坏。原因__TEXT段的vmsize和文件中的cryptsize可能不完全对应。vmsize是内存中占用的对齐后大小而cryptsize是文件中实际加密的数据大小。直接按vmsizedump可能会包含一些未初始化的内存或填充。解决始终使用otool查到的cryptsize作为dump和替换的依据。在计算dump大小时可以稍微多dump一些例如cryptsize 0x1000但替换时严格使用cryptsize。使用Python脚本进行替换比dd命令更精确。问题4脱壳后的文件无法被反汇编工具识别或提示“malformed Mach-O”。原因Mach-O头或加载命令在修改过程中被破坏。可能是替换数据时偏移计算错误或者修改cryptid时损坏了相邻数据。解决使用jtool2 --analyze或MachOView工具检查修复后的文件结构与原始加密文件对比。确保替换操作是二进制精确的没有引入额外的字节或缺失字节。尝试使用jtool2的--decrypt功能如果支持你的加密版本进行自动修复或者用joker工具来修正加密信息。问题5应用在脱壳重签名后闪退。原因除了脱壳问题还可能是签名问题、依赖的动态库路径问题、或应用有强力的完整性校验。解决使用ldid -S[ent.xml]对脱壳后的可执行文件及其Frameworks目录下的所有动态库进行伪签名。使用otool -L检查依赖的动态库路径是否正确。在越狱环境可能需要使用install_name_tool修改路径或确保相应的库存在于设备上。检查系统日志在macOS控制台选择你的iOS设备查看闪退时会生成崩溃报告crashlog里面通常有明确的错误原因如“code signature invalid”、“no suitable image found”等。5.3 高级技巧与注意事项对付代码混淆/符号剥离App Store应用默认会剥离符号Strip Symbol你看到的函数名都是像sub_104a4c000这样的地址。可以尝试从应用内嵌的Bitcode符号表如果有、或通过dyld_shared_cache中提取的系统库符号来辅助分析。对于自定义混淆则需要动态调试来理解其逻辑。批量脱壳与自动化上述流程可以编写成完整的Python脚本进行自动化包括查找进程、计算偏移、内存dump、文件修补。核心是结合frida的Process模块和debugserver的lldbRPC接口。但自动化脚本的鲁棒性需要针对不同应用进行大量测试。保持环境稳定脱壳过程中尽量避免手机锁屏或进入休眠。可以在设置中调整。一个不稳定的SSH连接也可能导致LLDB会话中断建议使用tmux或screen在设备端运行debugserver。法律与道德边界请仅对你拥有合法权限的应用进行脱壳分析例如自己开发的应用、进行安全研究的应用在合规范围内。尊重知识产权勿将脱壳后的二进制文件用于非法分发、破解或商业用途。手动脱壳是一项细致且需要耐心的工作它没有一键式的完美解决方案。每一次成功脱壳都是对iOS系统机制和Mach-O格式理解的一次加深。希望这篇详尽的教程能为你打开iOS逆向分析的大门。当你亲手从内存中抓取出那些加密的代码并在反编译器中看到清晰的逻辑时那种成就感绝对是使用自动化工具无法比拟的。
iOS应用手动脱壳实战：从FairPlay DRM到内存dump的完整指南
发布时间：2026/6/23 15:01:20
1. 项目概述为什么我们需要手动脱壳在iOS开发和安全研究的圈子里“脱壳”或者说“砸壳”是一个绕不开的话题。简单来说它指的就是从App Store下载的、经过苹果加密保护的iOS应用安装包.ipa文件中提取出未经加密的、可被分析和修改的二进制文件的过程。你可能好奇为什么一个从官方渠道下载的应用还需要“脱壳”呢这就要从苹果的App Store生态说起了。苹果为了保障应用的安全性和知识产权对所有通过App Store分发的应用都会进行一项名为“FairPlay DRM”的加密操作。这项加密会作用在应用二进制文件的“代码段”__TEXT段上使得应用在下载到你的设备时其核心代码是处于加密状态的。只有当应用被安装到一台经过授权的设备即你的iPhone或iPad上并由iOS系统在运行时动态解密后代码才能正常执行。这个机制就像给应用的核心代码上了一把锁而钥匙只在你的设备和iOS系统手里。对于普通用户这完全透明且无感但对于开发者想学习优秀应用的实现、安全研究员想进行漏洞挖掘或合规审计、或者逆向爱好者想研究某个功能是如何实现的这层加密就成了一个必须跨过的门槛。因此“脱壳”就成了获取可分析二进制文件的必要步骤。市面上虽然有Clutch、frida-ios-dump等自动化工具但在高版本iOS系统、新型加密方式或特定应用保护下自动化工具常常会失效。这时掌握一套手动脱壳的方法就成了一项非常宝贵且硬核的技能。它不依赖于特定工具的更新而是直击本质——利用系统运行时解密代码这一特性直接从内存中将解密后的代码“dump”转储出来。这个过程就像在应用运行的时候趁其不备把它已经解开锁、正在使用的代码抄录一份下来。接下来我将结合自己多次在真实设备上操作的经验为你拆解手动脱壳的完整流程、核心原理以及那些工具文档里不会写的“坑”。2. 核心原理与前置知识解析2.1 FairPlay DRM与ASLR理解两道防线手动脱壳之所以可行核心在于iOS系统的两个关键机制FairPlay DRM和ASLR。我们需要先理解它们才能明白我们每一步操作在对抗什么。FairPlay DRM数字版权管理这是苹果的加密方案。它并非加密整个IPA文件而是选择性地加密了Mach-O二进制文件中__TEXT段代码段的内容。这个加密在应用静态存储时即在你的手机存储里或IPA包中是生效的。当应用启动时iOS内核的AppleMobileFileIntegrityAMFI和FairPlay子系统会进行验证并在内存中动态解密这些代码页以供CPU执行。关键点在于解密只发生在内存中。磁盘上的文件始终保持加密状态。我们的目标就是在这个“内存解密后代码执行前”的瞬间把解密后的代码抓取出来。ASLR地址空间布局随机化这是现代操作系统包括iOS普遍采用的安全缓解技术。它的目的是防止攻击者通过硬编码的内存地址进行攻击比如缓冲区溢出。ASLR会在每次应用启动时随机化应用加载到内存中的基地址image base。这意味着同一个应用两次启动其代码、数据在内存中的具体位置都是不同的。这给我们手动脱壳带来了第一个挑战我们无法预先知道解密后的代码被加载到了内存的哪个地址。我们必须先动态地找到它。2.2 Mach-O文件结构浅析我们脱壳的最终产物是一个Mach-O文件这是iOS/macOS系统的可执行文件格式。了解其基本结构有助于理解我们修复文件时在做什么。一个典型的Mach-O文件包含Header头部包含文件的基本信息如魔数、CPU架构、文件类型等。Load Commands加载命令这是一系列指令告诉内核如何加载这个文件。其中对我们最重要的两条是LC_ENCRYPTION_INFO(或LC_ENCRYPTION_INFO_64)这个命令包含了加密信息比如加密的偏移量、大小以及加密状态cryptid。未加密的文件cryptid为0App Store下载的文件cryptid为1。LC_SEGMENT(或LC_SEGMENT_64)定义了段Segment和节Section如__TEXT代码段、__DATA数据段等。Data数据实际的代码和数据内容。脱壳后我们不仅要用解密后的代码数据替换原加密数据还需要修改LC_ENCRYPTION_INFO中的cryptid为0以标记文件为未加密状态否则系统仍会尝试将其作为加密文件处理导致无法运行或分析。2.3 工具选型为什么是LLDB和debugserver工欲善其事必先利其器。手动脱壳的核心工具链非常精简但每一样都至关重要越狱iOS设备这是前提。因为我们需要获取系统的root权限才能访问其他进程的内存空间和进行调试。目前主流越狱工具如palera1nA9-A11设备、DopamineA12-A15/M1设备等。debugserver这是苹果Xcode开发工具套件的一部分是一个轻量级的调试服务器。我们需要一个经过签名并附加了get-task-allow权限的debugserver这样才能附加attach到任意进程上进行调试。通常可以从Xcode中提取并自己签名或者直接使用越狱社区提供的预签名版本如从ellekit或procursus源安装。LLDBLLDB是下一代高性能调试器macOS命令行自带。它是我们与运行在iOS设备上的debugserver进行通信并执行所有调试命令如下断点、读内存的客户端。Python脚本用于自动化内存dump和初步修复过程。虽然可以完全手动但一个脚本能极大提升效率和准确性。通常会用到frida的Stalker或纯Python的ptrace、mach_vm_read等接口但最经典直接的方式还是配合LLDB。Mach-O查看/编辑工具jtool2或joker功能强大的Mach-O分析工具可以查看加载命令、符号表修改加密标志等。otoolmacOS自带可以查看加密信息otool -l binary | grep -A 4 LC_ENCRYPTION。insert_dylib或optool用于向二进制文件中注入动态库在某些脱壳方法中会用到。注意工具的版本和兼容性非常重要。特别是debugserver必须与你的iOS设备架构和系统版本匹配。使用来自不可信源的预编译二进制文件存在安全风险建议在可控环境下从Xcode自行构建和签名。3. 环境准备与工具部署3.1 越狱环境配置首先确保你的iOS设备已经成功越狱并且安装了包管理器如Cydia、Sileo或Zebra。这是所有后续操作的基础。越狱后你需要通过SSH连接到你的设备。通常越狱工具会安装OpenSSH服务。连接设备在macOS的终端中使用ssh root[你的设备IP]进行连接。默认密码通常是alpine强烈建议首次连接后立即修改root和mobile用户的密码。安装必要依赖通过包管理器安装一些基础工具。# 以Sileo/Procursus环境为例 apt update apt install -y file ldidfile命令用于检查文件类型ldid用于对二进制文件进行伪签名在越狱环境下运行必备。3.2 部署debugserver这是最关键的一步。一个正确配置的debugserver是调试的桥梁。获取debugserver最简单的方法是从已安装的Xcode中拷贝。路径通常在/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/[你的iOS版本]/DeveloperDiskImage.dmg。挂载后在/usr/bin/下找到debugserver。或者直接从越狱源安装社区维护的版本例如在ellekit源中搜索。签名debugserver从Xcode提取的debugserver缺少附加到任意进程的权限。我们需要用ldid为其添加get-task-allow和run-unsigned-code等权限。首先创建一个名为ent.xml的权限配置文件?xml version1.0 encodingUTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd plist version1.0 dict keycom.apple.springboard.debugapplications/key true/ keyrun-unsigned-code/key true/ keyget-task-allow/key true/ keytask_for_pid-allow/key true/ keyplatform-application/key true/ /dict /plist然后使用ldid进行签名# 在macOS上操作 ldid -Sent.xml debugserver传输到设备将签名后的debugserver通过scp传输到iOS设备的/usr/bin/目录并赋予可执行权限。scp debugserver root[设备IP]:/usr/bin/ ssh root[设备IP] chmod x /usr/bin/debugserver3.3 目标应用准备确定你想要脱壳的应用。通过SSH登录设备后可以找到已安装应用的目录。App Store应用通常位于/var/containers/Bundle/Application/下的随机命名文件夹中。找到应用你可以通过ps aux | grep [应用名]找到进程ID然后通过ps -p [PID] -o comm找到可执行文件路径再层层回溯找到.app包。或者直接使用find命令搜索。find /var/containers/Bundle/Application -name \*.app\ -type d | grep -i [应用名部分关键词]备份加密二进制文件进入对应的.app目录找到与.app同名的可执行文件通常就是主二进制文件。将其拷贝一份作为备份这是我们脱壳的“原材料”。cp [可执行文件] [可执行文件]_encrypted.backup4. 手动脱壳实战步骤详解现在进入核心环节。我们将使用debugserver和LLDB通过下断点的方式在代码解密后、执行前将其从内存中导出。4.1 启动调试会话在iOS设备上启动debugserver通过SSH在设备上执行以下命令让debugserver监听某个端口例如1234并等待附加到目标进程。debugserver *:1234 -a \TargetApp\其中TargetApp是目标应用的进程名不是应用名。如果应用未启动-a参数会让debugserver启动它。你也可以先启动应用然后用-p [PID]附加。 如果一切正常你会看到类似debugserver-(#)PROGRAM:debugserver PROJECT:debugserver-... Listening to port 1234 for a connection from *...的输出表示debugserver已在等待连接。在macOS上使用LLDB连接打开一个新的终端窗口启动LLDB并连接到设备。lldb (lldb) platform select remote-ios (lldb) process connect connect://[设备IP]:1234连接成功后LLDB会暂停目标进程的执行并显示当前线程和寄存器的状态。此时应用的所有代码都已解密并加载到内存中。4.2 定位内存中的代码段由于ASLR我们需要先找到__TEXT段在本次运行中的实际加载地址Slide Address。获取模块加载信息在LLDB中使用image list命令可以列出所有已加载的模块可执行文件和动态库。找到你的目标应用的主模块它通常是列表中的第一个或名字最长的那个。记下它的加载地址例如0x0000000104a00000。这个地址就是本次运行的基地址ASLR Slide。(lldb) image list -o -f [ 0] 0x0000000104a00000 /private/var/.../TargetApp.app/TargetApp(0x0000000104a00000) ...-o参数显示偏移量即ASLR后的加载地址。计算__TEXT段虚拟地址光有基地址还不够我们需要知道__TEXT段在文件内的相对偏移File Offset。这需要分析原始的加密二进制文件。在macOS上使用otool命令otool -l [加密的二进制文件备份] | grep -A 4 \segname __TEXT\在输出中找到vmaddr的值。例如vmaddr 0x0000000100000000。这个值是__TEXT段在链接时预设的虚拟地址。内存中的实际地址 基地址 (vmaddr - 0x100000000)。对于64位ARM架构__TEXT段的vmaddr通常就是0x100000000。所以内存中__TEXT段的起始地址通常就是image list里看到的那个基地址。我们将其记为text_start。获取__TEXT段大小同样使用otool在刚才的命令输出附近找到vmsize的值。这就是__TEXT段在内存中占用的总大小。记作text_size。segname __TEXT vmaddr 0x0000000100000000 vmsize 0x0000000000a80000 # 假设这是大小 ...4.3 从内存中Dump解密代码现在我们知道了解密后代码在内存中的位置text_start和大小text_size。接下来就是将其读取并保存到本地文件。在LLDB中我们可以使用memory read命令来读取内存但更高效的方式是使用其script桥接Python API或者直接用一个Python脚本通过mach_vm_read系统调用来完成。这里介绍LLDB内联Python的方法它不需要额外的脚本文件在LLDB会话中即可完成。在LLDB中执行Python脚本(lldb) script import lldb import struct # 获取当前目标进程 target lldb.debugger.GetSelectedTarget() process target.GetProcess() # 设置起始地址和大小 (替换成你实际获取的地址和大小) text_start 0x0000000104a00000 text_size 0xa80000 # 错误检查 if text_size 0: print(\Error: Invalid text size\) exit(1) # 读取内存 error lldb.SBError() mem_data process.ReadMemory(text_start, text_size, error) if error.Success(): # 将数据写入文件 output_path \/tmp/decrypted_text.bin\ with open(output_path, \wb\) as f: f.write(mem_data) print(\Successfully dumped decrypted __TEXT segment to:\, output_path) print(\Size:\, len(mem_data), \bytes\) else: print(\Failed to read memory:\, error)执行这段脚本后解密后的代码数据就保存到了iOS设备的/tmp/decrypted_text.bin文件中。将文件传输到macOS使用scp将dump下来的文件从设备拷贝到你的macOS工作目录。scp root[设备IP]:/tmp/decrypted_text.bin .4.4 重建可执行文件现在我们有了原始的加密Mach-O文件备份和解密后的代码数据decrypted_text.bin。接下来需要将它们“缝合”起来创建一个新的、未加密的可执行文件。定位加密数据在文件中的位置再次使用otool查看加密信息。otool -l [加密的二进制文件] | grep -A 4 LC_ENCRYPTION输出中cryptoff代表加密部分相对于__TEXT段起始的文件偏移cryptsize代表加密部分的大小。通常cryptoff就是__TEXT段中第一个节如__text的偏移cryptsize覆盖了__TEXT段内大部分需要加密的节。替换数据使用dd命令或Python脚本将原始文件中从cryptoff开始、长度为cryptsize的加密数据替换为我们dump出来的解密数据。重要dump出来的decrypted_text.bin是整个__TEXT段的内存镜像而cryptoff是段内的偏移。所以我们需要用decrypted_text.bin中从cryptoff开始的数据去替换。# 假设 cryptoff0x4000, cryptsize0xa7c000 # 首先创建一个原始文件的副本作为工作文件 cp [加密的二进制文件] [解密后的二进制文件] # 使用dd进行替换 (macOS上的dd需要指定convnotrunc) # 从decrypted_text.bin的0x4000偏移处读取cryptsize大小的数据写入到新文件的cryptoff处 dd ifdecrypted_text.bin of[解密后的二进制文件] bs1 seek$((0x4000)) skip$((0x4000)) count$((0xa7c000)) convnotrunc这个dd命令参数较多容易出错。更稳妥的方法是写一个简单的Python脚本#!/usr/bin/env python3 import sys if len(sys.argv) ! 5: print(\Usage: python3 patch_bin.py encrypted_bin decrypted_data cryptoff cryptsize\) sys.exit(1) encrypted_bin sys.argv[1] decrypted_data sys.argv[2] cryptoff int(sys.argv[3], 16) cryptsize int(sys.argv[4], 16) with open(encrypted_bin, \rb\) as f_enc, open(decrypted_data, \rb\) as f_dec: # 将加密二进制文件读入内存对于大文件可能需流式处理 data bytearray(f_enc.read()) # 读取解密数据中对应部分 f_dec.seek(cryptoff) patch_data f_dec.read(cryptsize) if len(patch_data) ! cryptsize: print(\Error: Decrypted data is too small\) sys.exit(1) # 替换 data[cryptoff:cryptoffcryptsize] patch_data # 写回文件 f_enc.seek(0) f_enc.write(data) print(\Patch applied successfully.\)运行python3 patch_bin.py [解密后的二进制文件] decrypted_text.bin 0x4000 0xa7c000修改加密标志最后也是最关键的一步将Mach-O头中的加密标志cryptid从1改为0。使用jtool2或joker可以很方便地完成。# 使用jtool2 jtool2 -e arch -arch arm64 [解密后的二进制文件] # 或者直接修改Load Command (更底层的方式) # 先用otool确认cryptid位置通常紧跟在cryptsize之后 # 然后使用十六进制编辑器或Python脚本修改对应字节。 # 使用jtool2是最简单安全的方法。对于jtool2如果它提示文件已经是未加密状态那可能已经修改成功。你也可以用otool再次验证otool -l [解密后的二进制文件] | grep -A 4 LC_ENCRYPTION查看输出中的cryptid应该已经变为0。5. 验证、修复与常见问题排查5.1 验证脱壳文件脱壳并修复后必须验证生成的文件是否有效。检查加密状态如上所述使用otool查看cryptid是否为0。检查文件完整性使用file命令检查文件类型使用codesign检查签名脱壳后签名会失效这是正常的。file [解密后的二进制文件] codesign -dv [解密后的二进制文件] 21 | head -20尝试静态分析使用反汇编工具如hopper、IDA Pro、Ghidra加载脱壳后的文件。如果能正常反编译出可读的汇编代码或伪代码而不是一堆乱码或加密数据基本说明脱壳成功。尝试重签名运行在越狱设备上可以使用ldid进行伪签名然后替换原.app目录下的可执行文件记得先备份原文件尝试运行应用。如果应用能正常启动并运行核心功能那就是终极验证。5.2 常见问题与解决方案手动脱壳过程中你几乎一定会遇到下面这些问题问题1debugserver附加失败提示“failed to attach”或“connection refused”。原因debugserver权限不足、签名问题、或者目标应用有反调试保护。解决确保debugserver已用正确的ent.xml文件签名。尝试在越狱环境中安装反反调试插件如Liberty Lite屏蔽越狱检测或Alderis针对某些调试检测。对于ptrace反调试可以尝试kill -SIGSTOP [PID]暂停进程后再附加。有些应用在启动时检测调试器。可以尝试先启动应用然后在它完成启动检测后再用debugserver -p [PID]快速附加。问题2LLDB连接成功但image list找不到主模块或者基地址看起来不对。原因可能附加到了错误的进程如应用插件或者应用使用了复杂的动态加载。解决确保附加的是主应用进程。使用ps aux仔细查看进程树。对于动态加载主模块可能不是第一个。查找包含应用名的路径。也可以尝试在LLDB中br set -n main设置断点然后c继续运行程序会在main函数入口暂停此时再image list通常能看到正确模块。问题3Dump出来的数据大小不对或者替换后文件损坏。原因__TEXT段的vmsize和文件中的cryptsize可能不完全对应。vmsize是内存中占用的对齐后大小而cryptsize是文件中实际加密的数据大小。直接按vmsizedump可能会包含一些未初始化的内存或填充。解决始终使用otool查到的cryptsize作为dump和替换的依据。在计算dump大小时可以稍微多dump一些例如cryptsize 0x1000但替换时严格使用cryptsize。使用Python脚本进行替换比dd命令更精确。问题4脱壳后的文件无法被反汇编工具识别或提示“malformed Mach-O”。原因Mach-O头或加载命令在修改过程中被破坏。可能是替换数据时偏移计算错误或者修改cryptid时损坏了相邻数据。解决使用jtool2 --analyze或MachOView工具检查修复后的文件结构与原始加密文件对比。确保替换操作是二进制精确的没有引入额外的字节或缺失字节。尝试使用jtool2的--decrypt功能如果支持你的加密版本进行自动修复或者用joker工具来修正加密信息。问题5应用在脱壳重签名后闪退。原因除了脱壳问题还可能是签名问题、依赖的动态库路径问题、或应用有强力的完整性校验。解决使用ldid -S[ent.xml]对脱壳后的可执行文件及其Frameworks目录下的所有动态库进行伪签名。使用otool -L检查依赖的动态库路径是否正确。在越狱环境可能需要使用install_name_tool修改路径或确保相应的库存在于设备上。检查系统日志在macOS控制台选择你的iOS设备查看闪退时会生成崩溃报告crashlog里面通常有明确的错误原因如“code signature invalid”、“no suitable image found”等。5.3 高级技巧与注意事项对付代码混淆/符号剥离App Store应用默认会剥离符号Strip Symbol你看到的函数名都是像sub_104a4c000这样的地址。可以尝试从应用内嵌的Bitcode符号表如果有、或通过dyld_shared_cache中提取的系统库符号来辅助分析。对于自定义混淆则需要动态调试来理解其逻辑。批量脱壳与自动化上述流程可以编写成完整的Python脚本进行自动化包括查找进程、计算偏移、内存dump、文件修补。核心是结合frida的Process模块和debugserver的lldbRPC接口。但自动化脚本的鲁棒性需要针对不同应用进行大量测试。保持环境稳定脱壳过程中尽量避免手机锁屏或进入休眠。可以在设置中调整。一个不稳定的SSH连接也可能导致LLDB会话中断建议使用tmux或screen在设备端运行debugserver。法律与道德边界请仅对你拥有合法权限的应用进行脱壳分析例如自己开发的应用、进行安全研究的应用在合规范围内。尊重知识产权勿将脱壳后的二进制文件用于非法分发、破解或商业用途。手动脱壳是一项细致且需要耐心的工作它没有一键式的完美解决方案。每一次成功脱壳都是对iOS系统机制和Mach-O格式理解的一次加深。希望这篇详尽的教程能为你打开iOS逆向分析的大门。当你亲手从内存中抓取出那些加密的代码并在反编译器中看到清晰的逻辑时那种成就感绝对是使用自动化工具无法比拟的。
