Updated 19.04.2019.

Well known that Russia is a land of car dashcams. :) So we have plenty of them here. And sometimes they breaks for some reason. This time we have bricked Mio MiVue 518 dashcam whose was incidentally "upgraded" by SD_CarDV.bin firmware from a different model. Since dashcam software doesn't care about is that firmware suitable for this device model or not, the device is ultimately bricked after flashing.

To unbrick device we should unsolder internal flash memory and write appropriate firmware dump to it. But at first, flash memory dump should be extracted from firmware upgrade file SD_CarDV.bin.

Opening of SD_CarDV.bin in file viewer makes clear that file format should be simple - firmware internal strings are readable so data is uncompressed. We only need to find where is end of header and start of dump data. This time we will use Linux command-line utility cmp to get byte-to-byte comparison of firmware upgrade files for two different dashcam models of same vendor:

$ cmp -l -n 1024 SD_CarDV.bin SD_CarDV.bin.568 
   9 115   0
  10 111   0
  11 117   0
  12 105   0
  13  67   0
  14  61   0
  15  65   0
  16  70   0
  17 345 336
  18 332 236
  19  40  74
  20  22 372
  21 355 323
  22 313 326
  23 317 312
  24 251 260
  25 142 317
  26 314 172
  27 132 102
  28 373 340
  29 142 303
  30 110 333
  31 173 326
  32 305  57

We could see that only first 32 bytes are different in first 1 kB of upgrade file (cmp command output enumerates bytes from 1). Looks like these 32 bytes are related to header, so let's strip it using dd command:

dd bs=32 skip=1 if=SD_CarDV.bin of=SD_CarDV.rom

Let's look to first 128 bytes of result using hex viewer:

$ xxd -l 128 -c 16 -g 1 SD_CarDV.rom 
0000000: 06 00 00 ea fe ff ff ea fe ff ff ea fe ff ff ea  ................
0000010: fe ff ff ea fe ff ff ea 20 ff 1f e5 fe ff ff ea  ........ .......
0000020: d3 f0 21 e3 b0 10 9f e5 01 d0 a0 e1 d2 f0 21 e3  ..!...........!.
0000030: a8 10 9f e5 01 d0 a0 e1 d1 f0 21 e3 a0 10 9f e5  ..........!.....
0000040: 01 d0 a0 e1 d7 f0 21 e3 98 10 9f e5 01 d0 a0 e1  ......!.........
0000050: db f0 21 e3 90 10 9f e5 01 d0 a0 e1 df f0 21 e3  ..!...........!.
0000060: 88 10 9f e5 01 d0 a0 e1 d3 f0 21 e3 80 0a a0 e3  ..........!.....
0000070: 11 1f 19 ee 00 10 81 e1 01 10 81 e3 11 1f 09 ee  ................

We could check the result by disassembling first bytes of dump data. This device is AIT8427-based, but vendor site doesn't provide any info about CPU architecture except it's "Embedded 32-bit CPU / 500MHz". But we could quickly try some popular architectures using ODA Online Disassembler:

Disassembled dump start data

Aha, it's ARM and first instruction is unconditional jump to initialization routine. Well, we got firmware dump for writing to internal flash, so it's time to unsolder flash memory chip:

W25Q64FV flash chip position on device board

Flash memory chip is marked with red, it's W25Q64FV with SPI interface, 64Mb size (8MB). We need SPI programmer to write firmware dump, but instead I used Raspberry Pi SBC with SPI interface available on its 26-pin header. This configuration is supported by well-known FlashRom utility. Only we need before writing is truncate dump length to flash memory size:

$ truncate --size 8M SD_CarDV.rom

Now connect flash memory chip to Raspberry Pi and start programming:

sudo ./flashrom -w SD_CarDV.rom -p linux_spi:dev=/dev/spidev0.0

Flash memory will be erased, written and verified. Now we should solder flash memory chip back to dashcam's PCB, power on device and check - it's working! :)

Updated 19.04.2019

For some (new) Mio dashcams (like MiVue 733) the firmware file looks slightly different. Startup sequence 06 00 00 ea fe ff... is placed at 0x2020, and at 0x20 we have something like this:

$ xxd -l 64 -c 16 -g 1 SD_CarDV.bin
00000000: 41 49 54 53 30 30 33 31 32 44 2e 31 31 34 33 20  AITS00312D.1143 
00000010: ac ae 2f d1 48 c8 d1 70 05 17 cd d2 24 da ef 3d  ../.H..p....$..=
00000020: 4d 43 52 32 01 00 00 40 0c 00 00 00 09 00 00 00  MCR2...@........
00000030: 02 00 00 00 64 6c 00 00 00 e0 11 00 01 00 00 00  ....dl..........

Despite it, a flash dump extraction steps remain the same - we just cut the first 32 bytes and flash the rest aligned to flash size. This difference probably caused by some changes in dashcam startup sequence with initial jump changed to 0x2000 instead of 0x0000.