折腾：
【已解决】尝试破解小花生app安卓apk希望看到api返回的json中的J的解密算法得到明文
期间，虽然之前已经：
【已解决】用apktool，dex2jar，jd-gui去反编译安卓apk查看app源码
但是看到的源码是混淆后的源码
看不出原来的源码，找不到原来的代码的逻辑了。
对于之前某个api请求：
去搜：
xiaohuasheng.cn
根本就搜不到：
在去搜：
Reading.svc
selfReadingBookQuery2
selfReadingBookQuery
也搜不到。
所以先去了解：
【已解决】搞懂安卓app混淆和加固常见做法和相关逻辑
此处虽然搜不到：mapping.txt文件
但是找到：
assets/litepal.xml
<?xml version="1.0" encoding="UTF-8"?> <litepal> <dbname value="xhs"/> <version value="1"/> <list> <mapping class="com.huili.readingclub.model.AudioDownloadRecord"/> <mapping class="com.huili.readingclub.model.AudioDownloadQueue"/> </list>
-》所以无从还原
-》不过看到了：
这个app
xiaohuashengv3.6.9_downcc.com.apk
对应的org应该是：
com.huili.readingclub
然后此处的代码，很明显做了混淆处理。
好像可以用来解密代码？还原代码？
-》需要知道解密算法，此处不知道，如何使用。
安卓 apk 反混淆
Android 反混淆神器JEB2的使用简介 – 飞少的博客 | Jack’s Blog
http://jackzhang.info/2018/08/28/Android-反混淆神器JEB2的使用简介/
“在SDK的安装目录下\tools\proguard\lib找到proguardgui，双击进入ProGuard工具，点击ReTrace按钮，将mapping文件和log信息导进去，点击ReTrace！就可以看到log的错误信息。”
我又没有别人的“mapping文件和log信息”
http://secwiki.neu.edu.cn/wiki/images/e/eb/Android混淆技巧与反混淆_小波.pdf
Android 混淆技巧与反混淆 小波 pdf
https://github.com/bit4woo/Summit_PPT/blob/master/2015阿里安全峰会/Android混淆技巧与反混淆-小波.pdf
-》Android混淆技巧与反混淆-小波.pdf
混淆VS加固
混淆
• 将代码变得难以阅读 • 配置复杂
需要开发配合
“加固
• 隐藏代码
• 对抗自动化工具
• 反调试/反篡改/反注入 • 一键搞定
不需要开发配合
不冲突, 可联⽤!”
“反混淆脚本思路
http://jackzhang.info/2018/08/28/Android-反混淆神器JEB2的使用简介/
许多APK开发商为了在崩溃时保存源文件类名、行号等信息会在APK混淆时添加以下规则保留源文件信息.
（注意：若APK没有保留这些源信息时则无法反混淆）
-keepattributes SourceFile,LineNumberTable
这样我们在看Smali时就能在(JEB中称为)字段中看到原始类名信息”
此处：
smali/com/tencent/StubShell/a.smali
.class Lcom/tencent/StubShell/a; .super Ldalvik/system/PathClassLoader;
->看不到原始类名
-》无法反混淆。
Generic Android Deobfuscator
-》感觉还是很难达到我们要的效果
-》感觉需要先去想办法：
破解之前的乐固的加固？
所以去：
【已解决】安卓app如何脱壳如何破解加固
【后记20190401】
后来的又有很多折腾，直到
【整理】把jar包转换为java源代码的java反编译器的整理和对比
感觉是：
貌似jd-gui，procyon等java decompiler，貌似已经就是
（在反编译，即把jar包转换为java源码，的同时）
实现了反混淆的功能了
后来基本上确认了，的确是的：
对于：
【已解决】mac中试用FDex2去hook导出安卓app的dex等文件
来说，在动态从app中hook导出dex文件时，好像就已经基本上部分破解了，之前被混淆的代码
-》因为内部是抓取到了函数的调用的，使得函数名，和参数，基本上都能被还原为之前的逻辑，只是参数的名字，不是之前的名字罢了。
-》然后，再通过各种java的反编译器，比如：
【整理】java反编译器对比：JD-GUI，CRF，Procyon，Jadx
尤其是效果很好的Jadx，可以非常完美，几乎接近源码的方式，还原出java代码
-》包括其中的常量的引用和定义，以及函数代码内部结构，都非常易懂了。
-》所以，可以算出95%的完成了代码的还原了。
-》所以算是破解了之前用ProGuard等方式混淆的java源代码了。
-》总结说就是：
用FDex2等从运行的app中，（如果能）导出dex文件，
再去用Jadx等java反编译器，从dex（或dex转换出的jar）反编译出的java源代码，
基本上可以实现90%左右的还原原始java源代码的效果了：
包括：
- 常量的定义和引用
举例：
public static void addSignature(RequestParams requestParams, String str) {
if (str.startsWith(MyConfig.SERVER_PORT)) {
str = str.substring(MyConfig.SERVER_PORT.length());
}- 变量的相对智能的命名
- 从函数类型来命令：
- long类型变量l1
- 或从调用的函数的名字来命令变量：
- long get1970ToNowSeconds = DateUtils.get1970ToNowSeconds();
- 清晰的代码逻辑和结构
举例：
jadx导出的计算m5的str的java源码：
逻辑结构就很清晰了。
-》等等，使得代码可读性很高，基本上破解了之前的代码混淆，实现了反混淆。
【后记】
对于代码混淆后，对于
导出dex，dex转jar，jar导出源码
的方法能否破解 代码混淆，
导出源码是否是混淆后的源码
有些不太确定，去研究看看
安卓 代码混淆 dex hook
安卓 代码混淆 dex
安卓 代码混淆 导出dex
“第三方框架不混淆，也要看具体情况，不是所有的lib都不能混淆。用了反射的肯定不能混淆。”
“六，Android混淆的总结
Java的反射，为什么不能混淆呢？因为代码混淆，类名、方法名、属性名都改变了，而反射它还是按照原来的名字去反射，结果只射出一个程序崩溃，Crash，一脸的懵逼。
注解用了反射，所以不能混淆。 不混淆任何包含native方法的类的类名以及native方法名，否则找不到本地方法。
Activity更不能混淆，因为AndroidManifest.xml文件中是完整的名字，混淆后怎么找？
自定义view也是带了包名写在xml布局中，给我换成a，怎么破？ R文件混淆了，id没了，界面崩溃那时自然咯。
本文没有指定混淆某个类中的某个方法。”
-》“Activity更不能混淆” 或许就是这个原因，导致包含app业务逻辑的代码，不能混淆？
-》导致反编译后，能看到原始完整的代码？
估计是这个原因吧
“混淆不能阻止反编译，只能增加反编译以后阅读理解的难度罢了，安全的代码依然安全，不安全的代码不会因为用了 proguard 就变得更安全。你代码再混淆再加固再怎么样怎么样最后用 http 传输、最后明文传输密码、最后自己开了后门、最后把数据保存在了 external storage，不还是白费？最近看了 Twidere 作者
@Mariotaku
的推，他的想法是把 StringBuilder 替换了，每次 toString 的时候 log 下来，这种时候底裤都被人看去了，什么 so 啊 jni 啊混淆啊加固啊都没有用，不如好好考虑一下服务器端以及通信协议的安全。”
安卓 导出dex 破解代码混淆
Android代码混淆技术总结（一） | DroidSec | Android安全中文站
http://www.droidsec.cn/android代码混淆技术总结（一）/
【总结】
目前感觉是：
反编译后得到的源代码，还是混淆后的。
不过由于一些原因：
- 部分代码安卓java内部用到了反射
- 如果混淆就会导致找不到类
- 导致crash崩溃
- 以及AndroidManifest.xml写明了类名
- 就无法混淆，否则也会找不到类？
使得包含app业务逻辑的代码，无法混淆？
至少是核心代码无法混淆？
-》使得反编译后的代码中，第三方很多库倒是混淆了，但是核心的app业务逻辑代码，却没有（无法）混淆
-》使得容易破解后搞懂app的业务逻辑，实现了破解的目的。
转载请注明：在路上 » 【已解决】如何反混淆即还原反编译后混淆的安卓代码