As a mobile phone examiner, law enforcement trainer and business owner, I’ve seen many changes in the industry over the short life of so-called mobile phone forensics. From documenting cellular data manually to full-fledged acquisitions of all data once thought impossible, a lot has come and gone. Further, the tools developed to acquire this data have grown by leaps and bounds—but to whose benefit? Surely not the examiner’s. To make this point, let’s first take a look at computer forensics.
Mechanics of Computing
To capably harvest digital evidence artifacts for criminal investigations, computer forensic training is an absolute requirement. Training ensures examiners not only understand the complex layout of data, the way the data is stored and how to recover it, but also how to articulate findings in court when called upon to do so.
Traditionally computer forensics training has begun by describing the breakdown of a computer’s hardware, then the internal systems, including the hard drive or storage device’s tracks, cylinders and sectors. Training then moved on to how and what can be stored on a device, operating systems, data layout, file headers/footers and different types of files. I recall participating in exercises in which I located information using a low-level disk editor and thinking to myself, “Are these instructors sadistic or what!”
It was only later that I realized how much I’d benefited from such intensive basic training in file recovery. My own training progressed on to the validation of the hardware and then a review of software utilized to perform my examinations. Only after I understood the physical characteristics of a device, its structures and how to manually recover artifacts, was I introduced to the automated tools used today in the computer forensics world. I understood then profoundly that a foundation in the physical and manual aspects of computing is essential for a firm grasp of automated functions. This knowledge not only benefits me in the lab, but also in the courtroom.
Remember : In the computer forensics world the automated tools support examination; they don’t perform it. This holds true for mobile phone forensics, as well.
Mobile Phones vs. Computers
Let’s first start with a few comparisons and differences between computer hard drives and mobile phones. A computer’s hard drive and a cellular phone both contain non-volatile data, files and user data. A computer can be protected from any writes by software using a hardware/software write-blocking device; a mobile phone cannot. The biggest difference is that computer forensics employs a standard examination process, but there’s currently no standard process for the examination of a mobile phone.
The reason: Today’s mobile phone examiners want to believe that mobile phones are quite different from computer hard drives, and as a result, in the United States at least, examiners aren’t accountable to a process—or even required to understand the device’s contents. This “push-button forensics” is the Achilles heel of the mobile forensics community. The manner in which most examinations are conducted is comparable to processing a Windows computer in a Windows environment—without the use of a write-protection device—and then pressing a big button that says “Get Evidence.” The forensics of mobile phones is about to change.
Tool Validation
First, what makes a tool “forensic”? Do we believe that a hardware write-blocking device works because the manufacturer says so? Of course not. We validate these hardware devices in computer forensics by attempting to write to a piece of media (never evidence) while it’s properly installed. If a write to the media isn’t successful, we can reasonably say the hardware write-blocking device worked properly.
Because we can’t place a hardware or software tool between our mobile device and our computer, we must devise a way to determine that “forensic” phone software is not writing to the device being processed. We do this by conducting our own validation process.
Validation can be as simple as attempting to write to a phone (never evidence) with known data when the software is set to “read-only.” For example, using BitPim, we might select “Block writing anything to the phone” on the settings screen. We could then attempt to add data to the phone. BitPim should indicate the phone is in read-only mode.
Another method, discussed in further detail below, involves creating a baseline read of a device, then utilizing a third-party hashing utility to extract known data, reacquire it with the initial tool and re-hash it with the third-party tool. The pre-hash values should match the post-hash values, thereby successfully validating the tool. Conducting these preliminary steps is vital, and the examiner must always remember that to process a device forensically requires the ability to duplicate the process and procedure with the same results.
Isolation of the Device
The isolation of a mobile phone can be compared to removing a computer from an internal or external network subsystem in the beginning of the forensic process. We isolate the mobile device to inhibit the addition and/or deletion of data over the air (OTA), either maliciously—not while conducting an examination—or when a device is in our possession. Any addition of data or deletion of data could make or break an examination.
Isolation can be done several different ways, but is ultimately determined by the type of device the examiner is processing. For example, if the device is a global system for mobile communications (GSM) device, the examiner should create a forensic SIM (subscriber identity module) cloned card to isolate the device from the cellular network. If the device is a CDMA (code division multiple access) device, simply placing the phone offline will work. These are only a couple of methods, but the isolation of the device is the first step to a successful examination.
Extraction & Validation
The examiner should then begin to extract data from the device, preferably the device’s file system, using a tool that will serve as the baseline we discussed earlier. Once the data is extracted, utilize a third-party tool to hash the evidence and then archive the extracted data file. Additional extraction tools can then be used to recover the required user data. Once all the requested data is extracted and the examination of the device is complete, the examiner will then use the baseline tool to duplicate the initial extraction. The data will be hashed once again to create a post-hash. The pre-hash can then be compared to the post-hash to validate that the evidence remained consistent during the examination when using multiple tools.
Completion & Reporting
All information extracted must be documented. Extracted information should include the location of artifacts, the location of user files (e.g., contacts, text messages, call history), the verification of dates/times and the location of anomalies, if any.
Noting the location of any anomalies is extremely important to deter the “Trojan horse” defense and also to identify hidden files. An example of the location of a malicious file would be to locate the applet that monitors the phone user’s activity and then sends this information to another device without the user knowing. Locating these and other added files will assist the examiner in thwarting any attempts in court to suggest that the files were added without the knowledge of the user.
Conclusion
Currently, a computer forensics examiner’s process is what’s scrutinized by the court, not the evidence recovered. The scrutiny of the mobile phone examiner’s process is not far behind. A thorough process in the examination of mobile phones ensures that the integrity of the evidence is maintained. Moreover, it ensures that the integrity of the examiner’s process is solid.