APK

APK（Android Package）是 Android 应用程序的安装包格式，本质上是一个 ZIP 压缩包，包含编译后的代码、资源、清单文件等

文件结构

使用解压工具打开 APK，可看到标准目录结构

1
2
3
4
5
6
7
8
9
10
11
APK/
├── AndroidManifest.xml          (二进制清单文件，需反编译)
├── classes.dex                   (Dalvik 字节码，可能有多个)
├── resources.arsc                (编译后的资源索引)
├── res/                          (资源文件，如图片、布局 XML)
├── lib/                          (原生库，按 ABI 分目录，如 arm64-v8a/)
├── META-INF/                     (签名信息)
│   ├── CERT.RSA
│   ├── CERT.SF
│   └── MANIFEST.MF
└── assets/                       (原始资产文件，可能包含 HTML、JS、DEX 等)

  • AndroidManifest.xml：声明权限、Activity、Service、Receiver、Provider 等组件

  • classes.dex：Dalvik 字节码，包含所有 Java/Kotlin 代码编译结果

  • lib/：armeabi-v7a, arm64-v8a, x86 等原生 .so 库，通过 JNI 调用

  • META-INF/：签名文件，用于完整性校验

实战案例

简单的 APK 分析（签到）

解包 APK 得到 multiprotocol.tesla.scada 文件

反编译该文件通过对比正版软件，很容易得到 flag（为混淆前的类名）

bang（梆梆壳 + Frida 动态脱壳 + Jadx 反编译）

pasted_1786202807133_7oi7ij.png

使用 APKiD 识别出加固过，用的是 SecShell/梆梆壳

  • [*] signed.apk!classes.dex*：APKiD 开始扫描 APK 包中的 classes.dex 文件（即 Java/Kotlin 字节码的核心文件）。末尾的 * 表示该文件在 APK 中处于被压缩状态，APKiD 会在内存中实时解压并扫描

  • *|-> anti_vm : possible ro.secure check：在 DEX 字节码中检测到了反虚拟机（Anti-VM）特征，具体表现为检查系统属性 ro.secure

    • ro.secure：Android 系统的只读属性。在生产环境（真机）中通常为 1

  • *|-> compiler : dexlib 2.x：检测到 DEX 文件的编译器版本标记为 dexlib 2.x

  • [*] signed.apk!lib/arm64-v8a/libSecShell.so：libSecShell.so 是百度旗下的 “SecShell” 加固壳（俗称 “百度加固”）的标志性文件名

  • |-> anti_hook : syscalls：在该 SO 库中检测到了反 Hook 机制，具体手段为直接使用系统调用

pasted_1786203271807_x80vr8.png

这里我使用的是 Genymotion 模拟器，安卓版本是 8.1，其自带 adb.exe

1
2
# 列出设备
adb devices

pasted_1786214164956_5b8x77.png

1
2
3
4
5
6
7
8
9
10
11
# 获取 Android 系统版本
adb shell getprop ro.build.version.release

# 获取首选 CPU 架构
adb shell getprop ro.product.cpu.abi

# 获取所有支持的 CPU 架构列表
adb shell getprop ro.product.cpu.abilist

# 获取当前 Shell 执行权限
adb shell id

pasted_1786214419109_9qeb3s.png

将 APK 拖进去运行

pasted_1786225528990_4q9ue9.png

然后查看对应的进程

1
adb shell ps | findstr how

pasted_1786225567345_ejo01q.png

先查壳有没有释放 dex

1
2
3
# /data/data：Android 系统规定的所有应用程序私有数据的根目录
# -type f：只查找普通文件
adb shell "find /data/data/com.example.how_debug -type f | grep -Ei 'dex|jar|apk|00081|secshell'"

pasted_1786225632983_sb3ssd.png

把缓存文件拉回电脑

1
2
3
4
5
6
mkdir dump_cache

# adb pull：拉取到电脑上
adb pull /data/data/com.example.how_debug/.cache/classes.jar dump_cache\classes.jar
adb pull /data/data/com.example.how_debug/.cache/oat/x86/classes.vdex dump_cache\classes.vdex
adb pull /data/data/com.example.how_debug/.cache/oat/x86/classes.odex dump_cache\classes.odex

pasted_1786226073395_6z5fph.png

结果发现都是被混淆加密的文件

pasted_1786226554017_tg482z.png

使用 frida 工具，提前下载好 frida-server-17.17.0-android-x86.xz，解压后把它改名成 fs 放到附件目录中

1
2
3
4
5
6
# adb push：电脑 → 手机的传输命令
adb push fs /data/local/tmp/fs
adb shell chmod 755 /data/local/tmp/fs

# 启动 Frida Server
adb shell /data/local/tmp/fs &

运行后需要开另一个终端看能不能连接上

1
2
# 测试列出进程
frida-ps -U

pasted_1786227155690_hj6g5s.png

其中 2458 how_debug 是我们的 APK

1
2
3
4
5
# frida-dexdump：基于 Frida 的动态脱壳工具
# -U：指定通过 USB 连接设备
# -p 2458：指定目标进程的 PID 为 2458
# -o dumpdex：指定输出文件夹的名称为 dumpdex
frida-dexdump -U -p 2458 -o dumpdex

成功 dump 两个 dex，分别是 classes.dex 和 classes2.dex

pasted_1786227401419_aamn1r.png

使用 Jadx 反编译拿到 flag

pasted_1786227597090_yiw9f1.png