编译arm64版本时出错 about dobby HOT 11 CLOSED

我也遇到同样的问题，解决方法是把platforms/backend-arm64/interceptor-template-arm64.s中所以下划线开始的label前面的下划线去掉。例如 _ctx_save 改为 ctx_save，_enter_thunk_template改为enter_thunk_template等等

from dobby.

arm32下没有这个问题

from dobby.

如果你想生成静态的 .a , 可以使用 make clean; make BACKEND=ios ARCH=arm64, 有个 asm 文件好像忘加到 Android.mk 了, 具体我再看下.

from dobby.

确实， 有个interceptor-template-arm64.s，加到android.mk里后，编译成功了，但是运行后hook, 会崩溃，我再看看，再给你反馈~

from dobby.

你是4.4版本以下的么?

from dobby.

我测试的机器是android 7.1.1, nexus 9, arm 64 cpu.

我大概是这样子做的，不知道哪里出了问题。
首先使用ndk编译出了一个arm64的libhookzz.a, 再链接到我自己用于测试的so里， 测试的so里代码是这样写的：

typedef FILE* (*ptr_func_fopen)(const char *filename, const char *mode);
ptr_func_fopen ptr_ori_func = NULL;

FILE* my_fopen(const char *filename, const char *mode)
{
    LOGD("%s, filename: %s, mode: %s", __FUNCTION__, filename, mode);
    return ptr_ori_func(filename, mode);
}

void hook_fopen()
{
    ZzEnableDebugMode();
    ZZSTATUS status = ZzHook((void*)fopen, (void*)my_fopen, (void **)&ptr_ori_func, printf_pre_call, printf_post_call, FALSE);
    LOGD("%s, status is %d", __FUNCTION__, status);
}

JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM* vm, void* reserved)
{
    LOGD("%s, begin", __FUNCTION__);
    JNIEnv* env = NULL;
    jint result = -1;

    if (vm->GetEnv((void**) &env, JNI_VERSION_1_4) != JNI_OK) {
        return result;
    }
    hook_fopen();
    FILE *file = fopen("/proc/self/maps", "r");
    fclose(file);
    // 返回jni的版本
    return JNI_VERSION_1_4;
}

运行起来后的日志：
` JNI_OnLoad, begin
ZzThunkerBuildThunk:
LogInfo: enter_thunk at 0x75f0658698, use enter_thunk_template.
ZzThunkerBuildThunk:
LogInfo: leave_thunk at 0x75f0674000, length: 240.
ZzThunkerBuildThunk:
LogInfo: half_thunk at 0x75f0673000, length: 244.
ZzBuildEnterTrampoline:
LogInfo: on_enter_trampoline at 0x75f06730f4, length: 44. hook-entry: 0x75e691cfc0. and will jump to enter_thunk(0x75f0658698).
ZzBuildInvokeTrampoline:
LogInfo: on_invoke_trampoline at 0x75f0673120, length: 36. and will jump to rest code(0x75f3d91cb8).
ArmInstructionFix: origin instruction at 0x75f3d91ca8, relocator end at 0x75f3d91cb8, relocator instruction nums 4
origin_prologue: 0xf8 0x5f 0xbc 0xa9 0xf6 0x57 0x01 0xa9 0xf4 0x4f 0x02 0xa9 0xfd 0x7b 0x03 0xa9
ZzBuildLeaveTrampoline:
LogInfo: on_leave_trampoline at 0x75f0673144, length: 44. and will jump to leave_thunk(0x75f0674000).
hook_fopen, status is 1
libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 12010 (m.myapplication)

ebuggerd: handling request: pid=12010 uid=10310 gid=10310 tid=12010
DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
DEBUG: Build fingerprint: 'google/volantis/flounder:7.1.1/N9F27M/4333998:user/release-keys'
DEBUG: Revision: '0'
DEBUG: ABI: 'arm64'
DEBUG: pid: 12010, tid: 12010, name: m.myapplication >>> test.exception.com.myapplication <<<
DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
DEBUG: x0 00000075e691cfc0 x1 0000007fc2f6a818 x2 0000007fc2f6a690 x3 0000007fc2f6a788
DEBUG: x4 0000000000000000 x5 0000000000000000 x6 00000075f5ac9000 x7 0000000000000000
DEBUG: x8 0000000000000000 x9 0000000000000024 x10 0000007fc2f6a2b0 x11 0000000000000018
DEBUG: x12 0000000000000018 x13 0000000000000000 x14 0000000000000000 x15 002a4387892727f0
DEBUG: x16 00000075f066df00 x17 0000000000000000 x18 00000000ffffffff x19 00000075f066d000
DEBUG: x20 00000075f1c7d040 x21 00000075f1c8b180 x22 00000075f0657288 x23 eee9445e84c5a9dd
DEBUG: x24 0000007fc2f6aa5c x25 00000075e6852f80 x26 00000075f1c7d040 x27 000000000010001d
DEBUG: x28 00000075f1c3fa00 x29 0000007fc2f6a990 x30 00000075f0658718
DEBUG: sp 0000007fc2f6a680 pc 0000000000000000 pstate 0000000060000000
DEBUG: backtrace:
DEBUG: #00 pc 0000000000000000
DEBUG: #1 pc 0000000000004714 /data/app/test.exception.com.myapplication-2/lib/arm64/libtest.so (enter_thunk_template+124)
`
我哪里写错了么？

from dobby.

ZzHook 返回 成功，但是执行 fopen时，崩溃了

from dobby.

这是我的 wechat: winter1ife

from dobby.

@davidlo-ghl 我试下

from dobby.

@davidlo-ghl 成功运行了, 谢了。这是怎么回事...看来，还是得研究研究...

from dobby.

可以参考一下
https://stackoverflow.com/questions/5908568/what-is-the-reason-function-names-are-prefixed-with-an-underscore-by-the-compile

from dobby.