微信版本：3.9.0.28

下载链接：链接：https://pan.baidu.com/s/1eUR9hoaJ8o_NMRybJ-MYpA?pwd=iofu
提取码：iofu

duilib：链接：https://pan.baidu.com/s/1_cuB7e2bBbIZrKexfmKBag?pwd=qx7x
提取码：qx7x

如造成侵权，请联系作者处理。

微信的白色背景页面实在是对像笔者这样眼睛不太好的用户不太友好，所以就有自己给他改改界面的打算，就改个颜色，应该不会太麻烦，所以就写了这篇文章记录一下过程。受限于笔者水平以及时间问题，这篇文章最终没有实现目的，但是理论上文章中所讲方法是可以实现的，并可以提取大部分微信界面UI布局，并且对其他功能的分析也有帮助。笔者将在文中给出使用frida进行简单内存dump的方式获取xml以及静态解密的方式拿到XML

比较笼统的资料即以上四点，这对我们帮助还是比较多的：

微信团队之前开源过Duilib的源码，但是现在Github上应该是找不到了，笔者这里有一份，出于学习的目的需要请联系笔者。拿到源码后笔者简单看了一下，对比官方原来来说改动不算太大。

因为我们的关注点是微信是从哪里获取XML资源的，所以我们需要大致了解一下Duilib的资源加载方式，微信之前开源的Duilib中有四种资源加载方式：

从磁盘上以及从ZIP中加载资源基本上是不可能的，我们在微信的根目录里没有发现相关信息，保险一点，我们通过火绒剑来监控一下文件操作，防止搞错方向。

我们只关注文件操作，设置好相关过滤后，我们记录微信启动完成的相关信息，搜索关键字“.xml”,”zip”,，没有发现什么有用的信息，但是在我们搜索“Resource”时，我们留意到

微信加载了这两个非常可疑的dll，我们索性用Resource Hacker看看里面有什么

首先WeChatResource.dll里面有一些较为简单的资源以及一个不明所以的奇怪资源，资源类型为WXZ，如下图：

WeUIResource.dll中同样含有此种资源类型，如下图：

其中，在其十六进制流中我们可以看到有PNG格式文件头如下

我们在010Editor中进行简单的提取

可以看到其中确实隐藏着png图片，但是我们没有发现xml的影子，应该是有加密的（不然也不会有这篇文章）

我们留意资源的类型为wxz,尝试在IDA中搜索相关字符串，并查找相关引用，如下图

可以看到加载了这种资源，但是如果从这里分析的话并不优雅，一般资源的加载是在初始化过程中，从这里跟下去不一定能找到解密点。

比较幸运的是我们有源码，我们可以试着从源码中找到一个xml文件明文出现的位置（对xml文件进行解析渲染，一定在某一个时刻会出现xml文件的明文信息），找到明文出现的位置逆向回溯找出密文解密点应该是比正着死磕分析要简单一点。

笔者结合网上对duilib的一些介绍进行了一些简单分析，我们关注点来到函数签名为LRESULT WindowImplBase::OnCreate(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)的函数中，这个函数所属的类被创建窗口的类继承，并且创建窗口时应当调用OnCreate()

可以看到关键的函数行为是，分析当前加载的方式选择合适的加载例程，最终会调用Create(),而GetSkinFile().GetData()是将返回xml的一些信息，在某些情况下，是xml内容本身，这里也是比较好定位，我们可以看到字符串“Duilib”，尝试在IDA中搜索，查找引用，我们来到VA：01C80DC5处，如下图：

​

对比源码，我们很容易确定这就是OnCreate函数内部，而117行对应位置就是Create，我们对其下断，重启微信。

成功断下后跟进，来到VA：1C81B13处，如下图

IDA对这一部分的分析比较模糊，并没有把其视为一个函数，我们可以进行简单的强制函数化，但也没必要fix相关内容，如下图

笔者对其进行了简单的分析，并根据函数行为进行了简单的重命名，这里是OnCreate内部嘛，跟源码进行简单对比，很容易发现并不是，如下

但是我们注意到调用了LoadFromMem，而其内部调用了MultiByteToWideChar,笨点的方法是，我们对这个函数下断，然后触发微信的图形操作，试着找找。

可以看到轻而易举的就断到了我们想要的地方，断下后栈回溯，就找到了比较明显的特征，我们在IDA中转到RVA :1C9F508

对比源码的LoadFromMem：

可以确定这就是LoadFromMem了，对此函数进行简单的重命名。

在LoadFromMem函数头部断下，查看第一个参数（esp+0x4）的值，xml内容已经作为参数传递进来，如下图，说明微信已经完成了对xml内容的解密。请留意xml内容缓冲区的地址。

我们进行回溯，查找第一个参数的值。

来到RVA：01C9D5D6，如下图

可以看到笔者已经根据分析进行了部分注解，我们观察第一个参数*((LPCCH *)v7 + 2048)(thiscall调用约定，第一个参数为对象本身)，v7作为stream2xmlbuf的返回值，对于这些重命名的由来，我们可以去源码中查看LoadFromMem的相关调用函数，对比可以确定这个函数的相关信息。如下图：

我们观察stream2xmlbuf的行为，在调用他的地方下断

可以看到对应的xml文件名作为参数传入

对应的xml内容作为返回值被传出，我们可以猜测，这个函数完成了对xml内容的读取以及解密，我们跟进这个函数。

需要留意的是stream2xmlbuf的返回值同样为5CC98D60，这与我们之前观察到的xml缓冲区的地址相同，也就是说，duilib极有可能申请了一个公共缓冲区来临时存储xml的内容，那么我们的突破点就找到了，既然用了公共缓冲区，待xml内容解密完成后势必会对这个缓冲区进行写的操作，我们可以对着个缓冲区下硬件写入断点（dbg的内存访问断点是针对整个内存页的，通常情况下这是我们不需要的）。如下图，成功在写入的地方断下，RVA：1F7D053

我们在IDA中同步。

我们在源码中搜索字符串：invalid literal/length code，定位到inflate_codes,其实这里已经比较明显了，inflate是zlib库唯一支持的压缩和解压缩算法，我们在这个函数头部下断，进行回溯。来到RVA：1F76282，如下图：

同样有比较有特征的字符串，同样在源码中搜索。推荐关键字“incorrect header check”如下图

现在看来我们在inflate内部，算法我们不需要分析，我们在inflate函数头部下断，RVA：01F75340，非常容易的断下。

我们需要留意inflate函数签名的结构体z_streamp,其结构如下：

比较关键的字段是

我们在inflate的函数头断下，对应的我们查看第一个参数，即z_streamp结构，如下：

可以看到基本上对应了z_streamp的结构，其中有我们非常眼熟的缓冲区5CC98D60，对应的就是next_out,而opaque指向的是WeChatresource中的数据，我们跟进

复制相应的十六进制流，在WeChatResource.dll中搜索，成功搜索到了对应的十六进制内容，如下图

可见，opaque保存的的是资源文件中的内容。

不要忘了字段next_in,按照解释，其应该指向的是将要解压的内容的缓冲区，我们跟进，如下图

理论上将，将要解压的内容应该与opaque里的内容一致，但这里却不同。经过笔者猜测，这里应该是又一层加密，原因是，当微信加载PNG类型图片时，opaque内容与next_in内容一致，或者在wechatresource.dll中搜索78 9C后，可以发现很多搜索项，如下图：

可以推测，部分资源的部分内容没有被加密。

那么我们怎么找到解密点呢？

一种比较朴素的想法是，在没进行解压之前对密文下访问断点，进行解密时必然要访问这篇内存

存在的问题是我们需要找到一个合适的位置，在没进行解压之前下断点，根据之前的分析我们似乎不能很好的确定这个位置，因为我们似乎除了在inflate例程中再没有发现密文出现的地方

一种或许可行但不太优雅的方法是记录一下加载某个页面时的密文缓冲区，在wechatresources中定位，然后在加载资源的地方（LoadResource）找到资源缓冲区，继而定位到加载那个指定界面时对应的密文缓冲区，对其下硬件访问断点，再次触发其页面加载，理论上可以断在解密的地方。

这里笔者使用的是一种非常笨拙的方法，赌解密的地方离解压的地方不远，即回溯，根据源码定位z_streamp结构的组装过程，根据内存访问关系找到解密资源的点，这个过程相当笨拙且没什么技术含量，所以这里笔者不再赘述

最后，笔者定位到RVA：01E103F1，如下图：

根据函数名读者可以猜到，密文用的是异或加密，我们跟进这个函数

根据伪代码分析，这段代码主要是对a1所指向的内存区域进行加密。下面是一些推测：

变量v4是一个密文缓冲区，初始值为a1+32，即指向a1之后的第32个字节的地址。
加密算法中使用了SSE指令集中的_XMMINTRIN_H头文件中的_mm_xor_si128()函数进行异或操作，xmmword_2B01A80是一个128位的常量值，可能是加密算法中使用的密钥。
在主循环中，每次处理64字节的数据，并且对这64字节中的每个128位（即16字节）进行加密。加密的方式是将128位的数据与xmmword_2B01A80进行异或操作，并将结果存储回内存中。
当a2的大小小于64字节时，程序会跳到LABEL_9处，进入另一个加密算法中，该算法对剩下的不足64字节的数据进行单字节异或加密。
函数的返回值为result，表示加密完成的数据的字节数。
综上所述，这段代码可能是一种基于SSE指令集的异或加密算法，密钥为xmmword_2B01A80

在这里秘钥为0x63，即字符‘c’,这个秘钥在不同wxid下是否不同笔者没有测试。

下面我们测试一下结论是否正确

我们在资源中赋值一个加密chunk，chunk以1B FF作为文件头，转储到一个名为“dump.xml”的文件中，然后尝试解密解压，并将其写入“decode.txt”中下面给出不成熟的脚本：

可以看到我们拿到了xml的内容，证实我们之前的分析时正确的。

至此，静态解密得到xml的目的已经实现，出于笔者水平原因，并不能拿到xml对应的文件名字。有兴趣的读者可以继续向下分析，如果想要拿到xml的名字，比较简单的方法是内存dump。下面笔者将使用frida来HOOK相关函数，缺点也是比较明显，我们通过HOOK很那实现完全的dump出所有的xml，因为解密渲染例程只有在被调用时我们才能拿到xml。

这里，我们选择的HOOK点为调用LoadFromMem的点上方，对应RVA：1C9D5C3，这里有xml缓冲区，缓冲区+0x2004指明了其大小，并有xml对应的名字，如下图

给出一下frida脚本（需要frida环境）：

调用命令：

效果如下：

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！