Seeking the Truth from Mobile Evidence

Simple Security Values

Before the advent of smartphones, the operating system on some phones would simply store the actual user value within the operating system. This means that if the user placed a handset lock code of 1325 on a simple bar or flip phone, that value would be stored in the basic encoding for the phone, usually in ASCII or Unicode. It could easily be located by employing encoding search techniques using popular tools such as Cellebrite's Physical Analyzer. Also, many of the devices will contain the user PIN and user security code just a few offsets from one another within the file system. On some phones, the security code is used to bypass the PIN if it is unknown. In a past criminal investigation several years ago, a homicide victim decided to change his 4-digit PIN and 6-digit (default) security codes. The phone was a Motorola iDEN. At the time of this incident, automatic tools were limited, and large vendors such as Cellebrite did support the phone for physical extraction, but the parsing on SMS and other user areas was limited. Logical settings, however, would parse the required fields for the case. A test phone of the same model was used to place a different (known) value for the PIN and 6-digit security code. Using the Find -- Code tab in Physical Analyzer, the values on the test phone were easily located. They were an offset apart and had unique characters before and after these security codes. A RegEX expression was then used to locate the values on the victim's phone, unlock the GUI, and allow a logical parsing of several SMS messages related to his death. The point of explaining this case is to convey that these values were on the phone, in their original state. This was typically how phones stored the security imposed by the user. There are many phones still sold today that work this way. These generally fall into the pay-as-you-go, simple "burner-phone" categories. They lack sophisticated operating systems and have limited features. Many are supported by several commercial forensic tools, while others may lock down their USB data port.

Fig. 19.1 is a file system from an LG VX8100 that was acquired from Bitpim. Within the nvm_security folder we can see the default 6-digit security value of 000000. The user enabled security PIN is below this, toward the end of offset 90 as 1397 (bottom image in Fig. 19.1).

Smartphones

In most cases when the user employs a specific type of security on a smartphone, the actual value is converted out of this simple format shown in Fig. 19.1. Depending on which type of security the user chooses, it runs a check against a specific hash value of that security when the user wants to enter the GUI. It is important that examiners understand that when it comes to the gesture and password locks, we are not addressing the entire file system encryption, but simply the security (value) encryption that is performed each time a user enters the phone. This is not to say that there is no hardware-based encryption that may be going on with newer chip sets. Many readers are probably aware of issues with newer iPhones. This also applies to newer devices using the UFS chip. This will become even more problematic, and new techniques will hopefully address exploits for these issues.

This chapter will discuss the security aspect of both the password lock and the pattern lock employed on Androids. It will conclude with focusing on manually creating a hash value based on a binary file created from the gesture pattern.

The Password Lock

When a user sets up a password lock, he/she can employ his/her own choice of data that contain special characters, numbers, letters, or any combination of the same. If the user sets up a password lock, it is given a hash that uses a combination of SHA-1 and MD5. The value is also salted. Salt or salting is the process of adding additional security, as it randomizes the hash. This can prevent dictionaries and rainbow tables from breaking the hash values that are always the same, such as what readers will see when we discuss the gesture value. The Android password can be complex, with 4–16 characters in length. There are 94 possible characters per space, with users having the choice of lower/uppercase letters, digits, and punctuation. The good news (if it can be called that) is that there are no spaces allowed. If we manually locate the value within the file password.key (Data/System/) location, the password hash has a 72-byte hexadecimal value. From left to right, it is comprised of the first 40 bytes showing the SHA-1 hash. This is immediately followed by the remaining 32 bytes of the MD5 hash. Because the value is salted, the salt value must be recovered first. Salt is represented in hexadecimal as a random 64-bit integer. Salt is stored in settings.db (SQLite database file), which is named lockscreen.password_salt. This will be within the (rebuilt) file system shown here:

data/data/com.android.providers.settings/databases/settings.db

If examiners have pulled a binary that has not been rebuilt and decoded with tools such as Physical Analyzer, it is a little bit more time-consuming to locate the password.key and the salt value. If examiners conduct an ASCII search for "lockscreen.password_salt," they will obtain at least one hit that places them in general the area they need to look for the entire salt value. The salt is a string of the hexadecimal representation of a random 64-bitinteger. The value along with the MD5 or SHA-1 from the password key location can then be used to brute force attack the values with Hashcat. Here are some steps to help examiners locate the salt when they have a physical file from a JTAG, ISP, or chip-off examination.

About the author:

John Bair is currently employed as a detective with the Tacoma Police Department. He has been commissioned as a law enforcement officer since May 1989. During his assignment in the homicide unit, he began specializing in Cell Phone Forensics.

In 2006 John created the current forensic lab that focuses on mobile evidence related to violent crimes. His case experience shortly thereafter gained the attention of Mobile Forensics Incorporated (MFI) where he was hired and spent several years serving as a contract instructor. MFI soon merged with AccessData to become the only training vendor for their mobile forensics core. This relationship fostered direct contact with engineers who assist in criminal cases which need anomalies and exploits addressed within their forensics products.

July 2013 he was hired as a contract instructor by Fox Valley Technical College to assist in training for the Department Of Justice - Amber Alert Program. His expertize with mobile forensics is being utilized to structure a digital evidence module for investigators responding to scenes where children had been abducted. The program promotes how to prevent mobile evidence contamination and how to triage live devices under exigent circumstances.

Within in Pierce County, he began a mobile forensics training program for Superior Court Prosecutors and Judicial Officers which is currently in its fourth year. The program stresses the technical origins of the warrant language, what to check for, validation of evidence and how to present this dynamic content in court.

In December 2013, Detective Bair gave a presentation to the University Of Washington Tacoma (UWT) Institute of Technology which provided an outline to merge digital solutions between the Tacoma Police Department and UWT. The relationship will focus on building a digital forensic lab that will be modeled after the Marshall University Forensic Science Center in West Virginia. The lab proposal also includes the ability to conduct advanced destructive forensics which will be a one of kind facility on the west coast. Based upon the proposal to create a combined lab, John created a mobile forensic course and began part-time lecturing at UWT in April 2014. The course covers legal concepts, logical, physical searching methods and manual “carving”. John authored his own student and lab manuals for these courses. In March 2015, John started an intern program within the lab at the Tacoma Police which involved students from this program. In late August 2015, one of the interns was able to use advanced python writing to assist with parsing over 3300 deleted messages in a homicide that took place earlier that year.

John Bair has instructed at various federal labs within the United States (Secret Service, ICE). He has presented on mobile evidence as a guest speaker at Paraben's Innovative Conference, Washington State Association of Prosecuting Attorney’s (WAPA) Summit, and the Computer Technology Investigations Network Digital Forensics Conference. Recently he spoke at the 16th Annual Conference on Information Technology Education / 4th Annual Research in IT Conference in Chicago Illinois. These conferences are sponsored by the ACM Special Interest Group for Information Technology Education (SIGITE). John and two other professors from the University Of Washington – Tacoma (UWT) recently co-authored a paper regarding the current Mobile Forensic Program.

John has over 42 certifications related to digital evidence training. The following reflect the most significant related to mobile forensics: Mobile Forensics Certified Examiner (MFCE), Cellebrite Certified Mobile Examiner (CCME), Cellebrite Certified Physical Analyst (CCPA), Cellebrite Certified Logical Operator (CCLO), AccessData Certified Examiner (ACE), Cellebrite Mobile Forensics Fundamentals (CMFF), AccessData Mobile Examiner (AME), and Cellebrite Certified Task Instructor.

John is also the co-owner of the forensics expert services firm, NAND Forensics (www.nandforensics.com).

Reprinted with permission from Elsevier/Academic Press, Copyright © 2018