android_os

第28章:逆向工程与安全研究

逆向工程是Android安全研究的核心技术,它不仅帮助我们理解恶意软件的行为,还能发现系统漏洞、验证安全机制的有效性。本章将深入探讨Android平台的逆向技术,从APK结构分析到系统级调试,从模糊测试到漏洞挖掘,全面覆盖安全研究所需的关键技术。与iOS的封闭生态不同,Android的开放性为逆向工程提供了更多可能,但也带来了独特的挑战。

APK逆向技术

APK文件结构深度剖析

APK(Android Package)本质上是一个ZIP压缩包,但其内部结构经过精心设计以支持Android的安全和性能需求。标准APK包含以下关键组件:

META-INF目录存储签名信息,包括MANIFEST.MF(清单文件)、CERT.SF(签名文件)和CERT.RSA(证书文件)。Android使用JAR签名机制的变体,支持v1(JAR签名)、v2(APK签名方案v2)、v3(APK签名方案v3)和v4(增量签名)多种签名版本。MANIFEST.MF包含所有文件的SHA-256摘要,CERT.SF包含MANIFEST.MF的签名,而CERT.RSA包含开发者证书和对CERT.SF的数字签名。这种多层签名结构确保了APK内容的完整性和来源的真实性。

classes.dex文件是Dalvik字节码的容器,采用特殊的文件格式优化移动设备的内存使用。DEX文件头包含魔数”dex\n035\0”或更高版本号,随后是文件校验和、SHA-1签名、文件大小等元数据。与Java的class文件不同,DEX将所有类的常量池合并,显著减少了冗余。DEX文件的主要区段包括:

resources.arsc是编译后的资源表,采用二进制格式存储所有资源的索引。该文件使用chunk-based结构,包含字符串池、资源类型规范和资源配置信息。主要chunk类型包括:

每个chunk都有标准的头部结构,包含类型、头部大小和chunk大小。通过分析resources.arsc,可以理解应用如何组织和引用资源,以及如何支持多语言、多分辨率等配置。

AndroidManifest.xml在APK中以二进制XML格式存储,使用Android Binary XML (AXML)编码。这种格式将字符串集中存储在字符串池中,通过索引引用,既节省空间又提高解析效率。AXML的主要结构包括:

其他重要组件

DEX反编译原理与工具

DEX反编译的核心挑战在于从寄存器机字节码恢复到高级语言表示。Dalvik/ART虚拟机使用基于寄存器的架构,与JVM的栈机架构有本质区别。

Dalvik字节码特性

反编译过程通常包括以下步骤:

  1. DEX解析:读取DEX文件结构,提取类定义、方法定义、字段定义等元数据
    • 解析header_item获取文件布局信息
    • 读取string_data_item构建字符串表
    • 解析type_id_item、proto_id_item等建立类型系统
    • 处理class_def_item获取类的完整定义
  2. 指令解码:将Dalvik字节码指令转换为中间表示(IR)
    • 识别指令格式(10x、12x、22x等)
    • 提取操作码和操作数
    • 处理伪指令如packed-switch、sparse-switch
    • 解析调试信息(局部变量名、行号等)
  3. 控制流重建:通过分析跳转指令构建控制流图(CFG)
    • 识别基本块边界(跳转目标、条件分支等)
    • 构建前驱后继关系
    • 识别循环结构(自然循环、不可规约循环)
    • 处理异常处理器的控制流
  4. 类型推断:基于指令语义和寄存器使用推断变量类型
    • 数据流分析追踪寄存器类型
    • 利用方法签名信息
    • 处理φ函数解决SSA形式下的类型合并
    • 推断泛型类型参数
  5. 代码生成:将IR转换为Java或Smali代码
    • 表达式重建(将寄存器操作转为表达式树)
    • 控制结构恢复(if-else、while、for等)
    • 变量命名和作用域分析
    • 代码美化和优化

主流工具的实现策略各有特色:

apktool专注于资源解码和Smali反汇编,保持了与原始字节码的一对一映射关系。它使用baksmali/smali工具链,能够精确地反编译和重新编译DEX文件。主要特点:

jadx采用更激进的反编译策略,尝试生成可读性更好的Java代码。它实现了复杂的模式匹配算法,能够识别常见的编程模式并生成相应的高级语言结构:

dex2jar将DEX转换为JAR格式,使得可以使用成熟的Java反编译器。这种方法的优势是可以利用Java生态系统的工具,但可能丢失一些Android特有的信息:

其他专业工具

资源文件解析与修改

Android资源系统的复杂性为逆向工程带来挑战。资源编译过程将人类可读的XML转换为高效的二进制格式,逆向时需要还原这一过程。

AXML解析需要理解其chunk-based结构:

AXML文件结构详解:

每个标签包含的属性信息结构:

9-patch图片是Android特有的可拉伸图片格式:

技术细节:

9-patch编译过程:

资源混淆是常见的保护手段:

混淆技术分类:

  1. 文件名混淆
    • 将res/drawable/icon.png改为res/a/b.png
    • 使用短路径减少APK大小
    • 保持资源ID不变,仅改变文件路径
  2. resources.arsc混淆
    • 修改字符串池中的资源名称
    • 添加无效的type或entry误导解析
    • 使用非标准的chunk排列顺序
    • 插入冗余数据增加分析难度
  3. 资源ID混淆
    • 修改资源ID的packageId部分(默认0x7f)
    • 使用动态资源加载绕过静态分析
    • 将资源打包到assets并运行时解密

高级资源保护技术

  1. 资源加密
    • 对关键资源文件进行AES加密
    • 运行时解密到内存使用
    • 使用自定义Resources类拦截资源加载
  2. 资源完整性校验
    • 计算资源文件的哈希值
    • 存储在.so文件或混淆的Java代码中
    • 运行时验证防止资源替换
  3. 动态资源加载
    • 从服务器下载资源包
    • 使用DexClassLoader加载外部资源
    • 实现资源热更新机制

资源修改工具和技术

  1. aapt/aapt2:Android官方资源编译工具
    • 可以单独编译资源文件
    • 支持增量编译提高效率
    • aapt2提供更好的错误信息和性能
  2. 资源编辑器
    • APK Editor:图形化资源编辑
    • ArscEditor:直接编辑resources.arsc
    • ResGuard:微信开源的资源混淆工具
  3. 自动化修改
    • 使用脚本批量替换资源
    • 基于规则的资源注入
    • 保持资源引用的一致性

签名验证机制绕过

Android的签名机制经历了多次演进,每个版本都在前一版本基础上增强安全性:

v1签名(JAR签名)

v2签名(APK签名方案v2)

v3签名(APK签名方案v3)

v4签名(增量安装签名)

签名验证流程分析

PackageManagerService中的关键验证点:

  1. PackageParser.collectCertificates():收集签名信息
  2. PackageManagerService.verifySignatures():验证签名
  3. ApkSignatureVerifier:实际验证逻辑
    • 优先使用最高版本签名(v4→v3→v2→v1)
    • 验证签名链和证书有效性
    • 检查签名者身份一致性

绕过技术分类

  1. 系统级绕过
    • Hook PackageManagerService: ```
      • 修改verifySignatures返回值
      • 跳过checkSignatures调用
      • 替换证书比较逻辑 ```
    • 修改系统framework:
      • 编译自定义framework.jar
      • 修改services.jar中的验证代码
      • 需要root权限和系统重启
  2. 应用级绕过
    • Lucky Patcher原理:
      • 生成新的签名证书
      • 修改应用的签名检查代码
      • 对比原始签名的地方返回true
    • 核心patch点:
      • Signature.equals()
      • Signature.hashCode()
      • PackageInfo.signatures数组
  3. 运行时绕过
    • Xposed模块: ```
      • Hook getPackageInfo返回伪造签名
      • Hook checkSignatures始终返回MATCH
      • 修改Context.getPackageManager() ```
    • Frida脚本:
      • 动态替换签名验证函数
      • 修改内存中的证书数据
      • 拦截JNI调用
  4. 漏洞利用
    • Master Key漏洞:利用ZIP解析差异
    • Janus漏洞:DEX/APK双重身份
    • 签名验证逻辑缺陷:如整数溢出

高级绕过技术

  1. 时间竞争攻击
    • 在验证和使用之间替换文件
    • 利用多线程竞态条件
    • 文件系统级别的替换
  2. 内存修改
    • 直接修改已加载的DEX
    • 替换ART的oat文件
    • 修改应用的类加载器
  3. 混合攻击
    • 结合多种技术提高成功率
    • 使用加壳保护绕过代码
    • 动态下载绕过模块

防护与对抗

与iOS App逆向对比

Android和iOS在逆向工程方面存在显著差异:

可访问性:Android APK可以轻易获取和解包,而iOS IPA文件需要越狱设备或特殊工具才能提取。Android的开放性使得逆向工程门槛更低。

代码保护:iOS使用Objective-C/Swift编译为本地代码,并且App Store的应用都经过加密(FairPlay DRM)。Android的DEX字节码相对更容易分析,虽然也支持native代码保护。

运行时修改:Android的Xposed、Frida等框架可以在非root设备上工作(通过重打包),而iOS的类似工具通常需要越狱。

系统API调用:Android通过Binder进行IPC,可以通过strace等工具监控。iOS使用Mach消息和XPC,需要专门的工具如Ftrace进行跟踪。

混淆技术:两个平台都支持代码混淆,但Android的ProGuard/R8是标准配置,而iOS开发者较少使用混淆。Android的字节码混淆更成熟,但iOS的本地代码混淆可以更复杂。

系统调试方法

内核调试技术

Android内核调试是深入理解系统行为和发现内核漏洞的关键技术。由于Android基于Linux内核,许多Linux调试技术都可以应用,但Android的特殊性也带来了独特挑战。

KGDB调试:Android内核可以编译with KGDB支持,通过串口或网络进行远程调试。这需要在内核配置中启用CONFIG_KGDB、CONFIG_KGDB_SERIAL_CONSOLE等选项。调试器可以设置断点、单步执行、检查内核数据结构。但在生产设备上,KGDB通常被禁用,需要自行编译内核。

printk调试:最基础但有效的调试方法。Android扩展了Linux的printk机制,通过/proc/kmsg或dmesg读取内核日志。内核日志级别从KERN_EMERG到KERN_DEBUG,可以通过/proc/sys/kernel/printk调整。Android还添加了特定的日志标签,便于过滤。

ftrace框架:Linux内核的跟踪框架,Android对其进行了优化。通过/sys/kernel/debug/tracing接口,可以跟踪函数调用、中断处理、调度事件等。Android的systrace工具就是基于ftrace,添加了用户空间事件,实现全系统性能分析。

动态探针(kprobes):允许在运行时向内核函数插入探针,无需重新编译内核。Android内核通常启用CONFIG_KPROBES,可以通过/sys/kernel/debug/kprobes接口或使用SystemTap、eBPF等高级工具。探针可以记录函数参数、返回值、执行时间等信息。

内存转储分析:当系统崩溃时,可以通过kdump、ramoops等机制保存内存转储。Android设备通常配置了pstore/ramoops,将崩溃信息保存在持久内存中。分析工具如crash可以离线分析这些转储,重建崩溃时的系统状态。

用户空间调试

Android用户空间调试涉及多个层次,从native代码到Java/Kotlin应用,每层都有专门的调试技术。

GDB/LLDB调试:用于调试native代码,包括系统服务、HAL实现、JNI库等。Android NDK提供了gdbserver和lldb-server,可以通过adb forward建立调试连接。调试64位进程需要使用对应架构的调试器。关键挑战包括处理多线程、信号处理、动态链接等。

Java调试:通过JDWP(Java Debug Wire Protocol)协议,可以使用标准Java调试器。Android Studio的调试器是最常用的工具,支持断点、变量查看、表达式求值等。ART虚拟机的调试支持比Dalvik更完善,包括更好的优化代码调试能力。

strace/ltrace:系统调用和库调用跟踪工具。Android的strace经过修改,支持Binder调用的解析。通过strace可以了解应用的系统资源使用、文件访问、网络通信等行为。配合-ff选项可以跟踪多进程应用。

Frida动态插桩:强大的动态分析框架,支持JavaScript API进行运行时修改。可以hook Java方法、native函数、系统调用等。Frida的Android支持包括:

Xposed框架:通过修改app_process,在Zygote进程加载时注入代码。可以在不修改APK的情况下改变应用行为。主要用于:

动态分析技术

动态分析关注程序运行时行为,是静态分析的重要补充。Android平台的动态分析技术涵盖多个方面:

API监控:跟踪应用的API调用序列,理解其行为模式。可以监控:

网络流量分析:通过tcpdump、Wireshark等工具捕获网络数据包。Android的挑战包括:

沙箱执行:在受控环境中运行可疑应用,监控其行为。Android沙箱需要考虑:

污点分析:跟踪敏感数据在程序中的流动。TaintDroid是Android上的经典实现,通过修改Dalvik虚拟机实现变量级污点跟踪。现代工具如FlowDroid结合静态和动态分析,提供更准确的数据流分析。

调试器检测与反调试

应用经常实现反调试技术来对抗分析,了解这些技术对逆向工程至关重要:

调试器检测方法

反调试绕过技术

高级保护机制

Fuzzing测试

模糊测试(Fuzzing)是发现软件漏洞的有效方法,通过向程序输入大量随机或半随机数据来触发异常行为。Android平台的复杂性为Fuzzing提供了丰富的攻击面。

Android组件Fuzzing

Android的四大组件(Activity、Service、BroadcastReceiver、ContentProvider)通过Intent和Binder通信,这些接口是Fuzzing的重要目标。

Intent Fuzzing:Intent是Android组件间通信的核心机制。Fuzzing策略包括:

工具如IntentFuzzer可以自动化这一过程,通过解析AndroidManifest.xml获取组件信息,生成针对性的测试用例。高级Fuzzing还需要考虑权限约束,某些组件需要特定权限才能访问。

ContentProvider Fuzzing:ContentProvider暴露数据访问接口,常见的Fuzzing点包括:

Service Fuzzing:特别是系统服务,通过Binder接口暴露功能。Fuzzing方法:

内核接口Fuzzing

Android内核暴露多种接口供用户空间使用,这些接口的安全性直接影响系统稳定性。

系统调用Fuzzing:使用syzkaller等工具对系统调用进行Fuzzing。Android特有的考虑:

设备文件Fuzzing:/dev下的设备文件提供硬件访问接口。重点目标:

procfs/sysfs Fuzzing:这些虚拟文件系统暴露内核信息和控制接口:

Binder协议Fuzzing

Binder是Android的核心IPC机制,其复杂性使其成为漏洞的高发区域。

协议结构Fuzzing:Binder协议包含复杂的数据结构:

Fuzzing策略包括修改这些结构的字段,如引用计数、偏移量、大小等,测试内核的错误处理。

事务Fuzzing:Binder事务是客户端-服务端通信的基本单位:

对象生命周期Fuzzing:Binder对象有复杂的引用计数机制:

崩溃分析与利用

Fuzzing发现崩溃后,需要分析其可利用性。

崩溃分类

崩溃信息收集

可利用性分析

自动化利用生成:现代工具如QSYM、SAVIOR等结合符号执行和Fuzzing,不仅发现漏洞还能生成利用代码。这些工具通过:

漏洞挖掘技术

漏洞挖掘是安全研究的核心,结合静态分析、动态分析和自动化技术,可以系统地发现Android系统中的安全缺陷。

静态代码审计

静态分析在不执行代码的情况下检查程序的安全性,适合发现逻辑漏洞和编码错误。

代码模式识别:通过识别危险的编码模式发现潜在漏洞:

数据流分析:跟踪数据从输入到使用的完整路径:

Android特定审计点

工具与技术

动态污点分析

动态污点分析在程序运行时跟踪敏感数据的传播,是发现信息泄露和注入漏洞的有效方法。

TaintDroid架构:经典的Android动态污点分析系统:

污点传播规则

实现挑战

现代方案

符号执行技术

符号执行通过使用符号值代替具体输入,系统地探索程序的所有可能执行路径。

基本原理

Android应用场景

技术实现

优化策略

漏洞利用链构造

现代Android系统的安全机制使得单个漏洞很难实现完整攻击,需要构造漏洞利用链。

信息泄露 + 代码执行

权限提升链

跨进程利用

0-day利用链案例分析

自动化利用链生成

缓解机制对抗

本章小结

本章深入探讨了Android平台的逆向工程与安全研究技术。从APK文件结构和DEX反编译开始,我们了解了Android应用的静态分析基础。通过对比iOS平台,展现了Android在逆向工程方面的独特性——更开放但也更复杂。

在系统调试部分,我们覆盖了从内核到应用层的完整调试技术栈,包括KGDB、ftrace、GDB/LLDB、Frida等工具的使用。动态分析技术如API监控、网络流量分析、污点分析为运行时行为分析提供了强大支持。

Fuzzing测试部分详细介绍了Android组件、内核接口、Binder协议的模糊测试方法,以及崩溃分析和自动化利用生成技术。这些技术是发现0-day漏洞的重要手段。

漏洞挖掘技术部分涵盖了静态代码审计、动态污点分析、符号执行等高级技术,并深入讨论了漏洞利用链的构造方法。在现代Android安全机制下,单个漏洞往往不足以实现完整攻击,需要精心构造利用链。

关键要点:

练习题

基础题

  1. APK签名验证机制 分析Android的v1、v2、v3、v4签名方案的区别,并解释为什么v1签名存在安全问题。

    提示 考虑ZIP文件格式的特性,以及v1签名只保护文件内容而不保护ZIP元数据的问题。
    参考答案 v1签名基于JAR签名,只对APK中的单个文件进行签名,不保护ZIP结构本身。这导致: - 可以修改ZIP注释、对齐信息而不影响签名 - 可能存在文件名解析差异导致的攻击(如Janus漏洞) - 验证效率低,需要解压并逐个验证文件 v2签名保护整个APK(除签名块本身),在ZIP Central Directory之前添加APK签名块,验证在解析ZIP之前进行。 v3在v2基础上支持密钥轮换,通过证明链允许开发者更新签名密钥。 v4为增量安装设计,生成独立的.idsig文件包含默克尔树,支持流式安装。
  2. Binder Fuzzing基础 设计一个简单的Binder服务Fuzzing方案,说明如何获取服务接口信息并构造测试用例。

    提示 考虑使用service list命令,以及如何通过反射或解析AIDL获取方法签名。
    参考答案 Fuzzing方案步骤: 1. 使用`service list`获取所有系统服务列表 2. 通过`service call SERVICE_NAME 1 i32 0`等命令探测接口 3. 从framework.jar提取AIDL接口定义或使用反射获取方法 4. 对每个方法构造随机参数: - 基本类型:边界值、随机值、特殊值(0、-1、MAX_INT) - 字符串:空字符串、超长字符串、特殊字符 - 对象:null、畸形Parcelable数据 5. 监控logcat和tombstone捕获崩溃 6. 记录导致异常的输入用于后续分析
  3. 动态调试检测 列举至少5种Android应用检测调试器的方法,并说明如何绕过。

    提示 从/proc文件系统、系统调用、时间检测等角度思考。
    参考答案 检测方法及绕过: 1. 检查/proc/self/status的TracerPid - 绕过:Hook open/read系统调用返回伪造内容 2. ptrace(PTRACE_TRACEME)自我跟踪 - 绕过:Hook ptrace始终返回0 3. 检查调试器端口23946(gdbserver默认) - 绕过:使用其他端口或隐藏端口 4. 时间检测(调试导致执行变慢) - 绕过:Hook时间相关函数保持一致 5. 检查/data/local/tmp/下的调试器文件 - 绕过:修改调试器路径或隐藏文件 6. 检查ro.debuggable属性 - 绕过:修改系统属性或Hook属性读取

挑战题

  1. DEX文件格式解析 给定一个DEX文件的十六进制头部数据,解析其主要字段并说明各字段的作用。如何验证DEX文件的完整性?

    提示 DEX文件头包含magic、checksum、signature、file_size等关键字段。
    参考答案 DEX头部结构(前0x70字节): - 0x00-0x07: magic "dex\n035\0"或更高版本 - 0x08-0x0B: checksum (adler32) - 0x0C-0x1F: signature (SHA-1) - 0x20-0x23: file_size - 0x24-0x27: header_size (通常0x70) - 0x28-0x2B: endian_tag - 0x2C-0x4F: 各种大小和偏移量 完整性验证: 1. 检查magic number是否正确 2. 计算除magic、checksum、signature外所有数据的adler32 3. 计算除magic、checksum外所有数据的SHA-1 4. 验证file_size与实际大小匹配 5. 检查各section的偏移和大小是否合理
  2. 漏洞利用链设计 假设你发现了以下两个漏洞:(1) Chrome渲染进程的类型混淆漏洞可实现任意读写;(2) system_server的Binder整数溢出。设计一个完整的漏洞利用链实现从网页到root权限。

    提示 考虑Chrome的多进程架构、Android的权限模型、SELinux限制等。
    参考答案 利用链设计: 阶段1:Chrome渲染进程逃逸 - 利用类型混淆实现任意读写 - 泄露渲染进程内存布局(绕过ASLR) - 构造ROP链劫持控制流 - 通过Mojo IPC攻击浏览器进程 阶段2:浏览器进程到系统权限 - 在浏览器进程中执行代码 - 准备Binder事务触发system_server漏洞 - 利用整数溢出造成堆破坏 - 在system_server上下文执行代码 阶段3:权限提升到root - system_server已有system uid - 利用其特权调用内核接口 - 或寻找内核漏洞进一步提权 - 禁用SELinux获得完整root 阶段4:持久化 - 修改init.rc添加自启动服务 - 或注入到关键系统服务 - 清理利用痕迹
  3. 高级Fuzzing技术 设计一个基于覆盖率引导的Android系统服务Fuzzer,说明如何收集覆盖率信息、如何生成有效的测试用例、如何处理Binder事务的复杂性。

    提示 考虑使用AFL++的Android模式、如何hook系统服务、Binder事务的序列化格式。
    参考答案 覆盖率引导的Fuzzer设计: 1. 覆盖率收集: - 使用kcov收集内核覆盖率 - 注入SanitizerCoverage到系统服务 - 或使用Frida动态插桩记录基本块 - 通过共享内存实时传递覆盖率数据 2. 测试用例生成: - 初始种子:录制正常Binder事务 - 变异策略: * 位翻转、算术运算、块操作 * 基于Binder协议的智能变异 * 字典指导(常见命令码、字符串) - 语法感知:保持Parcel格式正确性 3. Binder事务处理: - 解析binder_transaction_data结构 - 识别不同类型的Parcelable对象 - 处理文件描述符、Binder引用 - 维护对象生命周期避免崩溃 4. 反馈循环: - 优先处理产生新覆盖的输入 - 能量分配:给"有趣"输入更多变异机会 - 崩溃去重:基于崩溃点和调用栈 - 最小化:简化触发漏洞的输入
  4. 符号执行挑战 使用符号执行技术分析一个包含复杂约束的Android Native函数,该函数验证输入的序列号格式。说明如何处理字符串操作、如何优化路径爆炸问题。

    提示 考虑字符串的符号表示、路径合并策略、约束求解器的选择。
    参考答案 符号执行方案: 1. 字符串符号化: - 将字符串表示为符号字节数组 - 为strlen、strcmp等函数建模 - 处理正则表达式匹配的约束 - 优化:具体化不影响结果的字符 2. 路径爆炸优化: - 路径合并:识别汇合点合并状态 - 剪枝:移除不可达或重复路径 - 启发式搜索:优先探索接近目标的路径 - 并行化:分布式探索不同路径 3. 约束求解优化: - 增量求解:重用之前的求解结果 - 约束简化:代数化简、常量传播 - 理论组合:结合字符串、位向量理论 - 超时处理:设置求解时限,使用具体值 4. 实际应用: - 提取验证逻辑的约束条件 - 生成有效的序列号 - 发现验证逻辑的缺陷 - 生成绕过验证的输入
  5. Android与iOS逆向对比分析 对比分析Android和iOS在以下方面的逆向工程难度:(1)应用代码保护 (2)系统API调用跟踪 (3)运行时修改 (4)内核调试。设计一个跨平台的移动应用安全分析框架。

    提示 考虑两个平台的架构差异、安全机制、可用工具等。
    参考答案 平台对比与框架设计: 对比分析: 1. 应用代码保护: - Android:DEX易分析,但支持Native代码 - iOS:本地代码+FairPlay,但缺少标准混淆 2. API调用跟踪: - Android:strace/Frida易用,Binder可解析 - iOS:需要越狱,Mach消息复杂 3. 运行时修改: - Android:Xposed/Frida/重打包 - iOS:需要越狱,Substrate/Frida 4. 内核调试: - Android:开源内核,可自编译 - iOS:闭源,需要漏洞或特殊版本 跨平台框架设计: - 抽象层:统一API钩子、内存操作接口 - 插件系统:平台特定功能模块化 - 数据模型:统一的行为描述语言 - 分析引擎: * 静态:统一的IR表示 * 动态:基于Frida的跨平台插桩 - 报告生成:标准化的安全评估报告

常见陷阱与错误

  1. 过度依赖自动化工具:工具只是辅助,深入理解原理才能有效分析
  2. 忽视反调试/反逆向:现代应用普遍采用保护措施,需要先绕过
  3. 不完整的漏洞利用:只关注崩溃而忽视完整利用链的构造
  4. 忽略上下文:逆向时只看局部代码,忽视整体架构和业务逻辑
  5. 版本差异:Android碎片化严重,不同版本的实现可能完全不同
  6. 权限和SELinux:现代Android的安全机制使得很多传统技术失效
  7. 符号信息缺失:生产版本通常去除符号,需要通过其他方式恢复

最佳实践检查清单

逆向分析前

静态分析

动态分析

漏洞挖掘

安全研究