universal dumper - one more idea

[ewavr]

I just tested your first dumper on my A720.  I removed the signature, assigned the address to WriteSDCard directly and it actually wrote the firmware to the card.

Good!
Can you also test first or second dumper with signatures (generated by tools/gensig(.exe)) ? If it works, we can try to dump A650 in ten seconds

[jeff666]

Can you also test first or second dumper with signatures (generated by tools/gensig(.exe)) ? If it works, we can try to dump A650 in ten seconds

I made the signature and it seems to work (main.c attached). One thing is strange, though. wr() doesn't seem to return. At least the debug-led isn't turned off, but the data is written anyway.

Good luck to the A650-owners

Cheers.

[RyeBrye]

I made the signature and it seems to work (main.c attached). One thing is strange, though. wr() doesn't seem to return. At least the debug-led isn't turned off, but the data is written anyway.

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...

How would I go about finding that function so I can get this to work on the SD870?

Can you also test first or second dumper with signatures (generated by tools/gensig(.exe)) ? If it works, we can try to dump A650 in ten seconds

Real men dump by blinking! 

[Barney Fife]

Deleted

[ewavr]

How would I go about finding that function so I can get this to work on the SD870?

I also cannot find this function - it seems that dump is broken (piece of code is absent).
For example:
ROM:FF81019C                 B       aExporttoeven_0+8
Jump into string? Not real...

[jeff666]

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.

[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

[ewavr]

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

[jeff666]

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.

[RyeBrye]

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...

[ewavr]

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....

[jeff666]

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.

[ewavr]

Maybe, diskboot.bin is very long or OS reads whole cluster (up to 64k) with this file in RAM?

[jeff666]

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.

[ewavr]

diskboot is the usual 100k

My diskboot.bin is only 236 bytes long.