lunaticlabs
As an additional test, I found another area that I thought might have the version number in it again at offset 0x17bd0c. I checked the firmware update to v 1.0.2.0, and it had a similar occurance of 1.0.2.0 at a similar location (not quite the same, but same general area, with the same strings in near proximity). I tried changing that on my firmware from 1.0.1.0 to 1.0.1.1 to match what I had in my header area at 0x10000, but it did not make any difference. I had the same results/error in the end.
cail
lunaticlabs
The first firmware that was posted only changed the version number, and that version number is outside any of the sections described in the footer that we understand so far.
Thats not quite true. See, here is an unencrypted footer for HF10:
0000000000: 00 00 00 02 00 20 00 00 ? B6 7B 5C 3C 00 5F 73 64
0000000010: 64 58 2D F2 00 00 00 00 ? 00 00 00 00 00 00 00 00
0000000020: 00 00 00 00 00 00 00 00 ? 00 00 00 00
My previous guess was that it shows the sections in firmware file, which are used by the flasher to reflash the unit.
Here we have two sections, 0x200000 size and 0x5F7364 size, total size = sizeof(VEE1.FIM)-sizeof(footer).
This kind of prooves that the version number is located inside of the checksummed area.
Another version number you've found could be some kind of internal variable or static data - just a guess.
The best try IMHO is to try increment/decrement changed values accordingly, as Xcelerate suggested.
Wiesel
cail
Its good to hear we have volunteers with hardware not afraid of experimenting.
Yes that's indeed great 😀 Now it seems it's time for some trial and error...
cail
Regarding the checksum - the easiest try we can make is to check if this is some kind of trivial ADD/XOR checksum.
I think I already tried both and it didn't work out. But there are so many ways of making such a primitive "checksum" a little bit more complicated (additional adds, subs, shifts,...), and then think about "real" checksum algorithms...
cail
Wiesel, since you increasing version number by one - just try to fix the checksum field also by +1. You may also try to increase it by 0x0100, 0x010000, 0x01000000 - to check possible byte offsets.
That is just a guess - at least we are safe trying it.
Good idea, I was thinking the same already.
Xcelerate
I saw something that Napalm did-- changing two different bytes in opposite directions. For example, change the string "firmware" to "firmwbqe". For the camera he was analyzing, its checksum was not altered by incrementing one byte and decrementing the byte next to it, so if someone wants to see if the camera will allow an update with this modification, then it could give a clue as to what kind of checksum is being used.
Another good idea!
cail
My previous guess was that it shows the sections in firmware file, which are used by the flasher to reflash the unit.
Here we have two sections, 0x200000 size and 0x5F7364 size, total size = sizeof(VEE1.FIM)-sizeof(footer).
This kind of prooves that the version number is located inside of the checksummed area.
I'm sure that cails guess is right. IMO the unknown number can only be an address which tells the flasher where to write the data to (which we already know that it isn't) or a checksum. I cannot think of any other purposes such a number might have.
Btw I could post direct download links from canon for both 1.0.1.0 and 1.0.2.0, but I don't know if it's legitimate!?
PhyrePhoX
do it in PM then 😀
Wiesel
Alright, if anybody needs them, you know what to do 🧑🎄
lunaticlabs
Darn, that's what I get for staring at this all day. I figured they were offsets, and not lengths, so I drew some bad conclusions because of that. I'm going to try various checksum/CRC algorithms and see what I come up with.
Jollyrogerxp
Just a quick note... from my small analysis of the first 0x200000 byes of the HV30 FW file, the self references to the address range in 0xBFA00000 combined with some patterns I think I "see" in the data suggest me that it is part MIPS code and part data, I will try to disassemble it with IDA mips big-endian settings and see what it looks like. Perhaps MIPS16, perhaps MIPS32, or perhaps I am just wrong. 😉
If I am not wrong it could be that the same 0x200000 bytes in the HF10 FW are also MIPS + data, let's see!
Jollyroger
Jollyrogerxp
Ah, also from my small analysis on the CALIB.dll and the USB trace it looks like pretty much all the exported functions contained in the CALIB are more or less wrappers on the PTP protocol.
CALIB uses COM to create instances of the WIA driver and use PTP commands to communicate to the camera.
One interesting point is that when the camera reports the list of available PTP commands (which seems to be located at D89E8 in the dump) contains many Canon PTP extension commands, some of which are known in the PTP digital camera community, while others are unknown... another place to start?
Cheers,
Jollyroger
heron88
Noobie question, but how do I see the actual firmware code? I cant decrypt until I see the code that has to be decrypted. Is VEF1.FIM as seen in text edit on mac the actual firmware coding?
If so, how do I run the provided decrypters against vef1.fim on Mac OS X? Im using xcode, how do I run the decrypter?
Jollyrogerxp
Ok some more news, from a first inspection it looks like the first segment is indeed MIPS32 code, it looks like camera has a MIPS32 core somewhere to handle the USB communication and other utilities.
*** I think *** I found some parts of the code that implements the PTP protocol on the HV30, which could be useful to start doing something.
One of the routines I found sends to the PTP host (the user's computer) the device information parameters about the camera itself, and it seems to use a simple pair of "data length, data address" to send the device info data back to the host with some additional info, so in theory we could hijack that routine to dump at least the part of MIPS32 code that we are still missing (from 0xBFC00000 onwards, probably the bootloader).
This means though that we have to manually modify the asm code to dump the addresses we want (no problem) and then re-encrypt the firmware and upgrade one HV30 to test this...
At least it's some progress...
Cheers,
Jollyroger
Jollyrogerxp
A bit more news still, I think I found the PTP command jump table, with empty jump addresses for commands that are supported and NULL pointers exactly in the spaces where unsupported commands are in the array. In theory one could now put in a completely new routine address in that jump table and invoke it simply by sending the appropriate PTP command to the camera...
Unfortunately I don't have a HV30 to experiment with; I have a HV20, and the FW 1.0.0.0 on it supports a slightly different set of PTP commands, and I don't know if this should be attributed to the different camera or to the different FW version...
Jollyroger
Jollyrogerxp
I found a routine that loops through the filenames "VEF9.FIM" to "VEF0.FIM" probably trying to open the file and when it finds it, it proceeds to checks for the presence of the "VEFX" string inside it, and then does something else...
That routine might give us some hints about how the check for the validity of the firmware actually happens, or maybe not? 😛 😛
Jollyroger
Wiesel
some checksum news:
I set the version from 1.0.1.0 to 1.0.1.1 and incremented the checksum of the first block by one, and the upgrade succeeded!!
It took a pretty long time to flash the cam (a few times longer compared to when the checksum is wrong and the error message appears) and it now also shows me version 1.0.1.1 in the menu 🙁 Like I assumed the number in the header is the only real version number in the firmware file.
You can't belive how glad I am that the cam still works 😁
Jollyrogerxp
The routine that checks the validity of the firmware file seems to do all sorts of operations, many of which are in the system code, so we cannot see them.
The checking routine though seems to somehow "use" the VEFX (0x5645465😎 value in the calculations, and then in the very end it compares the result of all the calculations to the sign-extended 16 bit value found right after "VEFX", which is 0x0A16.
If the result is equal to 0x0A16 then te return value of the routine is zero, in all oher cases (file not found, seek error, anything else) the return value is negative (0xFFFFFFFF or others), which makes me suspect zero is "OK".
Cheers,
Jollyroger
Wiesel
Xcelerate
I saw something that Napalm did-- changing two different bytes in opposite directions. For example, change the string "firmware" to "firmwbqe".
Tried this as well, but didn't work.
heron88
ok, need a little help here. I get 4 errors when trying to compile dhv30.c in xcode:
and
I'm still confused as to how to run this decrypter against the hv30 firmware. Is anyone that has already decrypted the firmware willing to post a link to or attach a file containing the decrypted f/w so I can begin analyzing it?
Thanks
Jollyrogerxp
Please check the previous posts in the thread, you will find a pre-compiled executable and instructions on how to run the decrypter...
It's simple anyway, there is an option to skip the first 0x100010 bytes which are not encrypted, check the arguments in the code...
heron88
ok, need a little help here. I get 4 errors when trying to compile dhv30.c in xcode:
and
I'm still confused as to how to run this decrypter against the hv30 firmware. Is anyone that has already decrypted the firmware willing to post a link to or attach a file containing the decrypted f/w so I can begin analyzing it?
Thanks
lunaticlabs
It seems that the checksum at the end is just a standard 32 bit dword checksum. I have attached my updated decoder/encoder. It now has an a flag to decode and a flag to encode. The encode flag will rewrite the flash binary with the correct checksums, so you can modify your firmware and reflash. I also tried updating the bitrates at 0x66bd48. I originally tried all 6 bitrates updated to 24k, but after 2 seconds of recording, I get the error "Cannot write", and it stops recording. Next I went to the XLP recording mode, which seems to start at 0x66bd18, and I shifted all the bitrates down, and added 24k to the highest bitrate. This let it record, and my video came out to slightly larger than before (1 minute video unmodified was 118megs, and after this change it came out to 124megs). This is still under the limit for 18k (which would result in a 132meg file), so I don't know if this proves anything, but at least the values can be changed to a limited extent and it still works. Changing the XLP recording mode to 24k for all six values causes it to fail with the cannot write error after about 4 seconds (so it can record a bit longer). Next I think I'm going to make some modifications to my encryptor/decryptor that will allow you to pull out and re-insert any section. What offsets & lengths are you guys using for the code section (i.e. what exactly are you extracting)? Which version of IDA are you guys using? I tried loading some of the IDA scripts posted earlier into 4.9, but that failed.
Wiesel
Awesome, I've lost hope for a long time but now it seems that progress is made every day 😀
(I always forgot the endian conversation when calculating the checksum, stupid me... there's just too much you have to think of ^^)
The code section is loaded at 0x04000000, length is 0x00306b20, data is at 0x4c8a6840 until 0x4cb97064. I'm using 5.2
edit: happy new year everyone!
Jollyrogerxp
This is brilliant, we need to make sure the HV30 decoder is updated accordingly too.
I think most of what I found in the first section of the HV30 firmware should be also valid for the HF10, so it would be good to begin inspecting that piece of MIPS32 code/data to decide some places to start injecting custom code.
