Products > Embedded Computing

Extracting firmware from generic chinese car headunit.

<< < (5/6) > >>

Crawlie69:
Nice work! Would love to know more about these roms, and how they're run within the firmware. I also wonder how the rest of the firmware would be extracted. I see boot images (i believe?) and other cool stuff. Doesn't appear to be stored in any weird filesystem format, because a lot of it is readable straight from the firmware dump, but how it would be extracted i don't know yet  :D

Edit:

Maybe some of the data recovering programs could work? DMDE didn't give me any results, which i find weird because there appears to be lots of files visible outside the JJFS2 file system.. Would love to get the rest 'carved out' just cause.. Why not?  ;D

Edit:

Could the rest of the firmware just be stored in a simple UFS file system? Examining the decompressed roms, reveals unix paths, which appear to be stored outside the JFFS2 file system. The JFFS2 file system pretty much only seems to contain the pictures for boot and roms for Carplay, Android Auto, Apples IAP2, The chinese 'Carlife' and WFD. Seems like they just stacked the JFFS2 file system on top of the existing firmware, which also explains why it's pretty much identical to my last firmware from the user interface.

fzabkar:
DMDE (and all data recovery programs) look for file signatures at specific sector offsets. For example, a JPEG file in an NTFS file system starts with 0xFF 0xD8 at offset 0 within the sector. Your embedded JPEGs, on the other hand, are all over the place.

There is a block of JPEGs in the eCOS section between offsets 0x33E510 and 0x41DC1D. The preceding data look like graphical bitmaps, but I can't identify the beginning and end of each file. There must be some kind of directory which tells the firmware where to find each file, but I can't see it.

You can see the beginning of the first file after the last JPEG. It appears to contain bitmap data (not compressed), but I can't think what image format it could be.


--- Code: ---Offset(h) 00       04       08       0C

0041DC10  00000000 00000000 00000007 FFD90000
                                     ^^^^
                              end of last JPEG

0041DC20  14001100 08000000 CCF34198 14001100
          ^^^^^^^^
          beginning of next file

0041DC30  08000000 20F54198 0E000000 AC004C98
0041DC40  0E000000 2C004C98 3F000000 A4B05098
--- End code ---

amyk:
LOL @ JPEG #6...

Based on strings "8368-U" "8368-U-X" "8268K-WC" etc. found in some of the firmware files, this is probably one of these: https://www.sunplus.com/products/adas.asp
Unfortunately, like a lot of SoCs, detailed information on them is hard to find.

Crawlie69:
Sorry for the late reply - I've been very busy  :D

amyk: - Cool stuff - Seems that i was right in assuming it was some kind of arm processor lol.  :) I've had this happen multiple times, and it kinda makes the reverse engineering process harder, because without any datasheets it's harder to get an idea of how the firmware works in relation to the processor. I thought multiple times about the possibility of running the firmware in QEMU to have a live debugging environment, but i don't know if it's possible or even worth it.

fzabkar: Makes sense with DMDE, but i don't understand why it isn't possibe to scan all over the place instead of scanning specific sector offsets? - Maybe i don't really understand how it works. However since it's 99% sure that the firmware is based on some kind of version of eCos, which is open-source, would it be worth it reading the documentation about eCos? There must be a lot of 'default' settings or ways to set up the firmware, hence there must be a way to really debug and decompile the firmware right? Or atleast run it in a live environment somehow. Would love if there was some way to maybe bring up a terminal or console of some kind.

Thanks!

Edit:
After reading documentation about eCos and trying everything possible to extract the kernel and lzo compressed data, poking around the uimage header information, trying to understand the uboot images, etc. I truly think it's too hard to accomplish with the limited information available online, along with my limited knowledge. I think the first goal therefore will be to replace the boot image, and then at some point i hopefully will be able to modify more stuff.

Future goals will be to adjust the screen resolution a bit if possible, and modify some of the graphical user interface, as i'd love to modernize it a bit.

Edit2:
Will start working on replacing the boot image  :D I think i'll go the more simple route and just swap the existing VW Logo with the current boot image, like u suggested fzabkar. Will let you know how it goes :)

fzabkar:
If you want to use your own custom image, I would mount the JFFS2 file system in Linux, rename 0.bin to w.bin, say, copy your new image to 0.bin in the root directory, and then overwrite the original JJFS2 file system with your modified file system.

As for DMDE, it is designed to work with storage devices where files are aligned to sector boundaries. You can specify custom file types with non-zero offsets, though.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version