在刚接触安卓的时候，多么希望有一款像windows上od和x64dbg那样的调试器，但是奈何能接触到的调试器太少了，好在安卓可以编译驱动，能够让我们的程序拥有内核的权限，在runtime的情况下修改内核。于是我便像学习windows调试器那样自建调试体系，制作一款不需要ptrace就能调试程序的调试器。写完基本的调试功能之后，我便寻找了一款海外的ue4手游练练手，简单地找下存储了FNamePool的基址。

    首先在ida中找到FNamePool初始化的地方，如下图：

不难猜出s就是申请的FNamePool，而s最后存储到v7中去，而v7最后来源于v2，v2来源于sub_81DB440函数的返回值。

进入到sub_81DB440里边去，如下图：

在sub_81DB440函数里边有一大堆让人眼花缭乱的计算，光看伪代码，难以找出返回值的来源。于是我选择调试这段函数，在调试前观察下返回值的来源，如下图：

最后返回值来源于[x8],而x8来源于[SP,#0xE0+var_A0]（SP+0x40处）。我只需要在调试的过程中一步一步观察SP+0x40地址处内存的变化，然后记录下导致SP+0x40处内存发生变化的指令就行了。

首先在函数头下好断点：

在单步调试的过程中，发现在如下图：在执行完0x64ecf34d638处的str x11,[x10]的指令后，SP+40就发生了变化，看下ida中的伪代码如下：

在调试的过程中这里的循环经历了三次，最后一次是对应了sp+0x40地址处的变化（好在函数体不是很大，调试起来比较轻松，sp+0x40地址处就写了这一次内存），而SP+0x40的值是来源于x10处，在进入循环之后发现x10的值来源于qwrod_E77F6A8，而经历了三次循环，在调试器中发现相当于:

[SP+0x40]=[[[qwrod_E77F6A8]]];而返回值最终为[[SP+0x40]]也就是[[[[qwrod_E77F6A8]]]],最终发现与GNamePool相关联的基地址为libUE4.so+0xE77F6A8。

    本人其实是不太会逆向UE4，也不研究外挂，此次调试游戏也只是测试下编写的调试器，如果有错误恳请诸位大佬指正。目前调试器正在开发中。

    目前调试支持的功能：

    1.设置软件断点。

    2.设置硬件断点(不使用linux的perf体系)

    3.接管程序异常（信号）。

    4.追踪线程创建、死亡、fork事件。

    5.单步调试。

    6.暂停线程(进程)。

    调试器目前不依赖信号，但是只是玩具罢了，很难用，就驱动比较稳定，估计也会遇到难以应付的场景，并且我不一定能够开发完，就当是学习一下linux内核和ARM64一些底层相关的东西了。后续会增加如何设置内存断点和追踪系统调用，考虑开放源代码。

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！