[原创]对某移动安全sdk的深入探究-Android安全-看雪安全社区

[原创]对某移动安全sdk的深入探究

发表于: 2025-11-24 16:29 6378

[原创]对某移动安全sdk的深入探究

bananaships 活跃值

2025-11-24 16:29

6378

# 某SDK Frida检测绕过深度分析
对一些app进行初步的分析之后发现，很多app都集成了该sdk，绕过方法网上记载的也是很多，这篇文章深入挖掘一下如何绕过检测的始末。
## 0x01 动态定位分析
这里直接选用一款使用该sdk的app作为demo展开分析，直接挂载frida之后会直接死掉，所以先检查一下是在挂载了哪个具体的so文件之后挂掉的，定位到该so文件之后挂掉了
 ![](upload/attach/202602/987777_YXZXTPMHGWZDUT6.png)
    然后需要具体定位一下是在该so文件的具体哪个地方导致的frida死掉，使用下面这段脚本，过滤到目标so之后，看是否能正常打印Jni_Onload的函数

```
function hookDlopen() {
    let linker64_base_addr = Module.getBaseAddress('linker64')
    let offset = 0x3ba00 // __dl__Z9do_dlopenPKciPK17android_dlextinfoPKv
    let android_dlopen_ext = linker64_base_addr.add(offset)
    Interceptor.attach(android_dlopen_ext, {
      onEnter: function(args){//主要逻辑是hook linker64中的do_dlopen函数，然后在该函数返回的时候检查目标检测库是否加载
        this.name = args[0].readCString()
        console.log(`dlopen onEnter ${this.name}`)
      }, onLeave: function(retval){
        console.log(`dlopen onLeave name: ${this.name}`)
                if (this.name != null && this.name.indexOf('目标so文件') >= 0) {
          let JNI_OnLoad = Module.getExportByName(this.name, 'JNI_OnLoad')
          console.log(`dlopen onLeave JNI_OnLoad: ${JNI_OnLoad}`)
        }//如果加载了目标库的话则获取该库的 JNI_OnLoad 函数地址并打印
      }
    })
  }
```
结果如下，很明显是没有走到Jni_OnLoad的，故而可以初步判断该检测是在so的**init_proc**中或者**init_array**段做的：
 ![](upload/attach/202602/987777_UP9FPKBSHYY4ATS.png)

为了进一步去判断该程序的检测退出的触发，既然挂上Frida后进程就退出，那么我们就来分析是调用哪个系统调用退出的，可以通过**strace**查看系统调用，但在执行strace时需要在dlopen加载目标so文件之前让线程sleep 10秒，以便留出strace执行时机。使用脚本如下：

```
function hookDlopen() {
    // 获取libc中的sleep函数
    let sleep = new NativeFunction(Module.getExportByName('libc.so', 'sleep'), 'int', ['int'])
    let linker64_base_addr = Module.getBaseAddress('linker64')
    let offset = 0x3ba00 // __dl__Z9do_dlopenPKciPK17android_dlextinfoPKv
//do_dlopen的offset使用命令：readelf -sW /apex/com.android.runtime/bin/linker64 | grep do_dlopen
    let android_dlopen_ext = linker64_base_addr.add(offset)
    Interceptor.attach(android_dlopen_ext, {
      onEnter: function(args){
        this.name = args[0].readCString()
        console.log(`dlopen onEnter ${this.name}`)
        if (this.name != null && this.name.indexOf('目标so文件') >= 0) {
          sleep(10) // sleep10秒留出strace执行时机
        }
      }, onLeave: function(retval){
        console.log(`dlopen onLeave name: ${this.name}`)
      }
    })
  }

setImmediate(hookDlopen)
```
上述脚本执行之后，找到目标进程的pid之后执行命令`strace -e trace=process -i -f -p "目标pid"`，挂载系统函数的调用监视
使用strace在进入目标检测so之前挂载上之后截取了目标进程的一系列系统调用，主要关注导致进程退出的系统调用，由下图可见是在进程下面的一个线程实现的闪退效果，执行了系统调用`exit_group(0 <unfinished ...>`
同时查看了目标进程中的libc的地址也与导致闪退的地址不符，这就说明这个内容是动态加载的，故而会有一个mmap创建内存的操作
 ![](upload/attach/202602/987777_HKWBHDFAKT5772B.png)

动态释放代码一定是要操作内存的，接下来我们用前面相同的逻辑，用strace查看调用了哪些和内存相关的系统调用，`strace -e trace=process,memory -i -f -p "目标pid"`，如下图，mmap一块儿内存之后执行了造成闪退的系统调用（注意：下图是再一次的启动进程打印出来的内容，故而地址与上图可能有点出入）
 ![](upload/attach/202602/987777_CD2MYVYJGCPWJZ8.png)
于是我们可以hook mmap打印一下调用栈，从而定位到在目标so文件中创建这块内存造成闪退的偏移地址

```
function hook_mmap() {//打印一下mmap系统调用的调用栈，从而追踪调用源
  const mmap = Module.getExportByName("libc.so", "mmap");
  console.log("mmap address: " + mmap);
  Interceptor.attach(mmap, {
    onEnter: function (args) {
      let length = args[1].toString(16)
      if (parseInt(length, 16) == 28) {
        console.log('backtrace:\n' + Thread.backtrace(this.context, Backtracer.ACCURATE)
                                                  .map(DebugSymbol.fromAddress).join('\n') + '\n');
      }
    }
  })
}

function hookDlopen() {
    // 获取libc中的sleep函数
    let sleep = new NativeFunction(Module.getExportByName('libc.so', 'sleep'), 'int', ['int'])
    let linker64_base_addr = Module.getBaseAddress('linker64')
    let offset = 0x3ba00 // __dl__Z9do_dlopenPKciPK17android_dlextinfoPKv
    let android_dlopen_ext = linker64_base_addr.add(offset)
    Interceptor.attach(android_dlopen_ext, {
      onEnter: function(args){
        this.name = args[0].readCString()
        console.log(`dlopen onEnter ${this.name}`)
        if (this.name != null && this.name.indexOf('目标so文件') >= 0) {
          //sleep(15) // sleep10秒留出strace执行时机
          hook_mmap()
        }
      }, onLeave: function(retval){
        console.log(`dlopen onLeave name: ${this.name}`)
      }
    })
  }

hookDlopen()
```

会发现能够打印mmap的地址，但是还没到打印使用该函数的调用栈的时候就挂掉了，此处我理解的是出现这种问题的原因是做hook的时机还是不对，我们的hook还是被检测到了
 ![](upload/attach/202602/987777_K7GJWCRARYG3AWS.png)
因此对于hook的时机问题再探究一下，这里借用一张安卓中so文件的加载图来分析一下何时hook才能实现我们的目的：
 ![](upload/attach/202602/987777_4F5N6HFSQS28VZF.png)
上图描述的更多的是一个流程，结合如下的安卓源码，我理解的是do_dlopen和call_constructors应该是包含关系，call_constructors于do_dlopen的流程内执行

```
void* do_dlopen(const char* name, int flags,
const android_dlextinfo* extinfo,
const void* caller_addr) {
    std::string trace_prefix = std::string("dlopen: ") + (name == nullptr ? "(nullptr)" : name);
    ScopedTrace trace(trace_prefix.c_str());
    ScopedTrace loading_trace((trace_prefix + " - loading and linking").c_str());
    soinfo* const caller = find_containing_library(caller_addr);
    android_namespace_t* ns = get_caller_namespace(caller);

LD_LOG(kLogDlopen,
        "dlopen(name=\"%s\", flags=0x%x, extinfo=%s, caller=\"%s\", caller_ns=%s@%p, targetSdkVersion=%i) ...",
        name,
        flags,
        android_dlextinfo_to_string(extinfo).c_str(),
        caller == nullptr ? "(null)" : caller->get_realpath(),
        ns == nullptr ? "(null)" : ns->get_name(),
        ns,
        get_application_target_sdk_version());

auto purge_guard = android::base::make_scope_guard([&]() { purge_unused_memory(); });

auto failure_guard = android::base::make_scope_guard(
    [&]() { LD_LOG(kLogDlopen, "... dlopen failed: %s", linker_get_error_buffer()); });

if ((flags & ~(RTLD_NOW|RTLD_LAZY|RTLD_LOCAL|RTLD_GLOBAL|RTLD_NODELETE|RTLD_NOLOAD)) != 0) {
        DL_OPEN_ERR("invalid flags to dlopen: %x", flags);
        return nullptr;
    }

if (extinfo != nullptr) {
        if ((extinfo->flags & ~(ANDROID_DLEXT_VALID_FLAG_BITS)) != 0) {
            DL_OPEN_ERR("invalid extended flags to android_dlopen_ext: 0x%" PRIx64, extinfo->flags);
            return nullptr;
        }

if ((extinfo->flags & ANDROID_DLEXT_USE_LIBRARY_FD) == 0 &&
            (extinfo->flags & ANDROID_DLEXT_USE_LIBRARY_FD_OFFSET) != 0) {
            DL_OPEN_ERR("invalid extended flag combination (ANDROID_DLEXT_USE_LIBRARY_FD_OFFSET without "
                "ANDROID_DLEXT_USE_LIBRARY_FD): 0x%" PRIx64, extinfo->flags);
            return nullptr;
        }

if ((extinfo->flags & ANDROID_DLEXT_USE_NAMESPACE) != 0) {
            if (extinfo->library_namespace == nullptr) {
                DL_OPEN_ERR("ANDROID_DLEXT_USE_NAMESPACE is set but extinfo->library_namespace is null");
                return nullptr;
            }
            ns = extinfo->library_namespace;
        }
    }

// Workaround for dlopen(/system/lib/<soname>) when .so is in /apex. http://b/121248172
    // The workaround works only when targetSdkVersion < Q.
    std::string name_to_apex;
    if (translateSystemPathToApexPath(name, &name_to_apex)) {
        const char* new_name = name_to_apex.c_str();
        LD_LOG(kLogDlopen, "dlopen considering translation from %s to APEX path %s",
            name,
            new_name);
        // Some APEXs could be optionally disabled. Only translate the path
        // when the old file is absent and the new file exists.
        // TODO(b/124218500): Re-enable it once app compat issue is resolved
        /*
      if (file_exists(name)) {
        LD_LOG(kLogDlopen, "dlopen %s exists, not translating", name);
      } else
      */
        if (!file_exists(new_name)) {
        LD_LOG(kLogDlopen, "dlopen %s does not exist, not translating",
               new_name);
      } else {
        LD_LOG(kLogDlopen, "dlopen translation accepted: using %s", new_name);
        name = new_name;
      }
    }
    // End Workaround for dlopen(/system/lib/<soname>) when .so is in /apex.

std::string translated_name_holder;

assert(!g_is_hwasan || !g_is_asan);
    const char* translated_name = name;
    if (g_is_asan && translated_name != nullptr && translated_name[0] == '/') {
      char original_path[PATH_MAX];
      if (realpath(name, original_path) != nullptr) {
        translated_name_holder = std::string(kAsanLibDirPrefix) + original_path;
        if (file_exists(translated_name_holder.c_str())) {
          soinfo* si = nullptr;
          if (find_loaded_library_by_realpath(ns, original_path, true, &si)) {
            PRINT("linker_asan dlopen NOT translating \"%s\" -> \"%s\": library already loaded", name,
                  translated_name_holder.c_str());
          } else {
            PRINT("linker_asan dlopen translating \"%s\" -> \"%s\"", name, translated_name);
            translated_name = translated_name_holder.c_str();
          }
        }
      }
    } else if (g_is_hwasan && translated_name != nullptr && translated_name[0] == '/') {
      char original_path[PATH_MAX];
      if (realpath(name, original_path) != nullptr) {
        // Keep this the same as CreateHwasanPath in system/linkerconfig/modules/namespace.cc.
        std::string path(original_path);
        auto slash = path.rfind('/');
        if (slash != std::string::npos || slash != path.size() - 1) {
          translated_name_holder = path.substr(0, slash) + "/hwasan" + path.substr(slash);
        }
        if (!translated_name_holder.empty() && file_exists(translated_name_holder.c_str())) {
          soinfo* si = nullptr;
          if (find_loaded_library_by_realpath(ns, original_path, true, &si)) {
            PRINT("linker_hwasan dlopen NOT translating \"%s\" -> \"%s\": library already loaded", name,
                  translated_name_holder.c_str());
          } else {
            PRINT("linker_hwasan dlopen translating \"%s\" -> \"%s\"", name, translated_name);
            translated_name = translated_name_holder.c_str();
          }
        }
      }
    }
    ProtectedDataGuard guard;
    soinfo* si = find_library(ns, translated_name, flags, extinfo, caller);
    loading_trace.End();

if (si != nullptr) {
      void* handle = si->to_handle();
      LD_LOG(kLogDlopen,
             "... dlopen calling constructors: realpath=\"%s\", soname=\"%s\", handle=%p",
             si->get_realpath(), si->get_soname(), handle);
      si->call_constructors();//！！！重点看这里！！！
      failure_guard.Disable();
      LD_LOG(kLogDlopen,
             "... dlopen successful: realpath=\"%s\", soname=\"%s\", handle=%p",
             si->get_realpath(), si->get_soname(), handle);
      return handle;
    }

return nullptr;
}
```

跟进到call_constructors函数之后会发现会先调用.init_xxxx函数，接着调用.init_array中的函数
 ![](upload/attach/202602/987777_F3YM22F573X4FEM.png)
故而我们的hook应该更精确到call_constructors，所以可以把钩子挂载在call_constructors函数处，来执行我们对目标so文件中mmap系统调用的拦截

```
function hook_mmap() {//打印一下mmap系统调用的调用栈，从而追踪调用源
  const mmap = Module.getExportByName("libc.so", "mmap");
  console.log("mmap address: " + mmap);
  Interceptor.attach(mmap, {
    onEnter: function (args) {
      let length = args[1].toString(16)
      if (parseInt(length, 16) == 28) {//过滤到28字节的创建
        console.log('backtrace:\n' + Thread.backtrace(this.context, Backtracer.ACCURATE)
                                                  .map(DebugSymbol.fromAddress).join('\n') + '\n');
      }
    }
  })
}

function hook_linker_call_constructors() {
    let linker64_base_addr = Module.getBaseAddress('linker64')
    let offset = 0x52110//此处偏移的获取使用命令: readelf -sW /apex/com.android.runtime/bin/linker64 | grep call_constructors
    let call_constructors = linker64_base_addr.add(offset)
    let listener = Interceptor.attach(call_constructors,{
        onEnter:function(args){
            console.log('hook_linker_call_constructors onEnter')
            let secmodule = Process.findModuleByName("目标so文件")
            if (secmodule != null){
                // do something
                hook_mmap()
            }
        }
    })
}

hook_linker_call_constructors();
```
结果如下，成功得到了崩溃前对应的mmap函数的调用栈
 ![](upload/attach/202602/987777_GPYSW3FFAM377CG.png)

## 0x02 静态定位分析
那么现在我们能够通过上述最后hook到的mmap调用的偏移定位到目标so中可能存在检测的位置，从而一步步往上交叉引用来进行分析，由调用栈的最顶层0x2358C可以跟到下图这个位置，可以大概看出似乎是在解密一段shellcode然后开辟内存来执行
 ![](upload/attach/202602/987777_DBV2WPVW8NXYP7C.png)
使用脚本将此执行的shellcode dump下来之后选择arm64架构进行反编译之后发现还是一段跳板，有跳转到指定地址执行的逻辑，看来是为了防止直接调用系统函数被轻易追踪到而设计。由函数sub_234E0一路交叉引用上去，其上一层有一段检查dex文件完整性的逻辑
 ![](upload/attach/202602/987777_MEJJYMM9MUR7K5U.png)
 ![](upload/attach/202602/987777_P2K9GTTKQ223NN3.png)
继续由函数sub_11FA4往上回溯，发现于函数sub_19E0C中出现一段无限循环持续检测设备是否处于ADB调试模式的逻辑，当在 sub_19E0C 函数中检测到ADB调试模式时，会调用sub_17C8C和sub_19A58这两个函数进行进一步的环境验证，如若被检测出来了的话直接走我们刚刚交叉引用上来的闪退逻辑
 ![](upload/attach/202602/987777_EANUC86BWG3F6M7.png)
继续往上回溯，发现下面第二张图中调用了sub_19E0C，但是调用的方法有点奇怪，是作为v24函数的参数进行使用的，同时该段通过动态解密的操作，使用解密后的第一个字符串作为库名，调用dlopen动态加载该库，使用解密后的第二个字符串作为函数名，调用dlsym获取该函数地址，同时最后获取到的函数使用了sub_1B8D4和sub_19E0C作为参数，sub_19E0C是我们回溯上来的引线
 ![](upload/attach/202602/987777_UYQEFKKMBK563SP.png)
 ![](upload/attach/202602/987777_B2YF34NN2N9RBE3.png)
所以这里要搞懂这个函数中做了一件什么事，就得知道它调用dlsym获取了哪个函数的地址，从而进行使用，使用下列frida的脚本进行hook，同样是在call_constructors处做挂载

```
function hook_do_dlsym() {
    // 1. 获取 linker64 基址
    const linker = Process.arch === "arm64" ? "linker64" : "linker";
    const base = Module.getBaseAddress(linker);
    if (!base) {
        console.log("[!] Cannot find linker base.");
        return;
    }
    // 2. do_dlsym 偏移
    const offset = 0x3c5b0;//使用命令readelf -sW /apex/com.android.runtime/bin/linker64 | grep do_dlsym
    const do_dlsym_addr = base.add(offset);
    // 3. Hook 函数
    Interceptor.attach(do_dlsym_addr, {
        onEnter(args) {
            try {
                // args[1] 是符号名 char*
                let symPtr = args[1];
                let symname = symPtr.readCString();

console.log(`[do_dlsym] symbol = ${symname}`);
            } catch (e) {
                console.log("[error] readCString failed:", e);
            }
        }
    });
}

function hookdoDlopen() {
    // 获取libc中的sleep函数
    let linker64_base_addr = Module.getBaseAddress('linker64')
    let offset = 0x3ba00 // __dl__Z9do_dlopenPKciPK17android_dlextinfoPKv
    let android_dlopen_ext = linker64_base_addr.add(offset)
    Interceptor.attach(android_dlopen_ext, {
      onEnter: function(args){
        this.name = args[0].readCString()
        console.log(`dlopen onEnter ${this.name}`)
      }, onLeave: function(retval){
        console.log(`dlopen onLeave name: ${this.name}`)
      }
    })
  }

function hook_linker_call_constructors() {
    let linker64_base_addr = Module.getBaseAddress('linker64')
    let offset = 0x52110//此处偏移的获取使用命令: readelf -sW /apex/com.android.runtime/bin/linker64 | grep call_constructors
    let call_constructors = linker64_base_addr.add(offset)
    let listener = Interceptor.attach(call_constructors,{
        onEnter:function(args){
            let secmodule = Process.findModuleByName("目标so文件")
            if (secmodule != null){
                // do something
                hookdoDlopen()
                hook_do_dlsym()
            }
        }
    })
}

hook_linker_call_constructors();
```
得到结果如下，很明显那么上面那段函数就是去动态获取了libc.so库中的地址，读取了函数pthread_create的地址，然后创建了两个线程，最后都有执行到闪退函数sub_234E0的逻辑
 ![](upload/attach/202602/987777_W6CGKCVT6USPK3D.png)
那么这段逻辑就稍微明了了，sub_1B924中动态解密了库名libc.so和函数名pthread_create，开创了两个检测的线程
 ![](upload/attach/202602/987777_AC23H99KQC7N67E.png)
对此处几个关键函数进行分析之后可知如下图，其中标红的三个函数中都有开创新线程执行持续扫描一些特征的操作：
 ![](upload/attach/202602/987777_SC84PMKA3RDTUFS.png)
那么此时我们继续沿着上图有三处创建新线程的框架函数继续往上回溯，发现到达了init_proc，也就是so加载之后走的第一个流程块，其中框出来的即是我们上图中的内容，因此我们可以根据造成程序异常退出的这三处创建处以及根据创建线程必走的一些系统调用来bypass掉这个检测。
 ![](upload/attach/202602/987777_3Z644QA6XR6X9J8.png)

## 0x03 bypass手段
由上述分析我们可以得知，三处创建线程逻辑的地址，分别于sub_1BEC4函数中建立，根据上文中的详细描述可以锁定到这几处：
 ![](upload/attach/202602/987777_DNN3JSDTQYW2Z89.png)
![](upload/attach/202602/987777_4T5TYVY3WRFQCEU.png)
可以知道创建线程之后执行的函数分别是sub_1B8D4、sub_19E0C、sub_1C544，故而可以直接将几个线程执行的函数直接patch掉，实现绕过，但是是有下列脚本之后还是被杀掉了

```
const patchedOffsets = new Set();
function nopFunctionEntry(module, offset) {
    const addr = module.base.add(offset);
    if (patchedOffsets.has(offset)) {
        console.log("[nopFunctionEntry] already patched 0x" + offset.toString(16));
        return;
    }
    try {
        Memory.patchCode(addr, 4, code => {
            const writer = new Arm64Writer(code, { pc: addr });
            writer.putRet(); 
            writer.flush();
        });
        patchedOffsets.add(offset);
        console.log("[nopFunctionEntry] patched 0x" + offset.toString(16));
    } catch (e) {
        console.log("[nopFunctionEntry] patch failed 0x" + offset.toString(16) + " -> " + e);
    }
}

function patch_target_addr() {
    const module = Process.findModuleByName("目标so.so");
    if (!module) return;
    nopFunctionEntry(module, 0x1B8D4);
    nopFunctionEntry(module, 0x19E0C);	//对应的三个线程执行的函数
    nopFunctionEntry(module, 0x1C544);
}

hook_linker_call_constructors();
```
![](upload/attach/202602/987777_4V8CMF4FPEPUKYF.png)
所以还是有点问题，我们继续分析，发现sub_1B8D4和sub_19E0C两个函数最终都会调用**sub_234E0**这个函数来实现闪退，那么我们直接patch掉这个函数不就等同于对这两个线程函数检测的bypass了嘛
![](upload/attach/202602/987777_VBYB4AAXZ93A9VT.png)
然后发现在线程函数sub_1C544中对应执行类似的持续扫描闪退的操作的函数应该是sub_26334函数
![](upload/attach/202602/987777_2DGC3CNHPCDZDD9.png)
![](upload/attach/202602/987777_ZT7966UKDRSUVRG.png)
有此重大发现之后可以将bypass的脚本更新为如下，如此可以最小程度上的对程序进行修改的同时实现bypass：

```
const patchedOffsets = new Set();
function nopFunctionEntry(module, offset) {
    const addr = module.base.add(offset);
    if (patchedOffsets.has(offset)) {
        console.log("[nopFunctionEntry] already patched 0x" + offset.toString(16));
        return;
    }
    try {
        Memory.patchCode(addr, 4, code => {
            const writer = new Arm64Writer(code, { pc: addr });
            writer.putRet();
            writer.flush();
        });
        patchedOffsets.add(offset);
        console.log("[nopFunctionEntry] patched 0x" + offset.toString(16));
    } catch (e) {
        console.log("[nopFunctionEntry] patch failed 0x" + offset.toString(16) + " -> " + e);
    }
}

function patch_target_addr() {
    const module = Process.findModuleByName("目标so.so");
    if (!module) return;
    nopFunctionEntry(module, 0x234E0);//直接造成检测闪退的地址
    nopFunctionEntry(module, 0x26334);//直接造成检测闪退的地址
}

hook_linker_call_constructors();
```
可以成功绕过：
![](upload/attach/202602/987777_PV2NYFT8B3EGCDB.png)

## 0x04 总结
此文分析仅代表个人见解，希望师傅们多多指正捏~
参考文章：<a href="elink@878K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6^5K9h3q4G2k6h3g2&6N6g2)9J5k6h3N6A6N6r3S2#2j5W2)9J5k6h3W2G2i4K6u0r3x3U0l9J5y4q4)9J5c8U0l9^5i4K6u0r3x3o6W2Q4x3V1k6Q4x3U0g2q4y4#2)9J5y4f1u0n7i4K6t1#2z5e0g2Q4x3U0g2q4z5q4)9J5y4f1u0r3i4K6t1#2z5o6N6Q4x3U0g2q4y4#2)9J5y4e0R3^5i4K6t1#2b7U0q4Q4x3U0g2q4y4g2)9J5y4f1p5#2i4K6t1#2z5o6N6Q4x3U0g2q4z5q4)9J5y4e0R3&6i4K6t1#2b7V1q4D9K9h3u0E0M7$3q4G2j5h3W2V1M7$3g2U0i4K6u0V1M7$3!0Q4x3U0g2q4y4#2)9J5y4e0W2m8i4K6t1#2z5o6c8r3M7X3W2V1j5g2)9J5y4f1f1$3i4K6t1#2b7e0y4Q4x3U0f1^5x3q4)9J5y4f1f1$3i4K6t1#2b7U0g2Q4x3U0f1^5b7W2)9J5c8X3W2F1k6r3g2^5i4K6u0W2K9s2c8E0L8l9`.`.">参考文章1</a>

回复或点赞可查看完整内容

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。

最后于 2025-11-29 20:26 被bananaships编辑，原因：

#HOOK注入 #逆向分析

收藏・17

点赞・111

打赏

赞赏记录

参与人

雪币

留言

时间

xinxinqing

为你点赞！

10小时前

git_51951meggadf3df

非常支持你的观点！

2026-9-11 11:44

git_37832Hesiycn

这个讨论对我很有帮助，谢谢！

2026-8-28 15:21

mb_lthgjpwj

为你点赞！

2026-8-20 17:31

Wika

这个讨论对我很有帮助，谢谢！

2026-8-8 16:11

mb_wsoacceo

为你点赞！

2026-8-7 23:13

mb_cebxltxx

为你点赞！

2026-7-18 00:49

afishlong

你的分享对大家帮助很大，非常感谢！

2026-7-14 02:23

mb_hsscwjpz

你的帖子非常有用，感谢分享！

2026-7-9 15:30

GoKu123

你的分享对大家帮助很大，非常感谢！

2026-6-2 21:23

qqizai

感谢你分享这么好的资源！

2026-6-1 14:16

mb_fxywkzle

这个讨论对我很有帮助，谢谢！

2026-5-5 15:35

下雨天sana

你的帖子非常有用，感谢分享！

2026-4-9 17:31

mb_nofqtpir

为你点赞！

2026-3-18 15:39

mb_arjunooq

感谢你分享这么好的资源！

2026-3-9 20:31

Inse

你的分享对大家帮助很大，非常感谢！

2026-3-5 11:01

trackL

为你点赞！

2026-3-4 16:59

菜小基

为你点赞！

2026-3-3 15:34

wake0p

为你点赞！

2026-2-12 15:08

老小白

期待更多优质内容的分享，论坛有你更精彩！

2026-1-22 08:59

wcisang

感谢你的积极参与，期待更多精彩内容！

2026-1-21 05:15

Mark.

期待更多优质内容的分享，论坛有你更精彩！

2026-1-16 08:35

saykao

你的分享对大家帮助很大，非常感谢！

2026-1-13 21:37

Max_hhg

感谢你的贡献，论坛因你而更加精彩！

2026-1-7 20:20

Xunflash

非常支持你的观点！

2026-1-6 16:35

mb_izfxicrp

感谢你的贡献，论坛因你而更加精彩！

2025-12-30 16:08

123hh

非常支持你的观点！

2025-12-28 17:01

mb_zpvlfkkg

感谢你的积极参与，期待更多精彩内容！

2025-12-28 01:17

爱吃菠菜

感谢你的积极参与，期待更多精彩内容！

2025-12-27 13:54

jjjo

感谢你分享这么好的资源！

2025-12-24 15:07

peterchen

谢谢你的细致分析，受益匪浅！

2025-12-17 15:31

LIU.YZ

非常支持你的观点！

2025-12-16 18:27

git_52979perfunctory

感谢你分享这么好的资源！

2025-12-16 15:42

taeyeon_ss

为你点赞！

2025-12-16 11:57

mb_womisejh

感谢你的积极参与，期待更多精彩内容！

2025-12-15 20:51

j01y

期待更多优质内容的分享，论坛有你更精彩！

2025-12-9 18:02

lucasK

为你点赞！

2025-12-7 03:20

安卓逆向test

你的分享对大家帮助很大，非常感谢！

2025-12-4 20:57

NshIdE

这个讨论对我很有帮助，谢谢！

2025-12-4 15:36

mb_gezbxltk

感谢你的积极参与，期待更多精彩内容！

2025-12-3 18:37

棕熊

为你点赞！

2025-12-2 10:23

Doorsman

非常支持你的观点！

2025-12-1 22:45

Ma5k

感谢你的贡献，论坛因你而更加精彩！

2025-12-1 14:45

wogao

谢谢你的细致分析，受益匪浅！

2025-12-1 13:34

hanhaochi

感谢你分享这么好的资源！

2025-12-1 12:21

岁月。

感谢你的积极参与，期待更多精彩内容！

2025-12-1 11:03

khacker

期待更多优质内容的分享，论坛有你更精彩！

2025-12-1 10:40

x_req

感谢你的贡献，论坛因你而更加精彩！

2025-11-30 16:13

nxlite

非常支持你的观点！

2025-11-30 04:22

mb_zfqvurgb

期待更多优质内容的分享，论坛有你更精彩！

2025-11-29 20:31

Sigil

你的分享对大家帮助很大，非常感谢！

2025-11-29 20:19

wx_funcrever

感谢你分享这么好的资源！

2025-11-29 16:30

homea_qwq

你的分享对大家帮助很大，非常感谢！

2025-11-29 16:24

wconly

谢谢你的细致分析，受益匪浅！

2025-11-29 11:02

墨穹呢

感谢你的贡献，论坛因你而更加精彩！

2025-11-28 19:56

逆天而行

谢谢你的细致分析，受益匪浅！

2025-11-28 17:02

xiaowaaa

感谢你的贡献，论坛因你而更加精彩！

2025-11-28 10:45

xianyuuuan

为你点赞！

2025-11-28 10:30

WsttXm

感谢你的贡献，论坛因你而更加精彩！

2025-11-28 10:29

熊趴趴来

感谢你的贡献，论坛因你而更加精彩！

2025-11-28 03:29

快乐的小跳蛙

为你点赞！

2025-11-27 18:58

mb_iekomvyy

感谢你的积极参与，期待更多精彩内容！

2025-11-27 13:57

Old_Yuan

期待更多优质内容的分享，论坛有你更精彩！

2025-11-27 11:31

mb_kgfqphsx

非常支持你的观点！

2025-11-27 10:44

mb_hhiypuwp

你的分享对大家帮助很大，非常感谢！

2025-11-26 23:16

SecurityEye

为你点赞！

2025-11-26 17:04

mb_awbfnjrt

感谢你的积极参与，期待更多精彩内容！

2025-11-26 16:44

令狐双

感谢你的积极参与，期待更多精彩内容！

2025-11-26 10:28

cydian

你的帖子非常有用，感谢分享！

2025-11-26 10:16

ChuXinﻬ.

谢谢你的细致分析，受益匪浅！

2025-11-26 10:07

cppasm

为你点赞！

2025-11-26 09:43

Tokameine

感谢你的积极参与，期待更多精彩内容！

2025-11-26 00:12

git_69207xiaohuihui1024

你的分享对大家帮助很大，非常感谢！

2025-11-25 22:51

mb_fvjroydy

这个讨论对我很有帮助，谢谢！

2025-11-25 22:00

龙飞雪

为你点赞！

2025-11-25 19:36

sinker_

感谢你的贡献，论坛因你而更加精彩！

2025-11-25 17:33

mb_wyefudor

你的帖子非常有用，感谢分享！

2025-11-25 16:54

falconnnn

你的帖子非常有用，感谢分享！

2025-11-25 16:27

mb_wpitiize

为你点赞！

2025-11-25 15:53

npc0vo

谢谢你的细致分析，受益匪浅！

2025-11-25 14:33

P1umH0

你的帖子非常有用，感谢分享！

2025-11-25 14:10

天水姜伯约

这个讨论对我很有帮助，谢谢！

2025-11-25 13:39

孤独的街

你的分享对大家帮助很大，非常感谢！

2025-11-25 12:26

k423

感谢你分享这么好的资源！

2025-11-25 11:55

rettozero

感谢你分享这么好的资源！

2025-11-25 10:59

git_86715adam019701

感谢你分享这么好的资源！

2025-11-25 10:35

clz3216

为你点赞！

2025-11-25 10:30

哈哥

为你点赞！

2025-11-25 10:04

mb_thmdyxrm

为你点赞！

2025-11-25 10:01

寻影星尘

为你点赞！

2025-11-25 10:01

pianpu

这个讨论对我很有帮助，谢谢！

2025-11-25 09:20

UserXCh

为你点赞！

2025-11-25 09:17

优质胖虎

你的分享对大家帮助很大，非常感谢！

2025-11-25 09:05

ONewTach

这个讨论对我很有帮助，谢谢！

2025-11-25 09:00

Ot²

谢谢你的细致分析，受益匪浅！

2025-11-25 08:49

fanfall

感谢你的积极参与，期待更多精彩内容！

2025-11-25 08:36

mb_mfjsranl

感谢你的积极参与，期待更多精彩内容！

2025-11-25 07:57

Harpe

你的分享对大家帮助很大，非常感谢！

2025-11-25 07:50

Yves Luo

期待更多优质内容的分享，论坛有你更精彩！

2025-11-25 07:21

顽劣

感谢你分享这么好的资源！

2025-11-25 03:27

git_47499test-look

感谢你的贡献，论坛因你而更加精彩！

2025-11-25 01:45

mb_bppcorlj

感谢你的贡献，论坛因你而更加精彩！

2025-11-24 21:28

mb_asiwnxyv

感谢你的贡献，论坛因你而更加精彩！

2025-11-24 20:04

mb_wdhsjycl

非常支持你的观点！

2025-11-24 19:51

mb_tmbvnlxt

感谢你分享这么好的资源！

2025-11-24 18:58

huangyalei

感谢你的积极参与，期待更多精彩内容！

2025-11-24 18:17

doduhuang

感谢你的贡献，论坛因你而更加精彩！

2025-11-24 18:00

路过1

感谢你的积极参与，期待更多精彩内容！

2025-11-24 17:21

mb_zqrczqwa

期待更多优质内容的分享，论坛有你更精彩！

2025-11-24 17:14

mb_rjdrqvpa

感谢你的积极参与，期待更多精彩内容！

2025-11-24 17:04

小傲骨

感谢你的积极参与，期待更多精彩内容！

2025-11-24 16:36

最新回复 (57) 1 2 3 ▶
LQ6H 雪币： 530 活跃值： (2622) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 80 粉丝 1 关注私信	LQ6H 2 楼 666 2025-11-24 18:52 0
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 691 粉丝 7 关注私信	mb_ldbucrik 3 楼感谢分享 2025-11-24 19:00 0
随风而行aa 雪币： 7767 活跃值： (25134) 能力值： ( LV12，RANK：550 ) 在线值：发帖 39 回帖 423 粉丝 1585 关注私信	随风而行aa 10 4 楼看看 2025-11-24 19:04 1
mb_qimctavn 雪币： 5219 活跃值： (6615) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 385 粉丝 1 关注私信	mb_qimctavn 5 楼 6 2025-11-24 19:19 0
带带弟弟吧雪币： 2 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 93 粉丝 5 关注私信	带带弟弟吧 6 楼 1111 2025-11-24 20:00 0
lrhtony 雪币： 1366 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 12 粉丝 1 关注私信	lrhtony 7 楼看看 2025-11-24 20:09 0
SomeMx 雪币： 4156 活跃值： (5534) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 158 粉丝 1 关注私信	SomeMx 8 楼学习 2025-11-25 01:22 0
Ms135 雪币： 9 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 89 粉丝 0 关注私信	Ms135 9 楼 66 2025-11-25 09:49 0
KanXue_NG 雪币： 661 能力值： ( LV1，RANK：0 ) 在线值：发帖 7 回帖 100 粉丝 66 关注私信	KanXue_NG 10 楼学习 2025-11-25 10:14 0
mb_mmlkqxal 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 27 粉丝 0 关注私信	mb_mmlkqxal 11 楼 1 2025-11-25 11:40 0
逍遥无极天雪币： 226 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 27 粉丝 0 关注私信	逍遥无极天 12 楼 11 2025-11-25 14:08 0
inono 雪币： 7 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 19 粉丝 0 关注私信	inono 13 楼学习 2025-11-25 16:10 0
hanjcn 雪币： 220 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 16 粉丝 0 关注私信	hanjcn 14 楼 666 2025-11-25 16:25 0
嘎嘎真的很棒雪币： 716 活跃值： (3787) 能力值： ( LV3，RANK：30 ) 在线值：发帖 8 回帖 161 粉丝 6 关注私信	嘎嘎真的很棒 15 楼学习 2025-11-25 17:05 0
Our_OT 雪币： 521 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 23 粉丝 2 关注私信	Our_OT 16 楼学习一下 2025-11-25 20:56 0
执着的猫雪币： 2874 活跃值： (1569) 能力值： ( LV8，RANK：120 ) 在线值：发帖 20 回帖 23 粉丝 281 关注私信	执着的猫 1 17 楼请问这个so 没有加固吗？在样本app 里，因为我分析的时候，这个so 加固了，dump 内存出来之后，sofixer 无法还原 2025-11-25 22:57 0
bananaships 雪币： 321 活跃值： (150) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 4 粉丝 12 关注私信	bananaships 18 楼执着的猫请问这个so 没有加固吗？在样本app 里，因为我分析的时候，这个so 加固了，dump 内存出来之后，sofixer 无法还原这个so里面没有业务逻辑，是做的一些反调检测，有简单的ollvm混淆 2025-11-25 23:13 0
mb_lfvhycml 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 26 粉丝 0 关注私信	mb_lfvhycml 19 楼 6666 2025-11-26 14:00 0
九黎雪币： 51 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 92 粉丝 0 关注私信	九黎 20 楼 tql 2025-11-26 17:32 0
chenwitch 雪币： 87 活跃值： (686) 能力值： ( LV3，RANK：30 ) 在线值：发帖 14 回帖 122 粉丝 2 关注私信	chenwitch 21 楼 666 2025-11-26 17:41 0
zylyy 雪币： 144 活跃值： (2723) 能力值： ( LV2，RANK：10 ) 在线值：发帖 11 回帖 490 粉丝 3 关注私信	zylyy 22 楼 666 2025-11-26 17:44 0
wx_D_755717 雪币： 16 活跃值： (418) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 15 粉丝 0 关注私信	wx_D_755717 23 楼 66666 2025-11-26 18:53 0
Aar0n 雪币： 4208 活跃值： (4099) 能力值： ( LV6，RANK：90 ) 在线值：发帖 4 回帖 39 粉丝 57 关注私信	Aar0n 2 24 楼 look 2025-11-26 19:08 0
不具名的悲伤雪币： 3 活跃值： (1790) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 123 粉丝 0 关注私信	不具名的悲伤 25 楼 6 2025-11-26 20:29 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

bananaships

发帖

回帖

RANK

关注

私信

他的文章

关于我们

联系我们

企业服务

看雪公众号

最新回复 (57) 1 2 3 ▶
LQ6H 雪币： 530 活跃值： (2622) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 80 粉丝 1 关注私信	LQ6H 2 楼 666 2025-11-24 18:52 0
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 691 粉丝 7 关注私信	mb_ldbucrik 3 楼感谢分享 2025-11-24 19:00 0
随风而行aa 雪币： 7767 活跃值： (25134) 能力值： ( LV12，RANK：550 ) 在线值：发帖 39 回帖 423 粉丝 1585 关注私信	随风而行aa 10 4 楼看看 2025-11-24 19:04 1
mb_qimctavn 雪币： 5219 活跃值： (6615) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 385 粉丝 1 关注私信	mb_qimctavn 5 楼 6 2025-11-24 19:19 0
带带弟弟吧雪币： 2 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 93 粉丝 5 关注私信	带带弟弟吧 6 楼 1111 2025-11-24 20:00 0
lrhtony 雪币： 1366 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 12 粉丝 1 关注私信	lrhtony 7 楼看看 2025-11-24 20:09 0
SomeMx 雪币： 4156 活跃值： (5534) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 158 粉丝 1 关注私信	SomeMx 8 楼学习 2025-11-25 01:22 0
Ms135 雪币： 9 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 89 粉丝 0 关注私信	Ms135 9 楼 66 2025-11-25 09:49 0
KanXue_NG 雪币： 661 能力值： ( LV1，RANK：0 ) 在线值：发帖 7 回帖 100 粉丝 66 关注私信	KanXue_NG 10 楼学习 2025-11-25 10:14 0
mb_mmlkqxal 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 27 粉丝 0 关注私信	mb_mmlkqxal 11 楼 1 2025-11-25 11:40 0
逍遥无极天雪币： 226 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 27 粉丝 0 关注私信	逍遥无极天 12 楼 11 2025-11-25 14:08 0
inono 雪币： 7 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 19 粉丝 0 关注私信	inono 13 楼学习 2025-11-25 16:10 0
hanjcn 雪币： 220 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 16 粉丝 0 关注私信	hanjcn 14 楼 666 2025-11-25 16:25 0
嘎嘎真的很棒雪币： 716 活跃值： (3787) 能力值： ( LV3，RANK：30 ) 在线值：发帖 8 回帖 161 粉丝 6 关注私信	嘎嘎真的很棒 15 楼学习 2025-11-25 17:05 0
Our_OT 雪币： 521 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 23 粉丝 2 关注私信	Our_OT 16 楼学习一下 2025-11-25 20:56 0
执着的猫雪币： 2874 活跃值： (1569) 能力值： ( LV8，RANK：120 ) 在线值：发帖 20 回帖 23 粉丝 281 关注私信	执着的猫 1 17 楼请问这个so 没有加固吗？在样本app 里，因为我分析的时候，这个so 加固了，dump 内存出来之后，sofixer 无法还原 2025-11-25 22:57 0
bananaships 雪币： 321 活跃值： (150) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 4 粉丝 12 关注私信	bananaships 18 楼执着的猫请问这个so 没有加固吗？在样本app 里，因为我分析的时候，这个so 加固了，dump 内存出来之后，sofixer 无法还原这个so里面没有业务逻辑，是做的一些反调检测，有简单的ollvm混淆 2025-11-25 23:13 0
mb_lfvhycml 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 26 粉丝 0 关注私信	mb_lfvhycml 19 楼 6666 2025-11-26 14:00 0
九黎雪币： 51 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 92 粉丝 0 关注私信	九黎 20 楼 tql 2025-11-26 17:32 0
chenwitch 雪币： 87 活跃值： (686) 能力值： ( LV3，RANK：30 ) 在线值：发帖 14 回帖 122 粉丝 2 关注私信	chenwitch 21 楼 666 2025-11-26 17:41 0
zylyy 雪币： 144 活跃值： (2723) 能力值： ( LV2，RANK：10 ) 在线值：发帖 11 回帖 490 粉丝 3 关注私信	zylyy 22 楼 666 2025-11-26 17:44 0
wx_D_755717 雪币： 16 活跃值： (418) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 15 粉丝 0 关注私信	wx_D_755717 23 楼 66666 2025-11-26 18:53 0
Aar0n 雪币： 4208 活跃值： (4099) 能力值： ( LV6，RANK：90 ) 在线值：发帖 4 回帖 39 粉丝 57 关注私信	Aar0n 2 24 楼 look 2025-11-26 19:08 0
不具名的悲伤雪币： 3 活跃值： (1790) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 123 粉丝 0 关注私信	不具名的悲伤 25 楼 6 2025-11-26 20:29 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复