Viewing File Directory from NAND Flash Chip

[Crawlie69]

Thank you! I'll let you know!

[Arch Stanton]

No FAT?

[Crawlie69]

Alright, got the image edited to how i'd like it. It's got the exact same size as the original one as well

Attachments

logo00.7z

(246.67 KiB) Downloaded 526 times

[fzabkar]

Alright, got the image edited to how i'd like it. It's got the exact same size as the original one as well :D

Give me some to work on it.

No FAT?

The file system is read-only. It has no FAT or cluster allocation table, or anything of that type. The files are contiguous, so their directory entry needs only to identify the starting location and size.

[fzabkar]

Alright, got the image edited to how i'd like it. It's got the exact same size as the original one as well :D

Give me some to work on it.

Sorry, I meant "give me some time ..."

[Crawlie69]

All good my friend Take your time

[Crawlie69]

Hi again - i was wondering how it’s going with the image swap? Thank you again

[fzabkar]

Sorry for my late reply.

The first thing I would like to do is to ensure that the firmware will be able to decompress the new logo file. To this end we would decompress the original logo (with "AZ" header), and then recompress it. The result would need to match the original compressed file. Unfortunately I have been unable to find a suitable tool, with a suitable combination of parameters, to achieve the desired result.

[Crawlie69]

That’s alright mate Thank you for trying though. Guess they use some closed source firmware, whereever they develop the firmware then :/

[Crawlie69]

Still boggles me that the firmware can decompress files in such a complicated manner, while it doesn't show/state the decompression method used anywhere.. There is empty space left at the end of the firmware... Would it be possible to place the uncompressed .BMP at the end of the file, redirect the entry/loading thingy whatever and maybe the software would be able to read this 'raw' format, rather than a compressed file?

[fzabkar]

The total free space is 0x78BC0 (494528) bytes. A decompressed BMP file occupies 1.536MB (= 800 x 480 x 32 / 8).

[Crawlie69]

Still crazy how they are able to use so unknown compression parameters from a chinese factory. I don't understand how the firmware itself is able to uncompress the BMP file without having the compression method written somwhere in the firmware. Think i'll spend some time reading about compression, though it is probably a very hard task to solve this mystery, when you're even having trouble with it.

[fzabkar]

I have no knowledge of compression algorithms. I'm only an end user, like you.

[Crawlie69]

Understandable. However i wont give up just yet This is really the finish line, and after all the time spent on this firmware dump, i feel like a compression algorithm shouldn't stop me. I think i'm gonna do as much research as possible on 'compression' itself, and hopefully i'll find something. Interestingly i spoke with a local here about it, who told me that there's apparently a site (TaoBao i believe) where the chinese distributors can provide the tools and information behind the development of these embedded systems, and i even believe some big production companies provide the hardware and tools, for many of the headunits, where they are then distributed further to smaller companies and wholesalers, that then 'customize' the headunits before they are sold to the consumers.

- So possibly there's some kind of program out there made specifically for my hardware, but it's reaaaaally a long shot, and the rumors say that they arent selling these programs for cheap lol. Just thought i wanted to let you know Perhaps you've heard about similar stuff.

[fzabkar]

I've been through a similar process with a couple of DVD players based on Sunplus chipsets. A combination of development tools and inside information was involved. The data were encrypted (with an unsophisticated algorithm), and the checksum was convoluted. The ROM was programmed via an LVTTL UART interface. I succeeded in replacing the logo screens with landscapes, but the JPEGs had to be seriously compressed in order to fit into the allotted space.

[Crawlie69]

Hi again fzabkar

I've now compressed the BMP i want to merge into the firmware down to 105.557 bytes, and the original bootlogo bmp is 109.220 bytes, so they're pretty similar sizes now. I know we're dealing with this weird header in the 'stock' firmware, which also makes the BMP impossible to open on windows, however i've only compressed my BMP by lossy compression, in which i think i found a reasonable size and quality. Perhaps we could use a similar technique i used in my bluetooth speaker project, and then just fill the rest of my edited BMP with bytes, until they are exactly the same size. That'd make for an easy swap in the firmware i suppose.

However i'm wondering if my headunit will be able to read my BMP then, since the 'stock' BMP's all got those weird headers?

[fzabkar]

I don't think you understand the structure of the firmware.

This is not a case where you need to install the replacement image into the same space occupied by the original image. In fact you can install your new image anywhere in the free space, and your image can be as large as all the available free space. The original image can remain where it is. You only need to change the metadata in the directory to point to the new image location and to tell the firmware how large it is.

My software produces an "analysis" file which identifies the corresponding metadata.

BTW, your BMP file is 2 bytes too long (it has unnecessary 0x00 0x00 padding at the end).

Edit:

Is it a problem for you to experiment with flash images? I mean, will you risk working the board and IC to death if you resolder and desolder the chip multiple times?

[fzabkar]

These are the relevant directory entries:

Code:

  offset  filesize  origsize  dlen  attr  flag  lnam  lblk
--------  --------  --------  ----  ----  ----  ----  ----
    2430       594         0    18  0001  ...d     4     0  \config\logo
  2CCC50     1AAA4     1AAA4    20  0000  ....     A     0  \config\logo\logo00.bmp

                                          ...d = directory
                                          ..e. = extra block
                                          .c.. = compressed file

This is the relevant area in the MINFS file system:

Code:

Offset(h) 00       04       08       0C

00002430  50CC2C00 A4AA0100 A4AA0100 20000000  PÌ,.¤ª..¤ª.. ...        <--- you need to edit the first 3 dwords
00002440  0A000000 6C6F676F 30302E62 6D700000  ....logo00.bmp..
00002450  F4762E00 3E3D0000 3E3D0000 24000000  ôv..>=..>=..$...
00002460  0F000000 6C6F676F 30306272 6965662E  ....logo00brief.
00002470  626D7000 34B42E00 2A000000 2A000000  bmp.4´..*...*...

[Crawlie69]

Hi again. Sorry for the late reply - I've been very busy

Thank you for your answer!

It is no problem for me to experiment with flash images. So far i haven't even desoldered any of the chips i've been dumping, but been using a clip, that clips onto the eeprom.

I get what you're saying about the structure of the firmware - My thought was, that it would prevent messing around with the firmware too much, if you could match the data of the bootlogo BMP, with the exact bytes, so you wouldn't have to edit any metadata, etc, but just swap the image and call it a day. I don't know why i thought this was a better option, but i guess i was inspired by my other project.

[fzabkar]

There is a "$Root\res\boot_ui\logo_volkswagen.bmp" file in the first EEPROM in this thread. Perhaps you could use that?

Otherwise I have attached your VW logo (in "AZ" compressed format). You can paste this logo into your MINFS volume at offset 0x743040. That is the beginning of the free space. You would also need to enter this new offset at 0x2430 in the MINFS directory, plus its size 0x3F904 (twice). The values are little endian.

Attachments

logo00_VW_LZMA_64KB.7z

(254.42 KiB) Downloaded 398 times