上文通过fiddler抓到了点赞的包，并通过对比不同包的差异确定了需要逆向4个关键字段的算法：X-Ladon、X-Gorgon、X-Tyhon、X-Argus； 本文尝试逆向分析这些字段的实现算法！
逆向都是从数据开始的！于是满怀期待把这4个字符串放到android killer（jdax-gui逆向这种上百兆app时，用全局搜索非常耗内存，我16G的内存都不够用），结果无一例外都找不到！这不是应征了中国人的那句古话：此地无银三百两么！既然这些字段直接搜不到，那么就有这么及种可能：
- 字段本身被分成了好些段，比如X-Ladon被分成了X- La don等段，用完整的字符串搜不到；
- 字段本身被加密了，使用的时候才动态解密，导致静态搜索查不到
- dex文件被加密或加壳导致静态搜索查不到
- X-Ladon是在so层生成的，所以java层静态找不到！在kali下用strings命令查找的结果不乐观，如下：啥都没有
换成X-试试：这次找到了一大堆，但是挨个人肉搜查后发现还是没有我们想要的这4个字段，那么只剩一种可能了：这4个字段都被加密了！
关键字段直接找不到，只能“围魏救赵”，从非关键字段入口；GET头有很多字段，GET的url里面不也有很多字段么？其实这些字段都是为了从客户端给服务端传递信息，没有本质区别的！头的字段不好找，就从url下手呗！用url的“/aweme/v1/commit/item/digg/”下手，终于找到了（而且还只有2处，非常利于查找）：
smali代码看着不方便，这里继续换成jadx试试。代码如下：很明显用了retrofit框架！
从这里也看不出个啥！那就用obejction hook试试呗：结果没任何反应，说明根本没调用!
截至目前，静态分析能用的手段都用了，由于java层混淆地厉害，不太好分析这些类、方法和变量的功能；lib下面的so文件有113个，我也没时间精力挨个拖到IDA去分析，只剩一条路了：内存搜索和dump！
先用objection，查找某个字段，有结果：
用frida查看：意外发现了另一个关键的字符串；
在这个内存地址下断点，一旦有代码读写这个内存地址立即断下来，用来定位关键的代码；andrdoi端该怎么操作了？先试试GameGardiance！尝试后发现这里只能查找字符串地址，然后根据maps映射查看，发现这些地址都是通过malloc函数在栈上分配的，根本不再代码段（这又是一句正确的废话），无法定位到具体的so！
X-Ladon也是：都是通过malloc在栈上分配的地址，无法定位到so文件！
换成最熟悉的CE：X-Ladon关键字段存放的位置很多，但是值得关注的不超过5个，如下：
本以为胜利就在眼前，想直接通过“find out what access this address”定位到关键代码，结果直接报错！what the fxxk.............
刚开始不知道为啥，后来查了很多资料，发现是hw手机即使root后，默认也没开启硬件断点，所以用gdb调试也没法下硬件断点：
先根据ce的地址找X-Ladon字段，结果在这个字段的附近居然同时出现了其他3个字段，真是得来全不费功夫啊）！
耐心点：每个字段都下个读写断点：
有可能是这些通过malloc分配的地址只用1次（尝试过用pixel，毕竟是Google的亲儿子，root后默认是开启了硬件断点的。用CE的“find out what access this address”还是没断下来；不管我更换多少视频、点赞等操作，通过CE查看内存数据一直都没变，说明这块内存只被用了一次就没再用了; 后续从sub_6221c函数分析得知: 这3个字段每次生成前都用malloc分配内存，所以这些内存只用一次，用内存断点的方式自然是找不到读写的代码），用完就回收，所以导致断不下来！这种方式每次用的时候都要申请内存，效率较低，但也更加安全，可以有效防止内存断点的追踪！还有一种可能：这些加密字段是针对当时发送的数据做加密的，因为每次发送的数据包不同，所以每个数据包加密的密文只用1次，所以用这种方式是无效的！好吧，思路到这里又断了！
换个思路：从/proc/pid/maps这里看到，这些地址内存都是通过libc的malloc函数分配的内存，要是在这里下断点，然后在栈上回溯，是不是就能追踪到调用者了？
frida有个trace的功能（ida也有，但是调试时经常弹窗爆各种异常，需要手动选择和点击，trace的效率台低，已经放弃），首次运行命令后会生成一个js脚本，然后自己在js脚本添加需要打印的信息，我改后的js脚本如下：
这里打印调用堆栈；由于被调用很多次，我就不把所有的日子都贴出来了，这里选几个比较关键的：
从日志来看，调用libc.so文件中malloc函数的so文件不多，有libutils.so、libinput.so、libc++.so、libbinder.so、libstagefright.so、libui.so、libgui.so、libsqlite.so，这些so的数量和原始110多个so比，范围已经小了很多；并且也能定位到so的哪一行代码层层调用了malloc函数，后续先从内存dump这些so，从这里开始继续分析！
============================分割线==============================
个人猜测是给公司内部所有产品使用的通用代码）；这些基础框架代码包含了retrofit代码，通过http、network等关键自研，hook了 “com.bytedance.frameworks.baselib.network.http.util.UrlUtils.encode” 这个函数；又根据调用栈找到了com.ss.android.ugc.aweme.bp.d$3$1.run，这个是栈底的函数了，说明就是从这里开始运行的；并且从命名看，这明显是x音的函数，所以需要重点跟踪！从java层的源码看，这个是Thread线程，当试图搜索这个函数的start方法时，但是根本找不到（如下）：猜测start方法可能被加壳隐藏了，后续还要好好找找在哪藏着的！
本文地址：http://mdekt.bhha.com.cn/quote/168.html 康宝晨资讯 http://mdekt.bhha.com.cn/ , 查看更多