听说你想撤回信息?

趁着元旦假期,花了一天的时间了解了一下 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 中有一个方法:

1
- (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 中,方法同样是这个呢。

1
- (void)onRevokeMsg:(id)arg1;

然后用上面同样的方法,在 WCDeviceStepObject 里找到了对应步数的两个属性:

1
2
@property(nonatomic) unsigned long hkStepCount;
@property(nonatomic) unsigned long m7StepCount;

猜一下,这里应该就是根据 HealthKit 是否可用然后去取不同的属性吧。那把他们两个的 get 方法都替换了就好~ 利用 iOSOpenDev 创建一个 hook 的模板,就连手动调用 method-swizzling 的代码也省了。

然后加入对应要的 hook 的三个方法,让 onRevokeMsg 不执行任何操作,让 getters 直接返回想要的数值:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
@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 文件。

1
/insert_dylib @executable_path/JustATry.dylib  ~/Desktop/WeChat

MachOView 就能看到新的动态库已经被注入了:

最后把这个文件改名重新改回 WeChat ,再连同动态库放入原 WeChat.app 并替换原来的文件,再用 iOS App Signer 对其进行重新签名。搞定。

整个过程:

Binary –> Insert dylib –> Resign

由于 Objective-C 动态的特性,这次我们可以不用对二进制文件进行反汇编,然后再对汇编指令进行修改,只需要直接添加一个动态库就能实现功能的更改了。

至于迅雷的破解

其实迅雷的破解跟 Mac 版微信的破解思路是类似的。

1
2
3
4
5
[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 来绕过了。