这次案例使用的是最新某马拉雅，直接豌豆荚即可

​ 首先就是进行抓包了，下面是抓到的数据包

​ 接下来需要定位到登录函数调用的位置，可以通过关键字段的搜索、或者是hook函数打印调用堆栈。这里我直接hook了HashMap来打印堆栈，找到登录点：

定位请求体组装位置：

这里重定义了两个a函数，除了从调用链上判断使用的是第一个a函数外，还可以通过frida的overload来判断使用的是哪个函数。

这里就是signature进行拼接的位置，需要通过LoginRequest.b进行跟进，最后发现调用的是LoginEncryptUtil的a当中的WTWEctUfLf函数。

​ 通过函数声明可以看到这是个native函数，属于liblogin_encrypt.so这个库，接下来就需要对这个库当中的这个native函数进行分析了。

进入so当中的WTWEctUfLf通过CFG可以查看到这个函数是被控制流平坦化了（。

​ 这里想试试用Unidbg模拟执行一下看看，能不能找到一些线索，这里传入的参数需要注意一下，通过jadx的反编译可以看到传入了3个参数：

分别是上下文context，布尔值z以及拼接后的参数sb.toString。这里已经知道了参数一和参数三的形式了，但是参数二是true还是false依旧不清楚。那么这里可以直接对这个a方法进行hook，看看传入的是什么，hook脚本如下：

最后打印的是false：

那么此时就知道了参数二。此外为了确保模拟执行WTWEctUfLf的逻辑没有错误，这里将传入的sb.toString()以及返回值都hook出来，用作模拟执行的校验，使用Frida框架进行hook：

​ 最终得到的数据如下：

模拟执行时主动调用就可以直接传入这个明文作为字符串参数，并在结束后打印返回值。

​ 这里Unidbg代码篇幅比较长就不放在文章当中了。有需要的话可以到附件进行下载。总的来说就是补完环境之后，能够通过JNI日志看到大部分信息了。下面展示一些JNI的日志：

​ 首先就是获取包名，然后将输入的字符串转成字符指针方便后续调用

接着就是newStringUTF，通过这个可以发现，这里的字符串后面拼接了一串新的东西：

​ 接着就是使用toUpperCase将参数转成大写。

接着就是获取了SHA-1哈希算法的实例，接着调用update，这里传入的参数就是拼接上特定字符串的新参数，最后调用digest进行哈希运算。然后toHexString之后通过StringBuilder.append进行拼接，最后拼接的就是明文字符串

​ 最后可以观察到特征串和我们hook到的一模一样。说明这个模拟执行流程正确了。

​ 其实通过这个Unidbg已经几乎把这个signature生成方式给看得差不多了，首先就是拼接一串特定字符串，接着转大写，然后进行SHA-1。从而完成signature参数的生成。这个加密函数貌似并没有自己实现加密逻辑，全都是通过JNI来调用java层的函数以及加密标准库的。

​ 那么Unidbg分析完了，接下来可以试试IDA来分析这个ollvm

​ 进入大致浏览了一下，好像只有1千多行，试着分析一下。进入函数后，开始先通过TLS读取了一个值，然后就开始获取包名了（分析之后得出）。

来看看这个get_package_name函数是怎么样的：

可以看到这个函数也被ollvm混淆了一下，不过代码量不多，这里直接从头分析一下：

​ 首先进来就是给v12进行赋值，用作下面状态机的一个流程跳转。在ollvm中很多这种永真或者永假的条件，此时可以进行化简，实在不会的丢给ai化简。这里可以看到实际上执行的是：$a\times (a-)$a×(a−1) 那么起始就是偶数乘奇数，结果就是偶数，最低位为0，接着取反，此时最低位为1，或上0xFFFFFFFE，运算得出0xFFFFFFFF那么这个判断条件就为真，所以v12 = 1。

​ 所以这里事实上就只是对x_149的最低位做判断。继续往下看，并记录状态：

​ 这里点击x_149，然后给这个x_149一个值（这里我使用的是IDA Python来进行赋值）：

接着将.bss段的可写权限(W)关掉，这样就能够利用IDA引擎自动将这些虚假控制流去掉了。

x_150处理手法也差不多，效果如下：

接着回到函数继续分析。另外两个先不管，如果用到了再进行分析。

​ 接着进入while(1)循环：

由于此时的v3 = 0xB5E7D523不满足while和if的条件，直接走到了if-else这个位置，经过化简之后这里的条件判断其实就是：if(v12 || v13)。

此时的v12 = 1，所以这里v3被赋值成0xEA4F3F0B，接着就重新进行while循环，此时v3满足了while ( v3 > (int)0xCF812BC6 )，则进入循环，此时会进入到这个else分支：

​ 这里通过调用JNI的函数来获取context，接着获取pkgname，如果获取成功的话v15 = 0。这里调用函数用到的字符串都是加密的，这里先分析完整个大体流程之后再讲如何解决这个问题。

​ 执行完成这个else分支之后v3 = 0xB19E5A69，接着就会因为不满足循环条件而跳出循环。接着就是这里的if，继续break：

接着给v3继续赋值:

接着到下一个while循环：

先走else块，然后v3 = -8285439，接着就是if块，通过CallObjectMethod调用getPackageName获取pkgName存放到v16。然后v3被设置成1958226928，接着往下：

给将v16也就是pkgName赋值给v11，然后调整状态码，进入下一轮循环后直接就从if ( v3 != 1958226928 )处返回pkgName了。所以这个函数其实原本的逻辑就是获取pkgName后返回，去掉混淆之后就是这样的：

​ 接下来就来解决一下字符串加密的问题

​ 可以看到做的操作就是获取JNI的方法ID，方便后续调用。可以看到这里的本该传入的字符串好像都是被加密的，点击xmmword_2C010进入看看情况：

很明显确实是被加密了，那么要怎么还原回原本的字符串呢？这里可以使用交叉引用，发现只有这里是进行了写操作的，直接跳转到这个位置

接着就是一步步往上跟踪，最后定位到这个位置：

这里其实就是一个简单的异或加密，但是数据量太多，这个就交给AI来帮忙了，xmmword_2C010这里的字符串并不只是这个地方的，还延伸到了0x2C02E这个位置，遇到了ALIGN才算结束：

​ 按照上面的方法定位解密的位置，最后能够写出下面的脚本：

​ 这里用到的加密字符串基本上都能按照这个方法进行解密。

​ 使用上面的方法来获取解密函数效率会非常慢，而且写注释看的不舒服。通过刚才的分析可以发现，这些字符串解密之后都是存放到原来的位置上的，那么我们如果可以直接在这些位置上修改成明文的话，反编译当中也可以看到明文字符串了。爽歪歪~~

​ 那么来分析一下这个解密函数在什么时候会被调用，以此来确定dump点:

通过交叉引用可以看到，是在init_array当中被调用的，而这个so会在进行了一次登录之后加载。这样就很方便了，直接先登录一次，让so加载，加载完成后字符串解密完成。接着就可以直接dump了，连dump点都不需要找，这里使用Frida进行dump：

​ dump下来的so使用soFixed来修复一下，由于在加载到内存之后，got表会被污染，这里将对应解密的字符串数据移植到原来的so上，便于分析。移植的过程中要注意，soFixed修复的so，节的文件偏移和内存地址是一样的，但是原来的so可能有区别，需要注意。这里写个python脚本跑一下，再拿来分析：

这样看起来就非常舒服了。

​ 接下来继续进行ollvm的分析。这里一开始一步步分析ollvm，也是通过上面get_package_name的方法进行分析。发现太牢了，然后试着用交叉引用逃课。首先这里会获取包名，正常来说这个包名一般来说就是app的包名

​ 接着对这个pkg_nname进行交叉引用，并搜索app的包名:

发现了，然后跳转过去：

这里就是校验获取的包名和app包名是否一致，然后设置op状态码。然后继续跟踪，大致三四个状态码切换之后就会来到这个位置：

可以看到这两个字符串就是我们Unidbg模拟的时候发现拼接到参数当中的特定字符串。接下来可以继续分析状态机，这里我就直接交叉引用看调用了。首先对v160进行状态引用

​ 可以发现除了一堆字符指针的赋值，就是将v160赋值给了v193。那么此时就到这个地方看看有没有什么特别的。

并没有发现什么特别之处，这里再对193进行交叉引用，发现有用到了memcpy这种东西，经过简单分析，发现了几个这种结构：

都是开辟空间，然后进行参数拼接。这里猜测就是参数进行拼接的地方。如果需要更加准确的知道到底是调用了哪一个的话，需要跟着状态机分析。最后这里会通过newStringUTF将拼接后的参数转成jstring。接着就是继续对v175进行交叉引用，

接着就是这个位置，转大写，然后调用MessageDigest.digest，接着继续引用

最后就是这个位置，也就是进行SHA-1哈希，然后toHexString。

​ 至此整个signature就差不多完成了。到这里整个Signature生成应该是比较明确的了，大致过程就是：将登录参数按固定格式拼接后，追加固定字符串 MOBILE-V1-PRODUCT-7D74899B338B4F348E2383970CC09991E8E8D8F2BC744EF0BEE94D76D718C089，转大写，再做 SHA-1 并转十六进制输出。

参数分析：[原创]新版****Ollvm混淆Signature参数解析-Android安全-看雪安全社区｜专业技术交流与安全研究论坛

Unidbg补环境及Trace：《安卓逆向这档事》第二十四课、Unidbg之补完环境我就睡(上) - 吾爱破解 - 52pojie.cn

[培训]Windows内核深度攻防：从Hook技术到Rootkit实战！