|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
不在export。whale多搜索了两个段：gnu_nbucket_, nbucket_,symtab_, 而dlsym只搜索了symtab_ |
|
|
GetDexFile，用ida看的话，没有export，但是ida可以解析到这个函数。所以理论上是可以计算出函数地址的 |
|
|
|
|
|
|
|
|
刚刚发布的不知道为啥显示不出来。 首先这个是实践测试过的哈，目前我在sailfish Android8.0和小米9，Android9.0两个机型上面正常测试通过。 关于偏移错误这个，我通过编译aosp，在sailfish GetDexFile函数里面打印了DexFile对象的地址，然后hook调用之后也打印了DexFile对象地址，日志上这两个地址是一样的。这个看看你能不能给一个手机或者什么场景复现下。 和virtualXposd或者Epic冲突。。。貌似这个脱壳机并没有真的依赖ArtHook的什么功能，我常用的破解环境也是基于Sandhook的定制版本。我并没有发现Sandhok有对ArtMethod->Invoke有hook。一个是常规的inlinehook，一个是java的arthook，两个框架并没有直接影响才对啊。然后你说的SandVXP底层也是SandHook，讲道理底层和我的环境也是一套。 我之前测试过，如果同是arthook，两个hook框架同时工作会崩溃。比如sandhook和xposed。但是inlinehook貌似一般都可以被二次hook，这个我遇到过很多app，目前没有发现在inline hook层面两个hook框架不兼容的。然后，文章脱壳机代码，不依赖arthook功能，只依赖inlinehook |
|
|
inline hook在sandhook-native确实会崩溃，epic也是。推荐简单一点的方法，java把method传进去，硬偏移加4写死即可。 |
|
|
另，偏移错误纯粹是因为resolve_symbol的问题，有的机型会有问题（vivo x50pro和我自己的redmi note 4x，其中redmi是第三方基于原生10的固件）。反而有时候dlsym是正确的，resolve出来的地址是错的。 |
|
|
不理解，你没有回答我的问题。所谓崩溃到底是arthook导致的崩溃，还是inlinehook导致的崩溃。 偏移错误是whale计算GetDexFile地址错误，还是artmethod成员属性偏移计算错误。 |
|
|
artmethod 在 二次inlinehook以后 执行到函数地址 崩溃（跟指令修复有关）。 地址计算错误，不是成员偏移。 我想表达的主要是项目可以更简单一些的，不用做的太复杂。 |
|
|
artmethod我的hook点，不是sandhook的hook点啊。这个地方不存在二次inlinehook。 地址计算我就调用了一下whale，这里应该不至于导致复杂吧。当然artmethod的偏移，抄了sandhook，确实导致复杂了。不过这也是为了 兼容性。实际上sandhook这段代码兜底策略都有很多适配： uint32_t accessFlag = getIntFromJava(jniEnv, sandSandHookClass,
"testAccessFlag");
if (accessFlag == 0) {
accessFlag = 524313;
//kAccPublicApi
if (SDK_INT >= ANDROID_Q) {
accessFlag |= 0x10000000;
}
}
int offset = findOffset(p, getParentSize(), 2, accessFlag);
if (offset < 0) {
if (SDK_INT >= ANDROID_N) {
return 4;
} else if (SDK_INT == ANDROID_L2) {
return 20;
} else if (SDK_INT == ANDROID_L) {
return 56;
} else {
return getParentSize() + 1;
}
} else {
return static_cast(offset);
}更简单的方案，方便贴代码看看么？ |
|
|
|
|
|
|
|
|
没有，我认为没有执行过的代码不需要实现脱壳。所以我没有构造主动调用 |
