Adventures into NAND Dumping Part 2

Following on from my previous post into NAND dumping, I thought I would post about a recent issue I encountered, and also how to extract UBI file-systems.

In this particular case the NAND chip was a SK Hynix H27U1G8F2BTR-BC.

DumpFlash successfully dumped the contents, and listed it with a ID of: ADF101DA.

When running the Nand-dump-tool.py (to remove the OOB data), the tool reported back an error:

I had an immediate suspicion that the ID code was incorrect, so I resorted to the datasheet:

The 1st bytes represents the Manufacturer Code.
The 2nd bytes represents the Device Code.
The 3rd bytes represents the Internal chip number, Cell Type, Number of Simultaneously Programmed Pages.
The 4th bytes represents the Page size, Block size, Organization, Spare size.

I was then able to remove the OOB data using the new ID (ADF1001D):

Extracting UBI contents:

From here Binwalk was able carve out the UBI data, but was unable to successfully extract its contents:

Using the ubireader package (which is a Binwalk dependency), you can list the Volumes which are contained within the UBI data:

Then we can extract the volumes:

It should be noted, not all the extracted files are actually UBIFS:

Next I let Binwalk automagically extract all the contents:

Adventures into NAND Dumping Part 1

Over the next couple of blog posts I intend to document my adventures into NAND dumping.
My end goal is to dump the contents of NAND and successfully extract its contents.
This is a learning process for me, so if any information is wrong please let me know and I will correct my post. Additionally if you have any tips or tricks please comment below.

High-level key points on NAND memory:

• NAND technical specs are quite often vendor specific. You may have to resort to datasheet.
• Bad Blocks are blocks that contain one or more invalid bits whose reliability is not guaranteed.
• NAND can ship with Bad Blocks from the manufacturer. Manufacturers generally mark Bad Blocks.
• The smallest writable unit in NAND is a Page (aka Chunk).
• Pages are organised into larger units called a Block.
• The number of Pages per Block is vendor specific.
• Error Correcting Code (ECC) is used to detect (and sometimes correct) errors.
• ECC uses 2 common algorithms: Hamming and BCH
• The Out Of Band (OOB) (aka Spare Area) is a reserved area for ECC and sometimes metadata.
• The OOB area is stored after each Page.

Physically Accessing the NAND:

I am using a cheap Chinese hot air reflow station to remove NANDs from boards. I have not yet attempted to reattach a NAND.
I intend to add further detail at a later date, but essentially the process is to mask the surrounding area with Kapton tape to protect it from heat, then gradually heat up the NAND until the solder flows and you able remove the NAND using tweezers.

Whilst I do have some Bus Pirates/Blasters I have not yet attempted to dump the NAND using SPI/JTAG/etc, this will come in a later blog post.

Dumping Hardware:

I am using a "TSOP 48 to DIP 48 Pin IC Test Socket Programmer Adapter Converter" with a "Dangerous Prototypes FT2232H Breakout Board 1.0", based on the design by Jeong Wook (https://github.com/ohjeongwook/DumpFlash) to query and dump NAND.

I also have a 48 pin "360-Clip" attached to a "Dangerous Prototypes FT2232H Breakout Board 1.0", using the same design/pin out as above. I have NOT had any success with this.
The intention of using this is so you do not need to detach the NAND from the board. I have tested this with both attached and unattached NAND chips, I can only assume the pin out is wrong?

Dumping Software:

I am using DumpFlash.py also by Jeong Wook on Ubuntu 14.04.4 64bit. DumpFlash requires an older version of pyftdi to work.

Target Device:

This main components of this device are:

• ATMEL AT91SAM9610 ARM processor.
• 2 x Pointec PT483208FHG DRAM.
• Toshiba TC58NVG0S3ETA00 NAND.
• ATMEL ATMLH322 EEPROM.

It is useful to have an understanding of the target device components as this may hint at what you will expect to find on the NAND. In this case a ARM based architecture rather than the traditional x86.

Dumping the NAND:

First I query the NAND to confirm it is working:

As you can see DumpFlash successfully queried the NAND and pulled back information about the Page sizes, etc.

Next to Dump the NAND:

Dependent on the size of your NAND this process can take several minutes to complete.

With the NAND successfully dumped the first observation is the size discrepancy between the dump and the NAND information. This is because the dump includes both the Main memory and the OOB memory.

Exploring the dump:

Running Binwalk against the dump reveals some promising information, namely the U-Boot Header, Linux Kernel, and JFFS2 file-systems. This indicates the device is Linux based. Unfortunately there are several hundred entries for JFFS2 and Zlib which suggests the data is broken up:

Looking at the dump in a hex editor indicates the OOB areas are likely causing the problem.
To remove the OOB data I use a script by Jean-Michel Picod (https://bitbucket.org/jmichel/tools/src):

For the ID I supply the first 4 bytes of the Full ID we extracted earlier with DumpFlash.py.

Now when I rerun Binwalk I get a more of an expected output:

Next I tried using Binwalks automatic extract parameter but it was unable to extract anything meaningful. So instead I decided to manually carve the JFFS2 file-system from the dump:

I used a block size of 1 and skipped to the beginning of the JFFS2 area as listed in the previous Binwalk output.

From here I tried various tools (Binwalk, jffs2dump, etc) to extract the contents of the JFFS2 file-system without success, so instead I resorted to mounting it directly:

I used nandsim to create a virtual device, and supplied it the first 4 bytes from the ID I previously discovered.

From here the file-system was successfully mounted:

VLC Media Player 2.1.3 - .WAV DoS POC

VLC Media Player (2.1.3 Rincewind) - .WAV DoS Exploit:

!exploitable results:

Exploitability Classification: UNKNOWN
Recommended Bug Title: Data from Faulting Address controls Branch Selection starting at msvcrt!strcspn+0x000000000000002d (Hash=0x0c543936.0x0c29261d)
The data from the faulting address is later used to determine whether or not a branch is taken.

Download Here.

MPlayer (05/03/2014) - .WAV DoS POC

MPlayer [05/03/2014] (MPlayer-x86_64-r37182+g09725c1) - .WAV DoS Exploit:

!exploitable results:

Exploitability Classification: PROBABLY_EXPLOITABLE
Recommended Bug Title: Probably Exploitable - Data Execution Prevention Violation near NULL starting at Unknown Symbol @ 0x0000000000000008 called from Unknown Symbol @ 0x00000000067f2340 (Hash=0x48484848.0x53535353)
User mode DEP access violations are probably exploitable if near NULL.

Download Here.

Embedthis Appweb 4.2.0-0 - DoS POC

Embedthis Appweb 4.2.0-0 - DoS Exploit:

!exploitable result:

Exploitability Classification: UNKNOWN
Recommended Bug Title: Data from Faulting Address controls Branch Selection starting at libmpr!mprSeekFile+0x000000000000000f (Hash=0x0c566765.0x0c1b6765)
The data from the faulting address is later used to determine whether or not a branch is taken.

Download Here.

DD-WRT Network Sniffing

My DD-WRT router unfortunately does not have the option to create a TAP/Mirror Port, but using IPTables we can make a copy of all traffic and forward it to a IP:

SSH to your Router, in this case we are going to forward traffic to my IDS on: 192.168.1.200

iptables -A PREROUTING -t mangle -j ROUTE --gw 192.168.1.200 --tee
iptables -A POSTROUTING -t mangle -j ROUTE --gw 192.168.1.200 --tee

To confirm the rules have been created we can run the following command:

iptables -L -t mangle

To remove the rule we run the following command:

iptables -F -t mangle

VLC Media Player 2.0.3 - .AVI DoS POC

VLC media player (2.0.3 Twoflower) - .AVI DoS Exploit:

!exploitable result:

Exploitability Classification: UNKNOWN
Recommended Bug Title: Data from Faulting Address controls Branch Selection starting at KERNELBASE!lstrlenW+0x000000000000001a (Hash=0x2e3a5a04.0x79532c61)
The data from the faulting address is later used to determine whether or not a branch is taken. 

Download Here.