分析某乎 是因为有一老乡,刚学unidbg遇到某乎一直没办法正常运行、报错。问了我一句，我出于好奇于是想着帮他看看是哪里出的问题。

多次抓包发现每次这个x-zse-96一直是变化的 于是去代码里找找看看具体在哪里。

很好，找了个寂寞，果然没那么简单。看了下网络框架用的okhttp，那么请求头正常来说是放在拦截器中添加的,于是搜索了一下。

找到个感觉有点像的某乎包名下的net包，正常没有混淆的网络请求包基本上也采用这种命名方式，而且也有使用拦截器，点进去看看。最终在这个net包下找到这个类名为j

这个方法为添加请求头方法，怎么定位到的呢？这里的把请求头key做了一个加密。通过frida 去hook 这个方法拿到了x-zse-96 对应的加密串为G51CEEF09BA7DF27F  frida hook结果如下:

所以可以定位到了这个位置就是添加请求头的位置 从这里开始找该key 对应的value 是如何生成的。

value的值为 1.0_S85l858ic01VjwtX/xa0+BWZPtg5JRUKVGz3uz0XgD+JXTufPwrDK4sClacJhLk3 由两部分组成，

G38CD8525  代表的值为1.0_  

后面这串字符串是上面这个encrypt方法返回,具体分析这个方法。

具体加密为这个c类 的a 方法  

参数1：待加密的数组

参数2：一串固定的字符串 通过H.d()方法解密后得到  Aes 的key值

541a3a5896fbefd351917c8251328a236a7efbf27d0fad8283ef59ef07aa386dbb2b1fcbba167135d575877ba0205a02f0aac2d31957bc7f028ed5888d4bbe69ed6768efc15ab703dc0f406b301845a0a64cf3c427c82870053bd7ba6721649c3a9aca8c3c31710a6be5ce71e4686842732d9314d6898cc3fdca075db46d1ccf3a7f9b20615f4a303c5235bd02c5cdc791eb123b9d9f7e72e954de3bcbf7d314064a1eced78d13679d040dd4080640d18c37bbde

参数3：固定的byte数组  16位 看着像Aes 的IV值

接下来开始分析 b.b() 的入参1  也就是CryptoTool.laesEncryptByteArr() 方法的返回值

这里可以到b.b()方法 嵌套了几层

1.首先先b.a()方法计算CryptoTool.laesEncryptByteArr() 入参1

2.CryptoTool.laesEncryptByteArr()返回值 又作为b.b()方法的入参1

这里其实看看b.a() 、b.b() 方法都可以看到完整的java 实现代码 这里就不分析了,主要看CryptoTool.laesEncryptByteArr()这个方法 因为是 native方法 所以这里直接看下frida hook的结果

把上面这三个方法都hook 一遍看看结果吧 frida  hook 代码也送上

因为项目需要使用到unidbg 黑盒调用,所以这里我们需要使用unidbg来调用 so 的 CryptoTool.laesEncryptByteArr()这个方法返回值给上面截图的b.b()的入参 1进行比对 也就是返回值 必须为下面的值才是正确的

ida 打开libbangcle_crypto_tool.so 找到 laesEncryptByteArr() 很明显不是动态注册的,双击然后到混编区域 ，全是这种%1 加密了 。如下图：

上大杀器，用yang神的frida-dump工具重新导入修复 后 的 so包

可以正常看了，F5一波看伪代码

接下来unidbg 开始调用so包 补环境过程就不说了 很简单就是补一个包名就好 具体包名在清单文件中可以找到

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课