cail
Ok, thanks, I'll try to checkout the same for HV30.
s10sh is very interesting. I've also tried (under win32) and failed to compile it properly. Sources contain a private canon's usb protocol to interact with the camera. Definitely something similar should be available for our camcorders too.
I've discovered similar protocol within Canon's CALIB.DLL (part of f/w update):
ConnectCamera
CreateCameraObject
DestroyCameraObject
DisconnectCamera
And many other service functions, including for example
ComMethod_CancelWaitReceive
ComMethod_FinishReceive
ComMethod_FinishSend
ComMethod_ReceiveData
ComMethod_SendData
ComMethod_StartReceive
ComMethod_StartSend
These could be a serial access - and probably an internal shell is available via this API somehow.
I've managed to connect the camera via CALIB.DLL and readout its properties, however other methods are very difficult to test because of unknown signatures.
Wiesel
that's a great idea! why write it by yourself if canon provides it for free 😀
oh btw. I forgot in my previous answer, yes I discovered the service menue by resource strings. there's a function that enters the service menue and shows the versions of different parts of the fw software and if I remember correctly there's also a switch for different subpages of the menue.
cail
btw, probably this may help you (it helps me greatly) in code analysis:
IDA visual call graph scripts
Soultrape
At the risk of disturbing you guys with the brilliant work you're doing,
I just want you to know that I love you 😀
kmaage
Love is an understatement. I really hope you enjoy this kind of thing, because you're certainly spending hours and hours on it. I would help, if I knew what the heck to do 🙁
It's been exciting simply following the discussion, though. Great job!
mkhozi
Possible location of video compression bitrates (AVCHD VBR) for HF100 / HF10 at offset 0x46BCF8 of decrypted firmware "VEE1-decrypted.FIM.code-4000000" (firmware decrypted using cail's tools)
For firmware decrypted using hf10x.exe (see 5 posts below), the correct offset is 0x66BD18
Page 36 of HF100 / HF10 manual states that the camera uses VBR (variable bitrate)
Bitrates are 2 byte Big-Endian. Example 0x4650 = 18000 Kbps = 18 Mbps
For simplicity, some of the values have been rounded off ...
Rec BitRate XP = 4650 3E80 3E1C 3DB8 36B0 08D0 = 18Mbps, 16Mbps, 15.9Mbps, 15.8Mbps, 14Mbps, 2.2Mbps
Rec BitRate HQ+ = 3584 2EE0 2E7C 2C88 2AF8 0B95 = 13.7 Mbps, 12Mbps, 11.9Mbps, 11.4Mbps, 11Mbps, 3Mbps
Rec BitRate HQ = 3584 2EE0 2E7C 20D0 157C 0B95 = 13.7 Mbps, 12Mbps, 11.9Mbps, 8.4Mbps, 5.5Mbps, 3Mbps
Rec BitRate LP = 3584 2EE0 2454 1A2C 0FA0 0B95 = 13.7 Mbps, 12Mbps, 9.3Mbps, 6.7Mbps, 4Mbps, 3Mbps
Rec BitRate SP = 3584 2EE0 1900 1388 0FA0 0B95 = 13.7 Mbps, 12Mbps, 6.4Mbps, 5Mbps, 4Mbps, 3Mbps
NOTE : As Wiesel pointed out, "A little problem with changing the FW and testing with it is (beside the big risk of bricking the cam) that you can only upgrade the FW if the version number is higher than the current one"
Risky guy (or someone with a broken cam) may try to increase bitrate to 24mbs ...
Best of luck.
Wiesel
mkhozi
Possible location of video compression bitrates (AVCHD VBR) for HF100 / HF10 at offset 0x46BCF8 of decrypted firmware "VEE1-decrypted.FIM.code-4000000" (firmware decrypted using cail's tools, see post 31)
Cool finding, I never noticed that it uses VBR. How did you convert the hex numbers to the mbps numbers?
Btw, HF10/100 only have 4 quality presets: FXP (17Mbps), XP+(12Mbps), SP (7Mbps) & LP (5Mbps). So your numbers are either something else (hopefully not) or the HF10/100 have only 4 out of 5 presets activated. The upcoming HF11 features 5 quality presets adding MXP+ (24Mbps).
edit: ideed, it internally has those 5 presets 😀
Wiesel
Regarding the s10sh utility:
I set up an old debian 3.1 in a virtualbox vm with kernel 2.4 and could successfully compile and run v0.2.4 (btw, the makefile has an error which needs to be corrected to be able to compile).
It successfully connects to the cam but I didn't get a response to any of the control codes I sent :/
edit: I just got a response 😀
Soultrape
Guys - what would be the best cam or potential cams we can get to play with? (Hopefully broken)
Gemme priorities too
cail
For the moment these should be the only units with the f/w available. I.e. HF10/100 and HV30.
Note that firmware for HF and HV are quite different, so these most probably will be two rather separate branches (although with many things shared).
mkhozi
HF100 / HF10 Firmware
Decryptor and
Encryptor based on source code from Wiesel (dhf10.c)
- Very very very slow (you should compile Wiesel's version if you want speed)
- User friendly
- Both GUI and command line ( for command line parameters type hf10x /? )
- Written using Autoit v3 (
http://www.autoitscript.com/autoit3/)
Note : There is no option to omit the unencrypted file header in the GUI (use command line parameters instead)
P.S. GUI has a separate button for Encryption and Decryption to make it more user friendly. The algorithm is actually the same (XOR based) ...
P.S. Using this tool, the possible location of video compression bitrates are located at offset 0x66BD18
mkhozi
Modified firmware version from 1.0.1.0 to 1.0.0.0 at offset 0x10000 then tried to update HF100 camcorder.
Result : not allowed, firmware already up to date ... the exact wording was "updated already version 1.0.1.0"
P.S. "updated already" is located at offset 0x1891E3 and 0x786E35 so there is a good chance the version check function is part of the firmware update file.
Soultrape
P.S. "updated already" is located at offset 0x1891E3 and 0x786E35 so there is a good chance the version check function is part of the firmware update file.
That would be Massive. If so - there's a likely chance that we can bypass the checking function and have an easier life switching firmware Aye?
Wiesel
mkhozi
Modified firmware version from 1.0.1.0 to 1.0.0.0 at offset 0x10000 then tried to update HF100 camcorder.
Result : not allowed, firmware already up to date ... the exact wording was "updated already version 1.0.0.0"
So, you have the 1.0.0.0 firmware on your cam? That's great, you could find out for us how the firmware version is handled. If you change the version info at 0x10000 to 1.0.0.1 your cam will upgrade - and if it then shows 1.0.1.0 as firmware version we know that the actual version number that is used to compare with an eventual firmware upgrade file is stored somewhere else. If it shows 1.0.0.1 after the upgrade, you could just upgrade to the official 1.0.1.0 fw and have an official firmware version - and we know how the fw version info is handled. I can't test that because I already have the 1.0.1.0 fw on my cam. I hope that makes sense?!
Btw, again, can you please tell me how you calculate the Mbps values from the hex values... e.g. how do you get from 0x3E1C to 15.9?
mkhozi
Sorry my bad, made a typo, my camera also has 1.0.1.0 firmware. The message displayed was "updated already version 1.0.1.0" when I inserted the modified firmware (modified firmware version at offset 0x10000 from 1.0.1.0 to 1.0.0.0 using hex edit)
As for the bitrates, please have a look at my original message - it's been edited a couple of days ago...
Page 36 of HF100 / HF10 manual states that the camera uses VBR (variable bitrate)
Bitrates are 2 byte Big-Endian. Example 0x4650 = 18000 Kbps = 18 Mbps
For simplicity, some of the values have been rounded off ...
0x3E1C = 15900 Kbps = 15.9 Mbps
(use windows calculator, change View settings to Scientific, change mode to Hex, type 3E1C, change mode to Dec(imal), divide by 1000, result is bitrate in Mbps)
Wiesel
Omg it's so easy, thanks 😀 I tried all kinds of fixed and floating point representations forgetting about integers 😐:
I'd try upgrading to a bitrate-modified fw if I knew that the version number stays at 1.0.1.0 even if the fw file header gets modified.
Is there no one with a 1.0.0.0 cam who wants to find out for us how the version number is stored? I'm pretty sure it won't do any harm to the cam.
cail
Wiesel, is my understanding correct, that even if you manually change version f.e. to 1.0.2.0 - your cam still says "firmware already upgraded?", so you can't reload it?
Or, you just don't want to hijack it to 1.0.2.0 to avoid potential warranty breakage?
Wiesel
cail
Wiesel, is my understanding correct, that even if you manually change version f.e. to 1.0.2.0 - your cam still says "firmware already upgraded?", so you can't reload it?
Or, you just don't want to hijack it to 1.0.2.0 to avoid potential warranty breakage?
Yes I don't want to void my warranty.
If your want to update with a firmware that is less or equal to the version that you currently have, it says "already upgraded" or something like that. If the version if the update file is higher (manual change), then it asks if I really want to upgrade VX.X.X.X to VY.Y.Y.Y which I have to confirm. I never confirmed it so actually I don't know if it really upgrades but it seems so.
Soultrape
If your want to update with a firmware that is less or equal to the version that you currently have, it says "already upgraded" or something like that. If the version if the update file is higher (manual change), then it asks if I really want to upgrade VX.X.X.X to VY.Y.Y.Y which I have to confirm. I never confirmed it so actually I don't know if it really upgrades but it seems so.
If this is true, it means we can test infinite # of firmware updates yes? with every new test, crank up the firmware #, and update.
We need a HF100 to test ey? I'll try to push the forum guys to have us get a used one from eBay, it doesn't seem finding broken units is easy.
Wiesel
Soultrape
If this is true, it means we can test infinite # of firmware updates yes? with every new test, crank up the firmware #, and update.
Not infinite but yes, it would be like that (256^4 minus a few hundred). Still I'd like to avoid increasing the fw number with every try... I'm not sure if the warranty will still be valid if you send in a broken cam with firmware version 3.65.9.238 😉
That's why it would be cool if someone with a 1.0.0.0 cam could test it (no Japanese users here?). If it shows the modified version number after the upgrade (e.g. 1.0.0.1) and not the real one, he could still upgrade to 1.0.1.0 and have an "official number" and wouldn't loose anything by this test.
