本文最后更新于 1041 天前，其中的信息可能已经有所发展或是发生改变。
需求分析原则
- 逆向这个 apk 需要得到什么样的结果，是否可以在不破解的前提下获取
- 粗略判断逆向需求属于 java 层 还是 so 库层，单纯的静态分析 smali 是否可以完成需求
- 尽可能的将需求实现的步骤简单化，复杂的操作可以体现自己的技术，简单快速的完成需求可以有更多时间分析有可能存在的反逆向插桩检测
- Apk 分析第一步
- 判断是否加壳，如果加壳了需要先脱壳修复 — 脱壳的需求，我遇到了一般都懒得弄，除非以后打算走逆向方向，不然别碰脱壳，找人帮忙脱性价比比较高。
- 静态分析 smali 代码，将开发者的log开关打开 — 一般写代码都会有各种 log 在代码中，发布的线上包一般会通过开关去掉打印的 log ，需要修改 smali 代码先打开这个开关
- 通过 burp suite 抓包 ，或者 hook okhttp 请求函数，将这个应用所有的请求明细获取到 — 一般优先用 抓包的方式获取，但是有的 apk 加了ssl 证书校验，就会比较麻烦，不如直接 hook okhttp 库，打印所有请求
到这里，一个应用的运行流程以及原理，对应的工作方式，都可以分析出来
- Apk 分析第二步
- 把第一步中分析到的请求路径，伪造对应路径的服务端实现一遍，服务端固定死返回一个json，然后修改 json 中的 值，来动态测试对应的 json 键所控制的功能
- 从 application 中分析，一般的第三方 sdk 初始化都会在 application 中初始化，可以在这里修改第三方 sdk 的 key，如果加密混淆了，那么需要列一下符号表，将符号解密，也就是自己给加密字符定义内容
- 打入自己的代码
- 新建 as 工程，可以通过反射调用 apk 开发者的一些代码，也可以通过自己书写来覆盖 apk 开发者的功能，熟练的可以在 smali 代码中修改逻辑，但是效率比较低，炫技的同时头秃 hhh～
- 如果要写 ui 最好不用 xml，方便回编译，直接用代码生成布局
- Jadx 导出的 gradle 工程可以动态调试，用 as 动态调试可以更快的定位需要在哪里打入代码
PS：没有无法逆向的 apk，只有是否可以承受的逆向成本