微信安卓协议分析笔记

一、查资料

        网上没找到SDK可以分析，关于微信安卓协议的文章也比较少，比较有用的是<微信交互协议和加密模式研究>,这篇论文里介绍了微信使用RSA2048与AES-CBC-128结合的加密算法以及使用protobuf编码格式传输数据；<微信协议简单调研笔记>帖子里提到微信使用长短链接结合的网络通讯方式以及基于sync key的消息同步机制；<基于TLS1.3的微信安全通信协议mmtls介绍>详细讲解了类似于https中TLS作用的mmtls协议；<微信安卓客户端逆向分析>通过举例拦截聊天记录详细演示了安卓微信客户端分析的过程.

二、准备工作

        工具除了安卓反编译常用打包解包软件以及查看java代码的软件,还可以用XSearch方便在大量smali汇编文件中快速搜索字符串,Wireshark用于抓包,Android Studio动态调试smali汇编代码,IDA静态分析so文件，WinHex用于编辑二进制文件.

       微信底层使用自家开源的跨平台通讯库mars,该库包含xlog模块,详尽记录了微信几乎所有主要函数调用流程,开启log可以极大地方便动态分析,研究mars库也有助于理解微信与服务器交互流程.

       由于mmtls无法中间人攻击,所以抓包无法获取短链接HTTP通讯的明文数据;考虑到兼容性微信允许在不使用mmtls的情况下通讯,所以关闭mmtls有助于协议分析.

       由于长链接含有包头不利于分析，考虑到稳定性微信允许在不使用长链接的情况下通讯，所以禁用长链接有利于协议分析.

三、二次打包客户端

        微信允许非官方签名的客户端运行,但是会校验签名并上报异常数据.最近因使用非官方客户端封号的风控策略越来越严格,运行二次打包客户端时要做好被封号准备,或者使用XP插件Hook代码,或者patch掉获取软件签名的代码或者禁掉上传异常数据的封包,总之这不是本文的重点.如果反编译工具直接打包失败,可以只重新编译dex文件,然后替换到原来的apk中.

       从mars库的Xlog文档中可以知道setConsoleLogOpen接口负责开启控制台log,在反汇编代码中搜索这句代码的调用"->setConsoleLogOpen",找到XLogSetup.smali文件直接修改Lcom/tencent/mars/xlog/Xlog;->setConsoleLogOpen的调用参数即开启log.搜索getLogLevel最终可以在Lcom/tencent/mm/sdk/platformtools/下面找到输出Log等级的定义,从6改为0即可打印所有等级的log.logcat里可以通过"MicroMsg""mars"两个tag来分别过滤java层和native层的log.

       运行开启Log的客户端,过滤tag为"mmtls"的日志,可以找到"Java_com_tencent_mars_mm_MMLogic_setMmtlsCtrlInfo"函数打印的log:

1	I/mars::mmext(12496): [com_tencent_mars_mm_MMLogic_Java2C.cc, Java_com_tencent_mars_mm_MMLogic_setMmtlsCtrlInfo, 299]:j_use_mmtls=1

       从函数名可以猜出这是java调用jni控制开启mmtls的接口,在反汇编代码中搜索";->setMmtlsCtrlInfo"找到调用的代码,修改参数为0关闭mmtls.

       从mars库中可以看出,长链接使用mars/stn/src/longlink.cc文件的LongLink::__RunConnect函数连接服务器,解压apk搜索字符串"longlink.cc"可知mars库编译出的文件为libwechatnetwork.so,在二进制文件中结合IDA patch掉该函数返回值可以禁用长链接;从mars文档也可以看出上层需要调用mars::stn::MakesureLonglinkConnected();启用长链接,在smali代码中搜索调用";->makesureLongLinkConnected"的代码注释掉也可关闭长链接.

四、抓包

        使用安卓模拟器或用手机连接电脑开启的wifi,运行二次打包处理的客户端,使用Wireshark工具即可抓到微信短链接的HTTP协议封包了.比如登录包可以抓到使用POST方法向/cgi-bin/micromsg-bin/manualauth 发送了1183字节长度的数据,数据是被加密的：

       <微信安卓客户端逆向分析>文章中提到数据是被libMMProtocalJni.so这个库加密的,使用IDA查看该库的jni接口:

可以看到"Java_com_tencent_mm_protocal_MMProtocalJni_pack"很可能是封包加密的接口，在smali反汇编代码中搜索调用该接口的代码"MMProtocalJni;->pack"如下:

根据log tag"RemoteReq"以及"reqToBuf using protobuf ok"可以猜测这里就是protobuf明文加密封包的地方.接下来可以使用AS在smali这句代码上下断点观察参数与返回值,如果配置调试环境有困难,可以在smali代码中插log将参数与返回值打印并保存下来,方便后面分析.其中第二个参数类型是PByteArray,这是自定义的类型,需要打印的字节数组为该对象的value成员变量;使用Log.d在控制台打印时默认有4000字节的长度限制,超过的部分无法输出,插入log时注意将长log拆分多行输出.

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 31

#参数1:logtag,参数2:需要打印的bytes .method  public  static  logX(Ljava/lang/String;[B)V      .locals 8      .prologue      if -eqz p1, :cond_1      #如果参数p1是PByteArray,要取其成员变量value      #iget-object v1, p1, Lcom/tencent/mm/pointers/PByteArray;->value:[B      move-object v1, p1      #使用平台自带的将bytes转成string的函数,每个版本混淆函数名略有不同      invoke- static  {v1}, Lcom/tencent/mm/sdk/platformtools/bh;->bp([B)Ljava/lang/String;      move-result-object v1      invoke- virtual  {v1}, Ljava/lang/String;->length()I      move-result v2      const  v4, 0x0      #超过4000字节长度的 log ,分行输出      const  v3, 0xfa0      :goto_0      if -ge v4, v2, :cond_1      move v5, v4      add- int /2addr v5, v3      if -le v5, v2, :cond_0      move v5, v2      :cond_0      invoke- virtual  {v1, v4, v5}, Ljava/lang/String;->substring(II)Ljava/lang/String;      move-result-object v6      invoke- static  {p0, v6}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I      move v4, v5      goto  :goto_0      :cond_1      return - void .end method

准备好抓包环境并开启log,向任意好友发送一条消息,对比Wireshark抓到的发送的二进制数据与log中记录的该函数执行后第二个参数pByteArray.value的值发现一模一样,而该函数的入参可以看到有发送消息的明文数据,说明这就是微信的组包函数,实现 Java_com_tencent_mm_protocal_MMProtocalJni_pack 函数是分析微信协议的核心.

        用同样的方法分析可知"Java_com_tencent_mm_protocal_MMProtocalJni_unpack"是解包函数,函数执行后第1个参数pByteArray中保存解密后的protobuf数据.

        登录包由于涉及密钥协商,使用"Java_com_tencent_mm_protocal_MMProtocalJni_packHybrid"函数组包.

        把抓到的完整HTTP数据保存下来,自己写代码模拟向相同地址端口POST相同登录包数据,发现每次都返回相同的数据,说明登录包可以被重放攻击.

五、协议分析

         Http post的数据如下:

        重复登录几次对比封包数据,发现封包数据的前几字节基本是固定的,而且含有大量的连续"00"数据。由于加密后的数据通常无规律，所以一般情况下这些"00"附近的数据都是未加密的数据,而在封包前面出现的未加密数据一般是包含封包重要信息的封包头.

        首先查看这些二进制数据对应的ASCII数据,并未发现有意义的字符串；接下来只能靠经验"猜"每个字节代表的意义,然后尝试修改该字节重发封包验证.由于有详尽的log,这里可以直接根据log中的关键数据直接与二进制数据对比分析其意义,这将大大提高分析的成功率.比如,登录包组包log片段如下:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

D/MicroMsg.Jni( 2889): [common_function.h, CLogScope, 78]:--> Enter protocal_packHybrid V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 170]:cookie length=15 V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 172]:cookie attached V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 179]:rsa length=174 V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 181]:rsa attached V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 188]:aes length=1610 V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 190]:aes attached V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 197]:keye length=6 V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 199]:keye attached V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 206]:keyn length=512 V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 208]:keyn attached V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 215]:pkey length=16 V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 217]:pkey attached D/TLV_LOG ( 2889): [common_function.h, CLogScope, 78]:--> Enter EncodeHybirdEncryptPack V/TLV_LOG ( 2889): [mmpack.cpp,  bool  EncodeHybirdEncryptPack(Comm::SKBuffer&, Comm::SKBuffer&, unsigned  int , unsigned  char *, emMMFunc, unsigned  int , Comm::SKBu, 178]:writing head, g_clientVer: 637864504, flag:7 D/TLV_LOG ( 2889): [mmpack.cpp,  bool  EncodeHybirdEncryptPack(Comm::SKBuffer&, Comm::SKBuffer&, unsigned  int , unsigned  char *, emMMFunc, unsigned  int , Comm::SKBu, 207]:EncodeHybirdEncryptPack fgflag:1, cver：1001, calgo:2, clen:1180, cdlen:1180, ealog:7 I/TLV_LOG ( 2889): [skbuffer.cpp, EnsureExpandSize, 58]:EnsureExpandSize 34 to 1214 increase 1180 V/TLV_LOG ( 2889): [mmpack.cpp,  bool  EncodeHybirdEncryptPack(Comm::SKBuffer&, Comm::SKBuffer&, unsigned  int , unsigned  char *, emMMFunc, unsigned  int , Comm::SKBu, 219]:packing done, uin=0, func=701, ret=0 D/TLV_LOG ( 2889): [common_function.h, ~CLogScope, 83]:<-- Exit EncodeHybirdEncryptPack D/MicroMsg.Jni( 2889): [common_function.h, ~CLogScope, 83]:<-- Exit protocal_packHybrid

        log中"g_clientVer: 637864504"这句是打印客户端版本号 ,637864504二进制为26050A38,可以看到这与二进制封包数据中第3到第6字节一致,结合该版本的发布版本号"6510"更加确定封包头部的这4字节就是代表当前客户端的大、小版本号,这也印证了封包前面几个字节的数据是未加密的猜想.

        对于封包第一字节,通常固定是"bf",只有少部分不以"bf"开头(如截图中的登录包),log中也没找到该字节的含义,这种情况就只能反复发包测试验证是否必须以"bf"开头的封包才合法。目前测试下来是否包含该字节不影响通信.

        封包头剩余数据无法直接猜出意义，只能静态分析libMMProtocalJni.so中组包函数代码,必要时可以使用IDA下断点调试参数及栈,如果搭建动态调试so环境有困难,可以尝试调试PC版本微信的WeChatWin.dll,最近版本该dll都没有加壳.mars是跨平台的组件，PC版和android版底层通信代码差不多.

        从上面的log片段中找到关键词"writing head"定位到组包函数函数:EncodeHybirdEncryptPack

最终组包函数片段:

从组包函数可以看出有些字节的数据是由2个4bits的数据组合起来的,有些数据是转网络字节序后再经过处理的,处理的函数如图:

        这是整数压缩算法.

        尝试将包头中的数据使用整数压缩算法还原后,"BD 05"对应整数701,对应log中的

1	V/TLV_LOG ( 2889): [mmpack.cpp,  bool  EncodeHybirdEncryptPack(Comm::SKBuffer&, Comm::SKBuffer&, unsigned  int , unsigned  char *, emMMFunc, unsigned  int , Comm::SKBu, 219]:packing done, uin=0, func=701, ret=0

        "8C 09"对应整数1164,对应log中的clen(log是之前抓的,与截图中的封包不对应,实际log中应是clen: 1164 , cdlen: 1164 )

1	D/TLV_LOG ( 2889): [mmpack.cpp,  bool  EncodeHybirdEncryptPack(Comm::SKBuffer&, Comm::SKBuffer&, unsigned  int , unsigned  char *, emMMFunc, unsigned  int , Comm::SKBu, 207]:EncodeHybirdEncryptPack fgflag:1, cver：1001, calgo:2, clen:1180, cdlen:1180, ealog:7

        对比log可以猜出包头大部分字节的含义,第一个字节对应的代码:

        前6bits代表包头长度,后2bits表示是否使用压缩算法,在log中搜索"calgo",

        可以看出clen大于cdlen时calgo为1,即使用压缩算法; clen等于cdlen时calgo为2,即不使用压缩算法.

        从文档中前人已经分析出微信登录使用rsa算法协商秘钥后续使用aes加密通信数据，log中也明确记录了加密算法和密钥，如图：

1 2 3 4 5 6 7 8 9 10

V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 179]:rsa length=174 V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 181]:rsa attached V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 188]:aes length=1610 V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 190]:aes attached V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 197]:keye length=6 V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 199]:keye attached V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 206]:keyn length=512 V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 208]:keyn attached V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 215]:pkey length=16 V/MicroMsg.Jni( 2889): [MMProtocalJniImpl.cpp, protocal_packHybrid, 217]:pkey attached

        rsa的公钥n,e是内置在客户端里的，分为157和158两个版本:

         aes的密钥在log中只能看到一个key,没有iv.在腾讯开源项目mars中的aes_crypt.c文件中的aes_cbc_encrypt加密函数中,iv和key是相同的:

        在libMMProtocalJni.so也可以找到对应的代码:

        将明文protobuf数据和加密key从log中拷贝出来用aes在线加解密工具验证,加解密结果与log中一致,表明微信使用aes-cbc-128加密算法通讯.

        在log中搜索aes加密key的二进制数据,寻找该key第一次出现的位置,附近很可能有密钥计算的相关信息：

1 2 3 4 5 6 7 8 9 10 11 12 13 14

I/MicroMsg.AutoAuth( 2182): [, , 2182]:summerauth end type: 701, ret:[0,0][null] D/[LogI]( 2182): summerauth end type: 701, ret:[0,0][null] D/[LogD]( 2084): summerauth decodeAndRetriveAccInfo type:701 D/[LogI]( 2084): summerauth decodeAndRetriveAccInfo type:701, hashcode:196488030, ret:0, stack[[sdk.platformtools.v:i(262)][s.ap:b(661)][w.s:BQ(186)][network.q$a:onTransact(156)]] D/[LogI]( 2084): decodeAndRetriveAccInfo authResultFlag:4 UpdateFlag:1  D/[LogD]( 2084): summerauth svr ecdh key len:57, nid:713 sessionKey len:32, sessionKey： 9d d4 f8 c6 65 fe 03 ab 1b f5 03 ca 06 4d eb 0a a9 b0 05 38 3f 0f d4 79 c7 1a 2e 63 72 65 77 1e D/[LogD]( 2084): summerauth svrPubKey len:57 value: 04 6d 02 6d e2 94 22 48 00 fb c3 ec 1c 63 45 bb 84 c8 97 3f 8e 35 4b ed ce a3 d7 68 71 51 99 35 aa 2b 03 9d 1b c4 e2 f0 24 f5 fc 99 39 0e 8f ff a9 f9 6a 34 10 98 8d bb 11 prikey len:328, values: 30 82 01 44 02 01 01 04 1c 2e b1 e1 70 b0 c0 9f 3a a8 f3 8d 15 1e 50 30 80 b1 ed 93 be 03 e9 50 c9 f8 8a 80 7d a0 81 e2 30 81 df 02 01 01 30 28 06 07 2a 86 48 ce 3d 01 01 02 1d 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 01 30 53 04 1c ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff fe 04 1c b4 05 0a 85 0c 04 b3 ab f5 41 32 56 50 44 b0 b7 d7 bf d8 ba 27 0b 39 43 23 55 ff b4 03 15 00 bd 71 34 47 99 d5 c7 fc dc 45 b5 9f a3 b9 ab 8f 6a 94 8b c5 04 39 04 b7 0e 0c bd 6b b4 bf 7f 32 13 90 b9 4a 03 c1 d3 56 c2 11 22 34 32 80 d6 11 5c 1d 21 bd 37 63 88 b5 f7 23 fb 4c 22 df e6 cd 43 75 a0 5a 07 47 64 44 d5 81 99 85 00 7e 34 02 1d 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 16 a2 e0 b8 f0 3e 13 dd 29 45 5c 5c 2a 3d 02 01 01 a1 3c 03 3a 00 04 be b6 80 3e 74 d5 02 35 32 1b e4 ec 9e fc 71 ad 96 ff 2f 00 cd 21 e1 45 84 70 da 6e 9d 98 35 ad 2d 57 5a 49 08 70 8c 5f c0 01 f2 95 67 7a 07 a0 c2 fe 16 42 2d e3 d0 7c W/mars::comm( 2182): [platform_comm.cc, getCurSIMInfo, 303]:getCurSIMInfo error  return  null D/[LogD]( 2182): receive kv logid:11108, isImportant:  false ,isReportNow:  false D/[LogD]( 2182): receive group id size:3, isImportant: false D/[LogD]( 2182): receive kv logid:11110, isImportant:  false ,isReportNow:  false D/[LogI]( 2084): summerauth ComputerKeyWithAllStr ret:0, agreedECDHKey len: 16, values: 8c 1c 1a d8 a2 0b c4 41 0f a1 27 74 97 2c c9 b9 D/[LogD]( 2084): summerauth aesDecrypt sessionKey len:32, value: 9d d4 f8 c6 65 fe 03 ab 1b f5 03 ca 06 4d eb 0a a9 b0 05 38 3f 0f d4 79 c7 1a 2e 63 72 65 77 1e, session len:16, value: 55 6b 7a 52 79 24 55 57 79 56 4b 4c 4f 6d 45 6e D/[LogD]( 2084): summerauth decode session key succ session: 55 6b 7a 52 79 24 55 57 79 56 4b 4c 4f 6d 45 6e

        最后一行log中的 session就是除登录包外的aes解密key.

        根据关键词"summerauth decode session key succ session"定位代码片段:

        从java代码中可以看出,最终打印出的session是用MMProtocalJni.aesDecrypt做aes解密获得的,解密key是MMProtocalJni.computerKeyWithAllStr返回的,结合log可以看出 computerKeyWithAllStr的参数有svrPubKey,prikey.从函数返回值agreedECDHKey的命名可以看出这是ECDH密钥交换算法,在log中搜索 svrPubKey和 prikey二进制数据第一次出现的位置, svrPubKey在登陆封包返回的解密数据中, prikey出现在:

1

D/[chao-LogD]( 2084): summerecdh nid:713 ret:0, pub len: 57, pri len:328, pub: 04 be b6 80 3e 74 d5 02 35 32 1b e4 ec 9e fc 71 ad 96 ff 2f 00 cd 21 e1 45 84 70 da 6e 9d 98 35 ad 2d 57 5a 49 08 70 8c 5f c0 01 f2 95 67 7a 07 a0 c2 fe 16 42 2d e3 d0 7c, pri: 30 82 01 44 02 01 01 04 1c 2e b1 e1 70 b0 c0 9f 3a a8 f3 8d 15 1e 50 30 80 b1 ed 93 be 03 e9 50 c9 f8 8a 80 7d a0 81 e2 30 81 df 02 01 01 30 28 06 07 2a 86 48 ce 3d 01 01 02 1d 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 01 30 53 04 1c ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff fe 04 1c b4 05 0a 85 0c 04 b3 ab f5 41 32 56 50 44 b0 b7 d7 bf d8 ba 27 0b 39 43 23 55 ff b4 03 15 00 bd 71 34 47 99 d5 c7 fc dc 45 b5 9f a3 b9 ab 8f 6a 94 8b c5 04 39 04 b7 0e 0c bd 6b b4 bf 7f 32 13 90 b9 4a 03 c1 d3 56 c2 11 22 34 32 80 d6 11 5c 1d 21 bd 37 63 88 b5 f7 23 fb 4c 22 df e6 cd 43 75 a0 5a 07 47 64 44 d5 81 99 85 00 7e 34 02 1d 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 16 a2 e0 b8 f0 3e 13 dd 29 45 5c 5c 2a 3d 02 01 01 a1 3c 03 3a 00 04 be b6 80 3e 74 d5 02 35 32 1b e4 ec 9e fc 71 ad 96 ff 2f 00 cd 21 e1 45 84 70 da 6e 9d 98 35 ad 2d 57 5a 49 08 70 8c 5f c0 01 f2 95 67 7a 07 a0 c2 fe 16 42 2d e3 d0 7c

        根据log tag "summerecdh"定位代码:

        从java代码中可以看出 prikey是 libMMProtocalJni.so 库的jni函数generateECKey返回的.

        学习mars库时恰巧发现ECDH相关的这几个jni函数都是开源的:

        生成ECC密钥对的函数在ecdh_util.cpp中:

        计算共享密钥的函数在ecdh_crypt.c中:

        ECC参数nid在上面log中可以看到为713(即secp224r1).

        上面得到的session只能用于后续通信做aes加解密时的key,由于登录包是第一个封包,此时还未得到session,因此解密登录包的密钥需要单独计算.

        在log中搜索解密登录包的key二进制数据第一次出现的位置,发现在packHybrid的 protobuf 参数中,说明解密登录包的key是发包前本地生成发到服务器的.

        整个登录流程客户端共有2个随机参数:解密登录包的key和ecc密钥对,其余参数账号密码、硬件信息等是固定不变的。因此若每次登陆生成相同的解密key和ecc密钥对,则理论上登录请求数据可以完全相同(假设RSA加密后也生成相同的数据),将此登录包的二进制数据保存并记录与之对应的key和ecc prikey,直接发送即可 免去组包 完成登录;若在代码中动态替换掉进程的key和ecc prikey以及guid,则有可能实现在非授权设备上登录账号.

        通信协议草图如下:

（未完待续......）

（ demo）