September 17, 2012 at 16:28As I picked the firmware of the F500 dashcam
The DVR in the car is a necessary and extremely useful thing, especially if the driver is inclined to drive according to the rules. One of the best in terms of price / quality ratio is the F500 line and their older brother Karkam Q2. Here there is a big and long topic of discussion of these registrars.
About six months ago, I became the owner of such a device and am very pleased. But I wanted to refine it a bit - to give personality. This idea arose in the context of the registrar as a gift. The task of the minimum was to replace the starting and final screensavers with something of their own. This task was successfully solved, but there was still room for creative search.
For those who are not interested in reading the technical details - source codes and binaries are posted on GitHub(need .Net 4.0)
These links became the starting point for studying the firmware structure:
pixeldoc.kicks-ass.net/projects/goprohdhero/firmware/v02.05.11
goprouser.freeforums.org/search.php?author_id=4914&sr=posts
chdk.setepontos.com/index .php? topic = 5890.0
As well as the registrar’s ability to independently backup his firmware in whole and in part.
Having looked at the contents of the received files in a hex editor, comparing with the output of the recorder in UART, it became clear how this firmware is arranged.
The registrar firmware consists of 5 sections (their exact purpose is unknown): The Rom section contains the registrar resources - it is of maximum interest to us. The firmware file has the following structure: The file header is described by the following structure:
If for any type the Start and End sections are equal to zero, then the registrar considers that this section is not in the file.
In the Const field, the purpose of which is unknown is written, but they are constant for any combination of sections in the firmware file for the current firmware version.
Each section begins with its own title:
The CRC32 field is calculated for the section data (without header and alignment bytes) according to the most trivial algorithm .
ImgLen is the actual length of the section data.
The Rom section stores recorder resources organized in a simple file system.
Rom section data has the following format:
Rom header
The file header has the following structure:
To replace resources in the registrar, it is convenient to use the fact that the registrar can separately flash a file containing only one section. Therefore, we will generate a file containing only the Rom section. To do this:
1. Modify FileHeader, leaving only the Rom section there
2. Repack Rom aligning the beginning of each file with 0x800. The number and file names must be left original.
3. Recalculate the checksum in the section header.
4. Write all this to the output file.
In the end, I got this kind of programina: github.com/magnitudo/F500Tool .
In the Rom section there are files:
bitmaps.bin
fonts.bin
By the names it is clear what is stored in them. The format has so far failed to figure out.
Anyone wanting to help?
About six months ago, I became the owner of such a device and am very pleased. But I wanted to refine it a bit - to give personality. This idea arose in the context of the registrar as a gift. The task of the minimum was to replace the starting and final screensavers with something of their own. This task was successfully solved, but there was still room for creative search.
For those who are not interested in reading the technical details - source codes and binaries are posted on GitHub(need .Net 4.0)
Start
These links became the starting point for studying the firmware structure:
pixeldoc.kicks-ass.net/projects/goprohdhero/firmware/v02.05.11
goprouser.freeforums.org/search.php?author_id=4914&sr=posts
chdk.setepontos.com/index .php? topic = 5890.0
As well as the registrar’s ability to independently backup his firmware in whole and in part.
Having looked at the contents of the received files in a hex editor, comparing with the output of the recorder in UART, it became clear how this firmware is arranged.
Firmware structure
The registrar firmware consists of 5 sections (their exact purpose is unknown): The Rom section contains the registrar resources - it is of maximum interest to us. The firmware file has the following structure: The file header is described by the following structure:
[Bst] [Bld] [Pri] [Rom] [Dsp]
Заголовок файла [Bst] [Bld] [Pri] [Rom] [Dsp] unsafe public struct FileHeader
{
public Int32 BstStart;
public Int32 BstEnd;
public Int32 BldStart;
public Int32 BldEnd;
public UInt64 Empty0;
public Int32 PriStart;
public Int32 PriEnd;
public UInt64 Empty1;
public Int32 RomStart;
public Int32 RomEnd;
public Int32 DspStart;
public Int32 DspEnd;
public UInt32 Magik;
public fixed byte Const[0x19F - 0x03C + 1];
public fixed byte Empty2[0x7FF - 0x1A0 + 1];
}
If for any type the Start and End sections are equal to zero, then the registrar considers that this section is not in the file.
In the Const field, the purpose of which is unknown is written, but they are constant for any combination of sections in the firmware file for the current firmware version.
Each section begins with its own title:
unsafe public struct SectionHeader
{
public UInt32 CRC32;
public UInt32 Version;
public UInt32 Date;
public Int32 ImgLen;
public UInt32 Mem;
public UInt32 Flags;
public UInt32 Magik;
public fixed byte Empty0[0x8FF - 0x81C + 1];
}
The CRC32 field is calculated for the section data (without header and alignment bytes) according to the most trivial algorithm .
ImgLen is the actual length of the section data.
Section Rom
The Rom section stores recorder resources organized in a simple file system.
Rom section data has the following format:
Заголовок Rom {Заголовок файла} {Содержимое файла}Rom header
unsafe public struct RomHeader
{
public Int32 FilesCount;
public Int32 Magik;
public fixed byte Empty0[0x10FF - 0x0908 + 1];
}
The file header has the following structure:
unsafe public struct RomFileHeader
{
public fixed byte FileNameBuf[Const.RomFilenameLength];
public Int32 FileOffset;
public Int32 FileLength;
public UInt32 Magik;
}
Resource replacement
To replace resources in the registrar, it is convenient to use the fact that the registrar can separately flash a file containing only one section. Therefore, we will generate a file containing only the Rom section. To do this:
1. Modify FileHeader, leaving only the Rom section there
2. Repack Rom aligning the beginning of each file with 0x800. The number and file names must be left original.
3. Recalculate the checksum in the section header.
4. Write all this to the output file.
In the end, I got this kind of programina: github.com/magnitudo/F500Tool .
What's next?
In the Rom section there are files:
bitmaps.bin
fonts.bin
By the names it is clear what is stored in them. The format has so far failed to figure out.
Anyone wanting to help?