A practical example of How to use ghidra to attack crackme
First Download crackme from the site MalwareTech , the password to the archive – too MalwareTech.
So, let’s see what is in the archive. We see the executable file vm1.exe and dump file ram.bin. The explanation on the site says that we are dealing with an eight-bit virtual machine. The dump file is nothing more than a chunk of memory, in which random data and a flag that we need to find are interspersed. Let’s leave the dump file alone for a while and take a look at vm1.exe through the DiE program.
CrackMy Analyzer Detect It EasyDiE does not show anything interesting, everything is fine with entropy. It means that there is no hinged protection, but it was still worth checking. Let’s load this file into Ghidra and see what it gives out. I will give a complete listing of the application without functions (it is quite small) – so that you understand what we are dealing with.
PUSH EBP
MOV EBP ,ESP
SUB ESP ,0x94
LEA ECX =>local_94 ,[0xffffff70 + EBP ]
CALL MD5::MD5
PUSH 0x1fb
PUSH 0x0
CALL dword ptr [->KERNEL32.DLL::GetProcessHeap ]
PUSH EAX
CALL dword ptr [->KERNEL32.DLL::HeapAlloc ]
MOV [DAT_0040423c ],EAX
PUSH 0x1fb
PUSH DAT_00404040
MOV EAX ,[DAT_0040423c ]
PUSH EAX
CALL memcpy
ADD ESP ,0xc
CALL FUN_004022e0
MOV ECX ,dword ptr [DAT_0040423c ]
PUSH ECX
LEA ECX =>local_94 ,[0xffffff70 + EBP ]
CALL MD5::digestString
MOV dword ptr [local_98 + EBP ],EAX
PUSH 0x30
PUSH s_We've_been_compromised!_0040302c
MOV EDX ,dword ptr [local_98 + EBP ]
PUSH EDX
PUSH 0x0
CALL dword ptr [->USER32.DLL::MessageBoxA ]
PUSH 0x0
CALL dword ptr [->KERNEL32.DLL::ExitProcess ]
XOR EAX ,EAX
MOV ESP ,EBP
POP EBP
RET
As you can see, the code is simple and easy to read. Let’s use the Ghidra decompiler and see what it produces.
undefined4 entry(void)
{
HANDLE hHeap;
char *lpText;
DWORD dwFlags;
SIZE_T dwBytes;
MD5 local_94 [144];
MD5(local_94);
dwBytes = 0x1fb;
dwFlags = 0;
hHeap = GetProcessHeap();
DAT_0040423c = (char *)HeapAlloc(hHeap,dwFlags,dwBytes);
memcpy(DAT_0040423c,&DAT_00404040,0x1fb);
FUN_004022e0();
lpText = digestString(local_94,DAT_0040423c);
MessageBoxA((HWND)0x0,lpText,"We\'ve been compromised!",0x30);
ExitProcess(0);
return 0;
}
I added indentation for readability – separated the variable declarations from the rest of the code. The code is very simple: first, memory is allocated in the heap ( GetProcessHeap… HeapAlloc), then 0x1fb (507) bytes from are copied into it DAT_00404040. But we have nothing interesting in 00404040! We recall that the crack manual said that ram.bin is a piece of memory. Of course, if you look at the file size, it turns out to be 507 bytes.
*
We load ram.bin in HxD or any other hex editor and watch.
File ram.bin in HxD Hex Editor
Alas, there is nothing intelligible there. But the logic of the work DAT_0040423c is cleared up a bit: – this is ram.bin (our dedicated 507 bytes on the heap). Let’s rename DAT_0040423c RAM to make it easier to navigate the code. Next, go to the function FUN_004022e0.
Graphic representation of the function FUN_004022e0
Here is the decompiled function code:
void FUN_004022e0(void)
{
byte bVar1;
uint uVar2;
byte bVar3;
byte local_5;
local_5 = 0;
do {
uVar2 = (uint)local_5;
bVar1 = local_5 + 1;
bVar3 = local_5 + 2;
local_5 = local_5 + 3;
uVar2 = FUN_00402270((byte *)(uint)*(byte *)(RAM + 0xff + uVar2),
(uint)*(byte *)(RAM + 0xff + (uint)bVar1),
*(undefined *)(RAM + 0xff + (uint)bVar3));
} while ((uVar2 & 0xff) != 0);
return;
}
Since we still know that we have a virtual machine, everything becomes more or less clear. But in order to truly understand pseudocode, one must always look into the disassembler, otherwise pseudocode can be confusing.
Ghidra pseudocode and disassembler
I outlined the instructions that perform the increment of variables by one. Remember that we have a function FUN_00402270 that is initialized with three parameters. We look at the initialization of the first parameter.
MOVZX ECX ,byte ptr [EBP + local_5 ]
MOV EDX ,dword ptr [RAM ]
MOVZX EAX ,byte ptr [0xff + EDX + ECX *0x1 ]
MOV dword ptr [EBP + local_14 ],EAX
MOV CL,byte ptr [EBP + local_5 ]
ADD CL,0x1 ; Variable increment
Obviously, a byte is taken from [RAM] and the variable is initialized. And the same code when initializing each function argument, the only difference is that the registers in which the function arguments will be changed FUN_00402270 . As a result, the function call looks like this:
MOV ECX ,dword ptr [EBP + local_c ]
PUSH ECX
MOV EDX ,dword ptr [EBP + local_10 ]
PUSH EDX
MOV EAX ,dword ptr [EBP + local_14 ]
PUSH EAX
CALL FUN_00402270
So, FUN_00402270 three parameters are transmitted – three bytes from [RAM], following each other. Go to the function FUN_00402270, here is its pseudocode:
uint FUN_00402270(byte *param_1,int param_2,undefined param_3)
{
if (param_1 == (byte *)0x1) {
*(undefined *)(RAM + param_2) = param_3;
}
else {
if (param_1 == (byte *)0x2) {
param_1 = (byte *)(RAM + param_2);
DAT_00404240 = *param_1;
}
else {
if (param_1 != (byte *)0x3) {
return (uint)param_1 & 0xffffff00;
}
param_1 = (byte *)(RAM + param_2);
*(byte *)(RAM + param_2) = *param_1 ^ DAT_00404240;
}
}
return CONCAT31((int3)((uint)param_1 >> 8),1);
Here the first byte passed to the function is checked, and if it matches with 0x1, 0x2 or 0x3, the next two arguments are processed. The parsing of the first parameter is especially clearly readable in the disassembled listing. Apparently, this is a virtual machine command interpreter that contains only three VM commands.
Graphic representation of the interpreter in Ghidra
PUSH EBP
MOV EBP ,ESP
PUSH ECX
MOV EAX ,dword ptr [EBP + param_1 ]
MOV dword ptr [EBP + local_8 ],EAX
CMP dword ptr [EBP + local_8 ],0x1
JZ LAB_0040228e
CMP dword ptr [EBP + local_8 ],0x2
JZ LAB_0040229e
CMP dword ptr [EBP + local_8 ],0x3
JZ LAB_004022b0
JMP LAB_004022d1
At this stage I will discuss a little more to summarize. So, we have an application that works with 507 bytes of memory, the dump of which we have is ram.bin. Inside this dump, the data that is interesting to us is mixed with other data that we do not need. The application vm1.exe reads byte memory in search of instructions 0x1, 0x2 and 0x3, and as soon as one of them is found, the next two bytes after them are processed.
In other words, we have mnemonic commands (p-code, pi-code) that work with their two arguments, and a memory area of 507 bytes is nothing more than a pi-code tape mixed with garbage. In fact, do not be afraid of garbage – processing commands will begin with finding the desired byte of the opcode, and the following two values will be taken, and the garbage is simply skipped.
INFO
P-code, or “pi-code“, is the implementation of mnemonics for its own command interpreter. It is also called the “hypothetical processor” code – after all, in fact, the processor for the execution of pi-code was written by someone independently.
Now let’s analyze the programmed opcodes of commands that are parsed by the code shown above. I will immediately provide a C code similar to the disassembler listing.
LAB_0040228e:
MOV ECX ,dword ptr [RAM ]
ADD ECX ,dword ptr [EBP + param_2 ]
MOV DL,byte ptr [EBP + param_3 ]
MOV byte ptr [ECX ],DL
JMP LAB_004022d5
Let’s start to restore the logic of the virtual machine. Announce char ram[507] – it will be the memory of the virtual machine. Using this function fopen → fread →, fwrite write the contents of the ram.bin file to this array. Four lines of the assembler code and the transition – everything is simple: in the array ram by value we [EBP + param_2] move the value param_3. In the code, it will look like this:
ram[val_01] = val_02;
We start analyzing the following subroutine:
LAB_0040229e:
MOV EAX ,[RAM ]
ADD EAX ,dword ptr [EBP + param_2 ]
MOV CL,byte ptr [EAX ]
MOV byte ptr [r1 ],CL ; DAT_00404240
JMP LAB_004022d5
It is very similar to the previous one, it is also an analogue of the MOV operation, but one of the two registers of the virtual machine ( DAT_00404240 in the listing) is already used here , into which the value from the VM memory is put. And from our point of view – from the array ram, which is addressed param_2 in the disassembler code, and in ours – val_01. In other words, an operation MOV reg,[mem].
int r1 = 0, r2 = 0; // We declare VM registers
r1 = ram[val_01];
The last subroutine is twice as difficult – instead of four lines of code, here are eight! We take the value from memory (remember our array ram, where did we write the contents of ram.bin?) And save it to the virtual machine register (EDX), then take the first value after the mnemonics in the pi code (ECX) and perform the XOR operation between them . The result is put back into memory.
LAB_004022b0:
MOVZX EDX ,byte ptr [r1 ] ; DAT_00404240
MOV EAX ,[RAM ]
ADD EAX ,dword ptr [EBP + param_2 ]
MOVZX ECX ,byte ptr [EAX ]
XOR ECX ,EDX
MOV EDX ,dword ptr [RAM ]
ADD EDX ,dword ptr [EBP + param_2 ]
MOV byte ptr [EDX ],CL
JMP LAB_004022d5
In C, it will look like this:
r2 = ram[val_01];
ram[val_01] = r2 ^ r1;
That’s all. The three-team virtual machine has been restored, it remains to apply the results of our work to the ram.bin file in order to get the required cracking flag. As I said, for this we read the file in char ram[507] and use the VM code decompiler. As a bonus, the cycle will display the virtual machine mnemonics in a readable form, and at the end will print the desired flag. I added clarifying comments to the code.
char ram[507]; // VM memory, ram.bin
int r1 = 0, r2 = 0; // VM registers
for (;;)
{
int command = (int)ram[x]; // We take command opcode
int val_01 = (int)ram[x + 1]; // First operand of the command
int val_02 = (int)ram[x + 2]; // Second operand command
// Decoding the code
if (command == 0x1)
{
ram[val_01] = val_02;
cout << "mov " << "[" <<(int)ram[val_01] << "]" << "," << val_02 << endl;
}
if (command == 0x2)
{
r1 = ram[val_01];
cout << "mov " << "r1" << "," << "[" << (int)ram[val_01] << "]" << endl;
}
if (command == 0x3)
{
r2 = ram[val_01];
ram[val_01] = r2 ^ r1;
cout << "xor " << "r2" << "," << "r1" << endl;
}
if (command > 3 || command < 1) break;
x += 3;
}
printf("\n%s\n", &ram); // Print the result
After executing this code, we will get the disassembled VM and flag.
Result of the restored virtual machine
Conclusion
I hope that, after reading the article, you will stop being afraid of the words “virtual machine” or “pi-code”. Of course, in real commercial protectors like VMProtect or Themida everything will be much more complicated: there can be used a lot of virtual machine commands, their mnemonic codes can change constantly, there are virtual machines, different anti-debugging and anti-dump techniques written in pi-code, and much more . But you got the first idea.
At the same time, we became more closely acquainted with the toolbox called Ghidra and performed the first hack using it, even if it was a crack!
Leave a Reply