WTF is Frida?

Frida is a Dynamic Instrumentation ToolKit

Preface

Frida (often compared to GreaseMonkey) is a reverse engineering tool developed by two brilliant people: Havard and Ole. Over time, Frida became popular and gained a group of contributors that allow it to be flexible, lightweight, and researcher/developer friendly.

Frida supports debugging on OSX, Windows, Linux, and QNX, and has an API available for a plethora of languages, including Python, C#, and C.

What's Dynamic Binary Instrumentation

DBI (Dynamic Binary Instrumentation) is a technique for analyzing running processes. It uses a host of different methods, including code injection and module loading and has proven wildly successful - giants like Microsoft and Intel have already developed their own implementations.

Although most of the DBI functionality can be achieved with a traditional debugger, the lightweight and flexibility make DBI a superior method.

First few bits of memory are copied to process memory and jump to Frida code.

The Frida API

The Frida API has two main parts: **Gum API** (a.k.a JavaScript API) and **Bindings API**.

The most popular usage of Gum API is JavaScript (hence the name), and that's the kind we'll talk about.

Gum's main purpose is attaching hooks to a process. Additional benefits include running code in a process's context. For example, we could initiate a Java function call before it even happens.

Gum's different categories correspond to different operating systems and intentions: if I'm developing for Android and I need a hook, I'll use a Java class, but if I need a(n) ARM-specific function I'll use classes that start with ARM (ArmWriter, ArmRelocator e.t.c)

The Bindings API implementation is dependent on the language Frida Client was installed in. A Python version will require Python, and Node.js will partner up with JavaScript.

Bindings's main purpose is automation: we can recreate analysis done on single cases over and over, thanks to Frida Server

This segment of code will attach itself to notepad.exe and print out all module use (DLL function calls).

Instead of joining an existing process, the code above creates a process and subsequently attaches itself.

Immediately afterward, Frida generates JavaScript code that runs alongside the process (see send function). Said code generates callback events (of Message and Event types) and continues running the process. The send function allows us to transfer information from process side (Gum API) to automation side (Bindings API). Using this information, we can decide what we want to do when our hook sees a certain result.

Frida Native

real-time function call following

As mentioned above, the moment frida-trace is run a JavaScript file is loaded that defines how Frida should react upon entering and exiting a function.In this example, we'll use the default.

The above screenshot is filled to the brim with function calls. Each color represents a different Thread.

At this stage, we want to examine function inputs and reset Frida to print the relevant variables. According to MSDN documentation, the first variable (lpFileName) is actually the file path or device that we want to open or create.

Change Input in Real-Time

To spice things up, we’ll slightly adjust our script to change the way cmd behaves. That is, every time cmd tries to open “Password1.txt” (the real file), we’ll force it to open “Password2.txt” (FAKE NEWS)

Our tweaked script looks like that. We check to see if the memory string includes certain phrases and letter and if so, we change them. Hence, every time CreateFileW, Frida will change IpFileName to our desired value.

CMD output after our tomfoolery :

Conclusion

What have we learned.

What DBI is, what it can do, and why it's better than your traditional debugger.We met Frida, a wildly powerful tool that makes our lives much much easier.How to use Frida in all sorts of different situations