前言
对之前apk反编译的补充，很久没更新，怕忘记啦。正所谓好记性比不过烂笔头，哈哈
上一篇的地址：https://blog.csdn.net/weixin_42277380/article/details/97235098?spm=1001.2014.3001.5501
问题一：app抓到数据包，可返回的数据是加密的
原因：被AES加密了，要想还原出明文，必须要反编译拿到KEY
解决过程
1、下载APK文件
2、通过搜一些特征字符串，确定需要的.dex文件 ，例如找到url中加密的参数来搜
3、找到dex文件，然后依次用JADX对其进行反编译
4、再搜索AES相关的关键词最终成功定位、找到相关固定AES_key，lv
5、对应的KEY和IV，其使用了"AES/CBC/NoPadding"加密算法
6、通过对比测试，确认生成加密过程
问题二：发现app被加壳了，使用的是360的加壳工具
原因：DEX加固是对DEX文件进行加壳防护，防止被静态反编译工具破解而泄露源码
解决过程
使用Xposed + FDex2插件
1、模拟器安装好 FDex2插件 (不要忘了重启系统)，启动插件，点选要脱壳的APP
2、然后启动目标APP（儿科主治医师总题库）。
3、使用Root Explorer浏览到APP的数据目录下，如果看到多个dex文件，说明脱壳成功了（原本该目录下没有这些文件）
问题三：app安装在模拟器上打不开
抓取思路：
1.将apk 反编译 成java 文件
2.从java 文件中找到生成字段的代码，将其修改为可读的java程序
3.将java代码 改为python 代码（本来想从网上找找有没有python 执行java的方法 但安装完发现麻烦是一方面，主要还是不太好用）
4.尝试模拟请求获取数据
具体过程如下：
首先,抓包工具使用的是Burp Suite ， 先使用代理抓取手机端的具体请求--->查看header --->使用BurpSuite 工具中的Repeat--->在raw 上修改参数，删除参数--->得到必需字段 为Access_tk (Burp Suite 的使用安装下载自行百度)
之后，开始反编译apk.
反编译工具在网上有两种，一种是Android Killer 这是一个集成好的反编译工具直接安装即可使用 使用链接 https://www.cnblogs.com/common1140/p/5198460.html 适用于 简单的app ,如果在apk里加了防止反编译的化就不太好用，但它的搜索很好用，可以直接寻找文件中的字段，通过它 我们可以找到我们点击的页面 从而找到响应的方法名
第二种就是网上常见的反编译思路 ：
具体安装工程： https://blog.csdn.net/lmj623565791/article/details/23564065
1、android-apktool 主要是进行反编译的
2、dex2jar-0.0.9.15 将反编译后的classes.dex文件转化为jar
3、jd-gui-0.3.6.windows 对第2步获得的jar，进行查看
4、在文件夹中寻找.java的文件，生成的规则
加壳
加壳工具：Aspack 2.11，Pecompact v1.82, UPX 1.20 ，fsg
加壳的全称应该是可执行程序资源压缩,是保护文件的常用手段.
加壳过的程序可以直接运行,但是不能查看源代码.要经过脱壳才可以查看源代码.
原理：是利用特殊的算法，对EXE、DLL文件里的资源进行压缩。类似WINZIP 的效果，只不过这个压缩之后的文件，可以独立运行，解压过程完全隐蔽，都在内存中完成。
解压原理，是加壳工具在文件头里加了一段指令，告诉CPU，怎么才能解压自己。加“壳”虽然增加了CPU附带但是减少了硬盘读写时间，实际应用时加“壳”以后程序运行速度更快（当然有的会变慢，那是选择的加“壳”工具问题）
RAR和ZIP都是压缩软件不是加“壳”工具，他们解压时是需要进行磁盘读写
“壳”的解压缩是直接在内存中进行的
安卓APP安全
混淆代码、整体Dex加固、拆分 Dex 加固、虚拟机加固等方面。
混淆代码
Java代码是非常容易反编译的，作为一种跨平台的、解释型语言，Java 源代码被编译成中间“字节码”存储于class文件中。由于跨平台的需要，这些字节码带有许多的语义信息，很容易被反编译成Java源代码。为了很好地保护Java源代码，开发者往往会对编译好的class文件进行混淆处理。
混淆就是对发布出去的程序进行重新组织和处理，使得处理后的代码与处理前代码完成相同的功能，而混淆后的代码很难被反编译，即使反编译成功也很难得出程序的真正语义。ProGuard就是一个混淆代码的开源项目，能够对字节码进行混淆、缩减体积、优化等处理。
解决：利用Proguard，对Dex2jar进行反编译处理后的Apk效果示例，不仅能够保护代码，而且能够精简编译后的程序大小，减少内存占用。
整体Dex加固
DEX加固是对DEX文件进行加壳防护，防止被静态反编译工具破解而泄露源码，最刚开始出现的是整体加固技术方案。
整体加固技术的原理：包括替换application/classes.dex、解密/动态加载原classes.dex、调用原application相关方法、将原application对象/名称设置到系统内部相关变量四大环节。
其中最为关键的一步就是解密/动态加载原classes.dex，通过加密编译好的最终dex源码文件，然后在一个新项目中用新项目的application启动来解密原项目代码并加载到内存中，再把当前进程替换为解密后的代码，能够很好地隐藏源码并防止直接性的反编译。
整体Dex加固逆向分析：
一是在内存中暴力搜索 dex\n035，再 dump
另一种方法就是通过HookdvmDexFileOpenPartial(void* addr, int len, DvmDex**)。
拆分Dex加固
随着业务规模发展到一定程度，不断地加入新功能、添加新的类库，代码在急剧膨胀的同时，相应的apk包的大小也急剧增加，那么简单的整体加固方案就不能很好地满足安全需求，在整体加固方案之外又出现了拆分加固的技术方案。
dex文件是一个以class为核心组装起来的文件，其中最重要的是classdata和classcode两部分，有其特定的接口和指令数据，选取这两部分来拆分的话，即使拆分出来也不会泄露class数据和字节码数据，反编译出来也不完整，安全性较高。
拆分Dex加固逆向分析：用classdata替换从而组装成新的dex文件，虽然和原来的dex文件不会完全一致，但也在一定程度上复原了被拆分数据的样子。但要注意的是，这种方法仅适用于被拆分出去的数据变形一次性完成，也就是说，在有其他保护思路的情况下尽量避免使用，而且即使有需要也尽量选在用到这个类的时候才去恢复。
虚拟机加固
虚拟机加固也属于dex拆分加固的一种，它是对字节做了一些变化处理。
以add-int v0, v1, v2、sub-int v0, v1, v2、mul-int v0, v1, v2这三条指令进行替换，然后进行加固编译，这样子操作后，即使把替换后的数据恢复了，也不会以add-int v0, v1, v2、sub-int v0, v1, v2、mul-int v0, v1, v2这三条指令进行替换，然后进行加固编译，这样子操作后，即使把替换后的数据恢复了，也不会变形成为之前的字节码，安全系数较高。
虚拟机加固逆向分析—HOOK JNI 接口
结语
先记录到这，嘿嘿~