「摸鱼听书」逆向分析和一些心得（已脱壳）

霄云

梆梆SecShell一代加固。拿到APK第一眼看到梆梆壳，以为脱完壳基本就能跑，实际踩了一大堆坑

注意:只有脱壳成功了，但验证没过去 总结就是不能用，等别的大佬优化

一、先进行脱壳（有了AI脱壳就是方便）

用eBPFDexDumper的maps‑only模式直接扫进程内存，dump出来一共15个DEX，14份是解密后的业务DEX，剩下1份是原始stub。
脱壳完成后开始处理重打包相关内容。

1.删除梆梆壳本体libSecShell.so、libSecShell‑x86.so。

2.修改Manifest，把壳的Application com.SecShell.SecShell.AW替换成系统原生android.app.Application，删掉壳自带的Provider com.SecShell.SecShell.CP以及代理Activity com.SecShell.SecShell.AP。

踩坑点：libencrypta.so、libencryptb.so、libencryptc.so属于应用自身业务SO，不是壳文件，千万不能删掉，删掉直接报UnsatisfiedLinkError。

把dump出来的14个真实DEX按照multidex规范重命名classes.dex~classes14.dex，主DEX是classes.dex。
这里遇到好几轮闪退问题

- 第一次闪退：误删libencrypta/b/c.so，native方法找不到。保留这三个SO，smali直接patch checkSignatureNative返回0，绕过本地签名校验。

- 第二次闪退：Sigmob SDK类找不到，根源是DEX的adler32校验值计算错误，之前用ph adler32没带size参数，只计算了前256字节。重新从0x0c到文件末尾完整计算adler32，写入DEX头部对应位置。

- 第三次闪退：IncompatibleClassChangeError，R8混淆生成了两份同名oz类，一个接口一个普通类，DEX加载顺序导致冲突。调整DEX加载顺序，让接口类优先加载。

- 第四次闪退：还是oz相关报错，部分DEX的signature没有修复到位，重新计算更新对应DEX的signature和checksum之后才正常。

修复完之后APP可以正常打开运行，但是点播放直接返回破解版提示。

二、播放接口签名

点击播放就会走这套签名逻辑，全部参数放到Cookie里面传给服务端做校验。
调用链路：
AbiAudioApi.getAudioUrl()
→ SourceNetworkUtilsKt.managementGetDecryptWithSign()
→ ManagementClient.B post网络请求
→ SecurityManager.getStrengthenedSignatureData(context, timestamp)
→ getSignatureDataNative(context, timestamp) 【native层，输出sign2】
→ SecurityManager.getJsign(context)
→ getAppSignatureHash(context)，java层计算jsign，APK证书DER的SHA‑256小写64位hex
→ SecurityManager.encryptJsign(jsign, timestamp)
→ encryptJsignNative(jsign, timestamp)【native层，输出si】
拼接Cookie：sign2=xxx;jsign=yyy;sign=zzz，把整套cookie丢给服务器校验。

参数明细：

- jsign：纯Java实现，证书SHA256小写hex，已经通过smali写死原始值绕过。

- sign2：getSignatureDataNative输出，32位hex，每次请求随时间戳变化，OLLVM混淆native函数。

- si：encryptJsignNative输出，base64格式，native生成。

- sign：native组合签名，长base64字符串。

本地这边已经把checkSignatureNative、getJsign做了patch，本地校验可以过。但是sign2、si、sign全部来自混淆后的native方法，没有办法静态算出正确结果。服务器校验这三个字段，直接返回假音频地址
{"title": "检测到破解版应用", "url": "http://47.103.62.118/api/app/source/sound/fake-app.mp3/", ...}


三、进一步尝试

翻了一下帖子发现论坛有一位大佬给出了一个方案
原帖https://bbs.binmt.cc/thread-142096-1-1.html感谢大佬

结合AI试着使用了Frida 动态方案
libencrypta、libencryptb、libencryptc里面都存在frida检测字符串，frida‑agent、frida‑gadget这类特征串，直接内置gadget会被检测拦截。处理方式是dd原位替换检测字符串，全部替换成等长的乱码字符，三个so里的检测特征全部处理干净。
gadget在上面那个帖子里可以下载
选用gadget版本16.7.19，17.x在Android10环境下会出现脚本加载异常。准备libfrida‑gadget.so、libfrida‑gadget.config.so、libjs.so（存放hook脚本）。
注入点写在MainActivity.onCreate，添加System.loadLibrary("frida‑gadget")。gadget配置使用相对路径：{"interaction":{"type":"script","path":"libjs.so"}}。

脚本调试过程：
v1：增加5秒延迟再执行hook逻辑，16.7.19版本正常跑，APP不会卡死。
v2：成功抓取jsign、si变量。
v3：完整拿到完整Cookie，sign2、jsign、sign全部抓出来。
v4：拿着抓出来的样本，试MD5、各类HMAC算法，都对不上。
v5：猜测时间戳存在偏差，暴力枚举±10000ms时间戳去试，依旧匹配失败，还会阻塞播放流程。
到这里就没有再进行尝试了

实际抓到的样本数据：
jsign = c116a7867a7534e6a0dbe9a0c7c8eded224f6605e09d5b2676c4d384d2082006
sign2 = fd5206a20368730836a07b279ce92463（每次请求动态变化）
si = base64长串
Cookie：jsign=xxx; sign2=xxx; sign=xxx

结论：静态逆向native：libencrypta/b/c大量OLLVM平坦化混淆，JNI注册表也做了混淆，静态分析成本极高，动态没成功

残品和原包

游客，如果您要查看本帖隐藏内容请回复

霄云

这个版本用不了，甚至卡启动页面，原因帖子里也说了，懒得改了，即使改了也用不了，！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！，实在想看看里面长啥样就自己改libjs.so

兮夜

感谢分享

喜破解

牛逼牛逼

webcfo

学习学习

GoldApple1939

感谢分享

TGMxla520

跪谢楼主分享啊

道无相

感谢分享

zhangcanyun

感谢分享

Raymondman

看看

CGM

我也是折腾了好久没成功

小企鹅

看看隐藏

野比大雄

看看

niheibie

看看隐藏

氵衮

看看

吃橘子

看看隐藏