To support instrumenting barebone targets ranging from microcontrollers
to OS kernels. All that is required is a GDB-compatible remote stub,
such as those implemented by Corellium/OpenOCD/QEMU/etc.
The idea is to implement the same APIs as GumJS, but instead of running
JavaScript on the target, we run it on the host. Memory reads and writes
result in requests being issued to the remote stub.
To also support tiny targets with our Interceptor APIs, we implement
those using breakpoints when the callbacks are JavaScript functions.
However, if the callbacks specified are pointers, we perform inline
hooking, leveraging Gum's Relocator implementations.
This new backend should be considered alpha quality for now. Not all
features are available on non-arm64 targets yet, but this will improve
as the backend matures.
One of the particularly interesting areas for future improvement is the
notion of kernel-specific bridges -- e.g. one for Linux, another one for
XNU, etc.
The idea, if the target has an MMU, is to scan through memory looking
for kernel internals. This will allow us to find a suitable internal
memory allocator that we can use for our own needs.
It will also allow us to implement Process.enumerateModules(), to list
loaded kernel modules/kexts. Similarly we should also implement symbol
discovery where possible, and expose that through ApiResolver, so tools
like frida-trace can be used to trace kernel internals.
Co-authored-by: Håvard Sørbø <[email protected]>
