Okay, we can dump heap buffers. What’s next?

What about a sandbox-like, IOC generator & payload dumper? In its most basic version we will run a sample and our handlers will spit out all the file names of files being opened by the analyzed program. They will also dump file buffers read to and written from. And for a good measure, we will try to convert some of the file creation flags/arguments passed to the APIs so we can get a more readable log.

To dump a list of files being opened by APIs I will focus on handling CreateFileA, and CreateFileW APIs. I chose these APIs for a couple of reasons:

• They are very commonly used and are easy to test
• CreateFileA & CreateFileW exist inside kernel32.dll
• CreateFileA & CreateFileW exist inside kernelbase.dll
• you may hook them all, and you may also want to choose either of them; of course, too many hooks is not good, hence there are challenges introduced by this duplication

To test handlers (copy provided at the end of this post) just run this:

frida-trace -i RtlFreeHeap -i RtlAllocateHeap -i KERNEL32.DLL!CreateFileA -i KERNEL32.DLL!CreateFileW -i KERNEL32.DLL!WriteFile -i KERNEL32.DLL!ReadFile -f <exe> > log

Same as with buffers, we will store file handles in a table at the time file is created / opened. We will then lookup these handles at the time of file reading and writing so we can log actual file names in our logs, as opposed to just file handles. In my old sandbox I used a code inject that was relying on NtQueryObject executed in a context of a target process at the time Read/Write APIs were executed, but then again – I had to inject my code into that process, hook APIs before the malicious implant took over. Pretty complicated.

Anyway… since we can map file handles to file names we can now output the content of buffers/arguments to appropriate files (one file will store list of files/objects and the other one – actual file buffers). And for the fun of it, we will file buffers in hex + will include PID and TID, and of course a file name in our log:

The list of objects (and file handle to file name mapping) created using CreateFile APIs will be stored inside objects_list.txt file:

You may notice that some of them are 0xFFFFFFFF — these failed to open. It’s an interesting result – you will not only see existing files being accessed, but also these that don’t. Let me reiterate — these are calls to CreateFile API to access _some_ files or directories that may not be present on the system. Pretty much like Procmon, but a bit easier to read and far easier to mod the output to our needs. Such log’s value in security research cannot be overstated — it can help finding references to non-existing files, phantom libraries, anti-debugging strings e.g. device names, etc..

Finally, our attribute/flags resolution code works as well:

The screenshot below shows how this works in practice – the dwDesiredAccess’s value of 0x80000000 is translated to ‘GENERIC_READ’:

Now, before we get too excited about our ‘building our own sandbox’ experience… let me mention that there are caveats. One of them is that Frida doesn’t work all the time. For the benefit of this article, I tried to run my handlers over pafish.exe executable and… it just got stuck:

I wanted to test pafish, because it refers to a number of devices associated with guest OS devices that help to detect a virtualization:

and

– so I thought I can output all these referenced device names and show how cool the handlers can be. Then the main pafish.exe process got stuck and that’s about it. So, you have been warned.

Still, I have never worked with such rapid prototyping & hooking engine in one. It’s amazing what you can do with a few lines of JavaScript.

You can download my testhandlers from here.

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.