Windows Mobile advanced forensics 5 C. Klaver* Netherlands Forensic Institute, Dept. Digital Technology and Biometrics, Digital Technology Group, Postbus 24044, 2490 AA Den Haag, The Netherlands article info Article history: Received 31 December 2009 Received in revised form 9 February 2010 Accepted 10 February 2010 Keywords: Windows mobile NAND flash TFAT file system Live forensics Heap CEDB/EDB database Logical/physical acquisition abstract Windows CE (at this moment sold as Windows Mobile) is on the market for more than 10 years now. In the third quarter of 2009, Microsoft reached a market share of 8.8% of the more than 41 million mobile phones shipped worldwide in that quarter. This makes it a relevant subject for the forensic community. Most commercially available forensic tools supporting Windows CE deliver logical acquisition, yielding active data only. The possi- bilities for physical acquisition are increasing as some tool vendors are starting to imple- ment forms of physical acquisition. This paper introduces the forensic application of freely available tools and describes how known methods of Physical Acquisition can be applied to Windows CE devices. Furthermore it introduces a method to investigate isolated Windows CE database volume files for both active and deleted data. ª 2010 Elsevier Ltd. All rights reserved. 1. Introduction With Windows CE on the market for more than 10 years now, Microsoft has a market share that makes it a relevant subject for the forensic community. The first versions of Windows CE were not very successful on the hand-held electronics market. However, with the release of Windows Mobile 6, based on Windows CE 5.2 (Herrera, 2009), Microsoft has gained a market share of 13.6% of the nearly 40 million mobile phones shipped worldwide in the third quarter of 2008, but appears to be falling in 2009 (Canalys, 2009). Currently most commercial forensic tools that support Windows CE (WCE) acquire data from the device through the standard Remote Application Programmers Interface (RAPI). This results in the acquisition of only the active data. The capturing of deleted data is not possible using just this method. In 2005, PDA Seizure was one of the first tools that supported logical acquisition of WCE devices. Nowadays, other tools like MSAB’s.XRY and Cellebrite’s UFED support logical acquisition of WCE devices. In Ayers et al. (2005), a comprehensive over- view of forensic tools for mobile devices is given. MSAB is implementing physical acquisition of WCE devices in its tool XACT (MSAB). Cellebrite is supporting physical acquisition for Windows CE devices in their Physical-Pro version of UFED (Cellebrite). Since 2003 Hengeveld (2009) is publishing his open source XDA tools. With this toolset, among other things, an acquisition of RAM and flash memory inside WCE devices can be done. All these tools assume a WCE device that is not device locked by a handset security code. Revealing or circumventing security codes is beyond the scope of this paper, but physical acquisition methods like chip extraction, or the use of JTAG or a boot loader, work around handset security codes. More advanced protection of a smart phone would encrypt user data, imposing a new challenge to forensic examination of such a mobile device. This is also beyond the scope of this paper. 5 The Netherlands government is authorized to reproduce and distribute reprints of this paper for governmental purposes notwith- standing any copyright notation there on. * Tel.: þ31 (0)70 888 6423; fax: þ31 (0)70 888 6559. E-mail address: c.klaver@nfi.minjus.nl available at www.sciencedirect.com journal homepage: www.elsevier.com/locate/diin digital investigation 6 (2010) 147–167 1742-2876/$ – see front matter ª 2010 Elsevier Ltd. All rights reserved. doi:10.1016/j.diin.2010.02.001
21
Embed
Windows Mobile advanced forensics - Semantic Scholar · PDF fileWindows Mobile advanced forensics5 ... Live forensics Heap ... a smartphone,whichchipselectlinesareconnectedtowhich
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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 ) 1 4 7 – 1 6 7
ava i lab le at www.sc ienced i rec t . com
journa l homepage : www. e lsev ier . com/ loca te / d i in
Windows Mobile advanced forensics5
C. Klaver*
Netherlands Forensic Institute, Dept. Digital Technology and Biometrics, Digital Technology Group, Postbus 24044,
2490 AA Den Haag, The Netherlands
a r t i c l e i n f o
Article history:
Received 31 December 2009
Received in revised form
9 February 2010
Accepted 10 February 2010
Keywords:
Windows mobile
NAND flash
TFAT file system
Live forensics
Heap
CEDB/EDB database
Logical/physical acquisition
5 The Netherlands government is authorizstanding any copyright notation there on.
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 ) 1 4 7 – 1 6 7150
again. In the heap the status of a memory block(active or free)
can be detected.
The software managing the heap will try to keep the heap
as clean as possible. When N bytes are requested through
a call to ‘malloc(N)’, the heap manager will try to find a free
block (or contiguous free blocks) capable of holding at least
these N bytes. It might try to merge small free blocks into
a bigger free block by rearranging the heap. This is comparable
to the defragmentation process that can be applied to a hard
disk. How well the heap manager succeeds in fitting requested
blocks in free blocks and how well it defragments will influ-
ence the lifetime of data in ‘free’ blocks. In any case it is
possible to find data on the heap, either active or deleted, that
is otherwise not available to the user.
3.3. File systems
Most modern WCE devices are equipped with flash memory
hosting (T)FAT partitions for user data or firmware exten-
sions, and binary partitions with firmware and bootloader
code (Rogers et al., 2005), see Fig. 2. File systems are usually
not stored in NAND flash directly. The OS interfaces with a so
called Flash Translation Layer (FTL), which takes care of
storing File System blocks in NAND flash (Knijff, 2010, p. 390).
When analyzing the storage devices at file system level on
a WCE device, both binary partitions as well as File System
partitions can be found. Under normal use, the only partition
interesting for forensic analysis is the partition containing the
user file system. This partition usually contains a FAT or a TFAT
file system. TFAT is a Transaction Safe variant of FAT (Microsoft
4). As TFAT is transaction safe, sudden power loss, or other
interruptions of changes to the file system, will not lead to
a corrupt file system.
When looking at a TFAT file system image with a forensic
tool like EnCase or Ftk, one can notice that the root directory
the user sees on the WCE device itself is often not the root
directory of the file system. WCE can create a directory called
‘__TFAT_HIDDEN_ROOT_DIR__’ and inside this directory all
files and directories are stored that are seen by the user
(Microsoft 5). This means that the call
CreateFile("\temp\myfile.dat")
resolves to
CreateFile("__TFAT_HIDDEN_ROOT_DIR__\temp
\myfile.dat")
Another noticeable artifact is the presence of many
(deleted) file entries called ‘DONT_DELnnn’, where nnn is
FTLFlash Translation Layer
TFATUser data fs
TFATCustom fs
Firmware Bootloader
Fig. 2 – Flash memory in WCE devices.
a number starting at 000 and counting up. The reason for the
presence of these files is not exactly clear at this moment.
They might be there to make sure that flash erase blocks that
contain parts of File Allocation Tables, only contain FATs, and
not parts of regular files. If regular files share erase blocks with
FATs, changes to such a file will lead to copying that file and
possible reallocation of the FATs to other erase blocks,
possibly causing performance loss of the file system.
The user on a WCE device doesn’t see any of these files or
directories, because the file system drivers hide them from the
user. When analyzing a WCE TFAT file system image with
forensic tools, one can safely ignore the ‘__TFA-
T_HIDDEN_ROOT_DIR__’ and the ‘DONT_DELnnn’ entries.
3.4. Databases
In WCE versions earlier than 4.0, all user data was stored in the
so called ‘object store’. The object store is a database con-
taining the file system, the databases and the registry. The
object store lived in RAM; when power failed, all user data was
lost. From WCE 4.0 on, the roles are reversed; the file system is
now hosting the databases and the registry files. In devices
where this file system is based on flash memory, user data is
less dependent on battery life.
Flash based file systems also allow for easier imaging of the
file system, compared to RAM based storage. After a flash
based file system image has been created from the WCE device,
the databases containing user data can be extracted from the
image. This can be done with normal forensic tools supporting
TFAT; as TFAT is compatible with FAT, most tools will load
TFAT images without problems. Once loaded, the two most
interesting databases are cemail.vol and pim.vol, both located
in the root directory of the file system, as seen by the user.
4. WCE forensic investigation
When found during a criminal investigation, a WCE device has
to be treated just like any other mobile phone. Mostly, the first
goal is to avoid any further changes to the phone as much as
possible. Phone data can be changed for instance by incoming
calls, received text messages, connecting to WiFi/Bluetooth
networks, recorded GPS data and depleted batteries. In order
to avoid these changes, the phone should be isolated from the
GSM and other networks, reception of GPS signals and pow-
ered by an external power supply. A discussion on this subject
can be found in Jansen et al. (2007), chapter 5.3 and 6.
Another cause of changes in phone data lies in the phone
itself. While on, either in active or quiescent state, the phone’s
OS is active. The OS might be trying to manage the various
types of memory in the phone. The flash file system might
rearrange flash pages and erase flash blocks that only contain
expired pages. The heap manager might be trying to rearrange
the heap structure to join small free items into bigger ones. To
stop these processes, the phone has to be powered down, but
this is not always wanted, for instance because it might acti-
vate handset security code, hindering logical acquisition of the
phone, or activate memory rearranging or garbage collection.
Once connection to networks is properly prevented, data
on the WCE device can be acquired. As mentioned already,
Table 1 – Relative risks for data during logical and physical acquisition.
Risks Physical acquisition Logical acquisition
Chip extraction(damaged chip)
JTAG(damaged PCB,
‘bricking’)
Bootloader(‘bricking’)
Active data High High High Low
Deleted data High High High –
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 ) 1 4 7 – 1 6 7 151
two types of acquisition can be distinguished, physical
acquisition and logical acquisition. Depending on the inves-
tigation, it has to be decided which of the two has to be done
first, because either acquisition types have their own advan-
tages and disadvantages.
Physical acquisition can be a destructive operation. True
physical acquisition can either mean physically removing
memory from the device, using hardware techniques like
JTAG to extract data from the device or use an (adapted)
bootloader to gain low level access to the device. Most of the
physical data extraction methods hold some risk of destroying
data, the device or both.
For WCE devices there are ways to do an acquisition that is
somewhere in between a physical acquisition and a logical
acquisition. A copy can be made of the flash file system over an
ActiveSync connection. This requires a dedicated dll to be
loaded into the system under investigation, thus overwriting
RAM and possibly flash memory. The result however is an image
at file system level and not at flash hardware level. Because of
this, only unallocated clusters that reside in active flash pages
are in the image. Expired flash blocks that are no longer part of
the file system but still might contain data will not be copied. In
this paper, it is referred to as pseudo physical acquisition.
Logical acquisition is generally safer for active data. It does
not have the risks of losing all active data because of risks
involved in physical extraction. However, setting up an
ActiveSync connection to do a logical acquisition can change
data related to the ActiveSync connection itself. Another
downside is that during logical acquisition deleted data, that
still resides in the system, might be erased beyond recovery.
Because logical acquisition uses the system that is being
investigated, the processes in the phone that are used during
acquisition are using memory, RAM and possibly flash.
Another cause of permanent loss of deleted data is active
Wear Leveling and Garbage Collection in a working system.
Garbage Collection is a phenomenon that occurs in RAM,
where blocks of data that are no longer referred to by pointers
are freed by the OS and made available for reuse.
Sometimes logical acquisition is not possible, for instance
when the device is broken beyond repair, or when the device
does not have a standard interface to do the logical acquisition
over.
In cases where active data might be enough for the investi-
gation, doing a logical acquisition and a pseudo physical
acquisition on a WCE device before doing a physical acquisition
is the safest way to go. The risk of changing or destroying some
deleted data due to logical acquisition is then regarded less than
the risk of loosing all data in a physical acquisition. Table 1
shows relative risks for active and deleted data in physical and
logical acquisition. When executed by an experienced
investigator, and when a reference model is available, the
absolute risks of physical extraction are acceptable.
Physical acquisition might be the only option in cases where
there is an active phone lock or a non functioning phone.
Physical acquisition methods generally work at a low level and
are not hindered by the phone lock. The NAND flash of a broken
phone might still be working, allowing physical chip extraction.
There might be other situations where it is necessary to first
do a physical acquisition; when there is strong indication that
the essential evidence is in deleted data, the risk of overwriting
this evidence by switching on the phone and doing a logical
acquisition might be considered higher than the risk of loosing
the evidence through a failed physical acquisition.
5. Physical acquisition
In this section, several methods for getting a forensic image
from a WCE device are described. The methods are described
in order of forensic soundness. One has to realize that the
success of the described methods greatly depends on the
experience the investigator has with applying these methods.
Incorrectly applying these methods may destroy the WCE
device, the data in it, or both.
5.1. Physical chip extraction
In a WCE device, the investigation of the file system residing in
flash memory is best done by accessing the flash memory
directly. This method ensures that the OS does not interfere with
the data in memory. However, this type of acquisition might not
be feasible due to lack of necessary equipment. Section III-C,
Breeuwsma et al. (2007) describes how to remove a BGA
memory chip from a PCB and subsequently read the content of
the memory device. Desoldering the flash memory chip from
a WCE device might be an option in the following cases:
� Every risk of loosing deleted data has to be eliminated.
� The device is not working anymore
� No (known) possibility for access through JTAG
This method has some downsides:
� TSOP/BGA rework equipment is required
� Memory reader equipment is required
� The memory reader tool might not support the target chip
� The datasheet of chip equipment might not be available
5.1.1. Case exampleIn an investigation Police seized a Fiat 500 equipped with
a Blue&Me multi media set. Blue&Me is an ‘‘in-car
‘dimage’ connects to WCE DoC through JTAG
dimage
Tffs.dll
PC hardware
JTAG JTAG
WCE hardware
DoC
Normal situation for ‘dimage’
dimage
Tffs.dll
PC hardware
DoC
Fig. 3 – Making a file system image of an M-Systems DoC
through JTAG Technologies’ tools.
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 ) 1 4 7 – 1 6 7152
communication system’’, based on WCE for Automotive
(BusinessWeek, 2006; Microsoft 6). The investigation required
the examination of the content of the device, as it could
contain information on gsm handsets paired to the B&M unit,
SMS messages received with the handset or MP3 files played
with it. As time was limited it was decided not to look at RAM
data and only focus on flash memory. Three options for
accessing the flash data were identified:
� Acquisition through the USB port on the board
� Acquisition through JTAG
� Desoldering the flash chip
From a Fiat dealer several scrap units were obtained as
exemplar devices. On these it was established that the flash
chips were of a well known type (Samsung K9F5608U0D-
JIBO) and because of component placement, it was rather
easy to do Physical Extraction as described in Breeuwsma
et al. (2007). Furthermore, no information could be
obtained in reasonable time on how to get access through
USB, nor on the JTAG Test Access Points (TAPs) in the device.
This led to the decision that desoldering and subsequent
reading the memory chip with the NFI Memory Toolkit was
the quickest and most sound way to obtain a copy of the
flash chip.
This procedure was first tested on the exemplar. The file
system of the exemplar was reconstructed from the memory
copy and it appeared to contain:
- Bluetooth MAC addresses from devices connected to the
B&M set
- Full pathnames of MP3 files played
- Contact lists from paired phones
- Call history
Then the exhibit was processed the same way. It appeared
that non of the phones found earlier in the investigation had
been paired to the Blue&Me kit, so no further investigation
was necessary. As usual, new knowledge produces new
questions: It is the above list is complete? Probably not. For
example, the device is able to read out loud incoming SMS
messages, which indicates that received SMS messages will
probably be stored in the B&M unit.
4 M-Systems announced this chip End Of Life (EOL) in october
5.2. JTAG
In Breeuwsma (2006), a method is described on how to find
and use JTAG Test Access Points to obtain copies of
memory in JTAG enabled digital devices. In this paper,
a WCE device, the HP iPaq h1930 is investigated. It was
shown that it is possible to access SDRAM and flash
memory in this device.
5.2.1. Case exampleIn a case we received an HP Hx2790, of which we would like to
acquire an image of the internal flash memory, an M-Systems3
3 M-Systems was acquired by SanDisk in 2006, see www.sandisk.com/about-sandisk/press-room/press-releases/2006/2006-11-19-sandisk-completes-acquisition-of-msystems.
DiskOnChip (DoC) G3 type MD4331-d1 G-V3Q18X.4 After
having identified the JTAG pins on the device, and the
configuration of the JTAG chain, we searched for tools that
would be able to read the DoC. We found a tool set from
a Dutch company called JTAG Technologies. Their tool set
provides a mechanism to let M-Systems’ own utility ‘dimage’,
designed to make an image of a DoC hosted by a PC,
communicate with a DoC in another device through the JTAG
protocol, as if the DoC is on the same PC as the dimage utility
itself (JTAG). In this setup a file system image of the DoC in
a WCE device can be made. The Flash Translation Layer is in
the tffs5 library. It is crucial that the right version of the tffs
software is used (Fig. 3). Details of the flash translation
apparently change even between minor versions. A 6.3 tffs dll
is not capable of reading a 6.2 formatted DoC. As this method
offers a file system level image, expired pages within the DoC
are not found in the image, although these pages might
contain relevant information.
The result is shown in Fig. 4. The first 0x30 bytes show data
indicating this is a dump from an M-Systems device. We also
recognize the TFFS version 6.2.20 in this part. Then at offset
0x10C0 a Master Boot Record can be recognized. At offset
0x12C0 the boot sector of a TFAT16 file system is recognized.
Loading the image in EnCase is still problematic, this is
currently being researched further.
5.3. Bootloader
An example of bootloaders that have been reverse engineered
by people at xda-developers.com is the HTC Hermes boot-
loader (XDA Developer, 2008). Another example is a process
where the bootloader is replaced by one with capabilities to
copy of the TFAT file system (XDA Developer, 2007). The
author claims that the command ‘fat2sd 3’ will copy the
internal NAND based file system is copied to SD at file system
level. Supposedly the flash translation is being executed by
the bootloader, looking at output lines like ‘Nand2SDReorder
start.’. The output presented on this site looks like a valid
Windows CE TFAT root directory, including cemail.vol and
pim.vol files.
More research is needed to explore the possibilities of
these techniques on recent WCE devices.
2005, see www.sandisk.com.tw/Assets/File/OEM/Manuals/eol/mdoc/EOL-DOC-0505.pdf, but the chip is still found in olderdevices.
5 TrueFFS (tffs) is the flash file system developed by M-Systems.
1 Data type For instance ‘‘subject’’, ‘‘receive date’’,
‘‘message is opened’’.2
3 Last field Always ‘0’, except in the last
field it is ‘1’
4 Variable type See Table 3
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 ) 1 4 7 – 1 6 7160
In Fig. 17 the output of cedbexplorer.py is shown, decoding
this same record. Notice how the MD5 of this record matches
the MD5 of record 6 in Fig. 14. This means that record number
43 is actually message 6 in the SMS inbox. When this message
is deleted by the user, cedbexplorer.py will still find it back in
the volume file, as long as it is not actively erased by the
messaging application.
Record body
Odd byte stream
Even byte stream
[Compressed] data container
[Compressed data container]
Record header (8 bytes)
List of record ‘field type indicators’ (N* 4 bytes)
6.2. RAM
In 5.4.2.2 it was shown how to make a dump of the working
memory of a process. A first examination of such a memory
dump can be done with knowledge that can be found in the
source code that comes with Platform Builder. In heap.h10
constants and structures are defined that can help to dissect
a RAM memory copy of a process.
The first step is to find the start of the heap within the
memory copy. The heap starts at a 64 kB boundary and has
a marker ‘HeaP’. Starting at the ‘HeaP’ marker, a structure
occupying 0x30 bytes is the heap header. Then follows a so
called region. The regions contain the actual heap items. The
region header also contains a field that can point to the next
region. If there is no next region, this pointer is 0 (Fig. 18).
The first heap item starts at offset 0x58. Each heap item has
a header of 8 bytes. Four bytes indicate the length of the item
(including item header) and a pointer to the heap itself. A
positive length indicates that the item is in use, a negative
length indicates a free item.
A python script called heapdigger.py was written to dissect
the heap of a WCE process. This script searches the heap
marker in an image, decodes the heap headers and subse-
quent heap items. With this script a first step can be made to
analyze the way a program stores and leaves data on the
stack.
While simulating an SMS message being written but
cancelled before sending it, acquisitions of the process
memory of tmail.exe were made with pmemdump.exe. Fig. 19
shows an example of the output of the script. Heap item 823,
at address 0x1E0820 and a length of 0x118, is ‘free’ and avail-
able for reuse. In the raw data of this item one can read the
cancelled email in HTML format.
10 See shared source code that comes with Platform Builder. Thefile heap.h is in the directory WINCE500\PRIVATE\WINCEO-S\COREOS\CORE\ LMEM\.
7. Discussion
In section 2, NOR and NAND flash were identified as important
sources of user data. In modern WCE devices, NAND flash is
getting more important as opposed to NOR flash. RAM can also
hold information that can be of forensic relevance. WCE
devices may also have special memory locations, for instance
in the processor itself. These locations might hold items like
unique numbers that can be used for encryption.
Section 3 identified software components that are either
relevant to storage of user data, or useful in making copies of
that user data. A TFAT file system hosted on flash memory can
contain user data like text documents, pictures, videos, but
also database files for messaging and PIM data. The heap,
located in RAM, can contain relevant information related to
processes running on the WCE device. Examples are naviga-
tion software having an NMEA reception buffer or email
clients maintaining a scratch pad.
In section 4 the order of acquisition of the components
holding potential evidence was explored. Depending on what
kind of evidence is looked for, the risks of different kinds of
acquisitions are compared against the likelihood of successful
recovery of the evidence. For example, if there is reason to
believe that the essential evidence will be deleted video, the
risk of damaging the physical memory chip during chip
extraction might be regarded less than the risk of erasing
deleted data by switching the phone on to do a pseudo phys-
ical acquisitions with tools like pdocread or XACT. Likewise,
when it is suspected that evidence might be in the RAM that is
occupied by a navigation application which is still active, one
might decide to make a copy of RAM using JTAG or, if that is
not feasible, using pmemdump. Finding out how to apply
JTAG on a specific device might not only be a very time
consuming task, applying JTAG holds a risk of system crash,
making a reset necessary. This will obviously cause risk to
[Compressed] data container
[Compressed data container]
Fig. 15 – Structure of a CEDB record body.
Fig. 16 – cemail.vol opened with HexWorkshop and corresponding bookmark 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 ) 1 4 7 – 1 6 7 161
deleted data in both RAM and flash memory. On the other
hand, when using pmemdump the OS is still active, there is
a risk that deleted data in flash and RAM will be erased beyond
recovery.
Section 5 described methods for physical and pseudo
physical acquisition. For two physical acquisition methods
a case example was given; physical memory chip removal and
JTAG have been shown to be feasible methods to make
a physical acquisition of a WCE device. Furthermore the use of
several RAPI tools is described; it was shown how to deter-
mine the list of running processes on a WCE device. With this
list, the name of a running process could be determined and
used to make a dump of the RAM occupied by this process.
Next it was shown how to make a pseudo physical acquisition
of flash based file system in a WCE device.
When using the RAPI tools, or any other tool that is doing
pseudo physical acquisition on a WCE device, one has to take
into account that these tools make use of dedicated software
that has to be loaded on the running machine. Running this
software on the device will at least overwrite unused RAM that
might hold evidence. If the software is transferred to the WCE
device, it has to be stored on external media like an SD card
first, before it is loaded into RAM. If the software is loaded onto
the internal file system, it might cause expired flash blocks to
be erased and reused, thus erasing potential evidence.
In section 6 tools were presented to analyze acquired data.
An algorithm was presented to reconstruct a TFAT file system
from a physical acquisition. This reconstruction yields an
TFAT image file containing flash pages belonging to the latest
version of the file system. This image can be further investi-
gated with COTS file system analysis tools like EnCase or FTK.
It also produces a file containing flash pages that no longer
belong to the latest version of the file system. This file can be
loaded too into analysis tools as unallocated clusters.
A tool called xpdumpcedb was presented. This tool runs
under Windows XP. With this tool, a cedb database volume file
(for instance exported from EnCase) can be read completely.
All fields in all records of all databases in the volume are
outputted in xml format. The meaning of fields within data-
base records can sometimes be found in header files in the
Platform Builder source code, sometimes though, the meaning
has to be established by reverse engineering. Furthermore,
a tool called wmdumpedb was presented. This tool runs under
WCE, for instance on a WCE Emulator on an XP machine. This
tool reads a edb formatted database volume file. It writes all
fields in all records of all databases in the volume to a file in
xml format. This tool has the disadvantage that is can only
run on a WCE device or a WCE device emulator. No possibility
has yet been found to make a similar tool that runs on desktop
OS natively.
Fig. 17 – Output of cedbexplorer.py.
Region hdr Next reg.
Heap item hdr
Heap Item
Heap item hdr
Heap Item
Heap item hdr
Heap Item
Heap header0x300x57
Region hdr Next reg.
Heap item header
Heap Item
Heap item header
Heap Item
Heap item header
Heap Item
0x00 0x2F
Fig. 18 – Structure of a WCE heap.
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 ) 1 4 7 – 1 6 7162
Furthermore, some aspects of low level structures of
a WCE cedb database was explained. With knowledge of this
structures, a python script called cedbexplorer.py was
developed. It was presented here and it was shown that the
script can find and decompress (if necessary) individual cedb
records. Because the tool does not look at the status of the
individual records, it also finds deleted records that are still
present in a cedb volume file. On the bases of MD5 hash
values calculated over the record fields, the tool can deter-
mine whether a record is active (already found by xpdump-
cedb) or deleted (not found by xpcedbdump). Because the
decompression algorithm is not yet fully understood,
Fig. 19 – Part of the output of heap analysis tool.
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 ) 1 4 7 – 1 6 7 163
sometimes active records are not decompressed correctly
and thus not found back in the xpdumpcedb results and
subsequently falsely marked as deleted. This effect is noticed
mainly in big records. The script carves the records out of the
database file and uses an indirect way to distinguish between
active and deleted records. This indirect method is not the
most efficient way, but the advantage is that it can be used
independent of the higher level structures of cemail.vol, so
that also for instance expired flash memory blocks and
unallocated clusters can be carved as well. In these locations
both active and deleted database records can be found
(Stahlberg).
Finally a script called heapdigger.py was presented. With
this script a dump of the RAM occupied by a process can be
searched for the presence of a heap. If a heap is found, it will
be analyzed. Sections in the heap are written to an xml file. In
this way busy and free heap items can be studied. These items
can contain relevant evidence, as processes can use the heap
to allocate buffers. Examples are a receive buffer for GPS
NMEA data, or a buffer to hold an email while it is written.
These items can still be found on the heap although they are
released for reuse. This tool is a proof of concept. Experiments
are needed to find out what information is left on the heap by
popular WCE applications. Actual value in a forensic investi-
gation has to be established in this way.
8. Future work
This paper is mainly a starting point for further investigation
of Windows CE based devices. Lots of questions came up
during case driven research of WCE devices, but often the
research was stopped because the required data was recov-
ered or a case was closed. Because of this, there are still a lot of
interesting issues to be studied.
Besides the heap, the stack is a place to look for data. Func-
tions store local variables on the stack. Data stored by functions
with a relatively long lifetime might be on the stack for a rela-
tively long time. This has not been explored from a forensic point
of view. Memory mapped files might be interesting in a forensic
context? First, ways of recovering those files have to be estab-
lished. Then the forensic relevance can be determined.
Important aspects of the format of cedb database records is
clear, but the decompression for these records presented in
this paper is not yet perfect and has to be improved. The
format of the cedb successor edb however is not yet known. It
is likely that edb databases will also contain deleted records
until the moment of a database clean-up.
Deleted data is found in cedb databases. It would be
interesting to establish to what extent deleted data will
remain in the volume files and compare cedb databases to the
databases investigated by Stahlberg.
Finally, the knowledge on forensically interesting artifacts
of popular software on Desktop Windows version is not one
on one transferable to WCE platforms. Research should be
conducted to find out about similarities and differences in the
way evidence left by applications on both platforms.
Acknowledgement
The author would like to thank colleagues at the Netherlands
Forensic Institute for support in investigation the Windows CE
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 ) 1 4 7 – 1 6 7164
platform and writing this paper. Furthermore the author
would like to thank the reviewers for very useful suggestions.
Appendix.
Table 5. Databases and field types found in cemail.vol.
Database name: pmailFolders
This database holds the folder structure of the messaging system. Generally there are several root folders for the variousmessaging methods: SMS, ActiveSync, Hotmail, and some POP/SMTP email accounts. Each of these root folders havesubfolders: Inbox, Outbox, Sent items, Drafts and Deleted items.
c Type identifier Data type Function
1 3001001F String PR_DISPLAY_NAME, name of folder. When 2 and 3 are
equal, this is a ‘messaging method’ (SMS, ActiveSync,
hotmail or some SMTP/POP email account). When c2 and c3
are not equal, this is the ‘message box type’ (inbox, outbox,
drafts, sent items or deleted)
2 80010013 Uint32 Database for this folder. The name of the database is ‘fldrX’,
where X is the hexadecimal value of this field. If for example
this field has the value 31000026, messages in this folder can
be found in database with the name fldr31000026
3 80050013 Uint32 ‘Messaging method’ link. The ‘messaging methods’ and the
‘message box types’ that are grouped together by having
this number equal
8119001F String Signature used when composing a message in this channel.
Empty when c2 s c3
4 8117001F String Protocol. ‘SMS’, SMTP’ are values found
820F0040 DateTime Unknown
5 82160040 DateTime Unknown. Maybe last time sync’d
Database name: fldr3100026
This is an example for instance an Inbox. For each messaging method there are at least five subfolders. The user can alsocreate extra folders.
c Type identifier Data type Function
1 0E060040 DateTime Receive date and time
3 0C1A001F String ‘File as’ name
4 0C1F001F String ‘From’ name
5 003D001F String Subject prefix, like ‘Re:’ or ‘Fwd:’
7 0E1B0013 Uint32 If>0 then there is an attachment to this message
8 80050013 Uint32 Attachment id. In the attachment database, there is a field
‘81000013’. The attachment to this message can be found in
the record where the value in ‘81000013’ is equal to the
value in ‘80050013’ in this database
Database name: pmailAttach
This database is used to link the file holding the attachment to the message the attachment is attached to.
c Type identifier Data type Function
1 81000013 Uint32 Attachment ID. Links to field 80050013 in message
folders named ‘fldrX’
2 370E001F String Mime type of attachment
3 3704001F String Original name of file attached
4 81000013 Uint32 First set of 8 digits of file name where attachment is
actually stored in on the WCE device
5 80010013 Uint32 Second set of 8 digits of file name where attachment is
stored in, joined with c4 with a ‘-’. If c4 contains
13002345 and c5 contains 23450012, then the
attachment is stored in:
\Windows\Messaging\Attachments\13002345-
23450012.att
Database name: pmailMsgs
This database holds additional data on sent messages. Depending on the messaging method and the type of message(sent/received/draft or deleted), different data is stored.
c Type identifier Data type Function
1 81000013 Uint32 Attachment ID. Links to the value in field 80050013 in
message folders named ‘fldrX’
2 0E090013 Uint32 Originating folder. If this contains 31000026, the message
is in ‘fldr31000026’
3 851F0040 DateTime Related to the message: received date/time, stored date/
time, deleted date/time
4 800F001F String Dependent of message type. Can be ‘File as’ name
5 800C001F String Dependent of message type. Can be ‘From’ name
6 800E0041 Blob Contains data on the message, often data already found in
other fields. Seen to contain Protocol type, ‘File as’ name,
From, Number, email address
7 80010013 Uint32 Message number. For email messages: points to the file
holding the message body, including email header.
Example: If this field holds 34000135, the email message is
stored in a file \Windows\Messaging\35340001[postfix].mpb
(the value is rotated right one byte). The [postfix] is seen to
have on of the values: 8242001e, 8241001f, 1013001e,
1000001f, 1000001e and 81030102, but this list is probably
incomplete. These values seem to indicate the format of
the email body: html without header, smtp header,
empty. Email messages do not necessarily have to have
only one email body file. It can have more, for different
storage format types.
Database name: MessageThreadsDB
This database holds messages. Why messages are stored separately in this database is not yet looked at.
C Type identifier Data type Function
1 00010040 DateTime Date/time (exact meaning not looked at yet)
2 0002001F String Email subject or SMS body text
3 0004001F String ‘From’ name
4 0005001F String Originating from (phone number or email address)
Table 6. Databases and field types found in pim.vol.
Database name:Appointments Database
Holds appointment items
c Type identifier Data type Function
1 10420040 DateTime Due date/time
2 00520040 DateTime Some other
date/time
(exact meaning not looked at yet)
3 0020001F String Subject
4 0041001F String Location
5 0051001F String Organizer
6 0029001F String Type of appointment
(exact meaning not looked at yet)
Database name:Contacts database
Holds contact items
c Type identifier Data type Function
1 0080001F String Name 1
2 0082001F String Name 2
3 0096001F String Number
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 ) 1 4 7 – 1 6 7 165
Tasks database
Holds tasks items
c Type identifier Data type Function
1 0020001F String Subject
2 0029001F String Type of task
(exact meaning not looked at yet)
3 00620040 DateTime Date/time 1
(exact meaning not looked at yet)
4 00630040 DateTime Date/time 2
(exact meaning not looked at yet)
5 00640040 DateTime Date/time 3
(exact meaning not looked at yet)
6 00660040 DateTime Date/time 4
(exact meaning not looked at yet)
Clog
Holds the calllog of this phone
c Type identifier Data type Function
1 00020040 Date/Time Date/time 1
(exact meaning not looked at yet)
2 00030040 Date/Time Date/time 2
(exact meaning not looked at yet)
3 0006001F String ‘File as’ name
4 0007001F String Tbd
5 000A001F String Tbd
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 ) 1 4 7 – 1 6 7166
r e f e r e n c e s
Association of Chief Police Officers (ACPO). Good practice guidefor computer-based electronic evidence. Online, cryptome.org/acpo-guide.htm.
Ayers R, Jansen W, Cilleros N, Daniellou R. Cell Phone ForensicTools: An Overview and Analysis. Online. National Institute ofStandards and Technology, <csrc.nist.gov/publications/nistir/nistir-7250.pdf>; October 2005.
Boling D. Windows CE.NET advanced memory management.Online, msdn.microsoft.com/en-us/library/ms836325.aspx;August 2002.
Breeuwsma M, Jongh M de, Klaver C, Knijff R van der, Roeloffs M.Forensic data recovery from flash memory. Small Scale DigitalForensics Journal June 2007;1(1).
Breeuwsma M. Forensic imaging of embedded systems using JTAG(boundary-scan). Digital Investigation March 2006;3:32–42.
BusinessWeek, Fiat and Microsoft Launch Blue&Me. Online,www.businessweek.com/autos/content/feb2006/bw20060202_986426.htm; February 2006.
Canalys. Smart phone market shows modest growth in Q3. Online,www.canalys.com/pr/2009/r2009112.html; November 2009.
Eide J, Skogheim Olsen JO. Forensic analysis of an unknownembedded device. Online, ntnu.diva-portal.org/smash/get/diva2:121991/FULLTEXT01; June 2006.
Hengeveld Hengeveld W. Smartphone-policies. Online, www.xs4all.nl/witsme/projects/xda/smartphone-policies.html.
Hengeveld W. xda tools. Online, www.xs4all.nl/witsme/projects/xda/tools.html; November 2009.
Herrera C de. Windows CE/Windows Mobile Versions. Online,www.pocketpcfaq.com/wce/versions.htm; October 2009.
Intel� persistent storage manager user’s guide. Online, www.developers.net/filestore2/download/2613; September 2005.
Intel. Marvell to purchase Intel’s communications and applicationprocessor business for $600 Million. Online, www.intel.com/pressroom/archive/releases/2006/20060627corp.htm; June 2006.
Jansen W, Ayers R. Guidelines on cell phone forensics. Online.Recommendations of the National Institute of Standards andTechnology, <csrc.nist.gov/publications/nistpubs/800-101/SP800-101.pdf>; May 2007.
Microsoft 1, supported processors. Online, msdn.microsoft.com/en-us/windowsembedded/ce/aa714536.aspx#ARM.
Microsoft 2, virtual memory layout: Windows CE 5.0 vs. WindowsEmbedded CE 6.0. Online, msdn.microsoft.com/en-us/library/aa914933.aspx.
Microsoft 3, heaps. Online, msdn.microsoft.com/en-us/library/aa450550.aspx.
Microsoft 4, TFAT overview. Online, msdn.microsoft.com/en-us/library/aa915463.aspx.
Microsoft 5, TFAT File naming limitations. Online, msdn.microsoft.com/en-us/library/ms892402.aspx.
Microsoft 6, driving connectivity. Online, download.microsoft.com/download/6/5/0/6505FA0E-1F39-4A34-BDC9-A655A5D3D2DB/MicrosoftAutoOverview.pdf.
Microsoft 7, databases. Online, msdn.microsoft.com/en-us/library/ms885343.aspx.
Microsoft 8, Windows embedded CE 6.0 evaluation edition.Online, www.microsoft.com/downloads/details.aspx?familyid¼7E286847-6E06-4A0C-8CAC-CA7D4C09CB56&displaylang¼en.
Rogers A, Glaum J, Tonkelowitz M. Creating file systems within animage file in a storage technology-abstracted manner, www.freepatentsonline.com/EP1544732.pdf; June 2005.