Official Firmware Update
There's an official firmware update available which updates version 184.108.40.206 to 220.127.116.11, and you need to fill in your serial number at the official Canon download site. Where and how to get the firmware and a serial number: 
Another update for version 18.104.22.168 
The update file is encrypted with a 0x1040 XOR key, derived from 300D still camera keys. Search for the decoder in the above topic.
The key calculation works as follows, where key1 is the 512byte 300D key, and key2 is the 513byte 300D key:
do decode 64 bytes, begin with key1[ 0] and key2[ 0] decode 1 bytes, begin with key1[ 0] and key2 decode 63 bytes, begin with key1[ 1] and key2[ 0] decode 2 bytes, begin with key1[ 0] and key2 decode 62 bytes, begin with key1[ 2] and key2[ 0] decode 3 bytes, begin with key1[ 0] and key2 decode 61 bytes, begin with key1[ 3] and key2[ 0] decode 4 bytes, begin with key1[ 0] and key2 . . . decode 2 bytes, begin with key1 and key2[ 0] decode 63 bytes, begin with key1[ 0] and key2[ 2] decode 1 bytes, begin with key1 and key2[ 0] decode 64 bytes, begin with key1[ 0] and key2[ 1] while decodedbytes != 0
It uses only the first 64 respectively 65 bytes of the keys, and the resulting key is 4160 bytes long (0x1040).
You can find an universal firmware de-/encrypter here: . It can crypt all known firmware versions (HF10/100 and HV30 automatically recognized), recalculate checksums and optionally split the file into its sections.
Here's general description of the structure of an update file:
|0x10010 unencrypted header|
|0x0||0x10000||originally filled with 0xFF, but can be any data|
|0x10000||0x4||FW version x.x.x.x|
|0x10004||0x4||"VEEX" (must not be changed, gets compared with same string located at 0x4CA4D426)|
|0x10008||0x2||0x0207 (must not be changed)|
|0x1000A||0x6||originally filled with 0x20, but can be any data|
|code & data|
|0x2C unencrypted footer (describes file-sections)|
|0x10000||0x4||uint32 number of sections|
|0x10000||0x4||uint32 size of first section|
|0x10000||0x4||uint32 checksum of first section|
|0x10000||0x4||uint32 size of second section|
|0x10000||0x4||uint32 checksum of second section|
|0x10000||0x4||uint32 size of 3rd section|
|0x10000||0x4||uint32 checksum of 3rd section|
|0x10000||0x4||uint32 size of 4th section|
|0x10000||0x4||uint32 checksum of 4th section|
|0x10000||0x4||uint32 size of 5th section|
|0x10000||0x4||uint32 checksum of 5th section|
The checksum is a simple uint32 sum of all uint32's in the corresponding section.
This update consists of 2 sections.
- 0x0 - 0x200000 First section, including the first unencrypted 0x10010 bytes; MIPS
- 0x200000 - 0x7F7364 Second section
- 0x20 length header for this section. Contains this section size: 0x5f7344 bytes
- >= 0x200020 - ROM&RAM data; M32R
- 0x2C footer
- 8bit monochromatic bitmaps
These bitmaps consist of a 2-byte header containing the bitmap width (first byte) and the width that the bitmaps gets stretched to when displayed. The bitmaps are always 18 pixels high and aligned to 4 bytes. All fonts are included as well.
- 0x10608C - 0x14049C
- 0x142CA4 - 0x179A8C
- bitmap lookup table, referenced from m32r code
- 0x5EFC34 - 0x5F3433
- The same bitmaps as before can be found a second time, this time aligned at 2 bytes.
- 0x5F3434 - 0x663C46
- color palette
A color is 32bits long, in the format 0xRRGGBBAA. The mapping between this palette and the bitmaps is unknown, if there even exists one.
- 0x669234 - 0x66A0A0
- Video VBR compression rates 
There are 5 presets, each consisting of 6 2-byte big endian values
- 0x46BCF8 - 0x46BD34
To detect a valid firmware update file, the camera does the following:
At first it looks for this file, in descending order (9 to 1). This file is detected as a firmware file if a valid header exists, and only in this case the firmware update button in the OSD menu gets enabled.
- Version number check
The version number of the firmware update file gets compared to the camera's actual version. You need an increased number to update the camera, else it prints an error message.
- Checksum check
After passing the version number check, the camera takes some seconds to verify the checksum(s). if it succeeds, the firmware gets updated and the camera restarts, else you get the message ""Firm Update Error! Check the card.".
Processor and architecture
The HV10/100 contains 2 processor cores, one of the Renesas M32R family, and a MIPS.
The processor is of M32R family (Mitsubishi, now Renesas) Documentation:
- e32rsm.pdf - Instruction reference
- 32182um.pdf/e32172um.pdf - Chip architecture
The exact processor and peripherial models are unknown, however the code shows that CR5 (EIT Vector Base) register is used - and this register seems to be present only in M32R2 processors.
The M32R section should be loaded at 0x04000000 location. Initialization routine starts up at 0x04000000 (reset interrupt).
The MIPS section seems to be mapped to the address 0xBFA00000.
No clear location for the data section is found yet, but it starts averagely at 0x04306B20, and then moved to the destination location at 0x4C8A6840. This gives all valid string and data references.
No clear understanding yet - most probably a free usage RAM comes after the data (0x4C8A6840 and above)
Many of peripherial IO ports, etc. Some are documented in Renesas PDFs, but they seems not to be the same for our case.
Things to do
- Processor model. No documentation for M32R2 ?
- Bootstrap understanding (some section init/movements should be there)
- TRAP 7/8 usage (system calls?)
- stdlib exploration
- No information on how to detect OS related calls (tasks, sems, etc.)
- Which os (could be not dryos, but MR32R)?