HDD GURU FORUMS

Hi all, I have a car stereo that I am trying to hack into. The stereo has a NAND flash chip (Winbond w25q128jvsiq) and a CPU (Allwinner_F1C200s). I extracted the contents of the flash chip into a .bin file and am now trying to view the files and directory stored on this chip but am having trouble doing so. I tried running binwalk and decompressing the files but can't seem to get anything recognizable. I uploaded the entropy graph along with .bin file in a google doc (https://drive.google.com/drive/folders/ ... sp=sharing). Does anyone have any suggestions?

I hope I've come to the right place. Any help would be greatly appreciated.

If you open your BIN as an image in DMDE, DMDE finds two small FAT16 partitions at the end.

If you examine the BIN with a hex editor, there are several references to MINFS. That appears to be the file system.

I suspect that these are the superblocks:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00024400  4D 49 4E 46 53 00 00 01 00 02 00 00 80 01 00 00  MINFS.......€...
00024410  9B 00 00 00 C4 40 00 00 A8 59 7A 00 00 BC 7B 00
                                              ^^^^^^^^^^^
                                              size of FS = 0x7BBC00 ???

00024420  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
........
000245F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0004DB50  4D 49 4E 46 53 00 00 01 00 02 00 00 14 01 00 00  MINFS...........
0004DB60  11 00 00 00 B8 07 00 00 24 D2 01 00 00 70 03 00
                                              ^^^^^^^^^^^
                                              size of FS = 0x37000 ???

0004DB70  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
........
0004DD40  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The second FS appears to be contained wholly within the first.


This site talks about MinFS and Zircon:

https://fuchsia.dev/fuchsia-src/concepts/filesystems/minfs
https://fuchsia.dev/fuchsia-src/concepts/kernel/zx_and_lk

Some info about mounting MINFS here:

https://linux-kernel-labs.github.io/refs/heads/master/labs/filesystems_part1.html

I extracted the large MINFS volume at offset 0x24400 with a size of 0x7BBC00 bytes.

This appears to be the root directory:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000200  80 03 00 00 00 02 00 00 00 00 00 00 18 00 01 00  €...............
00000210  04 00 00 00 61 70 70 73 00 44 00 00 00 00 00 00  ....apps.D......
00000220  00 00 00 00 24 00 00 00 0E 00 00 00 61 70 70 5F  ....$.......app_
00000230  63 6F 6E 66 69 67 2E 62 69 6E 00 00 00 44 00 00  config.bin...D..
00000240  1E 00 00 00 1E 00 00 00 24 00 00 00 0E 00 00 00  ........$.......
00000250  61 70 70 5F 63 6F 6E 66 69 67 2E 66 65 78 00 00  app_config.fex..
00000260  A4 05 00 00 40 05 00 00 00 00 00 00 18 00 01 00  ¤...@...........
00000270  03 00 00 00 63 61 70 00 20 44 00 00 FE 03 00 00  ....cap. D..þ...
00000280  FE 03 00 00 20 00 00 00 0A 00 00 00 44 65 6C 53  þ... .......DelS
00000290  76 6E 2E 62 61 74 00 00 E4 0A 00 00 68 09 00 00  vn.bat..ä...h...
000002A0  00 00 00 00 18 00 01 00 03 00 00 00 64 72 76 00  ............drv.
000002B0  20 48 00 00 4A 44 02 00 B0 40 07 00 1C 00 04 00   H..JD..°@......
000002C0  08 00 00 00 65 70 6F 73 2E 69 6D 67 4C 14 00 00  ....epos.imgL...
000002D0  F8 03 00 00 00 00 00 00 18 00 01 00 03 00 00 00  ø...............
000002E0  6D 6F 64 00 6C 8C 02 00 E4 0A 00 00 E4 0A 00 00  mod.lŒ..ä...ä...
000002F0  20 00 00 00 0B 00 00 00 70 77 6D 5F 63 66 67 2E   .......pwm_cfg.
00000300  69 6E 69 00 50 97 02 00 00 70 03 00 00 70 03 00  ini.P—...p...p..
00000310  20 00 00 00 0B 00 00 00 72 61 6D 64 69 73 6B 2E   .......ramdisk.
00000320  69 73 6F 00 F4 40 00 00 54 00 00 00 00 00 00 00  iso.ô@..T.......
00000330  18 00 01 00 03 00 00 00 72 65 73 00 50 07 06 00  ........res.P...
00000340  FA 00 00 00 FA 00 00 00 24 00 00 00 0E 00 00 00  ú...ú...$.......
00000350  72 6F 6F 74 66 73 5F 69 6E 69 2E 74 6D 70 00 00  rootfs_ini.tmp..
00000360  4C 08 06 00 EC 2A 00 00 EC 2A 00 00 20 00 00 00  L...ì*..ì*.. ...
00000370  0B 00 00 00 73 74 61 6E 64 62 79 2E 62 69 6E 00  ....standby.bin.
00000380  38 33 06 00 44 51 03 00 88 0F 0F 00 A0 00 06 00  83..DQ..ˆ... ...
00000390  0C 00 80 00 61 70 70 5F 72 6F 6F 74 2E 61 78 66  ..€.app_root.axf
000003A0  00 00 00 00 09 3B 03 00 E4 12 0B 00 E4 12 0B 00  .....;..ä...ä...
000003B0  00 00 00 00 01 00 00 00 06 00 00 00 02 00 00 00  ................
000003C0  0C 3B 03 00 01 16 00 00 40 93 00 00 40 93 00 00  .;......@“..@“..
000003D0  E4 12 0B 00 01 00 00 00 03 00 00 00 02 00 00 00  ä...............
000003E0  00 00 00 00 00 00 00 00 00 00 00 00 64 92 01 00  ............d’..
000003F0  24 A6 0B 00 08 00 00 00 03 00 00 00 00 00 00 00  $¦..............

This appears to be the directory entry for a file named "ramdisk.iso":

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000300              50 97 02 00 00 70 03 00 00 70 03 00      P—...p...p..
                      ^^^^^^^^^^^ -----------
         byte offset in volume      file size in bytes

00000310  20 00 00 00 0B 00 00 00 72 61 6D 64 69 73 6B 2E   .......ramdisk.
                                  +++++++++++++++++++++++
                              file name terminated in ...
00000320  69 73 6F 00                                      iso.
          +++++++++++
      ... 1 or 2 zeros (even number of bytes)

This particular file has a size of 0x37000 bytes and is located at offset 0x29750 in the MINFS volume.

This is in fact the second, smaller MINFS volume found earlier. Therefore this ramdisk ISO file is a MINFS image.

what is the purpose of the hack.. to enable reversing camera/VIM more how you want or something else?
Ive helped do it on Commodore, you may have luck on one of the car forums. They get pretty deep in the weeds as well. From memory it was some memory locations to HEX edit, plus fix some checksums.

fzabkar wrote:Some info about mounting MINFS here:

https://linux-kernel-labs.github.io/refs/heads/master/labs/filesystems_part1.html

Thanks so much for all your help fzabkar! I am reading up about MINFS with hopes of mounting and viewing the file system.

HaQue wrote:what is the purpose of the hack.. to enable reversing camera/VIM more how you want or something else?
Ive helped do it on Commodore, you may have luck on one of the car forums. They get pretty deep in the weeds as well. From memory it was some memory locations to HEX edit, plus fix some checksums.

I am trying to change the bootup logo. The stereo is a cheap aftermarket one, so there isn't a lot of support on how to do this online (like there is for Android). I may be trying to go about this wrong but I thought the original image would be in the filesystem and that I could replace it through there.

There is also a USB port on the stereo but I decided to try to extract the contents from the flash memory chip instead.

I think this is a more accurate description of the directory structure:

Code:

Offset(h) 00       04       08       0C

00000300           50970200 00700300 00700300
                   ^^^^^^^^ --------
     byte offset in volume   file size in bytes

00000310  20000000 0B000000 72616D64 69736B2E   .......ramdisk.
                   ######## +++++++++++++++++
number of chars in filename  filename padded with zeros

00000320  69736F00                             iso.
          ++++++++

The minimum storage unit appears to be a dword rather than a sector or a cluster.

I can't find any bitmap, so I'm wondering how the file system keeps track of free and used space. I'm also wondering whether the absence (?) of a bitmap would imply that files need to be contiguous.

This is the structure of the header in the superblock:

https://git.hackfront.eu/Hackfront/minfs-fuse/src/branch/master/src/minfs.h

Code:

typedef struct {
  char magic[6];
  minfs_short_t version;
  minfs_long_t  tree_offset;
  minfs_long_t  root_size;
  minfs_long_t  tree_entries;
  minfs_long_t  tree_size;
  minfs_long_t  fdata_length;
  minfs_long_t  image_size;
} minfs_header_t;

The "tree" appears to be the root directory.

I used 7-Zip to examine the dump and it was able to find one compressed file (bin_arm64-v8a_hsncap) and extract it.

I can see references to Android R15C and Minicap in the decompressed file.

The two FAT 16 partitions are identical and contain 4 files (attached).

inquiringfornathan wrote:

HaQue wrote:what is the purpose of the hack.. to enable reversing camera/VIM more how you want or something else?
Ive helped do it on Commodore, you may have luck on one of the car forums. They get pretty deep in the weeds as well. From memory it was some memory locations to HEX edit, plus fix some checksums.

I am trying to change the bootup logo. The stereo is a cheap aftermarket one, so there isn't a lot of support on how to do this online (like there is for Android). I may be trying to go about this wrong but I thought the original image would be in the filesystem and that I could replace it through there.

There is also a USB port on the stereo but I decided to try to extract the contents from the flash memory chip instead.

Interesting.

I see here it is a thing people want to do: https://forum.xda-developers.com/t/guide-change-boot-logo.3454946/

If you are able, for some context and possible info to help further, could you post the model of stereo, and any pictures of internals, current boot logo etc please?

I am writing a tool to extract the directory tree from the MINFS volume. It's about 80% done.

I have attached a selection of logo files which are compressed BMPs. Unfortunately I don't know how to open them or decompress them.

The headers all appear to have these bytes in common:

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 00 21 13  AZ106p..........
00000010  42 C5 4E FD 90 30 0E 27 E2 97 71 F6 AA 67 F9 C1
00000020  86 B1 81 6F AD F0 5C 1B E3

AFAICT, MINFS is a read-only file system, so there would be no point trying to write a new logo file to the flash via a UART port.

The epos.img file appears to be compressed using the same algorithm as the BMPs. There is something familiar about the 0x5D 0x00 header (Lempel Ziv?).

Code:

Offset(h) 00   02   04   06   08   0A   0C   0E

00000000  5D00 8000 0000 7183 BC0E 2073 F270 635A

I have extracted all the files.

MINFS_00 contains the files/folders extracted from the MINFS volume at offset 0x24400, size 0x7BBC0.

MINFS_01 contains the files/folders extracted from MINFS image in the ramdisk.iso file.

I'm still working on my program, but here is my current working version:

http://www.users.on.net/~fzabkar/FreeBasic_W32/Utils/extminfs.exe
http://www.users.on.net/~fzabkar/FreeBasic_W32/Utils/extminfs.bas

This is the file list:

Code:

\apps
\app_config.fex
\cap
\DelSvn.bat
\drv
\epos.img
\mod
\pwm_cfg.ini
\ramdisk.iso
\res
\rootfs_ini.tmp
\standby.bin
\apps\app_root.axf
\apps\bg_default0.bgd
\apps\bg_default1.bgd
\apps\bg_default2.bgd
\apps\desktop
\apps\init.axf
\apps\lang.bin
\apps\theme.bin
\apps\desktop\app_root.desktop
\cap\bin_arm64-v8a_hsncap.ggg
\cap\bin_arm64-v8a_hsnth.ggg
\cap\bin_arm64-v8a_info_ex.ggg
\cap\bin_armeabi-v7a_hsncap.ggg
\cap\bin_armeabi-v7a_hsnth.ggg
\cap\bin_armeabi-v7a_info_ex.ggg
\cap\hk.ggg
\cap\hsrt.ggg
\cap\lib_16_armeabi-v7a_cap.so.ggg
\cap\lib_17_armeabi-v7a_cap.so.ggg
\cap\lib_18_armeabi-v7a_cap.so.ggg
\cap\lib_19_armeabi-v7a_cap.so.ggg
\cap\lib_21_arm64-v8a_cap.so.ggg
\cap\lib_21_armeabi-v7a_cap.so.ggg
\cap\lib_22_arm64-v8a_cap.so.ggg
\cap\lib_22_armeabi-v7a_cap.so.ggg
\cap\lib_23_arm64-v8a_cap.so.ggg
\cap\lib_23_armeabi-v7a_cap.so.ggg
\cap\lib_24_arm64-v8a_cap.so.ggg
\cap\lib_24_armeabi-v7a_cap.so.ggg
\cap\lib_25_arm64-v8a_cap.so.ggg
\cap\lib_25_armeabi-v7a_cap.so.ggg
\cap\lib_26_arm64-v8a_cap.so.ggg
\cap\lib_26_armeabi-v7a_cap.so.ggg
\cap\lib_27_arm64-v8a_cap.so.ggg
\cap\lib_27_armeabi-v7a_cap.so.ggg
\cap\lib_28_arm64-v8a_cap.so.ggg
\cap\lib_28_armeabi-v7a_cap.so.ggg
\drv\audio.drv
\drv\AuxDevice.drv
\drv\csi.drv
\drv\fm473x.drv
\drv\fm8035.drv
\drv\key.drv
\drv\keyic.drv
\drv\mcu.drv
\drv\monitor.drv
\drv\sdmmc.drv
\drv\touchpanel_ctp.drv
\drv\touchpanel_rtp.drv
\drv\uart.drv
\drv\usbd_msc.drv
\drv\usb_host0.drv
\mod\cedar
\mod\cedar.mod
\mod\charset.bin
\mod\charset.mod
\mod\desktop.mod
\mod\ginkgo.mod
\mod\orange.mod
\mod\update.mod
\mod\willow
\mod\cedar\adec_aac.drv
\mod\cedar\adec_ac3.drv
\mod\cedar\adec_alac.drv
\mod\cedar\adec_ape.drv
\mod\cedar\adec_cok.drv
\mod\cedar\adec_com.plg
\mod\cedar\adec_dts.drv
\mod\cedar\adec_flc.drv
\mod\cedar\adec_mid.drv
\mod\cedar\adec_mp3.drv
\mod\cedar\adec_ogg.drv
\mod\cedar\adec_pcm.drv
\mod\cedar\adec_ra.drv
\mod\cedar\adec_spr.drv
\mod\cedar\adec_wma.drv
\mod\cedar\adec_xxa3.drv
\mod\cedar\adec_xxaa.drv
\mod\cedar\adec_xxam.drv
\mod\cedar\adec_xxas.drv
\mod\cedar\aenc.plg
\mod\cedar\aenc_mp3.drv
\mod\cedar\aenc_pcm.drv
\mod\cedar\aenc_wma.drv
\mod\cedar\aenc_xxam.drv
\mod\cedar\aply.plg
\mod\cedar\araw_ac3.drv
\mod\cedar\araw_dts.drv
\mod\cedar\ardr_sw.plg
\mod\cedar\arec.plg
\mod\cedar\avs.drv
\mod\cedar\cedar.ini
\mod\cedar\cedar.ini.bak
\mod\cedar\ldec_itx.plg
\mod\cedar\ldec_lrc.plg
\mod\cedar\ldec_smi.plg
\mod\cedar\ldec_srt.plg
\mod\cedar\ldec_ssa.plg
\mod\cedar\ldec_sub.plg
\mod\cedar\ldec_txt.plg
\mod\cedar\muxer.plg
\mod\cedar\psr_asf.plg
\mod\cedar\psr_audio.plg
\mod\cedar\psr_avi.plg
\mod\cedar\psr_dev.plg
\mod\cedar\psr_flv.plg
\mod\cedar\psr_mkv.plg
\mod\cedar\psr_mov.plg
\mod\cedar\psr_mpg.plg
\mod\cedar\psr_pmp.plg
\mod\cedar\psr_rm.plg
\mod\cedar\psr_ts.plg
\mod\cedar\psr_video.plg
\mod\cedar\psr_xxvb.plg
\mod\cedar\vcoder.plg
\mod\cedar\vdecoder.drv
\mod\cedar\vdec_com.plg
\mod\cedar\vply.plg
\mod\willow\pdec_bmp.plg
\mod\willow\pdec_gif.plg
\mod\willow\pdec_jpg.plg
\mod\willow\pdec_png.plg
\mod\willow\pshow.plg
\mod\willow\psr_bmp.plg
\mod\willow\psr_gif.plg
\mod\willow\psr_jpg.plg
\mod\willow\psr_png.plg
\mod\willow\willow.mod
\res\boot_ui
\res\fonts
\res\sounds
\res\boot_ui\logo.bmp
\res\boot_ui\logo_fute.bmp
\res\boot_ui\logo_honda.bmp
\res\boot_ui\logo_hyundai.bmp
\res\boot_ui\logo_kia.bmp
\res\boot_ui\logo_nissan.bmp
\res\boot_ui\logo_suzuki.bmp
\res\boot_ui\logo_toyota.bmp
\res\boot_ui\logo_volkswagen.bmp
\res\fonts\font19jp.sft
\res\sounds\chord.wav

All the .ggg files can be decompressed with 7-Zip.

The structure of each directory entry appears to be as follows:

Code:

Type MinfsDir Field = 1
   
    dwFileOffset As ULong                   ' byte offset to file or subdirectory
    dwFileSize As ULong                     ' file/subdir size in bytes
    dwSize2 As ULong                        ' unknown file size parameter (= 0 if subdir)
    wdEntryLen As UShort                    ' length of directory entry including name and block following file/subdir name
    wdAttribs As UShort                     ' file/subdir attributes
    wdFilNamLen As UShort                   ' length of file/subdir name in bytes
    wdBlockLen As UShort                    ' length of block following file/subdir name (usually 0x0080 bytes)

End Type

Code:

  offset  filesize     size2  dlen  attr  lnam  lblk
--------  --------  --------  ----  ----  ----  ----
     380       200         0    18  0001     4     0  \apps
   63338     35144     F0F88    A0  0006     C    80  \apps\app_root.axf
   9847C     11568     11568    24  0000     F     0  \apps\bg_default0.bgd
   A99E4       11C       11C    24  0000     F     0  \apps\bg_default1.bgd
   A9B00      B646      B646    24  0000     F     0  \apps\bg_default2.bgd
     580        24         0    1C  0001     7     0  \apps\desktop
  22FC08        7E        7E    24  0000    10     0  \apps\desktop\app_root.desktop
   B5148      6DC8     1D8D4    9C  0006     8    80  \apps\init.axf
   BBF10     12848     12848    1C  0000     8     0  \apps\lang.bin
........

I have updated my program accordingly.

Pretty awesome Frank. Didn't we see someone else recently in reddit data recovery group with MINFS file system ..

I remember you helping me with a HPFS tree extraction, but I don't recall being involved in a MINFS thread. :-?

Nice work there Franc, The listings remind me of something I looked at a while ago, I will have to try and find what is was. I have a feeling it was an OS on a CF card, and to modify any config we had to mount filesystem read/write first or something like that.

AFAICS, the OP needs to decompress the BMP files before any progress can be made. I can see a reference to LZMA in the code.

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000134D0  FC 81 BD E8 00 00 A0 E3 FC FF FF EA 6C 7A 6D 61  ü.½è.. ãüÿÿêlzma
000134E0  20 75 6E 63 6F 6D 70 72 65 73 73 20 64 61 74 61   uncompress data
000134F0  20 66 61 69 6C 65 64 0A 00 00 00 00 10 40 2D E9   failed......@-é