During the debut of SEC563 Mobile Device Forensics last week, Eugene Libster from ManTech brought to my attention the open source itsutils package for extracting from Windows Mobile devices. Components of this package, psdread and pdocread, can acquire more data from Windows Mobile devices than many commercial forensic tools, but there are several issues that forensic practitioners need to understand before using these utilities on an evidentiary device.
First, acquiring data using these utilities creates files on the device, necessarily overwriting data. Specifically, an executable file named "itsutils.dll" is copied onto the device, and an error log "itsutils.log" is created on the device. Second, these tools acquire data through a hardware abstraction layer that does not provide direct access to flash memory on the device. Therefore, these utilities do not acquire a complete physical duplicate of flash memory on Windows Mobile devices.
Acquisition of Windows Mobile devices using both pdocread and psdread are described below. The itsutils package requires ActiveSync to be installed on the acquisition system in order to connect with the device, and the Windows Mobile operating system on the target device must be configured to permit unsigned programs to run. To configure a Windows Mobile 6 device to run unsigned code, add the Registry value "HKLM/Security/Policies/Policies/0000101B" with DWORD = 1. The first time a Windows Mobile device is accessed using a component of the itsutils package, a prompt appears on the mobile device requesting that the code be permitted to run, and the message "Copying C:Toolsitsutilsitsutils.dll to WCE:windowsitsutils.dll" is displayed on the command line.
Once a Windows Mobile device is connected to an acquisition system, obtaining a copy of storage areas on the device using psdread is relatively straightforward, with a -l option to list the available disks as shown here on an HTC Dash.
C:Toolsitsutils>psdread -l
C: - VMware Virtual S
Drive geometry: 0x7a6 cyls, 255 t/cyl 63 s/t 512 b/s - 15.00Gbyte
disknr=0 fixed disk
D: - NECVMWar VMware IDE CDR10
remote disk 1 has 120456 sectors of 512 bytes - 58.82Mbyte
SerialNr: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
remote disk 2 has 121464 sectors of 512 bytes - 59.31Mbyte
SerialNr: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
The first two entries in the above list refer to the local disk and CD-ROM drive of the acquisition system. The two subsequent entries referring to remote disks are the system and data storage areas on the attached HTC Dash Windows Mobile device. The following command options acquire the storage area that contains the most relevant data from a forensic perspective (remote disk 2 on this HTC Dash), starting at 0 and copying 62189568 bytes (121464 sectors x 512 bytes).
C:Toolsitsutils>psdread -2 0 62189568 E:HTC-Dash-psdread.bin
remote disk 2 has 121464 sectors of 512 bytes - 59.31Mbyte
SerialNr: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CopySDCardToFile(remote, 2, 0x0, 0x3b4f000, HTC-Dash-psdread.bin)
When psdread does not work with a given Windows Mobile device, it may still be possible to acquire data using pdocread. The pdocread utility only acquires individual partitions and sometimes must rely on the Windows disk API, which may restrict the amount of data that can be acquired. Using pdocread to list the available partitions is shown here.
C:Toolsitsutils>pdocread -l
58.82M (0x3ad1000) DSK1:
| 2.09M (0x217400) Part00
| 3.08M (0x313800) Part01
| 53.65M (0x35a6000) Part02
59.31M (0x3b4f000) DSK2:
| 59.06M (0x3b0e800) Part00
STRG handles:
handle cfae68ca 59.06M (0x3b0e800)
handle 2fb7ba2a 53.65M (0x35a6000)
handle cfb7ba06 3.08M (0x313800)
handle 2fb7b9be 2.09M (0x217400)
<cut for length>
The first three partitions under DSK1 are related to the base image on the HTC Dash running Windows Mobile 6: Part00 contains an update kernel that is used when upgrading the operating system, Part01 contains the primary kernel, and Part02 stores the ROM image in LZX compressed format. User created files, Windows Mobile folders and files, and other data of interest in a forensic investigation are stored in the partition listed under DSK2.
The partition to be imaged can be specified by name or handle, and we generally prefer to use the unique handle specified with -h option. Using the following command and the handle from the previous command output, we start reading at byte zero and read the full length of the partition, which is 59.06M (0x3b0e800 in hexadecimal).
C:Toolsitsutils>pdocread -v -w -h 0xcfae68ca 0 0x3b0e800 E:HTC-Dash-Dsk2.raw
The -v option provides verbose information during the acquisition process, and the -w option specifies that the Windows disk API be used. Attempts to acquire data without the -w option failed the HTC Dash, but is reported to work on some other Windows Mobile devices like the HTC Touch. Additional options are available to specify the block sizes for reading data from the disk and transferring the data via ActiveSync.
The file acquired using pdocread contains a TFAT file system that can be loaded into a tool like TSK or EnCase as a raw image, specifying that it is a FAT volume. Similarly, the file acquired using psdread can be loaded into forensic tools as a disk image. The file system hierarchy on a HTC Dash running Windows Mobile 6 is shown below in EnCase. Although file system entries associated with deleted files can be recovered, the contents were overwritten as shown here for a deleted digital photograph stored in the "My DocumentsMy Pictures" folder.
Windows Mobile Volume Viewed Using EnCase
The commercial forensic tool XACT can acquire the same information as itsutils from certain Windows Mobile devices as demonstrated through hands-on exercises in the SEC563 Mobile Device Forensics class (register now for NS2009 in San Diego, Sept 16 - 20). However, forensic tools have difficulty parsing the file system of certain Windows Mobile devices, and may not display all files and folders. As we emphasize in the class, processing the same mobile device using different methods and tools can have varied results, and processing similar mobile devices using the same tool can have varied results. Therefore, it is important to perform tool validation by comparing the results of multiple tools and examining data at a low level whenever feasible (e.g., using a hex viewer).
