d i g i t a l i n v e s t i g a t i o n 6 ( 2 0 1 0 ) 9 5 – 1 .docx

d i g i t a l i n v e s t i g a t i o n 6 ( 2 0 1 0 ) 9 5 – 1 0 3
a v a i l a b l e a t w w w . s c i e n c e d i r e c t . c o m
j o u r n a l h o m e p a g e : w w w . e l s e v i e r . c o m / l o c
a t e / d i i n
Using a software exploit to image RAM on an
embedded system
J.R. Rabaiotti*, C.J. Hargreaves
Centre for Forensic Computing and Security, Cranfield
University, Shrivenham, UK
a r t i c l e i n f o
Article history:
Received 15 December 2009
Received in revised form
8 January 2010
Accepted 19 January 2010
Keywords:
Memory imaging
Live forensics
Exploits
Games consoles

Xbox
* Corresponding author.
E-mail addresses: [email protected]
1 Microsoft did eventually supply some
completed. None of the information provide
1742-2876/$ – see front matter ª 2010 Elsevi
doi:10.1016/j.diin.2010.01.005
a b s t r a c t
The research in this paper is the result of a court case involving
copyright infringement,
specifically, a request for expert evidence regarding the
proportion of copyrighted data
present in the RAM of a games console. This paper presents a
novel method to image the
memory of an embedded device (a games console) where normal
software and hardware
memory imaging techniques are not possible. The paper
describes how a buffer overflow
exploit can be used in order to execute custom code written to
create an image of the
console’s memory. While this work is concerned with the
Microsoft Xbox, the principles of
vulnerability enabled data acquisition could be extended to
other embedded devices,
including other consoles, smart phones and PDAs.

ª 2010 Elsevier Ltd. All rights reserved.
1. Introduction (such as a pirated game) that would otherwise be
prevented
This paper describes research conducted as a result of a case
at the Court of Appeal involving the sale of ‘modchips’ for
games consoles, specifically the original Microsoft Xbox, the
Sony PlayStation 2 and the Nintendo GameCube. One aspect
of the case was concerned with whether a modchip counted
as a ‘device for circumventing an Effective Technological
Measure’ (ETM) within the meaning of Section 296ZA of the
Copyright, Designs and Patents Act 1988 (as amended), which
makes it a criminal offence to sell such devices. This was not
clear-cut, since the modchips did not enable the production of
a physical copy of a console game from its original protected
optical disc onto another permanent storage medium.
However, the Crown argued at the original trial that the
modchip caused an infringing copy to be made in the
console’s RAM since it permitted the execution of a program
.uk (J.R. Rabaiotti), c.j.har
technical information ab
d is included in this pape
er Ltd. All rights reserved

from executing by the ETM. This point was disputed by the
appellant, and so the court asked for expert evidence, specif-
ically concerning the proportion of the contents of a game disc
that would typically be copied into RAM during the execution
of a game.
In many cases of this nature, the easiest option is to ask the
manufacturers for assistance. However, in this case the
console manufacturers were already acting as expert
witnesses for the respondent, so independent research was
desirable.1 It was therefore necessary to rely on public domain
information and original research.
This paper outlines the research conducted to determine
the amount of data present in memory and focuses on the
challenge of obtaining a memory image from one of the
consoles. This is relatively trivial on a standard PC using one of
many memory imaging techniques, but is very difficult on
[email protected] (C.J. Hargreaves).
out the Xbox, but only after the research described here was
r.
.

mailto:[email protected]
mailto:[email protected]
http://www.elsevier.com/locate/diin
a ‘closed system’ such as a games console. This difficulty is
not necessarily restricted to games consoles and embedded
systems generally present a number of unique challenges for
memory imaging. Firstly, the manufacturers of the embedded
device may allow only pre-authorised and digitally signed
programs to run, which may not include imaging tools.
Secondly, the operating systems of embedded devices may
not include the sort of features which make software-based
memory imaging possible on desktop operating systems.
Thirdly, embedded systems are far less standard in design
than desktop computers, and may have no standardised or
easily-accessible interfaces to allow hardware memory
imaging tools to be attached.
Of the three consoles in question, the Xbox is the most
appropriate to examine for research purposes due to the

abundance of public domain information on the console. This
is largely as a result of the development of third-party
operating systems for the console (Steil et al., 2006). While this
paper focuses on the original Xbox, which is now obsolete,
similar techniques to the ones described in this paper are
almost certainly applicable to the other consoles in the case,
to current-generation games consoles such as the Xbox 360
and the Nintendo Wii, and to other embedded devices
(this point is expanded on in Section 6.2).
This paper describes the acquisition of a memory image
from an Xbox console thorough the exploitation of a buffer
overflow vulnerability in a game; this allows arbitrary code to
be executed – in this case, custom memory acquisition code.
The paper includes the technical details of this approach as
well as a discussion of its advantages and disadvantages. The
general principle of using exploits to allow the acquisition of
data may be useful on any system which has an authentica-
tion mechanism to prevent non-manufacturer-approved

programs from being executed. As is shown in this research, if
an exploitable vulnerability is discovered within a pre-
approved program then the device’s code authentication
mechanism does not need to be subverted. This is because
code may simply be injected into the vulnerable program
while it is running, after it has already been authenticated.
This paper is organised as follows: firstly background
information is provided about the Xbox, including details of its
code authentication mechanisms. This is followed by
a discussion of related work, including forensic analyses of
Xbox consoles, existing software and hardware memory
acquisition techniques and the reasons why they are not
appropriate in this case. The methodology for the exploit
based approach is then detailed followed by the results.
Finally the results are evaluated and the advantages and
disadvantages discussed, together with potential future work.
2. Background
2.1. Terminology
The term ‘exploit’ is used in this paper to denote a method for

using a hardware or software security vulnerability to execute
arbitrary code. Exploits are often used for illicit purposes such
as hacking, spreading malware, or running illegally-copied
software on a games console. On embedded systems exploits
are typically used to circumvent manufacturer-imposed
restrictions. For example, the ‘jailbreaking’ of Apple iPhones
allows unapproved applications to run, since applications for
standard iPhones must be approved and digitally signed by
Apple and downloaded via the official App Store. For further
information on jailbreaking see http://blog.iphone-dev.org/.
Such circumvention is discussed as a possible data acquisition
technique for iPhones in Kubasiak and Morrissey (2009).
2.2. The Xbox
The Xbox was a games console produced by Microsoft and
sold between 2001 and 2006, when it was supplanted by the
Xbox 360. It used an Intel Celeron 733 MHz processor and had
64 MB of RAM. Games were distributed on optical discs
(the format was a variant of DVD9), but the console also

possessed an 8 GB internal hard drive. Since the Xbox shared
many architectural similarities with a standard Intel-based
PC, groups of hackers quickly took an interest in it, and soon
organised themselves as the Xbox Linux Project (Steil et al.,
2006) to produce a version of Linux for the Xbox. In order to
do this, the various systems for stopping unapproved
programs had to be circumvented. These security systems are
fully described in Huang (2003) and Steil (2005), but a brief
outline is now presented.
When the console is switched on, a checksum is used to
verify the integrity of the firmware. The firmware contains the
Xbox Kernel in compressed form, and if the verification is
successful, this is decompressed to RAM and begins to
execute. The kernel determines if a genuine game disc is
present in the optical drive, and if so, loads the game program
which then executes. If no game disc is present, a program
called the Dashboard is loaded from the hard drive.
Game programs and the Dashboard are Xbox executables

(XBEs), which have the file extension ’.xbe’ and are similar in
structure to Win32 Portable Executable ‘.exe’ files. One of the
differences is that Xbox executables have anti-modification
features. When an XBE file is created, it is signed using a
digital
signature algorithm based on SHA-1 and 2048-bit RSA
(see Robinson, 2005 for the location of the digital signature in
the XBE file header). One half of the RSA key pair is retained
by
Microsoft, and the other half is embedded in every Xbox
kernel. When the Xbox kernel loads an XBE file, it verifies the
digital signature and allows the XBE program to run only if the
signature is correct. Since it is impossible to modify the XBE
file without altering the digital signature, the result is that
only Microsoft-approved programs are allowed to run on an
unmodified console.
XBE programs, when executing, run at the same privilege
level as the kernel code, and only one program may execute at
a time. The program and the kernel share the same ‘virtual

address space’ and as on a standard �86 PC, paging is used to
translate between virtual and physical addresses, but the
Xbox does not use disk-based virtual memory and hence there
is no pagefile on the hard drive. Therefore, the ‘memory’ of the
Xbox can refer to either the contents of the physical RAM, or to
the virtual address space. The Xbox kernel, which is mapped
to virtual address 0�80010000 (corresponding to physical
address 0�10000), provides around 360 low-level Application
Programming Interface (API) functions, many of which are
http://blog.iphone-dev.org/
d i g i t a l i n v e s t i g a t i o n 6 ( 2 0 1 0 ) 9 5 – 1 0 3 97
very similar to the Win32 kernel API. Game programs do not
usually call these functions directly; instead, they call func-
tions in a set of libraries which are statically linked into the
XBE file, and the library functions in turn call the low-level
kernel functions. The use of statically-linked libraries has the
side-effect that all programs built with the official Xbox Soft-
ware Development Kit (SDK) contain Microsoft-copyrighted
library code; this is the reason that third-party programs built
with the official Xbox SDK cannot easily be redistributed.

The security mechanisms protecting the boot process were
initially compromised when the contents of the hidden boot
ROM was captured by monitoring the bus which it travelled
over to reach the processor (Huang, 2003). Subsequently
a number of other weaknesses were found. Since then
a variety of different sorts of modchip have been developed, as
has an entire third-party replacement firmware known as
Cromwell. Exploitable vulnerabilities in games have also been
discovered, which allow third-party code to run without the
need for any hardware modifications and are therefore known
as ‘softmods’. One of the most significant vulnerabilities can
be found in the 2002 Microsoft Game Studios title ‘MechAs-
sault’, and this is described in detail in Section 4.4.
2 http://www.hex-rays.com/idapro/.
3. Related work
Previous forensic work on the Xbox games console such as
Vaughan (2004), Burke and Craiger (2006), and Collins (2007),
has concentrated largely on the challenges associated with the
imaging and analysis of the hard drive, which in this research is

not relevant since only data in memory is of interest.
Publications on forensic memory imaging concentrate on
desktop PCs rather than embedded systems and they can be
discussed in terms of software and hardware approaches. One
software approach is to use a debugger to view memory
contents during the execution of a specific program. Alterna-
tively, on most desktop operating systems the full memory of
the system is exposed as a manipulable device (e.g./dev/mem
in Linux or Device Physical Memory in Windows) which is
accessible using standard API functions. Due to these simple
means of accessing memory, anyone with the necessary skills
and a suitable compiler can write their own memory acqui-
sition software. As a result, software memory imagers for
most desktop systems are widely available.
However, in order to write a program that will run on
a games console it is usually necessary to have the official
SDK, which is normally sold only to established games
programming companies. Also, the digital signatures used on

development consoles normally differ from those used in
retail ones, meaning that games in development must be
re-signed before they will run on a normal console. This
makes deploying memory acquisition software for a games
console a significant challenge.
A number of hardware imaging techniques exist for
desktop PCs. For instance, Carrier and Grand (2004) shows
how a dedicated PCI card may be constructed for the purpose.
However, the Xbox does not have an accessible PCI bus and
this is therefore not of use. There is a Low Pin Count (LPC –
see
Intel, 2002) bus which might be used instead, but given that
detailed information about this aspect of the Xbox hardware is
unavailable, excessive amounts of time would be required to
determine the viability of this approach. Another approach
described in Boileau (2006) uses the IEEE-1394 ‘‘FireWire’’
bus
to gain access to physical memory. However, this approach is
limited even on desktop PCs as it requires IEEE-1394 ports to
be

present, and these are not ubiquitous. There is no IEEE-1394
port on the Xbox. ‘‘Cold Boot’’ methods as described in
Halderman et al. (2008) are theoretically possible, but are
hampered by the difficulty of removing the soldered-down
Xbox RAM chips and the previously-enumerated difficulties of
running imaging software on the console itself.
The ultimate hardware approach would be to use a logic
analyser, or the sort of custom FPGA-based solution used for
bus monitoring in Huang (2003). This would allow monitoring
of the address and data pins of the RAM chips, allowing all the
data read from and written to each chip to be logged. However,
this approach is hampered by two complicating factors. Firstly,
the number of IO lines on Xbox RAM chips, and the speed at
which it would be necessary to sample them, exceeds the
capabilities of reasonably-priced logic analysers and would
have required expensive or custom-built equipment. Secondly,
an enormous amount of sampled data would be generated and
in order to produce a memory image it would need to be

processed extensively. This would involve converting logs of
data transferred in and out of memory into a complete memory
image for a particular point in time. For these reasons, and
given the various time and monetary constraints, this hard-
ware approach is not suitable in this case.
4. Methodology
As a result of the limitations of each of the approaches
described in the previous section, the development of an
original technique is necessary. This section describes the use
of an exploit that uses a buffer overflow in MechAssault’s
savegame file handling code in order execute custom code that
allows access to the memory of the console. It is not known for
certain who originally discovered this vulnerability, but
a presentation given in 2003 by the Xbox Linux Project at the
20th Chaos Communications Congress (Steil et al., 2003)
credits
the discovery to Jeff Mears and also describes similar vulner-
abilities in other games and in the Xbox dashboard program.
This section is structured as follows: first the tools used

during this research are briefly described. This is followed by
a description of the initial work that was performed using the
pre-packaged Linux distribution which is part of the
MechInstaller package from the Xbox Linux project.
The limitations of this approach are outlined, followed by the
details of reverse engineering a similar exploit to allow
custom code to be executed. Finally the development of the
bespoke code to perform the acquisition of memory is
described.
4.1. Tools
Software tools used throughout the research include the
debugger/disassembler IDA Pro,2 which is used for all
http://www.hex-rays.com/idapro/
executable file analysis, along with a hex editor. To discover
exactly how the MechAssault vulnerability is exploited,
a pre-existing exploited savegame file taken from the
‘Krayzie Ndure Installer’ Xbox-Scene News (2006) is ana-

lysed. From this, a new exploit is developed and the open
source assembler NASM3 is used for its assembly. The open
source Xbox development kit OpenXDK4 is used to write the
XBE that is used to dump the Xbox kernel; and the Xbox
Linux utility ‘xbedump’5 is used to sign the XBE file allowing
the kernel dump tool to run (the kernel is dumped to allow
analysis of the functions relating to the savegame signature
process).
4.2. Dumping from within Xbox Linux
The first memory imaging method uses the packaged
‘‘MechInstaller’’ exploit provided by the Xbox Linux Project
(Steil et al., 2007) to load a basic Linux kernel called ‘Emer-
gency Linux’, which provides a variety of standard Linux tools,
including dd, which may be used to dump memory contents
from the/dev/mem device in the usual fashion. However, the
output image file from dd needs to be stored somewhere.
Obviously the memory image could be written to a file on the
Xbox hard drive, but due to the security mechanisms in place,

the Xbox hard disk is difficult to access from other systems,
i.e. to connect to a PC in order to retrieve the data. Instead the
output of dd is piped into netcat, which sends the data across
the network to a remote machine, which has another running
instance of netcat listening on a specific port, redirecting
received data into a file.
Initial images produced in this way are unsatisfactory
because the process of loading even this minimal version of
Linux overwrites significant portions of the Xbox RAM. The
resulting image file thus contains a jumbled mixture of data
originating from Emergency Linux – such as kernel error
message strings, ROMFS6 filesystem tables, and the boot
messages displayed when Linux loads – and data left over
from the game, such as strings referring to texture and sound
files and portions of the game’s executable header. Aside from
such obvious examples, determining which data definitely
originated from Emergency Linux (and hence the memory
footprint of Emergency Linux) is extremely difficult.
Table 1 – Hex dump from a standard MechAssault

savegame file. The file size is stored as 84 18 00 00 and the
digital signature begins 15 41 E1 8C.
4.3. The Krayzie Ndure Installer
While the MechInstaller exploit is heavily obfuscated, other
similar exploits are available that take advantage of the
MechAssault vulnerability. One such exploit is included in the
Ndure Installer from Krayzie (Xbox-Scene News, 2006) which
is a multi-function toolkit which can be used to install
replacement firmware, replacement dashboards, and much
else. One of the methods by which the Ndure Installer may be
loaded is via a MechAssault exploit. This exploit loads and
3 http://www.nasm.us/.
4 http://openxdk.maturion.de/.
5 http://xbox.cvs.sourceforge.net/viewvc/xbox-linux/
xbedump/.
6 ROMFS is a minimal read-only filesystem designed for Linux
boot disks and firmware.
executes any XBE file placed in a specific location, and thus
may be separated from the Ndure Installer and used on its
own to load an arbitrary XBE file. Therefore, if a memory
imaging tool is created as an XBE program, it would be
possible to use this exploit to run the tool. However, this

approach has the limitation that, as discussed in Section 2.2,
the Xbox can run only one process at a time and launching
a new process makes significant changes to the contents of
memory. This is therefore unsuitable.
4.4. The MechAssault vulnerability
Despite the exploit from the Ndure Installer not being ideal for
memory imaging, unlike the MechInstaller exploit, it is not
heavily obfuscated. It can thus be examined and used to
determine the nature of the vulnerability in MechAssault and
how it is exploited.
MechAssault stores user-specific settings, including
saved games, in files on the Xbox hard disk. Savegame files
are located on the Xbox hard drive partition ‘E’. The direc-
tory structure on the E partition is standardised (which
allows the dashboard to manipulate saves for multiple
games), and the Microsoft libraries provide a number of
functions for managing saved games and saving game data
to a file. However, the name and contents of the savegame

data files themselves are game-specific. MechAssault save-
game files are always called ‘MASave.sav’ and are 6276
bytes in length. The pertinent features of the MechAssault
savegame file are described below and a typical example is
given in Table 1.
The beginning of a MechAssault savegame file consists of
a 24-byte header, comprising a 4-byte little-endian integer
representing the file size (84 18 00 00 ¼ 0�1884 ¼ 6276). This
is followed by a 20-byte HMAC-SHA-1 digital signature of the
savegame file. Both of these features may be seen in Table 1.
The remainder of the file consists of the actual savegame
data; however, it is not necessary to understand the
complete savegame file format in order to understand the
exploit. The savegame file shown in Table 1 is created when
MechAssault is first loaded on an Xbox console, and at first is
empty apart from a single entry (‘StartCampaign’). As
gameplay progresses, more entries are made in the file, the
relevant entries consisting of a fixed record structure, defined
as follows:

http://www.nasm.us/
http://openxdk.maturion.de/
http://xbox.cvs.sourceforge.net/viewvc/xbox-linux/xbedump/
http://xbox.cvs.sourceforge.net/viewvc/xbox-linux/xbedump/
struct SAVEGAME_RECORD{
char record_descriptor[64];
char filename[132];
};
The records specify either the names of levels and a file
associated with the level, or the names of movies which
represent the ‘cut scenes’ between each level. Two examples
of movie file records are visible in Table 2.
The movie clip shown at the beginning of the game is
called ‘‘BEGINMOVIE’’ and the associated movie filename is
‘‘OpeningCinema.mgv’’. As gameplay progresses, further
movie sections appear in the savegame file. These filenames
are loaded by MechAssault when the saved game is accessed,
but apparently no length checking is performed on the movie

filename strings. This means that strings longer than
132 bytes are still loaded into memory and will overflow the
buffer allocated for the filename. It is therefore possible to
manipulate the string length such that a particular part of
memory is overwritten by data from the savegame file. In this
case, the return address of the currently executing function is
overwritten by data representing an address of the attacker’s
choice (here, the address 0�386448). Table 3, taken from an
exploit savegame file, shows how this is done (note the long
string of 0xFF bytes terminated by the address in little-endian
format). For a full explanation of how buffer overflows may be
used to execute arbitrary code, see AlephOne (1996), which is
the definitive reference on the subject.
In Table 3 it can be seen that the position corresponding to
the movie filename is filled with 140 0xFF bytes. If the
assumption is correct that a properly-formatted record
contains a movie filename of maximum length 132 bytes,
there are 12 extra bytes here (8 of 0xFF, plus the data which
ends up on the stack, overwriting the return address of the

executing function). This data, which contains a memory
address is always 0�386448. The address refers to the location
in memory where the savegame data is always copied,
specifically the position in memory where the data stored at
offset 0�200 in the savegame file is copied. This can be seen at
the end of Table 3 (‘‘E8 00 00 00 00 5D’’). This instruction
Table 2 – Two movie description sections from
a savegame created at a more advanced stage.
sequence is known as ‘call-to-pop’ and is a common trick for
getting the address of the current instruction. 0x5D is the
machine code for ‘POP EBP’ which is why, in the code shown
in
Section 4.6, memory addresses are calculated relative to the
value in the EBP register. The effect of loading a savegame
constructed in this way is that the code at offset 0�200 in the
savegame file is copied to memory and starts getting
executed; the execution path of the MechAssault program is
thus subverted. Therefore, whatever code is inserted at offset
0�200 in a similarly-crafted savegame file will be executed
when the savegame is loaded.
4.5. Creating a valid savegame file
While it is possible to construct a savegame file to exploit

the vulnerability and execute arbitrary code, in order for the
MechAssault game to successfully load a savegame file, the
savegame file must have a valid digital signature, as seen in
Table 1. If the signature is invalid, MechAssault will present an
error message instead of loading the savegame file. The
signature is calculated using a keyed-hash message authen-
tication code (HMAC), which involves taking an SHA-1 hash of
the savegame data and combining it with a key (see (Krawczyk
et al., 1997) for details of HMAC). The key is 16 bytes in
length
and is generated by the Xbox kernel when the XBE file is
loaded by similarly combining a ‘Title Key’ in the XBE header
with another key from the kernel. In order to sign arbitrary
savegame files, through examination of the MechAssault XBE
program binary and disassembly of the signature functions, it
is relatively straightforward to re-implement these functions
in C and thus create a program that allows arbitrary savegame
files to be signed. With the exploit reverse engineered so that

arbitrary code could be executed and a means to digitally sign
the savegame files, the next stage is to write code that will
acquire the memory of the Xbox.
4.6. Creating an image of memory
Since Xbox XBEs run in kernel mode and do not have their
own separate address space, it is possible simply to read
chunks of memory from this virtual address space and copy
them out to files on the Xbox hard disk using the XAPI
CreateFile() and WriteFile() functions. These functions are
statically-linked library functions within the MechAssault
program, and their addresses can be obtained from the
Table 3 – Constructed exploit savegame file.
MechAssault XBE disassembly listing. Attempting to access
certain parts of the address space causes the Xbox to crash,
and consequently the imaging needs to proceed in small
chunks at a time, closing each chunk file before moving on to
the next; this means that the entire memory image is not lost

if such a crash occurs. Chunks are 1 MB (1 048 576 bytes) in
size, an experimentally-determined figure. Also the Write-
File() function requires the chunk size to be a multiple of 4096.
After dumping is completed, concatenation of the files forms
the complete image file.
This virtual address space memory acquisition is imple-
mented in assembly code. NASM is used to assemble to file in
the correct format for a MechAssault savegame file, with the
code being placed at the offset 0�200 (which gets executed
due to the buffer overflow). A separate program is used to
calculate the HMAC-SHA-1 signature.
Pertinent portions of the assembly code memory imaging
program are given below with explanations. The data items
(variables and string constants) are stored in the savegame file
before the code. The comments in the listing below describe
how variable addresses are calculated.
In this first listing, the sprintf() function is used to create
a filename containing the start address and count of each
chunk. Then the CreateFile() function, which works identi-

cally to the Win32 equivalent, is used to create the file
(the addresses of sprintf() and CreateFile() are taken from
MechAssault and defined as NASM constants):
; variables are located before this point
start:
call base
base: pop ebp
; addresses of variables may now be calculated by
; (ebp þ var - base)
; **
; **
main_loop:
make_filename:
; formatstring ¼ ‘‘U:DUMPSdump%04u-%08X.bin’’
; uses sprintf to create filename for current chunk
; first, push address of current chunk
push dword[ebpþbeginning_address-base]
; then current value of counter
push dword[ebp þ counter-base]
; then the formatstring

lea eax,[ebp þ formatstring-base]
push eax
; then the filename buffer (to store the result)
lea eax,[ebp þ fnamebuf-base]
push eax
; finally, call sprintf(fnamebuf,formatstring,
counter,beginning_address)
mov ebx,sprintf
call ebx
createfile:
; hTemplateFile ¼ NULL
xor eax,eax
push eax
; FILE_ATTRIBUTE_NORMAL
push dword 128
; creationDisposition ¼ CREATE_ALWAYS
push dword 2
; LPSECURITY_ATTRIBUTES ¼ NULL
push eax
; dwShareMode ¼ NULL
push eax

; GENERIC_READ j GENERIC_WRITE
push 0xC0000000
; lpFileName
lea eax,[ebp þ fnamebuf-base]
push eax
mov ebx,CreateFile
call ebx
cmp eax,0xFFFFFFFF
je createfile_error_place
; save filehandle
mov [ebp þ filehandle-base],eax
The error handling code (which is not shown here) simply
involves setting the Xbox LED to flash on and off, using
different permutations of colours to signify different errors.
For example, in the previous listing the return value from
CreateFile() is checked to ensure it is a valid filehandle. If it is
equal to 0xFFFFFFFF (INVALID_HANDLE_VALUE), the jump
is
taken and the program halts with the LED set to a certain
colour. Otherwise, the filehandle is saved in ‘filehandle’.

Next, the address of the current chunk is passed to
WriteFile():
writefile:
xor eax,eax
push eax
; LPOVERLAPPED ¼ NULL
lea eax,[ebpþnumwritten-base]
; NumberOfBytesWritten
push eax
; write increment bytes at a time
push dword[ebp þ increment_size-base]
lea eax,[ebp þ beginning_address-base]
push dword[eax]
; HFile
push dword[ebp þ filehandle-base]
; write the file
mov ebx,WriteFile
call ebx
; abort if an error happens
test eax,eax

je writefile_error_place
close:
push dword[ebp þ filehandle-base]
mov ebx,CloseHandle
call ebx
A zero return value from WriteFile() (detected by the
instruction ‘test eax,eax’) results in an error. Finally, the
address is incremented by 0�100000 (the size of each dumped
chunk) and the process repeats:
do_rest:
; get beginning_address in eax
Table 4 – Strings from the MechAssault game.
mov eax,[ebp þ beginning_address-base]
; add increment size to eax
add eax,dword[ebp þ increment_size-base]
; put back in beginning_address
mov [ebp þ beginning_address-base],eax
; check counter < 4096
; 4096 * 0�100 000 ¼ total theoretical address space
; (obviously not all of this will be valid!)

mov eax,[ebp þ counter-base]
cmp eax,4096
jnb success
inc eax
mov [ebp þ counter-base],eax
jmp main_loop
As mentioned above, this code is assembled into a save-
game file, signed with the correct key, and placed in a directory
on the Xbox E: partition. The MechAssault game is loaded and
the appropriate savegame selected from the Campaign menu.
This loads the file and causes the above code to be executed due
to the buffer overflow exploit described in Section 4.4.
Table 5 – Strings referencing files stored on the
MechAssault game disc.
5. Results and validation
5.1. Results
The program shown in the previous section successfully
acquired memory between the virtual addresses 0�00000000
and 0�033FFFFF, resulting in a 52 MB image file after concat-
enation. The region from 0�80000000 to 0x8FFFFFFF was also
dumped, resulting in a second image file 256 MB in length. Any
attempt to access other regions of virtual memory caused the

Xbox to crash. Obviously, not all of the second image file can
represent actual RAM since as described in Section 2.2 the
virtual address space is larger than physical memory.
Much data obviously originating from the game was
discovered in the first image file, and small samples are given
in Table 4 and Table 5. They show strings which clearly relate
to the game and also strings that specifically reference data
stored on the MechAssault game disc.
5.2. Validation
Validation of the accuracy of any memory dump is a challenge
and is particularly true in this case since multiple methods for
acquisition are not available and therefore results cannot be
compared (e.g. results from dd and firewire on an �86 PC).
However, the correspondence between file offsets in the
acquired image and expected virtual addresses is probably the
best evidence that a reliable image has been created. For
instance, the XBE file could be seen in the memory image at
offset 0�10000. This correlates with the base address 0�10000
in memory where XBE programs are always loaded by the

kernel (determined by disassembly of the Xbox kernel). This
can be seen in Table 6.
Likewise, as shown in Table 7, the kernel is always loaded
at virtual address 0�80010000, and it correspondingly appears
in the second memory image (which began acquisition at
virtual address 0�80000000) at offset 0�10000.
Also in the memory dump it was possible to locate a copy
of the savegame containing the exploit used to execute the
memory imaging code. This was located in the memory image
at the offset that corresponded to the offset in memory which
was hard coded into the exploit (0�00386448). This can be seen
in Table 8. This further suggests that the acquired memory
image was accurate.
The exact mapping of virtual to physical addresses needs
further research to determine the differences from that used
by comparable versions of desktop Windows. It has already
been noted that accessing certain areas of the virtual address
space caused crashes, and it is clearly not possible for all of the
data obtained from the imaging process to have originated

from physical RAM. It is possible that some pages in the dump
files represent the contents of areas reserved for the use of
memory-mapped hardware (such as the sound or graphics
adapters) and thus do not contain any meaningful data. This
would require further analysis to unravel completely, but this
does not detract from the fact that based on the positions of
known data in the memory dump, it seems that an accurate
mapping of the virtual address space during the execution of
the MechAssault game has been produced.
6. Discussion and conclusions
6.1. Evaluation
It is clear that the goal of producing a memory image during
the execution of an Xbox game has been achieved. However,
as with the use of any software-based memory imaging
technique, changes will be made to the RAM. In this case the
use of the various XAPI library functions will cause modifi-
cations, for example, it is likely that file IO uses RAM buffers.
Table 6 – XBE at virtual address and dump file offset

0310000.
Table 8 – Exploit code at virtual address and dump file
offset 03386448.
However, this loss of data is limited to the size of the exploit
and imaging code (up to 6276 bytes) and these IO buffers.
Also, modifying the contents of the hard drive (by writing
the image file portions to it) is not traditionally considered to
be good forensic practice, but in this case, since the hard drive
data is not of interest, this consideration is not relevant. If
necessary, writing to the hard drive could be avoided by
writing the memory data out over an IO bus, but this would be
very much slower. Also, further analysis of the kernel might
allow a USB device to be connected and the imaged data
written to that instead.
A further limitation of this particular imaging code is that
due to the memory management of the Xbox, the virtual
address space has been acquired rather than the physical
RAM. This may or may not be an issue, depending on the

interpretation of ‘the memory’ of the Xbox. In addition, since
the Xbox kernel provides functions which translate between
virtual and physical addresses, a more advanced version of
the dumping exploit could be developed to use these to ensure
that only pages in physical RAM are dumped.
The final and most fundamental technical limitation of the
technique discussed above is that it can be used to image only
the memory of the specific game in which the vulnerability
exists. While this was not a problem in this particular case, it
may complicate attempts to generalise this technique. This is
because most modern operating systems generally isolate
processes in their own virtual address space, and special API
calls (and the correct privilege level) are needed to access the
address space of another process.
General disadvantages associated with the use of exploits
for forensic purposes include the fact that programs con-
taining them may be patched, thus rendering the technique
useless for future versions of the program (for instance, later

releases of the MechAssault game do not contain the vulner-
ability described in this document). Also, understanding and
Table 7 – Kernel MZ and PE headers at offset 0310000
(virtual address 0380010000) in the second memory
image.
deploying exploit code requires a certain degree of technical
skill, since pre-written exploits are often distributed in binary
form, are possibly obfuscated and are provided without any
explanation as to how they work. Exploits of this form are
obviously not reliable from an evidential point of view and
require the use of reverse engineering techniques such as
those described in this paper so that they are understood in
detail. Finally, exploits are commonly associated with hacking
and software piracy, and it is conceivable that the opposing
counsels could use such associations to try to discredit
evidence obtained via such methods in the minds of judges or
juries. However this paper has shown that if an analyst has
a full understanding of the exploit code, the data obtained is at
least as reliable as that obtained using other common soft-
ware based live acquisition techniques.

6.2. Generalising to other systems and future work
While in this paper the focus has been on the original Xbox
console, as mentioned in the introduction, this approach
could also be applied to other consoles. There are similar
exploits available for the Nintendo GameCube (Belvedere,
2004), the Sony Playstation 2 (BadServo, 2005), as well as
newer consoles such as the Nintendo Wii (Wiibrew,
2009a,b,c)). Additionally, both hardware (Free60 Project,
2009b) and software (Free60 Project, 2009a) exploits have
been discovered for the Xbox 360, although a Microsoft firm-
ware update in 2009 has patched many of these. Unlike the
original Xbox, the current generation of games consoles often
contain features such as web browsers and chat clients, both
of which produce data which is potentially of greater interest
to a forensic analyst. Some of the Nintendo Wii exploits are
open-source, meaning that no reverse engineering is neces-
sary in order to have a full understanding of the effect they
will have on a target system, and making them easier to

modify for the purpose of memory acquisition.
In addition to games consoles, this approach could also
apply to other embedded systems that have software
vulnerabilities. This could include smart phones, PDAs,
Internet routers and GPS devices. Finally, this approach could
be used not only to acquire memory of these devices (which
may have limited applications) but also for any other form of
selective data acquisition, e.g. to gain access to data that is
stored in encrypted form on permanent storage, but is avail-
able in decrypted form when the system is running.
6.3. Conclusion
This paper has shown that in cases where hardware approaches
to accessing data on embedded systems are impractical,
software based vulnerabilities can be exploited to execute
arbitrary code and avoid any security restrictions imposed by
the device manufacturer. Code can then be written to perform
the necessary acquisition procedure and executed using an

exploit. This has been demonstrated by acquiring data from the
memory of an Xbox console during the execution of a game.
6.4. Postscript
Although the memory images that were eventually produced
did provide evidence that certain parts of the game disc were
copied into memory, the appeal was dismissed for other
reasons and the technical evidence produced was not
considered (although a portion of the memory image was
printed out as a Section 9 statement and given to the judges at
the trial).
r e f e r e n c e s
AlephOne. Smashing the stack for fun and profit. Phrack(49),
http://insecure.org/stf/smashstack.html, 1996;7 [accessed 04.
12.09].
BadServo. EXPLOITSTATION.Com FAQ. Web site,
http://www.
exploitstation.com/index.php?page¼faq; 2005 [accessed 15
12 09].
Belvedere M. The gamecube ‘‘Phantasy Star Online’’ exploit.
Club
MyCE. Website, http://club.myce.com/f98/gamecube-
phantasy-star-online-exploit-94781/; 2004 [accessed 15.12.09].
Boileau A. Hit by a bus: physical access attacks with firewire.

In:
Presentation at Ruxcon; 2006.
Burke PK, Craiger P. Xbox forensics. Journal of Digital
Forensic
Practice 2006;1:275–82.
Carrier BD, Grand J. A hardware-based memory acquisition
procedure for digital investigations. Digital Investigation 2004;
1:50–60.
Collins D. XFT–a forensic analysis tool for the microsoft Xbox
game console. In: Proceedings of the 6th annual security
conference, April 11–12, 2007, Las Vegas, NV.
Free60 Project. Run code. Wiki page,
http://www.free60.org/Run_
Code; 2009a [accessed 06.01.10].
Free60 Project. SMC hack. Wiki page, http://www.free60.org/
JTAG_Hack; 2009b [accessed 06.01.10].
Halderman JA, Schoen SD, Heninger N, Clarkson W, Paul W,
Calandrino JA, et al. Lest we remember: cold boot attacks on
encryption keys. In: 17th USENIX security symposium; 2008.
Huang A. Hacking the Xbox. No Starch Press; 2003.
Intel. Intel low pin count (LPC) interface specification, revision
1.1.
Tech. Rep.. Intel Corporation; 2002
Krawczyk H, Bellare M, Canetti R. RFC 2104: keyed-hashing
for
message authentication. Tech. Rep. Network Working Group,
http://www.ietf.org/rfc/rfc2104.txt; 1997 [accessed 07.12.09].

Kubasiak RR, Morrissey S. Mac OS X, iPod, and iPhone
forensic
analysis DVD toolkit. Ch. 15(Forensic Acquisition of an
iPhone). Syngress; 2009:355–95.
Robinson A. XBE file format 1.1. Tech. Rep.,
http://www.caustik.
com/cxbx/download/xbe.htm; 2005 [accessed 15.12.09] – this
page is undated, but the Xbox Linux Wiki page containing
the same information (http://www.xbox-linux.org/wiki/XBE_
File_Format) was first published on 13th July 2005.
Steil M. 17 Mistakes microsoft made in the Xbox security
system.
In: Proceedings of the 22nd chaos communication congress;
2005.
Steil M, Jilli D, Esser S, Lehner F, Mears J, Hucek E. Xbox
software
hacking. In: Presentation given at 20th chaos
communications congress, http://sourceforge.net/projects/
xbox-linux/files/Presentations/
20thC%haosCommunicationCongress/20C3-Xbox_Software_
Hacking.pdf/download; December 2003 [accessed 18.12.09].
Steil M, Pye D, et al, 2006. The Xbox linux project FAQ. Wiki
article, http://www.xbox-linux.org/wiki/FAQ, page last
updated 6th February 2006, [accessed 15.12.09].
Steil M, Pye D, et al, 2007. Software method HOWTO. Xbox
Linux
Wiki entry, http://www.xbox-linux.org/wiki/Software_
Method_HOWTO, last updated 17th December 2007 [accessed
15.12.09].
Vaughan C. Xbox security issues and forensic recovery

methodology (using Linux). Digital Investigation 2004;1:165–
72.
Wiibrew. Bannerbomb. Wiki page, http://wiibrew.org/wiki/;
2009a. Bannerbomb, [accessed 15.12.09].
Wiibrew. Indiana pwns. Wiki article, http://wiibrew.org/wiki/
Indiana_Pwns; 2009b [accessed 15.12.09].
Wiibrew. Twilight hack. Wiki entry, http://wiibrew.org/wiki/
Twilight_Hack; 2009c [accessed 15.12.09].
Xbox-Scene News. Krayzie Ndure installer v1.1. website
posting,
http://www.xbox-scene.com/xbox1data/sep/
EEFlyylEypnyXfkSdp.php; January 2006 [accessed 04.12.09].
http://insecure.org/stf/smashstack.html
http://www.exploitstation.com/index.php%3Fpage%3Dfaq
http://club.myce.com/f98/gamecube-phantasy-star-online-
exploit-94781/
http://club.myce.com/f98/gamecube-phantasy-star-online-
exploit-94781/
http://www.free60.org/Run_Code
http://www.free60.org/Run_Code
http://www.free60.org/JTAG_Hack
http://www.free60.org/JTAG_Hack
http://www.ietf.org/rfc/rfc2104.txt
http://www.caustik.com/cxbx/download/xbe.htm
http://www.caustik.com/cxbx/download/xbe.htm
http://www.xbox-linux.org/wiki/XBE_File_Format
http://www.xbox-linux.org/wiki/XBE_File_Format
http://sourceforge.net/projects/xbox-
linux/files/Presentations/20thC%25haosCommunicationCongres

s/20C3-Xbox_Software_Hacking.pdf/download
http://www.xbox-linux.org/wiki/FAQ
http://www.xbox-linux.org/wiki/Software_Method_HOWTO
http://www.xbox-linux.org/wiki/Software_Method_HOWTO
http://wiibrew.org/wiki/
http://wiibrew.org/wiki/Indiana_Pwns
http://wiibrew.org/wiki/Indiana_Pwns
http://wiibrew.org/wiki/Twilight_Hack
http://wiibrew.org/wiki/Twilight_Hack
http://www.xbox-
scene.com/xbox1data/sep/EEFlyylEypnyXfkSdp.php
http://www.xbox-
scene.com/xbox1data/sep/EEFlyylEypnyXfkSdp.phpUsing a
software exploit to image RAM on an embedded
systemIntroductionBackgroundTerminologyThe XboxRelated
workMethodologyToolsDumping from within Xbox LinuxThe
Krayzie Ndure InstallerThe MechAssault vulnerabilityCreating
a valid savegame fileCreating an image of memoryResults and
validationResultsValidationDiscussion and
conclusionsEvaluationGeneralising to other systems and future
workConclusionPostscriptReferences

d i g i t a l i n v e s t i g a t i o n 6 ( 2 0 1 0 ) 9 5 – 1 .docx

Recommended

Recommended

More Related Content

Similar to d i g i t a l i n v e s t i g a t i o n 6 ( 2 0 1 0 ) 9 5 – 1 .docx

Similar to d i g i t a l i n v e s t i g a t i o n 6 ( 2 0 1 0 ) 9 5 – 1 .docx (20)

More from theodorelove43763

More from theodorelove43763 (20)

Recently uploaded

Recently uploaded (20)

d i g i t a l i n v e s t i g a t i o n 6 ( 2 0 1 0 ) 9 5 – 1 .docx