It’s quite common for bootkit malware to modify the Master Boot Record (MBR), Volume Boot Record (VBR) and even BIOS but we were unaware of anything more innovative.
Last week however, we found a new bootkit sample in China, which appeared to be a bit different from other bootkits. It behaved abnormally in its MBR’s 512 bytes code space.
Until now, we have malicious MBR codes doing the following:
1 Hide the virus code to the end of real-mode space
3 Hook int 13 interruption
For example, the self-decryption code of TDL4 bootkit is as follows:
Mebroot hooks int 13 interruption:
But what is the difference between these two and the new Wapomi sample we found last week?
Firstly, it loads 57 (0×39) sectors from the end of the disk into memory address 0×97200 and then it jumps to address 0×97400 and executes.
Then its 16bit code repeatedly calls the cs:dword_2580 function, but strangely the first 8 bytes are all zeros. Interesting, isn’t it?
Beginning of function cs:dword_2580:
Debugging by Bochs then reveals changes in the function’s beginning:
First bytes are no longer zeros and byte sequence is 0xe3fe, 0xf000. This byte sequence has been gained from the original BIOS int 13interruption address. This means that when the cs:dword_2580 function is called an int 13 interruption is invoked.
This is the first time we have seen malware which uses this trick to invoke an int 13 interruption. The question is why? We know that bootkit viruses hook int 13 to load virus drivers and we know that some AVs and security tools monitor int 13 interruption check the MBR for such infection. This seems to be an attempt to bypass int 13 interruption checks and also to make analysis of the code more difficult.
AVG detects this malware as Win32/Wapomi.F.
Stanley Zhu & Jason Zhou