听说你想撤回信息？

趁着元旦假期，花了一天的时间了解了一下 iOS 和 Mac App 的逆向技术。第一次涉足逆向工程，原本只是打算了解一下逆向的知识，然后发现原来还可以利用逆向做点有趣的事，于是在完成之后记录一下下~

实践结果

通过这次逆向，最终我实现了 iOS 端微信消息的防撤回 和 运动步数的修改 以及 Mac 端微信消息的防撤回 和 迅雷的免登陆免会员使用离线下载 功能。

当然，软件的权利应当受到保护，逆向的技术亦不应被非法利用。因此本文并非为了破解任何的软件，只是取一些常用的 App 作例子，从技术的角度阐述一下逆向的知识点。

前提条件

由于我的 iOS 设备都系统都在 9.3.5 以上（手动捂脸），因此本次逆向的前提条件是在非越狱的设备上运行的。

前期准备

想要实现 Mac 系（macOS、iOS） Apps 的逆向，首先需要一些工具的协助：

class-dump
Hopper
iOSOpenDev
insert_dylib
MachOView
iOS App Signer

如果有越狱的设备，则还需要 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 来绕过了。