Cbrom Exe Bios

by

• • • • Reading Time: ~ 6 min. By Marco Giuliani In the past few weeks a Chinese security company called blogged about a new BIOS rootkit hitting Chinese computers. This turned to be a very interesting discovery as it appears to be the first real malware targeting system BIOS since a well-known proof of concept called IceLord in 2007. The malware is called Mebromi and contains a bit of everything: a BIOS rootkit specifically targeting Award BIOS, a MBR rootkit, a kernel mode rootkit, a PE file infector and a Trojan downloader. At this time, Mebromi is not designed to infect 64-bit operating system and it is not able to infect the system if run with limited privileges. The infection starts with a small encrypted dropper that contains five crypted resource files: hook.rom, flash.dll, cbrom.exe, my.sys, bios.sys. The goal of these files will be presented later in this analysis. The infection is clearly focused on Chinese users, because the dropper is carefully checking if the system it’s going to infect is protected by Chinese security software Rising Antivirus and Jiangmin KV Antivirus.

To gain access to the BIOS, the infection first needs to get loaded in kernel mode so that it can handle with physical memory instead of virtual memory. Many of you may recall the old CIH/Chernobyl infection, the infamous virus discovered in 1998 that was able to flash the motherboard BIOS, erasing it. Even CIH needed to gain kernel mode access to reach the BIOS, though at the time the virus was exploiting a privilege escalation bug in Windows 9x operating system which allowed it to overwrite the Interrupt Descriptor Table with its own payload from user mode, then triggering the overwritten interrupt handler and its malicious code is executed in kernel mode. Mebromi does not use such kind of privilege escalation trick anymore, it just needs to load its own kernel mode driver which will handle the BIOS infection.

Feb 18, 2019 - Cbrom Exe Bios. This demo doesn't actually use any ChemDoodle Web Components. This demo will load a ChemDraw® CDX file and display.

Download tattle tale game show free. To do so, it uses two methods: it could either extract and load the flash.dll library which will load the bios.sys driver, or it stops the beep.sys service key, overwriting the beep.sys driver with its own bios.sys code, restart the service key and restore the original beep.sys code. The bios.sys driver is the code which handle the BIOS infection.

To read the BIOS code, it needs to map the physical memory located at physical memory address 0xF0000, this is where the BIOS ROM usually resides. Once read, the driver verifies if the BIOS ROM is Award BIOS, by checking the presence of the string: $@AWDFLA. If found, the driver tries to locate the SMI port that will be used by the rootkit to flash the BIOS ROM. If the BIOS ROM matches the string, the rootkit saves a copy of the BIOS to the file C:bios.bin and pass the next step to the user mode component of the infection. The dropper extracts two files: cbrom.exe and hook.rom. Cbrom.exe is a legitimate tool developed by Phoenix Technologies, used to modify the Award/Phoenix BIOS ROM binaries. Hook.rom is the rootkit ISA BIOS ROM that is added to the BIOS binary, containing the rootkit infection.

The dropper executes cbrom.exe with the /isa switch parameter, passing the hook.rom file. Before actually injecting the malicious ISA ROM, the dropper checks the BIOS ROM code looking for the “ hook rom” string, used as a marker of the infection. If found, it means that the BIOS is already infected and it doesn’t need to be infected again. After that the bios.bin file has been modified, the bios.sys driver send to the BIOS SMI port the command 0x29, used to erase the BIOS flash, and then the command 0x2F used to write the new BIOS ROM code to the BIOS ROM. The BIOS is now infected, and the dropper goes to its next step: infecting the Master Boot Record.

The infection is 14 sectors long and the original MBR is stored to the sector 7. To avoid potential startup issues, the infected MBR stores a copy of the original MBR’s partition table.

Cbrom

Finally the dropper extracts the my.sys driver on the root of the C: drive. My.sys is a kernel mode rootkit that hijacks disk.sys’s IRP major functions, by redirecting the IRP_MJ_READ/WRITE and IRP_MJ_DEVICE_CONTROL native functions. It is used to hide the infection on the disk. Even if the BIOS infection doesn’t succeed, the rootkit does infect the MBR.

At the next system startup, after the BIOS POST phase, the malicious code injected inside it prepares the full MBR infection (all the first 14 sectors are stored inside the malicious BIOS rom, 7168 bytes in total) and checks the MBR code of the hard drive looking if the infection is already present. To do it, the BIOS malicious code checks for the presence of the string “ int1” at the offset 0x92. If the string is not found, the BIOS malicious rom will overwrite all the first 14 sectors of the hard drive, thus restoring the MBR infection. The system startup procedure continues and the control now passes to the malicious master boot record. Here the malicious payload analyzes the original MBR partition table and looks for the active partition, checking if it’s using a NTFS or FAT32 file system. The malicious MBR code contains indeed NTFS/FAT32 parser routines, used to get inside the file system to look for winlogon.exe or wininit.exe file. When found, the malicious code contains a file infection payload, able to inject malicious code inside the specified file and hijack the entry point of it. Before infecting the file, the MBR malicious code checks if it is already infected, by looking for the string “ cnns” at the offset 0x50 from the beginning of the PE file.