This paper is really interesting: http://www.stewin.org/papers/dimvap15-stewin.pdf
---------------------------------------------------
Abstract (excerpt): ... Modern computers contain dedicated hardware such as network and graphics cards. Such devices implement independent execution environments but have direct memory access (DMA) to the host runtime memory. In this work we introduce DMA malware, i. e., malware executed on dedicated hardware to launch stealthy attacks against the host using DMA. DMA malware goes beyond the capability to control DMA hardware.
We implemented DAGGER, a keylogger that attacks Linux and Windows platforms. Our evaluation conrms that DMA malware can efficiently attack kernel structures even if memory address randomization is in place. DMA malware is stealthy to a point where the host cannot detect its presence. We evaluate and discuss possible countermeasures and the (in)effectiveness of hardware extensions such as input/output memory management units (IOMMU).
---------------------------------------------------
For me, the very interesting finding on the paper is the presence of ARCtangent Microcontroller which (acts as the DMA "engine". The vendor of this "vague" MCU is quite hard to come by on G$$gle search. It turns out that ARC International is a subsidiary of Synopsys now. These are the relevant links:
http://en.wikipedia.org/wiki/ARC_International
http://www.synopsys.com/dw/ipdir.php?ds=arc_mpu (I think the paper probably talks about this chip)
http://www.synopsys.com/IP/ProcessorIP/ARCProcessors/ARCEM/Pages/default.aspx
PS: "First Party" DMA is also known as Bus Mastering
Welcome to the dark corner of BIOS reverse engineering, code injection and various modification techniques only deemed by those immensely curious about BIOS
Tuesday, March 26, 2013
(First-Party) DMA Malware Paper
Friday, March 22, 2013
DOS Protected Mode Interface (DPMI)
DPMI is outdated by today's standard of course. However, in certain situation it comes handy. I've been looking for documents/standards/specifications from my early days of BIOS reversing that could explain most of the 32-bit code I'd seen on the BIOS.
One of the most intriguing terms were the memory related terms, e.g. high memory, upper memory, etc. I came to think that there were no standard(s) at all which govern the use of the term. However, upon reading the DPMI specification, I finally realize that the "gaps" (in my knowledge) between the 16-bit code and 32-bit code on the BIOS are covered by the DPMI specification. Well, not all of them of course because there are still the voodoo mode. But, nonetheless, a large fraction of the missing link is in the DPMI.
For those interested on the spec. This is the link: http://homer.rice.edu/~sandmann/cwsdpmi/dpmispec1.pdf.
Have a nice weekend :-)
One of the most intriguing terms were the memory related terms, e.g. high memory, upper memory, etc. I came to think that there were no standard(s) at all which govern the use of the term. However, upon reading the DPMI specification, I finally realize that the "gaps" (in my knowledge) between the 16-bit code and 32-bit code on the BIOS are covered by the DPMI specification. Well, not all of them of course because there are still the voodoo mode. But, nonetheless, a large fraction of the missing link is in the DPMI.
For those interested on the spec. This is the link: http://homer.rice.edu/~sandmann/cwsdpmi/dpmispec1.pdf.
Have a nice weekend :-)
Subscribe to:
Posts (Atom)