10 Conducting a Collection of a Mobile Device: Considerations and Actions

Now that the environment has been set and you understand some of the problems that may result, let’s get into the actual processing and collection of the mobile device. As covered previously, connecting to the device to complete an extraction can be difficult at times, so starting with a clean system and arming yourself with knowledge of troubleshooting problems can keep your frustrations to a minimum. Once a device successfully connects, you’ll find that collecting the digital data from the mobile device will be one of the more straightforward procedures in mobile forensics. Before we get into the connection and extraction of the digital data, let’s look at some initial considerations.

As discussed in Chapters 2 and 5, the status of the device when it is received and how the request to process the device is made will often steer the type of examination that will occur and all subsequent steps thereafter. If the device is powered on when it comes to the lab or is located at the scene, the initial steps in the examination as well as the workflow could be much different than they’d be if the device were powered off.

The type of collection (such as logical or physical) of a mobile device is another important consideration. The type of collection required is generally determined by the type of investigation underway, the time needed or available, the device to be examined, the training and expertise of the examiner, and the tools available for the job. No matter what type of collection is used, proper isolation and documentation of the device and its components are necessary, because the processing order can be dictated by both. The type of mobile device that is to be examined can also determine how the collection should be approached.

Feature phones, also referred to as legacy devices, add a different dimension regarding preparation before the collection, but the actual extraction of the digital data from these types of devices is no different from that of the latest smart device. The setup of these devices prior to device collection is also important to the overall success of the digital data collection.

Alternative methods for collecting mobile device data are available for some devices such as BlackBerry, Android, Windows Phone, and iOS, and these should also be considered if traditional collection methods do not work or are unsuccessful; however, the initial preparation of the device prior to the data collection should be no different.

Initial Considerations

Before beginning the collection phase on the mobile device, the examiner must reflect on the various aspects of the collection, such as whether the examination will take place on the scene or in a lab. Additionally, the state of the device is important. Most devices arrive at the lab powered off. Sometimes, while on scene, the device is powered on and the examiner must immediately take steps to examine it.

In most instances, whatever the state of the device at the time of collection, it must be powered on to be processed.

Prior to processing a mobile device of its digital contents, an examiner must consider other aspects of the examination. From documenting the state of the device in written form and in photographic form, to processing associated evidence, there are many nuances to a mobile device collection, and each must be considered. Also, the type of examination (whether logical or physical, as discussed in Chapter 8), must be considered. Conducting a physical collection outside the lab is not recommended, but it may be necessary based on the situation. To determine the need for and urgency of a specific type of collection, the examiner must consider how much time is available to complete the collection along with the type of data that is expected by either the requester or examiner.

Adhering to a sound methodology for all mobile device encounters will help solidify the resultant data and overall examination. The specifics are outlined in detail in the following sections of this chapter.

Isolating the Device

The examiner conducts the initial observation and subsequent processing according to the device state—powered on or off, or even in pieces. Whether the device is brought to a lab or the examiner conducts an on-scene examination, his or her first step should be to make sure that the device is isolated from any network connections. Device access to a network (such as cellular, Wi-Fi, or Bluetooth) can corrupt and even destroy the data.

If the device is powered on, it must be isolated immediately. Methods and appliances to isolate include but are not limited to mesh, bags, boxes, tents, rooms, and even signal disrupters (illegal in the United States, with exception of specific federal agencies). After the device is properly isolated, the examiner must be sure to keep the device isolated during the entire examination process.

This section is not intended as a guide for the examiner in isolating the device; that information was covered in Chapter 6 and is continued later in this chapter.

If the mobile device is powered off at the scene or when brought to the lab, the examination should commence immediately using a systematic approach. The physical characteristics of the mobile device should be documented, and all peripheral evidence (such as a Universal Integrated Circuit Card [UICC] or media card) should be forensically collected.

It is good practice to keep a device in a signal isolated bag, even if it is powered off. Some devices can turn power back on if an alarm has been set, which could lead to a connection to a network and possible data loss or contamination.

Whether the device is powered on or off, the examiner must research to determine whether the device can be examined physically using a non-invasive method, which could include both software and hardware solutions. Armed with this information, along with the level of the examiner’s expertise, the current status of the phone (on, off, or locked), and the software that will be used, the examiner can decide on the next step.

Device Collection Type: Logical or Physical

The status of the mobile device upon reception or discovery often determines whether the device should be processed logically or physically. The type of examination is contingent on the device’s power status and whether the device is locked, password protected, or disabled (disassembled or broken). Prior to conducting the initial collection of the device, the examiner must consider operational speed, available tools, and his or her level of expertise and training.

Not all mobile devices can be collected physically. An iPhone 5 to X, for example, cannot be collected physically using non-invasive methods. The following suggestions are offered to the examiner with the full understanding that each type of device encountered must be approached in a unique way.

In general, a physical collection should occur first to provide a representation of the overall data on the mobile device and can validate a logical collection. During a physical examination, any information collected can be used as a foundation for the data from a logical extraction. This foundation is extremely important, because this is the information on which a logical collection will stand. With a physical collection, an examiner can clearly show where the information “lived” when it was extracted during a logical collection.

If a physical collection is not achievable, a logical file system extraction can suffice.

By the examiner first obtaining the foundational information from a mobile device with a physical collection, any information that subsequent tools or logical extractions produce can be directly compared to the device file system. Comparing the data collected from a logical examination with the data from a physical collection is powerful evidence, especially if data recovered corroborates or contradicts either collection. Having this type of information is extremely powerful to an examination and to the overall outcome of the investigation.

Conducting one type of collection before the other generally does not constitute a disaster or epic failure, but in most situations, conducting one without the other can jeopardize the investigation. What will determine the order of the collection type (physical or logical) are the circumstances dictated by the scene, investigation, time allotted, or request.

Some examiners say that a physical collection should always precede a logical collection because of wear leveling, which arranges flash data so that write/erase cycles are distributed evenly among all of the blocks in the device. Simply reading data would not corrupt or overwrite existing data in a forensic examination, however, so this theory should not be the sole basis for conducting a physical collection of a mobile device prior to a logical collection.

Time Issues

Investigations that are not time sensitive or that have been submitted to a forensic lab should obtain a physical collection prior to a logical collection, when possible. As mentioned, by conducting a physical collection first, the examiner can rely on the underlying data to verify any information collected with the logical collection.

If an investigation depends on the examiner accessing the information quickly and in a format that can allow immediate follow-up, a logical examination should be first. With a logical collection, the investigator can immediately follow up on the information that is extracted from the device. A logical collection is also beneficial if the device loses power or is powered off and a lock is enabled. This quick collection can also assist if the device does not support a physical collection or if a physical collection is not possible for other reasons; the extraction can occur later either when time allows or upon arriving at a location that can conduct a physical collection safely and efficiently.

Device Power and Security Status

The power status of the mobile device should also be considered when determining whether to perform a logical or a physical collection first.

The type of investigation should be the primary directive in determining the type of collection, and the power status of the device should be secondary. If the investigation dictates immediate action, then whether a device is powered on or off does not matter. If the device is already powered on, process it logically first.

A physical collection should be attempted first if the mobile device is powered off when it is acquired. This can be accomplished with many feature phones if the connection to the device is via a USB or FBUS cable. These feature phones are often powered off while the device is placed into a special mode (such as flash, download, or bootloader) and cannot connect to a network. Also, if a device is powered off and it is a GSM (Global Systems for Mobile Communications) device containing a UICC, the card should be removed. When the card is removed from an iOS, Android, or Windows Phone, the device will be isolated from the cellular network and the examiner can attempt a physical collection using a USB and other non-invasive methods. With devices such as a Samsung SPH-D710, for example, an examiner can conduct a non-invasive Joint Test Action Group (JTAG) collection relatively easily with the device powered off. In this case, researching the device and the various ways to complete a physical examination are important before the examination begins. The physical collection should be a non-invasive physical technique, but the device can still be examined logically later.

If the device is powered on and unlocked, it should be processed logically first, because if the device is processed physically first and the device battery is removed or the device is turned off, the device can lock and a logical examination could be difficult. After the logical collection, the mobile device can be powered off for a physical collection and a locking mechanism will not be an issue.

A password-protected or locked device typically offers the examiner one initial collection method: physical. During a physical collection of the device, the examiner can hopefully obtain the passcode to access the device logically if required.

Sometimes a device may be collected physically but the passcode cannot be obtained to unlock the device and conduct a logical collection. In these instances, a physical collection will suffice.

Device Damage

If a mobile device is damaged (such as by exposure to water, a broken USB connection, or a damaged electrical system or circuit board), the device should first be examined physically using non-invasive methods and then using invasive methods if needed. In some cases, the examiner has only one chance to obtain data from the mobile device, and the only connection that can be made requires using an invasive technique. Because a damaged mobile device is unlikely to be able to be examined both physically and logically, a physical examination may be the only option. However, every attempt should be made to collect the device logically after completing a physical collection.

Initial Documentation

The documentation stage, which should occur just prior to collection, enables the examiner to capture not only the device details but also all associated materials. Having photographic evidence of the device, UICC, battery, and media card not only enables the examiner to complete a detailed report, but it also helps when the device has to be reassembled!

Photographs and documentation of the initial collection should detail every angle so that there is no question as to which device a card or battery belongs with. In addition, when examining multiple pieces of electronic evidence, never pile the UICC cards together; this helps avoid the tedious task of identifying which UICC goes with which device later on.

Photo documentation should begin as soon as the evidence is received. The outside of each evidence container should be clearly visible in each photograph. In addition, the chain of custody form should be clearly visible, and if an evidence seal is used, it should also be photographed to show it has not been manipulated or tampered with. When the evidence is removed from the evidence container, it should be photographed immediately to include all pieces that are within the container; the associated case number should also be clearly visible, as shown in Figure 10-1. The same procedure should be completed with each evidence container prior to beginning the individual examination of the artifacts; the examiner should be sure to return the evidence to each container after completing the documentation and examination. This will ensure that evidence items from different containers do not commingle.

FIGURE 10-1 A Kindle Fire mobile device shown alongside the UICC card, both a part of Case# 15-225, item K

Each container may contain multiple artifacts, but a single artifact (such as a mobile device or media card) should be removed from one container at a time. Each item should be photo documented in great detail and examined individually prior to the extraction of data from the device. During the collection phase, only one piece of evidence should be out of the container at a time. This helps ensure that items that are not part of the current case or extraction are not introduced to the evidence for the current case; this can easily occur if multiple devices are lying around with loose UICC or memory cards.

The following sections offer descriptions and information regarding handling the various types of evidence encountered during a mobile device exam and the proper ways of documenting each artifact. Order of documentation depends upon the power status of the device, on or off, and typically defines the documentation phase. A diagram showing the process for documenting mobile device evidence is shown in Figure 10-2.

FIGURE 10-2 Using the device state as a cue to the documentation phase can help the examiner develop a systematic approach while maintaining power to the device if needed.

Device

If the device is powered on and isolated from the network, documentation should include a clear image depicting the device within the isolation environment; if the device is in airplane mode, the image can be taken outside of an isolation environment. Also, a photograph should document the current display of the device that clearly shows the device carrier, date, time, and desktop or main screen. Documenting the date and time on the device is extremely important during the examination phase of the extracted data. This information is often critical in an investigation; the owner of a collected mobile device can change its date and time in an effort to throw off the examiner, for example, if this detail is critical to text messages, e-mails, or device use. Without this information, the collected data from the mobile device can be extremely confusing.

Documenting the initial screen was especially important with early-model Nokia mobile devices that lost the date and time and GMT (Greenwich Mean Time) offset when the battery was removed. Documenting the screen would enable the examiner to reset the date and time if needed to the proper time or use the offset information when converting dates that were extracted.

The back of the device and the USB connection should also be photographed to detail any imperfections, damage, or obstructions. This can help to dispel any allegations that the device was damaged during the examination process. Photographs should be taken of the device within its protective case, if applicable, and then outside of the case, including images of the front, back, and sides. It is important that the sides of a mobile device be photographed to show the location of a memory card slot. After a memory card slot is located, the protective flap should be carefully moved to photograph whether a memory card is inserted or not; the card should not be removed. With a device that is powered on, the collection phase of the examination would start at the completion of the device documentation.

Some devices, such as those in the Apple family, show clear model numbers on the exterior rear of the device. Be sure to document these numbers clearly.

If the device is powered off, the order of documentation is considerably different, with the exception of the initial photographs of the exterior of the device. The first few photographs should be of the front, back, sides, and USB connection with the case on (if applicable), and then with the case removed. These images will be used to identify the device and also document the current state of the device. If the device has a battery compartment, it should be opened and photographed. With the battery compartment exposed but the battery not removed, the examiner should locate and photograph the memory card and UICC slot if visible. Sometimes the memory card and UICC slot are under the battery, and the battery will have to be removed. Removing the battery should expose the device serial numbers, device information, memory card, and UICC if available (see Figure 10-3).

FIGURE 10-3 The serial numbers of the device should be clearly visible, along with the memory card still in place.

Some devices, such as those in the Apple family, do not allow the battery to be accessed and do not have memory cards.

Battery

If the device is powered on, the battery should not be photographed or accessed until after the device has been successfully collected logically. If the device battery is accessed while powered on, the device may lose power, and if security is enabled, the device may be locked. After a device that is powered on has been successfully processed, the examiner can logically access the battery compartment to complete the documentation, as described next when dealing with a device that is powered off.

If the device is powered off and the battery has been photographed in the device, the battery should be removed and photographed. The front, back, and sides should be photographed, and any distortions to the battery should be indicated. A failing battery should be documented, which is generally noticeable by a bulge in the center of the battery (Figure 10-4).

FIGURE 10-4 A normal battery (front) and a bloated battery (back). The middle of the back battery is distended and could explode, causing damage to the evidence and possibly the examiner.

“Thermal runaway” is a phenomenon caused by the battery failing to dissipate heat faster than it is generated; the increased temperature of the battery distorts the plastic container, causing the battery to appear bloated. This was clearly identified as the cause of the recall of the Galaxy Note 7 phones in 2016.

Prior to starting an examination of the mobile device with a damaged battery, the examiner should insert a new battery into the device so that the damaged battery does not breach and subsequently damage the mobile device.

UICC

If the device is powered on, the UICC should not be removed until after a logical collection has been completed successfully. Access to most UICC cards is via the battery compartment, and removing the UICC card may allow the device to lose power. If a device loses power, and if security was enabled, the device may lock and a logical examination would not be possible. After a device has been processed logically, the examiner can follow the process to document the UICC card for a device that is powered off.

Some devices can contain multiple UICC slots. If more than one UICC is located, all should be documented as indicated in this section.

If the device is powered off, the UICC may be in various locations, depending upon the device family. For iOS devices, the UICC slot is located on the top or side of the device. For most other devices, the UICC is in the battery compartment. The UICC location should be photographed in place prior to removal. Once removed, the UICC should be marked with the case number and evidence number if it has not been marked already. This marking should not obstruct the serial numbers on the exterior of the card. The UICC should also be photographed alongside the mobile device it was removed from; the UICC serial number, or the ICCID (Integrated Circuit Card Identifier), should be clear in the photograph. This documentation can help identify that the UICC is associated with the device if this detail is challenged later. Both sides of the UICC should be photographed along with the case number and evidence number. The UICC can then be processed with mobile forensic tools, and a forensic clone can be created, if needed.

Once processed, the UICC should be taped to the mobile device’s exterior, not reinserted into the device, because this would enable the device to communicate with a cellular network if the device was somehow powered on when repackaged. If a UICC must be inserted into the device, use the created forensic UICC instead of the original card. By taping the original UICC to the device, the examiner can be sure that the card will not be misplaced during the examination of other evidence and that it is matched with the device to which it belongs. As outlined, mobile devices, wearables, and IoT devices may contain an internal UICC card, and currently the information must be obtained with common commands via the interface since the physical card cannot be removed.

Memory Card

If the device is powered on, the memory should not be removed until after a logical collection has occurred successfully. Most mobile forensic tools will allow for the collection of data from these memory cards during an extraction, so removing a card while the device is powered on could miss critical data.

Android devices containing external memory cards can corrupt the data on the memory card if it is removed while the device is powered on and not unmounted first. If the device is powered on, unmount the memory card prior to removal to avoid this issue.

Some memory cards are accessed via the battery compartment, and removing the memory card could cause the device to lose power and lock. After a device has been processed logically, document the memory card in the same way you would if the device were powered off.

If the device is powered off, the memory card location should be photographed prior to removing the card. The memory card slot is on the top or side of the mobile device, under the battery, or in the battery compartment. Once removed, the memory card should be marked with a case identifier and evidence number and photographed alongside the device. The media card can then be physically collected separate from the device and reinserted into the device when complete. If the device is going to be collected physically, the memory card can remain inserted; that way, if a logical examination is also performed, the memory card will be available.

Remember that all photographs should include the case number and evidence number assigned to the article. Clearly photographing the progression of the collection will help for later documentation and also dispel any allegations of evidence tampering, destruction of evidence, or other issues.

JTAG, ISP, or Chip-Off

If a mobile device examination will be at the level of a JTAG (Joint Test Action Group), ISP, or chip-off examination, documenting the internal components is also important. For JTAG, ISP, and chip-off examinations, prior to disassembly, the examiner should follow the previously outlined steps to photograph the device and its components. Once the device is disassembled, the printed circuit board (PCB) should be photographed prior to making any connections. Once connections have been made to the JTAG test access ports (TAPs), a photograph should clearly document the connections to the ports. At the conclusion of the collection and removal of the connections, the printed circuit board should again be photographed and then again after the device is reassembled. For chip-off examinations, photographs of the memory chip should be taken prior to removal, after removal, after reballing (if applicable), and during a read of the memory chip.

This amount of documentation may seem extreme, but showing the examination’s progression and clearly showing that the chip in the device is the same chip that was collected can help immensely later if any challenges occur.

Mobile Device Isolation Methods

The techniques or methods used for isolating the device are often dictated by the device type. Whatever method or technique is employed; the isolation of the device must remain constant during the entire collection if the device is powered on. If the device can be collected while powered off, it is still a good idea to isolate the device if power is still available to it, because the device could be inadvertently powered on by the examiner or the software.

Several different isolation methods and techniques are covered in this section, from manually changing the device communication, to placing it in rooms devoid of radio waves. When selecting the type of isolation method, the examiner must remember that various factors can interfere with the technique’s consistency and coverage. As outlined in Chapter 6, different frequency ranges are used by the various technologies built into a mobile device. The techniques used by the examiner should be tested on all frequencies encountered in the course of the examination.

If a device is not properly isolated from the network, data loss can result, because cellular, Wi-Fi, and Bluetooth networks offer conduits to the device’s internal file system—a mobile device can pair with an active Bluetooth device in the examiner’s office, or it can authenticate on an open Wi-Fi guest network in the area. Although the result may not be data loss, the integrity of the data will be changed with the addition of information unrelated to the case. If the device accesses a cellular network or the Internet, a signal submitted to the device can also remotely wipe all the information from the device, making any type of recovery next to impossible. By following the simple steps and techniques covered in this section, an examiner should not have to worry about these types of scenarios.

Chapter 6 covered the various communication methods that are used in today’s mobile devices: cellular, Wi-Fi, Bluetooth, and near field communication (NFC) are used for both the reception and transmission of data. These services should all be inhibited during the collection process when possible using one or more techniques outlined.

Some solutions, including Cellebrite UFED Touch 2, UFED 4PC, MSAB XRY, and Oxygen Forensic Detective, among others, include a function for extracting data from devices using Bluetooth technology. If Bluetooth is inhibited, data transfer cannot occur from the device to the forensic solution. In these cases, the device Bluetooth must be enabled.

Methods, Appliances, and Techniques for Isolating a Device

There are various ways to isolate a mobile device from the network, and their differences are many. Isolation products range in cost from free to thousands of dollars. Some signal isolation products are portable; some are not. Some products require practice to use; others do not. Before deciding upon the best appliance solution, the examiner should vet it using real-world scenarios and testing, since many variables can affect even the most expensive appliances. Also, in some cases, an appliance is not needed and a method or technique can be used instead.

Before embarking on any isolation solution train, the examiner must test and retest the solution with live mobile devices where most of the mobile device collections are going to take place. If all device collections are conducted at a lab, testing is much easier. However, if the scene of mobile device collections is variable, the examiner must ensure that the solution is suited to isolating the strongest signal that may be available at the scene. What makes the selection of a signal isolation tool so difficult at times is that the installation of a new cellular tower by a local carrier can render a signal isolation device unable to protect the device from unwanted signals. The distance to the nearest tower can affect the usefulness of the solution, simply because the closer the device is to the tower, the stronger and more concentrated the signal will be. Also, if an isolation solution had been successfully tested with a third-generation (3G) device but the device to be examined is capable of using a fourth-generation (4G) signal—and soon fifth-generation (5G)—the solution might not be rated to block those signals, which ultimately can breach the supported barrier and reach the device. Many free apps for iOS (available from the iTunes Store) and Android devices (on Google Play) can read the radiofrequency (RF) signal strength in a particular area. Using these apps can help the examiner determine what course of action to take and whether a particular appliance will be effective.

An app should be thoroughly tested prior to using it in an actual forensic environment, where real evidence will be examined. Also, during testing, the app should be installed to a controlled device, not to the device that is to be examined.

Sometimes, the easiest solution when deciding on a proper appliance is not to use an appliance at all. Several chapters have mentioned placing a device into airplane mode, a technique that is the easiest to use and at times the most difficult to convince examiners to use. It is easy because all modern mobile devices have an airplane function, which inhibits all forms of communication, but it’s difficult for some examiners to embrace because the device must be manipulated—that is, buttons are pushed and screens are accessed. Some examiners believe doing this negatively impacts the device collection, but as mentioned in Chapter 6, placing a device into airplane mode is described in NIST and SANS documents as a viable technique to isolate a device.

If airplane mode is not available or the protocol requires that the examiner manipulate the device as little as possible, there could be another option. With GSM smart phones from Apple, Android, Windows Phone, and BlackBerry, the examiner can remove the UICC card and still process the mobile device. Without the UICC card, the device is effectively isolated from accessing the cellular network, but Bluetooth, NFC, and Wi-Fi can still be available. More information on processing mobile devices without UICC cards will be covered later in Chapter 11, but remember that the removal of a UICC card could mean the device must be powered off and any security feature that is active could be enabled. Because CDMA (Code Division Multiple Access) mobile devices operate primarily without a UICC, this method and approach will not work with those devices.

If security is enabled, airplane mode can still be accessed for the smart devices outlined in Chapter 5. Because security is already enabled, the device can simply be powered off, because turning off the device is not going to lock the device further. The examiner should then research the locked device to determine how to process it effectively.

If a device is powered on, the methods used to isolate it are similar no matter whether the device is GSM or CDMA, but they depend on security. If the mobile device does not have security enabled, both CDMA and GSM devices should be placed into a signal isolation appliance so that the examiner can visually see and manipulate the device.

Once inside the isolation appliance, the examiner can place the device into airplane mode and then remove the device from the appliance. Several available appliances will enable the examiner to see the device, push buttons, navigate capacitive screens, and even photograph it. Table 10-1 lists two appliances that have been used to process and interact with a mobile device in active investigations. Other isolation appliances that do not have the ability to connect to a computer are not listed in the table, but they are typically less expensive. At times, examiners have even used several wraps of aluminum foil or lined and unlined metal paint cans to isolate a mobile device during transport or while awaiting collection.

TABLE 10-1 Appliances Used to Process and Interact with a Mobile Device in Active Investigations

A study, “A Field Test of Mobile Phone Shielding Devices,” was conducted in 2010 at Purdue University that tested various RF-isolation appliances and mobile devices. The testing involved sending various messages and content to mobile devices while they were inside an appliance. No appliance tested passed at 100 percent signal blocking 100 percent of the time. Be aware of this when using any isolation appliance. Although the study is almost a decade old, it still holds valuable information on the lack of protection with some isolation techniques.

A signal isolation appliance enables the examiner to fix portable power, access external USB connections, conform to capacitive screens on today’s mobile devices, and view the device through a transparent window. The appliance can be connected directly to a power source and a computer and easily monitored. This technique can be used when the examiner does not want to remove the device from the appliance or navigate the device to locate airplane mode. When the examiner can keep the device in the same isolation appliance, whether at the lab or on the scene, outside contamination by both radio signals and the various people who come into contact with the mobile device can be minimized.

Signal isolation bags are made of interwoven metal fibers that degrade over time, leaving gaps where signals can escape and enter. Because this degradation is not visible, it is important that you replace these bags frequently and handle them with care.

Some techniques and methods are specific to the type of mobile device (that is, CMDA or GSM). Because of these differences, each technology is discussed in a separate section.

CDMA Devices

CDMA devices can be isolated using appliance-based solutions (such as isolation bags and boxes) and airplane mode if they are powered on, but some CDMA devices can also be processed without powering them on, bypassing security. When connected with a USB cable that allows charging and data transfer, CDMA devices—feature phones, in particular—often have enough power to be recognized by the computer. Once the device is recognized, a driver is loaded, and the mobile device can be processed as if the device were powered on.

Carefully monitor the CDMA device when plugging the device into the computer, because some devices will start a boot-up process.

If the CDMA feature phone is powered off, removing the battery and then plugging the device into the computer with a charging cable seldom boots the device. However, when the battery is attached to the device and then plugged in, the phone booting sequence would begin. For smart devices of today, the device cannot receive enough power to allow the computer to recognize the device and load a driver, so this option is not available.

GSM Devices

For GSM devices, creating a forensic subscriber identity module (SIM) clone can effectively isolate a device from the cellular network. Because a feature/legacy CDMA device does not contain a card to access and authenticate on a cellular network, this process will not pertain to these devices, only to GSM. Why not just remove the UICC from the mobile device and in that way isolate the device? This would be the best course of action, and it has already been established that removing the UICC in a smart device such as an Android, Apple, BlackBerry, and Windows Phone still allows for the collection of the device’s data. However, this is not always the case, especially with feature phones. By removing a UICC from a feature phone, forensic software is unable to communicate with the majority of handsets, and examiners are forced to take isolation of the mobile device seriously. Because the UICC must stay within the feature phone for a logical forensic examination to be successful, the device must be isolated correctly. This is why a forensic SIM clone is needed.

The term “forensic SIM clone” was coined in a paper I wrote in 2008, titled, “SIMs and Salsa,” which outlined the vulnerabilities of U.S. cell carriers and showed how a forensic SIM could be created without the original SIM card. Some of the content is used in this section to describe the process of creating a forensic SIM.

In essence, the examiner will create a SIM card that will satisfy the mobile device’s need for specific files: the IMSI (International Mobile Subscriber Identity) and the ICCID. Here’s an excerpt from my 2008 paper, “SIMs and Salsa”:

The two files we will focus on in this document are the ICCID … and the IMSI…. We will be focusing on these two important files because these files are needed to complete a Forensic SIM Clone™ and effectively isolate the device from the cellular network. To further elaborate, some handsets only need the IMSI, while some need only the ICCID and in some cases the device needs both the ICCID and IMSI.

Mobile Forensics, Inc. coined the term Forensic SIM Clone because the completion of this method should not be considered in anyway a “clone” in the sense that the card is a duplicate of the original SIM. If that were the case then we have not effectively isolated the clone from the network because if it is a duplicate of the evidence all the network information still resides on the handset. If this network information still resides on the cloned card we know that the cellular network can add, delete or change data on the handset. Hence “Forensic” was added because all the network information is nonexistent.

The question asked by students and examiners alike is, “Why not just place a foreign SIM into the device so the device has a SIM and the forensic software can then process the device logically? Just place a T-Mobile SIM card into a T-Mobile phone, right?” Completing this type of process would result in dire consequences, however, because the mobile device would reject the SIM card and undoubtedly purge data, as the expected files (IMSI and/or ICCID) were not there. Most often, call logs would be deleted, but the deletion of images and videos was also observed on early iDEN (Integrated Digital Enhanced Network) model devices. To create a proper forensic SIM clone, the proper IMSI and ICCID must be obtained from the original SIM. If the examiner does not have the original SIM card or the original SIM card is locked, proper paperwork would have to be submitted to the carrier of record for the mobile device to obtain both the IMSI and ICCID. With both the ICCID and IMSI, a forensic SIM could be created manually onto a GSM test card and inserted into the mobile device. This, however, does not always work for the reasons outlined in another excerpt from “SIMs and Salsa”:

What if the original SIM card is PIN locked? SIM card is gone? Damaged? For starters, if the SIM is PIN locked you are limited by the inability of most logical software to process the device. Again, I say logical, we will discuss physical software shortly. We know if the SIM PIN is locked, the ICCID is still readable. This is due to the fact the ICCID does not need a security condition to be satisfied to be read. Reading the ICCID is easy, but how about the IMSI? Well, the opposite is true for the IMSI. The IMSI does have a security condition, the PIN. Unfortunately, if we do not have the PIN we cannot satisfy the condition to read the IMSI. Without the IMSI we cannot in confidence create a Forensic SIM Clone that the device will not think is foreign. So how do we obtain the IMSI?

There are three methods that can help with this dilemma.

•  Send court order to cellular carrier

•  Obtain the IMSI from physical memory

•  Or create the IMSI yourself

I am sure you are aware of the first solution. By sending a valid court order to the carrier they can supply the last IMSI utilized by the device and matches the ICCID you have supplied. The second way mentioned involves using specialized hardware/software to obtain RAW data from the device and then parse the data, recovering the last IMSI or last IMSIs of the SIM. The examiner can then manually type this information into the MFI Forensic SIM Cloner application and create a Forensic SIM Clone. I am sure you are wondering about the third situation, creating the IMSI yourself.

Here’s an elaboration on the first condition outlined in the document in reference to obtaining a valid IMSI from the carrier: If a user contacts the carrier to obtain a new SIM card because the old card has been lost, the information from the old SIM will be lost and the information (IMSI) returned will be incorrect for the device. This would mean a failure in creating a forensic SIM clone, so obtaining information from a carrier does not always mean obtaining the correct information to compile a forensic SIM manually. Obtaining the IMSI from physical memory of a device was a better method, and once this was obtained, it could be used to create a forensic SIM card and obtain access to the device.

To automate the process of both reading an original SIM and then writing to a test card, I created the MFI Forensic SIM Cloner (which is no longer available). All major commercial mobile forensic solutions now support the creation of forensic SIM cards when needed.

The creation of a forensic SIM card with today’s investigations is generally not needed simply because the majority of devices that need to be processed and collected are smart devices. To reiterate, a smart device can be forensically collected without a UICC card, unlike legacy feature phones of the past. However, understanding how and why a forensic SIM should be created is critical, even if this technique is seldom required in today’s examinations.

Mobile Device Processing Workflow

As you know, the examiner should follow a process for every mobile device examination. If proper isolation techniques have been followed, the recommended methods for processing a mobile device depend on whether the device is powered off or on. Several pieces of evidence can be collected from a mobile device, and each must be treated as a single piece of evidence during the processing phase. Figure 10-5 represents the suggested ordering of processing for various situations, and the following sections offer information on how to process the device in various situations.

FIGURE 10-5 Mobile device evidence processing workflow

Device is powered on and unlocked   Evidence processing should be conducted in this order:

1.  Mobile device   The mobile device should be processed logically, and when the examiner is satisfied with the results, it should be processed physically, if possible.

2.  UICC   The smart card should be processed, obtaining the complete file system.

3.  Memory card   The memory card should be processed outside of the body of the mobile device and a physical image created.

4.  Cloud extraction   Additional data is available that might not be part of the device collection, and every attempt should be made to collect the cloud services associated with the device and owner.

Device is powered on and locked   Evidence processing should be conducted in this order:

1.  UICC   The smart card should be processed, obtaining the complete file system.

2.  Memory card   The memory card should be processed outside of the body of the mobile device and a physical image created.

3.  Mobile device   The mobile device should be processed, physically if possible. If a physical image is obtained, obtaining security information for bypass from the physical image may be necessary to then conduct a logical examination.

4.  Cloud extraction   Additional data is available that might not be part of the device collection, and every attempt should be made to collect the cloud services associated with the device and owner.

Device is powered off   Evidence processing should be conducted in this order:

1.  UICC   The smart card should be processed, obtaining the complete file system.

2.  Memory card   The memory card should be processed outside of the body of the mobile device and a physical image created.

3.  Mobile device   The mobile device should be powered on and, if not locked, the mobile device should be processed logically; when the examiner is satisfied with the results, it should be processed physically.

4.  Cloud extraction   Additional data is available that might not be part of the device collection, and every attempt should be made to collect the cloud services associated with the device and owner.

Device was powered off but is now powered on and locked   If the examiner turns on a mobile device and it is locked, the UICC and memory card should have already been processed. The final processing would involve the mobile device and cloud services:

1.  Mobile device   The mobile device should be processed, physically if possible. If a physical image is obtained, obtaining security information for bypass from the physical image may be necessary to then conduct a logical examination.

2.  Cloud extraction   Additional data is available that might not be part of the device collection, and every attempt should be made to collect the cloud services associated with the device and owner.

Feature Phone Collections

Most collections of mobile devices today involve smart devices, but because feature phones are still available and in use, these devices are also considered here. In general, a feature phone is a mobile device that contains voice telephone calling, text messaging, and Internet features such as e-mail and web browsing, but it lacks the independent apps available for a smart device. A feature phone typically uses a built-in keypad or a number dialing pad, and the user must use a series of key presses to access alphabet characters. Feature phones do have built-in applications, but they lack the ability either to install or upgrade apps. These devices generally have a proprietary or embedded file system that does not allow outside developers to create applications, so they rely on built-in apps that ship with the device.

This does not mean that there is no available data to be collected from a feature phone—in fact, quite the contrary is true. As mentioned, these devices contain a file system, and within the file system are artifacts you could expect on a smart phone, with Internet histories, GPS coordinates, and multimedia messages. The difficulty is not in the collection, but in the decoding of the data. Because of the lack of documentation from manufacturers (for obvious reasons), feature phone data repositories can be difficult to decipher and decode.

This book does not offer not an exhaustive list of feature phones, and some devices may support only the extraction of a small subset of the proposed list. The type of data that can be extracted varies, and the software that is used to complete the extraction should be consulted to see what data should be expected.

Connecting to a Feature Phone

The examiner should research to determine the best way to connect to a feature phone using available forensic software. Connection can be via USB, Bluetooth, or IrDA (Infrared Data Association). If the device has been isolated within an appliance, generally the only available connection method will be USB, so determining the software capabilities could impact the isolation mechanism, technique, or appliance. Once the connection method has been determined, the examiner should research whether or not the device must be placed into a certain mode to conduct a transfer to a mobile forensic solution. For example, to connect to a Nokia 5300 device and many other Nokia feature phones, the device must be placed into Nokia Mode by navigating to the appropriate menu on the device after a USB cable has been attached to the computer and to the phone. If the device is not in the correct mode, forensic software solutions will not be able to connect and collect the user data. The examiner should research data transfer methods and any specific settings by reviewing the model’s user manual prior to beginning a collection. These manuals are easily located on the manufacturer’s site, Phone Scoop (www.phonescoop.com), or GSMArena (www.GSMArena.com). Having a clear idea on how the connection will be made before beginning will save the examiner time when and if problems are encountered during the connection process.

Most connections to feature phones are made via a USB connector on the device. Feature phone USB connections have never been regulated, so many different types of connectors have been used, which can make connecting to the many devices difficult at times. All USB connections, however, communicate using specific pins on the USB head connected to the pins on the exposed USB connection on the phone. If any of the pins on either the cable or device are corroded, missing, or nonoperational, a connection cannot be made. The examiner should carefully inspect both the cable pin connections and the connections on the device to ensure a successful connection and data collection. If any debris is seen inside of the USB connection port, the examiner can use a small wire brush to clear it away. After a successful connection to the computer using a USB cable, the device is recognized and driver installation begins.

If a cable with a serial-to-USB converter (such as Prolific or FTDI) is used, the examiner cannot be sure that a successful connection has been made to the device until a forensic software solution is used. Because the installed driver is for the cable and not the device, the examiner may be required to reexamine the device if the software cannot connect.

If a connection cannot be made and a driver does not load, the examiner can check the type of cable being used (see Figure 10-6). Some USB cables are for charging only and do not allow data transfer. Because specific pins are used to charge and others are used to transmit and receive data, a faulty cable may be a charging cable that does not have the Tx (Transmit) and Rx (Receive) pins. The examiner can exchange the cable with another cable that is known to be a data transfer cable.

FIGURE 10-6 The many different types of cables used for feature phones can make collecting data difficult at times.

Device State Considerations

In order for a driver to install successfully and a solid connection to be made, the feature phone must be at least 50 percent charged or be connected using a charging cable. A charging cable has an extra pin that allows the device to receive power from the USB hub on the computer while connected. This is a good alternative if the device does not have a 50 percent charge and time is critical.

If a device does not have enough power when it is connected to the mobile forensic solution and computer, failure during processing may occur, such as the inability to recognize the device driver, a collection failure, or a successful collection but incomplete data. A computer communicates with the mobile device through the driver, and if the device does not have enough power to bridge the two devices, run system processes, and keep the phone functioning, this communication will not occur. When power is not sufficient or available, the driver either fails to load or ceases functioning at some point.

A failed collection is obvious to the examiner, because the software crashes or returns information identifying that connection cannot be made to the device, with a suggestion to reconnect and try again. Receiving this error during the collection can be frustrating, but it can be managed. Even if a device is not sufficiently charged, some software will return the collected data as though a successful collection had been achieved, but closer inspection will show that data is missing. This consequence can be devastating, because the examiner believes that no error has occurred and considers the collection complete. In fact, NIST, as part of its testing for mobile forensic software, disconnected a device that was being collected to determine whether this effect could occur to the software. The resulting physical disconnection of the device was similar to the behavior of a device that was 50 percent charged, and, as NIST noted, some software solutions will not indicate to the user a failure has occurred.

Collecting the Device Logically

If the feature phone is powered on and not locked, the examiner should first attempt a logical collection after the device has been isolated. The device can be connected to the computer using the prescribed and supported methods and placed into the proper mode if applicable. Next, the examiner can apply the solution of choice for a logical collection.

A file system collection should always be attempted first if such a collection is not a part of the standard capabilities supported by the software. Collecting a file system of a feature phone enables the examiner to demonstrate unequivocally in documentation and testimony where data came from during the logical collection of the phone. Too often, examiners simply allow the software to identify the data (such as contacts, call logs, and Short Messaging Service [SMS]) without completely comprehending where the actual file that contains this data “lives” within the device’s embedded file system. When a file system is extracted from a feature phone, however, this is no longer a limitation, because the file is available for inspection, examination, hashing, and documentation.

If a file system option is not available or has already been completed, the examiner can obtain a surface collection of user data. This WYSIWYG extraction uses device protocols to query the device files, parse the extracted information, and present the data to the examiner in the solution interface. This type of logical collection can be compared to navigating the mobile device interface to locate the information and then using the software to extract that same information into the forensic solution. Typical feature phone surface collections include contacts, call logs, SMS, Multimedia Messaging Service (MMS), calendar, notes, and media.

Having this information immediately available can help steer any additional follow-up and also help to identify areas of interest to the examiner during a file system examination and after the device is collected physically. The biggest benefit to conducting a logical collection as a first step with a feature phone is ease of collection and support. Most feature phones that are not disabled by the carrier can be collected logically by most mobile forensic solutions with a USB cable, and most surface data can be parsed. However, obtaining the file system of a feature phone along with the surface data is recommended.

Associated Evidence (UICC and Memory Cards)

Feature phones also can contain a UICC and memory cards. As mentioned, each item should be treated as a separate piece of evidence. Following the recommended guidelines on processing, the examiner should examine the UICC and memory card first if the device is powered off and last if the device is powered on. Collecting each card individually outside the body of the mobile device is important, because it will assist the examiner in collecting much more information that can be used later in the investigation if needed.

UICC   With feature phones, the UICC can contain much more evidence than would be found on a smart device’s UICC and should not be ignored. Because of the limitations on the internal storage of a feature phone, some valuable information is stored on the UICC, including text messages and contacts. This storage setting can be controlled within the device by the phone’s user.

Most mobile forensic tools will allow some information to be read from the UICC from within the mobile device during a standard logical collection. Unfortunately, this information is very limited. The examiner should always collect the UICC outside of the body of the device, to enable the UICC and its complete file system to be collected and later examined. When conducting a collection of a UICC, the examiner should make sure that the forensic tool allows for a full file system collection of the card, not just the surface data. With the file system, the examiner can verify and validate the data that has been parsed and displayed and locate additional information, as outlined in Chapter 11.

Memory Card   Generally, a memory card within a feature phone contains far less data than a memory card in a smart device, but some newer Nokia feature phone devices contain a 32GB card. Typically, the smaller size limitation has to do with the phone’s internal capacities to recognize larger memory cards. During a logical examination, the memory card can be read by most forensic software while it is within the phone, so the card should not be removed until this is complete. Once the memory card is removed, the examiner should also physically read the card using a forensic tool that will allow for the creation of a forensic image of a mass storage device. AccessData FTK Imager is a free alternative for creating a forensic image, along with paid commercial tools from Guidance Software (EnCase), Oxygen (Oxygen Forensic Detective), Cellebrite (Physical Analyzer), and several others.

When creating an image of a memory card using one of the mentioned tools, the examiner should be sure to have a write-blocking mechanism or appliance in place. Doing so will disable the abilities of the software to write to the evidence.

The creation of a physical image will allow for a deeper analysis of the memory card, which will include unallocated space and file slack, which generally contains deleted data. This type of data is not recoverable when the memory card is within the device and standard logical collection has taken place.

Collecting the Device Physically

If the feature phone has been powered off and is locked or disabled, or after completing a logical extraction of the mobile device, the examiner should do a physical collection of the device. A physical collection of a feature phone is critical and advisable in all situations if the device is supported for a simple reason: deleted data is almost never available in a feature phone’s file system with a logical collection. If deleted data is required for a case, a physical collection of a feature phone is necessary.

Cellebrite supports the most feature phones for both GSM and CDMA physically, with MSAB coming in second because of its limited CDMA support. Unlike a smart phone, a feature phone’s physical image includes only a small part of the device’s internal memory. With a feature phone’s memory measured in megabytes, this does not yield a lot of additional data, but, when possible, a physical image should be obtained.

When collecting a feature phone physically with a mobile forensic tool, the examiner should remove the UICC and the memory card from the device prior to starting the acquisition. Methods for obtaining a physical collection of feature phones were derived from the methods and code used by service tools, as discussed in Chapter 8. Overheating has been known to occur during acquisition, which could damage the UICC and memory card if they are inserted in the device at the time of the physical collection. Also, the UICC and memory card are not needed, nor are they a part of the area the tool will read to obtain the internal memory area.

If using other means, such as a flasher box, JTAG, or chip-off, the examiner should follow the procedures described in Chapter 8. Prior to the examiner beginning the physical acquisition, it is critical that a logical collection occur.

After a collection is completed, the examiner can analyze the information obtained in the physical collection. This is a labor-intensive process, because a lot of forensic tools currently do not support the decoding of the feature phone’s file system. Tools such as MSAB XRY and Cellebrite Physical Analyzer do allow for the decoding of many feature phone file systems. These file systems can then be compared with the logical extraction during the critical data analysis phase. File system and data analysis for feature phones are covered in Chapter 12.

Archiving the Data

During each phase of the feature phone collection, all data collected from the logical collection, to the UICC and memory card, to the physical acquisition of each image, along with all associated data, should be securely stored on an evidence drive prior to the examiner beginning the analysis phase. This storage location should use a unique name that pertains to the case or investigation. All subsequent analysis will be on a copy of the data that was collected during the primary acquisition. By doing this, the examiner is never working on the original data from any phase. By archiving data, the examiner can be assured that if the software or computer malfunctions, the original evidence will still be available if a new examination of the data must occur.

BlackBerry Collections

BlackBerry devices were once prevalent in many examinations, but today, in my experience, they account for less than 1 percent of investigations. BlackBerry devices were one of the most easily collected devices by forensic software, but now they are one of the most difficult. Early BlackBerry devices’ content, backup, and storage methods were documented and available to developers all the way up to version 7. Because of this level of documentation, software vendors and open source engineers built tools to mimic BlackBerry desktop software to create a local backup of the device and then parse the resultant files. This method drastically changed with the release of BlackBerry 10, an operating system built from scratch. With this new file system, along with the methods a version 10 device uses to create a backup, forensic tools have a difficult time producing usable evidence. Today’s BlackBerry collections remain tedious, but since devices are using Android, the analysis and decoding of the data have become more reasonable.

With the current market share of BlackBerry reported at the end of 2016 as 0.0 percent by Gartner, commercial tool manufacturers have stopped development cycles on these devices. Forensic examiners around the globe encounter no more than five devices a year per current surveys and polls conducted during conventions and speaking spots of active examiners. However, information on all devices is important for a well-rounded examiner.

Connecting to a BlackBerry Device

As with all mobile forensic solutions, the connection to a BlackBerry device requires a USB cable—either a mini USB or micro USB connection. Like any other mobile device, the BlackBerry must be isolated using an appropriate isolation method or appliance.

BlackBerry was the first reported smart device that could be remotely wiped using settings within the phone. This was first reported on the forums at crackberry.com in 2008, when BlackBerry had not even added the feature to its user guide. However, this feature was used by a criminal to wipe his BlackBerry while it was being transported to be examined, and the story is often used in forensic training classes.

If a BlackBerry is powered on and locked, the examiner must know the password to access the device. Also, if the BlackBerry has encryption turned on, a secondary password might be requested, which could be different from the first. If either password is not known, the examiner will not be able to connect to the device using a USB cable; however, connection to any other associated artifact (such as the UICC and memory card) can still be attempted.

Device State Considerations

If possible, the examiner needs to know the BlackBerry access passwords, whether the device is controlled by a BES (BlackBerry Enterprise Server) or the device is unlocked. By having both passwords (handset and encryption), the examiner will be able to conduct a logical or physical collection. If the device is set up with a BES, the administrator of the BES can disable or enable the password and encryption for the device, if needed.

For BlackBerry 7 and older devices, the examiner will recognize that a device is locked by the padlock icon that is displayed in the lower-right corner of the screen. If the device is also encrypted, another padlock will be visible at the upper left. The device will have to be unlocked using the previous suggestions or by enabling the info.mkf file on the memory card. This file is available only on the memory card at /BlackBerry/system/ if the device is locked and the card has been encrypted using either the BlackBerry Security Password or Device Password mode. If this is the case, the examiner can use the Elcomsoft Phone Breaker tool to obtain the password. This method will not uncover all passwords, however, especially if they are complex, unless a dictionary has been compiled. The password, if obtained, can then be used to create a backup of the device.

On BlackBerry 10 devices, security is similar to that of prior versions with device passwords, device encryption, and media card security and encryption. One difference, however, is that locked version 10 devices cannot be accessed using the info.mkf memory card file. If a device is locked, the only way to bypass security and obtain a forensic image is by obtaining the password, or the BES 10 admin can reset the password if possible.

Collecting the Device Logically

If the device is powered on and the examiner has access to the device with disabled security, he or she can perform a logical extraction using most mobile forensic software. This involves attaching a USB cable, plugging the cable into the computer, and selecting the device to be collected. The software will perform a backup of the device, similar to the backup functions in the BlackBerry Desktop software, and then parse out the database files for supported user data files. The BlackBerry collection does not contain a typical file system as you would expect, but a listing of all of the database files from the device. In a logical collection, it is important that the software enables the examiner to access each of the database files, regardless of the software’s ability to parse out the user information. In other words, the examiner should be able to examine the complete set of files collected from the BlackBerry device to verify and validate the solution’s parsing ability, as well as uncover additional data the solution might not be currently able to extract.

Current mobile forensic tools do not support the collection of a BlackBerry 10 device directly, but some can produce a backup and then conduct an analysis. This method will be explained later in the section “BlackBerry Collections.”

Much like a feature phone, if the BlackBerry also contains a UICC and memory card, the artifacts should be removed and processed. However, because of the limitations also imposed on a physical collection by a locked device, a physical collection should be attempted before an acquisition of the UICC and memory card if the device is unlocked. If the device is locked or powered off and known to be locked, the UICC and memory card can be processed first as described in the preceding section, making sure a physical collection of the memory card takes place.

Collecting the Device Physically

The physical collection of a BlackBerry device using a USB connection is limited to a small number of devices and even a smaller set of forensic tools. Cellebrite UFED Touch currently supports physical collection of 50 various CDMA and GSM devices, as indicated in its current supported devices list (www.cellebrite.com/mobile-forensics/support/ufed-supported-devices), but the device password must also be known. Currently, BlackBerry 10 devices are not supported for a physical collection by any tools via a USB connection.

JTAG can be used on locked devices if the password is not known, but this technique is relegated to older devices because BlackBerry has made the TAPs extremely difficult, if not impossible, to use. The only alternative method would be an invasive physical examination. The chip-off method can be used on devices up to but not including BlackBerry 10, and the created binary file can be examined and decoded using Cellebrite Physical Analyzer or Oxygen Forensic Analyst. However, even when the chip-off method is used, examining BlackBerry 10 devices is impossible because the data is encrypted at the chip level. So even with a successful binary dump, the data could be unreadable and unusable.

Additional Collection Methods

Both free and commercial mobile forensic solutions use the same protocols used by the manufacturer’s software, and at times using the software developed by the manufacturer can be beneficial. However, the BlackBerry software up to version 7.x, BlackBerry Desktop Manager, also allows data to be restored and synced to a connected device, so the examiner must be careful when using a software tool that can synchronize data to a device being examined. BlackBerry 10 devices use BlackBerry Link software, which also allows the device to be backed up and restored. Currently available tools cannot complete a backup of a BlackBerry 10 device independent of using the BlackBerry Link software. Furthermore, the output file that is created by the software is encrypted and unable to be parsed by most currently available software, with two exceptions: Oxygen Forensic Detective and Elcomsoft both support the ability to open BlackBerry backups from BlackBerry 10 devices.

With new BlackBerry devices and the underlying Android operating system, the examiner can conduct a backup of the data using the USB debugging bridge (also known as ADB) as well as the associated Google account. These devices have a function that allows for the backup of the data for later restore if the device is lost, stolen, or damaged (https://help.blackberry.com). The information that is backed up to the Google account includes the following:

•  Google Calendar settings

•  Wi-Fi networks and passwords

•  Home screen wallpapers

•  Gmail settings

•  Apps installed on Google Play

•  Display settings

•  Language and input settings

•  Date and time settings

•  Third-party app settings and data (varies by app)

To back up the information manually on a BlackBerry, tap the cog icon and then tap the Backup & Reset button. A Google account must be configured.

BlackBerry Desktop Backup Software   To create a backup of a BlackBerry device successfully using BlackBerry Desktop Manager software, the examiner must first install and properly configure the software, which can be downloaded from http://us.blackberry.com/software/desktop.html. Both Mac and Windows are supported. The examiner should make sure to disable automatic syncing upon connection and ensure that automount is disabled on the forensic computer so the memory card is not altered by the operating system. When the examiner sets up the device, My Computer’s Date And Time With My Device should be unchecked, as shown in Figure 10-7. The BlackBerry can then be backed up.

FIGURE 10-7 Disable the synchronization feature before connecting the device.

BlackBerry IPD and BBB Backup Files   An IPD (Inter@ctive Pager database) backup file is produced with the BlackBerry Desktop software running on Windows machines up to version 7, and a BlackBerry Backup (BBB) file is produced on the Mac versions of BlackBerry Desktop up to version 7 of the BlackBerry software. The IPD is a single file that contains multiple other database files that make up the content on the BlackBerry device. The Mac BBB file (up to version 7) is a compressed IPD file. At version 7.1, BlackBerry transitioned to creating BBB files on both Mac and Windows machines using BlackBerry Desktop, and the BBB is still a compressed file, but it now comprises .dat files. Each .dat file contains various data and data types. BlackBerry Desktop is no longer updated by BlackBerry because the company is transitioning users to the BlackBerry Link solution.

BlackBerry Link also creates a BBB file that differs from the Desktop BBB file. The difference is encryption: The newer BBB file is fully encrypted independent of user interaction on the device or within the Link software. This means that if a backup is going to be read within a forensic software solution, the examiner must have a key piece of information: the BlackBerry Link password associated with the BlackBerry user account. Technically, the examiner will need both the user account associated with the device and the password, but current software, such as Oxygen Forensic Detective, which supports the analysis of BlackBerry 10 devices, reads the user ID from the manifest and requests only the associated password. What can cause difficulty is the fact that the Link password is completely independent of the device password, so even if the device password is known for the BlackBerry 10 device and it is unlocked, the collected backup might still not be able to be examined if the Link password is unknown. The BlackBerry Link password must be used to decrypt the files to enable the software solution to parse the available user data. Furthermore, the verification of the BlackBerry ID by the BlackBerry server is used for BlackBerry Link and is necessary for the decryption of the backup-and-restore process. The software solution must be online for this process to be successful.

The BBB file that is produced is similar to the original BBB compressed file, but new BBB files contain a manifest file and informational file that are not encrypted and can offer information about the device. This file is needed by the current software solutions mentioned in previous sections along with the BlackBerry Link password. Mobile forensic software from Oxygen Forensics allows the new BBB files to be decrypted and analyzed with the correct BlackBerry account password for both live and backup collections.

With the introduction of the Android runtime to the BlackBerry device, the device is much more accessible to recover without the use of the BlackBerry backup software.

Archiving the Data

Much like a feature phone collection, the BlackBerry data and UICC and memory card information should be securely stored on an evidence drive prior to beginning the analysis phase. This storage location should have a unique name that pertains to the case or investigation. All subsequent analysis will occur on a copy of the data that was collected during the primary acquisition.

Even if the BlackBerry 10 device is currently encrypted, the examiner should create a backup if possible. This will enable the examiner to perform an analysis at a later date if a password is eventually discovered or additional techniques are introduced. Software solutions are always advancing with more options available. Having the file at the onset, even if not currently usable, would enable it to be parsed with new technology.

Windows Mobile and Windows Phone Examinations

Although the Windows Mobile operating system is no longer on the market and Microsoft has transitioned to Windows Phone, Windows Mobile systems are still being used. Windows mobile devices, both Windows Mobile and Windows Phone, differ regarding collection, the ability to access user data, and data layout. Today, the Windows Phone holds a small portion of the smart device market share, but it continues to grow. Undoubtedly, an examiner will be requested to complete an examination of a Windows Mobile or, more likely, a Windows Phone at some point.

Windows smart phone devices were released in 2000 as a mobile solution based on Windows CE (Compact Embedded) and saw exposure as Pocket PCs and the Windows smart phone based on CE 3.0. Windows Mobile 2003 was running 3.0, and in 2004, Windows Mobile 5 was released and 6 followed, all progressing on the CE architecture. The last available Windows Mobile version, 6.5, was released in 2009, and Windows Phone 7 became available in 2010, which was not just a complete rebranding, but something completely new.

At the release of the Windows Phone 7, users and examiners alike saw a complete change in the collection and recovery of a Windows mobile device. Windows Phone 7 was not based on previous Windows Mobile functions and accessibility, and as such it created problems for digital forensic examinations. In 2011, Windows Phone 7.5 was released, and version 7.8 added some Windows Phone 8 capability, since 7.8 devices could not be upgraded to Windows Phone 8 because of hardware limitations. In 2012, Windows Phone 8 was released and in 2014 upgraded to version 8.1. The device was again rebranded as Windows 10 Mobile in 2015 as a way to unify with the PC operating system. What has been of benefit to mobile forensics examiners is simply the market share of 0.01 percent by Windows devices, which means Windows devices aren’t involved in most mobile forensic examinations. However, with the massive move to cloud services by most mobile device apps and devices themselves, the data can often be recovered as long as the data was backed up to the service.

Remember that a Windows device can also contain a UICC and memory card, so the correct procedure in processing these pieces of evidence should be followed, depending upon the state of the mobile device.

Connecting to the Device

Communication with a Windows Mobile device and a Windows Phone both generally require a USB cable and computer, but the way and conduit in which the communication occurs differ between the two devices. Communication to the Windows Mobile device occurs using Active Sync or Windows Mobile Device Center (WMDC) protocols. Both operate using a hardware abstraction layer, much like how iTunes operates with an iOS device. Active Sync and WMDC are not capable of the same communication layer with a Windows Phone device, so Microsoft Zune was released to accommodate that. However, the access to a Windows Mobile device using Active Sync and WMDC is considerably more verbose than a connection to a Windows Phone using Zune. In 2015 Microsoft released the Windows Phone Companion to act as a conduit to the flagship Windows 10 operating system that supported Windows 10 Mobile devices, Android, and even iOS. It has been rumored the software has been discontinued and a form of the Companion will be incorporated into the Windows 10 OS.

When connecting either a Windows Mobile or Windows Phone device, the software must have preinstalled drivers, or the examiner must install drivers for the device. Most forensic software that supports Windows Mobile devices will either have Active Sync or WMDC installed as part of the driver package. Connecting and then collecting with a Windows Mobile device, as mentioned, is similar to doing so on an iOS device, in theory. The examiner will use the data syncing function built into the Windows Mobile device architecture and operationalized via Active Sync or WMDC, install a file to the device or device SD card, and initiate the card on the device. Connection and logical collection can occur only using an intermediary file, also referred to as an agent. The agent, using the Active Sync or WMDC connection, transfers data to the forensic software. The examiner must ensure that the loaded file does not overwrite inactive data.

Windows Phone logical collections using commercial and open source tools involve using the Zune software, ActiveSync, WMDC, Windows Phone Companion, or a derivative.

Some commercial tools have harvested some of the functionality from the Zune software to bundle into their driver packages, but these tools will not allow Zune to be installed along with the forensic software. If a Windows Phone cannot be recognized, make sure the forensic software is not conflicting with Zune, if it’s installed.

Collecting the Device Logically

If the device is powered on and unlocked, and after connection has been made to the Windows Mobile device using Active Sync or WMDC, the agent recovery process will begin. Typical data recovered using mobile forensic tools includes contacts, call logs, SMS, media, and other critical user information. On the other hand, a Windows Phone will yield very little user type information with a logical collection. The information that is collected in a logical extraction of a Windows Phone is limited to media and documents. Really, anything that is accessible using a Windows Explorer instance will be collected in a logical collection using modern forensic solutions.

If the device is locked with a password, the only option will be to conduct a physical collection of the Windows Mobile or Windows Phone device.

With today’s Windows Phone 10 devices, a considerable amount of data can be collected from the user’s cloud account to include SMS, app data, phone settings, and media (images/videos). To set a device to back up to the account, the proper method, as outlined by Microsoft, is to tap the Windows key | Update & Security | Backup and then select both settings and app data. Furthermore, if a manual backup is needed in the case of a forensic examination, tap the Windows key | Update & Security | Backup | More Options | Backup Up Now. To back up the messages on the device, tap Settings | System | Messages | Turn On Sync Messages Between Devices. If media items (images/videos) are to be backed up, this will occur on One Drive, which can be extracted via the cloud backup. To set this option on the device, tap OneDrive | Menu | Settings | Camera Upload. Using this method will enable the collection of much more information than can be obtained using the standard USB connection.

Collecting the Device Physically

Most Windows Mobile 8 device models can be collected physically using non-invasive methods. Cellebrite, MSAB, and Paraben software include methods to recover a file system from a Windows Mobile device. When the examiner is conducting a physical collection of a Windows Mobile device, Active Sync or WMDC will be used to place an agent onto the device. The agent is then initiated and the recovered data is sent to the forensic software.

Most of the forensic tools are based upon the work by Willem Jan Hengeveld and the open source Remote API (RAPI) tools (www.xs4all.nl/~itsme/projects/xda/tools.html). RAPI is defined by the Microsoft Developers Network as follows:

The Remote API (RAPI) library enables applications that run on a desktop to perform actions on a remote Windows Mobile device. The functionality that RAPI provides includes the ability to manipulate the file system on the remote device, including the creation and deletion of files and directories. RAPI functions can be used to create and modify databases, either in the device’s object store or in mounted database volumes. RAPI applications can also query and modify registry keys as well as launch applications and invoke methods on the remote device. Although most RAPI functions are duplicates of functions in the Windows Embedded CE API, a few new functions extend the API. Use these functions to initialize the RAPI subsystem and enhance performance of the communication link by compressing iterative operations into one RAPI call.

Using RAPI tools and other advanced tools and command utilities without properly understanding and testing them is not advised.

The RAPI tools shown next enable the examiner not only to extract the database and system files but also dump RAM and entire partitions from Windows Mobile devices with more than 30 different functions. Only two of these functions are discussed in this section:

•  itsutil.dll   This file is copied to the connected device using Active Sync and is used as a helper library for access to the Windows Mobile device. This file can be copied to various locations on the mobile device and is set by using a Registry key on the examination computer.

HKEY_CURRENT_USERsoftwareitsutilsdevicedllpath [ "Storage Carditsutils.dll"

This places the file onto the storage card of the connected mobile device. A log file is also created if set to true, and its location can also be set in the Registry of the connected computer. When any item is executed using the itsutil.dll, the examiner will be prompted to accept this function on the mobile device interface.

•  pdocread   This command can be used to make a copy of the partitions on the mobile device. Using this command with a -l flag will list the known devices and the active handles on the device. This information will be used by the examiner to identify the correct user partition to be selected and then extracted. Using a -w flag when reading the selected partition will specify use of the standard disk API to perform the read. The format and parameters of the command should look like this:

pdocread -[flag(s)] -[partition] [starting byte] [ending byte] <path and output file name>

After obtaining a list of the partitions using pdocread -l, the examiner will see partitions identified as disks with partitions, but more importantly for collection, with string handles. Using the partition name (in hexadecimal) or handle number and total size of the partition (in hexadecimal), the examiner can then extract the partition from the device. If the output produced by pdocread lists the partition of interest as handle#3 73efe04a 60.98M (0x3cfc000), the command to create a binary image of this partition looks like this:

pdocread -w -h0x73efe04a 0 0x3cfc000 D:WindowsMobile.bin

A binary file will then be output to the D: drive and can be analyzed by EnCase, FTK, Oxygen Forensic Analyst and Detective, Physical Analyzer, or XACT.

On devices containing larger partitions, the standard disk output controlled by Windows can fail to extract the complete disk size specified in the command.

Windows Mobile applications cannot run on a Windows Phone, so a different approach to obtaining a physical image of the device is needed. Several methods for obtaining partition-level information from Windows Phone 7 have been circulated, which are much like the earlier versions of rooting techniques for Android. Still termed “rooting,” the level of sophistication and technical work involved with both Windows Phone 7 and 8 devices to obtain root-level access is daunting for most examiners. For version 7 and 8 devices, the examiner must have a device with an unlocked bootloader, and if the device is not unlocked, he or she must perform necessary modifications to the device to unlock the bootloader. Once unlocked, another application will be run to obtain permission and root the device. ChevonWP7 was frequently used with earlier Windows Phone 7 devices but has since ceased to be developed or used because of the difficulty involved in running it successfully.

With Windows Phone 7 and 8 devices, the most successful methods currently used to obtain a physical-level collection involve invasive techniques. Both version 7 and 8 devices are supported by JTAG techniques and chip-off. The collected image can then be examined in EnCase, FTK Imager, FTK, Oxygen Forensic Detective, Physical Analyzer, or XACT.

Alternative Collection Methods

Windows Mobile devices are supported pretty extensively by all commercial tools. With coverage for both logical- and physical-level collection, a commercial mobile forensic tool will often be the most reliable. However, alternative applications are available for Windows Mobile devices.

PIM Backup (www.dotfred.net/) has been used in MFI mobile forensic training courses and offers a free alternative to the logical recovery of valuable data from a Windows Mobile device. PIM Backup functions much like the commercial forensic tools and uses Active Sync or WMDC to install an application to the device over a connected USB cable. After the application is installed to the mobile device, it runs and the selected data is exported into individual files (such as CSV, XML, or iCAL files).

Windows Phone 7 and 8 do allow for the creation of a backup using Zune, but the backups are encrypted, and currently no tool can decrypt the backups. Some third-party tools also allow backups, but they also use the Windows Phone backup service that creates the encrypted backup. Windows Phone 7 and 8 devices enable the examiner to access files and folders that are stored on the internal memory and also the external card. Both versions use external and internal storage areas much like the standard Windows operating system and use these areas to store data that is directly related to the device operating system. If a memory card is removed, a Windows Phone could become unstable, and sometimes the device will have to be reset. This creates a great opportunity for the examiner to recover valuable information simply by moving the data from the memory card into an evidence location. This data could include media types, documents, and other files.

Windows 10 Mobile devices are also supported by the majority of mainstream tools, but the type of data that can be extracted is typically limited to the data that can be observed and extracted when the device is plugged in and mounted as a portable device in the collection operating system (for example, documents, media, or files on media card). However, with many tools now supporting the extraction of data from cloud services, critical data such as SMS messages, application data, and settings are now accessible.

Archiving the Data

All data, including physical images, exported files, backups, and logical images, along with physical images of memory cards and UICC information, should be copied to an evidence drive before the analysis phase. The information needed for the analysis phase should then be copied to a temporary location. The storage location should include a unique folder specific to the case and an internal folder that is specific to the device. Any additional evidence recovered as part of the analysis should also be stored permanently at this location once the case is completed.

As with BlackBerry devices, the current market share of Windows Mobile devices was reported in the first quarter of 2017 as 0.15 percent by Gartner. Commercial tool manufacturers have stopped development cycles on these devices, and forensic examiners will see even fewer Windows Phone devices than BlackBerry devices. However, knowledge of all devices is important for a well-rounded examiner.

Apple iOS Connections and Collections

A collection of an Apple device by a forensics examiner can be an almost daily occurrence, because Apple mobile devices are some of the most widely used devices globally. Connections to and collections of these devices are rather straightforward processes. Apple allows the device to communicate with a computer using its proprietary protocols via iTunes. iTunes enables communication to occur with the attached device, and a user can update applications, media, device firmware, and more. Forensic software vendors use the same type of communication methods used by Apple with iTunes. Forensic software vendors, third-party free utilities, and open source tools use methods and services that have been exposed in Apple’s API, enabling the software to simulate an iTunes communication session, but these tools also use methods that are not used in the iTunes application.

Communication with the Apple device is generally straightforward for each forensic solution. What will be the most confusing part for an examiner is understanding the logical versus physical support of an Apple device.

Connecting to the Device

Connecting to an Apple device with most traditional mobile forensic solutions requires a USB cable. Apple mobile devices up to and including the iPhone 4S and iPad 1 will use a standard iPhone 30-pin cable. When the iPad 2 was released, Apple changed the USB cable to an 8-pin Lightning Cable, and now all Apple devices use this cable for charging and syncing.

Many manufacturers have released less expensive cable products that violated Apple’s patent and produced a non-OEM (non-Lightning Cable) cable. Most of these cables are recognized by the Apple device when plugged in, but will not allow data transfer, or will cause failures during data transfer. For these reasons, using the Apple Lightning Cable for connection to an Apple device is recommended. More and more Lighting Cables are becoming available on the market that do not fail, however, and allow for a quality extraction—at a lower price.

The cable connection is located at the bottom of the device. After the cable is plugged into the computer, with iOS 7 and later devices, the examiner will see a prompt asking whether the computer should be trusted (see Figure 10-8). This security feature enables the device to create a pairing record with the attached computer if a pairing record has not already been established. (If the device has previously been connected to the computer and is unlocked, this prompt will not be shown. The pairing record that is created upon acceptance is discussed a bit later in this section.) Once the device is attached to the computer and the drivers have been successfully installed, the device can be collected using a software solution of choice as long as the iOS device and its OS version are supported by the solution.

FIGURE 10-8 The Trust Computer prompt must be accepted for successful data transfer.

If at any time the examiner chooses not to trust the computer, the device will have to be unplugged from the computer and then reattached for the trust prompt to be displayed again. If the examiner does not indicate that the computer can be trusted, the forensic software will be unable to collect the iOS device. If the prompt to trust the computer does not display, either the device is running an iOS version earlier than 7 or the device has already been deemed trustworthy. This is often the most encountered failure in the connection phase with an iOS device.

Device State Considerations

If the device is unlocked and powered on or off, collection will not be a problem, no matter what the operating system version. If the device is locked by a password and the password is known, the examiner should attach the device to the computer that will complete the collection, unlock the device, and then accept to trust the computer. Unlocking the device will create a trusted pairing relationship that will be used later during the collection if the device locks. If at any time the device has to be reexamined, a password will not be needed to complete a collection.

If the device is locked and running any version of iOS, the examiner can use the escrow keybag, also known as the pairing record. The escrow keybag is created and used for user experience during an iOS device backup-and-restore process. Where the escrow keybag for the iOS device is located depends on the type of computer operating system being used for the examination:

•  Windows   %ProgramData%AppleLockdown

•  macOS X   /private/var/db/lockdown/

Within the lockdown folder is a property list (plist) that is identified using the device UDID (Unique Device Identifier). Using these property lists will be covered in the discussion regarding locked devices in the following section.

When a user plugs in an iOS device with a set passcode, he or she is asked to enter the passcode. The device then creates an escrow keybag (pairing record) that contains the same keys that are used on the device, along with a new generated key. The escrow key and the new key are split between the device and the computer to which it is connected. With any reconnects to that same computer, a password does not have to be entered into the device for processing. By using the escrow keybag, the software can bypass the lock and process the mobile device. With iOS 7 and later versions, there is a caveat, however: if the device is rebooted and then reconnected to the computer that contains the device escrow keybag, the device could request the passcode to be re-entered, creating a new trusted relationship. Obtaining the lockdown folder from the computer with which the iOS device was last synced can help to process a mobile device that is locked. Using this folder and included property list files, the examiner can use mobile forensic software to use the file to simulate a pairing relationship with the iOS device and conduct a logical collection. Without this pairing record for today’s iOS devices, the examiner will be unable to connect and ultimately process any mobile device data.

Collecting the Device Logically

All mobile forensic tools use Apple File Conduit (AFC) and forms of AFC along with Apple Services to conduct a logical extraction of an iOS device, just like Apple’s own iTunes. iTunes must be installed on the forensic computer for a logical collection to occur for most software solutions; however, some software solutions that collect iOS devices do not require that iTunes be installed. All iOS logical collections are not created equal, and it is imperative that the examiner understand and research the data that can be extracted with the software solution that will be used. A software solution for an iOS device should be able to collect more data than would be available in a standard iTunes collection.

Consulting the forensic software solution’s documentation will assist in determining whether iTunes must be installed on the forensic computer prior to conducting a collection.

The connection and logical collection of an iOS device is the same for all devices, with some special considerations. Typically, the examiner can connect the USB cable, connect to the computer or hardware device with the collection software, and extract the data. The special considerations come in the form of an iTunes password and encrypted backups. If the device to be examined has the backup encryption set, the backup that is to be collected will not be readable. During the collection phase, the examiner must supply the password for the iTunes backup in order to decrypt the iOS data after it is extracted from the device. Most forensic software solutions offer the ability to decrypt the device backup from an iOS device. If the iTunes password is not known, some data will still be available for collection if the device is not locked, such as media and some application data.

A logical collection of an iOS device can include a significant amount of valuable data. Far too many examiners believe that only a small amount of data is available in a logical iOS collection and neglect to perform a collection. In Chapter 13, you’ll see why this is not the case.

An iOS device does not have an external media card, but it can contain a UICC, which should be removed prior to the collection. Personal experience has shown little valuable user information on a UICC card from an iOS device, but network information can be observed. However, the UICC should be collected and included in the overall case file as evidence.

Collecting the Device Physically

Probably the most frequently asked question of software vendors, support staff, and training staff has to do with the non-invasive physical collection of an iOS device. The question is always centered around the collection of an iOS device version later than an iPhone 4S from those versed in the limitation, but from new examiners it is more along the lines of questioning why a piece of software that specifically states it supports the physical collection of iOS devices fails on anything above an iPhone 4S or iPad 1. This is not a limitation of the software or the technology, but a limitation imposed by Apple in an effort to patch vulnerabilities. Devices with an A5 or newer processor (as of today, an A12) will not support the vulnerabilities exposed by today’s forensic software. The iPad 2 was the first device to use the A5, with the iPhone 4S soon following and now the iPhone XS sporting the A12. The A4 and earlier processors can be exploited using the same method by all forensic software vendors that currently support a physical collection of an iOS device.

An iOS device can run in normal mode, DFU (Device Firmware Update), or Recovery mode. The non-invasive physical methods used by forensics tools use DFU or Recovery mode to obtain access to the device via USB. If the device is not running in DFU or Recovery mode, the device typically boots up in normal mode starting with the read-only bootROM as the first stage when powering on. This startup procedure in normal mode is called the “chain of trust.” In the chain of trust, the device boots and walks through a series of security checks using signatures for each level. Each level will then check the other level (for example, the LLB [Lower Level Bootloader] checks the iBoot, iBoot checks the kernel), and if at any time a signature does not match, the iOS device will stop the boot process.

When an examiner places a device into DFU or Recovery mode, the iOS device boot procedure changes to involve second-level bootloaders, iBSS and iBEC. These are stripped-down versions of iBoot that allow for the preparation of the device Restore Ramdisk, but in the case of a forensic collection, the iBSS bootstraps the iBEC to deliver a custom RAM disk into the volatile memory of the iOS device. The custom RAM disk allows access to the iOS device and the partitions (OS and UserData) that otherwise could not be accessed when the iOS device is in normal mode. The forensic software will take advantage of the newly granted access to the device’s file system and a non-invasive physical image of the device can be collected. Once the device is rebooted after the collection, the custom RAM disk is removed, and the only trace that something has occurred to the device would be the indication that it had been rebooted.

The HFS+ (Hierarchical File System Plus) file system contained within the physical image of the iOS device can then be examined within the forensic software. As outlined in Table 10-2, the custom RAM disk method is possibly with only a certain set of iOS devices. With the supported devices, Apple added a layer of data encryption for unallocated areas of the user partition. With this layer of encryption, the data can be collected, but the keybag used for the decryption of that area is unavailable. This occurred in device versions later than and including iOS 4.

TABLE 10-2 Devices Capable of a Physical Collection Using the Customized RAM Disk Option

All other iOS devices not supported using the bootROM or iBoot exploit and RAM disk function (such as iPhone 6+, 6, 5S, 7, 8, X, and newer versions of the X) can also have their internal file systems collected with exposure to protected files not available in a logical file system (HFS+ and iOS 10.3 APFS) collection. In this case, the device must be jailbroken using a userland exploit, which is completely software based, and access is available only to the user area without access to the boot process. This means that the entire partition, as in a bootROM or iBoot exploit, is not available for full extraction; only the internal file system can be extracted. When an iOS device is jailbroken, most forensic software will obtain the new jailbroken verbose file system using the standard logical collection methods, along with advanced protocols added in the jailbreak. This collection, because of the now-jailbroken device, will allow access to files and folders otherwise not available in a standard logical collection. These folders and files include Apple Mail, Safari, applications, the protected data store, the cache, and many other files not accessible by other means.

The most common solutions used for iOS devices used to be Pangu (http://en.pangu.io/) and TaiG (www.taig.com/en/). TaiG had offered an untethered solution for up to and including iOS 8.2, while Pangu supports up to and including iOS 9.3. However, as the file system versions advanced, more and more jailbreaks became available, with published exploits Meridian, Electra, and LiberiOS shown to be the most utilized and popular. If using a tethered jailbreak, the examiner must plug the iOS device into a computer every time it is booted so the iOS device can boot with the help of the jailbreak application. Most jailbreaking tools use a tethered solution, but in today’s jailbreaking world, semi-tethered and semi-untethered jailbreaks are available. The semi-tethered jailbreak operation is much like the tethered version described previously, but more stable, and it enables the device to again be jailbroken upon reboot with the jailbreaking tool. With the semi-untethered jailbreak, the device is not in the jailbroken stage upon reboot but can be re-jailbroken by the user of a side-loaded app or even a web site.

Jailbreaking a mobile device was ruled not illegal by the Library of Congress in 2012 (www.copyright.gov/fedreg/2012/2012-26308_PI.pdf) and extended to tablets (such as an iPad) a few months later. However, jailbreaking can void the warranty by Apple, so using third-party methods to jailbreak a device should be used only in situations where warranted.

An examiner who understands the methods used to obtain physical access to an iOS device, either using bootROM exploits, iBoot exploits, or userland, can positively impact later testimony and documentation, especially if the method is challenged.

Unlocking an iOS device and obtaining a raw file system using a tool such as GrayKey from Grayshift can produce the same type of file system as a jailbroken phone, but can also acquire a snapshot of the device memory as well. This information and artifacts are discussed in Chapter 13.

iTunes Collection

If performed correctly, an iTunes collection will yield much of the same information you would expect from a collection with forensic software. However, an iTunes collection backup will contain many files that are represented by a hash of the path of the actual file on the device. Although the collection process and the connection of the device to the computer are no different from what has already been discussed with other operating systems, the collected data’s format is much different from the others. The examination and analysis of this data are covered in Chapter 13.

To create a backup successfully using iTunes, the examiner should first download and install the most current version from Apple (www.apple.com/itunes/download/). After installing and launching the software, and after iTunes is running, the examiner should navigate to Edit | Preferences and click the Devices icon on the tool ribbon. On the Devices screen, the examiner should select the checkbox for Prevent iPods, iPhones, And iPads From Syncing Automatically. The iOS device can then be connected.

iTunes displays the connected device. On the device information screen, the examiner must clear the checkbox for Encrypt Backup. If this box is selected, the device has been set to encrypt the backup, and the examiner, when unchecking the box, will have to enter the password for the iTunes backup that the device owner used. If the password is not known, a backup can still be created, but the data that is produced will be encrypted. An examiner should still create a backup, even if the backup password is not known, in case the password is later available. Or the examiner could use software such as Elcomsoft Phone Password Breaker (EPPB) or Oxygen Forensic Detective to retrieve the password. While still connected, the examiner should right-click the connected device and select Backup. A backup will be created in the predefined default location depending on the operating system:

•  Mac   ~/Library/Application Support/MobileSync/Backup/

•  Windows Vista, Windows 7, Windows 8, and Windows 10   Users(username)AppDataRoamingApple ComputerMobileSyncBackup

The backup password and the PIN/Password for entry to the phone are two separate security features. This means they can be, and usually are, completely different passwords.

Note that many users are using the iCloud backup function for iOS devices versus the standard cable connection to a PC or Mac using iTunes. However, the data backed up using a cable and iTunes contains additional data not available in an iCloud backup. This information was covered in Chapter 4 and more information will be available in Chapter 13.

Archiving the Data

All data, including physical images, logical file systems, backups, pairing records, and UICC information, should be copied to an evidence drive before the analysis phase begins. The appropriate information should then be copied to a temporary location for the analysis phase of the investigation. The storage location should be a unique folder specific to the case and an internal folder specific to the device. Any additional evidence recovered as part of the analysis should also be stored permanently in this location after the case is completed.

Android OS Connections and Collections

With more than 18,000 different types of Android devices available to users around the world, it is no wonder that connecting and collecting from these devices can be difficult at times. An Android logical collection is much different from an iOS logical collection because the internal logical file system of an Android is not available by default. Settings on the device must be enabled for proper communication, and these can vary depending upon the device. Not only does it matter what type of Android device is being examined, but the version of the operating system will also determine whether a connection and collection can occur. Other considerations for Android collections include whether the device is powered on or off, locked or unlocked, encrypted or not, and also whether or not security is enabled. A locked device with security enabled can prevent the examiner from turning on settings needed to communicate with an Android device. All of these facts must be considered before the examiner even connects the device to be collected.

The Android device can contain a UICC along with memory cards, and the processing order described in the “UICC” and “Memory Card” sections earlier in the chapter should be followed. These sections cover the connection of the mobile device.

An Android device should be collected with the memory card still inserted in the device to collect and extract the media and file data that are located on the removable media. If the memory card is removed, actual files that are on the external media will not be mapped to data that is contained on the mobile device’s internal database.

Connecting to the Device

The Android Debug Bridge (ADB) is used to communicate with an Android device. The ADB.exe command line tool is part of the Android Standard Development Kit and is used for testing and development of Android apps and applications. This tool offers a computer a way to communicate with a connected Android device. It comprises the client, a server, and a daemon. The client is the action or job initiated by the ADB command. The server is the management portion that is running on the computer that manages the communication between the client and the ADB daemon that is running on the Android device. The ADB daemon is a background process that is running on the device conducting the command and control as given by the client. ADB must be used for all communication to and from an Android device, whether it is a logical or particular non-invasive physical collection. The Android device that is to be collected must have ADB enabled, either manually by the examiner or programmatically by the software. Once ADB is enabled, the proper ADB driver must also be installed and functioning on the examination computer for proper communication.

The only driver that would need to be installed successfully to collect an Android device is the ADB driver; all others are not significant.

Whether the examiner will need to set the Android manually into ADB will depend upon the operating system. Outlined in Table 10-3 are the various ways of setting an Android device into ADB, depending upon the operating system version. All ADB menus are located in the Developer options menu.

TABLE 10-3 Ways to Locate the ADB Functions Within Android Devices (http://developer.android.com/tools/help/adb.html)

Up until Android 4.2, Developer Options was visible in the Settings menu. Android 4.2 and later versions have hidden developer options, and to see the menu, the examiner must go to About Phone in Settings and tap Build Number seven times. Developer Options will then be visible in the Settings menu.

In addition, when conducting forensic collections, you need to set the device to allow unknown sources in the Security settings on the Settings menu. Allowing unknown sources will enable the forensic software to “sideload” a special package file, called an Android application package (APK), onto the device. Sideloading an app means installing APK files that are not directly from the Google Play store. If the device will not allow unknown sources, the forensic software will not be able to install the forensic package to collect logical data.

Another setting—more of a security feature—is the acceptance of an RSA key when the device is connected to a computer (for devices running Android 4.2.2 and later). This must be accepted on the device, not the computer to which the device is connected. This RSA key acceptance is similar to selecting to trust the computer with an iOS device. By accepting the RSA key on the device, the examiner is stating that the connected device is safe to connect with the computer.

Once all settings have been configured, the device can be connected to the mobile forensic software and the collection can begin. Typically, the display and subsequent manual acceptance of RSA certificate will vary depending on the software that is used. For example, with Oxygen Forensic Detective, the RSA certificate screen will show upon communication with the device, after connection via USB cable.

Device State Considerations

If an Android device is unlocked and powered on, unlocked and powered off, or the security is enabled and the password is known, the connection and collection will be typical and straightforward. There are instances, however, when an unlocked Android device cannot be recognized by the software or even the forensic computer or hardware. In such instances, it is important that the examiner determine whether the device’s USB port is intended for charging only or whether data can actually be transferred to and from the device via the port.

Here’s an easy way to determine this: After you plug the device into a computer, if a device can transfer data, the device will be shown as a portable device within the computer’s device tree, and a menu will be displayed on the mobile device screen with at least an option to turn on USB mode for the device. USB mode will allow the device to move files on and off the media portion. If the device is capable of doing this, it can be collected using ADB.

Android devices are predominantly collected using a USB cable connected to the computer running the forensic solution. In some situations, however, the use of alternative connections may be warranted.

If the device is locked by a password and the password is not known, the device must be physically collected, unlocked using software such as Cellebrite or Oxygen Forensic Detective, or JTAG/ISP/chip-off used to access the data. As mentioned earlier, in order for data transfer to occur using USB, ADB must be enabled. Android devices by default do not have ADB enabled, but an examiner should always plug the device into the forensic solution, even if it’s locked, to see if ADB has been turned on. Users who frequently sideload applications or hack Android devices will have ADB enabled, and when it is available, the device will still be accessible if locked. However, if the device is locked and ADB is not enabled, logical access will not be available and the examiner will be limited to non-invasive physical or invasive physical collections.

Collecting the Device Logically

Once ADB is enabled, a logical collection of an Android device can occur. Forensic software vendors all use a customized APK file to collect this valuable user data. The examiner needs to understand firmly the method and installation of a program onto an Android device to collect data. Because the forensic software is writing to the evidence and altering the internal file system, a challenge could be raised that the evidence is no longer valid. This, of course, is not true, but without an understanding of the forensic tool and how the process works, an examiner may have a difficult time dealing with such a challenge.

An APK is a compressed file containing uncompiled code. This package contains files and folders that, when compiled on the Android device upon installation, create a port for which the forensic software can communicate and collect the user data from the mobile device. Each software vendor’s APK is different: some extract user packages and Wi-Fi settings, while others do not; some remain installed on the device after running, while others do not. What is important, other than what type of data will be extracted, is how the APK is delivered, where it is delivered, and what happens to it once it has been installed and run. Typically, the APK is pushed onto the Android device and placed into the system/tmp folder using ADB. The APK is then installed and compiled onto the device and an instance is initiated, also via ADB.

Most forensic software solutions instances are not visible on the device during the collection, with the exception of Oxygen Forensic Detective and Analyst, Compelson MOBILedit, and Cellebrite. These programs display a splash screen on the device while the app is running, collecting data.

While running, the app will be sending data to the forensic software based upon queries to the supported databases. This is an important concept for the examiner to understand, because a logical extraction of an Android device will not include the actual database files where the queries were directed. In simpler terms, if the SMS messages are collected from an Android device, the mmssms.db file is not extracted during a logical collection—only the data from the SQLite database table is extracted. Because the Android protects the data area of the file system, access to these database files is not available using SQL commands and is available only if the FLAG to include in backup is not FALSE for an ADB backup, or with a physical collection and elevated privileges, commonly referred to as root privileges. If database files, media files, or other files are extracted in a logical collection agent extraction, they will be extracted from the internal and/or external storage area using the Media Transfer Protocol (MTP).

Once the collection has completed, the forensic software will issue another command to the installed application to uninstall the software. The software is then removed from the target device and the system/tmp file will be cleaned and purged of any leftover data. If the examiner is unsure whether the forensic software removed the installed APK, he or she can navigate to the applications area on the Android device. If an icon for the forensic software APK is located, the app was not uninstalled and should be uninstalled manually.

Collecting the Device Physically

Collecting an Android device using non-invasive techniques requires root access to the device. Typically, if an Android device is supported in a forensic software solution for physical collection using a USB connection, two methods can be used, either automated rooting or custom ROM installation.

Different root levels are available on a device. A shell root is the most desirable when you’re conducting mobile forensics because this can obtain root access to the device. Upon reboot, after the extraction is complete, the device will be back in the unrooted state. With a permanent root, on the other hand, a reboot will not remove the root access. Some third-party rooting tools can also “unroot” a rooted tool, and if available this should be attempted after the collection has completed. Leaving evidence in a rooted state could introduce malware or other issues that would not be possible with a secured device.

Automated rooting procedures require an unlocked phone with ADB available and enabled; to perform the rooting process manually, ADB also must be enabled and available. Forensic tools such as Oxygen Forensic Detective, UFED Touch 2/4PC, Magnet AXIOM, and XRY have built-in functions that will attempt to root the device when conducting a physical collection. If a tool is unable to root a device and no other methods for physical access are available, however, some third-party applications can be used: dr.fone from Wondershare supports devices from 2x to 5.1; KingoRoot for Android supports devices up to 4.2.2 and includes unroot capabilities; and SRSRoot supports Android versions up to 4.2 and has an unroot option, while One Click Root supports devices up to 6x for root as well as unroot. Other available tools also allow for the rooting of devices up to 7x, but they come with caveats of unlocking the bootloader (OEM unlock), which voids the warranty of the device.

If the device is locked, supported for physical collection, and ADB is disabled, the forensic software will connect to the device typically by using fastboot, recovery, emergency download (EDL) mode, or download mode. These modes are used to install customized ROM that enables ADB and grants access to the device with root access. Once the collection is completed, the original ROM is returned.

It is extremely important that the specific ROM matches that of the evidence to be collected when using a forensic solution with this type of physical method. Because of slight differences in the ROM for any Android device, using another device’s ROM can cause disastrous results. This is primarily why this method fits in the invasive physical collection method category.

JTAG/ISP can also be used and has become extremely popular for Android collections. There are many different boxes and cables used in the mobile forensic community, but as with most everything else, no single mobile forensics solution supports every mobile device encountered. JTAG/ISP software typically displays the TAPs for the model to be collected in an image within the application. Following the image, the connection to the JTAG hardware can be made either by soldering to the correct port and then matching to the referenced port on the JTAG hardware, or connection can be made with other solutions such as Molex or jigs. When the device is connected and the JTAG software has been configured, a binary image is created and can then be imported into mobile forensic solutions such as Cellebrite Physical Analyzer, Oxygen Forensic Detective, and MSAB XACT.

Alternative Collection Methods

As with other device types, Android mobile devices can be collected using other, more raw, collection methods. If a physical collection is not available, these alternative methods can be used to gather information from an Android device over and above what a standard logical collection can gather, including file system and app data. These methods do not require having device root.

ADB Backup   This function became available in Android 4.0 and enables a backup of individual apps or the entire app catalog along with the application data, cache, and internal storage. This function can be initiated using ADB.exe, available in the Android SDK in the /platform-tools/ folder. To use ADB Backup, the device must be unlocked and USB debugging must be enabled. Once an app or apps are downloaded using ADB Backup, the created file will be compressed and encrypted. To uncompress and decrypt the created file, the examiner runs the file through Android Backup Extractor (http://sourceforge.net/projects/adbextractor/), which will create a tarball file that can be examined using mobile forensic software capable of importing and viewing these types of files. Use of ADB Backup involves using a command line instruction and device interaction once ADB Backup is initiated on the mobile device.

ADB Backup does not allow for the backup of Digital Rights Management (DRM) protected applications.

The parameters and flags needed to create an ADB Backup, along with a breakdown of each parameter, are shown next:

adb backup [-f <file>] [-apk|-noapk] [-shared|-noshared] [-all] [-system|-nosystem] [<packages…>]

•  [-f <file>]   Specifies the location where the backup will be stored.

•  [-apk|-noapk]   Specifies whether or not the app APK will be backed up. Backing up the APK could allow for later scanning for malicious software. The -noapk flag is set by default.

•  [-shared|-noshared]   Specifies whether or not shared memory areas on the internal and external storage media will be backed up. The -noshared flag is set by default.

•  [-all]   Specifies all applications on the device. When conducting a forensic backup of the device, use the -all flag.

•  [-system|-nosystem]   Specifies whether or not ADB Backup includes system applications in the backup. The -nosystem flag is set by default.

•  [<packages…>]   Specifies the app that will be backed up. If this is set, only the specified app will be included (that is, com.android.provider.telephony).

Here are the command parameters and flags for ADB Backup to collect all applications and internal/external media to a file called backup without system files at C:Evidence:

adb backup -f C:Evidenceackup.ab -all -nosystem -shared

If the examiner wants to extract all apps and memory contents of internal and external areas and their APKs to scan for malicious applications, the command would look similar to this:

adb backup -f C:Evidenceackup.ab -apk -all -system -shared

When the command is complete, the examiner will be prompted with the screen displayed in Figure 10-9. Do not enter a password to encrypt the backup, and tap Back Up My Data. The duration of the process will depend upon the amount of data that is being backed up. Once the process completes, the examiner will be notified on the Android screen. The backup can then be extracted using the Android Backup Extractor and examined in the software solution of choice.

FIGURE 10-9 Screen activated on a connected Android device when running the ADB backup command

Helium   Helium, formally known as Carbon, is an app-based solution that uses the front end of ADB Backup as well. To use Helium on a non-rooted device, install the application on the target device and on the desktop. An examiner can create a backup of select applications or individual applications to the PC; by default, the backup is saved to the SD card, but it can be added to Dropbox, Google Drive, and so on. As with ADB, some applications are not available for backup. What is quite interesting with this solution developed by Koushik “Koush” Dutta is the fact that the user simply connects the device and then untethers the device after connection; all extraction occurs over Wi-Fi (https://www.clockworkmod.com/).

Windows Explorer

Android devices are recognized as portable devices by both Mac and Windows systems. If a forensic solution is unable to extract the data from the internal or external memory areas, the examiner can copy the information from the mobile device to the location where the evidence is to be saved. Because dates will probably be altered using this method, it should be used only if there are no other alternatives.

Archiving the Data

All data, including physical images, logical file systems, backups, and UICC information, should be copied to an evidence drive before the analysis phase. The information that is needed for analysis should be copied to a temporary location. The storage location should have a unique folder specific to the case and an internal folder specific to the device. Any additional evidence recovered as part of the analysis should also be stored permanently in this location once the case is completed.

Chapter Summary

The collection of mobile device data is often the easiest part of mobile forensics, but only if device state, drivers, and workflow are considered appropriately. Thoroughly documenting the device, UICC, and memory cards is the first step, but the examiner must also determine what evidence should be processed first, depending on whether the device is powered on or off.

Logical examinations are just as important as physical collections, and both types of collections should always be attempted. Obtaining a logical collection first can usually help the examiner obtain valuable data in case a physical collection is not supported, does not successfully complete, or disables the mobile device. The device type (whether a feature phone, an Android, a BlackBerry, an iOS, or a Windows Phone) can also determine the order of processing and workflow.

Often, mobile device forensic software will use functions and technology to conduct logical collections that have been formulated from the device manufacturer’s own backup tools. Because of this, an examiner can use the manufacturer’s software to create a backup as an alternative. It is important to understand, however, that some settings might need to be adjusted to maintain a valid backup. Collection methods may not work or may be unsuccessful, but the initial preparation of the device prior to collection of the digital data should be the same, no matter what device is to be examined and what software is used.

By understanding the way forensic software communicates with a mobile device to obtain data, the examiner can be prepared to face many challenges. The expert examiner should know how to determine that an APK file is installed, that the Android device data is placed into a temporary area and later removed, that a custom RAM disk is created in the iOS volatile memory and later removed upon restart, and that obtaining root to an Android device changes security privileges and not the underlying user data.