但是注意，该API只能实现一次性的监控，不能持久化

本质上是将目标内存页设置为不可读写，这样在发生读写行为时会触发事先注册好的中断处理函数，其中会调用到用户使用 gum_memory_access_monitor_new 注册的回调方法中

如何实现持久性监控呢？网上有一些相关项目：

ARM架构下的

GitHub - asmjmp0/fridaMemoryAccessTrace: android memory access trace utility powered by frida framework

X86架构下的

GitHub - revercc/fbkpt: frida 设置软件断点和内存读写断点

在Frida 16.5.0 Released的发布中，frida添加了硬件断点的实现，其说明如下：

Some of you may have found yourself in a situation where a piece of data in memory looks interesting, and you want to locate the code responsible for it. 

You may have tried Frida’s MemoryAccessMonitor API, but found the page granularity hard to work with.

To address this, hsorbo and I implementing support for hardware breakpoints and watchpoints. The long story short is that thread objects returned by Process.enumerateThreads() now have setHardwareBreakpoint(), setHardwareWatchpoint(), and corresponding methods to unset them at a later point. These are then combined with Process.setExceptionHandler() where you call the unset method and return true to signal that the exception was handled, and execution should be resumed.

翻译：

你们中的一些人可能遇到过这样的情况：内存中的一段数据看起来很有趣，而你想要找到生成它的代码。你可能尝试过使用Frida的MemoryAccessMonitor API，但发现其页面粒度难以操作。

为了解决这个问题，hsorbo和我正在实现对硬件断点和监视点的支持。简单来说，现在由Process.enumerateThreads()返回的线程对象有了setHardwareBreakpoint()、setHardwareWatchpoint()以及相应的取消设置方法，这些方法可以在稍后使用。然后，这些功能与Process.setExceptionHandler()结合使用，在其中调用取消方法并返回true，以表明异常已被处理，程序应该继续执行。

相关示例也在发布的链接上有实现。

其过程如下：

使用`Process.enumerateMallocRanges()`扫描堆内存中的“50”，打出子弹后，匹配扫描结果中的“49”，确定子弹存储地址对子弹存储地址下硬件断点，当有汇编对子弹存储的地址 rwx 时则会抛出异常，打印该处汇编的地址

找到修改子弹的汇编地址之后就方便了，在native层的汇编插桩读取rax

或者进一步实现patch功能

[培训]科锐逆向工程师培训第53期2025年7月8日开班！