本次逆向分析用到的工具：adb、ida、010Editor、ddms。

这次主要对某右的libnet_crypto.so分析,主要工作是分析ollvm混淆的字符串被处理加密。

先检测一下设备是否正常

adb devices

然后解压apk文件，提取出lib目录下的libnet_crypto.so文件

armeabi-v7a对应的是32位的ARM设备，调试使用IDA，不要用IDA64

so文件挺大的，编译需要等待一会，看一下字符串，基本都是混淆加密的

接下来，分析一下JNI_onload

先看一下JNI_onload流程，不是很复杂

在F5或者空格查看伪代码，代码没什么混淆

修改参数,静态分析方法

右键选择set lvar type或y修改参数类型

)

在下面GetEnv处 选择Force call type识别一下类型

v4是JNIenv * 也修改一下

)

下面 FindClass和Registernatives也一下，识别一下类型

点进去查看，没有native方法的对应关系，第一个参数是java层native的方法名称，第二个参数是java层native的签名信息，第三个参数才是对应的c\c++的参数

)

根据上面静态分析遇到的问题，接下来的想法是恢复被ollvm加密混淆的字符串信息

打开010Editor，将so文件和elf头文件拖进去

主要分析数据区域

第一个是程序头，不是关注的，第二个和第三个是关注重点，第二个是只读的，那么根据so文件对字符串进行加解密可以判断ida编译出的混淆字符串属于第三个区域

这部分区域是被加密处理的

)

那对于这个so的还原，就需要dump出解密后的数据，将数据复制到原加密数据位置，完成对字符串解密。

dump的位置可能在JNI_onload 、 init 、 init_aray

ida 附加一下进程，看一下so文件是否被加载

先进行一下android端的配置

找到ida的android_server

)

将ida的android_server发送到android

)

执行android_server

转发端口

)

附加端口，这里先要启动apk

Debugger-> Attach -> Remote ARmlinux\Android debugger

)

在Modules发现so文件已经被加载进去了

)

那么直接搜索dump内存中解密的字符串数据

ctrl+s搜 crypto

)

File->script commond

然后输入命令，替换初始地址和结束地址

)

使用010Editor打开，里面的字符串都是解密的

)

这是加密的数据，可以对比一下，前六行基本是一致的都是地址。最后一行都是00，这里是相对地址
)

这个是解密的数据，前六行都是04 这里是绝对地址。

)

复制解密后的数据，到这里为止

)

在鼠标放到如图位置，ctrl+v搞定

)

看一下修复后的so文件

看一下Findclass,之前混淆的现在已经解密了
)

同样RegisterNatives也是，之前不知道方法的类型和参数，现在都已经解密出来了
)

这种方法仅适用在内存中解密状态的情况，如果是在使用时解密，解密后在清除，需要使用动态调试。

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