PowerShot SX210 IS - Porting Thread

[HarpoMa]

Ahh the fun starts....

It appears to have a different key and iv then past versions.  Anyone know of any recent cameras with new key/iv that I should try?

It also appears a new set of dancing bits are in use.

Harpo

[asm1989]

NEW POST NOVEMBER 2010

Version 1.2.5
Current status is most of the stuff working except
- flash + iso overrides
- edgeoverlay only in 16:9
- zebra??

Ok Latest version with latest trunk 1211 - version 1.9

http://www.4shared.com/file/OCeTT8Tb/CHDK1211-sx210is-ASM1989-RCv19.html-compiled with the crash avoiding (mine didnt crash earlier, but maybe will help someone)
-also with chkd in exmem (seams to do nothing bad)
-Not with exmem malloc seams to corrupt video record

New Version 1.8

http://www.4shared.com/file/vUCx4XTv/CHDK1154-sx210is-ASM1989-RCv18.html
compiled with latest trunk 1154, dont know if fixes or crashes anything, but seam to work

Full Source here with ixus1000too:
http://www.4shared.com/file/fwfRXVYZ/sx210-ixus1000asm1989trunk1154.html


New Version 1.7-Compiled with latest chdk 1070

Binary:
http://www.4shared.com/file/FEcA7ech/CHDK1070-sx210is-ASM1989-RCv17.html

Sources of sx210 and ixus1000 with trunk 1070 here:
http://www.4shared.com/file/LQHKqGu8/sx210-ixus1000asm1989trunk1070.html




New Version 1.6-Updated some stuff for shot in scripting needs testing
-Compiled with latest chdk 1050

http://www.4shared.com/file/WweJWVX0/CHDK1038-sx210is-ASM1989-RCv16.html


Test out this new version 1.5, I think it solves the bracketing thing
http://www.4shared.com/file/wgX0OlbZ/CHDK1038-sx210is-ASM1989-RCv15.html

->Latest binary 1.4 without badpixel.bin
-Updated some stuff for braketing needs testing
http://www.4shared.com/file/Zo9MjtuR/CHDK1023-sx210is-ASM1989-RCv14.html

->Latest binary 1.3 without badpixel.bin
http://www.4shared.com/file/unuuTute/CHDK1023-sx210is-ASM1989-RCv13.html
-Updated DNG color profile so better color!

->Latest binary 1.2.7 without badpixel.bin
http://www.4shared.com/file/BXuGzeT_/CHDK1004-sx210is-ASM1989-RCv12.html
-Zebra "works" but not in the right spot.

->Latest binary 1.2.6 without badpixel.bin
->http://www.4shared.com/file/2Tp5Y47f/CHDK-sx210is-ASM1989-RCv126.html

-> Latest binary file ->http://www.4shared.com/file/xBo_2Xyx/CHDK-sx210is-ASM1989-RCv125.html
  Including my conf file and my badpixel.bin -> Delete it and generate a new One with the badpixel script!!!


-> Latest sources (Including full 1038 trunk, and source for ixus1000 100D & 100F too up to 09-01-11)
http://www.4shared.com/file/HfWk9tD4/sx210-ixus1000asm1989trunk1038.html

This was the OLD POST:

Anyone could make a firmware dump? so we can start playing

Software dumping dosnt seem to work as HarpoMa said

Due to timeline maybe advances in the SD1400IS http://chdk.setepontos.com/index.php/topic,5034.0.html could help
or the SD3500IS

Someone has any clue, of how to get the firmware?

[ccheney]

I got a SX210 a few days ago as well, have either of you been able to find the LED addresses? Or do the problems HarpoMa refers to keep from being able to do that yet?

[HarpoMa]

Until we find a way to get the camera to respond we are stuck.  It is my opinion that the dancing bits have changed which means we cannot get a working image to run. 

Just means we need to wait and see if anyone else gets one of the new cameras to respond....

[ccheney]

How does one generally find out what the dancing bits need to be changed to? Just a bunch of trial/error changing of the bits until it works or is there a way to shortcut to less than just brute force?

[ccheney]

It appears the following cameras may be similar to the SX210 based on release dates:

2010-02-08
---
SX210 IS
SD3500 IS / IXUS 210
SD1400 IS / IXUS 130
SD1300 IS / IXUS 105

2010-01-05
---
A3100 IS
A3000 IS
A495
A490

I briefly checked the chdk wiki and none appear to have dumps yet but I haven't search the forum.

[reyalp]

If canon actually changed both diskboot and FI2 encoding simultaneously, things could get difficult. Might be stalled until a firmware update comes out for one of the affected cameras.

Another option would be to look for exploitable flaws in existing firmwares that can be triggered from something on the SD card.

How does one generally find out what the dancing bits need to be changed to? Just a bunch of trial/error changing of the bits until it works or is there a way to shortcut to less than just brute force?

There's too many combinations to brute force, given that you have to put a new DISKBOOT on the card each time.

[ERR99]

It appears the following cameras may be similar to the SX210 based on release dates:

2010-01-05
---
A495

I briefly checked the chdk wiki and none appear to have dumps yet but I haven't search the forum.

I can confirm that the A495 also is not "working".
The ver.req/vers.req info display is not working anymore on the A495.
I discovered the P-ID of this camera via the usb-id and tryd to create a PS.FI2 file with d3 or d4 keys,
but the camera does not accept this "firmware-update", shows only a error.
Also no success getting a diskboot.bin file  (led blinker software/modified udumper) running
with dancingbits encoding 1/2/3.

So i also guess that canon changed the keys&dancingbits values for the cameras released in 2010.

[ccheney]

If canon actually changed both diskboot and FI2 encoding simultaneously, things could get difficult. Might be stalled until a firmware update comes out for one of the affected cameras.

This could end up pretty bad as unless I missed one they haven't updated any camera since the G10 on Feb 10 2009 and generally don't seem to update cameras unless they have major problems.

Is there any other way around the issue without having to wait for a firmware update?

[HarpoMa]

I've tried some brute force based on prior dancing bit "patterns".  To date no success since it takes a bit of time for each attempt.  My first subset is 250 files in size.    

I've contemplated trying to find an alternate vector but I don't know where to begin really.  If it was plausable (ie someone had the method of trying) I would either connect the ARM debug pins to something or try to read the eeprom directly.  I don't know how to do either of these possibilities.

I'm wondering if one could speed up the brute force by using an eye-fi card but as I don't have one I don't know yet.  If one could change the file remotely it would greatly speed up the brute force.  After all it's only a 8 factorial.  LOL - 40k plus tries. 


Harpo

[ccheney]

How were dancingbits 2/3 found, was it via the other FI2 method referenced? They appear to only be used on cameras that don't have firmware updates available either.

[ewavr]

 If one could change the file remotely it would greatly speed up the brute force.  

To locked card? It's impossible, IMHO.
BTW, transferring of diskboot.bin via USB works at least for VxWorks cameras (with Vitaly's libptp patch).

[ccheney]

I've tried some brute force based on prior dancing bit "patterns".  To date no success since it takes a bit of time for each attempt.  My first subset is 250 files in size.   

I've contemplated trying to find an alternate vector but I don't know where to begin really.  If it was plausable (ie someone had the method of trying) I would either connect the ARM debug pins to something or try to read the eeprom directly.  I don't know how to do either of these possibilities.

I'm wondering if one could speed up the brute force by using an eye-fi card but as I don't have one I don't know yet.  If one could change the file remotely it would greatly speed up the brute force.  After all it's only a 8 factorial.  LOL - 40k plus tries. 


Harpo

Entertaining the brute force method, at 40K its not inconceivable to find it, do we have any super simple test we could do with it to verify the dancingbits pattern works? Cutting the time needed per test down to absolute minimum while still having some way to verify if it worked would be ideal. As I understand even with the proper dancingbits udumper sometimes won't work due to issues with finding the function, so that seems to not be a reliable way to find the new pattern.

[asm1989]

If we procedure the brute force option, we can spread it over serveral owners to win time.

Can't we read the bits directly from the chip, using some kind of electronic custom built device?

[HarpoMa]

@ewavr - Ahhh yes a locked card.  Forgot about that. 

As for the brute force there are several issues (at least).  #1 is the simple fact that you don't know if it's running or crashed.  LOL   So you need to do something that is simple and doesn't crash in the case where it is actually running.  So what I do is try to turn on LEDs in the C022xxxx range.  This assumption is large as maybe C022xxxx does not have leds assigned to it.  Also, maybe the first 0x44 I find is not valid if turned to 0x46.   ect ect ect.

So even if we run a full brute force we could find nothing.