DVR in the car thing necessary and extremely useful, especially if the driver is inclined to drive by the rules. One of the best in terms of price / quality ratio is the F500 line and their older brother Karkam Q2. Here 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 modify it a bit - to give personality. This idea appeared in the context of the registrar as a gift. The task of the minimum was to replace the starting and final splash screen with something different. This task was successfully solved, but there was still room for creative searches.
For those who are not interested in reading technical details -
source code and
binaries are posted on GitHub (need .Net 4.0)
Start
These links are the starting point for studying the firmware structure:
pixeldoc.kicks-ass.net/projects/goprohdhero/firmware/v02.05.11goprouser.freeforums.org/search.php?author_id=4914&sr=postschdk.setepontos.com/index.php?topic=5890.0As well as the ability of the registrar to independently make a backup copy of their firmware in whole and in parts.
After looking in the hex editor the contents of the received files, comparing with the output of the recorder in UART, it became clear how this firmware is arranged.
Firmware structure
Registrar firmware consists of 5 sections (their exact purpose is unknown):
[Bst] [Bld] [Pri] [Rom] [Dsp]
In the Rom section are the resources of the registrar - it represents for us the maximum interest.
')
The firmware file has the following structure:
[Bst] [Bld] [Pri] [Rom] [Dsp]
The file header is described by the following structure:
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 of section, 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 assignment data is unknown, 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 byte alignment) using the trivial
algorithm itself .
ImgLen - the actual length of the data section.
Rom Section
The Rom section stores registrar resources organized into the simplest file system.
Data section Rom has the following format:
Rom { } { }
Heading rom
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; }
Replacing resources
To replace resources in the registrar it is convenient to use the fact that the registrar is able to separately flash a file containing only one section. Therefore, we will generate a file containing only the Rom section. For this:
1. Modify the FileHeader, leaving only the Rom section there
2. Repackage Rom aligning the beginning of each file to 0x800. The number and name of the files must be left original.
3. Recalculate the checksum in the section header.
4. Write all this in the output file.
The result was such a program line:
github.com/magnitudo/F500Tool .
What's next?
In the section Rom there are files:
bitmaps.bin
fonts.bin
By name it is clear that they are stored. The format has not yet been sorted out.
Any help?