Disassembly

From LRREW
Jump to navigation Jump to search

Disassembly in computers generally refers to the practice of taking apart binaries (such as .exe files) in order to analyze them without having access to the original source code. With regards to Roblox, disassembly of binaries is necessary in order to achieve any meaningful patching, such as hooks, modifying strings, and other necessary modification. There are two sections that will be covered in this article which are immediately relevant to Roblox:

  • Assembly language (ASM), a low-level programming language that all computers speak, and more specifically x86 assembly; assembly using the x86 instruction set (as Roblox clients are all x86[a])
  • Debugging and disassembly in order to find subroutine addresses to place hooks and to make other client modifications, such as cosmetic ones

Common tools used in disassembly are:

  • Cutter : A cross-platform fast disassembler with a much more welcome welcoming user interface and the Ghidra decompiler included, as well as the jsdec decompiler. Includes an experimental debugger. This is an excellent tool to get started with disassembly. This, in combination with x64dbg and Resource Hacker create a fantastic starter kit.
  • IDA Pro with Hex-Rays decompiler: An all-in-one disassembler with a debugger and decompiler (from ASM to rudimentary C++) included. This is the preferred choice for most reverse engineers as it is includes state-of-the-art disassembling technology; however, a license is necessary and prices for those can go up to more than a thousand dollars. As such, most people choose to acquire it through illegitimate means, despite it being unsafe to do so. Additionally, the learning curve is steep; newcomers may be intimidated by its complicated UI.
  • Ghidra: An alternative to IDA developed by the NSA[1]. Requires Java and has a very basic, primitive UI. However, the learning curve isn't as steep. Includes a decompiler.
  • x64dbg (Windows only): A powerful debugger for Windows. Fast, simple UI. Not too complicated to use but also not that easy. However, the learning curve is smooth and it's easy to get a hang of it.
  • HxD (Windows only): A basic hex editor for Windows. Simple UI and easy to use.
  • Resource Hacker (Windows only): A resource editor for Windows applications. Useful for editing the icon of the client, and to edit menus[b] and other special metadata.

This article assumes you have an intermediate knowledge in both C++ and computer science in general.

Assembly

Instruction set

The x86 instruction set is a vast instruction set with various extensions. Luckily, you'll only really see basic x86 instructions when debugging Roblox.

These are some common instructions (but not every instruction) that can be seen while debugging Roblox.

x86 instructions (partial list)
Instruction (NASM syntax) Name Purpose
jnz [address], jne [address] Jump if not zero, Jump if not equal The processor will set EIP to the given address if EFLAGS has the ZF (zero flag) bit cleared (generally set by a cmp operation).
jz [address], jeq [address] Jump if zero, Jump if equal The processor will set EIP to the given address if EFLAGS has the ZF (zero flag) bit set (generally set by a cmp operation).
jmp [address] Jump The processor will set EIP to the given address.
call [address] Call The processor will set EIP to the given address and then push the current address to the stack.
cmp [A], [B] Compare The processor will compare addresses A and B, and set EFLAGS to the result of the comparison.
mov [A], [B] Move The processor will set B to A.
nop No operation The processor will not do anything. This is generally only used for debugging.

Why does jne and jnz have the same purpose? Its largely for programmer readability, but cmp sets ZF in EFLAGS if the value being compared is 0 or equals the other value. jz and jeq does this too.

Where's all the data?

It may be noticed, that in the set provided above there are terms such as "EFLAGS" and "EIP". These are what are known as CPU registers. CPU registers are the fastest way to retrieve, manipulate, and store data, but are limited in size.

x86 registers (partial list)
Register Purpose
EAX General purpose register, sometimes called the Accumulator register. In C and C++ this is used for storing the return value of the last function.
EBX General purpose register, sometimes called the Base register
ECX General purpose register, sometimes used to store the loop counter. In C++, *sometimes* this points to this, the current class.
EDX General purpose register
EBP Stack Frame Pointer. This is how programs will typically safely address other values in the stack, because ESP will fluctuate wildly during execution.
ESP Stack Pointer. This is where the x86 fetches the top of the stack from. This decrements (decreases) when PUSHed to, and increments (increases) when POPed from.
EDI Destination index (typically used for arrays)
ESI Source index (typically used for arrays)
EIP Instruction Pointer. This is where the x86 fetches the next instruction from memory from, and is incremented by the size of the decoded instruction every instruction.
EFLAGS FLAGS. This is where the cmp instruction stores its results. This is not directly accessible by code itself, but can be manipulated via flow control using the jnz, jne, jeq and miscellaneous instructions.

All of the registers here are 32 bit registers, which when PUSHed take up 4 bytes in the stack.

Memory

Memory is the second fastest way to store data on x86. It is a large array of sorts, storing the program itself, all of the data the program reads and writes to, and everything else necessary for system functioning.

Values have different size depending on their storage type. Here are some storage types that are immediately relevant to us:

Type Size (in bytes) Max Value
uint64_t (unsigned long) 8 ±9,223,372,036,854,775,807 (signed), 18,446,744,073,709,551,615 (unsigned)
uint32_t (unsigned int) 4 ±2,147,483,647 (signed), 4,294,967,295 (unsigned)
uint16_t (unsigned short) 2 ±32,767 (signed), 65,535 (unsigned)
uint8_t (unsigned char) 1 ±127 (signed), 255 (unsigned)

Unsigned and Signed Integers

A signed integer is simply an integer with the last bit set to hold the "sign" bit. This bit determines if the integer is negative or positive. When it is 0, the integer is positive; and when it is 1, the integer is negative.

Integer Endianess

Endian example
Big-endian
Little-endian, the one x86 uses

In x86, integers are little endian. That means that the most significant byte (the first byte in the integer) at the largest address (the address farthest from 0), and stores the least significant byte (the last byte in the integer) at the smallest address (the address closest to 0.)

Stacks

Stacks are a form of data storage employed by most CPU architectures, including x86. In x86, the stack can be imagined as a stack of plates. You can put a plate on top of the stack (PUSH to the stack), and take the top most one off (POP from the stack).

When you call for example, the processor will PUSH the value of EIP, then go to the new address. When that subroutine eventually executes a RETurn instruction, the processor will POP the last value on the stack (which in this case, is what EIP used to be!) and then set EIP to the old address.

The stack of plates analogy breaks when it is possible to access ANY value in the stack at ANY time without POPing it, because in x86's case it has full access to the memory of the stack. This is useful when you use a calling convention, which is explained further below.

Calling Conventions

To complicate stacks even further, most programs employ a calling convention. This is most used by programming languages such as C, in order to keep track of data between functions. When functions run, without storing its initial registers the new function will overwrite them, and the data held beforehand will be lost. An example :

int x = 10;                // imagine this is a register named "x"
printf("Hello World");     // this function will likely need to use register "x" in its lifetime
printf("%i", x)           // this will print 5 as the function before overwrote register "x", thus "mangling" it

The solution to this is to use the aforementioned stack. When a function is called, it will PUSH certain registers and then CALL the address. In our basic calling convention where the callee (the thing that calls the function) stores EAX.

callee:
    mov eax, 20
    push eax
    call function
    ; eax now equals 10
    pop eax
    ; eax now equals 20
function:
    mov eax, 10
    ret

There is a catch here, for function to manipulate data. When function reaches its first instruction, this is what memory looks like at ESP for itself:

x86 stack frame
Offset Value
esp Return Address
esp + 4 bytes EAX

This is not a realistic calling convention however, as it does not store EBP (the stack frame base pointer.)

__cdecl

__cdecl is one of the calling conventions used in modern x86. It is the default calling convention used in C, and stores arguments and local variables on the stack.

Through accessing memory using ESP or EBP as offset bases the function can modify the stack, receiving arguments and allocating values on the stack.

void caller()
{
    function(5);
}

int function(int y)
{
    int x = 0;
    x = x + y;
    return x;
}

This will be assembled as:

caller:                
    push 5                ; push argument y to function
    call function
function:
    push ebp              ; preserve current frame pointer
    mov esp, ebp          ; set frame pointer to stack top
    sub esp, 4            ; allocate space for int x;
    mov eax, [ebp-4]      
    mov eax, 0            ; int x = 0
    add eax, [ebp+8]      ; x = x + y
    add esp, 4            ; restore space from int x;
    pop ebp               ; restore old frame pointer
    ret                   ; eax is the return register on __cdecl

In memory, the function will see this before executing add esp, 4:

x86 stack frame
Offset Value
esp, ebp - 4 bytes int x;
esp + 4 bytes, ebp + 0 bytes EBP
esp + 8 bytes , ebp + 4 bytes Return Address
esp + 12 bytes, ebp + 8 bytes int y;

The conventions above are using the __cdecl conventions however, and are not what you would find in some Roblox methods. Roblox and C++ classes uses a calling convention named __thiscall.

__thiscall

In __thiscall, variable arguments are not supported. However, ECX (which you might be able to recognize now) is used as this. All arguments are pushed onto the stack. A __thiscall function may look like this in ASM:

callee:
    push ecx           ; save class
    push eax           ; argument 0
    push ebx           ; argument 1
    mov ecx, class_ptr ; class
    call class_func    ; class' class_func
    add esp, 8         ; 'remove' argument 0 and 1 from stack
    pop ecx            ; restore class

This would roughly be the same as:

void caller(void)
{
    class* class = 0;
    class->class_func(0, 0);
}

The function class_func would most likely assemble to:

class_class_func:
    push ebp          ; preserve current frame pointer
    mov ebp, esp      ; create new frame pointer by pointing to the current stack top
    ret

__stdcall

__stdcall is a Win32 specific calling convention in which the callee cleans the stack. It's not very important here, so we'll brush over this.

Modules

Modules are executable files loaded into memory. When Roblox starts, Win32 will load various DLLs and run them and then run Roblox. This is why if you start Roblox with x32dbg, it will start in some random DLL instead of RobloxApp.exe for example.

Performing operations such as searching for strings will not work in modules that are not the RobloxApp module (or whatever executable Roblox is running from) since it will search memory regions that may have nothing to do with Roblox itself.

When Win32 loads a module, the module within has information where certain regions of data within the module are mapped into memory. There are 4 sections which are important:

.text

.text is where the executable code is located. It is meant to be non-writable. Most of the time you spend disassembling will be within this section.

.rodata

.rodata is where global constants are located. It is meant to be non-writable as well (Read only data.)

.data

.data is where initialized read-write data is located, such as strings.

.bss

.bss is where uninitialized read-write data is located.

Where's the stack?

The stack is not in any of these sections, and is set to an address specified by the executable upon startup.

Why does Roblox keep on stopping?

This is probably because you ran into an exception. Exceptions are used in C++ to signal when a function must quickly exit and return some error data to the parent function. For example, when trust check fails it will throw a C++ exception, which is then caught, outputting an error in the Roblox console.

I got ACCESS_VIOLATION instead!

That probably means something broke within Roblox itself. An access violation is when the program attempts to access unallocated or unusable memory, and the OS raises an error. It signals to the program that it has done something wrong (thus an access violation.) Access violations generally get passed to Roblox's crash handler.

Why is there an infinite amount of exceptions when Internet Explorer opens on old studio versions?

That's because Internet Explorer sucks tries to load a page it can't support (generally if you haven't changed the URL from http://roblox.com in AppSettings.xml.

Disassembly and debugging

TODO

References

Footnotes

  1. Until version 0.574.1.5740447 (dated 5/3/2023), which is when Roblox introduced Byfron and dropped x86 support.
  2. On MFC clients (before they fully migrated to Qt studio.)

Citations

  1. "NSA Releases Ghidra, a Free Software Reverse Engineering Toolkit." ZDNET, www.zdnet.com/article/nsa-release-ghidra-a-free-software-reverse-engineering-toolkit/.