Http www caustik com xbox

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: j.rabaiotti@cranfield.ac

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

greaves@cranfield.ac.uk (C.J. Hargreaves). out the Xbox, but only after the research described here was r. .

mailto:j.rabaiotti@cranfield.ac.uk
mailto:c.j.hargreaves@cranfield.ac.uk
http://www.elsevier.com/locate/diin
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 396

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/
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 398

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/
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 99

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.

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 3100

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:\DUMPS\dump%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.

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 101

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.