趁着元旦假期，花了一天的时间了解了一下 iOS 和 Mac App 的逆向技术。第一次涉足逆向工程，原本只是打算了解一下逆向的知识，然后发现原来还可以利用逆向做点有趣的事，于是在完成之后记录一下下~
实践结果
通过这次逆向，最终我实现了 iOS 端微信消息的防撤回 和 运动步数的修改 以及 Mac 端微信消息的防撤回 和 迅雷的免登陆免会员使用离线下载 功能 。
当然，软件的权利应当受到保护，逆向的技术亦不应被非法利用。因此本文并非为了破解任何的软件，只是取一些常用的 App 作例子，从技术的角度阐述一下逆向的知识点。
前提条件
由于我的 iOS 设备都系统都在 9.3.5 以上（手动捂脸），因此本次逆向的前提条件是在非越狱的设备上运行的。
前期准备
想要实现 Mac 系（macOS、iOS） Apps 的逆向，首先需要一些工具的协助：
如果有越狱的设备，则还需要 dumpdecrypted 对应用进行 “敲壳” 。由于前提条件，这次就不谈论这个了。
从 Mac 端微信开始
鉴于 Mac 端微信的逆向比较简单，这次就先从这开始吧。这次我们的目标是使得对方的撤回功能失效，即即使对方撤回了消息，我们还能看到对方的消息。那先用 class-dump ，导出微信的头文件吧。
看了一下，40+M 的二进制文件竟然包含了 2000+ 的头文件。好吧，那得 search 一下了。既然是撤回消息，应该其方法名称就包含 ”撤回“ 了吧。Search 一下，目标瞬间缩小成个位数了。
然后我关注到了 MessageService 中有一个方法：
- (void)onRevokeMsg:(id)arg1;
猜测应该就是收到 ”撤回消息“ 这一条消息的时候要执行的方法了，于是试一下吧。
把微信的 Mach-O 文件扔进 Hopper ，然后修改一下其汇编指令，让它不执行任何操作直接返回吧。
重新生成可执行文件之后直接替换掉原来的文件，然后重新运行微信，发现就成功了：）
整个过程为：
Binary --> Assembly Language --> Modification --> Assembly Language --> Binary
至于 iOS 端
同样的功能，在 iOS 端上要实现看起来就要麻烦多了。由于 未越狱的 iOS 并不允许运行未经签名的应用 ，因此在修改之后还需要对 app 进行 重新签名 。同时，在 App Store 里下载到的应用都是经过加密的，因此不能直接就 dump 出其头文件。（同时由于前提条件无法自行敲壳）于是只好直接去 PP助手 下载一个越狱版的 ipa 了。
这次要实现的是 消息防撤回 和 修改微信运动步数 两个功能，于是我们利用 method-swizzling hook 一下，通过动态修改其本该调用的方法来实现。
在得到了已敲壳的 ipa 之后，就能 dump 出头文件了。在 dump 出来之后，我收到了惊吓。。。竟然有高达 8000 个头文件。。。 真是一个好庞大的工程啊。
好吧，然后结果发现 iOS 版的微信 ”撤回“ 功能在 CMessageMgr 中，方法同样是这个呢。
- (void)onRevokeMsg:(id)arg1;
然后用上面同样的方法，在 WCDeviceStepObject 里找到了对应步数的两个属性：
@property(nonatomic) unsigned long hkStepCount;
@property(nonatomic) unsigned long m7StepCount;
猜一下，这里应该就是根据 HealthKit 是否可用然后去取不同的属性吧。那把他们两个的 get 方法都替换了就好~ 利用 iOSOpenDev 创建一个 hook 的模板，就连手动调用 method-swizzling 的代码也省了。
然后加入对应要的 hook 的三个方法，让 onRevokeMsg 不执行任何操作，让 getters 直接返回想要的数值：
@class CMessageMgr;
CHDeclareClass(CMessageMgr);
CHOptimizedMethod(1, self, void, CMessageMgr, onRevokeMsg, id, value1) {
}
@class WCDeviceStepObject;
CHDeclareClass(WCDeviceStepObject);
CHOptimizedMethod(0, self, unsigned long, WCDeviceStepObject, m7StepCount) {
return 66666;
}
CHOptimizedMethod(0, self, unsigned long, WCDeviceStepObject, hkStepCount) {
return 66666;
}
CHConstructor {
@autoreleasepool {
CHLoadLateClass(CMessageMgr);
CHLoadLateClass(WCDeviceStepObject);
CHHook(1, CMessageMgr, onRevokeMsg);
CHHook(0, WCDeviceStepObject, m7StepCount);
CHHook(0, WCDeviceStepObject, hkStepCount);
}
}
这样就好了，build 一下生成 .dylib ，再用 dylib_insert 把动态库的地址注入 Mach-O 就会生成一个新的 Mach-O 文件。
/insert_dylib @executable_path/JustATry.dylib ~/Desktop/WeChat
用 MachOView 就能看到新的动态库已经被注入了：
最后把这个文件改名重新改回 WeChat ，再连同动态库放入原 WeChat.app 并替换原来的文件，再用 iOS App Signer 对其进行重新签名。搞定。
整个过程：
Decrypted Binary --> Insert dylib --> Resign
由于 Objective-C 动态的特性，这次我们可以不用对二进制文件进行反编译，然后再对汇编指令进行修改，只需要直接添加一个动态库就能实现功能的更改了。
至于迅雷的破解
其实迅雷的破解跟 Mac 版微信的破解思路是类似的。
[UserController isLogined];
[UserController isVip]:
[UserController isPlatinum];
[UserController isDiamond];
[LocalTask isValidLixianTask];
让以上五个方法全部返回 YES 即可。
到这吧。
2017-1-28
结尾再送个彩蛋。关于某度云客户端对非会员用户默默地实行最高 80k 的下载速度的事情。原本可以通过使用旧版本 "XX同步盘" 来免受速度的限制，而后来 "XX同步盘" 在启动后检查版本的时候加入了更新提醒并自动退出了程序。而新版的 "XX网盘" 貌似是用 swift 和 objective-c 混编的。
于是直接对旧版 "XX同步盘" 的检查更新方法处理一下就可以继续使用咯。
2017-2-4 再更。
刚发现上述同步盘的彩蛋已失效。原本其通过强制升级来禁止用户使用，而如今改成了在用户登录的时候加入了版本的检测，若使用了旧版本的应用，则会提示登录失败。通过查看 errorMsg 得知是 tpl 的错误：
对比一下旧版本与新版本的请求后发现 tpl 从 mybox 改成 netdisk 了。
旧版本
新版本
当然，由于还有请求签名的存在，这次就不能再仅仅通过动态库修改 tpl 来绕过了。
