DIGITAL FORENSIC RESEARCH CONFERENCE

Acquisition and Analysis of Compromised

Firmware Using Memory Forensics

By

Johannes Stuttgen, Stefan Voemel and Michael Denzel

From the proceedings of

The Digital Forensic Research Conference

DFRWS 2015 EU
Dublin, Ireland (Mar 23rd- 26th)

DFRWS is dedicated to the sharing of knowledge and ideas about digital forensics
research. Ever since it organized the first open workshop devoted to digital forensics
in 2001, DFRWS continues to bring academics and practitioners together in an
informal environment.
As a non-profit, volunteer organization, DFRWS sponsors technical working groups,
annual conferences and challenges to help drive the direction of research and
development.

http:/dfrws.org
 Digital Investigation 12 (2015) S50eS60

Contents lists available at ScienceDirect

Digital Investigation
journal homepage: www.elsevier.com/locate/diin

Acquisition and analysis of compromised firmware using

memory forensics
Johannes Stüttgen*, Stefan Vo
€ mel, Michael Denzel
Department of Computer Science, Friedrich-Alexander University of Erlangen-Nuremberg, Martensstraße 3, 91058 Erlangen, Germany

a b s t r a c t

Keywords: To a great degree, research in memory forensics concentrates on the acquisition and
Memory forensics analysis of kernel- and user-space software from physical memory to date. With the sys-
Memory acquisition tem firmware, a much more privileged software layer exists in modern computer systems
Live forensics
though that has recently become the target in sophisticated computer attacks more often.
Firmware rootkits
Compromise strategies used by high profile rootkits are almost completely invisible to
Incident response
standard forensic procedures and can only be detected with special soft- or hardware
mechanisms. In this paper, we illustrate a variety of firmware manipulation techniques and
propose methods for identifying firmware-level threats in the course of memory forensic
investigations. We have implemented our insights into well-known open-source memory
forensic tools and have evaluated our approach within both physical and virtual
environments.
© 2015 The Authors. Published by Elsevier Ltd. This is an open access article under the CC
BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).

Introduction This fact is quite surprising, considering that recent works

have indicated quality deficiencies in popular imaging so-
Over the last decade, forensic practitioners have lutions under certain conditions that may severely impede
increasingly started to perceive the value of volatile infor- or even prevent thorough artifact examination at a later
mation in system RAM for the outcome of a case. Particu- time (Vo € mel and Stüttgen, 2013; Stüttgen and Cohen,
larly when suspecting potentially-installed malicious 2013).
applications on a compromised host, so-called memory In order to mitigate this research gap, we will discuss
forensic investigation techniques can frequently confirm several scenarios in this paper that exemplify various hur-
assumptions and yield results more quickly than tradi- dles and pitfalls modern memory acquisition technologies
tional, persistent data-oriented approaches (Walters and must overcome. With respect to this, we will focus on
Petroni, 2007). The majority of research has thereby specific system manipulation strategies on the firmware
concentrated on memory analysis, i.e., identifying relevant level, in contrast to other studies that illustrate issues in
data structures and subsequently extracting pieces of evi- kernel or user space (see Ligh et al., 2010; White et al.,
dence (for an overview of current practices, please refer to 2013). Although only a comparatively small amount of
Ligh et al. (2010) and Vo
€mel and Freiling (2011)). The pro- malicious programs distributed in the wild are known of
cess of securing said data in a forensically-sound manner explicitly attacking base components and features of a
on the other hand, i.e., memory acquisition, has been system, the lower machine layers have received broader
described to a significantly lesser degree in the literature. attention by malware authors in the last years, especially
with regard to the development of Advanced Persistent
Threats (APTs) and special rootkits that are remarkably
* Corresponding author. difficult to detect and remove (Shields, 2008; Davis et al.,
E-mail addresses: [email protected] (J. Stüttgen), stefan.
2010). As we will see, however, the vast number of
[email protected] (S. Vo
€mel), [email protected] (M. Denzel).

http://dx.doi.org/10.1016/j.diin.2015.01.010
1742-2876/© 2015 The Authors. Published by Elsevier Ltd. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/
licenses/by-nc-nd/4.0/).
 J. Stüttgen et al. / Digital Investigation 12 (2015) S50eS60 S51

forensic programs and toolkits available on the market to products, specifically when sophisticated malware species
date are unfortunately ill-prepared for dealing with such are present.
threats and fail at properly duplicating all sources of a
computer's physical address space in which malicious code Outline of the paper
may reside.
The remainder of this paper is outlined as follows: In
Section Background, we briefly define the type of malicious
Contributions of the paper
program we will concentrate on throughout our discussion.
We also describe standard approaches for acquiring a copy
In the scope of the paper, we will see that most firmware
of main memory from different operating systems and give
code and data can be accessed over the memory bus. We
an overview of several firmware features and technologies
present a broad survey of firmware rootkit techniques and
that help the reader better understand later parts of our
the traces such threats leave in a system. To facilitate
work. A survey of current firmware rootkit techniques and
acquisition and analysis of potential infections, we have
their implications for memory forensic investigations is
developed methods for enumerating, imaging, and exam-
presented in Section Rootkit Strategies for Compromising
ining firmware components and implemented them into
Firmware. Methods for enumerating and acquiring firm-
free, open-source utilities. The reliability of these utilities is
ware code and data are subject of Section Firmware
evaluated with the help of a proof-of-concept ACPI rootkit
Acquisition Using Memory Forensics. In Section Firmware
as well as manipulated BIOS ROMs.
Analysis, we discuss the analysis of the acquired data, fol-
lowed by an evaluation of how well these approaches are
Related work already incorporated in common forensic suites and ap-
plications in Section Evaluation. Aspects and limitations
As we have already indicated, the development of ma- that need to be considered when applying the respective
licious programs that are directly stored and executed on concepts in real-world investigations are discussed in
the hardware or firmware layer has increased over the last Section Discussion. We conclude with a short summary of
years. Stewin and Bystrov (2012), for instance, outline our work and indicate various opportunities for future
techniques for silently capturing keystrokes or extracting research in Section Conclusion.
sensitive information such as cryptographic keys from a
running machine with the help of Direct Memory Access Background
(DMA). Embleton et al. (2008) illustrate how the pro-
cessor's System Management Mode (SMM) may be misused In the scope of this paper, we discuss challenges and
for storing malevolent code, while Tereshkin and Wojtczuk pitfalls for memory acquisition solutions that operate within
(2009) manipulate the chipset of the Memory Controller a hostile environment, i.e., the target system is likely to have
Hub (MCH) for these purposes. been affected by malicious programs, and the integrity of
With respect to forensic investigations, other authors the machine cannot be trusted. In Section Rootkits, we
have attempted to leverage specific features or components specify the conditions the respective acquisition technolo-
of the hardware. Most notably, the IEEE 1394 (FireWire) gies must cope with in more detail and give a more thorough
interface or the more recent Thunderbolt port permit definition of the rootkit term. In Section Memory Acquisition
duplicating the contents of memory from a target system Process, we outline basic approaches for duplicating volatile
quite easily (see Zhang et al., 2011; Maartmann-Moe, 2012). information on different operating systems. The character-
In contrast, Wang et al. (2011) as well as Reina et al. (2012) istics of major firmware technologies are subject of Sections
describe a prototype implementation for creating a System FirmwareeACPI. The information presented in these
consistent copy of the physical address space by entering sections is mainly based on the work of Salihun (2006), Dice
the System Management Mode. Memory acquisition based (2013) as well as the respective vendor specifications (Intel
on DMA operations over a network card is subject of the Corporation, 2014b; PCI-SIG, 2010) and is required to better
work of Balogh and Mydlo (2013). Last but not least, understand the technical complexities illustrated in later
obtaining the contents of firmware ROMs is the specific parts of this paper. Readers who are already familiar with
goal of the Copernicus project (Butterworth et al., 2013). rootkits and have a solid knowledge of the BIOS, PCI, and
Copernicus permits extracting firmware data directly over ACPI environment may safely skip these explanations and
the Serial Peripheral Interface (SPI) bus. Because this directly proceed to Section Rootkit Strategies for
approach is vulnerable to malicious software running in Compromising Firmware.
System Management Mode, the latest implementation
utilizes the Intel TXT extensions (Intel Corporation, 2014c) Rootkits
to isolate the acquisition module from other parts of the
system (Kovah et al., 2014). A particularly sophisticated type of malicious programs
Most of the previously described technologies have not are so-called rootkits. Rootkits are defined to consist of a set
or only insufficiently been evaluated. First, more extensive of programs and code that allows a permanent or consistent,
studies concerning the quality of imaging applications undetectable presence on a computer (Hoglund and Butler,
were presented by Vo €mel and Stüttgen (2013) and Stüttgen 2005, p. 4). They are intentionally designed to project a
and Cohen (2013). We will further elaborate upon these manipulated view to the system user in order to achieve the
works and assess the performance of common imaging primary objectives concealment, surveillance as well as
S52 J. Stüttgen et al. / Digital Investigation 12 (2015) S50eS60

command and control of the target host (Blunden, 2009). The ROM is also aliased in a way that 16 bytes are map-
Depending on the execution mode they operate in, rootkits ped to the physical address 0xFFFFFFF0, at the CPUs reset
are commonly divided into distinct classes. These include vector (Intel Corporation, 2014b).
the user as well as kernel space, the system library level, the The firmware code initially runs on the ROM chip. It
hypervisor level (sometimes also referred to as ring -1, in then moves from ROM into RAM by manipulating special
reference to the ring architecture of the x86 processor registers, the so-called Programmable Attribute Map (PAM),
family), and finally, the firmware level (see Shields, 2008). In to shadow the ROM-mapped regions with RAM and
this paper, only the latter layer will be in the focus of our uncompressing its code image into memory. Firmware then
discussion. Introductions concerning samples running in starts initializing devices on the PCI bus and maps their
higher levels of the system abstraction can be found in the registers and memory into the physical address space as
works of Vieler (2007) and Davis et al. (2010). required. It is during this phase that the BIOS and EFI start
to differ greatly, and the final layout of the physical address
Memory acquisition process space is determined (Dice, 2013; UEFI Forum, 2014).

One of the most common and convenient methods for BIOS

obtaining a copy of volatile memory is the use of an im- The BIOS runtime environment operates in 16-bit real
aging utility. Due to security restrictions, the respective mode. It is responsible for creating an Interrupt Vector Table
programs can usually not be entirely executed in user space (IVT) in order to support a set of simple operations, e.g.
(e.g., see Microsoft Corporation, 2013), but must rather sending output to the screen or reading data from a hard
inject a special kernel driver or module into the core of the disk. The latter functionality is required to drive the boot-
operating system. With regard to Microsoft Windows, strapping process and load the boot manager as well as the
frequently-applied procedures involve either reading from operating system eventually. Precisely, the BIOS reads the
the yy.yDeviceyPhysicalMemory section object or code of the boot manager into memory and hands over
calling one of the memory-mapping APIs of the kernel, i.e., control.2 The boot manager, in turn, loads the operating
MmMapIOSpace() or MmMapMemoryDumpMdl(). On Linux system and further prepares the system environment. For
platforms, the predominant approach is similar and relies these tasks, the primary BIOS services are used. In the last
on parsing the iomem_resource tree and mapping step, the operating system takes over interrupt handling by
memory using the kmap() API (Sylve, 2012). replacing the IVT with an appropriate Interrupt Descriptor
One distinctive disadvantage of software-based imagers Table (IDT). Thereby, direct access to the BIOS services is lost.
is that they may easily fall prey to manipulation (Stüttgen
and Cohen, 2013). Moreover, because they run in parallel EFI
to other system processes, the state of memory is in a Contrary to BIOS-based firmware, EFI operates in 32-bit
constant state of flux, leading to a drastically reduced level protected mode. The boot process comprises a distinct se-
of atomicity of the generated snapshot (Vo € mel and Freiling, curity phase (SEC) in which the integrity of the firmware is
2012). To mitigate these drawbacks, researchers have out- explicitly checked, and secure booting is facilitated. In a
lined various alternatives that explicitly leverage the ca- second, so-called Pre-EFI Initialization (PEI) phase, similar
pabilities of specific hardware features and technologies. tasks as during early BIOS initialization are performed.
These include, for instance, the Intel VMX instruction set However, at the end of this phase, EFI provides a structured
for accessing physical memory from an isolated hypervisor Driver Execution Environment (DXE) for drivers and services.
environment (Martignoni et al., 2010; Yu et al., 2012) as These are not loaded from the MBR but from the file system
well as patching the system BIOS for transparently and of a designated EFI System Partition. The location of the
reliably writing out the contents of memory via the pro- respective images are specified in Non-Volatile RAM
cessor's System Management Mode (SMM, Wang et al., 2011; (NVRAM) on the mainboard. Drivers, bootloaders, and the
Reina et al., 2012). An overview and comparison of the in- OS can interact with the firmware through specific pro-
dividual propositions can be found in the work of Vo € mel tocols. After the operating system has started, it still has
and Freiling (2011). access to some firmware interfaces through the so-called
EFI runtime services.
System firmware
PCI option ROMs
The system firmware, i.e., the Basic Input Output System
(BIOS) or the Extensible Firmware Interface (EFI) on more Because the system firmware has no internal knowledge
modern systems, is the first program that runs on the CPU of the functionality and specifics of attached devices,
when a computer is turned on. The respective code is saved complementary code that is required for unique device
in a non-volatile storage area, usually an EEPROM, on the initialization is stored on a separate chip. With regard to
mainboard of the machine. The north- and southbridge are hardware cards that are connected via the PCI bus, the
initially configured to map the contents of this ROM into respective instruction set is saved in a read-only area on the
the physical address space at an architecture-specific device, the so-called PCI Option ROM. In order to be
location inside the first megabyte of the address space.1

2
The boot manager is resident in the Master Boot Record (MBR) on the
1
On most x86 systems this range spans from 0xF0000 to 0xFFFFF. first hard disk.
 J. Stüttgen et al. / Digital Investigation 12 (2015) S50eS60 S53

successfully accessed, a PCI card must implement a System Description Table (RSDT).4 For this purpose, a
configuration space, i.e., 256 bytes of registers that control signature-based scan in memory is applied.5 Once the table
the behavior of the PCI device at all times (Salihun, 2013, p. has been found, pointers to various other important system
9). Part of this space are two special registers at offsets tables can be identified, e.g., to the Fixed ACPI Description
0x04 (Command Register) and 0x30 (Expansion ROM Base Table (FADT) or to the Differentiated System Description Table
Address Register), each of them contains a bit that must be (DSDT). While the former saves the addresses of a number
explicitly set before operations on the ROM can be executed of power management-related register blocks, the latter
(Salihun, 2013). supplies the implementation and configuration informa-
The ROM itself is typically composed of a number of tion about the base system (ACPI Promoters Corporation,
separated code images that apply to different processor 2013, p. 19).
architectures and platforms. For a given machine, always
only one particular image is chosen and run though Rootkit strategies for compromising firmware
(Salihun, 2012). The format and contents of an image are
standardized and incorporate a header and PCI data In this section, we present a survey concerning the
structure (see Salihun, 2006). The header includes a current state of the art in x86 firmware exploitation. We
signature bytestring and a pointer that references the illustrate attacks on the BIOS and EFI environment,
adjacent data structure. The PCI data structure, in turn, is respectively, on PCI Option ROMS as well as ACPI, and
located in the first 64 kilobytes and contains several iden- outline the respective traces that may be recoverable dur-
tifiers with device and vendor information as well as pa- ing memory forensics.
rameters for the image and code size. These values are later While firmware rootkits are highly target-specific and
needed for dynamically fitting the code base into memory. require a lot of in-depth knowledge to develop, malware
Precisely, device-specific tasks are not carried out in-place, authors have demonstrated that building working pro-
but the system firmware rather transfers the image file into totypes is feasible, and various approaches have already
RAM below the 1-MB boundary in the course of the Power- been adopted by different species “in the wild” (Giuliani,
On Self Test (POST).3 A custom INIT function that is invoked 2013).
during this process is responsible for adjusting the image
size to the actual runtime requirements. Thereby, available
memory can be used as efficiently as possible. BIOS- and EFI-Based attacks
For further explanations concerning the previously
described steps, the reader is referred to the official speci- As Bulygin et al. (2014) report, a significant number of
fication (PCI-SIG, 2010). BIOS/EFI attacks were successfully carried out in the past.
Despite update signature verification, secure boot, and other
security measures at the firmware level, many feasible
ACPI attack vectors still exist. In the following, we give a brief
overview of common system compromise strategies.
The Advanced Configuration and Power Interface (ACPI)
defines a platform-independent interface specification Flash protection registers
comprised of both software and hardware elements for When an x86 computer is first switched on, the ROM
device configuration and power management (ACPI containing the firmware is initially writable through the SPI
Promoters Corporation, 2013, p. 4). The interface consists bus. This functionality is necessary to permit legitimate
of three components, i.e., the ACPI System Description Tables, installation of new firmware updates. On the other hand,
the ACPI Registers, and the ACPI BIOS. Moreover, system- before control is handed to the operating system, SPI flash
specific drivers facilitate communication between the must be properly locked down to prevent software from
hardware and software layer and implement methods for overwriting the ROM. However, many vendors fail at these
easily accessing the provided functionality. tasks and leave the respective areas open for manipulation
Of the three interface components, the ACPI System (Bulygin, 2013; Bulygin et al., 2013). As a consequence,
Description Tables are most interesting. They contain malicious code may flash the firmware ROM directly from
structured information about the computing environment, kernel space and incorporate malevolent functionality.
available devices as well as their capabilities, and may be
read out by the operating system-directed configuration and Insecure firmware updates
power management (OSPM) unit. The information is stored Most BIOS update implementations do not require a
in so-called definition blocks and encoded in a special cryptographic signature. They process any source file as
language, the ACPI Machine Language (AML). AML may be long as it matches a given format. This flaw was exploited
converted into the ACPI Source Language (ASL) format for by the Mebromi rootkit to infect versions of Award BIOS
better readability, a step we will describe in more detail in a (Bulygin et al., 2014). In contrast, modern firmware tech-
later part of this paper. nologies based on EFI are more wary of such attack vectors
In order to process a definition block, the OSPM must
first locate a pointer to the main ACPI table, i.e., the Root
4
On modern systems, this structure is superseded by the Extended
System Description Table (XSDT).
3 5
For legacy devices, the image is mapped in the address space between For more information concerning the exact memory locations, please
regions 0xC0000 and 0xDFFFF (see Salihun, 2006). refer to the ACPI specification (ACPI Promoters Corporation, 2013, p. 107).
S54 J. Stüttgen et al. / Digital Investigation 12 (2015) S50eS60

and attempt to verify update requests more rigorously. ROM's), it is possible to consider the respective pages
However, the respective algorithms may contain uninten- during memory acquisition as well.
tional errors and, thus, be susceptible themselves as
Wojtczuk and Tereshkin (2009) argue. ACPI-based attacks

Physical attacks ACPI programs run in kernel space and therefore have
Even with all software measures perfectly implemented, full permission to operate on the physical address space.
a malicious adversary at an arbitrary position in the supply Even though sensitive data structures could theoretically
chain can modify a system's firmware with the help of a be protected efficiently by filtering the respective in-
flash programmer. As recently outlined by Brossard (2012), structions in the AML virtual machine, such restrictions
these tasks can be easily accomplished using open firm- have not yet been implemented in any major operating
ware like Coreboot (Minnich, 2014), SeaBIOS (O'Connor, system to the best of our knowledge. Neither Linux up to
2014), or iPXE (Brown, 2014). kernel 3.15 nor Windows up to version 8 seem to have
security measures in place to prevent ACPI programs from
Memory forensic implications subverting the system core. Because the ACPI tables are
All of the previously described attacks ultimately result provided by the firmware, they are implicitly trusted. In the
in reprogramming of the firmware flash ROM. As laid out in presence of a skilled adversary, this assumption may be
Section System Firmware, the ROM chip is mapped on the potentially devastating.
memory bus from 0xF0000 to 0xFFFFF. It is therefore The vulnerability we have just outlined can be exploited
possible to include said region in a memory image and in several ways: First, it is possible to patch the ACPI tables
analyze the duplicated pages in a later step. directly in the firmware image. In addition, because the
tables are copied to memory and must be identified by the
PCI option ROM-Based attacks operating system, a malicious bootkit has the chance of
modifying them prior to this process. Alternatively, a
Because some PCI devices require custom initialization, manipulated version of the tables can be placed right in
system firmware loads and executes any option ROM pro- front of the firmware-provided copy. Since the location of
vided by devices during boot time. This code runs in firmware the pointer to the Root Description System Table is not
context while SPI flash is unlocked and can therefore patch strictly defined and must be retrieved by the operating
the firmware ROM effortlessly. For instance, as Brossard system with the help of a signature-based scan (see Section
(2012) points out, it is possible to load a bootkit over the ACPI), only the manipulated version is found, while the
built-in Wifi or WiMax devices of the system by flashing a original and legitimate code is never executed. As a
malicious option ROM onto a network card. Thereby, firewalls consequence, an ACPI rootkit may be embedded in either
or intrusion detection systems can be bypassed.
A vulnerable firmware version can also be directly
exploited over the network: Triulzi (2010) outlines tech-
niques for remotely reflashing the firmware of specific
network cards. Even worse, because PCI devices have un-
restricted access to physical memory, additional malicious
code may be downloaded in order to further propagate into
the local network.
Last but not least, a system may also be compromised
using a malicious device that is attached over a hardware
port and initiating a subsequent reboot. For example,
Loukas (2012) shows how an Apple computer may be
infected with malware by connecting a small ethernet
adapter to the Thunderbolt port. Because Thunderbolt
hardware has direct access to the PCI bus and, thus, to
physical memory, the machine is prone to attack, in cor-
respondence to our previous explanations.

Memory forensic implications

The different attacks outlined above result in the
introduction of one or more new PCI Option ROMs into the
system. Firmware maps these ROMs somewhere into the
physical address space and stores a pointer to their location
in PCI configuration space. Similarly to the firmware ROM,
Option ROMs can also be read over the memory bus, and
thus, their code can also be included in a memory image. In
addition, because firmware copies Option ROMs for
execution purposes into the memory area between ad-
dresses 0xC0000 and 0xE0000 (see Section PCI option Fig. 1. Firmware memory ranges.
 J. Stüttgen et al. / Digital Investigation 12 (2015) S50eS60 S55

the firmware ROM on the mainboard, in any PCI option mode by setting the eax register to 0xE820 and repeatedly
ROM, on a connected PCI device, or even as part of an EFI invoking interrupt 0x15. This method is usually applied by
driver module. Detection and removal of such a threat is the boot manager, and the retrieved information is passed
cumbersome, and most of the described methods even to the operating system for further processing. During
survive a complete wipe of the hard disk. runtime, it is not advisable to manually switch to real mode
A proof of concept implementation of an ACPI rootkit for from a driver as this can cause system instabilities. Fortu-
the Linux kernel has already been published (see Heasman, nately, since Windows Vista, the kernel's Hardware
2006). The rootkit hooks all unused system calls by over- Abstraction Layer (HAL) includes an undocumented BIOS
writing the sys_ni_syscall() function with the in- emulation module that permits drivers accessing BIOS
structions call ebx; ret;. Because the ebx register is services directly (Chappell, 2010).
controlled by code running in user space, effectively all
programs with an arbitrary privilege level are able to Enumeration of the physical address space
execute code in kernel space. The concept can be used to,
e.g., illegitimately gain additional permissions or load Each memory enumeration method provides a unique
additional kernel rootkits even in case kernel module view of the physical address space. None of them is entirely
loading has been disabled. However, at the point of this accurate though, because most devices (especially on the
writing, we are not aware that these insights are being PCI bus) are not directly managed by the operating system
actively abused by malicious programs in the wild. but by a vendor-supplied driver. In Fig. 2, a direct com-
parison of three major sources of information on the
Memory forensic implications physical address space is shown.
Irrespectively of the original attack vector, the ACPI ta- The most incomplete view of the physical address space
bles must be placed into RAM in order for the operating is returned when querying the MmGetPhysicalMemor-
system to find and execute them. As a consequence, they yRanges() API in the windows memory manager. As we
can be included into a memory image. If the tables are have argued in the previous section, memory imaging
supplied by the firmware or a malicious Option ROM, all programs only acquire those ranges that are identified as
firmware ROMs should be included in the memory image. being available by the operating system. For safety reasons,
other areas are ignored, including regions of memory that
Firmware in the physical address space are used by the firmware. For this reason, memory images
obtained through this method are not suited for firmware
As we have indicated in the previous sections, there are examinations. With respect to a test system that we have
many regions in the physical address space that contain analyzed, a created memory image only contains two
firmware code and data. A typical layout of the address ranges of physical memory (see Fig. 2 on the right). The
space, taken from a test machine, is illustrated in Fig. 1. In remaining regions in the image are either zero-padded or
the figure, regions that are not highlighted contain physical not part of the image at all (e.g., when using the crash dump
RAM and are marked as “Memory”. Such regions are approach (Microsoft Corporation, 2011)).
generally considered by standard physical memory acqui- As depicted in the center part of Fig. 2, the BIOS provides
sition solutions. In contrast, regions colored in blue contain a better view of the physical address space. Additionally to
firmware code or data. As we have pointed out, these re- the memory regions identified by the memory manager,
gions can also be accessed through the memory bus and the BIOS also keeps track of memory used by ACPI.
have to be duplicated if firmware analysis should be Furthermore, there are 3072 bytes of memory right at the
included in the memory forensic investigation. Finally, re- end of the first memory region that the operating system
gions marked in red represent memory-mapped I/O areas does not know about. This area represents hidden memory
and must not be touched as even read operations on these that is simply neither used by the BIOS nor the OS (Stüttgen
addresses may trigger interrupts on the device and, thus, and Cohen, 2013).
lead to data corruption or unintentional system crashes. In EFI offers a similar service to the BIOS memory map.
the worst case, the interrupt may cause the device to However, because it is a boot service, it is not available
exceed its operational parameters, and physical damage is anymore once the boot manager has handed control to the
caused. operating system. The layout and classification of memory
ranges is the same though.
Firmware acquisition using memory forensics The most exhaustive map of the physical address space
can be constructed by intersecting knowledge from the
As pointed out in Section Memory Acquisition Process, architecture specifications with an enumeration of PCI
memory acquisition software commonly relies on the configuration space. This view is illustrated on the left side
operating system to identify and map physical memory. of Fig. 2: As discussed in Section System Firmware, the
Precisely, imaging programs duplicate solely those parts of physical address space layout in the first megabyte is well-
the address space that are explicitly marked as RAM. On defined. Areas that are reported here as being “reserved”
Microsoft Windows, the respective regions are usually (or not available at all) are either firmware code, firmware
identified using the MmGetPhysicalMemoryRanges() data, or video memory. Please note that the mentioned
API (Stüttgen and Cohen, 2013). However, further but less firmware ROMs in these regions are not actually mapped
common methods do exist: On systems with a BIOS, for ROMs anymore. Due to performance reasons, firmware
instance, the firmware memory map may be queried in real migrates into memory during initialization (see Sections
S56 J. Stüttgen et al. / Digital Investigation 12 (2015) S50eS60

System Firmware and PCI option ROM's). It is therefore safe MmMapIOSpace() on Windows, respectively, we prefer to
to read from these addresses and perform memory acqui- completely bypass the operating system for accessing de-
sition just like with regions that are explicitly marked as vice memory. If an area of memory has already been
RAM. mapped by a driver or even the kernel itself, care has to be
The memory layout above the first megabyte is not taken to conform to caching attributes in order to avoid
defined and depends on the amount of installed memory as memory corruption. The Windows kernel will actually
well as on the number of installed devices. Because the prevent any attempts to map memory that has already
latter map registers and memory into this part of the been mapped with different caching attributes, thus mak-
address space, simply iterating through the entire area ing use of standard operating system memory-mapping
would be a dangerous process since the respective opera- facilities unreliable (Vidstrom, 2006).
tions could trigger interrupts and result in undefined Our method of memory acquisition is based on direct
behavior, loss of data, or even physical damage to the de- remapping of page table entries with a kernel module (see
vice (see Section Firmware in the Physical Address Space). Stüttgen and Cohen, 2013). When a page is about to be
Therefore, in order to avoid instabilities, software needs to acquired, the module remaps a page in its data segment to
consult the firmware or operating system upon what areas point to the physical page in question by directly manipu-
are safe to read (Stüttgen and Cohen, 2013). lating the corresponding page table entry. After flushing
Because the ACPI tables lie somewhere outside of the the Translation Lookaside Buffer (TLB), the driver can then
memory regions reported by the operating system, it is read the desired page by reading from the data segment.
prudent to acquire as much memory from the upper part as Because this method uses a separate mapping and is
safely possible. Furthermore, it is trivial for malware to guaranteed to only read from this mapping, we can avoid
hook the kernel memory enumeration APIs and hide from running into problems with cache coherence and align-
the acquisition. Because the real danger of accessing ment requirements (Stüttgen and Cohen, 2013). In addition,
memory outside the available regions comes from touching because the mapping is manually created and the memory
PCI device memory, it is best to simply exclude all MMIO management APIs are bypassed, the operating system is
regions and acquire all remaining sections. unable to interfere with these operations as already indi-
Stüttgen and Cohen (2013) have shown that it is cated. The resulting memory image contains the entire
possible to find all MMIO regions of PCI devices by memory, firmware code and data, and can be analyzed with
enumerating the PCI configuration space. As explained in standard memory forensic suites such as Rekall (Cohen,
Section PCI option ROM's, all PCI devices must implement 2013) or Volatility (Walters, 2009).
such a space with special address registers that specify the We have implemented the previously described tech-
exact location and size of all MMIO regions (PCI-SIG, 2010). niques in the free, open-source memory acquisition utili-
As long as these regions remain untouched, it is safe to read ties Winpmem and Pmem (Cohen, 2013). With the help of
from any other address in the entire physical address these utilities, firmware code and data on both Windows
space.6 and Linux can be efficiently acquired.
To sum up, the blue regions (in web version) on the left
of Fig. 2 do not necessarily contain RAM. Reading from parts Firmware analysis
of the physical address space that are not mapped simply
returns zeroes.7 The resulting image is significantly larger Firmware implementation is highly dependent on the
than an image that solely comprises ranges being marked platform. Even executable formats and code compression
as available but includes the entire firmware code and data. schemes vary wildly from vendor to vendor. It is out of the
For this reason, we deem this trade acceptable. scope of this paper to present generic firmware code
analysis and verification solutions. However, since most of
the locations of firmware code are clearly defined, it is
Mapping of memory and firmware regions trivial to disassemble these, e.g., using the dis plugin of the
Recall framework (Cohen, 2013). ACPI code on the other
Some of the firmware regions in the physical address hand allows for more automation on the analysis side. We
space we have identified are in fact RAM. The BIOS area, have created two plug-ins for both Volatility and Rekall.
ACPI tables, and the legacy PCI Option ROM area in the first One plug-in permits extracting the ACPI tables from a
megabyte are stored in memory and can therefore be memory image, a second plug-in facilitates scanning the
accessed with the help of conventional methods like respective tables for potential rootkits. To extract the
kmap(). Others are part of the memory-mapped I/O space different tables, we have mirrored the process used by the
which may lead to problems with standard memory- OSPM unit. Specifically, a signature-based scan for the Root
mapping functions due to caching constraints. While it is System Description Table (RSDT) is performed (see Section
possible to use the iomap_nocache() API on Linux or ACPI). Once the RSDT is found, we process the respective
pointers to locate associated ACPI structures. All tables are
finally saved to the file system for further analysis.
6
There can be non-PCI devices in the address space, e.g., HPET, RTC, or With respect to the latter task, we first decompile and,
APIC. In our experiments we found no indication that reading from their
in a second step, examine the tables for signs of malicious
mapped registers caused any problems.
7
It is possible that some systems return another pattern or even data
behavior. The central technique for manipulating kernel
that is still on the bus from a previous read. However, we have not wit- memory from an ACPI program is the definition of so-called
nessed such behavior during our tests. operating regions. Such regions determine which part of
 J. Stüttgen et al. / Digital Investigation 12 (2015) S50eS60 S57

Fig. 2. Physical memory layout views.

the address space will be modified. Our method for ! A virtual machine based on VirtualBox with 2 GBs of
detecting malicious behavior is thus to identify all opera- RAM running Windows 7 SP1 x64
tion regions that reference kernel memory. In the course of
investigation, an analyst may then use this information to All acquisition operations were successfully completed
particularly focus on these parts of the ASL program. every time. We could identify the firmware regions in every
Our plug-in utilizes the official AML decompiler (Intel image with corresponding data. We were not able to verify
Corporation, 2014a) to transform the AML code into ACPI the firmware though, because we did not have access to
Source Language. Subsequently, the resulting ASL code is EEPROM reprogramming hardware and, thus, did not have
scanned, and all operation regions referencing critical access to the original contents of the firmware ROM.
memory are flagged as suspicious, i.e., parts of physical Additionally, because most firmware implementations are
memory that contain kernel code and data. compressed to save space, proper verification would
require reverse engineering of the firmware compression
Evaluation algorithm and analysis of the decompressed ROM image. To
establish correct firmware acquisition without access to the
We have evaluated the created acquisition utilities for ROM nonetheless, we leveraged features of virtualization
stability, correctness, and, in case of the ACPI triage plug- software. Specifically, qemu-kvm (Linux Kernel
ins, for rate of detection and number of false positives Organization, 2014) permits loading custom BIOS images
and negatives as well. over the -bios command line option. With the help of the
-option-rom parameter, it is possible to load a custom
Option ROM as well.
Stability and correctness of the acquisition method We started a qemu-kvm-based virtual machine with a
known BIOS version (SeaBIOS, O'Connor, 2014) and a
To assess the stability and correctness of our approach, known Option ROM (iPXE, Brown, 2014). By acquiring
we set up several physical as well as virtual machines and memory from inside the virtual machine, we obtained an
created duplicates of their physical address space. The image with known BIOS and PCI Option ROM code. We
machines comprised the following configuration: were able to find fragments of the iPXE and SeaBIOS images
in the created memory images at their expected locations.
! A Lenovo x220 notebook with an Intel Sandy Bridge CPU In addition, we could identify parts of the dumped firm-
and 8 GBs of DDR3 RAM running Ubuntu 12.04 x64 ware to come from the supplied ROM images. Other parts
! A Dell workstation with Intel Ivy Bridge CPU and 8 GBs of were heavily modified though and are likely to have been
DDR3 RAM running Windows 8.1 x64 space-optimized in memory. Further experiments are
! A virtual machine based on VirtualBox with 4 GBs of needed in the future to confirm these assumptions.
RAM running Debian 7 x64 with Kernel 3.2.41
S58 J. Stüttgen et al. / Digital Investigation 12 (2015) S50eS60

Comparison with available memory acquisition solutions Table 2

Classification of operation regions in the test data set.
P
We have evaluated a large group of freely-available Correctly classified Falsely classified
memory acquisition solutions to see if they are capable of Malicious 13.0% 16.4% 29.4%
correctly obtaining firmware code and data. The results of Benign 61.9% 61.9%
our evaluation are depicted in Table 1. Thereby, an entry Unknown
P
8.7% 8.7%
labeled with the extension pci means that the respective 83.6% 16.4% 100%

version of the program supports PCI address space

enumeration (see Section Enumeration of the Physical
Address Space). As can be seen, only those two versions the result of a function call, it is impossible to determine
were able to acquire all firmware code and data. All other the target of the operation with static code analysis. Eval-
tools simply imaged the available ranges supplied by the uating those would require the state of the runtime envi-
Windows Memory Manager or, on Linux systems, by the ronment at the given time they are executed. The missing
iomem_resource tree (see Section Memory Acquisition regions can thus not be classified and have to be manually
Process), and do not contain any firmware-related con- analyzed.
tent at all. Our results can be summarized as follows: On the one
hand, due to our plug-in, more than three fifths of all
memory accesses do not need to be examined in detail and
Detection of ACPI rootkits may safely be ignored in the course of an investigation. As
such, forensic practitioners benefit from considerable time
We created a simple ACPI rootkit that is capable of savings and are able to focus on the relevant sections of an
modifying the Linux kernel and setting up a hidden back- ACPI program. On the other hand, with 16.4%, the number
door, analogously to the proof of concept application by of false positives is still rather high. As we have already
Heasman (2006) as described in Section ACPI-Based indicated, these misclassifications stem from the fact that
Attacks. The rootkit was installed on five virtual machines we were unable to distinguish accesses to regions that
running Fedora 19, Ubuntu 12.04, Debian 7, OpenSuse 12.3, belong to legitimate ACPI memory from those that access
and Windows XP as well as two physical Intel Sandy Bridge actual kernel data structures. To decrease the false positive
systems running Ubuntu 12.04. Each system was analyzed rate, an in-depth analysis of the ACPI environment of the
with the help of the scanner plug-in we developed for the kernel would be necessary. For this task, further research in
Volatility framework (see Section Firmware Analysis). the future must be conducted.
Further tests were conducted with non-infected ACPI tables
of original manufacturers as well as manually-manipulated
Discussion
tables that covered a wide range of malicious accesses to
kernel memory. Objective of our experiments was to
Even though our approach is capable of reliably
examine ACPI-related data structures and automatically
dumping all firmware code and data and may be easily
distinguish potentially infected components from legiti-
integrated with existing memory forensic procedures,
mate program parts. In total, 299 operation regions were
practitioners have to be aware of several technological
evaluated. The corresponding results are shown in Table 2.
limitations and pitfalls. A brief discussion of these will be
As can be seen, the scanner flagged 29.4% of all opera-
subject of the following sections.
tion regions as malicious. In reality however, only 13% of
these regions represented true rootkit activity. The
remaining 16.4% were erroneously reported and are due to Technological limitations
legitimate memory accesses in the AML virtual machine. In
contrast 61.9% of the operation regions were correctly Some firmware rootkits cannot be detected with soft-
recognized as benign and do not reference any kernel ware-based memory forensic methods. Any rootkit that
memory. Last but not least, 8.7% of the regions could not be completely isolates itself from the CPU-accessible memory
evaluated because their respective arguments were dy- falls into this category. SMM rootkits, for instance, patch the
namic. If the parameters of a region depend on a variable or BIOS to inject code into System Management Mode. This
code is run when a System Management Interrupt (SMI) is
triggered. The System Management Mode comprises its
Table 1 own address space, i.e., System Management RAM (SMRAM),
Ability of memory acquisition solutions to acquire firmware code and data. and is strictly separated from accesses by kernel or user
Acquisition tool Firmware acquired space applications. The Memory Controller Hub (MCH) en-
Memoryze 7
forces this restriction. By a similar reasoning, malicious
FTK Imager 7 programs running on the Management Engine (ME, Stewin
Moonsols DumpIt 7 and Bystrov, 2012) cannot be discovered.8 The only way
WinPmem 7 of obtaining a copy of the respective memory regions
WinPmem "3 (pci) ✓
WindowsMemoryReader 7
LiMe 7
8
Pmem 7 The Management Engine (ME) is a co-processor on the chipset that is
Pmem (pci) ✓ used to perform administrative tasks. For more information on this topic,
please refer to Kumar (2009).
 J. Stüttgen et al. / Digital Investigation 12 (2015) S50eS60 S59

would be to perform a RAM transplantation attack improvement. We also thank our shepherd Dr. Bradley
(Halderman et al., 2008). For this purpose, physical access Schatz for his guidance in revising the paper.
to the machine and a system reboot would be required. As a
recent study has indicated though, such attacks do not
reliably work on modern RAM technologies such as DDR3 References
anymore (Gruhn and Müller, 2013).
ACPI Promoters Corporation. Advanced configuration and power interface
specification e revision 5.0 errata a. 2013. URL, http://acpi.info/
Anti-forensics
DOWNLOADS/ACPI_5_Errata%20A.pdf.
" Mydlo M. New possibilities for memory acquisition by enabling
Balogh S,
It is also possible for firmware to hide or even wipe dma using network card. In: Proceedings of the 7th IEEE international
malicious code and data from RAM before the acquisition conference on intelligent data acquisition and advanced computing
systems (IDAACS); 2013.
process commences. If the only malicious component that Blunden B. The rootkit arsenal: escape and evasion in the dark corners of
is still in memory at runtime resides in SMRAM, it is pro- the system. Wordware Publishing; 2009.
tected by the MCH and will not appear in the memory Brossard J. Hardware backdooring is practical. 2012. URL, https://media.
blackhat.com/bh-us-12/Briefings/Brossard/BH_US_12_Brossard_
image. Any bootstrapping code in the firmware can be Backdoor_Hacking_Slides.pdf.
wiped from memory after performing its designated task. Brown M. ipxe. 2014. URL, http://ipxe.org/.
In this situation, the only way of acquiring the malicious Bulygin Y. Evil maid just got angrier e why full-disk encryption with tpm
is insecure on many systems. 2013. URL, https://cansecwest.com/
code is by either using a flash programmer to physically slides/2013/Evil%20Maid%20Just%20Got%20Angrier.pdf.
read the ROM chip or running a tool like Copernicus Bulygin Y, Bazhaniuk O, Furtak A, Loucaides J. Summary of attacks against
(Butterworth et al., 2013) if Intel TXT is available. bios and secure boot. 2014. URL, http://www.c7zero.info/stuff/
DEFCON22-BIOSAttacks.pdf.
Bulygin Y, Furtak A, Bazhaniuk O. A tale of one software bypass of win-
Conclusion dows 8 secure boot. 2013. URL, https://media.blackhat.com/us-13/us-
13-Bulygin-A-Tale-of-One-Software-Bypass-of-Windows-8-Secure-
Boot-Slides.pdf.
In this paper we have discussed possibilities for root-
Butterworth J, Kallenberg C, Kovah X, Herzog A. Bios chronomancy: fixing
kits and other sophisticated malicious applications to the core root of trust for measurement. In: Proceedings of the 2013
compromise x86 systems at the firmware level. Although ACM SIGSAC conference on computer & communications security.
yet rarely seen in the wild, these types of attacks are highly ACM; 2013. p. 25e36.
Chappell G. The x86 bios emulator. 2010. URL, http://www.geoffchappell.
dangerous and may be particularly devastating because the com/studies/windows/km/hal/api/x86bios/call.htm.
base of the machine is subverted at a very early point of Cohen M. Rekall memory forensic framework. 2013. URL, http://www.
time and corresponding traces are easily overlooked during rekall-forensic.com/docs/Tools/pmem.html.
Davis M, Bodmer S, Lemasters A. Hacking exposed e malware & rootkits.
typical system investigation routines. As we have seen, McGraw Hill; 2010.
common memory forensic solutions distributed on the Dice P. Quick boot: a guide for embedded firmware developers. Intel
market to date fail to properly acquire the respective Press; 2013.
Embleton S, Sparks S, Zou C. Smm rootkits: a new breed of os indepen-
sources of the physical address space and are therefore ill- dent malware. In: Proceedings of the 4th international conference on
prepared in the course of an incident. We have therefore security and privacy in communication networks; 2008.
suggested alternative techniques for improving current Giuliani M. Mebromi: the first bios rootkit in the wild. 2013. URL, http://
www.webroot.com/blog/2011/09/13/mebromi-the-first-bios-rootkit-
imaging approaches based on PCI introspection and page in-the-wild/.
table entry remapping. Our insights are incorporated in the Gruhn M, Müller T. On the practicability of cold boot attacks. In: Pro-
software products Winpmem and Pmem and will be made ceedings of the 8th international conference on availability, reliability
and security (ARES). IEEE; 2013. p. 390e7.
available in the Rekall memory forensic framework. We
Halderman JA, Schoen SD, Heninger N, Clarkson W, Paul W, Calandrino JA,
have also created two plug-ins for the Volatility and Rekall et al. Lest we remember: cold-boot attacks on encryption keys. In:
forensic frameworks to facilitate inspection of the ACPI Proceedings of the 17th USENIX security symposium; 2008.
environment and discover traces of malevolent behavior Heasman J. Implementing and detecting an acpi bios rootkit. 2006. URL,
http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-
more quickly. Heasman.pdf.
Hoglund G, Butler J. Rootkits: subverting the windows kernel. Addison
Opportunities for future research Wesley; 2005.
Intel Corporation. Acpi component architecture. 2014. URL, https://acpica.
org/.
In spite of our plug-ins, automated methods for Intel Corporation. Intel® 64 and ia-32 architectures software developer's
analyzing the firmware layer for signs of system infections manual. 2014. URL, http://www.intel.de/content/dam/www/public/
us/en/documents/manuals/64-ia-32-architectures-software-devel-
are still sparse. For this reason, a strong focus should be put oper-manual-325462.pdf.
on identifying and developing additional detection capa- Intel Corporation. Trusted compute pools with intel® trusted execution
bilities. Moreover, in order to discover ACPI-related threats technology (intel® txt). 2014. URL, http://www.intel.com/content/
www/us/en/architecture-and-technology/trusted-execution-
more efficiently, creating an emulator for naturally pro- technology/malware-reduction-general-technology.html.
cessing the ACPI Machine Language (AML) would prove Kovah X, Butterworth J, Kallenberg C, Cornwell S. Copernicus 2: senter the
fruitful. dragon. 2014. URL, http://www.mitre.org/publications/technical-
papers/copernicus-2-senter-the-dragon.
Kumar A. Active platform management demystified: unleashing the
Acknowledgments power of intel VPro (TM) technology. Intel Press; 2009.
Ligh MH, Adair S, Hartstein B, Richard M. Malware analyst's cookbook and
We would like to thank Ben Stock and Prof. Dr.-Ing. Felix DVD: tools and techniques for fighting malicious code. Wiley Pub-
lishing; 2010.
Freiling for reading a previous version of this paper and Linux Kernel Organization. Kernel virtual machine. 2014. URL, git://git.
giving us valuable feedback and suggestions for kernel.org/pub/scm/virt/kvm/kvm.git.
S60 J. Stüttgen et al. / Digital Investigation 12 (2015) S50eS60

Loukas K. De mysteriis dom jobsivsemac efi rootkits. 2012. URL, http://ho. Tereshkin A, Wojtczuk R. Introducing ring -3 rootkits. 2009. URL, http://
ax/De_Mysteriis_Dom_Jobsivs_Black_Hat_Paper.pdf. www.blackhat.com/presentations/bh-usa-09/TERESHKIN/BHUSA09-
Maartmann-Moe C. Adventures with daisy in thunderbolt-dma-land: Tereshkin-Ring3Rootkit-SLIDES.pdf.
hacking macs through the thunderbolt interface. 2012. URL, http:// Triulzi A. The jedi packet trick takes over the deathstar. 2010. URL, http://
www.breaknenter.org/2012/02/adventures-with-daisy-in- www.alchemistowl.org/arrigo/Papers/Arrigo-Triulzi-CANSEC10-
thunderbolt-dma-land-hacking-macs-through-the-thunderbolt- Project-Maux-III.pdf.
interface/. UEFI Forum. Unified extensible firmware interface specification. 2014.
Martignoni L, Fattori A, Paleari R, Cavallaro L. Live and trustworthy URL, http://www.uefi.org/sites/default/files/resources/2_4_Errata_B.
forensic analysis of commodity production systems. In: Proceedings pdf.
of the 13th international conference on recent advances in intrusion Vidstrom A. Forensic memory dumping intricacies e physicalmemory, dd,
detection (RAID); 2010. and caching issues. 2006. URL, http://ntsecurity.nu/onmymind/2006/
Microsoft Corporation. Windows feature lets you generate a memory 2006-06-01.html.
dump file by using the keyboard. 2011. URL, http://support.microsoft. Vieler R. Professional rootkits. Wrox Press; 2007.
com/?scid¼kb%3Ben-us%3B244139&x¼5&y¼9. Vo
€mel S, Freiling FC. A survey of main memory acquisition and analysis
Microsoft Corporation. Deviceyphysicalmemory object. 2013. URL, techniques for the windows operating system. Digit Investig 2011;
http://technet.microsoft.com/en-us/library/cc787565%28v¼ws.10% 8(1):3e22.
29.aspx. Vo
€mel S, Freiling FC. Correctness, atomicity, and integrity: defining
Minnich R. Coreboot. 2014. URL, http://www.coreboot.org/. criteria for forensically-sound memory acquisition. Digit Investig
O'Connor K. Seabios. 2014. URL, http://www.seabios.org/SeaBIOS. 2012;9(2):125e37.
PCI-SIG. Pci firmware 3.1 specification. 2010. URL, https://www.pcisig. Vo
€mel S, Stüttgen J. An evaluation platform for forensic memory acqui-
com/specifications/conventional/pci_firmware/. sition software. In: Proceedings of the 13th annual DFRWS confer-
Reina A, Fattori A, Pagani F, Cavallaro L, Bruschi D. When hardware meets ence; 2013.
software: a bulletproof solution to forensic memory acquisition. In: Walters A. Volatility framework. 2009. URL, https://github.com/
Proceedings of the 28th annual computer security applications con- volatilityfoundation/volatility.
ference; 2012. Walters A, Petroni NL. Volatools: integrating volatile memory forensics
Salihun D. BIOS disassembly Ninjutsu uncovered. A-List Publishing; 2006. into the digital investigation process. In: Proceedings of black hat DC;
Salihun D. Malicious code execution in pci expansion rom. 2012. URL, 2007.
http://resources.infosecinstitute.com/pci-expansion-rom/. Wang J, Zhang F, Sun K, Stavrou A. Firmware-assisted memory acquisition
Salihun D. System address map initialization in x86/x64 architecture part and analysis tools for digital forensics. In: Proceedings of the sixth
1: pci-based systems. 2013. URL, https://sites.google.com/site/ international workshop on systematic approaches to digital forensic
pinczakko/bios-articles/System%20Address%20Map%20Initialization% engineering (SADFE); 2011.
20in%20x86_x64%20-%20Part%201.pdf?attredirects¼0&d¼1. White A, Schatz B, Foo E. Integrity verification of user space code. In:
Shields T. Survey of rootkit technologies and their impact on digital Proceedings of the 13th annual DFRWS conference; 2013.
forensic. 2008. URL, http://www.donkeyonawaffle.org/misc/txs- Wojtczuk R, Tereshkin A. Attacking intel® bios. 2009. URL, https://www.
rootkits_and_digital_forensics.pdf. blackhat.com/presentations/bh-usa-09/WOJTCZUK/BHUSA09-
Stewin P, Bystrov I. Understanding dma malware. In: Proceedings of the Wojtczuk-AtkIntelBios-SLIDES.pdf.
9th international conference on detection of intrusions and malware, Yu M, Lin Q, Li B, Qi Z, Guan H. Vis: virtualization enhanced live forensics
and vulnerability assessment (DIMVA); 2012. acquisition for native system. Digit Investig 2012;9(1):22e33.
Stüttgen J, Cohen M. Anti-forensic resilient memory acquisition. In: Pro- Zhang L, Wang L, Zhang R, Zhang S, Zhou Y. Live memory acquisition
ceedings of the 13th annual DFRWS conference; 2013. through firewire. Forensics Telecommun Inf Multimedia 2011;56:
Sylve J. Lime e linux memory extractor. In: Proceedings of the 7th 159e67.
ShmooCon conference; 2012.