Two ways to adjust the Partition Table (an exercise in futility...)

After I made a mention last week about the latest TDL4 version which alters the partition table, I decided to try a few things to see how to manually do this. Note that this is NOT a fix for the latest TDL4 variant (for more information about this rootkit, see TDL4 rebooted | ESET Threat blog).

Repeating the steps below is at your own risk; if you are not sure what your are doing, this may result in serious damage. My recommendation for everyone who wants to try this, is to use a Virtual Machine (I use Virtual Box).

For this experiment I have used a VM (VirtualBox) with one partition, containing XP. I have used TestDisk to alter the partition table so that the boot flag for this partition no longer was Active. I also have written the TestDisk MBR to the drive to illustrate that the partition is still there and can be booted from. I then dumped the MBR using linux's DD utility (using xPUD live CD), after which I opened this dump with HxD hex editor. I used this to manually change the bootflag for the partition back to Active. Finally I restored this fixed MBR using DD, et voila...


1. Use TestDisk to change the bootflag

TestDisk can be used both under Windows and Linux (in this case I used the xPUD live CD). The hard disk showed up as follows in Testdisk (you can see here this is a virtual harddisk, created using Virtual Box).
After selecting the device, you get presented with some options. To see and alter partition information you need to select Analyse. After a Quick Search the following was displayed (see image below).

Next I used the arrow keys to change the bootflag from Primary and bootable (*, see left image) to Primary partition (P, see right image).







2. Use TestDisk to rewrite the MBR

To make sure I could test the altered partition table afterwards, I next
have rewriten the Master Boot Record with TestDisks MBR (this option is available after choosing the Device, see right picture). The only advantage is that this, when it doesn't see an Active partition or when it is not able to boot from the Active partition, will display manual boot yptions, as you can see in the left image below. The right image displays what happened when I pressed 1 at that point.
By doing that I forced the computer to look on primary partition 1 (as present in the partition table) for a boot loader. As this was present (on XP this is the NTLDR file), the boot process continued normally and Windows was loaded.


3. Dump the MBR with DD
While it would be easy to change the boot flag back to Active (bootable) partition with TestDisk (just reverse the steps under point 1), lets fix this another way than I broke it. For the next steps I used the xPUD live CD and an USB jump drive. In xPUD I navigated to my USB drive (usually present in the File menu as /mnt/sdb1) and opened a terminal. I executed the DD command visible in the image, which dumped the first 512 bytes of the drive (otherwise known as the MBR) to my USB drive as mbr.bin.

4. Edit the MBR dump to manually change the boot flag

Now that we have the MBR dump, we can open it with any (hex) editor. I used HxD hex editor for this. This is how mbr.bin looks in a hex editor (see image):

I have highlighted the partition table and color coded it for clarity. The first partition entry is yellow, the second green, the third blue and the fourth pink. Because this harddisk has only one partition, only one partition is present in the Partition Table.



In order to readjust the Partition Table so it will once again have an Active partition set, we can simply edit this dump. The bootflag for each partition is set in the first number of the respective partition entry (for the partition we need to adjust, this is 000001BE). The bootflag for the Active partition is 80, so we can simply edit the number in 000001BE and change it from 00 to 80. When done I saved the change I made in mbr.bin (to be sure I also saved the original as mbr.bin.bak) and transfered the USB jump drive with mbr.bin back to xPUD.

5. Restore the adjusted MBR

The only thing that remains to be done now is to restore the adjusted MBR and overwrite the existing MBR with it. We can do that in xPUD using DD as shown in the image.

The computer booted normally afterwards.

I hope that this example has helped you to gain an insight in how the Partition Table "works" and how you can adjust it.

TDSS in layman's terms

Since 2008 it has been a constant factor in malware-land: the TDSS rootkit (also known as Alureon rootkit).  

There is a lot of good in-depth information and analysis posted all over the internet, a few examples are TDSS - Securelist and TDSS aka TDL: A Botnet Framework. However, I often get questions from people who are looking for a simple description: how are the different variants being identified and what is the difference between them? For that reason I have posted this (very) general overview.

• TDL1: Classic TDSS; created a hidden driver service named TDSSserv, which loaded c:\windows\system32\drivers\tdssserv.sys

• TDL2: Same as TDL1, but the names differ and contain a random string. There are many different versions, each of them containing new tricks to avoid detection and deletion. Examples are UACxxxxx, SKYNETxxxxx, GEYEKxxxxx, GASFKxxxxx, H8SRTxxxxx, PRAGMAxxxxx (where xxxxx represents a random string).

• TDL3: The aim is to patch the hard disk controller driver (atapi.sys/iastor.sys) in order to get control over the system. Classic TDL3 directly patches atapi.sys on disk, later versions patch a random .sys file in the c:\windows\system32\drivers folder, which in turn patches atapi.sys in memory only, thus making detection/removal more difficult.

• TDL4: The aim of this variant is the same as that of TDL3, however instead of patching a file, the Master Boot Record is patched, which makes infection of 64 bit systems possible and detection/removal harder. 

• The latest version (at this moment still called TDL4) no longer patches the MBR. It alters the partition table so that its own hidden HPFS partition is set to Active. That way, when the computer is started, it will boot from the TDLFS partition, and load the infection from there, thus gaining control over the machine (it can then alter the MBR in memory and from there acts similar to TDL4 as described above). Fixing the MBR is no longer an option; the only way to fix this is to alter the partition table.