PowerShot SX210 IS - Porting Thread - page 5 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 59   Go Down

PowerShot SX210 IS - Porting Thread

  • 589 Replies
  • 301627 Views
*

Offline whoever

  • ****
  • 280
  • IXUS950
Re: PowerShot SX210 IS - Porting Thread
« Reply #40 on: 30 / May / 2010, 14:00:05 »
Advertisements
Quote from: HarpoMa on 30 / May / 2010, 12:49:06
Scripts was one entry point I tried but didn't know about the <0> byte at the start.
It's in the code. Example:
   FFB27ED8   BL    Fread_Fut       ; Branch with Link
   FFB27EDC   LDRB  R3, [SP,#0x24+var_1D] ; Load from Memory
   FFB27EE0   CMP   R3, #0          ; Set cond. codes on Op1 - Op2
   FFB27EE4   BNE   loc_FFB27F04    ; Branch
   FFB27EE8   CMP   R8, #0          ; Set cond. codes on Op1 - Op2
   FFB27EEC   BNE   loc_FFB27F30    ; Branch
   FFB27EF0   LDR   R1, =CanTExecuteScr ; Load from Memory
   FFB27EF4   LDR   R2, =NotPlaneText ; Load from Memory
   FFB27EF8   LDR   R0, =ss_1       ; Load from Memory
   FFB27EFC   BL    printf          ; Branch with Link
On a second thought (and a quick try), if the first byte isn't 0, my cam shuts down, and if it is 0, then, no matter what gibberish follows, it doesn't. One evidently needs to inspect the camera log. Will try to investigate some day...
Logged
*

Offline cppasm

  • **
  • 92
Re: PowerShot SX210 IS - Porting Thread
« Reply #41 on: 31 / May / 2010, 04:10:12 »
This is related to script autotest.m - shooting sequense test.
The script extend.m (EWAVR mentioned about it in dpreview) is extension to playback controller.
It looks like extend.m does not require zero in first byte.
In any case the major problem is that we don't know how to create entry point.
Script is checked by the parser, but does not execute.
Maybe we need to create some 'public' sub or something like this...
Logged
*

Offline scuffedshoes

  • *
  • 1
Re: PowerShot SX210 IS - Porting Thread - a bit OT
« Reply #42 on: 11 / June / 2010, 13:57:50 »
Hi,
First let me apologize for not adding info to this thread but rather asking an end user question.
Do you folks have a sense that you will be able to port CHDK to the SX210?

I've been shooting with an SD750 for a couple of years and really enjoying the extras made available by CHDK. Now I'm looking to upgrade. I want something with a long zoom and the SX210 has really good specs, especially for the price. But I'm chary about getting one if CHDK isn't going to make it into the camera.

I note that the majority of models have been ported to, but there are a few that were skipped over. I'm wondering if the SX210 might be a camera that never gets a port. If so, I might be able to find an SX200 kicking around in old stock somewhere, but I'd hate to get that one and in in 6 months find CHDK for the SX210. Also, the 200 is 0.25" thicker than the 210, as well as having a smaller pixel count and a lower zoom ratio.

There are only a few of the many features of CHDK that I use with any regularity, RAW, zebra stripes and auto-bracketing, but I've grown really used to those functions and hate the idea of foregoing them completely.

So, whaddaya think? Shall I gamble that you folks will crack the new firmware and port CHDK over? Personally, I think it's likely that you'll port it this year, but I thought I'd ask the folks who have the best notion of how it's going.

Thanks for any suggestions, and again, my apologies for the interjection.
Logged
*

Online reyalp

  • ******
  • 14082
Re: PowerShot SX210 IS - Porting Thread
« Reply #43 on: 12 / June / 2010, 00:37:59 »
Quote from: scuffedshoes on 11 / June / 2010, 13:57:50
Hi,
First let me apologize for not adding info to this thread but rather asking an end user question.
Do you folks have a sense that you will be able to port CHDK to the SX210?
Allow me to run the preceding thread through my handy dandy programmer-to-english translator
Quote from: magic translator
We have no frackin idea

It is possible that the CHDK will never be ported to these cameras.
It is possible that there will be a breakthrough in the near future, and ports will follow shortly.
It is possible that it will be many months or years before someone figures it out.

Your guess of the probability of any of these is likely to be as good as anyone else. A fair set of dice may also provide an equally useful estimate.

What features you want doesn't matter, the stumbling block is getting code to run on the camera at all. There may be further stumbling blocks later, but we won't even find out about them until we get past the first one.

If CHDK is really important to you, get a CHDK supported camera. If the SX210 is the camera you want even without CHDK, get that. If you can't decide, procrastinate or flip a coin :)
Logged
Don't forget what the H stands for.
*

Offline dumper

  • *
  • 15
Re: PowerShot SX210 IS - Porting Thread
« Reply #44 on: 28 / June / 2010, 00:27:41 »
Hi Guys, this is my first post here lol.

I will get this camera tomorrow hopefully and probably I can help with the port process. I have some background in electronics as well as asm/c languages.

I've spent some time going through the general articles in the wiki but unfortunately I still feel there is some important background knowledge missing. For example I don't quite understand the "dancing bits", "key/iv" stuff you were talking about. Could you refer me to any materials that might be useful?

Thanks.
Logged
*

Online reyalp

  • ******
  • 14082
Re: PowerShot SX210 IS - Porting Thread
« Reply #45 on: 28 / June / 2010, 01:24:04 »
Quote from: dumper on 28 / June / 2010, 00:27:41
For example I don't quite understand the "dancing bits", "key/iv" stuff you were talking about. Could you refer me to any materials that might be useful?
Dancing bits refers to the format and associated program used for diskboot.bin images. The source, including with values used to encode diskboot for known models may be found in the tools directory of the source tree as dancingbits.c.

The key/iv stuff refers to the encoding used for dryos firmware update files (*.FI2). The packfi2 subdirectory of tools contains the source for this tool. The encoding and method to find the key/iv values are described in http://chdk.setepontos.com/index.php/topic,2995.0.html

However, it's not clear that either of the above will help get code running on sx210 or other new cameras. We already know that none of the known encodings are used.
Logged
Don't forget what the H stands for.
*

Offline dumper

  • *
  • 15
Re: PowerShot SX210 IS - Porting Thread
« Reply #46 on: 30 / June / 2010, 03:54:10 »
So it seems we should look for exploitable flaws in the system software? Which firmware should we look into? Could you post a link for the unencoded binary?
I'm not sure if I can help now since I am not familiar with ARM architecture. I don't have IDA pro either... btw has anyone got any clue yet?
Logged
*

Offline dumper

  • *
  • 15
Re: PowerShot SX210 IS - Porting Thread
« Reply #47 on: 30 / June / 2010, 15:58:22 »
I think it may be possible to hand craft a small DISKBOOT.bin program in machine code (a few bytes long) and use that to narrow down the choice of dancing bit pattern. Is there any one-byte long opcode in ARM ISA? What happens to the camera if it encounters invalid opcode? What happens if the bin file is filled with no-ops? The point is, is there any way to distinguish between the two situations?
« Last Edit: 30 / June / 2010, 16:00:32 by dumper »
Logged
*

Online reyalp

  • ******
  • 14082
Re: PowerShot SX210 IS - Porting Thread
« Reply #48 on: 30 / June / 2010, 17:13:58 »
Quote from: dumper on 30 / June / 2010, 03:54:10
So it seems we should look for exploitable flaws in the system software? Which firmware should we look into? Could you post a link for the unencoded binary?
Look in the dumps thread. I'd suggest using one of the most recent, supported cameras (sx20, sx200, ixus200). Once you find a potentially exploitable flaw, you'll want to look at several different cameras to get an idea of what is likely to vary between versions, and how frequently canon has changed the code involved. Ideally you'd find a buffer overflow or similar in something very old and stable.
Quote
I'm not sure if I can help now since I am not familiar with ARM architecture.
The ARM documentation is quite good, and available for free from the ARM site. See http://chdk.wikia.com/wiki/Developer_Technical_Documents for some useful links.

Quote from: dumper on 30 / June / 2010, 15:58:22
I think it may be possible to hand craft a small DISKBOOT.bin program in machine code (a few bytes long) and use that to narrow down the choice of dancing bit pattern.
ISTR there is generally a minimum size required to load the diskboot. This can be padded with zeros, I used 10kb when I was last messing with udumper.

Quote
Is there any one-byte long opcode in ARM ISA?
No, ARM is RISC, all instructions are 32 bits (or 16 bits in thumb mode, but switching to thumb would require one ARM instruction, and would add needless complications)
Quote
What happens to the camera if it encounters invalid opcode?
An exception occurs and the camera shuts down, if the exception handling code hasn't been hosed. But diskboot loads before the camera has visibly powered on, and I don't think you can rely on the exception code not being hosed. If you have a supported camera you can experiment.
Quote
What happens if the bin file is filled with no-ops? The point is, is there any way to distinguish between the two situations?
See early discussion about measuring power consumption. Otherwise, you have to find an LED.

Reducing the size of the diskboot won't help you anyway, you still need to load a unique one on the card every time.
Logged
Don't forget what the H stands for.
*

Offline dumper

  • *
  • 15
Re: PowerShot SX210 IS - Porting Thread
« Reply #49 on: 01 / July / 2010, 00:33:56 »
Quote
Reducing the size of the diskboot won't help you anyway, you still need to load a unique one on the card every time.

Actually what I wanted to reduce is the number of tries required to find the byte swap pattern.
I'm not sure how the camera starts to execute the code in DISKBOOT.bin (is it an unconditional jump or routine call, which should be able to return, right?). But if returning is possible we can find the machine code that does the "return" function and encode it with the dancing bit algorithm. Since I want it to be the first instruction executed (otherwise, I want the camera to fail to start), it will be clear what the four bytes should be in the bin file. The thing that really matters is the positions of the four bytes. We can brute force this much easier. For four different bytes in a 8-byte segment, there are 8*7*6*5=1680 possible outcomes. If the four bytes are not all different, then this number will be even smaller.

Then we can brute force all the combinations. Once the camera boots up correctly, we know the first instruction is correct, by which we can find out the first half of the dancing bit pattern.

I will read the architecture manual... and sorry if the idea sounds naive.. :(
Logged
Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 59   Go Up
« previous next »
 

Related Topics