Memory buffers for… initiated, part 2 – Frida(y) edition

November 12, 2020 in Frida, Malware Analysis, Reversing, Sandboxing

In my last post I boasted about my tool that could dump memory blocks that included plain vanilla perl, or .bat code obfuscated using a number of ‘2exe’ converters. Boasting is fun, but what about trying to share the actual tool instead?

While I can’t share the tool, I can do better — in this short post I will prototype 2 Frida handlers to do the job for me and since their code is available you can not only adjust it to your needs, but also copy the ideas presented and use it to hook & dump buffers of other APIs.

I am not very well versed in modern JavaScript, I used to code in it for a living at some stage in my past, but things changed so much since that I am basically a JavaScript noob. Secondly, I am also a Frida noob. Hence, the code I am going to present you is not top notch. Still, better some than none 🙂

In my original tool I was injecting a code into a monitored process; that code would then hook RtlFreeHeap function and the hook would make a call to RtlSizeHeap at the time of memory freeing. I needed the latter to obtain the size of the memory dump I wanted to save to a file.

With Frida, I took a simpler approach. I hook RtlAllocateHeap and anytime it is called I store the returned memory address and its requested size in an internal buffer. When RtlFreeHeap is called, I simply do a lookup in a table and obtain the size from there. If the size is larger than 1MB I just truncate the buffer to 1MB. Simple, and seems to work. Note that resizing of memory blocks is not supported and will break things.

That’s it really. All you have to do is to drop these 2 handlers in __handlers__\NtDll.dll\ and run:

frida-trace -i RtlFreeHeap -i RtlAllocateHeap -f <exe>

The heap buffers will be stored in a heap_buffers.bin file.

Since I referred to rfc.exe in my previous article, let’s have a look how the tool works with this .exe — reviewing the content of heap_buffers.bin we can see:

Not bad.

The code of both handlers is here.

See part 3 here.

Comments are closed.