dumpdecrypted的发展历史：
在 iOS 平台上，从 App Store 下载的 App 会被 Apple 使用 FairPlay 技术加密，使得程序无法在其他未登录相同 AppleID 的设备上运行，起到 DRM 的作用。这样的文件同样也无法使用 IDA Pro 等工具进行分析。不管是出于安全研究还是再次分发的目的，都需要获取未加密的二进制文件，这一过程俗称砸壳。
最早的动态砸壳工具是stefanesser写的dumpdecrypted，通过手动注入然后启动应用程序，在内存进行dump解密后的内存实现砸壳。
但是这种砸壳只能砸APP可执行文件，对于动态库就无能为力了。为什么呢？这是个2014年就停止更新的项目，那时候iOS8系统刚出，也是苹果刚开始尝试在iOS系统中使用动态库，因此很少有人使用，iOS7之前又全是静态库，是直接编在APP的可执行文件中的，所以只要砸二进制主文件。
但是英雄总是出现在人民群众最需要他的时刻，就在大家一筹莫展之际，conradev出现了，他稍微改进了一下dumpdecrypted，使它具有了砸动态库的能力。
原理是通过_dyld_register_func_for_add_image注册回调对每个模块进行dump解密。
然而问题出现了，这种砸壳方式依然需要拷贝dumpdecrypted.dylib，然后找路径什么的，还是挺麻烦的，而且最重要的一点，自从iOS系统增加了widget和watchOS APP之后，这个版本的dumpdecrypted砸不了带有Plugins（也就是extension）的壳。
于是又一位英雄出现了，也就是iOSRE界大家熟知的庆总AloneMonkey（刘培庆），也是MokeyDev的作者。
他又对dumpdecrypted进行了修改，放到MonkeyDev模板变成一个tweak的形式dumpdecrypted，这样填写目标bundle id然后看日志把文件拷贝出来就可以了，当然，这里的dumpdecrypted已经被现在的frida-ios-dump取代了。
分析一下最终的dumpdecrypted
我们可以分析一下他的代码，看一下两个问题：
究竟做了什么操作，为什么可以砸Frameworks和extension的壳了？
原版的 dumptofile 的函数参数是怎么来的？
首先介绍一下attribute修饰词
GNU C 的一大特色就是__attribute__ 机制。
__attribute__ 可以设置函数属性（Function Attribute ）、变量属性（Variable Attribute ）和类型属性（Type Attribute ）。
__attribute__ 书写特征是：__attribute__ 前后都有两个下划线，并切后面会紧跟一对原括弧，括弧里面是相应的__attribute__ 参数。
__attribute__ 语法格式为：__attribute__ ((attribute-list))
constructor参数的作用
constructor参数让系统执行main()函数之前调用函数(被attribute((constructor))修饰的函数).同理,destructor让系统在main()函数退出或者调用了exit()之后,调用我们的函数.带有这些修饰属性的函数,对于我们初始化一些在程序中使用的数据非常有用.
为什么可以砸Framework和extension的壳
在这个dumpdecrypted(建议下载源码看一下，再看下面的解释)的Frameworks 分支版本中用到了上面介绍的参数：
__attribute__((constructor))
static void dumpexecutable() {
...
_dyld_register_func_for_add_image(&image_added);
}
所以这里 dumpexecutable() 方法在 main 函数之前执行_dyld_register_func_for_add_image方法，这里用到了dyld里的函数，我们来看一下这个函数的实现（开源大法好opensource-apple）：
/*
* _dyld_register_func_for_add_image registers the specified function to be
* called when a new image is added (a bundle or a dynamic shared library) to
* the program. When this function is first registered it is called for once
* for each image that is currently part of the program.
*/
void
_dyld_register_func_for_add_image(
void (*func)(const struct mach_header *mh, intptr_t vmaddr_slide))
{
DYLD_LOCK_THIS_BLOCK;
typedef void (*callback_t)(const struct mach_header *mh, intptr_t vmaddr_slide);
static void (*p)(callback_t func) = NULL;
if(p == NULL)
_dyld_func_lookup("__dyld_register_func_for_add_image", (void**)&p);
p(func);
}
dyld 会负责传递 mh 和 vmaddr_slide 参数
我们看一下这里intptr_t到底是个什么类型，继续追踪：
// usr/include/sys/_types/_intptr_t.h
typedef __darwin_intptr_t intptr_t;
// usr/include/arm/_types.h
typedef long __darwin_intptr_t;
可以清楚的看到，intptr_t就是__darwin_intptr_t，也就是个long类型（不懂为啥这么麻烦，还typedef两次）
继续看代码，这里写了一个image__added方法，该方法调用了 dumptofile 函数：
static void image_added(const struct mach_header *mh, intptr_t slide) {
Dl_info image_info;
int result = dladdr(mh, &image_info);
dumptofile(image_info.dli_fname, mh);
}
_dyld_register_func_for_add_image从注释中可以知道，通过_dyld_register_func_for_add_image 注册的回调函数会在每次 dyld 加载镜像之后被调用。传递给回调函数的参数有两个：载入镜像的文件头：mach_header 和内存数量：vmaddr_slide。在本例中，dumpexecutable 函数中通过 _dyld_register_func_for_add_image 函数向 dyld 注册一个回调函数 image_added，每当 dyld 载入一个镜像（可以是可执行程序、动态库、Plugin等），dyld 会调用 image_added 函数，并将相应的 Mach-O header 和 vmaddr_slide 传递给 image_added，这也就是为什么可以砸Framework和extension的原因。
关于原版dumpdecrypted的dumptofile函数实现
查找 dyld 后发现在 ImageLoader.h 头文件中,有一个很长的函数：
typedef void (*Initializer)(int argc, const char* argv[], const char* envp[], const char* apple[], const ProgramVars* vars);
然后再ImageLoaderMachO.cpp中找到了调用：
void ImageLoaderMachO::doImageInit(const LinkContext& context)
{
if ( fHasDashInit ) {
const uint32_t cmd_count = ((macho_header*)fMachOData)->ncmds;
const struct load_command* const cmds = (struct load_command*)&fMachOData[sizeof(macho_header)];
const struct load_command* cmd = cmds;
for (uint32_t i = 0; i < cmd_count; ++i) {
switch (cmd->cmd) {
case LC_ROUTINES_COMMAND:
Initializer func = (Initializer)(((struct macho_routines_command*)cmd)->init_address + fSlide);
// <rdar://problem/8543820&9228031> verify initializers are in image
if ( ! this->containsAddress((void*)func) ) {
dyld::throwf("initializer function %p not in mapped image for %s\n", func, this->getPath());
}
if ( context.verboseInit )
dyld::log("dyld: calling -init function %p in %s\n", func, this->getPath());
//就是这句话了
func(context.argc, context.argv, context.envp, context.apple, &context.programVars);
break;
}
cmd = (const struct load_command*)(((char*)cmd)+cmd->cmdsize);
}
}
}
根据函数命名知道这应该是给镜像做初始化的,里面 func 函数是 Initializer 类型的,通过 context 参数获取上下文信息,原版的 dumptofile 函数的参数列表为什么会是 (int argc, const char argv, const char envp, const char *apple, struct ProgramVars pvars) 到这里就很清楚了。
