13.1 Overview of Handheld Devices

13.1 Overview of Handheld Devices

Handheld devices are simple computers with a CPU, memory, batteries, input interfaces such as a keypad or mouthpiece, and output interfaces such as a screen or earpiece. Data in memory are generally the focus of a forensic examination, but some understanding of the input/output components are needed to access these data. In some instances, it may be sufficient manually to operate a device and read information from the display. However, to recover deleted data or perform more advanced examination, specially designed tools are needed to interface with the device. Knowledge of how data is manipulated and stored on handheld devices is sometimes needed to acquire all available digital evidence from handheld devices without altering it and translate it into a human readable form. For instance, placing a Palm OS device on a cradle and HotSyncing it with a computer to obtain information from the device will not copy all data and may even destroy digital evidence.

When learning about handheld devices, it is helpful to consider one type in depth. All handheld devices have many similarities so an understanding of one can be generalized to others. Therefore, this section focuses on one of the most common types of PDA: those running Palm OS.

13.1.1 Memory

Handheld devices generally have two types of memory: read only memory (ROM) and random access memory (RAM). The ROM contains the operating system and other software needed for basic functions and RAM is used to store user data and software. As the name suggests, data in ROM cannot be altered but it can retain its contents indefinitely even when it is not being supplied with electrical power, providing a stable platform for critical system components. However, the inability to upgrade critical system software in ROM is inconvenient. To provide greater flexibility, newer devices use programmable ROM that can be modified a limited number of times but will still retain its contents for several years without power. Currently, the most common form of programmable ROM used in PDAs and mobile telephones is called FLASH.

In addition to storing data in RAM, many devices have the ability to save data on removable memory modules similar to those found in a digital camera. Some memory modules are the size of a postage stamp and can store hundreds of megabytes of data (see Figure 13.6).

13.1.2 Data Storage and Manipulation

Handheld devices are designed to make efficient use of their limited amount of memory. For instance, Palm OS divides its memory into partitions called heaps and further divides some of these heaps into chunks for storing the equivalent of files (called databases on Palm OS). Each chunk is referened using a "Local ID," which is basically the position in memory relative to beginning of the memory card it is on.

The two main heaps on Palm OS are the dynamic and storage heaps. The dynamic heap is used for transient data storage and the storage heap is used for long-term storage (e.g. user data). So, when a user enters data into a database on Palm OS, the software uses the dynamic heap for temporary storage while it is running and saves the data in the storage heap for long-term storage. Data in the dynamic heap, such as decrypted data, is overwritten frequently and is completely reinitialized when the device is soft reset.^[1]

Data in the storage heap is less volatile but can be deleted by the user or by the device under certain circumstances. For instance, when Palm OS cannot find enough memory in the storage heap to save a piece of data, it uses a process called heap compaction to rearrange data and expunge deleted records as discussed later in this section. Heap compaction also occurs when a Palm OS device is soft reset. More drastically, a hard reset effectively reformats the memory, recreating empty heaps.^[2] Some data may still be recoverable after a hard reset because it only initializes areas that are important and may not clear all memory.

Some devices use the FAT file system to arrange data in memory but Palm OS uses databases. Databases are relatively simple structures that maintain data in records. Each Palm Database (PDB) consists of a database header, followed by a table of record entry headers, followed by the records containing the data as shown in Table 13.1.

Table 13.1: PDB format.

DATABASE HEADER (78 BYTES)
FIELD	BYTES	VALUE
DB Name	32	Database name
Attributes	2	e.g. hidden, readonly, copyprevent
Version	2	Application - specific version of the database
Creation time	4	Seconds since 12:00 A.M. on January 1, 1904
Modification time	4	Most recent modification
Backup time	4	Last time database was backed up
Modification number	4	Number of times database has been modified
Applnfo offset	4	Optional application specific information
Sortlnfo offset	4	Optional application specific information
Type	4	Set by the application/system (e.g. pqa, data)
Creator	4	Application identifier (e.g. clpr)
Unique ID seed	4	Used by PalmOS to create unique record Ids
Next Record list ID	4	Location of 2nd record list with more records
Number of records	2	Number of records in this record list
First Entry	2

RECORD LIST	VARIABLE	ONE ENTRY PER RECORD WITH THE FOLLOWING FIELDS
Offset	4	Location of record from the start of database
Record attribute	1	e.g. private (1), modified (4), deleted (8)
Unique ID	3	Unique number for each record
Gap	variable	Empty
Data	variable	Data in database

Database records can be deleted in several ways on Palm OS. The DmRemoveRecord function is the least complicated and simply removes a record. However, this method of deletion does not allow for synchronization between the device and another computer. To accommodate the need for synchronization, two other deletion methods are available: DmDelete Record and DmArchiveRecord.^[3] DmDeleteRecord sets the delete bit in the record and removes the pointer to the data's location in memory. The record is then moved to the end of the database and, during the next synchronization, the corresponding record is deleted from the desktop. The DmArchive Record method, on the other hand, allows a user to archive a deleted record on the desktop during the next synchronization before it is removed from the handheld. Specifically, DmArchiveRecord sets the delete bit in the record but does not free the associated data chunk until the next synchronization.

All of these deletion methods ultimately cause Palm OS to "forget" where the associated data was located in memory. Although data may still exist in this unallocated space, handheld operating systems are quite efficient and unallocated data may only exist for a short time. Some of the digital evidence collection tools described later in this chapter cause a soft reset after acquiring evidence from Palm OS devices, triggering heap compaction that overwrites data in unallocated space.

13.1.3 Exploring Palm Memory

To learn more about the operation of Palm OS devices and how their data are structured, it is useful to experiment with the Palm Debugger (do not experiment on an evidentiary device). Palm devices must be put in debug mode before they are accessible to the Palm Debugger. This is achieved using a special combination of graffiti symbols (ℓ,..,2).^[4] The Palm Debugger can be used in combination with the Palm OS Emulator (POSE) to experiment without actually using a physical device. The emulator can also be used to synchronize with the desktop via TCP/IP, a useful feature for testing and for viewing evidentiary databases in a safe environment.

The following shows commands in the Palm Debugger being used to query a device directly. The cardinfo command obtains information about specified memory chips in the device, the heaplist command obtains information about the heaps on a specific card.^[5]

    >cardinfo 0    Name: PalmCard    Manuf: Palm Computing    Version: 0001    CreationDate: B28C66DF    ROM Size: 00127FFC    RAM Size: 00400000    Free Bytes : 003ED792    Number of heaps: #3    > heaplist 0    index   heapID     heapPtr       size      free   maxFree   flags --------------------------------------------------------------------    0         0000    00001510   0001EAF0  0001890E  00017ED6   4000    1         0001    0002010E   003DFEF2  003D4E84  003D4D42   4000    2         0002    10C08212   00127DEE  0000C2CA  0000C2C2   4001 

The memory sizes are represented in hexadecimal format - note the discrepancy between memory sizes reported by cardinfo and heaplist in this example.

• RAM size (cardinfo): 4,194,304 bytes (x00400000);

• RAM size (heaplist): 4,188,642 bytes (dynamic + storage heaps);

• ROM size (cardinfo): 1,212,412 bytes (x00127FFC);

• ROM size (heaplist): 1,211,886 bytes (x00127DEE).

The reason for this difference is that cardinfo provides information about the memory card whereas heaplist reports how the card has been divided by Palm OS (some RAM is reserved by the operating system). Notably, although cardinfo reports the correct RAM size, it does not report ROM size accurately - the actual size of the memory chips in this device are larger (2,097,152 bytes). This discrepancy is due to the Palm OS not using the entire ROM chip and most tools calculate this value incorrectly. Currently, only Pilot-link and pdd calculate the actual size of ROM correctly by extracting information from the processor directly (Grand 2002).

Although differences in ROM size may not seem significant, from an investigative perspective it is important to keep in mind that FLASH is not ROM. Individuals may use extra space in FLASH to backup important data or hide incriminating evidence. For instance, an individual can store data in FLASH on a Palm OS device using programs such as FlashPro and JackFlash. After installing FlashPro on this device, heaplist shows two additional heaps that have been created in FLASH.

    > heaplist 0    index    heapID     heapPtr       size       free    maxFree    flags ------------------------------------------------------------------------    0        0000      00001510   0001EAF0   000188B0   00017E6C    4000    1        0001      0002010E   003DFEF2   003C0756   003C06EA    4000    2        0002      10C08212   00127DEE   0000C2CA   0000C2C2    4001    3        0003      10D303FA   00001C06   00000000   00000000    4001    4        0004      10D32000   000CE000   00000000   00000000    4001 

Interestingly, the Palm OS Emulator will report when such modifications have been made (Figure 13.1).

Figure 13.1: Warning message displayed by Palm OS Emulator when loading a copy of ROM that has been modified using FlashPro.

Ironically, certain features of FLASH can facilitate data recovery, making it easier for forensic examiners to obtain valuable evidence.

The block structure [of FLASH] has two important implications for forensic investigations. Firstly, these systems are mostly built in such a way that erased files are only marked in the FAT as erased but can still be retrieved. After formatting, the blocks are indeed physically erased and cannot be retrieved. In addition, difference physical versions of one logical file can be present. This occurs when the size of the files is much smaller than the FLASH block size, which makes it more efficient to erase a file only if here is no more free space available. (Van der Knijff 2001, p. 321)

Additionally, data are generally stored in contiguous chunks rather than in a fragmented manner, making it easier to recover entire databases.

The structure of data on Palm OS allows individual to manufacture a database with any properties and import it into a device. For instance, using a program called files2pdb.java,^[6] a database with a fabricated date-time stamp can be created using the following command.^[7]

    examiner1% java files2pdb -n TestDB -a 0 -v 0 -t DATA -md 1470137001 \    -cd 1470138004 -bd 1470148004 -c test TestDB MemoDB1 MemoDB2    $ pilot-file -h TestDB    name: "TestDB"    flags: 0x0    version: 0    creation_time; 1950-08-02 07:40:04    modified_time: 1950-08-02 07:23:21    backup_time: 1950-08-02 10:26:44    modification_number: 1    type: 'DATA', creator: 'test' 

When this database is imported into a device, its last modified date-time stamp is updated but the fabricated creation and backup date-time stamps are not.

    examiner1% pilot-file -h TestDB    name: "TestDB"    flags: 0x0    version: 0    creation_time: 1950-08-02 07:40:04    modified time: 2001-09-30 13:58:00    backup_time: 1950-08-02 10:26:44    modification number: 11    type: 'DATA', creator: 'test' 

The ability to insert fabricated data may be used by criminals in some cases and should be kept in mind as a possibility during analysis.

^[1]Inserting a pin into a small hole in the back of the device that contains the reset button causes a soft reset.

^[2]A hard reset can be caused by power loss or by holding down the power key while inserting a pin into a small hole in the back of the device that contains the reset button.

^[3]Other deletion methods exist such as DmRemoveSecretRecords and DmDetachRecord but they are less common.

^[4]Handspring devices may require the "up" button to be depressed while writing the "2." Palm OS 4.0 and above require the power on password (if it is set) before putting device in console debug mode.

^[5]Card 0 refers to the internal RAM and ROM on a Palm OS device. Additional memory chips or modules are numbered card 1, card 2, etc.

^[6]http://www.righto.com/pilot/pdb.html

^[7]The header can be viewed using pilot-file from the Pilot-link package discussed later in this chapter.