-
Notifications
You must be signed in to change notification settings - Fork 636
Home
Welcome to the wxhelper wiki!
1.发送相关call
关键字 batchSendMsg
case 1 :发送文本
case 2 :发送图片
case 3 :发送文件
如何定位
可以通过CE搜索发送内容的相关引用
然后使用x64dbg或者od在地址处下断点
断点后一步步跟进即可。
熟练后,可以通过ida或者ghidra,直接通过关键字搜索即可。
定位到关键函数后
直接复制汇编,修改相应寄存器对应的值即可。
函数的相应参数可以通过动态调试观察,填写对应参数,注入后调用即可。
就这样一个关键call的调用就完成了。
在ghidra里的伪c代码里可以看到,case 1,2,3,4,5,6 就是对应的关键的发送相关的call。
多练习实践就孰能生巧了。
sqlite3的定位相当简单,一分钟搞定。
因为sqlite3为了保持兼容性,api是向下兼容的,在sqlite3.c文件里有个sqlite3_api_routines,把api固定了。
所以随便定位一个函数,根据他的引用就可以定位到sqlite3_api_routines,然后直接按偏移计算其他函数即可。
sqlite3_close函数特征最明显,直接搜索字符串 "unable to close due to unfinalized statements or unfinished backups"即可定位。
定位了该函数以后,其他函数根据sqlite3_api_routines的偏移也就全部定位到了。
微信里的引用如下:
和sqlite3.c里api保持一致。
微信使用的是SQLCipher加密sqlite3,推而广之也开源采用此方法定位key相关的函数。
再推而广之,开源项目的逆向基本上都可以采用这种套路。
经过简单分析可以确定微信是使用的SQLCipher进行加密。可以简单分析一下SQLCipher的加密过程如下:
然后看下crypto.h,解密就是反过程:
这些事当然要先看看官方的解密工具 https://github.com/sqlcipher/sqlcipher-tools , 简单测试了一下,只解密了第一页,应该是后面更新了版本的原因, 也编译了sqlcipher,不过也没解密成功,因为微信用的是3.40的sqlite,版本不一致。sqlcipher使用的版本是v2.0-statble版本,根据微信里的license,基本上就可以确定。这种体力活,肯定是先搜一搜有现成的工具没有,然后参考了一个博主的python脚本, 简单修改一下即可。
测试了一下效果还可以。
dev-3.9.11.25 分支 Sqllite3Script.java 脚本通过先确定sqlite3_api_routines位置,其余函数可以直接通过脚本定位。 sqlite 版本为3.40. FindSqliteCloseScript.java 脚本是定位sqlite_close函数的脚本,通过该函数关键字搜索相关引用函数,然后根据其他版本定位的函数的fid进行比较,可以定位。 然后再确定sqlite3_api_routines的偏移。 因为sqlite的函数没有进行混淆,x64版本的fid基本上不会有变化,所以多版本可以通用。
NamedScript.java 通过定位wechat内部日志函数,重命名其他函数。 通过观察可以发现,wechat内部函数都会有日志输出,以此可以推断该函数的原始名称就是该函数的第4个参数。
所以按照此规律,可以大大降低逆向难度,还原原始函数名。每个版本的逆向分析成功可以积累到下一个版本使用。
FindCallScript.java 先导入xx.fid相关数据库内容,然后才能执行。 主要是利用以前分析过的结果和已经分析出来的结果直接定位相关函数的偏移。因为wechat有些功能只要没有更新,大概率函数的fid不会改变,所以可以降低重复工作。 ghidra 脚本的位置和使用方式,可以参考ghidra文档。