universal dumper - one more idea - page 3 - Firmware Dumping - CHDK Forum
« previous next »
Pages: 1 2 [3] 4 5 6 7   Go Down

universal dumper - one more idea

  • 63 Replies
  • 58850 Views
*

Offline jeff666

  • ****
  • 181
  • A720IS
Re: universal dumper - one more idea
« Reply #20 on: 25 / January / 2008, 08:59:13 »
Advertisements
Quote from: RyeBrye
I tried the siganture-based main.c in my SD870 and it didn't work... I have the dump for my SD870 loaded into IDA, and I don't see that the WriteSDCard is labeled after running through the DryOS CHDK.idc script...

WriteSDCard isn't part of the signature-file, you have to locate it yourself. Take a firmware in which you know the address, trace the path to the function and walk the same path on your own firmware.

To make sure the dumper is really not working ...
* note that it does not write a file. It starts writing at sector 1024 on the sd (not the partition)
* make sure that the code runs. My code didn't do anything at all using ewavr's makefile. Use the one you compiled your blinker with. Check this by enabling an led right after the start.

Also make sure to change the offset of your firmware or you might get unpredicted behaviour.

Cheers.
Logged
*

Offline RyeBrye

  • **
  • 73
  • SD-870
Re: universal dumper - one more idea
« Reply #21 on: 25 / January / 2008, 10:50:52 »
Quote from: jeff666 on 25 / January / 2008, 08:59:13
Quote from: RyeBrye
I tried the siganture-based main.c in my SD870 and it didn't work... I have the dump for my SD870 loaded into IDA, and I don't see that the WriteSDCard is labeled after running through the DryOS CHDK.idc script...

WriteSDCard isn't part of the signature-file, you have to locate it yourself. Take a firmware in which you know the address, trace the path to the function and walk the same path on your own firmware.

To make sure the dumper is really not working ...
* note that it does not write a file. It starts writing at sector 1024 on the sd (not the partition)
* make sure that the code runs. My code didn't do anything at all using ewavr's makefile. Use the one you compiled your blinker with. Check this by enabling an led right after the start.

Also make sure to change the offset of your firmware or you might get unpredicted behaviour.

Cheers.

I modified the code to blink once when it started, and then to blink when it was writing... I see it blink when it loads so I know it is running - but I don't see any other blinks. I checked the card with hexedit, and I just see a bunch of 00's around block 1024
Logged
*

Offline ewavr

  • ****
  • 1057
  • A710IS
Re: universal dumper - one more idea
« Reply #22 on: 25 / January / 2008, 12:20:06 »
Quote from: RyeBrye on 25 / January / 2008, 10:50:52
I modified the code to blink once when it started, and then to blink when it was writing... I see it blink when it loads so I know it is running - but I don't see any other blinks. I checked the card with hexedit, and I just see a bunch of 00's around block 1024
You can try main.c from attachment - on every signature match it blinks. How many signature matches you find?
If none, you can play with signature length and matches condition (success>fail). If one or two - it is very good.

edit: from your dumped firmware: WriteSDCard=0xFF9182FC
« Last Edit: 25 / January / 2008, 13:25:52 by ewavr »
Logged
*

Offline jeff666

  • ****
  • 181
  • A720IS
Re: universal dumper - one more idea
« Reply #23 on: 25 / January / 2008, 15:33:24 »
Since the location of WriteSDCard seems a little difficult, I approached the idea of locating the function that initializes a pointer to Read/WriteSDCard and use the location that is set there.

This seems promising. The code is identical on all DryOS-cams I checked. Attached is a file of this function in A720, S5 (1.01A + B), G9 and SX100. Bad news is that the function exists, but looks differently on VxWorks (just checked A710, though).

A code example (A720) for clarification:
Code: [Select]
ROM:FFC3EC9C sub_FFC3EC9C                            ; CODE XREF: sub_FFC3F0CC+Cp
ROM:FFC3EC9C                 LDR     R1, =0x2BA0
ROM:FFC3ECA0                 LDR     R1, [R1,#0xC]
ROM:FFC3ECA4                 CMP     R1, #0
ROM:FFC3ECA8                 CMPEQ   R0, #0
ROM:FFC3ECAC                 BXNE    LR
ROM:FFC3ECB0                 MOV     R1, #0
ROM:FFC3ECB4                 LDR     R0, =0x11800
ROM:FFC3ECB8                 STR     R1, [R0,#0x34]
ROM:FFC3ECBC                 STR     R1, [R0,#0x38]
ROM:FFC3ECC0                 MOV     R1, #3
ROM:FFC3ECC4                 STR     R1, [R0,#0x3C]
ROM:FFC3ECC8                 LDR     R1, =ReadSDCard
ROM:FFC3ECCC                 STR     R1, [R0,#0x4C]
ROM:FFC3ECD0                 LDR     R1, =WriteSDCard
ROM:FFC3ECD4                 STR     R1, [R0,#0x50]
ROM:FFC3ECD8                 BX      LR

If we locate this piece of code, we do:
* cmd_LDR = offset_func + (13*4) ==> "LDR R1, =WriteSDCard"
* ptr_WriteSDCard = offset_func + (13*4) + (cmd_LDR & 0xff) + 8
* WriteSDCard = *ptr_WriteSDCard

Explanation:
* offset_func is the starting location of the above function (which needs a name, btw. Any suggestions?)
* 13 commands later is the pointer to WriteSDCard, each command is 4 bytes long
* The pointer is not direct but points to a nearby memory location, offset is one byte unsigned.
* Add this amount + 8 (why 8?) to the location of the LDR command and you get the address that holds the actual functions location.
* read the actual address and use it as function pointer.

Right now I'm to tired to write (functioning) code. So if anybody wants to give it a shot...

Cheers.
Logged
*

Offline RyeBrye

  • **
  • 73
  • SD-870
Re: universal dumper - one more idea
« Reply #24 on: 25 / January / 2008, 16:02:43 »
Quote from: ewavr on 25 / January / 2008, 12:20:06
edit: from your dumped firmware: WriteSDCard=0xFF9182FC

Sweet :) Now I just need to learn how to use IDA better so what you just did doesn't seem like magic to me... because I did my best to try to poke around and find it...
Logged
*

Offline ewavr

  • ****
  • 1057
  • A710IS
Re: universal dumper - one more idea
« Reply #25 on: 25 / January / 2008, 16:09:19 »
How about RAM search?
Code: [Select]
#define FW_ADDRESS      0xFFC00000
#define FW_SIZE         0x3F0000
#define START_SECTOR    1024
#define LED_PR 0xC0220084

inline void debug_led(int state)
{
    volatile long *p=(void*)LED_PR;
    if (state)
p[0]=0x46;
    else
p[0]=0x44;
}


typedef int (*f_w)(int, int, int, int); // drive(?), start sector, number of sectors, address
 
int main()
{
  int i;
  f_w wr;
  for (i=0x1900;i<0xF0000;i+=4)
   if ((*(unsigned int*)(i+0x34)==0) &&
       (*(unsigned int*)(i+0x38)==0) &&
       (*(unsigned int*)(i+0x3C)==3) &&
       (*(unsigned int*)(i+0x4C)>FW_ADDRESS) &&
       (*(unsigned int*)(i+0x50)>FW_ADDRESS) ) {

        wr=(f_w)*(int*)(i+0x50);
        debug_led(1);
        wr(0,START_SECTOR,FW_SIZE/512,FW_ADDRESS);
        debug_led(0);
}
   while(1);
   return 0;
}


It works on my A710....
Logged
*

Offline jeff666

  • ****
  • 181
  • A720IS
Re: universal dumper - one more idea
« Reply #26 on: 25 / January / 2008, 17:02:44 »
Quote from: ewavr on 25 / January / 2008, 16:09:19
How about RAM search?

It works on my A710....

Seems logical but doesn't work on my A720.

I tried
* original search method => didn't find anything
* skip search, set i to 0x11800 (offset for STRs) => no data written
* set "wr=(f_w)*(int*)(0x11850)" => no data written

I also tried "wr=(f_w) (void*) 0xFFCF51B0", which worked (but isn's any progress).

Next I will write the memory (0x1900 - 0xf0000) to the card to find out if it is cleared upon diskboot-start.

Update: The memory has actually been cleared. Nice to know it works for VxWorks, though. We should keep this method.

For DryOS it's go-for-the-signature now. I'll rewrite the code to use the offsets in the firmware and see if this will work.

Cheers.
« Last Edit: 25 / January / 2008, 17:10:20 by jeff666 »
Logged
*

Offline ewavr

  • ****
  • 1057
  • A710IS
Re: universal dumper - one more idea
« Reply #27 on: 25 / January / 2008, 17:17:09 »
Maybe, diskboot.bin is very long or OS reads whole cluster (up to 64k) with this file in RAM?
Logged
*

Offline jeff666

  • ****
  • 181
  • A720IS
Re: universal dumper - one more idea
« Reply #28 on: 25 / January / 2008, 17:34:11 »
Quote from: ewavr on 25 / January / 2008, 17:17:09
Maybe, diskboot.bin is very long or OS reads whole cluster (up to 64k) with this file in RAM?

diskboot is the usual 100k, but that could actually be it. 128k is 0x020000 which would definitely overwrite the necessary memory. I'll check this.
Logged
*

Offline ewavr

  • ****
  • 1057
  • A710IS
Re: universal dumper - one more idea
« Reply #29 on: 25 / January / 2008, 17:38:17 »
Quote from: jeff666 on 25 / January / 2008, 17:34:11
diskboot is the usual 100k

My diskboot.bin is only 236 bytes long.
Logged
Pages: 1 2 [3] 4 5 6 7   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal