[HOW TO] How to Dump Firmware ?

[urbient]

hi ... i have the 650is and am interessted in how to dump the firmware ...
what tools are needed and what tasks have to be done to achive this ? ....

chris

[admin edit - sorry chris]
It sounded pretty reasonable to me that we should have this one sticky...


the right question at the right time ... forest gump
after jeffs reply i knew already that i cannot help in that field
but i rolled the snowball down the hill 

[jeff666]

The current state-of-the-art (and also only) method to get the firmware is to "blink" it using a phototransistor and a dumper-program that blinks the firmware to one of LEDs (preferably the AF-LED).

See:
General information:
http://chdk.wikia.com/wiki/Porting_the_CHDK

Run own code on a Cam without "Firm Update"-menu entry:
http://forums.dpreview.com/forums/read.asp?forum=1010&message=25202367

Find the address of the LEDs:
http://forums.dpreview.com/forums/read.asp?forum=1010&message=24988142

You will also need to (partly) modify and compile the dumper-code which needs a ARM-Compiler as well as some (at least basic) c-programming knowledge.

see:
http://chdk.wikia.com/wiki/Compiling_CHDK_under_Windows or
http://chdk.wikia.com/wiki/Compiling_CHDK_under_Linux


There are thoughts going on about a universal dumper. In case this approach is successful the effort for dumping the firmware may be as little as copying a file to the card and putting it into the cam. But there's nothing usable, yet.

Cheers.

[Trackieman]

Winno made an interesting edit on the A650IS CHDK Wiki. Apparently the addresses of the LED's are known on this camera.
http://chdk.wikia.com/wiki/A650IS#LED_Memory_Addresses

I'm intrigued as to how this was obtained. I guess the SD card was made bootable as described at:
http://forums.dpreview.com/forums/read.asp?forum=1010&message=25202367

I too have a A650IS. I borrowed a A640 and was impressed by CHDK.
Surely if the LED addresses are known and we can load executable code.
Then I've just got to have a go at dumping.

[Winno]

Hi everyone.  I'd thought I'd chime in on how I got those LED addresses.  I started without any CHDK experience, but I gathered a lot of information and ideas from the CHDK wikia and the DPReview forum, particularly the "CHDK for S5" http://forums.dpreview.com/forums/readflat.asp?forum=1010&thread=24983823&page=1 and the "CHDK firmware hack discussion" threads.  For my work, I used the supplied 32mb SD card, card readers and a Linux environment.

After identifying the firmware version using ver.req, I tried loading the G7-1.00g build onto the camera.  It didn't load, and there was no "Firmware Update" prompt in the menu. 

So the next task was to make the card bootable.  Unfortunately there wasn't much info on doing that outside a CHDK-enabled camera.  Eventually, I found some info on DPReview, especially the "CHDK for S5" thread.  I had to locate the first partition's boot sector and add the BOOTDISK string to it so it looks like the G7 sector, followed by locking the SD card.  Originally I thought that the boot sector meant the master boot record, or the first sector, but that was wrong, won't work and forced me to format the card in the camera.  So finally after reformatting the card, remodifying the boot sector (now at offset 0x6600), adding the "preblinker" files and locking the card, the camera responded - by locking up completely when the power button is pressed.  Same happened when G7 files were booted - nothing happens.

Now that the camera has responded to some code, it was time to find the LED addresses.  I went through various camera models on the wikia to get an idea of where the LEDs exist within the 32-bit address space.  All models had them in the range of about 0xC022 0080 to 0xC022 00E0.  I then modified the G7 blinker and tried turning everything >=80 to <FF on/off.  Initially every LED turned on, so I progressively halved the range until I got single LEDs turning on.  As I've found, LEDs only needed to be turned on and not blinked.  Incidentally, the addresses were the same as the A720IS. 

With the LED addresses and process of making an SD card bootable now known, a firmware blinker could be modified to blink out the firmware provided the correct firmware starting address is coded in. 

======
As a side note, I bought the A650 not long ago, as my first digital camera.  No, I didn't buy it purposely to hack, but to take photos with its nice features and likeness to the G9.  I tossed up between buying the A650 or S5, both of which I wanted to hack (and use).  I leaned towards the A650 because it was smaller and no one was hacking it until about now.

[Barney Fife]

Deleted

[mx3]

re: Make card bootable. Could someone make a small windows or DOS (or other) utility that could be used just for the purpose of writing that string to a card?

Why would anyone without enough of computer science knowledge want to make card bootable ?
- for those have been made menu option in already running CHDK

Those who know what to do and how to modify sector can do it without specialized tool.

Anyway there is an utility "Changing volume's serial number" on codeproject
http://www.codeproject.com/system/change_drive_sn.asp
its code can be easily used/modified to write "BOOTDISK" mark onto SD Card using cardreader

copying of files can be easily done using some.bat file without using of any other program

the easy way for developers is to make "hdd_directwrite.exe" and batch file to invoke it and other copy operations

but it stil requires person to enter right disk letter to execute this batch file in a right way
such tool used on wrong disk letter can lead to computer system damage ( I can be wrong )

anyway it seems tool you are asking for must be able to recognize removable media disks to be used safely
and it seems you would like it to have some windows interface too :-)

do you realy think that such tool is required?

[digit]

I've just tried a few of the steps in this thread to try and get chdk on my G9.  I've retreived the firmware version using the  ver.req method. I also made my SD card bootable and copied the three pre_blinker .bin files.

My question is about the these three files.  After inserting the card into my camera, nothing happens, the camera boots up normaly.  But when I lock this same card, and try to boot the camera, it does not start,  the screen is blank and any buttons are non-responsive.  Is this what is considered as "The camera Hangs"?  or should it be doing something else when the pre_blinker files are in?  What should I be looking for?

[Winno]

My question is about the these three files.  After inserting the card into my camera, nothing happens, the camera boots up normaly.  But when I lock this same card, and try to boot the camera, it does not start,  the screen is blank and any buttons are non-responsive.  Is this what is considered as "The camera Hangs"?  or should it be doing something else when the pre_blinker files are in?  What should I be looking for?

You're spot on.  When the camera "hangs" it does nothing when you try turning it on.  No lights, nothing on LCD, no LCD backlight, no lens movement, no response.  It is exactly what the preblinker is meant to do, and shows that your camera is running that code.  Don't worry about it damaging your camera - just pop open the battery door and unlock the SD card and you should be fine.

[digit]

Thats Great to here!  I will keep on following the steps indicated in the forums and post any results(if any...)  CHDK would be a great addition to the G9


Thanks again

[digit]

Playing with the G7 Blinker code last night, I got my G9's green LED to light up

The blink_G7 file from this post seems to be doing something   http://forums.dpreview.com/forums/read.asp?forum=1010&message=25071034&q=blink%5Fg7&qf=m.

I didn't have to modify the code at all, I just recompiled the "for camera" files using the included batch file, placed the diskboot.bin and PS.FIR on the bootable SD card, locked the card. After pressing power on the camera, the green LED turns on.

Does anyone know if it's suppose  to blink, or should it stay solid? 

For the G7 blinker code to light up the G9's led, these two camera's can't be that different.

[VMark]

Thanks for the big helps you provided (via userguides, etc). Especially to GrAnd and this site users and wikia users however, I have not asked anybody. The guides were pretty good!

I successfully dumped the firmware from an SX100 1.00B

I used the normal (not the g7) blinker (with crc16), from http://grandag.nm.ru/hdk/blinker with major modifications:
- I "cleared out" the startup procedure just left "b main" there, because for SX100 it did not work and I did not understand the reason interacting coprocessors, ...
- I rewrote the send_byte function in assembler, because
  1. I believe, the timing is quite important (same code length in every branch, very easy codepath, ...)
  2. I played the DELAY values, and (for sure by my mistake) it seemed the DELAY_SYNC and DELAY_SPACE shows the same signal despite the fact I wrote 10000 for the first and 100 for the second.
  3. My c knowledge is somehow limited (until now, because my mother language is Pascal), but I wrote pretty much in asm and I had a feeling, that the compiler did something wrong...

I used the soundcard method with my laptop internal mic with 96K (first, I was sure it cannot grab more than 44100, but with 96K I saw significant improvement). I followed the steps from http://chdk.wikia.com/wiki/Porting_the_CHDK
I compiled everything from "scratch", followed the instructions from http://chdk.wikia.com/wiki/Compiling_CHDK_under_Linux

The firmware can be found: http://www.zshare.net/download/6465081c0424a0/

I tested, if you put a file and call it PS.FI2, the firmware update line in the menu APPEARS.
Also I would like to confirm, that the SX100 running on DRYOS version 2.3, release #0023 (read from ROM)

I am updating the wikia pages.

I attached the source files with "my" diskboot.bin to this post. GrAnd, if you wish you could put next to the original blinker_g7.

VMark

[GrAnd]

I used the normal (not the g7) blinker (with crc16), from http://grandag.nm.ru/hdk/blinker with major modifications:
- I "cleared out" the startup procedure just left "b main" there, because for SX100 it did not work and I did not understand the reason interacting coprocessors, ...
- I rewrote the send_byte function in assembler, because
  1. I believe, the timing is quite important (same code length in every branch, very easy codepath, ...)
  2. I played the DELAY values, and (for sure by my mistake) it seemed the DELAY_SYNC and DELAY_SPACE shows the same signal despite the fact I wrote 10000 for the first and 100 for the second.
  3. My c knowledge is somehow limited (until now, because my mother language is Pascal), but I wrote pretty much in asm and I had a feeling, that the compiler did something wrong...

Congrats for your success!
I've looked in your blinker sources - a lot of asm .
Actually, the timing is not so important, because the decoding is done by the software. It's quite flexible to understand the input signal. There should be only one - the noticeable differences between DELAY_SYNC and DELAY_SPACE, DELAY0 and DELAY1.

[Kodl]

Hello,
as I promised, I am trying to dump SD700 (IXUS800) firmware 1.00B.
(http://chdk.setepontos.com/index.php/topic,146.msg937.html#msg937)
I have bought the BPW96C phototransistor, connected it to soundcard microphone input using the "Porting_the_CHDK" scheme via old headphones cable.
Using Adobe Audition 3, I've recorded some samples (PCM 96kHz raw 8-bit). I'm afraid that the resulting signal is not correct. Signal seems like the correct blinker pulses are modulated on another sinusoid or noise (?), but it is strange, because when I shade the camera's AF lamp while recording, signal totally disappears, no noise is visible in Audition's waveform graph.
The more stronger (loader) is the signal from the blinker the more the blinker signal is flying around the baseline (hex:80) up and down. Tested number of AFlamp-phototransistor distances - more close -> more distortion.
Is it possible, that this problem is caused by long, not well-shielded thin headphones cable? Amplitude (dB range of waveform in Audition) from phototransistor should be constant, shouldn't it?
(using ASUS P5N32E-SLI Plus's SupremeFX / ADI 1988b microphone input)
Thanks in advance!
Kodl

[Kodl]

...
The more stronger (loader) is the signal from the blinker the more the blinker signal is flying around the baseline (hex:80) up and down. Tested number of AFlamp-phototransistor distances - more close -> more distortion.
Is it possible, that this problem is caused by long, not well-shielded thin headphones cable? Amplitude (dB range of waveform in Audition) from phototransistor should be constant, shouldn't it?
(using ASUS P5N32E-SLI Plus's SupremeFX / ADI 1988b microphone input)
...

I will answer myself:
I had to switch Soundmax microphone filtering (in Soundmax control panel) to "No filtering". ("Mic array" was default setting) Moreover, before recording, I used the Soundmax wizard to setup optimal mic input level/volume for blue LED blinking.

I've dumped the firmware on 1600bod speed using blue LED. 

[clau30]

Hello,

Trying to port CHDK to A410. I don't really understand the process of dumping. I get the firmware version with the ver.req method, but what do I do with it then? Then I make a bootable SD card, put the blinker on it (which files? do I have to compile?) eventually run the blinker.. right?
Also, running Linux
Hope someone can clarify this for me.
Thanks!