折腾：
【已解决】尝试破解小花生app安卓apk希望看到api返回的json中的J的解密算法得到明文
期间，看到源码中有：StubShell
搜：
Android StubShell
腾讯加固纯手工简易脱壳教程 – 『移动安全区』 – 吾爱破解 – LCG – LSG |安卓破解|病毒分析|破解软件|www.52pojie.cn
好像很复杂的样子
搜：
com.tencent.StubShell.TxAppEntry
还真搜到了：
/Users/crifan/dev/dev_tool/android/reverse engineering/apk/xiaohuashengv3.6.9 – apktool decoded/AndroidManifest.xml
<application android:allowBackup="true" android:icon="@drawable/app_logo" android:label="@string/app_name" android:name="com.tencent.StubShell.TxAppEntry" android:supportsRtl="true" android:theme="@style/AppTheme"> <meta-data android:name="TxAppEntry" android:value="com.huili.readingclub.MyApplication"/>
搜：
TxAppEntry
找到很多：
自己此处也是类似结构：
➜ tencent pwd /Users/crifan/dev/dev_tool/android/reverse engineering/apk/xiaohuashengv3.6.9 - apktool decoded/smali/com/tencent ➜ tencent ll total 0 drwxr-xr-x 12 crifan staff 384B 3 14 13:39 StubShell drwxr-xr-x 3 crifan staff 96B 3 14 13:39 bugly ➜ tencent tree . . ├── StubShell │ ├── SystemClassLoaderInjector.smali │ ├── SystemInfoException.smali │ ├── TxAppEntry.smali │ ├── TxReceiver.smali │ ├── XposedCheck.smali │ ├── ZipUtil.smali │ ├── a.smali │ ├── b.smali │ ├── c.smali │ └── d.smali └── bugly └── legu ├── Bugly.smali ├── BuglyStrategy$a.smali ├── BuglyStrategy.smali ├── CrashModule.smali ├── a.smali ├── b.smali ├── crashreport │ ├── BuglyHintException.smali │ ├── BuglyLog.smali │ ├── CrashReport$CrashHandleCallback.smali │ ├── CrashReport$UserStrategy.smali │ ├── CrashReport.smali │ 。。。 │ └── inner │ └── InnerAPI.smali └── proguard ├── a.smali ├── 。。。 └── z.smali 14 directories, 123 files
➜ ➜ lib pwd /Users/crifan/dev/dev_tool/android/reverse engineering/apk/xiaohuashengv3.6.9 - apktool decoded/lib ➜ lib tree . . ├── arm64-v8a │ ├── libBugly.so │ ├── libgifimage.so │ ├── libimagepipeline.so │ ├── libjcore119.so │ ├── libshella-2.9.1.2.so │ └── libstatic-webp.so ├── armeabi │ ├── libBugly.so │ ├── libgifimage.so │ ├── libimagepipeline.so │ ├── libjcore119.so │ ├── libshella-2.9.1.2.so │ ├── libstatic-webp.so │ ├── mix.dex │ └── mixz.dex ├── armeabi-v7a │ ├── libBugly.so │ ├── libgifimage.so │ ├── libimagepipeline.so │ ├── libjcore119.so │ ├── libshella-2.9.1.2.so │ └── libstatic-webp.so ├── 。。。 7 directories, 36 files
另外，其中：
也看到了legu=乐固 加密
里面很多legu
也是够复杂。
特征很明显，这是个Legu壳
“此时，我们就完成了native层的分析，并获得了恶意APP的真正DEX文件。
Package Name: net.gotsun.android.wifi_configuration ”
以及后来的：
【已解决】安卓app如何脱壳如何破解加固
中的：
另外参考：
“大多数都混淆过了
大多数软件都上加固保了”
后来看到有个：proguard
smali/com/tencent/bugly/legu/proguard
或许这里面有我们要的（混淆过的）源码？
所以去研究看看：
proguard
是所谓的：加固保？
中的：”360加固宝”
Android proguard
ProGuard的三大作用
- 压缩（Shrinking）
- 移除未被使用的类、属性、方法等，并且会在优化动作执行之后再次执行（因为优化后可能会再次暴露一些未被使用的类和成员
- 优化（Optimization）
- 优化字节码，并删除未使用的结构
- 混淆（Obfuscation）
- 将类名、属性名、方法名混淆为难以读懂的字母，比如a,b,c等，增大反编译难度
ProGuard的输出文件说明
- dump.txt 说明 APK 中所有类文件的内部结构。
- mapping.txt 提供原始与混淆过的类、方法和字段名称之间的转换。
- seeds.txt 列出未进行混淆的类和成员。
- usage.txt 列出从 APK 移除的代码。
“ps：这里有时候会看到诸如a.a.a、b等字母标示的包名、类名或者方法名，这是由于在某些apk打包的时候进行代码混淆导致的。使用反编译工具只能看到混淆之后的代码结构，真正未混淆前的源码还需要结合mapping.txt文件进行分析。mapping.txt文件里即标注出了代码混淆前后的文件名称对应关系。”
看到别人有提到：mapping.txt
-》但是自己此处肯定没有人家的mapping.txt文件
-》也搜不到相关的内容。
另外去：
“整个流程下来，虽然看上去很顺利，但实际操作上还是有很多问题的，比如想反编译的apk是被混淆过的，或者被加固过，又或者在native层做了签名校验，反编译的难度就会难很多。
但安全攻防，有加固那也有脱壳，也有.so库的反编译，不过作为一个做开发而不是做安全的，也没有必要研究得太深入）”
-》防止被反编译看到原始源码的做法：
- 混淆
- 加固
- 在native层做了签名校验
接着去：
【已解决】用基于Procyon的Luyten反编译安卓jar包得到java源码
再去：
【已解决】安卓app如何脱壳如何破解加固
【总结】
自己的Android的程序，项目，app，为了防止被别人反编译而看到自己的原始源码，有多种保护措施或做法：
- 混淆=代码混淆：
- 含义：把原先的代码通过变量替换（成a,b,c等）方式使得代码不可读，很难读，增加破解人员读懂原先代码逻辑的难度
- ProGuard
- 作用：
- 压缩（Shrinking）
- 移除未被使用的类、属性、方法等，并且会在优化动作执行之后再次执行（因为优化后可能会再次暴露一些未被使用的类和成员
- 优化（Optimization）
- 优化字节码，并删除未使用的结构
- 混淆（Obfuscation）
- 将类名、属性名、方法名混淆为难以读懂的字母，比如a,b,c等，增大反编译难度
- 说明+注意事项：
- 有些库，混淆后，导致代码不可用
- 所以有些好的库，专门支持了ProGuard
- okhttp
- https://github.com/square/okhttp
- R8 / ProGuard
- If you are using R8 or ProGuard add the options from okhttp3.pro
- 有些库不够好，需要自己额外处理
- https://github.com/lovedise/PermissionGen
- -》
- permissiongen权限管理混淆处理 – dobiman的博客 – CSDN博客
- https://blog.csdn.net/dobiman/article/details/78595709
- 加固=应用加固：
- 含义：加了层保护壳，使得别人及时反编译得到jar包，看到源码，也看不到原始的项目的源码
- 有好多家提供加固方案：
- 腾讯乐固
- 官网：http://legu.qcloud.com/
- 加固后变成：
- com.tencent
- StubShell
- bugly
- 360加固保
- 官网：http://jiagu.360.cn/
- 加固后：
- com
- qihoo.util
- qihoo360.replugin
- stub
- 阿里聚安全
- 官网：http://jaq.alibaba.com/
- 爱加密
- 官网：http://ijiami.cn/AppProtect
- 在native层做了签名校验
- “只是对部分方法由java层移到了native层， 需要配合阿里的安全组件才能真正起到保护的目的。”
【后记 20190321】
继续研究加固技术：
Android 加固
解释的很全面了。
TODO：
抽空整理过来即可。
此处（好像）是用的：
第一代壳
的
内存Dump法
-》用DumpDex导出了dex
“总结
以上分析基于免费版加固，企业级加固肯定加固强度高一个等级，再加上代码加花混淆等操作，相信一般人员很难破解，而且网上企业级破解样例很少，短期内可以有效保证代码安全。因而继续使用梆梆加固还是很有必要的，但出于兼容性考虑，有时候需要给用户提供别的加固包，这里结合使用成本，以上分析及实际使用体验（启动速度，兼容性，操作复杂度）给出2个备选方案：
1. 360加固（dex级）
2. 阿里加固（核心方法级）+ 安全组件
* 360加固包已经提供部分用户使用，目前没有异常反馈。”
应用加固服务
防篡改
通过完整性保护和签名校验保护，能有效避免应用被二次打包，杜绝盗版应用的产生。
防逆向
对代码进行隐藏及加密处理，使攻击者无法对二进制代码进行反编译，获得源代码或代码运行逻辑。
防调试
通过反调试技术，使攻击者无法调试原生代码或Java代码，阻止攻击者获取代码里的敏感数据。
Dex加固
SO加固
防二次打包
核心技术
*
- 防逆向
- 通过DEX加花和加壳、SO文件高级混淆和加壳等技术对DEX和SO文件进行保护，防止被IDA等逆向工具分析
- 防篡改
- 在加固时提取APP内各文件的文件特征值，当文件运行时，系统解密加密文件提取特征值进行文件校验
- 防调试
- 多重加密技术防止代码注入，防JAVA层/C层动态调试、防代码注入和防HOOK攻击
- 数据防泄漏
- 使用多种加密算法，包括国际通用算法及自主研发的加密算法等，保护本地数据
- 页面数据防护
- 应用防劫持、应用防截屏、虚拟键盘SDK产品和技术，防界面劫持插件对组件进行全方位监听
- 传输数据防护
- 在客户端和服务器分别嵌入数据加密SDK，保证通道中传输的数据为高强度加密后的数据
“
防逆向
多重指令转换VMP虚拟机保护技术，对关键代码、核心逻辑进行加密保护，避免通过IDA，Readelf等逆向工具分析获取源码
防调试
多重加密技术防止代码注入，防止JAVA层/C层动态调试，可有效抵挡动态调试、内存DUMP、代码注入、HOOK等恶意攻击
DEX安全保护
* VMP虚拟机保护
* Java2C保护
* DEX函数抽取加密
*
SO库加密保护
* SO代码高级加密
* SO函数动态加密
* 防HOOK攻击
* 防脱壳
”
“总结
- 体积（体积小的为优）：360 > 腾讯 > 爱加密 > 阿里 > 梆梆
- 兼容性： 阿里 > 腾讯 > 360 = 梆梆 > 爱加密
- 启动速度（时间短为优）： 阿里 > 爱加密 > 360 = 梆梆 > 腾讯
- 漏洞： 腾讯 > 爱加密 > 360 > 梆梆 > 阿里
app加固的好处是进一步保护了自己的核心代码，提升了盗版的难度，但同时也影响的应用的兼容性，程序的执行效率，还有部分的市场会拒绝加壳后的应用上架。所以请大家结合自身的情况来选择。”
“主要来看一下Dex文件的头部信息，其实Dex文件和Class文件的格式分析原理都是一样的，他们都是有固定的格式，我们知道现在反编译的一些工具:
1、jd-gui：可以查看jar中的类，其实他就是解析class文件，只要了解class文件的格式就可以
2、dex2jar：将dex文件转化成jar，原理也是一样的，只要知道Dex文件的格式，能够解析出dex文件中的类信息就可以了”
-》
最终完整的总结详见：
安卓应用的安全和破解
转载请注明：在路上 » 【已解决】搞懂安卓app混淆和加固常见做法和相关逻辑