Problems dumping the SD1100IS/IXUS80IS

[chr]

ok, and here is a crypted diskboot.bin with blinker inside.

Just in case anyone else want to give it a try.

[faljse]

ok, and here is a crypted diskboot.bin with blinker inside.

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.

[jeff666]

How does the encryption work?
Would be great if you could paste some code.

I agree. A description or code would be great.

Have you tried to encode the udumper and dump the firmware using that?

Cheers

[side78]

Very interested in seeing this too... trying to dump the SD790IS, and seems to have similar problems to what you're trying to solve...

[ccmcgeek]

Great work!

I confirm the encrypted blinker works on my SD890IS (IXUS 970), and the AF LED must be at the same address, because it turns on immediately and is blinking.  I will build the receiver circuit soon and attempt a dump.

If you have time to very briefly describe what encryption was required, that would be great.  As jeff666 says, it would be great to try encrypting the udumper program in the same fashion, to see if we can avoid having to set up the full blinker toolchain.

[chr]

Hello ppl!

I'm going to document everything! Be patient. I'm actually not at $HOME but I am currently in a hack lab. Had some trouble to setup a working PC from junk.

Sure, I tried a udumper in the cam, no success.

I need GrAnd's advice:
I'm using the A610 - SLOW (2500) [96KHz] timing. The FAST timing doesn't give me a good amplitude.
There is a noticeably gap every 5 seconds. I can see it with my eyes while dumping.
Smells like if irqs are not dead?

Heres a dump 8bit raw:
dump.raw.bz2

Code: [Select]

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


[chr]

LED - Dumper images, encoded.

Use as diskboot.bin on a sd-bootable sd card

blinker1.cr.bin - 0.10MB
blinker2.cr.bin - 0.10MB

(actually I'm not sure who is who  )

A610 - FAST (9230) [96KHz]
A610 - SLOW (2500) [96KHz]
(from speeds.txt)

AF LED should light and start 0123456789\a\d dump, rom at 0xff800000


led_on_off.bin.cr.5 - 0.10MB
switch led on and off - loop. Also try to hold down the powerbutton ~10sec.

Code: [Select]

#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;
}



[dlw]

(quote) "My interpretation of this is that having "noag" and "yosi" in the right spots on the card causes the camera to boot as normal." (close quote)

I think you're right.  I have the same code in LoadBootFile in my G9 firmware.  You may have not yet seen the beginning of the firmware:  it's a branch around the constant, "gaonisoy".  This could well be a validity test.
 
I haven't been able to boot CHDK on my G9, so I'm grasping at straws.

Thanks for your work.

[side78]

LED - Dumper images, encoded.

Very nice work, it appears to be working. I'm off to buy a photo resister

Any thoughts on extending this to dump to SD?

[chr]

Here we go:

[DOWNLOAD LINKS] Firmware dumps available

100%, no crc errors!



Found the gap problem: comes from delay while calculating crc for one block. This made my capture circuit crazy.
I put on/off around crc call, shifted it before sending anything.
Also I added sending four 0x00 before each SIG, so my homebrewn circuit can proper swing up at each block.

Also started some documentation in the wiki:

GPL Tools - CHDK Wiki

[jeff666]

Firmware dumps available

Loads into IDA, DryOS-Signatures apply. Good work.

I had a quick look into the Diskboot-loader (LoadDiskbootFile). In your cam its return-value is checked and a new error message ("not executable") is written to stdout on failure. If the return-value of LoadDiskbootFile doesn't indicate an error, the same code as in existing cameras is executed. Also the load-function itself looks nearly identical, thus the decoding mechanism should have been needed before, but existing firmwares just didn't check for successful decoding.

It seems we have been exploiting a bug in the firmware to boot CHDK, until now.

Addresses: 
  StartDiskboot: 0xFF82A0B0
  LoadDiskbootFile: 0xFF8666BC

Cheers.

[chr]

Firmware dumps available

Loads into IDA, DryOS-Signatures apply. Good work.
Cheers.

kewl!

Can we exchange symbol files? I'm thinking about hacking gdb to make it reading at least a plain ascii symbol file:

Gpl Qemu - CHDK Wiki

or ... can IDA save it in elf format w/symbols?

[jeff666]

Can we exchange symbol files? I'm thinking about hacking gdb to make it reading at least a plain ascii symbol file:

Well, IDA has a function called "export map file". Have a look:
zSHARE - ixus1100.0xff81000-0xffb1ffff_led.map.bz2

or ... can IDA save it in elf format w/symbols?

Negative.

Running the firmware in qemu seems like a lot of work but might be very useful.
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.

[chr]

Well, IDA has a function called "export map file". Have a look:
zSHARE - ixus1100.0xff81000-0xffb1ffff_led.map.bz2

Wrong offset. Mh, let's see if my renumber.pl works

Running the firmware in qemu seems like a lot of work but might be very useful.
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.

I posted the patch here:
Emulating Digicam with QEMU

in qemu's hw/ directory u find a lot of complete hardware setup from a full x86 IBM PC to simple ARM evaluation boards.
I just took an ARM, some RAM and a loader for the ROM. For I/O there are callbacks. So far I only printf but I found something like stdout. There's a SD cardreader implementation but someone must look with chdk into the cam to find out which chipset the cams use.

[jeff666]

Wrong offset. Mh, let's see if my renumber.pl works

A simple string-replace should be sufficient.


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 and the following posts.

Cheers.