In the previous post on MEMZ Trojan, I have attempted to analyze the MBR to see how Nyan cat animation occurs and how sounds were made. The purpose for this analysis is to get familiar with MBR analysis and to experiment with real world malware which might come in useful in future reverse engineering efforts that deals directly with the MBR. This sample was chosen simply because it was on a Google search with MBR corruption.
After clicking on yes, the computer restarted.
We see the CHKDSK message and that is is repairing sector.
There is then this blinking page with the “PRESS ANY KEY” string at the bottom
After which, we get the following
Everything Before WinMain
During the debugging, it seems that the code did not make it to the WinMain function which is interesting. It turns out that there is this _calloc_crt function that has the first call to sub_41A8DA which contains some form of decryption which lead to creation of RWX page which is suspicious to me.
Breakpoint at 0x41ad2c reveals that the address to mark as RWX (0x40) would be
Address: 0x41ad73
Size: 0xc1f0
Original Protection : 0x20
Example of such decryption would be to reveal new MZ file (DLL). The instructions in the figure below is something that has been decrypted by the earlier discussed routine. The dump shows the production of some bytes of a new MZ file which we can dump later on.
After dumping more contents from the file. It seems that we have found the string of the supposed site that was found when detonating the malware.
After this, the path \\.\C: was open to allow read and write.
After which it makes use of DeviceIOControl Control Code 0x560000 which maps to IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS which retrieves the physical location of a specified volume on one or more disks. The output shows that there is just one volume which is the C:\ drive. It then copy the string \\.\PhysicalDrive0 via the movs(d/b)
Once the string has been set, it would then call CreatefileAand get information on the disk via DeviceIoControl with control word IOCTL_DISK_GET_PARTITION_INFO_EX to get the partition style. The output buffer would be PARTITION_INFORMATION_EX
In this environment, we got back PARTITION_STYLE_MBR (0). The following shows the struct of PARTITION_STYLE and would default to raw (2) if there is an error.
BOOL __fastcall ReadMBR_sub_10A0EE(LPCSTR lpFileName, int output_buffer_MBR, unsigned __int64 sector_offset){ int hFile; // esi int bytesRead; // [esp+Ch] [ebp-4h] BYREF // CreateFile \\.\PhysicalDrive0 hFile = CreateFile(lpFileName, 0x80000000, 1, 0, 3, 0, 0); if ( hFile == -1 ) { // CloseHandle CloseHandle(-1); return 0; } // SetFilePointerEx // Essentially <<9 is multiply offset by sector of size 512 SetFilePointerEx(hFile, (_DWORD)sector_offset << 9, sector_offset >> 23, 0, 0); // ReadFile if ( !ReadFile(hFile, output_buffer_MBR, 512, &bytesRead, 0) ) return 0; // CloseHandle CloseHandle(hFile); return bytesRead == 512; // MBR size}
Let’s step through and view the MBR that was being read by the malware. Here is before the read where the output would be stored to 0x12f8f8
The output of the MBR can be found in the following.
After that, it does some processing to what was being read. The figure shown previously was not accepted and the MBR was re-read again:
Eventually, it would still read the next 0x20 number of 512 bytes after the initial 512 bytes of MBR which should be the kernel module that would be loaded by the MBR.
We can see that there are strings that was seen during the Detonation which shows us that this are the bytes that would be used for overwriting the MBR.
During this function call, it would XOR another k -2of 512 bytes (just another layer of obfuscation of other sections and payloads) and write it into a different segment address (Not the Boot Sector). p
for ( k = 1; k < 34; ++k ) { v22 = k >> 31; ReadMBR_sub_10A0EE((LPCSTR)v23, (int)v30, k); for ( m = 0; m < 0x200; ++m ) v30[m] ^= 0x37u; if ( !sub_10A163((int)v23, (int)v30, __PAIR64__(v22, k)) ) return 0; }
Here is an example of the XOR.
After writing those data, it would then replace the original MBR boot sector 0 with the NotPetya’s MBR.
We can tell that because looking through the code, we can see the strings that were present during the Detonation.
NotPetya MBR Dump
By dumping those bytes, we can make use of this MBR for actual debugging in QEMU. For dumping I found that Winpmem tool was the most effective one.
Note that MBR starts from Real Mode, we will probably need to (unless there is a trick), to disassemble these as 16 bits real mode separate from the rest. We can choose to extract the and analyze the original MBR in another IDA instance.
This is tricky because causes the system to restart somehow. Therefore, setting breakpoint after the final copy of MBR bytes and killing the malware process would help with the extraction of MBR.
Tip for the future
Set a lower RAM size so that this process would be sped up with smaller size.
Debugging with GDB
If you would like to try it out, the MBR is uploaded to Github
For the debugging setup, I used QEMU similar to the MEMZ Blogpost.
Read from the C drive with Disk Address Packet in memory located at DS:SI→ Disk Address Packet in memory 0000:7bdc.
512 bytes (1 sector) is being transferred to destination (0000:8000)
That 512 bytes is transferred from 0xc000
0x22 in Load addr refers to how many sectors it is from sector 0
0x7c00+0x200*0x22 = 0xc000
In the following GDB output, we see that the Disk Address Packet is as follows
Offset Size Description
0 1 size of packet (24 bytes)
1 1 always 0
2 2 number of sectors to transfer (max 127 on some BIOSes)
4 4 transfer buffer (0xFFFF:0xFFFF)
8 4 lower 32-bits of starting 48-bit LBA
12 4 upper 32-bits of starting 48-bit LBA
16 4 lower 32-bits of load address
20 4 upper 32-bits of load address
size of packet : 10
always 0 : 00
Number of sectors : 0001
Transfer Buffer : 00008000 <--- Write Disk content to 0x8000
Lower 32 bits 48 bit LBA : 00000022 <--- Where to get the content from
Upper 32 bits 48 bit LBA : 00000000
Lower 32 bits of Load addr : 00000022
Upper 32 bits of Load addr : 00000000
These values are obtained from the debugger. We can see the Disk Address Packet also from the following:
Checking and parsing MBR Partition (Last 64 bytes excluding Signature AA55). You can see the first byte is 0x80 which refers to bootable. It has the value 7 at byte 4 (5th byte) which signals that this is an NTFS partition. The last two bytes in the following shows the bytes to be compared.
The four long rectangles shows the different partitions (4 maximum). From the following figure, it shows that there is just one bootable partition that is of NTFS format with the LBA of 0x800 and size of 0x7fff000 sectors which estimate to be 0x7fff000 * 0x200 / 1000000000 = 68.717 Gb To view this, we can set a breakpoint at 0x00008c3d:
Scrolling Up One Line
The following reveals how the scrolling works!
undefined __cdecl16near Scroll_Up_One_Line0000_8aa8 (un 0000:8aa8 55 PUSH BP 0000:8aa9 8b ec MOV BP ,SP 0000:8aab 8a 7e 04 MOV BH ,byte ptr [BP + param_1 ] 0000:8aae 33 c9 XOR CX ,CX scroll up window DH = 0x18 (row of bottom-right corner) DL = 0x4f (column of bottom-right corner) CX = 0x00 BH = Fill Attribute (attribute for new line) AX = 0x600, AL = 0 (clear) , AH = 6 (scroll up) 0000:8ab0 ba 4f 18 MOV DX ,0x184f 0000:8ab3 b8 00 06 MOV AX ,0x600 0000:8ab6 cd 10 INT 0x10 BH = 0 (page number = 0) DX = 0; DH = row 0, dl = column 0 AH = 2 (Set cursor position) This resets cursor position 0000:8ab8 32 ff XOR BH ,BH 0000:8aba 33 d2 XOR DX ,DX 0000:8abc b4 02 MOV AH ,0x2 0000:8abe cd 10 INT 0x10 0000:8ac0 c9 LEAVE 0000:8ac1 c3 RET
Color is specified with BL = 7 to do Teletype Output.
undefined __cdecl16near PrintLightGrayCharacter_0000_872 BL = 7 (LightGray) AL = Character AH = Teletype Output BH = 0 (Page number 0) 0000:8726 55 PUSH BP 0000:8727 8b ec MOV BP ,SP 0000:8729 bb 07 00 MOV BX ,0x7 0000:872c 8a 46 04 MOV AL ,byte ptr [BP + param_1 ] 0000:872f b4 0e MOV AH ,0xe 0000:8731 cd 10 INT 0x10 0000:8733 c9 LEAVE 0000:8734 c3 RET
Setting breakpoint at 0x8a1a should give us the first print of the skull.
Scanning All HardDrives for Partitions
Printing “Repair Message”
This repair message only surface once (only during the first boot) which is called in FUN_0000_8640. After this whole CHKDSK saga is over, it will print the ransom note.
Offset Size Description 0 1 size of packet (16 bytes) 1 1 always 0 2 2 number of sectors to transfer (max 127 on some BIOSes) 4 4 transfer buffer (16 bit segment:16 bit offset) (see note #1) 8 4 lower 32-bits of 48-bit starting LBA12 4 upper 16-bits of 48-bit starting LBA
This means that the LBA of 0x36 is offset of 0x6c00 (from the start of sector 0). To verify this, lets take a look at the content in 0x6C00 which we will want to read and verifying with the before and after image at memory address (0x7722)
The following shows the content of the transfer buffer BEFORE the Disk Read Operation:
And the following is AFTER the read operation
We can verify the content where it was read from. Additionally, the personal decryption code is also found.
This is the decryption code being displayed
Keyboard Handling
The local variable local_4 is used to check if a key is present. When the BIOS Keyboard service is called with AH = 1. If the key is waiting, then BIOS clears the ZF and AH returns the scan code while AL contains the ASCII. The flag is then moved into AL before returning as result
This snippets shows how keyboard service is used to peek at the keyboard’s buffer without consuming the key.
0000:8af2 c8 02 00 ENTER 0x2 ,0x0 00 0000:8af6 c6 46 fe MOV byte ptr [BP + local_4 ],0x0 00 0000:8afa b4 01 MOV AH ,0x1 ; BIOS: check for keystroke KEYBOARD - CHECK BUFFER, DO NOT CLEAR Return: ZF clear if character in buffer AH = scan code, AL = character ZF set if no character in buffer 0000:8afc cd 16 INT 0x16 0000:8afe 74 04 JZ LAB_0000_8b04 ; if ZF is set, no key is waiting 0000:8b00 c6 46 fe MOV byte ptr [BP + local_4 ],0x1 ; if there is key 01 LAB_0000_8b04 XREF[1]: 0000:8afe (j) 0000:8b04 8a 46 fe MOV AL ,byte ptr [BP + local_4 ] 0000:8b07 c9 LEAVE 0000:8b08 c3 RET
Keyboard Handling
In the following snippet, the check is done is a loop if no key is waiting. It loops back and repeats the check. Once a key is detected, the AH register is set to 0 and make a BIOS call that reads the key from the keyboard. The key press is returned via AL as ASCII and AH as scan code. ASCII character is stored in local_6 while the scan code in local_4. ASCII character is stored into AL before returning.
0000:8ace e8 21 00 CALL CheckBuffer_0000_8af2 undefined CheckBuffer_0000_8af2( 0000:8ad1 0a c0 OR AL ,AL 0000:8ad3 74 f9 JZ LAB_0000_8ace 0000:8ad5 b4 00 MOV AH ,0x0 Returns AH = scan code, AL = character Keyboard - Read char from buffer, wait if empty 0000:8ad7 cd 16 INT 0x16 0000:8ad9 88 46 fe MOV byte ptr [BP + local_4 ],AL 0000:8adc 88 66 fc MOV byte ptr [BP + local_6 ],AH 0000:8adf 83 7e 04 CMP word ptr [BP + param_1 ],0x0 00 0000:8ae3 74 08 JZ LAB_0000_8aed 0000:8ae5 8b 5e 04 MOV BX ,word ptr [BP + param_1 ] 0000:8ae8 8a 46 fc MOV AL ,byte ptr [BP + local_6 ] 0000:8aeb 88 07 MOV byte ptr [BX ],AL LAB_0000_8aed XREF[1]: 0000:8ae3 (j) 0000:8aed 8a 46 fe MOV AL ,byte ptr [BP + local_4 ] 0000:8af0 c9 LEAVE 0000:8af1 c3 RET
Do Key Check and Decrypt
This function validates the input key by (for example) comparing it against an internal lookup table and possibly using it to decrypt part of the disk.
0000:8627 56 PUSH SI 0000:8628 e8 05 fe CALL Check_Input_Key_0000_8430 undefined Check_Input_Key_0000_8 0000:862b 83 c4 08 ADD SP ,0x8 0000:862e fe c8 DEC result 0000:8630 74 09 JZ LAB_0000_863b 0000:8632 68 fc 9b PUSH s_Incorrect_key!_Please_try_again._0000_9bfc = "\r\n Incorrect key! Please tr 0000:8635 e8 fe 00 CALL Print_String_Gray_FUN_0000_8736 undefined Print_String_Gray_FUN_ 0000:8638 5b POP BX 0000:8639 eb b8 JMP LAB_0000_85f3
Within Check_Input_Key_0000_8430, there is key check includes minimum length (>16 bytes).
There is some form of a lookup table in [BL+0x9716] would search for a match in that table. For each match, it would do some arithmetic which I am not able to understand.
This is found in Sector 0x37 (0x6e00) which is xor’d by 0x37!
After applying the XOR transformation, we can verify that it is true.
Salsa20 or ChaCha20 ?
We see expand 32-byte k string in this function which is a hint that this function might be part of Salsa20 or ChaCha20. However, based on the key expansion, we see Salsa20’s key expansion.
Had a better familiarity of analyzing MBR. One interesting point is to set breakpoints at CreateFile and look for the file path that is created like PhysicalDrive0 and extracting these bytes out with tools like winpmem which worked like a charm. Using the script as shown in previous Analysis on Destructive MEMZ’s Master Boot Record (MBR) which help give a better disassembly in GDB has been of a really great help.
There is then this blinking page with the “PRESS ANY KEY” string at the bottom
We can see the Initial state of the key seen in https://en.wikipedia.org/wiki/Salsa20