概叙
越狱防护是指防止别人修改自己的APP作出的防护手段。
1.了解代码注入方式
了解防护之前需要了解代码注入的方式，针对性防护。
代码注入一般有两种方式：
- 第一种是通过注入动态库改变machO文件头的Load_Command字段，注入dyld或者framework，让dyld加载我们注入的动态库。
- 第二种是通过配置
DYLD_INSERT_LIBRARIES的环境变量，在dyld执行过程中插入动态库。
Theos是一个逆向插件，它可以生成的dylib动态库后通过DYLD_INSERT_LIBRARIES的方式插入到app中。采用了第二种注入方式。
了解Theos的工作方式后，我们现在对Theos进行防护！
2 防护
2.1 了解dyld的插入过程
在做防护前我们先了解dyld，dyld是app程序调用前的执行代码，他会帮我们启动库、执行machO文件、并执行程序代码入口的程序，是苹果开源的代码。可以百度搜索下载得到！
打开dyld，全局搜索DYLD_INSERT_LIBRARIES找到插入动态库的函数调用位置。
在第5909行有一个loadInsertedDyldb(*lib)加载动态库的函数，此函数是调用动态库的函数。
dyld在调用这个函数的前面做了很多判断！
但在5693行有一个重要的判断条件是关键：gLinkContext.processIsRestricted
这个函数开关是限制动态库的开关，只要符合这个条件就无法插入动态库。
那在什么时候这个
gLinkContext.processIsRestricted才会等于true呢？全局搜索一下
processIsRestricted = true在第一个结果中可以看到这个判断条件等于true
而他前面还有两个判断条件
( issetugid() || hasRestrictedSegment(mainExecutableMH) )其中
issetugid()是系统调用公用动态库的函数，是私有的，无法知其工作原理。而
hasRestrictedSegment(mainExecutableMH)是可以看得到源码的。跳转到
hasRestrictedSegment(mainExecutableMH)函数中。
可以看到这里面判断了两个东西 ：
__RESTRICT和 __restrict。如果这两个东西存在就返回true。就符合我们的预期。表示是限制的。
在看看此函数，在函数的入参中有一个macho_header结构体类型，这个地方传进来的其实就是machO文件的头。那么只需要在machO文件的头添加这两个字段就可以起到防护的效果！
2.2 开始第一次防护
我们随意新建一个demo。
然后在Build Settings中搜索other linker flags。
并输入值-Wl,-sectcreate,__RESTRICT,__restrict,/dev/null。
这样就能完成那两个字段，此乃固定写法。
只需要在此处添加这一句话，编译后就会在ipa包的machO文件的头部出现__RESTRICT和 __restrict判断条件。
通过MachOView工具就可以看到效果
对此就完成了通过
DYLD_INSERT_LIBRARIES方式注入动态库的防护。
2.3 攻破防护！
你以为通过添加两个字段就搞定防护了吗？太幼稚了。
我只要把这两个字段随便改掉，你这个防护一点用都没有了！
我们可以通过修改machO的二进制进行修改__RESTRICT和 __restrict。
下面介绍一款工具：Synalyze It! Pro Mac。
Synalyze It! Pro是一款Mac上的16进制编辑工具，能够实时编辑任何二进制文件，简单易用，支持多种字符编码、Python和Lua脚本、导出XML和TXT文件等等，可谓反向工程的利器，对于经常需要编辑二进制文件的开发者很有帮助！
通过此工具打开ipa内的machO文件，通过搜索直接可以定位到修改处！
我们对其进行随意修改，如下图。
修改完成后记得保存！
然后我们在把修改过对machO文件放回原来ipa内，覆盖掉原来的machO文件。
覆盖完后还是不能直接运行，需要对其进行重签才能运行在手机中！
使用Monkey可以很轻松的完成重签过程！推荐使用。
这样我们又再一次攻破machO的防线！
2.4 再一次防护！
既然被攻破，那就再防护一次！
你修改了__restrict字段，那我监测一下你有没有修改那两个字段行不行？
答案是肯定的！
事实上mach-o程序是公开使用的，导入头文件！
#import <mach-o/dyld.h>
#import <mach-o/loader.h>
再把dyld的这段代码复制过来！
//
// Look for a special segment in the mach header.
// Its presences means that the binary wants to have DYLD ignore
// DYLD_ environment variables.
//
#if __MAC_OS_X_VERSION_MIN_REQUIRED
static bool hasRestrictedSegment(const macho_header* mh)
{
const uint32_t cmd_count = mh->ncmds;
const struct load_command* const cmds = (struct load_command*)(((char*)mh)+sizeof(macho_header));
const struct load_command* cmd = cmds;
for (uint32_t i = 0; i < cmd_count; ++i) {
switch (cmd->cmd) {
case LC_SEGMENT_COMMAND:
{
const struct macho_segment_command* seg = (struct macho_segment_command*)cmd;
//dyld::log("seg name: %s\n", seg->segname);
if (strcmp(seg->segname, "__RESTRICT") == 0) {
const struct macho_section* const sectionsStart = (struct macho_section*)((char*)seg + sizeof(struct macho_segment_command));
const struct macho_section* const sectionsEnd = §ionsStart[seg->nsects];
for (const struct macho_section* sect=sectionsStart; sect < sectionsEnd; ++sect) {
if (strcmp(sect->sectname, "__restrict") == 0)
return true;
}
}
}
break;
}
cmd = (const struct load_command*)(((char*)cmd)+cmd->cmdsize);
}
return false;
}
#endif
复制过来后出现了很多警告和错误。大部分是类型的问题，我们把相关的类型定义也复制过来！
#if __LP64__
#define LC_SEGMENT_COMMAND LC_SEGMENT_64
#define LC_SEGMENT_COMMAND_WRONG LC_SEGMENT
#define LC_ENCRYPT_COMMAND LC_ENCRYPTION_INFO
#define macho_segment_command segment_command_64
#define macho_section section_64
#else
#define LC_SEGMENT_COMMAND LC_SEGMENT
#define LC_SEGMENT_COMMAND_WRONG LC_SEGMENT_64
#define LC_ENCRYPT_COMMAND LC_ENCRYPTION_INFO_64
#define macho_segment_command segment_command
#define macho_section section
#endif
这样就少了很多警告！
其中有一个是入参macho_header的警告
实际上macho_header是有32位和64位架构的读取方式。
/*
* The 32-bit mach header appears at the very beginning of the object file for
* 32-bit architectures.
*/
struct mach_header {
uint32_t magic; /* mach magic number identifier */
cpu_type_t cputype; /* cpu specifier */
cpu_subtype_t cpusubtype; /* machine specifier */
uint32_t filetype; /* type of file */
uint32_t ncmds; /* number of load commands */
uint32_t sizeofcmds; /* the size of all the load commands */
uint32_t flags; /* flags */
};
/*
* The 64-bit mach header appears at the very beginning of object files for
* 64-bit architectures.
*/
struct mach_header_64 {
uint32_t magic; /* mach magic number identifier */
cpu_type_t cputype; /* cpu specifier */
cpu_subtype_t cpusubtype; /* machine specifier */
uint32_t filetype; /* type of file */
uint32_t ncmds; /* number of load commands */
uint32_t sizeofcmds; /* the size of all the load commands */
uint32_t flags; /* flags */
uint32_t reserved; /* reserved */
};
这是两种结构体。
我们需要区分32架构和64架构使用的结构体。在下面的构架方式定义中添加两条宏定义。
#if __LP64__
#define macho_header mach_header_64 //64为架构中添加此条
#define LC_SEGMENT_COMMAND LC_SEGMENT_64
#define LC_SEGMENT_COMMAND_WRONG LC_SEGMENT
#define LC_ENCRYPT_COMMAND LC_ENCRYPTION_INFO
#define macho_segment_command segment_command_64
#define macho_section section_64
#else
#define macho_header mach_header //32为架构中添加此条
#define LC_SEGMENT_COMMAND LC_SEGMENT
#define LC_SEGMENT_COMMAND_WRONG LC_SEGMENT_64
#define LC_ENCRYPT_COMMAND LC_ENCRYPTION_INFO_64
#define macho_segment_command segment_command
#define macho_section section
#endif
添加完成！
重新编译一下，编译通过！
接下来调用这个函数！
我们在load方法中调用，这个方法是在main后最先调用的方法了！
判断如果是有字段存在，表明未被修改，否则被修改！
+ (void)load{
//获取镜像image的头。
//image是一个列表，列表中第一个就是自己的镜像
//还记得通过lldb的`image list`指令获取的镜像列表吗？就是它！
const struct macho_header* header = _dyld_get_image_header(0);
if (hasRestrictedSegment(header)) {
NSLog(@"安全！");
}else{
NSLog(@"被修改了__RESTRICT或__restrict");
exit(0);
}
}
到这里我们就再一次做了防护！
这里有一个问题！
发现被修改后执行exit(0)真的好吗?
不一定～因为一旦执行退出程序操作，就相当于告诉黑客我执行了什么代码。黑客就可以通过这个提示去找到对应的方法。降低了防御能力！
微信是如何做的呢？微信被注入后是没有任何提示！它在你不知不觉中就上报了一段序号，比如89757，我们根本不知道这是什么！一旦被发现，第二天可能就被封号。这种情况下，你很难找到它在什么时候做了防护！
第二种防护方式！《白名单库》
第二种方式是把正常使用的镜像库列表作为字符串保存，然后在dyld加载动态库时判断是否一致实现的。
如果dyld在执行过程中插入了任何的动态库，都会判断为被修改了！
怎么做呢？
@implementation ViewController
const char * libPaths = "/var/containers/Bundle/Application/3C9EDF66-A49D-4CF2-BDC8-03EA2E26E3E6/demo.app/demo
/Developer/usr/lib/libBacktraceRecording.dylib
/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib
/System/Library/Frameworks/Foundation.framework/Foundation/usr/lib/libobjc.A.dylib/usr/lib/libSystem.B.dylib
/System/Library/Frameworks/UIKit.framework
/UIKit/usr/lib/libarchive.2.dylib/usr/lib/libicucore.A.dylib
/usr/lib/libxml2.2.dylib/usr/lib/libz.1.dylib
..."
+ (void)load{
int count = _dyld_image_count();
for (int i = 0; i<count; i++) {
// 在打包前先把库链接打印粗来，复制保存到libPaths，用于对比
const char * libPath = _dyld_get_image_name(i);
// 通过这个方法判断libs是否包含libPath，如果包含会返回libPath，否则返回空。
// 后面这个判断是判断自己，因为自己所在的是一个沙盒路径，路径不是固定的，所以要排除它
if (!strstr(libPaths, libPath)&&
!strstr(libPath, "/var/mobile/Containers/Bundle/Application")){
printf("被修改了！");
}
else{
printf("该库在白名单内，安全！");
}
}
}
这样，防护又做了一个，安全又提高了一点点。
但是这样做其实还是可以被修改，因为libPaths是全局的字符串，还是可以拿到修改的。起到防护效果有限！
结语
防护的方式还有很多很多，这里只是一些启发性的知识点，更多防护还需要更多学习。
