In my previous post I have demoed a simple example of Frida-based Delphi API monitor. Let’s look at one more example — this time the strings are stored in a different way, with a 32-bit length preceding the actual text which is passed via eax/edx to the utility functions e.g. LStrAsg and LStrLAsg. These 2 functions are very interesting, because they are often used to initialize strings in Delphi programs. By simply monitoring their input we can sometimes guess what the program’s functionality is.
Let’s take 0000E1A0B0CAEFD82B9E71098E92EE08FA3C47B889108B450712B4D9C3AE4D6E sample as an example. A small Delphi downloader that is not really worth any attention, but it’s perfect to demo Frida’s capabilities.
Applying Delphi Flirt signatures to the sample tells us that LStrAsg is located under 0x00403B3C (0x3B3C) and LStrLAsg is located under 0x00403B80 (0x3B80). We can create a quick&dirty handler for both of these functions – it can look like this:
onEnter(log, args, state) {
edx_len = this.context.edx.sub(4).readS32();
if (edx_len>0&&edx_len<256)
{
edx_str = this.context.edx.readUtf8String(edx_len);
console.log(JSON.stringify(edx_str));
}
},
We are taking the value of edx (second argument to both functions), read the length of the string stored as a 32-bit integer at a memory offset at (edx-4), and then we read the UTF8 string from the edx location.
If we now run Frida-trace (sample renamed to 1.exe) we get the following output:
Not bad. We can almost immediately tell there is a network connectivity (user agent) and possible destination for the downloaded payload.
Combine it with InternetOpenUrlA API monitoring (which should be done by default for any Windows binary), we get a really simple and nice answer to ‘what is this program doing?’ question — that’s what sandboxes are for, right?
frida-trace c:\test\1.exe 1.exe -a 1.exe!3B80 -a 1.exe!3B3C -i wininet.dll!InternetOpenUrlA
Yes, it is THAT simple.
Kudos to Frida developers, you have created something truly wonderful!