APP客户端之逆向工程防护

逆向工程防护概述

逆向工程是指通过分析软件的二进制代码或运行行为，来还原其逻辑结构、算法实现或敏感信息的过程。在移动App开发中，逆向工程常被用于破解、篡改、盗版、注入恶意代码等攻击手段。因此，加强逆向工程防护是保障App安全的重要环节。

1.应用完整性检测

检测项描述

Android应用在编译后会将其代码、资源文件、配置文件打包成APK文件，APK文件的格式为zip包，任何人均可通过解压的方式获取其内部文件。如果不对内部文件进行完整性校验，攻击者可能会对APK包中的资源文件、代码文件进行篡改（插入恶意代码、木马、后门、广告等），重新签名并且发布，并使用钓鱼的方式对终端用户进行攻击。

测试详情

1.利用apktool解包

1

java -jar apktool_2.9.0.jar d base.apk -only-main-classes

app能够被解包不代表应用完整性存在问题，我们需要修改解包出来的文件，如资源文件（常使用APP图标文件来验证应用完整性）

应用完整性指的是：App 在运行时能否检测自身是否被篡改、重打包、注入或调试。

2. 将app的图标文件修改后重新打包，并安装

如何确定 App 使用的是哪个图标？

查看**AndroidManifest.xml**这个文件

1
2
3


android:icon="@mipmap/ic_launcher"         就是android图标位置
对应解包后文件的res目录下以mipmap开头的文件
-hdpi/-mdpi/-xhdpi表示不同手机分辨率使用的图标

更改里面的图片或涂改都可以，文件名别变就行，使用apktool重新打包APK

1

java -jar apktool_2.9.0.jar b base -o new1.apk

打包完成后重新安装运行，看能否正常运行，正常运行存在风险

大部分都无法安装，因为修改文件后破坏了APP原有的签名，****而 Android 系统要求所有 APK 必须使用有效证书签名后才能安装。

2. 应用签名校验检测

检测项概述

Android系统使用JAR包的签名机制对APK进行完整性保护，确保APK在不安全的网络传输时的完整性得到保护。但Android系统没有对数字签名的颁发者进行管理，任何人都可以生成数字签名，并使用该签名对APK包进行重新签名。如果App本身不对自身的签名来源进行有效的完整性检查，攻击者可以篡改应用（插入恶意代码、木马、后门、广告等），重新签名并且二次发布，导致应用程序完整性被破坏。

测试详情

1.查看原签名信息

1

keytool.exe -printcert -jarfile D:\Tools\Android\APKTOOL\base.apk

2.使用签名工具对APK进行重签名并安装到手机上

3.查看重新的签名

1

keytool.exe -printcert -jarfile D:\Tools\Android\APKTOOL\new.apk

4.安装到手机看是否能正常运行

3. DEX代码加密程度检测

检测项概述

App在发布的时候并没有对classes.dex文件进行保护。classes.dex是Android App的可执行文件，包含了编译后的Java代码的字节码。由于没有对该文件进行加密，使用工具可以将字节码还原成Java代码。攻击者可以轻松的获取App客户端所有的业务逻辑代码，并发起其他攻击，如二次打包、植入恶意代码、WebApi逆向等。

测试详情

1.使用JADX反编译查看APP，发现可以查看APP的主函数，且其可以被反编译为可读性较强的JAVA代码

只要能够反编译就存在风险

修复建议

建议对应用进行加固保护。

4. DEX动态调试检测

DEX 动态调试检测是 Android App 客户端安全防护中的关键一环，目的是防止攻击者通过动态调试工具（如 Frida、Xposed、JDB、GDB 等）在运行时分析、篡改或 Hook 应用逻辑。

检测项概述

在应用的开发的过程中，开发者可以通过调试快速定位到对应的问题代码位置。同样的，攻击者对应用进行动态调试后可以了解应用的执行逻辑，快速定位关键代码的位置，同时攻击者可以在调试过程中动态修改关键位置代码，导致某些限制措施被绕过，或者运行时的各类信息泄露。

测试详情

1.确认app是否能够被调试

1
2
3
4


1：如果应用的AndroidManif.xml文档中设置了android:debuggable:true
那么标志了这个应用是可以被调试的。可以通过解包apk之后，修改这个标志位，再重打包重签名
但是应用一般会有防护手段，无法完成这种操作apktool解包后查看AndroidManif.xml文档
中设置了android:debuggable:true那么标志了这个应用是可以被调试的

**2.如果应用不能直接被调试，如何进行调试
**如图所示表示没有调试权限，需要切换成root后开启调试权限

1
2
3
4
5
6


https://www.cnblogs.com/r1char/p/13131516.html
adb shell                                今日shell环境
su root                                 切换为高权限用户
magisk resetprop ro.debuggable 1        设置为1表示可调试
getprop ro.debuggable                    查看ro.debuggable
stop;start                              重启应用

以调试模式启动应用：使用以下命令启动应用

1

adb shell am start -D -n cn.gov.zcy.gpcclient/cn.gov.zcy.gpcclient.ui.activity.ZcyMainActivity

使用adb进行端口转发

使用jdb连接该端口，即可使用jdb相关命令对应用进行调试，发现可以进行调试

1

jdb -connect com.sun.jdi.SocketAttach:hostname=127.0.0.1,port=12345

修复建议

对应用进行远程调试，需要要在手机中运行android_server、gdbserver、gdb等进程，建议在应用运行中遍历系统进程，检测是否存在对应的进程名，如果发现存在对应的进程名即可确定应用被调试，及时退出应用。

5.Native层代码加固检测

Native 层代码加固检测 是 Android App 安全防护中的高阶环节，主要用于评估 C/C++ 编写的 **.so** 动态库是否经过有效保护，防止攻击者通过 IDA Pro、Ghidra、Radare2 等工具进行静态反编译或动态调试，从而窃取核心算法、密钥或业务逻辑。

检测项概述

App在发布的时候没有对核心的SO库进行加密、加壳或混淆等加固处理。SO中包含了编译后的机器码，由于没有对该文件进行加固保护，使用工具可以将字节码还原成类C代码，由此可导致关键业务代码逻辑暴露，存在风险。

测试详情

1.对应用解压缩后，找到应用调用的SO文件，如下图中所示：

一般在lib目录下，我们要找APP本身的.so文件而不是第三方SDK的.so文件

直接使用AI判断哪些是应用自身的.so文件，如果没有则安全，或者**查看 **AndroidManifest.xml** 中是否有 **nativeLibrary** 配置**

1
2
3


<application ...>
    <meta-data android:name="android.app.lib_name" android:value="myapp_native"/>
</application>

2.如果找到应用自身的so文件那么使用Ghidra对应用so文件进行分析，发现可以分析得到清晰的伪代码

6.Nativie层动态调试检测

检测项概述

App没有使用反调试技术对运行时的程序进行保护。攻击者可以通过动态调试的方法，对App进行逆向、跟踪等。同时，攻击者还可以利用调试技术，在运行时的App内存中注入恶意代码，达到截获运行时数据的目的，此举可能导致用户的隐私信息被窃取。

测试详情

1.将移动设备对应架构的gdb_server上传至设备中，授予权限，确认应用进程，使用gdb_server attach对应进程，并监听在12345端口：

https://github.com/topjohnwu/FrankeNDK/blob/master/prebuilt/android-arm64/gdbserver/gdbserver

1

./gdbserver :12346 --attach 27362

2.将PC本地端口转发至jdwp，并使用gdb连接该端口，选择不需要下断点连接

1
2


adb forward tcp:12346 tcp:12346
adb forward --list       # 查看Android端口映射

3.如下图连接成功，此时即可执行各类调试命令进行调试

1
2


set architecture aarch64      # 针对ARM64设备
target remote :12344

https://gitee.com/David-CrossTools/aarch64-none-linux-gnu/blob/master/bin/aarch64-none-linux-gnu-gdb.exe

查看app堆栈信息

1
2
3
4


 info reg               #查看应用寄存器

使用am命令启动该服务，发现应用正常运行
am startservice -n cn.gov.zcy.gpcclient/com.zcy.gov.log.service.LogReportService

修复建议

7. 动态注入检测

检测项概述

测试详情

1.在设备中启动frida-server

2.使用frida-trace -U -i “read*” -i “recv*” cn.gov.zcy.integration.client:channel，追踪应函数调用，如下图，可导出文件

测试结果

中风险

修复建议

对应用进行加固保护，并启用防注入策略。

8. 模拟器检测

检测项概述

Android模拟器是指运行在电脑中的虚拟设备，可以预览、开发和测试APP。在模拟器中运行，可能带来如下安全风险：模拟多个设备，进行虚假注册、刷单、薅羊毛等；模拟虚假位置，发送位置欺骗信息；适用于大多数的外挂程序，导致用户挂机刷任务，破坏APP的公平性；存在后台程序，导致用户在模拟器中输入的敏感数据（APP账号和密码等）被窃取。

测试详情

1.在模拟器中安装应用运行，发现应用未对用户进行提示：

测试结果

低风险

修复建议

对用户的运行环境进行检测，并进行提示。

9. Root环境检测

检测项概述

应用运行的终端可能被攻击者获取ROOT权限。攻击者可以随意访问获取了ROOT权限的设备中任意应用储存的任何数据，存在数据泄露、数据非法篡改等风险。

测试详情

1.在获取了root权限的终端上安装运行应用，发现未提示用户设备已获取ROOT权限：

测试结果

低风险

修复建议

对用户的运行环境进行检测，并进行提示。

Bypass root

https://github.com/LSPosed/LSPosed.github.io/releases/

插件介绍
- Shamiko是Magisk的一个插件，主要用于在Android设备上实现更隐蔽的root权限管理
- 它能够配合Magisk Hide等机制，隐藏root痕迹，防止被银行、支付类等应用检测到已root，从而确保这些应用可以正常运行
- Shamiko的特点是无需将应用添加到Magisk的“隐藏”列表中，而是通过更底层的Zygisk注入方式动态隐藏，使用起来更加灵活和高效
- 补充：Zygisk是Magisk 提供的一种高级技术，它能在手机系统启动时、应用程序刚打开的瞬间就悄悄介入，对App的运行环境进行修改，可以把它想象成一个“幕后操控者”，在每个App出生（启动）的那一刻就对其进行调整，比如：隐藏Root痕迹或添加新功能，像 Shamiko、LSPosed这些功能强大的模块都依赖它才能工作

1

adb push Shamiko-v1.2.5-414-release.zip /sdcard/