ELPH300HS aka IXUS220HS - Porting Thread

  • 836 Replies
  • 102935 Views
*

Offline tommi2water

  • ***
  • 157
  • IXUS 220 HS Firmware: 1.00c
  • Publish
    Re: ELPH300HS aka IXUS220HS - Porting Thread
    « Reply #300 on: 27 / November / 2011, 08:48:15 »
    Advertisements
    Good afternoon, jstanley! ;) (it is already 2:45 PM here in Germany, weekend nearly over)

    Fantastic comparison of photos!  :)


  • Publish
    Re: ELPH300HS aka IXUS220HS - Porting Thread
    « Reply #301 on: 27 / November / 2011, 09:53:55 »
    Reviewing movie_rec.c (100c vs 101a), and I'm seeing a lot of addresses that I'm not sure about.

    in both firmwares, GetZoomLensCurrentPosition is at 0xffadcc9c. 

    in 101a, MoveIrisWithAv is at 0xffaeecc4, compared to 0xffaeecac in 100c.

    so _somewhere_ between 0xffadcc9c and 0xffaeecc4, 0x18 bytes were inserted, shifting everything else back.

    problem is, when I diff movie_rec.c 100c vs 101a, I see a TON of unconverted addresses in that range.  how can we narrow down exactly where the insert took place?

    on second thought, I suppose that the movie recording task likely is the change that pushed other stubs back in the binary...

  • Publish
    Re: ELPH300HS aka IXUS220HS - Porting Thread
    « Reply #302 on: 27 / November / 2011, 10:19:46 »
    Reviewing movie_rec.c (100c vs 101a), and I'm seeing a lot of addresses that I'm not sure about.

    problem is, when I diff movie_rec.c 100c vs 101a, I see a TON of unconverted addresses in that range.  how can we narrow down exactly where the insert took place?

    on second thought, I suppose that the movie recording task likely is the change that pushed other stubs back in the binary...

    I believe that there is an easier way to do all of this.  Don't try to convert the movie_rec.c file by modifying addresses.  That's just got to be a source of errors unless you are really luckly.  Create your own file from scratch.   From an earlier post,  there seems to be only 3 routines that you need to find in your firmware :

    Code: [Select]
    void __attribute__((naked,noinline)) movie_record_task(){
    //ff985e5c      IXUS220: DONE

    void __attribute__((naked,noinline)) sub_FF985498_my(){

    void __attribute__((naked,noinline)) sub_FFAE6A58_my(){
    // FFAE6A58      IXUS220: DONE

    Find those in YOUR firmware,  export them,  build your own movie_rec.c and then make the small changes for that to hook into CHDK.


    *

    Offline tommi2water

    • ***
    • 157
    • IXUS 220 HS Firmware: 1.00c
  • Publish
    Re: ELPH300HS aka IXUS220HS - Porting Thread
    « Reply #303 on: 27 / November / 2011, 10:21:42 »
    Hmm, I don't think that it is important which 0x18 bytes have been inserted in the firmware, because we know and call the correct addresses of those functions.

    I stepped through movie_rec.c with disassembled Firmware in parallel in Notepad++. That's how I could find differences of movie_rec.c from original firmware. I did this for 100c, 101a and 101c.

    When I compare movie_rec.c (100c vs 101a) I get only 7 differences. And these differences I checked again and again in original firmware. I cannot find any error.

    What about substituting sub_0xFxxxxxxx_my calls with original sub_0xFxxxxxxx firmware calls and see if it still crashes?

    In movie_rec.c we have only two _my calls:
    sub_FF985498_my
    sub_FFAE6A44_my

    Just change them to original calls:
    sub_FF985498
    sub_FFAE6A44

    and look what happens. If it still crashes we are probably searching at the wrong place?

    --

    Uups, waterwingz was faster. Maybe start from scratch for that one file would be easier then just trying some stuff.


    *

    Offline tommi2water

    • ***
    • 157
    • IXUS 220 HS Firmware: 1.00c
  • Publish
    Re: ELPH300HS aka IXUS220HS - Porting Thread
    « Reply #304 on: 27 / November / 2011, 10:26:03 »
    Code: [Select]
    void __attribute__((naked,noinline)) movie_record_task(){
    //ff985e5c      IXUS220: DONE

    void __attribute__((naked,noinline)) sub_FF985498_my(){

    1.01c:
    void __attribute__((naked,noinline)) sub_FFAE6A58_my(){

    1.00c and 1.01a:
    void __attribute__((naked,noinline)) sub_FFAE6A44_my(){

    Find those in YOUR firmware,  export them,  build your own movie_rec.c and then make the small changes for that to hook into CHDK.

    The third function has different address for 100c/101a and 101c (if I'm not wrong ;)).

  • Publish
    Re: ELPH300HS aka IXUS220HS - Porting Thread
    « Reply #305 on: 27 / November / 2011, 10:27:11 »
    okay, I figured out how to answer my question; it's actually not quite as simple as a single 0x18-byte insert. 

    I used CHDK-PT to disassemble both firmwares in the region, then diffed the two disassemblies.

    both firmwares largely match up to address FFAE6D54.  at that location, there is a chunk of data that is 4 bytes *shorter* on 101a.  from this point through FFAE7850, code is shifted backward four bytes on 101a.  then 101a has substantially different code.  when things sync up again, 100c is at FFAE7904 and 101a is at FFAE791C.  101a stays 24 (0x18) bytes ahead of 100c from that point, as far as I've looked anyway.

    heh, while I was doing this, I see multiple replies telling me why this was the wrong thing to do.  pardon my n00bishness.  :-[


  • Publish
    Re: ELPH300HS aka IXUS220HS - Porting Thread
    « Reply #306 on: 27 / November / 2011, 10:39:51 »
    I stepped through movie_rec.c with disassembled Firmware in parallel in Notepad++. That's how I could find differences of movie_rec.c from original firmware. I did this for 100c, 101a and 101c.
    But if you point CHDK-PT at the addresses  in your original firmware where the routines are,  and then tell it which firmware file you want to port to,  it will do all that for you. It outputs the matching code from the target firmware.



    *

    Offline tommi2water

    • ***
    • 157
    • IXUS 220 HS Firmware: 1.00c
  • Publish
    Re: ELPH300HS aka IXUS220HS - Porting Thread
    « Reply #307 on: 27 / November / 2011, 10:49:51 »
    I didn't know how powerful CHDK-PT can be. :(

    During my next port ( ;)) I will use more of the CHDK-PT advantages.  :)


  • Publish
    Re: ELPH300HS aka IXUS220HS - Porting Thread
    « Reply #308 on: 27 / November / 2011, 12:16:10 »
    I didn't know how powerful CHDK-PT can be. :(

    During my next port ( ;)) I will use more of the CHDK-PT advantages.  :)

    Don't feel bad about it.  It'd be hard to use CHDK-PT effectively unless you understand what it's doing.  It was a magic box when I first tried to use it a couple days ago.  After these discussions, I have a much better idea how it works.

  • Publish
    Re: ELPH300HS aka IXUS220HS - Porting Thread
    « Reply #309 on: 27 / November / 2011, 12:19:31 »
    Don't feel bad about it.  It'd be hard to use CHDK-PT effectively unless you understand what it's doing.  It was a magic box when I first tried to use it a couple days ago.  After these discussions, I have a much better idea how it works.
    I can see now that the brief instructions assumed some background knowledge of CHDK.  When you are starting new,  there is learning curve that everyone must follow and overcome in their own way.  Even if I wrote a 50 page manual,  I suspect it would not get read -  people have to just figure things out for themselves (sometimes the hard way the first time).




     

    Related Topics