The DEITYBOUNCE core functions above imply that there are possibly
three kinds of malware components required for DEITYBOUNCE to work as
follows:
- A persistent “infected” PCI expansion ROM. This module contains a
routine to configure DEITYBOUNCE’s frequency of execution. The routine
possibly stores the configuration in the RAID controller NVRAM. This
module also contains the tainted interrupt 13h (Int 13h) handler that
can call other routines via SMI to patch the kernel of the currently
loading OS.
- SMI handler(s) code implanted in the PowerEdge motherboard BIOS to
serve the software (SW) SMI calls from the “infected” RAID controller
PCI expansion ROM.
- An OS-specific malware payload running in Windows 2000, Windows Server 2003, or Windows XP.
At this point we already know the DEITYBOUNCE malware components.
This doesn’t imply that we would be able to know the exact architecture
of the malware, because there are several possible pathways through
which to implement the components. However, I present the most probable
architecture here. This is an educated guess. There could be
inaccuracies because I don’t have a sample DEITYBOUNCE binary to back up
my assertions. But I think the guesses should be close enough, given
the nature of x86/x64 firmware architecture. If you could provide a
binary sample with suspected DEITYBOUNCE in it, I’m open to analyze it,
though :-).
***Read full article here***
No comments:
Post a Comment
The Recaptcha is disabled because most of you are not robots.