反射是逆向工程中解析运行时行为、绕过静态混淆、还原逻辑结构的关键技术，通过程序自身暴露的元数据动态探查类、方法、字段与调用链，适用于分析ProGuard、R8等混淆后的Java/Kotlin/Android/.NET程序。
反射是逆向工程中解析运行时行为、绕过静态混淆、还原逻辑结构的关键技术。它不依赖源码，而是通过程序自身暴露的元数据动态探查类、方法、字段与调用链，特别适用于分析经过ProGuard、R8、Dotfuscator或自定义混淆处理的Java/Kotlin/Android/.NET程序。
反射如何突破常见代码混淆
混淆工具通常重命名类名、方法名、字段名，但不会（也无法）彻底擦除JVM/.NET运行时所需的元信息。反射正是利用这些残留的结构化数据实现“反向解构”：
- 类名被改为a、b、c，但
Class.forName("a")仍可加载，再用getDeclaredMethods()遍历所有方法，观察参数类型、返回值、注解等线索推测原始语义 - 私有字段被混淆后仍可通过
getDeclaredField("f1")获取并setAccessible(true)读取真实值，用于验证加密密钥、配置项或状态变量 - 反射可捕获动态生成的类（如Lambda生成的$Lambda$类、DexClassLoader加载的插件类），这类类在静态反编译中常被遗漏
实战中识别反射调用的关键特征
在Smali、IL、Java字节码或反编译后的伪代码中，反射不是“隐形”的，它有明确的API签名和模式，需重点筛查：
-
核心类调用：
Class.forName、Class.getDeclaredMethod、Method.invoke、Field.get、Constructor.newInstance - 字符串常量异常集中：大量短字符串（如"com.a.b.c"、"m3"、"setKey"）连续出现在同一方法中，且未被正常业务使用，极可能是反射目标名称
-
异常吞咽+兜底逻辑：
try-catch(ClassNotFoundException|NoSuchMethodException)包裹关键调用，说明程序预判了反射失败，属于典型混淆适配写法
结合动态调试提升反射分析效率
纯静态分析反射容易误判——因为目标类/方法可能尚未加载，或名称由运行时拼接生成。此时应联动调试器定位真实触发点：
- 在
Class.forName和Method.invoke处下断点，运行时直接观察传入的类名字符串和实际调用栈 - 对关键对象（如加密器实例）执行
obj.getClass().getDeclaredFields()并打印字段值，在LLDB/JDB/WinDbg中实时查看内存状态 - 使用Frida Hook反射API，自动记录所有
invoke调用及其参数、返回值，生成调用图谱辅助逻辑还原
绕过反射保护机制的常见思路
部分加固方案会Hook或替换反射API（如Xposed拦截Method.invoke、虚拟机层禁用setAccessible）。此时需降维应对：
- 检查是否启用了
hiddenapi策略（Android 9+），尝试通过dalvik.system.VMRuntime或sun.misc.Unsafe绕过访问限制 - 若反射调用被JNI层封装（如
nativeInvoke(String cls, String method)），需反编译so文件，定位其内部使用的FindClass/GetMethodID逻辑 - 对强校验型反射（如只接受Base64编码的类名），在调用前Hook解码函数，注入合法明文路径
