The process is the same as the Android phone I mentioned in my previous post, only difference is the equipment. The JTAG points are connected by soldering the wires to the Test Access Points (TAP) on the PCB board to the corresponding pins of the JTAG device.  Then using the software interface, identify the controller chip and memory chip and establish communication with the two in order to get your data dump. In this case, it appears that the Blackberry 8130 uses a 64 MB NOR flash memory and the device’s CPU is a MSM 6550 from Qualcomm.

Once everything is configured, the acquisition takes place. This process takes time, much slower than using the regular tools through USB. The process recovered 67108864 bytes of data including images, call logs, contacts, SMS Text messages and more. My good friend and one of the leading experts in Blackberry Forensics, Shafik Punja, has been provide the pre-IPD backup file and this data dump to compare them in search of deleted data; validation; and to assist with decoding the user data for future R&D and training purposes.

My intention was to discover a way to acquire a Blackberry in a locked state by circumnavigating the USB port using the JTAG process,  not unlike the Android phones that have USB Debugging disabled and locked by the user. What I did discover was a way to recover a PHYSICAL acquisition of a Blackberry device using the JTAG process, the dump is a full data acquisition from the memory used by the device to store the user data. The difficulty is that this data is fragmented and requires some work to carve out and decode the information )-: Larger files like multimedia are very difficult to recover using this process. The way NAND flash deals with data causes these files to be fragmented to a point that recovery is usually only possible by rebuilding the Blocks and Pages (Spare Data associated with these) in order using the FTL to recreate a logical format.

My next project still involves the Blackberry phone. One of my graduates from the Teel Tech Training Advanced Chipoff class from the UK used the tools discussed in class to recover a chipoff acquisition of the BB 9700. My goal is to repeat his process to test the phone in three states, unlocked; locked but not encrypted; and locked and encrypted, to see difference in how the data is stored. This process will also involve acquiring a 9800 that carries a similar NAND Flash chip………………….So many things to try, so little time (-:

Recently I was directed to a link that shows a group in the UK that have created a Python script to help us recover the swipe user lock code on the locked Android devices, please see this at the CCL-FORENSICS news page.

This is exactly the process that I was looking at when I was acquiring the user data partitions from the Android devices using the JTAG process. With the RAW data recovered from the device using the JTAG process, the phone can be reassembled and the found user code implemented on the device so the forensic tools can make the acquisitions. Thanks to CCL-FORENSICS, we now have a tool to run against this physical data dump. Thanks for sharing this guys!

Happy JTAG’ing!

**********************************************

I am putting together an introduction JTAG course in time for the 2012 Mobile Forensics World in Myrtle Beach and the full 5 day Advanced JTAG training will be rolling out in August through Teel Tech Training.

Sorry that I have been away for a bit, between family holidays, taking courses and teaching a number of Chipoff Classes these past few months, I have not had the time to post anything to my Blog. I am taking some time off travelling to return to R&D of physical acquisitions of cell phones. I will continue to find more solutions for the BGA chips for the Chipoff process, the classes are now reading chips from various phones like Blackberry, iPhone, HTC, and the core LG/Samsung/Motorola phones. With this R&D kind of on the side plate, I am now focussing on the JTAG process and have had some success with it. I would like to share a bit with everyone so you know that this process is another option for you to get past the dreaded locked Android phones………enjoy!

Besides the challenges of keeping up to date with the iPhone OS updates and Blackberry passcodes, we are faced with the challenge of the Android smart phones that are either passcode or pattern locked. If the android phone has a user lock on it and the USB Debugging is not activated (by default it is turned off), then most Android phones can not be accessed by Law Enforcement to gather evidence. There are tools out there that are working on getting past the user lock code of an Android phone with the USB Debugging deactivated but this is limited to a small number of phones……for now, I have confidence that they will persevere! Here is a quick overview of where I am to date…..keep in mind, this is just in general terms, there is a lot more to this process but this is a Blog just to introduce the process to Investigators who are not aware of it or looking for other options……

The JTAG process requires research into the cell phone that you are working on. This includes looking into what kind of CPU, NAND memory, controller chip and pinouts you will be dealing with. The pinouts are the actual test points that are found on the mainboard that provide a communication path with some items found on the board, in our case, the memory that contains the user data. This research into the phones will also take you to tear down sites as you will have research in order to take the phone apart, and later put it back together to input the passcode to use your forensic tools on it.

Below is the pinout diagram of the HTC Incredible found on the GSM-Forum:

The next step is to be able to hook up the pinouts from the mainboard to the JTAG box that is in turn operated by the Debugging type software. With the above reference, it is fairly easy, but if you can’t find one, then you need to do some probing to determine what function each pinout is related to.

Connecting the pinouts can be challenging, you can either use pin type probes or use your soldering skills (WildPCS Cell Phone Repair course is great for this) to accomplish this. Below is an example how one can make a connection with the JTAG Box:

The phone needs to be powered on at this point, you can either use the USB power or a DC power supply and probe the battery connectors. Now the reading process can begin, using a profile provided by the software you are using or manually configuring the settings using open source processes, activate a read from the Flash memory and get your Physical data dump from the cell phone. Here is what the process looks like:

The result in this case is a physical data dump of the memory from this  HTC Incredible that revels the OS and user data. The process can take some time and speed depends on the type of connection (RJ45 or IDE type pin). The results are very rewarding for the work you put in though:

We now have a physical acquisition of the phones flash memory. Because we have bypassed the USB port (shut down by USB Debugging) and found another channel to access the flash memory, this is a solution for Investigators to use while our Forensics Tools seek out a Nintendo type solution. The R&D continues into the JTAG process and I will provide updates as time goes on. My quest now is to seek out the user pass code in this physical data dump, and with that, put the phone back together and access it using this new-found pass code in order to analyze it with my forensic tools.  Forensics tools are providing resources to decode this from JTAG dumps if you can locate specific files, for instance, VIAForensics has a solution to use after you have obtained a JTAG dump. Cellebrite also has a solution coming in its new release due out in the next week or so:

This is still in the initial stages but as I said, it is exciting to get the reads from the flash memory after all this work, very rewarding. Even if you don’t get a solution from the Forensic Tools for your phone and the JTAG process is supported, you will have a physical data dump from the flash memory that you can use automated and manual tools/processes to recover your user data, including the deleted items.

The JTAG process will be included in the upcoming Flasher Box training at Teel Technologies in early 2012.

I am very open to sharing ideas and work with any researchers who are pursuing the same techniques, or new ones, found in my Blogs, but please keep in mind, the magic word is “sharing” (-: Feel free to email me with comments, sugestions and feedback: cop.geek@gmail.com

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

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.

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!

This is a new area of user data acquisitions and is still being researched and developed. As a group, we can collaborate our R&D and work together to decode the physical and RAW data dumps we get from these sources.

We are looking for forensic examiners who are actively doing data dumps from mobile devices using tools like flasher boxes and chip off type programmers and who are manually decoding this results from these dumps.

This will be a participation type group where sharing of findings and techniques is required to remain a member of the group. I am a firm believer of sharing ideas, findings and theories so that we all can benefit from the groups contributions. If this is of interest to you, join up at:

http://groups.google.com/group/physical-mobile-forensics

My main focus will be on Mobile Forensics. I have a passion for this type of work and a drive like no other when it comes to getting information from cell phones. Like most people who I have met and/or communicated with in this field, we like to share ideas, findings and methods, and I am a firm believer of this. If I know how to process and/or access certain information from a mobile device, it is not a secret, it belongs to the community and I am the first to share this with everyone.

Why do I feel this way, because I am where I am now because of people who were willing to share with me their work and research in this field. Call it a form of “payback”.

Please stay tuned to this blog over time and when I get some spare time, I will post information on my findings and share with you other people’s findings (with their permission and credit given) when I can.

If you looking for training, I do train through Teel Technolgies Inc. If you are Law Enforcement and are looking for assistance and I can help, contact me via the Victoria Police Department.

Thanks for being a part of one of the best communities I know, Computer and Mobile Forensics.

Talk Soon,

Bob – aka Copgeek018

cop.geek@gmail.com