Well known that Russia is land of dashcams. :) So we have there many of them. And sometimes they are die for some reason. This time we have bricked Mio MiVue 518 dashcam. This device is upgraded by throwing SD_CarDV.bin file downloaded from vendor site to SD card root, but dashcam software isn't verifying is that file related to this device model or not, so you could get SD_CarDV.bin file from other MiVue dashcam (say, MiVue 568) which doesn't fit and device will be ultimately bricked.

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! :)