0x01 - 01HY27UF084G2B Flash DataSheet

This article is the seventh in the 'Do whatever you can with what you have' series. The series was supposed to be over, but this one is a special extra. The research subject is the e-reader, and the focus is onFirmware Extraction and Reverse Engineering.

The content mainly includes:

0x00 Origin: A Deviation from the Right Path Research
0x01 Stand on the shoulders of giants: Hardware Information
0x02 Do it yourself: Firmware Extraction and Reverse Engineering
0x03 Summary: Brief Summary
0x04 In Conclusion: Series Summary
0x05 References: Reference Links

Previous Issues:

Do whatever you can with what you have (1) — Xiaomi Mi Band 3

Do whatever you can with what you have (2) — Cat Disc

Do whatever you can with what you have (3) — WiFi Signal Amplifier

Do whatever you can with what you have (4) — H3C Smart Camera

Do whatever you can with what you have (5) — Xiaomi Powerline Adapter

Do whatever you can with what you have (6) — Smart Plug

0x00Origin

This research was purely accidental, and it has strayed further and further from the original intention. When I was packing up, I found an antique-level e-reader Hanvon N510, it's unusable now, so I want to disassemble the screen to makeE-ink Display Digital Photo Album. Later, with the disassembly done, I decided to study the circuit board, then the chip, and finally the firmware, and step by step, I went astray.

0x01 Stand on the shoulders of giants

Here is a simple introductionE-ink Display,Nand Flashand ProcessorInformation.

0x01 - 00 ED050SC3(LF) E-ink Display

0x01 - 01HY27UF084G2B Flash DataSheet

0x01 - 02 Ingenic JZ4740 DataSheet

0x02 Do it yourself

0x02 - 00 Disassemble, disassemble, disassemble

Disassembly is very simple, the main purpose is to disassemble the screen:

The screen model is ED050SC3, 33 pin inkjet screen, and then the main line should be aroundDriver board,Hardware for image processingandDevelopment of display codeHowever...

The chip is Ingenic JZ4740 DataSheet,mipselArchitecture, the Nand Flash is hynix HY27UF084G2B.

Here we only extract the firmware from the Flash:

0x02 - 01 Firmware Extraction

This Flash is TSOP48 packaged, use the programmer to select the correct type, read the firmware, with a size of 528Mwhich is consistent with the storage structure described in the DataSheet.

0x02 - 03 Firmware Analysis

Until this moment, everything has gone smoothly, and the next step is just to run binwalk -eAfter quickly dealing with it, you can go back to doing serious development, however, some of the information is as follows:

> binwalk Hynix HY27UF084G2B.bin
DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
384112        0x5DC70         U-Boot version string, "U-Boot 1.1.6 (Sep 10 2009 - 15:22:56)"
385504        0x5E1E0         CRC32 polynomial table, little endian
4194304       0x400000        uImage header, header size: 64 bytes, header CRC: 0xEB6E491A, created: 2010-04-02 03:17:58, image size: 1487278 bytes, Data Address: 0x80010000, Entry Point: 0x802800C0, data CRC: 0xB8409BA4, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: gzip, image name: "Linux-2.6.24.3"
4194368 0x400040 gzip compressed data, maximum compression, has original file name: "vmlinux.bin", from Unix, last modified: 2010-04-02 03:17:58
25495523 0x18507E3 MySQL MISAM index file Version 2
26059613 0x18DA35D MySQL MISAM compressed data file Version 9
26102424 0x18E4A98 MySQL MISAM index file Version 2
51828922 0x316D8BA MySQL ISAM compressed data file Version 7
52586619 0x322687B MySQL MISAM index file Version 4
54650826 0x341E7CA MySQL ISAM index file Version 4
55179998 0x349FADE MySQL MISAM index file Version 2
58751182 0x38078CE MySQL ISAM compressed data file Version 11
58751288      0x3807938       MySQL ISAM compressed data file Version 11
58964726      0x383BAF6       Copyright string: "Copyright DynaComware Corp. 2009DFPHeiHK-W5DFPHeiHK-W5DFPHeiHK-W5RegularVersion 1.00Trademark by DynaComware Corp."
59047936      0x3850000       JPEG image data, JFIF standard 1.02
59047966      0x385001E       TIFF image data, big-endian offset of first image directory: 8
59048268      0x385014C       JPEG image data, JFIF standard 1.02
59050819      0x3850B43       JPEG image data, JFIF standard 1.02
59064320      0x3854000       JPEG image data, JFIF standard 1.02
59064350      0x385401E       TIFF image data, big-endian, offset of first image directory: 8
59064652      0x385414C       JPEG image data, JFIF standard 1.02
59069983      0x385561F       JPEG image data, JFIF standard 1.02
59101184      0x385D000       JPEG image data, JFIF standard 1.02
59101214      0x385D01E       TIFF image data, big-endian, offset of first image directory: 8
59101516      0x385D14C       JPEG image data, JFIF standard 1.02
59104127      0x385DB7F       JPEG image data, JFIF standard 1.02
59111992      0x385FA38       Copyright string: "Copyright (c) 1998 Hewlett-Packard Company"
59123712      0x3862800       JPEG image data, JFIF standard 1.02
59123742      0x386281E       TIFF image data, big-endian offset of first image directory: 8
59124044      0x386294C       JPEG image data, JFIF standard 1.02
59128366      0x3863A2E       JPEG image data, JFIF standard 1.02
59138192      0x3866090       Copyright string: "Copyright (c) 1998 Hewlett-Packard Company"
59172864      0x386E800       JPEG image data, JFIF standard 1.02
59172894      0x386E81E       TIFF image data, big-endian, offset of first image directory: 8
59173196      0x386E94C       JPEG image data, JFIF standard 1.02
59176220      0x386F51C       JPEG image data, JFIF standard 1.02
59184759      0x3871677       Copyright string: "Copyright (c) 1998 Hewlett-Packard Company"
59199488      0x3875000       JPEG image data, JFIF standard 1.02
59199518      0x387501E       TIFF image data, big-endian, offset of first image directory: 8
59199820      0x387514C       JPEG image data, JFIF standard 1.02
59208025      0x3877159       JPEG image data, JFIF standard 1.02
59221479      0x387A5E7       Copyright string: "Copyright" (c) 1998 Hewlett-Packard Company"
59322368      0x3893000       PDF document, version: "1.4"
59323055      0x38932AF       Zlib compressed data, best compression
59662336      0x38E6000       JPEG image data, JFIF standard 1.01
59674624      0x38E9000       JPEG image data, JFIF standard 1.01
59756544      0x38FD000       JPEG image data, JFIF standard 1.02
......
92250582      0x57FA1D6       Unix path: /var/run/wvdial.%iface% -s 2
92264872      0x57FD9A8       Unix path: /etc/iproute2/rt_tables
92267112      0x57FE268       Unix path: /var/run/udhcpd.pid
92278136      0x5800D78       Unix path: /var/run/syslogd.pid
92288396      0x580358C       Unix path: /dev/misc/rtc
92295543      0x5805177       POSIX tar archive (GNU), owner user name: " magic", owner group name: "not stat tar file"

No structure was extracted after automatic unpacking, and many false positives were found after manual addressing, except for U-Bootand uImageIn addition to the header information that cannot be solved, the only thing that can increase knowledge is that I know Hewlett-PackardIt is the full name of HP.

It is normal that it cannot be solved, because it is directly read from the Flash, so OOB needs to be manually removed, that is, the normal data is 512M, but each block is interspersed with redundant information, so the overall data is 528M, the specific structure is as follows:

Memory: 4096 blocks × 64 pages/block × 4 sectors/page × 512 Byte/sector = 512 MiB
Spare memory: 4096 blocks × 64 pages/block × 4 sectors/page × 16 Byte/sector = 16 MiB
Total memory: 512 MiB + 16 MiB = 528 MiB

It can be removed using Flash tools or a simple script:

def fix_data(i, src_file, dst_file):
    with open(src_file, "rb") as fpr:
        with open(dst_file, "wb") as fpw:
            while(i > 0):
                fpw.write(fpr.read(0x800))
                gap = fpr.read(0x40)
                i = i - 0x800 - 0x40

if __name__ == '__main__':
    total = int(sys.argv[3], 16)
    src_file = sys.argv[1]
    dst_file = sys.argv[2]
    fix_data(total, src_file, dst_file)

Now, using binwalk can unpack the gzip format uImage, and after decompression it is vmlinux.bin, it also indicates that the previous operation was correct.

As for binwalkinformation identified by rootfsis very likely RTOS, using binwalk -ADiscover a large number of mipselinstructions also prove this point, which is the beginning of going astray.

After the firmware is trimmed and the tail 0xff is removed, according to the guess, it is loaded into IDA for analysis, although many instructions and strings are indeed identified, but there is no clue about the loading address, and I can only turn back and look at vmlinux.bin.

Whether from the information identified by binwalk or its name itself, it is basically certain that this is a Linux kernel, indicating that this e-reader uses the Linux system, which is contradictory to the previous RTOS, but rootfsIt was not recognized, nor was any useful header information found.

So I went back to the firmware itself, searched for useful strings, and started with Uboot first:

We got the boot parameters:

bootargs=mem=64M console=ttyS0,57600n8 ip=172.17.2.26 rootfstype=yaffs2 root=/dev/mtdblock2
bootcmd=nand read 0x80600000 0x400000 0x200000;bootm
bootdelay=3
baudrate=57600
loads_echo=1
ethaddr=00:2a:cc:2a:af:fe
ipaddr=172.17.3.30
serverip=172.17.3.113
autoload=n
bootfile="uImage"

from bootargsIt is obvious that the one used is Linuxsystem, rootfsUsage Yaffs2structure, stored in mtdblock2In it, the firmware structure is likely to be as follows:

Uboot can also be manually unpacked according to the string and Flash Block, but yaffs2 did not start unpacking, an important reason is that the starting address of mtdblock2 cannot be found, and the read address 0x400000 in bootcmd is also obviously not. At this time, I feel that I started too early, and the conventional research method isFind the dynamic debugging interface and obtain dmesg information, so it is easy to know mtdblock2addresses.

Found several containing ELFThe structure of the header can indeed be restored, and there are also symbols:

It shows that there is indeed a file structure, and it is not achieved through scheduling. Because it is more麻烦 to re-solder the Flash, so start from yaffs2. The author just analyzed the UBI structure in the same way a few days ago. Here yaffs2 is not compressed and is stored directly in the Flash through a linked form. Searched for the magic information of yaffs2, but could not find it in the firmware, even thought of directly using unyaffs to traverse and brute force, but the file is too large.

With a try-and-see attitude, I really found a firmware package for an e-reader with a similar model:

From the name and size, you can basically know the function and startup sequence:

uboot → kernel → initramfs → application

Because of the differences in models, the firmware format is not completely the same, and the largest application_upgradeis yaffs2format.

Here is some nonsense: the decompression approach for rootfs in formats such as ubi and yaffs2 generally has two types

Usage unyaffs/ ubi_readerand other tools to directly parse the structure
Usage nandsimMount after simulating Flash

Although the former is relatively easy, it has high requirements for tools, and the content read from the Flash is likely to report an error. After modifying the ubi_reader source code in many places, the author decisively gave up and chose to modify the firmware data and use the second nandsim method. But here you can directly use unyaffsDecompress.

unyaffsBy installing with apt install, the yaffs2 format of the above application_upgrade can be directly identified:

By analyzing the application_upgrade format, search for the following string in the firmware that needs to be analyzed:

03 00 00 00 01 00 00 00 FF FF 00 00 00 00 00 00

There is only one, extracted by removing the tail 0xff according to the Flash structure and parsed using unyaffs, but an error is reported:

> unyaffs -d test
Detect no layout(s)

This is quite embarrassing, and we can only go back to the old way of modifying the source code to print the structure...

There is another way, which is to compare the Block header structure of the two files, and find that they are completely consistent, but the end of the first Block has a distinct difference:

The file structure is extracted to 0x800 and ends here:

application_upgrade ends at 0x8400:

This makes one think of the 0x40-byte OOB, so yaffs2 header is directly found in the unprocessed firmware data and extracted, successfully obtaining rootfs data:

In this way, all the required structures have been extracted, and the analysis can proceed next.

so many P's ~

The firmware unpacking is over, as it is not the main task. Looking back at this point, the unpacking process is just:

Remove OOB, extract Uboot, vmlinux.bin

Original file found 03 00 00 00 01 00 00 00 FF FF 00 00 00 00 00 00Extract data using unyaffs to restore yaffs2 rootfs.

so easy, but just like vulnerability挖掘, it may be just one sentence to show you, but it's hard to find by yourself.

0x02 - 04 Back to Development

Development is another topic, and this is just a brief mention due to limited space.

UsageEPDIY Plan, which supports this e-ink screen:

Since open source requires self-design, I found a ready-made one at JLC ESP32 Integrated SolutionBecause the author is not professional and is still in the process of making mistakes...