There was a user NoobSchoolBus on the forums who had one,
http://chdk.setepontos.com/index.php/topic,1199.msg11029.html#msg11029 (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.
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!
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
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.
I found something!
ps: I'm linux user ....
mh, arm assembler looks cute ... :)
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.here: IXUS960IS - CHDK Wiki (http://chdk.wikia.com/wiki/IXUS960IS)
diskboot.bin does not work with the IXUS960IS.
The IXUS960IS firmware will be close to the IXUS80IS.
[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
>> Entering to tools
pakwif.c -> pakwif.o
as: unrecognized option `-Qy'
make[1]: *** [pakwif.o] Error 1
2. how to disassemble a firmware dump? which (linux/gnu) tool to use?
No success. I tried up to 512k.
Ah, it used the arm gcc ... hehe, ok it compiles now.>> 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.
Both. Also padded udumper up to 512kNo 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).ok, attached
Did you only try larger file sizes or smaller ones as well?
Did you rebuild the source I posted or just added padding?Both. Also padded udumper up to 512k
ok, attached
Damn SD cards: my poor fingernails ... I saw the upload stuff libptp2, want to use that!
here: IXUS960IS - CHDK Wiki (http://chdk.wikia.com/wiki/IXUS960IS)
I'm still wondering how he did it.
r0 -> *file (?!)
ff8650cc: e5d02000 ldrb r2, [r0]
ff8650d0: e3520000 cmp r2, #0 ; 0x0
ff8650d4: 112fff1e bxne lr
ff8650d8: e5902010 ldr r2, [r0, #16]
ff8650dc: e59f303c ldr r3, [pc, #60] ; ff865120 <_binary_ixus860is_dump_start+0x55120>
-> "gaon"isoy
ff8650e0: e1520003 cmp r2, r3
ff8650e4: 05902020 ldreq r2, [r0, #32]
ff8650e8: 059f3034 ldreq r3, [pc, #52] ; ff865124 <_binary_ixus860is_dump_start+0x55124>
-> gaon"isoy"
ff8650ec: 01520003 cmpeq r2, r3
ff8650f0: 012fff1e bxeq lr
...
don't understand the rest, yet.
ff82bbd8: e59d1000 ldr r1, [sp]
ff82bbdc: e1a00004 mov r0, r4
ff82bbe0: eb00e539 bl ff8650cc <_binary_ixus860is_dump_start+0x550cc>
ff82bbe4: e3a00101 mov r0, #1073741824 ; 0x40000000
ff82bbe8: e5906000 ldr r6, [r0]
ff82bbec: e59d5000 ldr r5, [sp]
ff82bbf0: ebffbf31 bl ff81b8bc <_binary_ixus860is_dump_start+0xb8bc> IRQ off?!
ff82bbf4: e3a03c19 mov r3, #6400 ; 0x1900
ff82bbf8: e1a02005 mov r2, r5
ff82bbfc: e1a01004 mov r1, r4
ff82bc00: e3a00c19 mov r0, #6400 ; 0x1900
ff82bc04: e12fff36 blx r6
ff82bc08: e8bd40f8 ldmia sp!, {r3, r4, r5, r6, r7, lr}
ff82bc0c: ea006226 b ff8444ac <_binary_ixus860is_dump_start+0x344ac>
.. stuff like IDA only exists in proptary windows world :P
.. stuff like IDA only exists in proptary windows world :P
Really? (http://www.hex-rays.com/idapro/linux/index.htm)
"The (Linux) IDA Pro debugger, disassembler and remote debuggers are not sold separately but are included in the normal IDA Pro Windows distribution."
There's no stuff like this in the GNU world ... usually we have the source ;)So, I looked into the ARM reference and into ixus860is_dump ... which might be close to sd1100 or not.
(only have arm-objdump ... stuff like IDA only exists in proptary windows world :P )
1. it looks for DISKBOOT.BIN and then Upgrader.bin. confirmed.Code: [Select]r0 -> *file (?!)
ff8650cc: e5d02000 ldrb r2, [r0]
ff8650d0: e3520000 cmp r2, #0 ; 0x0
ff8650d4: 112fff1e bxne lr
ff8650d8: e5902010 ldr r2, [r0, #16]
ff8650dc: e59f303c ldr r3, [pc, #60] ; ff865120 <_binary_ixus860is_dump_start+0x55120>
-> "gaon"isoy
ff8650e0: e1520003 cmp r2, r3
ff8650e4: 05902020 ldreq r2, [r0, #32]
ff8650e8: 059f3034 ldreq r3, [pc, #52] ; ff865124 <_binary_ixus860is_dump_start+0x55124>
-> gaon"isoy"
ff8650ec: 01520003 cmpeq r2, r3
ff8650f0: 012fff1e bxeq lr
...
don't understand the rest, yet.
2. it looks first byte if 0x00, and then checks "gaonisoy" ...
confirmed.
0x00 => brick
0x00 and "gaon" at #16 and "isoy" at #32 => no brick, (but still hates usb)
I googled for that string. Found "yosinoag", which is a litte japanese assurance company.Code: [Select]ff82bbd8: e59d1000 ldr r1, [sp]
ff82bbdc: e1a00004 mov r0, r4
ff82bbe0: eb00e539 bl ff8650cc <_binary_ixus860is_dump_start+0x550cc>
ff82bbe4: e3a00101 mov r0, #1073741824 ; 0x40000000
ff82bbe8: e5906000 ldr r6, [r0]
ff82bbec: e59d5000 ldr r5, [sp]
ff82bbf0: ebffbf31 bl ff81b8bc <_binary_ixus860is_dump_start+0xb8bc> IRQ off?!
ff82bbf4: e3a03c19 mov r3, #6400 ; 0x1900
ff82bbf8: e1a02005 mov r2, r5
ff82bbfc: e1a01004 mov r1, r4
ff82bc00: e3a00c19 mov r0, #6400 ; 0x1900
ff82bc04: e12fff36 blx r6
ff82bc08: e8bd40f8 ldmia sp!, {r3, r4, r5, r6, r7, lr}
ff82bc0c: ea006226 b ff8444ac <_binary_ixus860is_dump_start+0x344ac>
So, it gets the jump address from 0x40000000 ...
Questions:
Has canon implemented exception handling?
What happens on other cams, if there is a undefined instruction or a breakpoint (freeze/brick/reboot/poweroff)?
In which mode does the ARM cpu run (LE, User Mode, whatever)? Do we have a MMU?
ROM:FF8650CC LoadBootFile ; CODE XREF: StartDiskboot+9Cp
ROM:FF8650CC ; sub_FF8F9CB0+88p ...
ROM:FF8650CC LDRB R2, [R0] // Load the first byte of the DISKBOOT.bin file to R2
ROM:FF8650D0 CMP R2, #0 // Compare R2 to "0"
ROM:FF8650D4 BXNE LR // If not equal, branch to LR (break out, go somewhere else)
ROM:FF8650D8 LDR R2, [R0,#0x10] // Read DISKBOOT.bin file at 0x10 (16)
ROM:FF8650DC LDR R3, =0x6E6F6167 // Set R3 to "noag"
ROM:FF8650E0 CMP R2, R3 // Compare R2 and R3
ROM:FF8650E4 LDREQ R2, [R0,#0x20] // If equal, read DISKBOOT.bin file at 0x20 (32)
ROM:FF8650E8 LDREQ R3, =0x796F7369 // If equal, set R3 to "yosi"
ROM:FF8650EC CMPEQ R2, R3 // If equal, compare R2 and R3
ROM:FF8650F0 BXEQ LR // WTF!? If equal, branch to LR (break)
ROM:FF8650F4 SUB R2, R1, #1 // Else, do this stuff...
ROM:FF8650F8 MOV R1, #0
ROM:FF8650FC
ROM:FF8650FC loc_FF8650FC ; CODE XREF: LoadBootFile+44j
ROM:FF8650FC CMP R1, R2
ROM:FF865100 ADDCC R3, R0, R1
ROM:FF865104 LDRCCB R3, [R3,#1]
ROM:FF865108 STRCCB R3, [R0,R1]
ROM:FF86510C ADDCC R1, R1, #1
ROM:FF865110 BCC loc_FF8650FC // Loop (loading DISKBOOT.bin to RAM?)
ROM:FF865114 MOV R1, R0
ROM:FF865118 B sub_FF865008 // Branch unconditionally to sub_FF865008
ROM:FF865118 ; End of function LoadBootFile
I just want to say I appreciate the work you guys are doing!
/me stares at his SD1100 and wishes for chdk soon
r1 = len ?
ff8650f4: e2412001 sub r2, r1, #1 ; 0x1 // r2 = r1 - 1
ff8650f8: e3a01000 mov r1, #0 ; 0x0 // r1 = 0
// r0=*file; r1=0; r2=len-1 //
ff8650fc: e1510002 cmp r1, r2 // for (r1=0; r1<r2 ;r1++) {
ff865100: 30803001 addcc r3, r0, r1 // r3 = r0 + r1
ff865104: 35d33001 ldrccb r3, [r3, #1] // r3 = (char)*(r3 + 1)
ff865108: 37c03001 strccb r3, [r0, r1] // *(char)(r0 + r1) = r3
ff86510c: 32811001 addcc r1, r1, #1 // r1++;
ff865110: 3afffff9 bcc ff8650fc // }
So, it shifts the file one byte down in memory. Makes sense. I tried the led blinker with putting one, 63, 64, 65 0x00 in front: brick, no led. (0x00000000 = "andeq r0, r0, r0" is (almost) a NOP ?!)Hi TPC!
"BXEQ LR" is a conditional "ret". the LR register holds the return address.
the "noag" and "yosi" must be a special sense of humor: I expected it's a positive magic. Who knows, maybe that company have a funny TV spot?
The rest reads like this:Code: [Select]r1 = len ?So, it shifts the file one byte down in memory. Makes sense. I tried the led blinker with putting one, 63, 64, 65 0x00 in front: brick, no led. (0x00000000 = "andeq r0, r0, r0" is (almost) a NOP ?!)
ff8650f4: e2412001 sub r2, r1, #1 ; 0x1 // r2 = r1 - 1
ff8650f8: e3a01000 mov r1, #0 ; 0x0 // r1 = 0
// r0=*file; r1=0; r2=len-1 //
ff8650fc: e1510002 cmp r1, r2 // for (r1=0; r1<r2 ;r1++) {
ff865100: 30803001 addcc r3, r0, r1 // r3 = r0 + r1
ff865104: 35d33001 ldrccb r3, [r3, #1] // r3 = (char)*(r3 + 1)
ff865108: 37c03001 strccb r3, [r0, r1] // *(char)(r0 + r1) = r3
ff86510c: 32811001 addcc r1, r1, #1 // r1++;
ff865110: 3afffff9 bcc ff8650fc // }
I followed the rest an I saw, 40 bytes are allocated on stack. it puts stuff from #ff86511c in it, then it reads from the first bytes from diskboot.bin. So I guess we have a file header of 40+1 bytes.
Any known binary formats with a header size like this?!
I got a a590 which seems to work very similar to the ixus80.
However, the file is loaded, thats for sure. I tried a 16M discboot.bin. There's a noticable delay on power up.
Mh, if the jump to *0x40000000 is the same in ix80 firmware ... and first byte != 0x00 the file is left untouched in memory. We need a 1G diskboot.bin to write at 0x40000000 maybe this overflow works. My largest SD card is a "1G" so can't try this now. Any FAT filesystem hackers here to fake such a file? ::)
I got a a590 which seems to work very similar to the ixus80.Interesting! The cam really crashes but doesn't brick:
Using a 16mb discboot delays power up.
Discboot.bin larger than about 17,5MB shut the camera down(usb disconnected).
exact crash size isWhen using a diskboot.bin larger than 30.953.664 Bytes the cam(a590) doesnt even power up
0x010d.a300 + 1
First: omg you got the camera firmware to run in qemu? That is front page material, sir.
I'm going to post details on using qemu-arm in an extra thread for ppl not having IDA. Still sorting stuff and copy'n'pasting stuff from bash_history.
Just a short update. I found LED_AF @ 0xc0223030
blinker is running but need better adjustment. The recording looks odd.
Stay tuned ;)
ok, and here is a crypted diskboot.bin with blinker inside.How does the encryption work?
Just in case anyone else want to give it a try.
How does the encryption work?
Would be great if you could paste some code.
I used
./adc2 -d 60 207 1 70 6 23 ~/ixdump2/dump.raw dump
60 140 9 80 1 17
... (more or less sync err)
./dec.o
read 6740 bytes...
found SIG at 3302... Base: 7f800000 CRC...a8a9...FAIL
found SIG at 4333... Base: 7f800400 CRC...c49f...FAIL
found SIG at 5364... Base: 7f800800 CRC...9449...FAIL
found SIG at 6396... Base: ff7f8000 CRC...1188...FAIL
first hexdump looks like this
00000408 37 38 39 0D 0A 30 31 32 33 34 35 36 37 38 39 0D 0A 30 31 32 33 34 35 36 789..0123456789..0123456
00000420 37 38 39 0D 0A 30 31 32 33 34 35 36 37 38 39 0D 0A 30 31 32 33 34 35 36 789..0123456789..0123456
00000438 37 38 39 0D 0A 30 31 32 33 34 35 36 37 38 39 0D 0A 30 31 32 33 34 35 36 789..0123456789..0123456
00000450 37 38 39 0D 0A 30 31 32 33 34 35 36 37 38 39 0D 0A 30 31 32 33 34 35 36 789..0123456789..0123456
00000468 37 38 39 0D 0A 30 31 32 33 34 35 36 37 38 39 0D 0A 30 31 32 33 34 35 36 789..0123456789..0123456
00000480 37 38 39 0D 0A 30 31 32 33 34 35 36 37 38 39 0D 0A 30 31 32 37 38 39 0D 789..0123456789..012789.
00000498 0A 30 31 32 33 34 35 36 37 38 39 0D 0A 30 31 32 33 34 35 36 37 38 39 0D .0123456789..0123456789.
000004B0 0A 30 31 32 33 34 35 36 37 38 39 0D 0A 30 31 32 33 34 35 36 37 38 39 0D .0123456789..0123456789.
000004C8 0A 30 31 32 33 34 35 36 37 38 39 0D 0A 30 31 32 33 34 35 36 37 38 39 0D .0123456789..0123456789.
000004E0 38 39 0D 0A 30 31 32 33 34 35 36 37 38 39 0D 0A 30 31 32 33 34 35 36 37 89..0123456789..01234567
000004F8 38 39 0D 0A 30 31 32 33 34 35 36 37 38 39 0D 0A 30 31 32 33 34 35 36 37 89..0123456789..01234567
00000510 38 39 0D 0A 30 31 32 33 34 35 36 37 38 39 0D 0A 30 31 32 33 34 35 36 37 89..0123456789..01234567
00000528 38 39 0D 0A 30 31 32 33 34 35 36 37 38 39 0D 0A 30 31 32 33 34 35 36 37 89..0123456789..01234567
00000540 38 39 0D 0A 30 31 32 33 34 35 36 37 38 39 0D 0A 30 31 32 33 34 35 36 37 89..0123456789..01234567
#define led_start 0xc0220000
#define led_end 0xc022f000
//AF 0xc0223030
#define delay 0x1000
void sleep(int d) {
for ( ; d>0; d--) {
asm("nop");
asm("nop");
}
}
int main(){
while (1) {
long* led;
led=(long*)led_start;
while (led < led_end) {
*led = 0x46;
led++;
sleep(delay);
}
sleep(0x100000);
led=(long*)led_end;
while (led > led_start) {
*led = 0x44;
led--;
sleep(delay);
}
sleep(0x100000);
}
return 0;
}
LED - Dumper images, encoded.
Firmware dumps available
Firmware dumps availableLoads into IDA, DryOS-Signatures apply. Good work.
Cheers.
Can we exchange symbol files? I'm thinking about hacking gdb to make it reading at least a plain ascii symbol file:
or ... can IDA save it in elf format w/symbols?
Well, IDA has a function called "export map file". Have a look:Wrong offset. Mh, let's see if my renumber.pl works
zSHARE - ixus1100.0xff81000-0xffb1ffff_led.map.bz2 (http://www.zshare.net/download/15248236726bacae/)
Running the firmware in qemu seems like a lot of work but might be very useful.I posted the patch here:
Is it simple enough to rebuild the canon-hardware in qemu?
How do you handle unknown MMIO access?
Can you access the memory from outside qemu so it's possible to rebuild a GUI (display + LED output, kbd input)?
Cheers.
Wrong offset. Mh, let's see if my renumber.pl works
I looked for two functions in your firmware:
WriteSDCard: 0xFF91F0C8
ReadSDCard: 0xFF91EF70
WriteSDCard is used by udumper to write the firmware to the SD. I wrote some notes on how to use it. See this (http://chdk.setepontos.com/index.php/topic,1132.msg17178.html#msg17178) and the following posts.
Cheers.
kewl. I'm going to build an udumper. Might work in other latest cams too.
Wait: these symbols were not in the file ??? !
Question: can IDA "run" the code like that?
Mh, we close this thread and open "porting SD1100" ::)
SD1100IS/IXUS80IS dump (http://chdk.setepontos.com/index.php/topic,288.msg17485.html#msg17485)
it is great.Mh, I documented everything ... is something missing?
please share diskboot.bin project sources and crypter sources so other people could do the same with theirs similar camera models.
Also note that the addresses only work for your firmware. Function locations differ in every firmware-build. The udumper locates WriteSDCard due to some hints and guesswork - it doesn't always succeed, though. See this (http://chdk.setepontos.com/index.php/topic,221.msg2726.html#msg2726) and the subsequent posts for details.
WriteSDCard: 0xff91f0c8
ReadSDCard: 0xff91ef70
ff84e81c: e3a01000 mov r1, #0 ; 0x0
ff84e820: e59f00b4 ldr r0, [pc, #180] ; ff84e8dc <_binary_dump_bin_start+0x3e8dc>
ff84e824: e5801034 str r1, [r0, #52]
ff84e828: e5801038 str r1, [r0, #56]
ff84e82c: e3a01003 mov r1, #3 ; 0x3
ff84e830: e580103c str r1, [r0, #60]
ff84e834: e59f10c0 ldr r1, [pc, #192] ; ff84e8fc <_binary_dump_bin_start+0x3e8fc>
ff84e838: e580104c str r1, [r0, #76]
ff84e83c: e59f10bc ldr r1, [pc, #188] ; ff84e900 <_binary_dump_bin_start+0x3e900>
ff84e840: e5801050 str r1, [r0, #80]
ff84e844: e12fff1e bx lr
(gdb) j *0xff84e81c
Continuing at 0xff84e81c.
Breakpoint 3, 0xff84e844 in _binary_dump_bin_start ()
(gdb) x/32x $r0
0x11544: 0x00000000 0x00000000 0x00000000 0x00000000
0x11554: 0x00000000 0x00000000 0x00000000 0x00000000
0x11564: 0x00000000 0x00000000 0x00000000 0x00000000
0x11574: 0x00000000 0x00000000 0x00000000 0x00000003
0x11584: 0x00000000 0x00000000 0x00000000 0xff91ef70
0x11594: 0xff91f0c8 0x00000000 0x00000000 0x00000000
0x115a4: 0x00000000 0x00000000 0x00000000 0x00000000
0x115b4: 0x00000000 0x00000000 0x00000000 0x00000000
#if defined (DRYOS)
// #warning DRYOS
// jeff666: fill some memory with zeroes; "simulate" large diskboot
// WARNING: the starting address is a guess
for (i = 0x1c00; i<0x30000; i+=4) *(int*)i=0;
Argh! U Bastard! Why didn't u post this earlier???
Question:
#if defined (DRYOS)
// #warning DRYOS
// jeff666: fill some memory with zeroes; "simulate" large diskboot
// WARNING: the starting address is a guess
for (i = 0x1c00; i<0x30000; i+=4) *(int*)i=0;
???
Argh! U Bastard! Why didn't u post this earlier???Because it would have been to easy and no challenge at all :D
Bad news.
Yesterday my cam got a E18 "Lens error, restart camera" without any reason! :blink:
I did not drop the cam nor did I play with DISKBOOT. It simply refused to work. Looking closly I noticed, the Lens is not correct mounted: The outer "Gummidichtung" (english?!) is not well fitting and maybe caused the blocking.
Today it operates as nothing happened, but vers.req show an "E18" with timestamp in the log.
So tomorrow I'm going to return the cam.
Hi, so I have the A470 and tried the encoded blinker diskboots and it gets the LCD blinking...Thats a good start. With that u can already calculate the led adress
The led_on_off.bin.cr.5 does get the AF LED on...
I could probably work out writing a blinker and getting the LED address, but the encoding stage sounds a little beyond me... :(
so i'm just wondering if we are actually any closer to getting CHDK on ixus80is? i cant really understand all this talk of LED blinkers and whatnot ( :-[my bad - just not that technically minded) and was just wondering what all this means for the average pleb who just bought a shiny new ixus80is?
i got addicted to CHDK with my ixus70 which i lost recently :( hence the ixus80is...
thanks for all the hard work from everyone who understands what they are doing here...
hope we get CHDK on ixus80is soon :)
i'll just sit here patiently till then...