CHDK Wiki
Don't have an account?
Register
Register
CHDK Wiki
CHDK Wiki
632
pages
in: Camcorders

Changes: HF10/100 Firmware Analysis

Back to page
Sign in to edit
(New page: == Firmware decoding == Where and how to get the firmware and a serial number: http://chdk.setepontos.com/index.php/topic,1641.0.html 0x1040 XOR key, derived from 300D still camera keys...)
 
mNo edit summary
 
(5 intermediate revisions by 4 users not shown)
Line 1: Line 1:
−
== Firmware decoding ==
 +
== Official Firmware Update ==
   
  +
There's an official firmware update available which updates version 1.0.0.0 to 1.0.1.0, 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: [http://chdk.setepontos.com/index.php/topic,1641.0.html]
−
Where and how to get the firmware and a serial number:
  
   
  +
Another update for version 1.0.2.0 [http://web.canon.jp/imaging/dcp/firm-e/hf10/index.html]
−
http://chdk.setepontos.com/index.php/topic,1641.0.html
  
   
  +
=== Encryption ===
⚫
0x1040 XOR key, derived from 300D still camera keys. Search for the decoder in the above topic.
  
   
  ⚫
The update file is encrypted with a 0x1040 XOR key, derived from 300D still camera keys. Search for the decoder in the above topic.
−
== Firmware analysis ==
  
   
  +
The key calculation works as follows, where key1 is the 512byte 300D key, and key2 is the 513byte 300D key:
−
=== Decoded f/w content ===
  
−
The next logical parts are detected for now:
  
⚫
* 0x0 - 0x200000 (including the first unencrypted 0x10010 bytes)
  
−
A kind of data area, some self-references shows that it should be placed at 0xBFA00000 linear address. Probably its a static data (language resources, etc).
  
−
* 0x200000
  
⚫
Simple 0x20 length header for the next. Contains this section size: 0x5f7344 bytes
  
⚫
* 0x200020 - ROM&RAM data.
  
−
* 0x2C sized tail - no understanding of its content yet.
  
   
  +
do
⚫
=== Processor and architecture ===
  
  +
decode 64 bytes, begin with key1[ 0] and key2[ 0]
  +
decode 1 bytes, begin with key1[ 0] and key2[64]
  +
decode 63 bytes, begin with key1[ 1] and key2[ 0]
  +
decode 2 bytes, begin with key1[ 0] and key2[63]
  +
decode 62 bytes, begin with key1[ 2] and key2[ 0]
  +
decode 3 bytes, begin with key1[ 0] and key2[62]
  +
decode 61 bytes, begin with key1[ 3] and key2[ 0]
  +
decode 4 bytes, begin with key1[ 0] and key2[61]
  +
.
  +
.
  +
.
  +
decode 2 bytes, begin with key1[62] and key2[ 0]
  +
decode 63 bytes, begin with key1[ 0] and key2[ 2]
  +
decode 1 bytes, begin with key1[63] 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).
−
The processor is of M32R family (Mitsubishi, now Renesas)
  
  +
  +
You can find an universal firmware de-/encrypter here: [http://chdk.setepontos.com/index.php/topic,1641.msg27029.html#msg27029]. It can crypt all known firmware versions (HF10/100 and HV30 automatically recognized), recalculate checksums and optionally split the file into its sections.
  +
  +
=== File Structure ===
  +
Here's general description of the structure of an update file:
  +
  +
{| border="1" style="border-collapse:collapse;"
  +
|-
  +
!pos
  +
!length
  +
!description
  +
|-
  +
| colspan="3" | ''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
  +
|-
  +
| colspan="3" | ''code & data''
  +
|-
  +
| colspan="3" | ''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.
  +
  +
==== Version 1.0.1.0 ====
  +
  +
This update consists of 2 sections.
  +
  +
===== Content Overview =====
  +
  ⚫
* 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
  +
  +
===== Interesting Addresses =====
  +
  +
* 8bit monochromatic bitmaps<br/>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<br/>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 [http://chdk.setepontos.com/index.php/topic,1641.msg19665.html#msg19665]<br/>There are 5 presets, each consisting of 6 2-byte big endian values
  +
** 0x46BCF8 - 0x46BD34
  +
  +
=== Update Process ===
  +
  +
To detect a valid firmware update file, the camera does the following:
  +
# '''VEE'''[1-9].FIM<br/>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<br/>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<br/>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.
  +
  +
=== M32R ===
  +
The processor is of [http://www.renesas.com/fmwk.jsp?cnt=m32r_family_landing.jsp&fp=/products/mpumcu/m32r_family/ M32R family] (Mitsubishi, now Renesas)
 
Documentation:
  
Documentation:
 
* e32rsm.pdf - Instruction reference
  
* e32rsm.pdf - Instruction reference
Line 29: Line 134:
 
=== Code location ===
  
=== Code location ===
   
−
Code section should be loaded at 0x04000000 location.
 +
The M32R section should be loaded at 0x04000000 location.
 
Initialization routine starts up at 0x04000000 (reset interrupt).
  
Initialization routine starts up at 0x04000000 (reset interrupt).
  +
  +
The MIPS section seems to be mapped to the address 0xBFA00000.
   
 
=== DATA location ===
  
=== DATA location ===
Line 45: Line 152:
   
 
Many of peripherial IO ports, etc. Some are documented in Renesas PDFs, but they seems not to be the same for our case.
  
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 M32R'''2''' ?
  +
* 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)?
  +
[[Category:Camcorders]]

Latest revision as of 17:23, 28 May 2009

Official Firmware Update

There's an official firmware update available which updates version 1.0.0.0 to 1.0.1.0, 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: [1]

Another update for version 1.0.2.0 [2]

Encryption

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[64]
  decode 63 bytes, begin with key1[ 1] and key2[ 0]
  decode  2 bytes, begin with key1[ 0] and key2[63]
  decode 62 bytes, begin with key1[ 2] and key2[ 0]
  decode  3 bytes, begin with key1[ 0] and key2[62]
  decode 61 bytes, begin with key1[ 3] and key2[ 0]
  decode  4 bytes, begin with key1[ 0] and key2[61]
  .
  .
  .
  decode  2 bytes, begin with key1[62] and key2[ 0]
  decode 63 bytes, begin with key1[ 0] and key2[ 2]
  decode  1 bytes, begin with key1[63] 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: [3]. It can crypt all known firmware versions (HF10/100 and HV30 automatically recognized), recalculate checksums and optionally split the file into its sections.

File Structure

Here's general description of the structure of an update file:

pos length description
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.

Version 1.0.1.0

This update consists of 2 sections.

Content Overview
  • 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
Interesting Addresses
  • 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 [4]
    There are 5 presets, each consisting of 6 2-byte big endian values
    • 0x46BCF8 - 0x46BD34

Update Process

To detect a valid firmware update file, the camera does the following:

  1. VEE[1-9].FIM
    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.
  2. 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.
  3. 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.

M32R

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.

Code location

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.

DATA location

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.

RAM location

No clear understanding yet - most probably a free usage RAM comes after the data (0x4C8A6840 and above)

Special locations

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)?
Community content is available under CC-BY-SA unless otherwise noted.