Xposed Hook 钱庄 APP 常见问题及解决方案

一、问题1：为何需先 Hook 壳 Application 的 onCreate 方法再 Hook 目标类/方法

问题描述

Hook APP 内部类/方法前，需先 Hook 壳 Application（路径：com.secneo.waer.A*）的 onCreate 方法，直接 Hook 目标方法会导致失败。

根本原因

钱庄 APP 为加固包（加固壳），类加载存在“加密→解密”的特殊过程：

解决方案

将 Hook 目标方法的逻辑，置于壳 Application 的 onCreate 方法的 afterHookedMethod 中执行，确保目标类已完成解密：

// 先Hook壳的onCreate，再Hook目标方法
XposedHelpers.findAndHookMethod(
"com.secneo.***w*a**er.A*", // 壳Application类名
lpparam.classLoader, // 壳的类加载器
"onCreate",
new XC_MethodHook() {
@Override
protected void afterHookedMethod(MethodHookParam param) throws Throwable {
super.afterHookedMethod(param);
// 此时类已解密，可安全Hook目标方法
hookSendShark(lpparam.classLoader);
}
}
);

关键结论

• 加固包 Hook 最优时机：壳 onCreate 执行后 → 目标类解密完成 → Hook 目标方法，该时机稳定性最高；

• 直接在 handleLoadPackage 中 Hook 目标方法，会因获取的是“加密空壳类”，导致 Hook 无响应。

补充：未加固 APP 的 Hook 时机适配及 Application 入口查找方式

若目标 APP 无加固，无需 Hook 壳 Application，直接 Hook 系统通用 Application 基类（android.app.Application）的 onCreate 方法即可，此时类加载已完成，Hook 稳定性更高：

// 未加固APP：Hook系统Application的onCreate
XposedHelpers.findAndHookMethod(
"android.app.Application", // 通用Application基类，兼容所有未加固APP
lpparam.classLoader, // 目标APP的类加载器
"onCreate",
new XC_MethodHook() {
@Override
protected void afterHookedMethod(MethodHookParam param) throws Throwable {
super.afterHookedMethod(param);
// 未加固APP此时类已加载完成，可安全Hook目标方法
hookSendShark(lpparam.classLoader);
}
}
);

场景对比总结：

• 未加固 APP：Hook android.app.Application.onCreate，通用且稳定，无需考虑壳解密逻辑；

• 加固 APP（如钱庄 APP）：必须 Hook 壳 Application（com.secneo.waer.A*）的 onCreate，等待类解密后再 Hook 目标方法。

查找目标APP的Application入口，并非只能依赖代码层面Hook推测，还可通过以下两种方式精准定位，且两种方式获取的入口效果一致，均可作为Hook目标：

无论通过哪种方式定位到的Application入口，其核心作用均为APP启动初始化，Hook对应的onCreate方法，均可达到等待类加载/解密完成的效果，无需局限于某一种查找方式。

二、问题2：MethodHookParam 仅在 handleLoadPackage 中无报错，自定义方法中报错

问题描述

在 handleLoadPackage 方法内使用 XC_MethodHook.MethodHookParam 无报错，在自定义方法（如 hookSharkFramework）中使用时，IDEA 会出现爆红及编译报错。

根本原因

• 报错本质为导入路径错误与作用域缺失，二者共同导致 IDEA 无法识别 MethodHookParam，最终引发爆红；

• MethodHookParam 是 XC_MethodHook 的内部类，非顶级类，其作用域依赖 XC_MethodHook 类的可见性，正确导入路径为 de.robv.android.xposed.XC_MethodHook.MethodHookParam；

• 场景差异导致作用域识别差异：

  • handleLoadPackage 方法：作为 IXposedHookLoadPackage 接口的实现方法，该接口来源于 de.robv.android.xposed.callbacks.XC_LoadPackage 包。Xposed 框架初始化时，会自动关联 XC_MethodHook 相关类的作用域，且该方法运行于 Xposed 核心回调环境中，IDEA 可通过环境上下文自动识别 MethodHookParam，无需额外显式导入，因此无作用域缺失问题；

  • 自定义方法（如 hookSharkFramework）：属于手动定义的普通方法，脱离了 Xposed 核心回调环境，IDEA 无法通过上下文自动关联 MethodHookParam 的作用域。若未手动导入该类，IDEA 会判定其为“未定义符号”并爆红；若导入路径错误，也会因作用域不匹配导致识别失败。

解决方案

// 必须导入此路径，避免自定义方法中报错
import de.robv.android.xposed.XC_MethodHook.MethodHookParam;

// 自定义方法中使用MethodHookParam，需通过显式导入确保识别
private void hookSendShark(ClassLoader classLoader) {
XposedHelpers.findAndHookMethod(
"com.***.core.***.BizCls", // BizCls：业务类，承载具体功能逻辑（如sendShark为数据请求方法），非壳Application
classLoader,
"sendShark",
new Object[]{… , new XC_MethodHook() {
// 已通过全局导入识别MethodHookParam，无爆红问题
@Override
protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
super.beforeHookedMethod(param);
}
}}
);
}

关键结论

• handleLoadPackage 中无报错，因该方法为 IXposedHookLoadPackage 接口方法，Xposed 环境已自动识别相关类；

• 自定义方法中需手动导入 MethodHookParam，且确保包路径正确（无 callbacks 子包），方可避免报错。

补充：两个核心导入包的区别及适用场景

以下两个核心包功能不同，需根据开发需求针对性导入，核心区别如下：

import de.robv.android.xposed.XC_MethodHook; // 核心Hook方法类
import de.robv.android.xposed.callbacks.XC_LoadPackage; // 包加载回调类

1. de.robv.android.xposed.XC_MethodHook

作用：提供方法 Hook 的核心能力，是实现 beforeHookedMethod（Hook 前执行）、afterHookedMethod（Hook 后执行）的基础类，同时包含内部类 MethodHookParam（用于获取 Hook 方法的参数、返回值等信息）。

适用场景：解决自定义方法中 MethodHookParam 爆红问题的核心包。因 MethodHookParam 是该类的内部类，导入此类方可间接使用 MethodHookParam，避免 IDEA 爆红。

2. de.robv.android.xposed.callbacks.XC_LoadPackage

作用：提供包加载相关的回调接口和类，核心为 IXposedHookLoadPackage 接口（handleLoadPackage 方法来源于此接口），同时包含 XC_LoadPackage.LoadPackageParam 类（用于获取当前加载包的类加载器、包名等信息）。

适用场景：与 MethodHookParam 爆红问题无关，仅当需在 handleLoadPackage 中操作包加载信息（如通过包名过滤目标 APP、获取 lpparam.classLoader）时，需导入此类。

总结：导入包选择建议

• 解决 MethodHookParam 在自定义方法中爆红：仅需导入 de.robv.android.xposed.XC_MethodHook（或更精准的 de.robv.android.xposed.XC_MethodHook.MethodHookParam），无需导入第二个包；

• 操作包加载信息：需导入 de.robv.android.xposed.callbacks.XC_LoadPackage；

• 实际开发中，两个包常同时导入以覆盖 Hook 方法与包加载场景，但针对 MethodHookParam 爆红问题，核心依赖第一个包。

三、问题3：findAndHookMethod 重载函数的参数混淆（ClassLoader 是否需要传）

问题描述

findAndHookMethod 的重载函数中，第二个参数有时为 ClassLoader，有时为 String methodName，传入 ClassLoader 时出现报错，不传入则正常运行。

核心知识点：两个核心重载函数对比

常见错误场景

混淆重载函数参数的错误写法：

// 错误：传了Class对象，额外多传ClassLoader
XposedHelpers.findAndHookMethod(
sharkClazz, // Class对象（重载2的第一个参数）
classLoader, // 多余参数（重载2无此参数）
"sendShark", // 应为重载2的第二个参数，误变为第三个
new Class<?>[]{…}
);

正确写法

XposedHelpers.findAndHookMethod(
"com.***.core.***.BizCls", // 类名字符串
lpparam.classLoader, // 必须传ClassLoader
"sendShark", // 方法名
new Object[]{…}
);

XposedHelpers.findAndHookMethod(
sharkClazz, // Class对象
"sendShark", // 直接写方法名（无需传ClassLoader）
new Object[]{…}
);

关键结论

• 传入 Class 对象时，第二个参数直接写 methodName，无需传 ClassLoader；

• 传入类名字符串时，第二个参数必须传 ClassLoader，否则无法加载目标类。

四、问题4：findAndHookMethod 的 Object… args 参数格式错误（Class 数组 vs Object 数组）

问题描述

使用 new Class<?>[]{参数类型} 传递目标方法入参类型时 Hook 失败，替换为 new Object[]{参数类型+回调} 后执行成功。

根本原因

findAndHookMethod 的最后一个参数为 Object… args（可变参数），需遵循以下规则：

常见错误写法

// 错误：Class数组被当作单个参数，Xposed会查找“参数为Class数组”的目标方法
XposedHelpers.findAndHookMethod(
sharkClazz,
"sendShark",
new Class<?>[]{sharkHttpEntityClazz, Integer.TYPE, iSharkCallBack2Clazz, Long.TYPE}, // 错误：Class数组
new XC_MethodHook(){…} // 被当作第二个可变参数，非回调
);

正确写法

// 正确：Object数组中依次放入参数类型+回调
XposedHelpers.findAndHookMethod(
sharkClazz,
"sendShark",
new Object[]{
sharkHttpEntityClazz, // 参数类型1
Integer.TYPE, // 参数类型2
iSharkCallBack2Clazz, // 参数类型3
Long.TYPE, // 参数类型4
new XC_MethodHook(){ // 最后放入回调（必须在Object数组内）
@Override
protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
Log.d(TAG, "sendShark触发：" + Arrays.toString(param.args));
}
}
}
);

关键结论

• Object… args 的正确格式为：[参数类型1, 参数类型2, …, XC_MethodHook 回调]；

• 禁止用 Class[] 包裹参数类型，需将每个参数类型及回调直接放入 Object 数组中。

最终关键总结（快速查阅版）

（注：文档部分内容可能由 AI 生成）