2023-03-13 21:09:47 +08:00
|
|
|
|
# 第十二章 逆向实战
|
|
|
|
|
|
2023-04-11 23:32:57 +08:00
|
|
|
|
## 12.1 案例实战
|
2023-03-13 21:09:47 +08:00
|
|
|
|
|
2023-04-11 23:32:57 +08:00
|
|
|
|
经过对`AOSP`源码的不断探索,对`Android`中应用深入了解,在最后一章中,将结合前文中学习的知识,来进行一个案例的实战,在实战的过程中,首先要对需求进行分析,然后将需要实现的目标进行拆分,最后对其逐一实现,最后组合并测试效果。
|
2023-03-13 21:09:47 +08:00
|
|
|
|
|
2023-04-11 23:32:57 +08:00
|
|
|
|
`JniTrace`是一个逆向分析中常用的基于`frida`实现的工具,在`native`函数调用时,`c++`代码可以通过`JNI`来访问`Java`中的类,类成员以及函数,而`JniTrace`工具主要负责对所有`JNI`的函数调用进行监控,输出所有调用的`JNI`函数,传递的参数,以及其返回值。
|
2023-03-13 21:09:47 +08:00
|
|
|
|
|
2023-04-11 23:32:57 +08:00
|
|
|
|
但是由于`frida`过于知名,导致大多数情况下,开发者们都会对其进行检测,所以在使用时常常会面临各种反制手段导致无法进行下一步的分析。为了能够躲避检测并继续使用`JniTrace`,逆向人员将其迁移到了更隐蔽的类`Xposed`框架中(例如`LSPosed`)。
|
2023-03-13 21:09:47 +08:00
|
|
|
|
|
2023-04-11 23:32:57 +08:00
|
|
|
|
而对比`Hook`的方案来说,从`AOSP`中修改,则完全不存在有`Hook`的痕迹,但是相对而言,开发也更沉重一些,因为需要对系统有一定的理解,并且需要重复的编译系统来进行测试。
|
|
|
|
|
|
|
|
|
|
在这一章的实战中,将讲解如何从`AOSP`的角度完成`JniTrace`这样的功能,并且使用配置进行管理,让其仅对目标进程生效,仅对目标`native`函数生效。
|
|
|
|
|
|
2023-04-13 22:21:53 +08:00
|
|
|
|
在前文讲解`RegisterNative`的输出时,注意到当时的处理将会对所有的进程生效,导致输出过于庞大,在,优化的处理也是从一个配置中,获取到当前进程是否为目标进程,才进行对应的打桩输出。在这个例子中的配置管理同样适用该优化。
|
2023-04-11 23:32:57 +08:00
|
|
|
|
|
2023-04-13 22:33:24 +08:00
|
|
|
|
##
|
2023-03-13 21:09:47 +08:00
|
|
|
|
|