Problems dumping the SD1100IS/IXUS80IS

[rlyon]

There is a problem in attempting to get a firmware dump from this new model. It appears that it is not possible to get diskboot.bin to run from a bootable, locked, FAT, 1 GB, SD card on camera power up (in review mode). The camera simply powers up as normal without delay and displays a message indicating the detection of a locked card.

ver.req may be used to get firmware version. The presence of a file called ps.fi2 causes the display of the firmware update menu item.

Maybe a a different first sector format is required in this camera to indicate a bootable card? Or maybe a different binary filename? Does anyone have any ideas or information?

An alterative approach is to create a custom ps.fi2 file which will be used to dump the firmware using LED blinking or writing to the SD card. What are the format/layout requirements for a valid ps.fi2 file? I have heard rumours that it contains encrypted data. Does anyone actually have a valid ps.fi2 file supplied by Cannon?

Canon has released quite a few new models in the last few months and I suspect they are all going to present the same difficulties in obtaining a firmware dump. This includes the following models:

SD890IS, SD790IS, SD770IS, SD1100IS, A590 IS, A580 and maybe the A470.

Has anyone had luck getting diskboot.bin or a blinker to run on these models?

Regards ...

[stunted]

I'm very interested in the A470, I've been hanging around on the forum to see if it's going to be supported,

I have an old S50 (not compatible I don't think) and shoot exclusively in RAW mode (particularly useful when diving) and have been searching for months for a replacement when I found CHDK.

Very excited, if I can get this to work I'm looking for cameras for 3 ~ 5 people.

If I were to buy one how likely is it that as a novice I could help things progress?

[rlyon]

I'm speculating about how the A470 works. uDumper may work correctly or it may have the same problems as with the SD1100IS/IXUS80 IS. I'm interested in the SD1100IS/IXUS80IS and perhaps/maybe trying to work on some porting for that model.

[stunted]

There was a user NoobSchoolBus on the forums who had one,
http://chdk.setepontos.com/index.php/topic,1199.msg11029.html#msg11029

I've PM'd him to find out if he ever dumped the firmware.

[NoobSchoolBus]

There was a user NoobSchoolBus on the forums who had one,
http://chdk.setepontos.com/index.php/topic,1199.msg11029.html#msg11029

I've PM'd him to find out if he ever dumped the firmware.

Sorry guys, I took the a470 back to the shop and brought an sx100 IS which seems to be pretty much the only reasonably priced camera on the market at the moment that supports remote capture.

[pricead]

any update on getting the SD1100 dumped?

[stunted]

Sorry guys, I took the a470 back to the shop and brought an sx100 IS which seems to be pretty much the only reasonably priced camera on the market at the moment that supports remote capture.

OK, thanks for the update, Do we think the A470 will support remote capture if/when we can get chdk on it?

I'm going to see how much they are here in Singapore,  If it's not too much I'll get one to see if I can get the dump,  Problem is I've got so much on at the mo, I'm not sure when I'll have time.

[chr]

There is a problem in attempting to get a firmware dump from this new model. It appears that it is not possible to get diskboot.bin to run from a bootable, locked, FAT, 1 GB, SD card on camera power up (in review mode). The camera simply powers up as normal without delay and displays a message indicating the detection of a locked card. ...

I found something!

I got a ixus 82 is, which is a 80 with a blue case. I tried to dump firmware with udumper w/o success. But I found some reactions of the cam:

Code: [Select]

zero   empty.dum
touch diskboot.bin
lock sd
power on "nothing happens" => brick, no more power on even w/o sd-card. Had to remove batt to resurrect cam

Ok, same with dryos diskboot.bin, camera simply operate as normal.

I looked through 960is.dump to get some insperation. The string "A/uartr.req" made me curious because there seems to be a shell inside the dump. Mh, how might that work? Another usb-endpoint? No. The presence of that file did nothing special on usb, but .... try this:

Code: [Select]

On SD:
dryos diskboot.bin
empty empty.dum
lock sd, card into cam
connect usbcable to computer (!)
power on

10: splash screen "card is locked" for 1 second,
camera switches off (!)

not bricked, power on again: goto 10

On my linux host pc, on usb bus nothing happened.

So, with usbcable something happens. However, the udumper doesn't seems to work. emtpy.bin still zero.

[jeff666]

I found something!

Seems like diskboot.bin is still read and even executed. The cam just won't execute our existing binaries.

I've observed something on my A720 when I was making udumper-tests. If the diskboot-file was to small, the cam wouldn't load it, still my cam hangs with an empty diskboot-file (just tested). I found out that the minimum size to get diskboot.bin started was about 20k. The actual code was only a few hundred bytes long and file size was increased by appending zeros.

Here's a small test program that should immediately turn on all LEDs on your cam (if the program runs). The program itself is only about 25bytes long, 100k are padded (see Make.bat). Feel free to play around with file sizes and see what is necessary to get the program running. If you want to recompile, it was built with the win32-toolchain.

Cheers.

[chr]

Hi Jeff!

I'll give that a try.

edit:

No success. I tried up to 512k.

Mh, the cam also switches off, when I plug in the usb cable after power on.

ps: I'm linux user .... mh, arm assembler looks cute ...

[jeff666]

ps: I'm linux user ....

Me too (well, both linux and win32, actually). I used the win32-toolchain because it's faster to "install" for the first tests. Now I have the linux-toolchain and use that.

mh, arm assembler looks cute ...

Yes, very nice ASM dialect. After reading ARM ASM for a while, I load a x86-binary into IDA and find it ugly and chaotic. One day I will throw my PC hardware into the garbage and get ARM-devices

Cheers.

[rlyon]

I looked through 960is.dump to get some insperation. The string "A/uartr.req" made me curious because there seems to be a shell inside the dump. Mh, how might that work? Another usb-endpoint? No. The presence of that file did nothing special on usb, but .... try this:

Where did you get a dump of IXUS960IS? No one has reported dumping this camera.

diskboot.bin does not work with the IXUS960IS.

The IXUS960IS firmware will be close to the IXUS80IS.

[chr]

Where did you get a dump of IXUS960IS? No one has reported dumping this camera.
diskboot.bin does not work with the IXUS960IS.
The IXUS960IS firmware will be close to the IXUS80IS.

here: IXUS960IS - CHDK Wiki
I'm still wondering how he did it.

@jeff:
2 questions
1. I got now gcc-arm ready. I can compile udumper and ledblink but make in chdk.trunk gives me:

Code: [Select]

[chris@hirnlego ~/ixus/chdk.trunk]$ LC_ALL=c make
>> Entering to tools
pakwif.c -> pakwif.o
as: unrecognized option `-Qy'
make[1]: *** [pakwif.o] Error 1
make: *** [all-recursive] Error 1

2. how to disassemble a firmware dump? which (linux/gnu) tool to use?

[jeff666]

>> Entering to tools
pakwif.c -> pakwif.o
as: unrecognized option `-Qy'
make[1]: *** [pakwif.o] Error 1

Your local c-compiler is damaged. The programs in tools/ are built using your local c-compiler (usually gcc) since they're supposed to run on your host.

2. how to disassemble a firmware dump? which (linux/gnu) tool to use?

Our reference disassembler is IDA pro. See here and here.

No success. I tried up to 512k.

Did you rebuild the source I posted or just added padding?
If you compiled the source yourself, post the binary so I can make sure your compiler worked (=run it on my cam).
Did you only try larger file sizes or smaller ones as well?

Cheers.

[chr]

>> Entering to tools
pakwif.c -> pakwif.o
as: unrecognized option `-Qy'
make[1]: *** [pakwif.o] Error 1

Your local c-compiler is damaged. The programs in tools/ are built using your local c-compiler (usually gcc) since they're supposed to run on your host.

Ah, it used the arm gcc ... hehe, ok it compiles now.

No success. I tried up to 512k.

Did you rebuild the source I posted or just added padding?

Both. Also padded udumper up to 512k

If you compiled the source yourself, post the binary so I can make sure your compiler worked (=run it on my cam).

ok, attached

Did you only try larger file sizes or smaller ones as well?

Smaller not yet. Damn SD cards: my poor fingernails ... I saw the upload stuff libptp2, want to use that! But actually any diskboot.bin on SD + USB cable the cam switches off. I guess can't upload anything.