Problems dumping the SD1100IS/IXUS80IS

[jeff666]

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

Both. Also padded udumper up to 512k

Don't go for udumper for now. Keep it as simple as possible. This reduces the possibilities for errors. We first want to light up an LED.

ok, attached

Seems ok, at least it works here (after some padding).

Damn SD cards: my poor fingernails ... I saw the upload stuff libptp2, want to use that!

Use a card reader (and maybe one which doesn't require breaking your fingers to insert/remove the card).

Cheers.

[chr]

so far not much progress.

The arm in the cam really runs in little endian, normal mode?!

if diskboot.bin is 0 size -> cam brick
if diskboot is any size, first byte 0x00 -> cam brick

if diskboot is any size, first byte != 0x00 -> cam "normal" (but usb plug powers off)

mh, we need some magic at beginning???

[rlyon]

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

I don't believe this is the IXUS960IS. There is some confusion on IXUS model numbering. The IXUS960IS operates in a similar manner to the IXUS80IS. The same dumping techniques will be applicable.

[chr]

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 )

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?

[user1]

.. stuff like IDA only exists in proptary windows world

Really?

[chr]

.. stuff like IDA only exists in proptary windows world

Really?

Code: [Select]

"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

The IDA demo version can't read raw, the free version can't do ARM. Both don't have linux stuff on board.

[TPC]

Hey chr,

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 )

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?

I've run through the 860is dump in IDA and can confirm that what you've found is true.

I can also confirm that the A580 exhibits the same behavior with diskboot.bin - 0 at 0x00, "noag" at 0x16, and "yosi" at 0x32 = camera boots, but won't run code on the card. Yet.

Having 0 at 0x00 and anything else at any other address = no activity from camera.

Here's a question - what does a Japanese insurance company have to do executing code on Canon digital cameras? What is it about that particular string that opens Pandora's box? We may never know.

Again, I'm using an A580 to crack this code and not an IXUS80... I'll let you know if I find anything that might be useful to you.

[TPC]

Just a progress report...

This is from the IXUS80IS firmware.

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

My interpretation of this is that having "noag" and "yosi" in the right spots on the card causes the camera to boot as normal. I don't have a reasonable explanation for this at all. It seems that all we need is "0" at 0x00 and "noag" at 0x10 and theorectically the camera will try to load whatever is in the DISKBOOT.bin file. I need to study this assembly code for a bit longer.

That's it for now.

[pricead]

I just want to say I appreciate the work you guys are doing!

* pricead stares at his SD1100 and wishes for chdk soon

[r8dhex]

I just want to say I appreciate the work you guys are doing!

* pricead stares at his SD1100 and wishes for chdk soon

Same here...

I'm haven't been able to touch our SD1100 lately, since my wife's been using it...

[chr]

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 ?
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 ?!)

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?!

[TPC]

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 ?
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 ?!)

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?!

All Japanese TV is funny. I'm guessing it's the name of some guy's kid.

After looking over the code again I see that only having a 0 at 0x00 is needed to "catch" the camera's boot process. Testing for the other two strings doesn't seem to do anything useful, unless someone wanted to write a kickin' rad DISKBOOT.bin hack that makes their camera boot normally.

A 40 byte header, hmm... I'm going to go play with this.

[chr]

I think, we are wrong.
I looked further at the stuff in LoadBootFile ... it looks like a decryption 

Also, in the 860 dump, I can't find the string 'Card locked' nor '*.fi2'

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?

The usb issue is maybe just a bug?
It doesn't freeze the cam, it really shuts down. The lens retracks before power off.
A present sd-bootdisk disables the irq's as a side effect. Pluggin the usb emits one I guess.

[faljse]

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.
Using a 16mb discboot delays power up.
Discboot.bin larger than about 17,5MB shut the camera down(usb disconnected).

[chr]

I got a a590 which seems to work very similar to the ixus80.
Using a 16mb discboot delays power up.
Discboot.bin larger than about 17,5MB shut the camera down(usb disconnected).

Interesting! The cam really crashes but doesn't brick:

On my ixus82is/1100is:
insert sd-boot diskboot.bin >~17.5, first byte !=0x00
switch to rec mode
power on
now switch to play: crash: upper led lit up green, then lcd+led dark, lens doesn't retrack
cam not bricked, can power on again.

I also tried a big diskboot file with led-blinker code inside: nothing.