Recent information has been brought to my attention that requires me to password protect portions of my Blog. I apologize for the inconvience this may cause people who want to read the threads. Please contact me with your agency or company email and after a quick check, I will provide you with the password to have access to this Blog. cop.geek@gmail.com
Category: Uncategorized
In the field of mobile-device forensics, the practices of “chip-off” and “JTAG” analysis have become topics of growing interest among the community. As mobile devices continue to bring new challenges to the examiner, these two disciplines warrant close attention, as they both offer examiners avenues for deeper data access, the ability to bypass lock codes, and a way to recover data from damaged devices…………………………………..to read the full article, please follow the link below:
http://evidencemagazine.com/v10n3.htm
Happy Reading!
Thanks to Bill Teel of Teel Technologies for the assistance in writing and editing the article.
Bob
Sorry I have not been able to post items these past few months, work case loads; summer holidays and R&D has kept me away from my Blog. What has brought me back sooner than later is an update to my previous Blog about Cellebrite’s P.A.’s software…………
Well, I was impressed with the Cellebrite P.A. 1.9x in my previous testing, I am even more impressed by the newest edition of Cellebrite’s Physical Analyzer version 2.2. The crew at Cellebrite have overcome annoying barriers that we as cell phone forensic examiners have been challenged with this past year. One of the main problems for us was the ability to bypass the user lock on iPhone cell phone (resolved with version 1.9x) and then the encryption we faced even when we were able to obtain a physical dump. This is no longer the case; Cellebrite has overcome both these obstacles with more to come.
In my previous posting (Cellebrite Physical Analyzer Beta Testing June 2011) I examined my personal iPhone 4 CDMA (Model: MC605C) running iOS 4.3.3. At that time, I was able to get a file system and physical acquisition from the locked phone. I was not able to view much from the physical acquisition as the data was encrypted but the file system dump was successful. A great feat considering this data was not obtainable a few weeks due to the user lock code. Now it is possible to recover the data from the physical acquisition in version 2.2 as they have been able to decrypt this data with new processes.
In this testing, I am using the same iPhone (iOS 4.3.3) and will test a new feature of version 2.2, obtaining the user passcode and displaying it. The steps remain the same, enter into Recovery and DFU modes to prepare the phone for analysis only this time you have a new option to run with, “Device Password Recovery” as seen below:
P.A. 2.2 Options
The software ran for about 5 minutes and then it came up with the passcode (white’d out in this case):
Passcode Recovered
You now have the option to continue and get either a file system or physical data dump from the phone, or shut it down and access the phone with the newly discovered user passcode. With this passcode, you now have the option to acquire the iPhone again using other forensics tools, an excellent capability when you want to validate your Cellebrite dumps and/or just use other tools like XRY Complete; MPE+; Oxygen Suite; and Lantern that have options for acquiring user data from iPhones.
Next, I wanted to see if the newest iOS version available to iPhone users would be a challenge for P.A. 2.2. I ran the iTunes software and upgraded the newest iOS on the iPhone to 4.3.5. This was no challenge at all for P.A. 2.2, the user passcode recovery was no issue and it took no more time than it did for iOS 4.3.3. I then ran the new Physical Extraction and Decryption which took about 40 minutes to complete on this 32 GB iPhone. I open the acquisition and was amazed at the number of items it was able to decrypt for us, it was pretty much what we saw in my June 2011 File System dump but more, the added data is obviously deleted items obtained from the physical acquisition.
Physical Acquisition
To see the difference, I then ran the File System dump (I noted a disclaimer indicating that some emails are not obtainable) on the iPhone and compared the finding from the two acquisitions:
File Sysytem Acquisition
I did note that the Physical acquisition recovered 704 emails and the File System acquisition recovered 446. One main item that file system dump cannot get and only physical with decryption is the emails.The Mail folder is locked for file system dump and even has its own encryption keys. Only physical with decryption can get that. Other artefact differences included images P-16790 FS-11732; audio P-1847 FS-1845; and text 324 FS-244.
As with most of my important acquisitions, I like to validate my finding with a second or third tool, in this case I used another software kit and did a file system dump with their software. There are some notable differences that one can see and supports the need for examiners to run multiple tools against your cell phones exhibits. In some cases (file system comparison) Cellebrite recovered more items; in some cases the other software recovered more; and in some cases they both recovered the same amount.
In the end, Cellebrite P.A. 2.2 is a resourceful option for forensic examiners faced with iPhone exhibits that require the bypassing of the user passcode and/or for physical acquisition of the user data to recover deleted items. The interface is very easy to use; the instructions are very simple to follow; the data dump and reporting of this acquired data is visually easy on the eye; and the ability to search for artefacts not recovered by the physical acquisition process (yup, there is more evidence in there, you just have to work the P.A. search features to find them) is simple.
During the testing of this software, I spoke with the team at Cellebrite and they are working feverously on the newest challenge facing cell phone examiners these days, the Android OS cell phones. They are having success with some Andoid phones now and hope to release a new update in the near future that will allow us to bypass the user code and obtain physical acquisitions from these devices.
Another challenge for cell phone examiners is the user lock code found on Blackberry’s; well, Cellebrite is also working on a solution to decode the data dumps from the chipoff process of the NAND flash memory from these devices as well. They have been able to decode the data dumps from some versions of the Balckberry chipoff dumps and are looking for anyone that has chipoff dumps to help them with developing this part of their tool. If you can help, send an email to Ron Serber serberron@gmail.com.
Coming up in future postings:
JTAG vs. cell phones
Chipoff progress
“Wait until you get it right, then release it” This is exactly what Cellebrite is doing, getting it right!
For the past two weeks, I have had the privilege to Beta test the upcoming version of the Physical Analyzer that supports the Physical and File System acquisitions of most any iPad and iPhone iOS and models. I have acquired everything from the iPhone 2G right up to my newer iPhone 4 with the newest iOS release of 4.3.3. Both Physical and File System acquisitions. BEST OF ALL, most of them were passcode locked by the users and myself. The software unlocked all the phones to recover the data.
Even better, the user data from the file system dumps were all decrypted and we are able to read: SMS Text; MMS; Calendar; Application Usage; Call Logs; Chats; Contacts; Emails; Installed Applications; locations; Notes; User Account info; User Dictionary; Web Bookmarks; Web History; Wireless Networks; Images; Videos; Audio; and Text items. This includes my newer iPhone 4.3.3 that was tested.
Some items that I like about the new P.A. software includes:
- the walk though screens are very easy to follow, fool-proof I would say!
- no jailbreak is required
- you never power the iPhone on to the user interface, the process involves Recovery and DFU modes only
- the decoding data carving is outstanding
- you can get a physical dump, work on it while you are getting a second file system dump
- runs on most Windows OS’s, I am running Windows 7 64 Bit
- the whole process is clicking on an icon, wait for instructions, when the iPhone is ready to proceed, the screen changes and walks you through it
- it is a free upgrade to existing P.A. users with up to date licensing (release is soon)
- supports phones that are not even supported by the jailbreak process (example: iPhone 3G 4.2.1 MC)
- iTunes is not an issue; specific version or uninstalling is not a concern
Issues that I have found so far that are being worked on by Cellebrite:
- no support for the iTouch yet
- some issues with viewing some image formats
- some issues with certain USB ports
In the past few days I have acquired both Physical and Filesystem dumps from the following phones:
iPhone 3Gs with 4.2.1, no password active
iPhone 4, password protected, 4.3.3, 8J2, MC605C
iPhone 3G password protected, 4.2.1 8C148, 931.71.16, A1241
iPhone 3G, password protected, 3.1.2 7C146, 636.66, A1241
iPad 1 with 4.3.3 (8J3) 16GB Model MC349C
iPhone 3Gs iBoot 889.24, password protected
The process is fast and easy. A 16 GB device took about 20 minutes to get a physical dump.
I am now doing some validation with one of the dumps I got from the iPhone 3GS 4.2.1 to see if the physical dump acquired and recovered the same amount of pictures that another tool obtained. I am in the process of validating the iPhone 4 4.3.3 PW locked phone as well to see if the P.A. obtained and decrypted all the important user data.
Too many projects on the table, need to focus on one and get r’ done! More to follow……must fly to Myrtle Beach for Techo and MFW, network, network, network!
Posted with permission of R. S. /Cellebrite.
iPhone 3G 8GB – Memory size problem
UPDATE Feb. 12, 2012
While I was at the DOD Cybercrime conference in Atlanta this past month, I atteneded a presentation by Drew Fahey (Vice President, Product Development, BlackBag Technologies Incorporated) on iOS Device: Seizure and Analysis. During this presentation, Drew confirmed my findings that the NAND flash memory is manufatured larger than the actual size indicated by the chip specs. He explains that this is to help offset the bad pages that are present during the manufacturing process of the chip. We have also confimed this a number of times in the Chipoff Training when we do the RAW data dumps of the NAND chips, the dumps are of various sizes larger than the chip size specs indicate. So keep in mind, the forensic tools are doing a physical acquisition, but are they getting it all…..NO! One un-named manufacturer of mobile phone forensic tools expliained to me that they can only access the defined partition of the NAND flash and that only the chipoff process will get the full physical dump. Are we missing evidence?????????? Something to keep in mind!
*****This is an update to the original post as the way I wrote it read like I was making assumptions when they were actually observations. My bad!*****
I have a case where the suspect has destroyed his cell phone during his arrest. The phone would not function at all and is in small pieces. I located the 48 PIN TSOP NAND chip and found that it was intact. I recovered the chip by desoldering it and cleaning the pins for data reading with a programmer.
I placed the chip in the reader and tried to read it as an 8GB chip as the iPhone indicated that it was an 8GB model. The programmer kept erroring out and when it did a read, it was only a partial read. One read would get 1.6 GB, then one would get 5.3 GB, the one would get another random amount, and so on, all of them had error alarms going off during the process.
This led me to try out other programmers, specifically, one that allows me to manually configure the size of the reads from the NAND chips. This is when I actually read the chip number off the chip itself. The number for this chip was MT29F64G08TAA. My original assumption was that the chip identification reference indicated the “64G” as a 64 GB chip, the data sheet actually indicated 64GB but this refers to 64 GBits, not 64 GBytes (thanks to all who guided me in the right direction on this).
I reconfigured the programmer to read 64GB and it read with no errors. As a test, I did a second read for 128 GB and it read up to 64 GB and then 0′d out for the next 64 GB. My next plan it to do a read of 8 GB only, then compare this data with the first 64 GB read I got to see if there is any discrepancies or information found in the 64 GB read that not present in the 8 GB dump.
The dump creates two files, 32 GB each. I can read each one using Encase and they are different, indicating that it was not just reading 32 GB and then repeating itself. Both 32 GB dumps had different header information which indicates that I was not just getting 8 X 8GB reads as well. So what am I getting? This remains unclear but what I believe I am getting more than just an 8 GB data read from the chip.
I have discussed this problem with another expert in our field, Shafik Punja of Calgary PS, and his thought was this may be a function of the iPhone hardware, software, Controller Chip or the Flash Translation Layer that limits the usage of 8 GB of the actual size of the chip.
Unfortunately, NAND works in a manner that does not restrict this possible limitation defined by the iPhone and/or Controller Chip. NAND will use the full capacity of the chip as required to store data and allow for the process of the Wear Levelling functions. The memory will use the full capacity of the NAND chip and then move around and wipe data as required to store and update the user’s data, again, using the full capacity of the chip.
We have found similar instance’s of this when we do our chipoff training and work with 1 GB thumb drives to practice removing and reading the TSOP NAND memory. After the students complete the reads, the file size of the dumps are different. With the 1 GB thumb drives, we were getting dump of between 1.0 and 1.6 GB.
It is a known fact that NAND memory chips are sent from the manufacturer with bad blocks on them (unlike NOR), are the chip really bigger then we all believe them to be? Is there an area beyond the 8GB present to compensate for this? Do the manufacturers sell the NAND chips providing some extra space to make up for the bad blocks to provide an area for fault processes? There has also been a suggestion relating to how much the chip can actually buffer out in contrast to its actual size.
Another expert, that will remain nameless as I have not asked his permission to disclose it, provides this explanation:
Basically, this is very similar to a USB drive that its partition is being imaged (Fat16/FAT32 …). Actually this USB drive has a flash chip inside that in most cases will be larger than the actual partition (each USB drive manufacturer uses his own FTL and the ratio between declared size and actual flash size is their secret).
You can also see this from a different angle:
If an iPhone physical dump is in dd format, there are no flash spare area’s there, so only the “live” partition sectors are extracted, so there are generally other flash physical sectors that are not extracted.
There are other examples, such as Windows Mobile physical dump that also extracts the live partitions (Generally FAT). Same regarding some of the Android solutions that extract the YAFFS2, EXT2, EXT3 partitions, but not the complete flash chip.
During the analysis of this iPhone, I am recovering data throughout the chip read and some of the user data dates back 3 years including SMS text, internet history, emails and call logs. Good stuff to find but I need to validate if it came from beyond the 8 GB identified by the chip size.
I need to do some more work on this but I am also looking for others who are doing the same kind of work to see if we can come to a consensus on this. Is the NAND chip on the iPhone, or any phone for that matter, exactly the size indicated by the phone manufacturer? Is there user data beyond the size of the NAND chip identified by the chip number and phone company specs that can provide us with missing evidence?
I would like to open this for “constructive” discussion with other experts who are involved in the physical and RAW data extractions of mobile phones and see if anyone can help me with more research on this. I would hate to be missing out on valuable user data if it is there for the picking.
I appreciate the information/feedback from the original post I received from people like Shafik, Larry, Ron, J Z, Sean, Boris, Stephane, Mark, pytey from the DEV Team, Georg and the crew from Forensic Forum this weekend, all good stuff and it helps us solve the puzzles we encounter during our work on a daily basis. I have a number of suggestions to try and validate what I am seeing here, and will be busy over the next while working on it. I will update you when I can, so many projects on the go (-:
Thanks again!
