Identity Theft Coming to a Mobile Device Near You

The increasing use of mobile devices for banking, money transfer, and payment is increasing the risk that criminals will target these devices for financial gain.

More banks are providing customers with the ability to access their accounts using mobile devices. In a number of cases, criminals have gained access to bank accounts by tricking cell phone providers into issuing SIM cards associated with the customer’s account.

December 2009: Duplicate SIM card was issued to an imposter with the driver license of the victim

In addition, fraudulent mobile banking applications have emerged for Android devices that attempt to steal personal financial information.

December 2009: USAA Thwarts Mobile App Fraud

These risks will continue to grow in the coming years as more mobile devices are used to execute financial transactions. Gartner’s top 10 consumer mobile applications for 2012 includes applications that enable mobile device users to make purchases and to transfer funds to others via SMS.

Digital forensic examination of mobile devices may be necessary in investigations of identify theft or data breach, providing clues about the origin and scope of an attack. In addition, financial institutions can use digital forensics techniques to assess the security of their mobile banking applications by searching for sensitive information that may be exposed on the device.

For those who want to stay current in digital forensics and incident response, I recommend taking the SANS FOR563 Mobile Device Forensics course. We are teaching this next in San Diego, May 8-12 (register here) and then at SANSFIRE 2010 in Baltimore, June 7-11 (register here).

Examining Windows Mobile Devices Using File System Forensic Tools

Windows Mobile file systems have similarities with other Microsoft operating systems that make for an easy transition into mobile device forensics for anyone who has performed forensic examinations of Windows computer systems. As with a desktop or laptop computer, Windows Mobile devices retain substantial information about user activities that can be relevant in a digital investigation involving Web browsing, user created files, and Windows registry entries.

Windows Mobile uses a variation of the FAT file system called the Transaction-safe FAT (TFAT) file system, which has some recovery features in the event of a sudden device shutdown. Here is the volume information of a memory dump from a Windows Mobile device, showing that it is FAT.

$ fsstat SamsungBlackjack.bin

FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: FAT16
OEM Name: MSWIN4.1
Volume ID: 0x8250047
Volume Label (Boot Sector):
Volume Label (Root Directory):
File System Type Label: TFAT16
Sectors before file system: 0
File System Layout (in sectors)
Total Range: 0 - 112389
* Reserved: 0 - 0
** Boot Sector: 0
* FAT 0: 1 - 110
* FAT 1: 111 - 220
* Data Area: 221 - 112389
** Root Directory: 221 - 252
** Cluster Area: 253 - 112388
** Non-clustered: 112389 - 112389

As with any FAT file system, forensic analysts can recover deleted files from Windows Mobile devices and view date-time stamps as shown below in Autopsy.

Samsung Blackjack Autopsy

The folder hierarchy on Windows Mobile devices has some similarities with other Windows systems. For instance, the majority of user-created files, including digital photographs and videos taken with the device camera, are stored in the “My Documents” folder.

Many of the lessons learned from forensic processing of other Microsoft Windows operating systems can be applied to Windows Mobile, including understanding of FAT file systems and index.dat files. Entries extracted from index.dat files on a Windows Mobile device using EnCase are shown below.

BlackjackEnCase
BlackjackEnCase

However, there are sufficient differences between Windows Mobile systems and other Windows operating systems to require specialized knowledge and tools to locate and interpret digital evidence. There are data structures on Windows Mobile devices like volume files that contain communications, contacts, and other useful information.  In addition, forensic analysts must be alert to interpretation errors introduced by forensic tools that result in important information not being displayed. Furthermore, the use of Flash memory in mobile devices has a number of implications from a forensic viewpoint, potentially retaining copies of deleted data that may not be accessible using commonly available methods and tools.

These and many other topics are covered in SANS FOR563 Mobile Device Forensics. I am teaching this course in San Diego on May 8-12 (register here).

Recovering Deleted Text Messages from Windows Mobile Devices

I have encountered a number of people who are dealing with Windows Mobile Devices in cases and need to recover text messages and e-mails, including deleted items. For the most part, the contents of such messages are stored in the cemail.vol database (MMS attachments are treated separately). This file can be acquired from a Windows Mobile Device as described in the Acquiring Data from Windows Mobile Devices blog entry.

The cemail.vol file is a proprietary Microsoft format and there are limited tools for parsing this format directly. In some situations, viewing this file using a hex viewer will reveal deleted messages and other items that are not acquired using common forensic tools. Although XACT from Microsystemation has the ability to interpret cemail.vol databases automatically, forensic practitioners with limited budgets are seeking lower cost solutions.

One effective approach to interpreting this type of database using freely available software is to mount a copy of the acquired cemail.vol file into a Windows Mobile Emulator and use the itsutils package to navigate the database and extract the desired items. The pdblist utility in the itsutils package can dump many databases on a Windows Mobile device.

To illustrate, consider the following message “I have your package” in an acquired cemail.vol file viewed with a hex viewer.

SMS Hex View

Mounting the Acquired File in Window Mobile Emulator

First, it is necessary to mount the acquired cemail.vol file in a Windows Mobile Emulator. Although it is not necessary to use an Emulator that exactly matches the evidentiary device, some similarity is recommended. There are a number of emulators included in Visual Studio. Additional emulators can be downloaded from the Microsoft Web site.

Once a suitable Windows Mobile Emulator has been selected, it is necessary to configure it to access the folder on the examination computer where the acquired cemail.vol file is stored. The following screenshot shows the shared folder being configured to point to C:\Documents and Settings\Administrator\Desktop\WindowsMobile, which is then accessible under the volume named “Storage Card” within the Emulator.

Emulator Configuration

After launching and configuring the desired Windows Mobile Emulator, it is necessary to create a conduit that itstutils uses to send commands to the Emulator by establishing an ActiveSync connection. You achieve this by opening the Device Emulator Manager in Visual Studio (under the Tools menu), then right-clicking the selected Emulator and selecting Cradle. In addition, within ActiveSync connection settings it is necessary to allow DMA connections.

Useful Commands

After an ActiveSync connection has been established with the Emulator, you can access its contents using components of the itsutils package. For our purposes, the pdblist utility can list accessible volumes, including the virtual “Storage Card” that contains the cemail.vol file to be examined as shown here:

 

C:\Tools\itsutils>pdblist -v
volume {00000000-0000-0000-0000-000000000000} \Documents and Settings\default.vol
volume {40684a00-994b-f835-7742-f7f435ba8d2b} \ReplStorVol
volume {15005d00-12f3-a6e9-76e8-595b9d742cc8} \mxip_notify.vol
volume {65ca7a00-7d53-6505-5671-0b1908d7e6eb} \cemail.vol
volume {225c1b00-e193-8a1a-785f-68f818cf3dd0} \Storage Card\cemail.vol
volume {c479de00-e4b7-9037-1352-dced359be0ad} \mxip_system.vol
volume {d071d100-fb8f-1505-782c-e71b23e00165} \mxip_lang.vol

 
More importantly from a forensic examination perspective, pdblist can list components of databases that are accessible via the emulator as shown here:

C:\Tools\itsutils>pdblist -D
volume {225c1b00-e193-8a1a-785f-68f818cf3dd0} \Storage Card\cemail.vol
oid310000c0: dbase F00000017 T00000000    0    356 ... 'fldr31000095'
   ORDERING: 0e060040:00000000 0c1a001f:00000002 0037001f:00000002 001a0013:00000000
[cut for brevity]
oid38000079: dbase F00000017 T00000000    1    484 ... 'fldr31000028'
   ORDERING: 0e060040:00000000 0c1a001f:00000002 0037001f:00000002 001a0013:00000000
oid32000087: dbase F00000017 T00000000    0    356 ... 'pmailAttachs'
   ORDERING: 81000013:00000000
oid37000081: dbase F00000017 T00000000    0    356 ... 'fldr32000023'
   ORDERING: 0e060040:00000000 0c1a001f:00000002 0037001f:00000002 001a0013:00000000
oid34000071: dbase F00000017 T00000000    3    800 ... 'fldr31000026'
   ORDERING: 0e060040:00000000 0c1a001f:00000002 0037001f:00000002 001a0013:00000000
[cut for brevity]
oid33000029: dbase F00000017 T00000000    0    356 ... 'pmailVolumes'
oid3b000017: dbase F00000017 T00000000   53   3768 ... 'pmailNamedProps'
   ORDERING: 8300001f:00000000 83010013:00000000
oid30000009: dbase F00000017 T00000000   12   1020 ... 'pmailMsgClasses'
   ORDERING: 8300001f:00000000 83010013:00000000
oid30000007: dbase F00000017 T00000000    0    356 ... 'pmailOldTables'
oid30000003: dbase F00000017 T00000000    6   1824 ... 'pmailMsgs'
   ORDERING: 800c001f:00000000 0e090013:00000000 00150040:00000000
oid30000001: dbase F00000017 T00000000   21   3052 ... 'pmailFolders'
   ORDERING: 0e090013:00000000
[cut for brevity]

 
The same utility can be used to dump a particular object by name. Working through the objects listed in the above pdblist output, the same text message shown earlier in a hex viewer is revealed in fldr31000026 as shown below using the pdblist command in this manner. Additional details like the date-time stamp associated with the message are also displayed along with other text messages.
 

C:\Tools\itsutils>pdblist -d fldr31000026
3f000089 (  284 12      2)
        8005 T13 L0000 F0000 UI4 838860938
        8011 T13 L0000 F0000 UI4 3
        001a T13 L0001 F0000 UI4 822083599
        003d T1f L0000 F0000 STR [00169898]( 0) ''
        0037 T1f L0000 F0000 STR [0016989c](19) 'I have your package'
        0e17 T13 L1ebe F0000 UI4 262144
        0e06 T40 L0000 F0000 FT  2009-04-22 21:01:47.000
        0e07 T13 L0004 F0000 UI4 33
        0c1f T1f L0000 F0000 STR [001698c4](11) '14438509426'
        0c1a T1f L0000 F0000 STR [001698dc](11) '14438509426'
        8001 T13 L0001 F0000 UI4 1056964745
        3008 T40 L9b35 F0000 FT  2009-04-22 21:01:47.000
3000008e (  284 11     78)
        8005 T13 L0000 F0000 UI4 973078668
        8011 T13 L0000 F0000 UI4 5
        0e17 T13 L0001 F0000 UI4 0
        001a T13 L0000 F0000 UI4 822083597
        003d T1f L0000 F0000 STR [00169888]( 0) ''
        0037 T1f L1ebe F0000 STR [0016988c](13) 'meeting place'
        0e08 T13 L0000 F0000 UI4 9284
        0e06 T40 L0004 F0000 FT  2009-04-22 21:05:45.000
        8001 T13 L0000 F0000 UI4 805306510
        0e07 T13 L0000 F0000 UI4 268501033
        3008 T40 L0001 F0000 FT  2009-04-22 21:05:45.000
3e0000a1 (  284 12     72)
        8005 T13 L0000 F0000 UI4 855638176
        8011 T13 L0000 F0000 UI4 7
        0e1b T13 L0001 F0000 UI4 0
        8012 T13 L0000 F0000 UI4 0
        001a T13 L0000 F0000 UI4 822083597
        003d T1f L1ebe F0000 STR [00169898]( 0) ''
        0037 T1f L0000 F0000 STR [0016989c]( 8) 'codeword'
        0e08 T13 L0004 F0000 UI4 17015
        0e06 T40 L0000 F0000 FT  2009-04-22 23:56:46.000
        8001 T13 L0000 F0000 UI4 1040187553
        0e07 T13 L0001 F0000 UI4 268501033
        3008 T40 L006d F0000 FT  2009-04-22 23:56:47.000

 

Additional Evidence

Be aware that Windows Mobile creates temporary files in various locations where you may find useful information depending on what you are seeking (e.g., e-mail, MMS). We cover Windows Mobile in the SANS Mobile Device Forensics course, and we delve into cemail.vol and other useful data sources on these devices. The next course is January 11 – 15, 2010 in New Orleans.

SANS SEC563

Eoghan Casey is founding partner of cmdLabs (http://www.cmdlabs.com/) , author of the foundational book Digital Evidence and Computer Crime, and coauthor of Malware Forensics. He has been involved in a wide range of digital investigations, including network intrusions, fraud, violent crimes, identity theft, and on-line criminal activity. He has testified in civil and criminal cases, and has submitted expert reports and prepared trial exhibits for computer forensic and cyber-crime cases.

Acquiring Data from Windows Mobile Devices

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. 

 

sec563_4_528x90

 

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
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).

Top 7 ways investigators catch criminals using Mobile Device Forensics

Modern day mobile devices are a double-edged sword, creating new security risks while providing valuable sources of evidence for digital forensic investigators. Their ever expanding capabilities make mobile devices more like personal computers that accompany us as we navigate the world. Digital forensic investigators can use information stored on and generated by mobile devices to reconstruct our movements, communications, and other personal details.

 

If you need to extract information from cell phones, smart phones, and other mobile devices, or are concerned about the security of data on such devices, here are some important things you should know.

 

Bypassing Security Codes: Digital forensic investigators can extract the security code from some locked mobile devices using specialized tools. The screenshot below shows the security code “12345” recovered from a Nokia 6230 using  .XRY (subscriber identifier redacted). Being able to bypass security mechanisms on a mobile device enables digital forensic investigators to acquire data from the device with forensic software. 

Nokia 6230 security code recovered using .XRY

 

Safe SIM Card: Inserting the wrong SIM card into a cell phone destroys some useful data in memory. To mitigate this issue, digital forensic investigators can create “safe” SIM cards designed for forensic examination purposes.

 

Live Acquisition: Removing the battery from a cell phone before performing a forensic acquisition may destroy valuable evidence. In some cases, to ensure that all available evidence is preserved, digital forensic investigators will leave a mobile device powered on until a forensic acquisition can be performed, taking precautions to prevent external influences from altering data on the device.

 

Trusted Time Source: Even if the clock on the evidentiary device is incorrect, some time stamps on the device may still be accurate because they are generated by system on the core network. For instance, the time stamp in a received SMS message is set by the Short Message Service Center, not by the phone.

 

Tracking Movements: Some mobile devices store location-based information associated with certain media and actions on the device. Digital forensic investigators can recover this information to determine the geographic location of the mobile device at a particular time. For instance, the following screenshot shows Exif metadata extracted using JPEGsnoop from a digital photograph taken using a G1 mobile device. This metadata includes the date and time the photograph was taken and GPS coordinates of the location (location details redacted).

JPEGsnoop used to extract Exif data from a GPS tagged digital photograph

 

Recovering Deleted Data: When the user clears the call log from a cell phone, it may still be recoverable with relative ease. Therefore, even when call logs are not displayed on the device, digital forensic investigators may be able to view details about dialed, received, and missed calls on the device using readily available tools.

 

Getting Physical: Digital forensic investigators can recover substantial amounts of deleted data from an increasing number of mobile devices by acquiring and analyzing the full contents of memory. This screenshot shows a physical memory acquisition of a Nokia 6610 using the Sarasoft application via a Twister flasher box.    

 

Physical memory dump of Nokia 6610 using Twister flasher box and Sarasoft

 

Deleted data like photographs, call logs, and traces of user activities (e.g., Web browsing and file viewing) recovered from a mobile device can provide digital forensic investigators with some of the most useful and incriminating evidence in a case. 

 

To learn how to perform these and other Mobile Device Forensics techniques, joins us for the debut of SEC563 Mobile Device Forensics in Baltimore, July 27 – 31 (register here). This is an intensive technical course with plenty of hands-on exercises to familiarize you with the inner workings of various mobile devices and show you the benefits and limitations of various approaches and tools. We not only demonstrate state-of-the-art mobile forensic tools and techniques, we peel back the layers of digital evidence on mobile devices to show what is going on behind the scenes. In this way, you obtain a deeper knowledge of the information you rely on when investigating cases involving mobile devices.

SEC563 - Mobile Device Forensics

 

Eoghan Casey is founding partner of cmdLabs (http://www.cmdlabs.com/) , author of the foundational book Digital Evidence and Computer Crime, and coauthor of Malware Forensics. He has been involved in a wide range of digital investigations, including network intrusions, fraud, violent crimes, identity theft, and on-line criminal activity. He has testified in civil and criminal cases, and has submitted expert reports and prepared trial exhibits for computer forensic and cyber-crime cases.

Common Pitfalls of Forensic Processing of Blackberry Mobile Devices

by Eoghan Casey

Digital forensic investigators who are not properly trained will alter evidentiary media or will misinterpret important information, potentially damaging a case. Pitfalls that less experienced practitioners encounter when processing Blackberry devices are discussed below with guidance on how to obtain the most useful information from these devices.

We frequently encounter Blackberry devices in digital investigations that are not fully supported by commonly available forensic tools. Fortunately, a significant amount of data can be obtained using Blackberry Desktop Manager, which is freely available from the manufacturer’s Web site. In fact, even when forensic tools can acquire data from a Blackberry device, it is still advisable to obtain a logical backup using Blackberry Desktop Manager. By logical backup, we mean that only active items on the device are copied, not deleted data. An IPD file can contain almost any type of data stored on a Blackberry device, including call logs, calendar items, photos, contacts, text messages, e-mails and associated metadata.

There are several reasons for making an IPD backup of a Blackberry device even when a forensic tool can acquire data from the device:

  1. Nobody knows Blackberry devices better than the manufacturer (RIM), and their software may obtain more data than some forensic tools.
  2. Data acquired using a forensic tool can be compared with data in an IPD backup to ensure they are consistent.
  3. The IPD file can facilitate additional analysis such as inspecting data using ABC Amber Blackberry Converter or a Blackberry device simulator.

From a forensic perspective, there are some important considerations when creating an IPD backup file using Blackberry Desktop Manager. By default, Blackberry Desktop is configured to synchronize some data between the device and computer. Failure to disable these synchronization options will alter data on an evidentiary device. At the very least, the date and time on the device will be changed to match the computer clock. This alteration of an evidentiary device can negatively impact a forensic examination, particularly when multiple devices from different time zones are involved. For instance, if the original date and time settings of the device were not documented, it may be difficult to ascertain exactly when specific events occurred.

To prevent Blackberry Desktop Manager from altering an evidentiary device, it is necessary to select the Synchronize item in Blackberry Desktop Manager and disable all options as shown below.

Blackberry Desktop Manager Configuration
Blackberry Desktop Manager Configuration

By default, the “Update device’s date and time” is selected along with the Automatic synchronization option. Therefore, it is necessary to explicitly deselect these options before attaching an evidentiary item to the acquisition system.

As mentioned above, an effective and inexpensive tool for examining data in an IPD file is ABC Amber Blackberry Converter. However, once again, it is necessary to change the default configuration before using this tool to examine an IPD file for forensic purposes. Specifically, the “local time zone” option must be deselected as shown below to prevent all times in the IPD file from being updated to the time zone of the examination system.

ABC Amber Blackberry Converter Configuration
ABC Amber Blackberry Converter Configuration

Keep in mind that Blackberry IPD backup files may exist on a user’s computer. These backup files are particularly useful when the original Blackberry device is not available or accessible. Even when the original device is available, these backups may contain historical data that are no longer stored on the device.

By default, recent versions of Blackberry Desktop Manager save IPD files in the user’s “My Documents” folder with the filename “Backup-(yyyy-mm-dd).ipd” but the user can provide and alternate location and filename. Fortunately, IPD files contain the distinctive line “Inter@ctive Pager Backup/Restore File” in their header. This header signature can be used to perform a comprehensive search of storage media for IPD backups.

To learn more about forensic acquisition and examination of mobile devices, including Blackberry devices, register for SEC563 Mobile Device Forensics.

Eoghan Casey is founding partner of cmdLabs (http://www.cmdlabs.com/) , author of the foundational book Digital Evidence and Computer Crime, and coauthor of Malware Forensics. He has been involved in a wide range of digital investigations, including network intrusions, fraud, violent crimes, identity theft, and on-line criminal activity. He has testified in civil and criminal cases, and has submitted expert reports and prepared trial exhibits for computer forensic and cyber-crime cases.