xhs协议分析小记（2）

书接上文
根据业务要求，其他字段先放放，主要针对shield字段进行分析。
jadx全文查找，相关信息只有一条

跟进调用信息

继续跟进

发现这里是请求头的内容，但是出现了multiHeaderMap字段，这就感觉不像是我们需要的东西，放弃。
但是，在代码中发现了Intrinsics.checkParameterIsNotNull(obj, "");这个方法，调用量还很庞大，程序的值传递大多会用到此方法，那么，我们可以适用交叉定位来确定我们需要的内容，直接frida-hook此方法，打印处堆栈信息，顺带把他第二个参数也打印看看。


打印处的数据量庞大，直接复制到文本中，配合抓包数据进行交叉定位，搜索关键字段fid，shield等，获得以下信息：


从抓包信息看，fid字段为设备信息相关，暂搁置，先处理sheild信息，查找om.xingin.shield.http.XhsHttpInterceptor.intercept信息，发现native层信息。

该方法构造方法为static，且调用了jni接口，可以视为优先划分内存进行实例化，对应的initialize，destroy均为native方法，包括获取response对象的intercept，也是调用so层，至此，Java层逻辑中断，但是并没有找到system.loadLibrary()这一关键方法，这样我们就无法定位到对应的so库，那么我们如何进行下一步追踪呢？
先试着查找XhsHttpInterceptor实现的接口Interceptor，并没有发现loadLibrary，XhsHttpInterceptor也不存在继承关系，通过继承关系查找的路也断了，那Java层是如何调用到so库的呢？
运用逆向思维，既然顺序追查找不到，那我们就试试反向查找。
hook住system.loadLibrary方法，打印出堆栈信息，这样就可以列出所有Java层加载so库的信息，然后在根据堆栈信息对比，来定位出XhsHttpInterceptor类适用到的so库。

frida启动后，只抓了少量包，就出现了程序闪退的情况。此处记录下闪退前最后调用的so文件：System.loadLibrary("wind")。相关检测hook，so层保护等功能代码可能出自此处。
通过Java端查找调用关系的路算是断了，那么接下来该如何继续着手呢？这里就需要先了解android的so库加载机制，Android的so库加载流程大抵如下图所示

可以看见，Java层的loadLibary是最上层的调用，这一步找不到，我们可以深入到下层逻辑中去寻找，nativeLoad，jvmload相对难以接触，但是dlopen，linker这部分，我们是可以从安卓系统中找出文件分析的，那么接下来就是挑战系统文件的时候了。
至此，Java层分析结束，转而面向android系统文件以及JNI_ONLOAD的so文件分析。
---未完待续---