HDD GURU FORUMS http://forum.hddguru.com/ |
|
Viewing File Directory from NAND Flash Chip http://forum.hddguru.com/viewtopic.php?f=10&t=40760 |
Page 2 of 4 |
Author: | fzabkar [ January 3rd, 2021, 15:14 ] | ||
Post subject: | Re: Viewing File Directory from NAND Flash Chip | ||
I've worked out how to decompress those files which are flagged as compressed in their attributes. I'll use epos.img as my example. This is the header: Code: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 5D 00 80 00 00 00 71 83 BC 0E 20 73 F2 70 63 5A These are the compression parameters: Code: 5D lc, lp and pb in encoded form 00800000 dictionary size (little endian) = 0x8000 This is what 7-Zip expects to see: Notes on the LZMA format: https://github.com/cscott/lzma-purejs/b ... /FORMAT.md Code: The LZMA header is not well documented. It's also a bit usual: it doesn't appear to have a magic byte prefix, as one would expect from a modern file format, and it not word-aligned. Nevertheless: Offset Size Description 0 1 lc, lp and pb in encoded form 1 4 dictSize (little endian) 5 8 uncompressed size (little endian) -lc{N}: number of literal context bits - [0, 8] -lp{N}: number of literal pos bits - [0, 4] -pb{N}: number of pos bits - [0, 4] To make 7-Zip happy, we need to insert 8 bytes corresponding to the decompressed size of the payload. We can obtain this information (size2 = 0x740B0) from the file's directory entry. Code: offset filesize size2 dlen attr flag lnam lblk -------- -------- -------- ---- ---- ---- ---- ---- 4820 2444A 740B0 1C 0004 .c.. 8 0 \epos.img ...d = directory ..e. = extra block .c.. = compressed file The new header becomes ... Code: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 5D 00 80 00 00 B0 40 07 00 00 00 00 00 00 71 83 The parameters are little endian. The modified file can now be decompressed by 7-Zip.
|
Author: | fzabkar [ January 5th, 2021, 1:11 ] |
Post subject: | Re: Viewing File Directory from NAND Flash Chip |
I have modified my program to generate LZMA files with modified headers so that they can be recognised by 7-Zip. Unfortunately the example I used is the only one that decompresses correctly. All the other files decompress incompletely. Either the choice of algorithm is incorrect, or there are two or more sections to the payload. I tried to apply a similar technique to the compressed BMPs. The headers appear to have the same LZMA parameters. Code: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 41 5A 31 30 36 70 17 00 5D 00 00 01 00 AZ106p..].... I stripped off the AZ106p signature and inserted a file size of 0000000000020000 corresponding to 128KB. Code: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 5D 00 00 01 00 00 00 02 00 00 00 00 00 7-Zip was then able to recognise the file and decompress it, but only the first 0x36 bytes. The rest of the space is filled with some repeating data pattern. Every BMP produces the same result, but with a different pattern. Code: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 42 4D 36 70 17 00 FF FF FF FF 36 00 00 00 28 00 BM6p..ÿÿÿÿ6...(. 00000010 00 00 20 03 00 00 20 FE FF FF 01 00 20 00 00 00 00000020 00 00 00 70 17 00 00 00 00 00 00 00 00 00 00 00 00000030 00 00 00 00 00 00 FE FE FE FF FE FE FE FF FE FE 00000040 FE FF FE FE FE FF FE FE FE FF FE FE FE FF FE FE ........ 0001FFF0 FE FF FE FE FE FF FE FE FE FF FE FE FE FF FE FE FWIW, if I take those first few bytes which are common to each BMP (see previous post) and decompress them, I get ... Code: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 42 4D 36 70 17 00 FF FF FF FF 36 00 00 00 28 00 BM6p..ÿÿÿÿ6...(. 00000010 00 00 20 03 00 00 20 FE FF FF 01 00 20 |
Author: | fzabkar [ January 5th, 2021, 1:50 ] | ||
Post subject: | Re: Viewing File Directory from NAND Flash Chip | ||
The size of the BMPs is 0x177036. If I modify the LZMA header as follows ... Code: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 5D 00 00 01 00 36 70 17 00 00 00 00 00 ... I get a valid BMP after decompresion. Logo.bmp produces a black welcome message on a white background. That explains the repeating data pattern.
|
Author: | fzabkar [ January 5th, 2021, 2:38 ] | ||
Post subject: | Re: Viewing File Directory from NAND Flash Chip | ||
Here are the logos.
|
Author: | fzabkar [ January 5th, 2021, 17:43 ] |
Post subject: | Re: Viewing File Directory from NAND Flash Chip |
According to this web page ... https://github.com/cscott/lzma-purejs/b ... /FORMAT.md ... the compression level is 1. Code: -1 5d 00 00 01 00 The corresponding parameters for 7-Zip's compression algorithm are ... Code: { 0, 16, 64, L"hc4", 3, 0, 2}, // -1 Code: struct lzma_option { short compression_mode; // -a short dictionary; // -d short fast_bytes; // -fb const wchar_t *match_finder; // -mf short literal_context_bits; // -lc short literal_pos_bits; // -lp short pos_bits; // -pb }; AFAICT, the following command line should take the decompressed BMP file and recompress it to its original form. Code: "C:\Program Files\7-Zip\7z.exe" a logo_bmp.7z logo.bmp -m0=LZMA:a=0:d=16:fb=64:mf=hc4:lc=3:lp=0:pb=2 However, the resulting payload is not as expected. |
Author: | fzabkar [ January 5th, 2021, 21:02 ] |
Post subject: | Re: Viewing File Directory from NAND Flash Chip |
I realise I'm talking to myself, but this appears to be the operating system: Embedded Parallel Operating System: https://epos.lisha.ufsc.br/EPOS+2+User+Guide |
Author: | HaQue [ January 5th, 2021, 23:32 ] |
Post subject: | Re: Viewing File Directory from NAND Flash Chip |
No, This is really informative. I've been following but don't have anything better to add! If I wasn't working on making PCB for L18 Strataflash from old Cell Phone I would probably buy one of these stereos to hack around with and display much more fun logos for example. |
Author: | fzabkar [ January 5th, 2021, 23:46 ] |
Post subject: | Re: Viewing File Directory from NAND Flash Chip |
When the system boots, ramdisk.iso becomes drive C: and the main MINFS volume becomes drive D:. The RAM drive has a shell whose embedded help docs (after decompression) are as follows: Code: = Help Information: v2.0 =
= cat <filename> [/x] : show specific text file content(/x: hex) = = cd <dst_path> : change current diretory = = copy <srcfile> <dstfile> : copy one file = = cpustatstart : start cpu stat = = cpustatstop : stop cpu stat = = cpustatreport : report cpu stat = = create <filename> : creat a file = = del <filename> : delete a file = = dir : show content of current or specific dir = = fs : fs debug control = = help : help information = = history : display the history command = = insmod \drv\<drvname> : install module = = keysim : keyboard simulation = = mkdir <dirname> : creat a direntory = = mount <driver> <res> : mount one specific driver = = poweroff : power off = = quit : jump out shell Be careful use 'quit' = = reset : reset the system = = rmdir <dirname : delete a direntory = = run <programme> [/w] : run axf file under current or specific dir = = set : set the debug envirnment = = setpath : set app seach path = = src <script file> : execute one script file = = startx : start x window = = sysinfo : list process/thread info and memory info = |
Author: | fzabkar [ January 5th, 2021, 23:54 ] |
Post subject: | Re: Viewing File Directory from NAND Flash Chip |
HaQue wrote: No, This is really informative. I've been following but don't have anything better to add! I can't work out how to calculate the checksum. I believe it would need to be done in the range 0 - 0x243FF. That appears to be the boot code. You say that you managed to do this for a Commodore. Any clues? The header format of the compressed BMP appears to be ...
size of original uncompressed BMP file - dword, little endian 0x5D - LZMA algorithm parameters dictionary size in bytes - dword, little endian LZMA payload |
Author: | fzabkar [ January 6th, 2021, 0:18 ] |
Post subject: | Re: Viewing File Directory from NAND Flash Chip |
I forgot to say that the logos are 800 pixels wide, 480 pixels high, and have a depth of 32 bits per pixel. There is plenty of space at the end of the MINFS volume to store a complicated logo. One would only then need to determine which of the BMP directory entries to edit to point to the new logo. I couldn't find any INI file, or similar, which tells us the make of the car that the unit was built for. Instead I'm thinking that this unique info may be stored in a small EEPROM, eg 24C02. Of course this is irrelevant if one only wants to edit the Welcome logo. |
Author: | fzabkar [ January 9th, 2021, 13:50 ] |
Post subject: | Re: Viewing File Directory from NAND Flash Chip |
I think I've found the checksums for the various boot blocks: https://linux-sunxi.org/Boot0 Code: Offset(h) 00 04 08 0C 00000000 A80000EA 65474F4E 2E425430 62F4BE6E ¨..êeGON.BT0bô¾n ^^^^^^^^ 00000010 003A0000 30000000 32303030 31313030 .:..0...20001100 00000020 31323030 31313030 53554E49 49000000 12001100SUNII... 00000030 78020000 31323030 00000080 00000000 x...1200...€.... 00000040 A0000000 01000000 01000000 00000000 ............... 00000050 01000000 10000000 0A000000 0D000000 ................ 00000060 04000000 04000000 01000000 05050501 ................ 00000070 01FF0000 05050501 01FF0000 00000000 .ÿ.......ÿ...... 00000080 06000301 01FF0000 06050301 01FF0000 .....ÿ.......ÿ.. 00000090 06030301 01FF0000 06010301 01FF0000 .....ÿ.......ÿ.. 000000A0 00000000 00000000 03010201 01010000 ................ 000000B0 03000201 01010000 03030201 01010000 ................ 000000C0 03020201 01010000 00000000 00000000 ................ Code: Structure of Boot0 Offset Name Size Notes 0x00 B_INS 4 Branch instruction to Code Starting Point 0x04 Magic 8 Ascii string "eGON.BT0" (No Null-terminated ) 0x0c Checksum 4 Simple 4-bytes Checksum (Before calculate checksum this must be 0x5F0A6C39 ) 0x10 Size 4 Size of Boot0, it's must be 8-KiB aligned in NAND and 512-Bytes aligned in MMC 0x14 Code - Code of SPL. The size depends on the processor and if it 's loaded from SPI, NAND or MMC Good info here: https://linux-sunxi.org/BROM https://linux-sunxi.org/FEL A second boot block with its own checksum ... Code: Offset(h) 00 04 08 0C
00006000 AA2000EA 65474F4E 2E425431 7F4B1CA6 ª .êeGON.BT1.K.¦ 00006010 00160100 B0820000 32303030 31313030 ....°‚..20001100 00006020 31323030 31313030 53554E49 49000000 12001100SUNII... 00006030 80820000 31323030 01000000 05050501 €‚..1200........ |
Author: | sin [ January 12th, 2021, 11:47 ] |
Post subject: | Re: Viewing File Directory from NAND Flash Chip |
Nailed it Frank. |
Author: | Crawlie69 [ April 14th, 2021, 6:45 ] | ||
Post subject: | Re: Viewing File Directory from NAND Flash Chip | ||
Hey this is awesome stuff. I know im late to the party, but would really love your help. I've also got a chinese head-unit, with very similar hardware. - AllWinner F1C200S - Some 8MB eeprom (Sorry i don't remember the name) I've extracted the contents from the eeprom and ran binwalk on the file, where i tried feeding offsets through dd, extracting it, etc. The data i get is not really usable to my knowledge, as i just get a bunch of useless files when extracting through binwalk. I've been trying to get help on reddit, and someone sent me this forum post. My firmware must be very similar, but unfortunately the program you made won't work for me. I don't know why but im not able to run the .exe file you've made. Also i was wondering, how you'd compile everything again after extraction, so it can be written to the eeprom. I've attached the firmware dump in case anyone wants to play with it. Thanks!
|
Author: | Crawlie69 [ April 15th, 2021, 16:42 ] |
Post subject: | Re: Viewing File Directory from NAND Flash Chip |
Hi again... Hopefully you'll see this I got it running, but i keep getting an error saying 'Length of image file (0x2AD31) is inconsistent with superblock (0x7BBC00)' |
Author: | fzabkar [ April 16th, 2021, 1:08 ] |
Post subject: | Re: Viewing File Directory from NAND Flash Chip |
Use a hex editor to extract the MINFS to a file, and then run my tool against the extracted file. The MINFS is located at offsets 0x24400 - 0x7DFFFF. |
Author: | Crawlie69 [ April 16th, 2021, 6:38 ] |
Post subject: | Re: Viewing File Directory from NAND Flash Chip |
Hey thank you! Guess my end offset was off. I got it extracted, and it's very interesting stuff. Took me 4 months of posting my project in every thinkable place to get here, and honestly im so thrilled about the fact that i even have it extracted. However i've tried understanding the stuff you wrote earlier about the compression of the bmp files, but it's beyond my skillset. Would i hypothetically be able to somehow decompress the BMP's, find the boot logo, edit it and somehow compress it and merge it back into the firmware? After poking around the extracted filesystem, i can see that my firmware is a bit different than OP's. Also thank you so much for writing this script - Hard to imagine why people of the internet would help, but apparently there's also nice people around on the internet. Im so thankful for all the help i've got so far. If the guy on reddit didn't show me this, i'd never come any closer to changing that boot logo. I'd never thought it would be this complicated to swap a boot logo haha, but im too deep now |
Author: | Crawlie69 [ April 16th, 2021, 7:46 ] |
Post subject: | Re: Viewing File Directory from NAND Flash Chip |
Also i was wondering if you'd be able to run the firmware in a virutal machine, and experiment modifying stuff that way before you'd write the firmware to the headunit? |
Author: | fzabkar [ April 16th, 2021, 10:11 ] |
Post subject: | Re: Viewing File Directory from NAND Flash Chip |
If you examine the files, you'll see several that have .LZMA extensions. These files don't actually exist in the file system, but have been created by my program. They are mostly identical to their similar named counterparts, with the exception that I have added a header which then allows these LZMA files to be decompressed by 7Zip. These decompressed files can then be viewed in an image editor. |
Author: | Crawlie69 [ April 16th, 2021, 10:15 ] |
Post subject: | Re: Viewing File Directory from NAND Flash Chip |
I was wondering about them. Good stuff! Is it possible to then merge an edited picture back in the original file? |
Author: | fzabkar [ April 16th, 2021, 10:19 ] |
Post subject: | Re: Viewing File Directory from NAND Flash Chip |
I would write the edited BMP (with appropriate header) to the free space at the end of the MINFS volume, then edit its directory entry to point to it. Let me know when you get to this point. |
Page 2 of 4 | All times are UTC - 5 hours [ DST ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |