Reverse engineering NAND Flash Memory – POS device case study (part 3/3)

[Nytro]

[h=1]Reverse engineering NAND Flash Memory – POS device case study (part 3/3)[/h]Matt_Oh| November 17, 2014

In my first blog, I talked about a method for acquiring a NAND Flash memory image by directly interacting with the chip. After you acquire a raw firmware image, using the various approaches I proposed with my second blog, you should be able to easily identify the layout of the firmware. At this point in the process, it’s time to extract the data and manipulate it.

Figure 1 shows a typical firmware image layout. (This is also relevant to the POS device I worked on.) The U-Boot bootloader can be replaced with another bootloader if you like, and the JFFS2 file system can also be replaced with another popular journaling file system.

Figure 1 Typical firmware image layout

1st stage bootloader

The 1st stage bootloader is usually very architecture-dependent code that performs hardware initialization. The code is automatically loaded at address 0x00000000 by an ARM CPU when it powers up. Figure 2 shows the hardware initialization code from the image I worked on.

Figure 2 Hardware initialization code

The 1st stage bootloader usually loads up the 2nd stage bootloader – like a U-Boot bootloader for example. This is more of a general purpose bootloader and has more features than the 1st stage bootloader. This 2nd stage bootloader enables user interaction through UART, etc. It can also identify and load the kernel, and various images from various sources - including NAND Flash memory and the network location.

Figure 3 Code from U-Boot bootloader

U-Boot and U-Boot images

The U-Boot bootloader uses U-Boot images to pack the next level OS and recovery file system images. Figure 4 shows the definition of the U-Boot image header. It has a magic value of 4 bytes (27 05 19 56) and a new image always starts with a new block. So identifying U-Boot image is relatively easy. Figure 5 shows a typical U-Boot image header.

Figure 4 U-Boot image header

Figure 5 U-Boot image example

Sometimes, one U-Boot image contains multiple sub-images - Figure 6 shows an example. It contains a Linux kernel image and a Ramdisk image. This is a recovery OS image that is used when the main file system image is damaged or the main kernel doesn’t boot up correctly for some reason.

Figure 6 Multi-file image

The DumpFlash tool can be used to dump information and extract sub-images from U-Boot images. Figure 7 shows a good example when using the –U option to extract every U-Boot sub-image from the Flash device.

Figure 7 DumpFlash.py -U option to extract all sub-images

After acquiring the sub-images, depending on the type of the image, you can apply various analysis methods. If the file is a file system image, you can actually mount it on the system and browse the contents. Figure 8 shows an example of mounting an ext2 file system image file extracted from U-Boot image blocks.

Figure 8 Mounting RAM disk image

Journaling file system

Modern embedded systems usually use a journaling file system. This has some advantages over traditional file systems when initial performance is not as good. Usually when the machine starts up, it loads up the whole file system on DRAM first, with modifications to the file system being performed in memory before it is synced to Flash memory. The journaling file system makes it possible to split a file write into small chunks of records, so that it will not re-write the whole file contents when only small parts of it are modified. This is beneficial because reading and writing NAND Flash data is a slow process and excessive writing can diminish the lifespan of a NAND Flash device.

Identifying a JFFS2 file system (one of the popular journaling file systems used in the device) is relatively easy. When the JFFS2 software first prepares the NAND Flash device for JFFS2, it leaves a special marker called an erasermaker in the OOB area of the first page of each block. The erasermaker bytes are usually 85 19 03 20 08 00 00 00. (Figure 9)

Figure 9 JFFS2 erasermakrer

After the JFFS2 file system, investigating the contents is very straightforward. Just by using MTD (Memory Technology Device) in Linux systems, you can directly mount it as a file system. (Figure 10)

Figure 10 Mounting JFFS2 image

You can then browse the contents using usual Linux commands. (Figure 11)

Figure 11 JFFS2 contents

Modifying firmware

Acquiring firmware in itself is very useful for further analysis and vulnerability research. It is also beneficial if you can modify the firmware and reload it from the machine. This is not quite as easy, but it’s certainly not impossible. The first thing to do is to find the target code to patch. After this you’ll need to fix all related page checksums.

For example, the device I worked on has tamper protection. If the device is opened up at least once, it won’t boot up correctly and displays error messages similar to those shown in Figure 12. This is to alert the POS owner if any attempts to modify the device are made. Tamper protection is a big deal with POS devices because they process financial transactions. Obviously, if it is back-doored or tampered with the integrity of the system is lost and it could potentially leak credit and debit card information, such as track 1 and track 2 data.

Figure 12 Tamper protection in action

When I opened up the device, I saw another very curious device inserted between the front and back panels. This device connects the circuits of the front and back panels. (Figure 13)

Figure 13 Front and back panels

When I looked closely at the device, it appeared more interesting. (Figure 14) First I thought it was like plastic padding or something, but it actually had circuits inside it. And as I discovered, trying to tamper with this device is not easy. The conducting materials are painted inside the cover and any attempt to tamper with this easily breaks the circuits. So I suspect this device is used for tamper detection. When you open up the device, the current between the back and front panel is broken, and there might be a proprietary chip that detects this. Of course, this is just speculation for now.

Figure 14 Circuits inside plastic padding

The thing is that I don’t know exactly how tamper detection is performed at the hardware level but it is relatively easy to patch this up in the software level. To circumvent this protection, you need to find the process that actually checks the tamper detection in the device. The process that is responsible for this is the /bin/svcsec program. It is loaded with the rcS script when the system starts up. It uses a proprietary device called /dev/spectrum to retrieve tamper information. The code that is doing the tamper detection is shown in Figure 15 and you can patch the CMP instruction to the CMN instruction to change the control flow.

Figure 15 Patching CMP instruction

Now that you have a patched binary, you need to write this file into the flat JFFS2 image file. Figure 16 shows this process. DumpJFFS2.py has various command line options. The –t and –s options specify the location and size of the patch location in the file. Here we patched 4 bytes at offset 0x11380 of /bin/svcsec file. It reads the original JFFS2 dump file - named JFFS2-01.dmp - and modifies the affected JFFS2 records, writing the output to the JFFS2-01-Patched.dmp file.

Figure 16 DumpJFFS2.py tool to overwrite modified JFFS2 record

Figure 17 and Figure 18 show how this command modifies the affected JFFS2 record. The original record has a compressed data size of 0xF4 bytes. If you decompressed this data using the ZLIB library, it would be part of the executable code from /bin/svcsec. The decompressed size is 0x100 bytes. Out of these bytes, we modify only 4 bytes and compress the entire data again, which creates new compressed bytes of 0xEF size. After appending a few 0xFF padding bytes to fill the space between this and next JFFS2 record, the script calculates 3 CRC values – header, data and node - and writes them back to the header.

Figure 17 Original JFFS2 record

Figure 18 Modified JFFS2 record

Now with the patched JFFS2 raw image, you need to flash it back to Flash memory. With the changes made, it affects one page in this case. It doesn’t need to flash whole blocks and pages of the image, it just needs to write back one page. Figure 19 shows the command line options to achieve this. The –OJ option specifies the patched dump file to write back to and the –C option specifies the original JFFS2 dump file. The program compares both images and only writes the modified data. The –b option specifies the range of JFFS2 file system blocks. We already got this information with the DumpFlash.py –j command. You need to erase a block before writing NAND Flash pages – that is how it usually works with Flash memory, so the script will erase the affected block and rewrite the whole block, not just the page.

Figure 19 DumpFlash to write affected page

Movie 1 shows the process of re-soldering the Flash memory back to the board after modifying the firmware. If this process is successful, you can turn on the device and see it working again with the modified firmware.

Movie 1 Re-soldering Flash memory back to the board

Conclusion

After identifying the layout of the firmware using the various methods I shared last time, you can extract bootloader and file system images. I talked about extracting and modifying U-Boot images and JFFS2 images, which are very popular with embedded systems. Journaling file systems are especially interesting in the way they work and how they are laid out in the image file. Modifying a few bytes in the binary inside the file system involves various levels of modification to the image. First, the whole JFFS2 record that contains the affected bytes needs to be modified. Then the page that contains the specific JFFS2 record needs to be checksumed again. Next you need to write the image back to the physical Flash memory. Finally, you need to re-solder the chip to the board again. I used the example of a POS device. This POS device had tamper protection, but the check for tampering was performed in userland process level, which means that if you can modify the code, the protection is off. So even with very sophisticated hardware devices that detect tampering, a few bytes of code modification nullifies whole physical security concept.

Sursa: Reverse engineering NAND Flash Memory – POS device... - HP Enterprise Business Community