逆向block是一个稍微难点的活，因为你并不知道需要传什么样的参数，也不知道是什么类型的返回。另外，Swift的block的内存分布的实现与OC不一样会带你入坑。
接着上回逆向系列0x01-在Swift中使用Social框架，我们将实现SLComposeViewController的completion回调。
crash?
打开ViewController.swift把下面逻辑加入到sharingButtonTapped(_:)中：
...
vc.completionHandler = {
print("SLComposeViewController completed")
}
present(vc, animated: true)
...
请确保你已经在设备上登陆了Facebook账号（假设我们使用的的serviceType是Facebook的）。构建并运行，点击分享按钮，然后在这个分享vc出现后点击取消。
嗯，你又会遇到一个crash了。我们来用LLDB分析一下，选择Frame 1：(lldb) frame select 1
仔细观察这里的汇编，红色线的上一个指令是个call指令，地址为对RDI内容的偏移。那现在RDI里面存放的是个什么鬼呢？
跳回到第一个栈帧（你不能在frame 1访问寄存器RDI）：
(lldb) frame select 0
然后打印RDI：
(lldb) po $rdi
输出结果为：
(Function)。有点意思，来看看它是否是个NSObject的子类：
(lldb) po [$rdi class]
_SwiftValue
(lldb) po [$rdi superclass]
NSObject
从我先前的文章常用lldb可以知道，这个类应该继承自一个叫NSBlock的私有类。于是编译器对Swfit的闭包要转换成的OC类型做了一个错误的假设。
这里的意思是你需要显示的将Swift闭包转换成OC的block。这是因为Swift编译器没有completionHandler的类型信息，所以它没有帮我们自动转换。
没错，在上篇的NSObject+P_SLComposeViewController.h中我们的确声明了completionHandler的类型为id。
打开ViewController.swift用以下内容进行替换：
@IBAction func sharingButtonTapped(_ sender: Any) {
guard let vcClass =
NSClassFromString("SLComposeViewController") else { return }
let vc = vcClass.composeViewController(forServiceType:
"com.apple.social.twitter") as! UIViewController
vc.setInitialText("Yay! Doggie Love!")
if let originalImage = imageView.image {
vc.addImage(originalImage)
}
typealias CompletionBlock = @convention(block) () -> Void
vc.completionHandler = {
print("SLComposeViewController completed")
} as CompletionBlock
present(vc, animated: true)
}
我们增加了一个叫CompletionBlock的typealias，它将会把这个Swift闭包转换成何时的OC对象。再次构建并运行app，程序再不会crash了！
OC block的参数
我们先了解以下调用OC block时的汇编指令。
在Xcode中创建一个GUI断点在给completionHandler赋值的那一行。构建并运行app然后点击分享按钮。这个时候断点就会命中一次，Continue忽略这一次继续执行。
接着按Cancel取消按钮，这时候断点会再一次被触发。去到frame2：(lldb) frame select 2
仔细观察这里的汇编，会发现一个有趣的指令。没错了，就是下面红框标注的那一行。
在调用OC的block之前，一个参数会被保存到RSI寄存器中。这意味着这个OC block有一个参数。
在当执行停止时RSI寄存器没有被重写的前提下，我们可以打印出RSI的内容。又因为我们刚好停在block执行的最开始，所以RSI寄存器的内容应该是完好如初的。
跳回到frame 0并打印RSI的内容：
(lldb) frame select 0
(lldb) register read rsi
rsi = 0x0000000000000000
那儿并没有任何东西。这似乎有点悲剧。但它至少能告诉我们一些东西。在经过一番研究折腾苹果是如何实现他们的API之后，我们可以假设一个为nil的NSObject被传进去了，又或者它是某种东西。在这个情形里，它可能是个枚举值enum来标记vc是否正常结束。
只有一种途径来验证这个猜想。我们需要一次成功的内容推送然后观察RSI寄存器有什么变化。
那就推送吧（反正图片是两只可爱的狗狗，非常河蟹），点击Post之后断点应该再一次命中。此时再来检验一下RSI的值：
(lldb) register read rsi
rsi = 0x0000000000000001
完美！现在它的值是1了。这意味着这个传进来的参数是个会根据操作结果是失败还是成功而变化的枚举值（或者布尔值，差不多的）。好了我们要更新一下completionHandlerblock的类型了。
打开NSObject+P_SLComposeViewController.h然后用以下内容替换：
typedef enum : NSUInteger {
P_SLComposePostFailed = 0,
P_SLComposePostSuccess = 1
} P_SLComposePost;
@interface NSObject (P_SLComposeViewController)
+ (id)composeViewControllerForServiceType:(NSString *)serviceType;
- (BOOL)setInitialText:(id)text;
- (BOOL)addImage:(id)image;
@property (copy, nonatomic) void (^completionHandler)(P_SLComposePost);
稍微改一下ViewController.swift：
vc.completionHandler = { result in
let resultString = result == P_SLComposePostFailed ? "failed" :
"success"
print("SLComposeViewController completed with result: \(resultString)")
}
注意到我们再也不需要typealias了。这是因为我们已经把completionHandler的类型从id改为了了一个block类型，于是编译器便知道了应该把这里的Swift闭包看待成OC的block。
大功告成！我们成功的探索并使用了别人的代码来发送一个Facebook的post，这个过程中我们并没有借助任何头文件或者其他关于模块的信息。
下篇预告：查找和执行代码只是逆向Framework时的挑战之一。下一个挑战便是修改Framework的函数的参数或逻辑来满足我们自己的需求！暴走吧！逆向！