Frida分析OLLVM字符串混淆教学文档<\/h1>

前言<\/h2>
本教程将详细介绍如何使用Frida分析经过OLLVM字符串混淆处理的Android原生库(so文件)。我们将分析三个不同版本的APK，它们具有相同的Java层逻辑，但SO库采用了不同的OLLVM字符串混淆技术。<\/p>

准备工作<\/h2>

示例APK下载<\/strong>：<\/p>

链接: https:\/\/pan.baidu.com\/s\/1zTCqXvG9PHxOQAqfoJS-1g<\/a><\/li>
提取码: ttmm<\/li> <\/ul>
工具准备<\/strong>：<\/p>

Frida<\/li>
IDA Pro或其他反编译工具<\/li>
Android设备或模拟器<\/li> <\/ul>
Java层分析<\/h2>
三个APK的Java层逻辑一致，主要功能：<\/p>

初始界面显示欢迎字符串（通过stringFromJNI<\/code>函数生成）<\/li>
点击sign1按钮会更新显示类似hash的字符串（通过sign1<\/code>函数生成）<\/li> <\/ol> 这两个函数都是JNI函数，因此我们需要转向SO层分析。<\/p> SO层分析<\/h2> 版本0分析（hellojni_2.0.0.apk）<\/h3> 静态注册与动态注册<\/h4> stringFromJNI<\/code>：静态注册，可在导出表中直接搜索到<\/li> sign1<\/code>：动态注册，导出表中无法直接搜索到<\/li> <\/ul> stringFromJNI函数分析<\/h4> 函数直接将stru_37010<\/code>指向的内容转换为UTF-8编码字符串返回给Java层<\/li> stru_37010<\/code>以64位双字对形式定义，初始值可能是返回字符串的原始数据<\/li> 众多byte_<\/code>开头的变量（每个占1字节）参与数据处理<\/li> 通过DATA XREF<\/code>注释可知这些数据在多处被引用，参与如datadiv_decode8846988481537047047<\/code>等函数的复杂处理流程<\/li> <\/ol> 字符串解密特征<\/h4> 导出表中可搜索到datadiv_decode<\/code>函数<\/li> 解密函数对字符串的每一位进行异或操作<\/li> 手动还原较麻烦，可使用Frida从内存中dump解码后的字符串<\/li> <\/ol> 解密函数加载时机<\/h4> 使用IDA快捷键Ctrl+S<\/code>跳转到.init_array<\/code>段<\/li> 发现三个decode函数都在.init_array<\/code>中加载<\/li> 因此可以直接hook 37010<\/code>地址获取解密后的字符串<\/li> <\/ol> sign1函数分析<\/h4> 最终结果存储在v19中返回<\/li> 进入37040<\/code>同样可以看到datadiv_decode<\/code>函数<\/li> 同样可以dump解密后的字符串<\/li> <\/ol> 版本0特征总结<\/h4> 导出表中出现.datadiv_decode<\/code>是OLLVM字符串混淆的特征<\/li> 解密发生在初始化时（.init_array<\/code>段）<\/li> <\/ul> 版本1分析（hellojni_2.0.1.apk）<\/h3> 主要区别<\/h4> 从stringFromJNI<\/code>里的37010<\/code>进入未发现datadiv_decode<\/code>函数<\/li> 导出表中也没有datadiv_decode<\/code><\/li> 发现类似std__string___4921590060622252445<\/code>的交叉引用<\/li> <\/ol> 解密函数分析<\/h4> std__string___4921590060622252445<\/code>实际上就是之前的datadiv_decode<\/code>函数<\/li> 加载时机仍在.init_array<\/code>中<\/li> 可以直接打印字符串获取明文<\/li> <\/ol> 版本1特征总结<\/h4> 无法在导出表中看到OLLVM字符串混淆的明显特征<\/li> 解密函数名称变化，但功能相同<\/li> 解密仍在.init_array<\/code>中加载<\/li> 这种情况在64位架构中更常见<\/li> <\/ol> 版本2分析（hellojni_2.0.2.apk）<\/h3> 主要变化<\/h4> .init_array<\/code>中没有解密函数的踪迹<\/li> 解密时机改为运行时<\/li> <\/ol> stringFromJNI函数分析<\/h4> 将3E160<\/code>数组转换为Java字符串返回<\/li> 解密逻辑：byte_22E80[i + 21 + -18 * (i \/ 0x12)] ^ byte_22E80[i + 39]<\/code><\/li> byte_22E80<\/code>是映射表<\/li> 打印0x3E160<\/code>可获取欢迎字符串<\/li> <\/ol> sign1函数分析<\/h4> 解密代码不在函数内部<\/li> 需要在JNI_OnLoad<\/code>中查找解密逻辑<\/li> 发现映射表出现在JNI_OnLoad<\/code>中<\/li> 解密发生在JNI_OnLoad<\/code>中<\/li> <\/ol> 版本2特征总结<\/h4> 解密时机改为运行时（JNI_OnLoad<\/code>）<\/li> 没有明显的.datadiv_decode<\/code>特征<\/li> 需要分析运行时解密逻辑<\/li> <\/ol> Frida Hook脚本示例<\/h2> 版本0和1的Hook脚本<\/h3> \/\/ Hook .init_array中的解密函数 <\/span><\/span><\/span><\/span>Interceptor<\/span>.attach<\/span>(Module<\/span>.findBaseAddress<\/span>('libhello-jni.so'<\/span>).add<\/span>(0x37010<\/span>), { <\/span><\/span> onLeave<\/span>:<\/span> function<\/span>(retval<\/span>) { <\/span><\/span> console<\/span>.log<\/span>("Decrypted string: "<\/span> +<\/span> Memory<\/span>.readUtf8String<\/span>(retval<\/span>)); <\/span><\/span> } <\/span><\/span>}); <\/span><\/span> <\/span><\/span>\/\/ Hook sign1函数的解密结果 <\/span><\/span><\/span><\/span>Interceptor<\/span>.attach<\/span>(Module<\/span>.findBaseAddress<\/span>('libhello-jni.so'<\/span>).add<\/span>(0x37040<\/span>), { <\/span><\/span> onLeave<\/span>:<\/span> function<\/span>(retval<\/span>) { <\/span><\/span> console<\/span>.log<\/span>("Sign1 result: "<\/span> +<\/span> Memory<\/span>.readUtf8String<\/span>(retval<\/span>)); <\/span><\/span> } <\/span><\/span>}); <\/span><\/span><\/code><\/pre>版本2的Hook脚本<\/h3> \/\/ Hook JNI_OnLoad中的解密过程 <\/span><\/span><\/span><\/span>Interceptor<\/span>.attach<\/span>(Module<\/span>.findExportByName<\/span>('libhello-jni.so'<\/span>, 'JNI_OnLoad'<\/span>), { <\/span><\/span> onLeave<\/span>:<\/span> function<\/span>(retval<\/span>) { <\/span><\/span> var<\/span> decryptedStr<\/span> =<\/span> Memory<\/span>.readUtf8String<\/span>(Module<\/span>.findBaseAddress<\/span>('libhello-jni.so'<\/span>).add<\/span>(0x3E160<\/span>)); <\/span><\/span> console<\/span>.log<\/span>("Decrypted welcome string: "<\/span> +<\/span> decryptedStr<\/span>); <\/span><\/span> } <\/span><\/span>}); <\/span><\/span> <\/span><\/span>\/\/ Hook sign1函数的解密结果 <\/span><\/span><\/span><\/span>Interceptor<\/span>.attach<\/span>(Module<\/span>.findBaseAddress<\/span>('libhello-jni.so'<\/span>).add<\/span>(0x3E160<\/span>), { <\/span><\/span> onLeave<\/span>:<\/span> function<\/span>(retval<\/span>) { <\/span><\/span> console<\/span>.log<\/span>("Sign1 result: "<\/span> +<\/span> Memory<\/span>.readUtf8String<\/span>(retval<\/span>)); <\/span><\/span> } <\/span><\/span>}); <\/span><\/span><\/code><\/pre>总结与识别特征<\/h2> OLLVM字符串混淆的识别特征<\/h3> 版本0<\/strong>：<\/p> 导出表中可见.datadiv_decode<\/code>函数<\/li> 解密发生在.init_array<\/code>段<\/li> 字符串以加密形式存储在数据段<\/li> <\/ul> <\/li> 版本1<\/strong>：<\/p> 导出表中无.datadiv_decode<\/code>函数<\/li> 解密函数名称变化（如std__string_<\/code>前缀）<\/li> 解密仍在.init_array<\/code>中<\/li> 64位架构中更常见<\/li> <\/ul> <\/li> 版本2<\/strong>：<\/p> 无.init_array<\/code>中的解密函数<\/li> 解密逻辑在JNI_OnLoad<\/code>或运行时<\/li> 需要分析运行时解密算法<\/li> <\/ul> <\/li> <\/ol> 分析方法总结<\/h3> 首先确定解密时机（.init_array<\/code>或JNI_OnLoad<\/code>）<\/li> 查找解密函数或解密逻辑<\/li> 使用Frida在内存中dump解密后的字符串<\/li> 对于运行时解密，需要分析解密算法<\/li> <\/ol> 应对策略<\/h3> 对于初始化时解密：<\/p> Hook .init_array<\/code>中的解密函数<\/li> 或直接Hook加密字符串的内存地址<\/li> <\/ul> <\/li> 对于运行时解密：<\/p> 分析JNI_OnLoad<\/code>函数<\/li> 跟踪字符串使用过程，找到解密点<\/li> Hook解密后的内存位置<\/li> <\/ul> <\/li> <\/ol> 通过本教程，您应该能够掌握使用Frida分析不同OLLVM字符串混淆技术的方法，并能够根据不同的混淆特征选择合适的分析策略。<\/p>

Frida分析OLLVM字符串混淆教学文档<\/h1>

前言<\/h2> 本教程将详细介绍如何使用Frida分析经过OLLVM字符串混淆处理的Android原生库(so文件)。我们将分析三个不同版本的APK，它们具有相同的Java层逻辑，但SO库采用了不同的OLLVM字符串混淆技术。<\/p>

SO层分析<\/h2>

版本0分析（hellojni_2.0.0.apk）<\/h3>

版本1分析（hellojni_2.0.1.apk）<\/h3>

版本2分析（hellojni_2.0.2.apk）<\/h3>

Frida Hook脚本示例<\/h2>

总结与识别特征<\/h2>

前言<\/h2>
本教程将详细介绍如何使用Frida分析经过OLLVM字符串混淆处理的Android原生库(so文件)。我们将分析三个不同版本的APK，它们具有相同的Java层逻辑，但SO库采用了不同的OLLVM字符串混淆技术。<\/p>