universal dumper - one more idea

[jeff666]

My diskboot.bin is only 236 bytes long.

My cam won't load diskboot if the file isn't at least 20k. It just hangs then (confirmed by debug-led which blinks on start).

update: with a shorter diskboot, an address is actually found, but no data is written. I'll check if the found address is ok.

[ewavr]

My cam won't load diskboot if the file isn't at least 20k. It just hangs then (confirmed by debug-led which blinks on start).

Yes, this also sometimes happens with a710, but not in this case. I tried 16M, 1G & 2G cards - all works.
And 20k+0x1900<0x11800.

[ewavr]

update: with a shorter diskboot, an address is actually found, but no data is written. I'll check if the found address is ok.

Firmware can blink this address (if it is correct) to user in Morse code 
Or can fill 100k memory with zeroes and then call WriteSDCard()

[jeff666]

Firmware can blink this address (if it is correct) to user in Morse code 

I'd rather go with a good old "if (wr == 0xMYADDR) blink_long else blink_short"

Or can fill 100k memory with zeroes and then call WriteSDCard()

This actually seems necessary. If diskboot is short, not even a manual assignment of the correct offset writes data. If I blow it up to 100k, it works, again.

I'll try to figure out, what needs to be cleared.

[RyeBrye]

Once I can test and verify it works on my SD870 - I'll race over to the local camera store and see if I can dump the 650

Also - if you want to blink stuff out I wrote some code when I was searching for the AF-LED that will blink out numbers... could easily make it blink out hex if someone cared...

Chances are, however, this dumper will be used by people even before they know any LED addresses - so you might want to write some signature checking to find the LED to blink on first

[jeff666]

Once I can test and verify it works on my SD870 - I'll race over to the local camera store and see if I can dump the 650

Well, here you are: http://www.zshare.net/download/68797117f280ae/
The 650 has the same LED addresses as the 720

Chances are, however, this dumper will be used by people even before they know any LED addresses - so you might want to write some signature checking to find the LED to blink on first

I already considered running the whole firmware in a virtual machine that is started via diskboot


Here's the code:

Code: [Select]

#define FW_ADDRESS      0xFFC00000
#define FW_SIZE         0x400000

#define START_SECTOR    1024
//#define LED_PR 0xC0220084
#define LED_PR 0xC02200c4   

#define DEL 50000
void delay(float i){
int j;
j = i * 30 * DEL;
while(--j) {
asm("nop\n");
asm("nop\n");
asm("nop\n");
asm("nop\n");
}
}

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, j;
int tw, tr;

int *p;

f_w wr;

debug_led(1); delay(2); debug_led(0); delay(2);

  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)*(unsigned int*)(i+0x50);

// check if found address was expected and blink state (8:good, 3:bad)
/*
if ((void*) wr == (void*) 0xffcf51b0) {
j = 8;
} else {
j = 3;
}

for (; j>0; j--) {
debug_led(1); delay(0.5);
debug_led(0); delay(0.5);
}
*/

// fill some memory with zeroes; "simulate" large diskboot
                // WARNING: the starting address is a guess
for (j = 0x1c00; j<0x30000; j+=4) {
p = (int *) j;
*p = 0;
}

debug_led(1);
wr(0,START_SECTOR,FW_SIZE/512,FW_ADDRESS);
debug_led(0);
}


// would blink 5 times if wr() would return (which it doesn't, but still works)
for (j=5; j>0; j--) {
debug_led(1); delay(0.3);
debug_led(0); delay(0.3);
}

while(1);
return 0;
}

Remember to keep the diskboot short. I got strange effects with the 20k diskboot. Several tries may be necessary.

Needless to say, that I wouldn't post the code if it wouldn't work, right?

Cheers.

[RyeBrye]

I tested out some things... the SD870 doesn't work with that signature...

I hardcoded in the address 0xFF9182FC to see if that would work, but no go... 

I also tried 0xFF9181A4 to see if that would work, and it didn't work either.

I am using a 32 meg bootable SD card, and the 100k diskboot image. I'm scanning the entire card each dump attempt to search for the firmware, but not finding it

Oh well... I'll try some more things later and see how it goes.

[ewavr]

Latest jeff's dumper works on A650 - one guy from russian forum got the dump. After verification I'll post this dump in corresponding topic.
"The triumph of mind over sarsaparilla"

[mx3]

Latest jeff's dumper works on A650 - one guy from russian forum got the dump.

I like it

[RyeBrye]

Here's a helper function that will blink out the hexadecimal value of an unsigned int - one digit at a time in a very easy-to-use format....

Usage:
1. Define LEDs you will use

• If you know multiple LEDs, you are in luck - because you can ping-pong between them to make it easy to identify when one digit ends and the next digit begins

2. Call function output_hex_address(unsigned int value)

It's pretty straightforward. Should be helpful for debugging any signature-searching functions...

[RyeBrye]

How is this supposed to work?

If I load up a relatively short diskboot (40k or so) - the signature finds something and it will do its thing.

Where is the file supposed to be output on the flash disk? I see sector 1024 in the code - but if I open up hexedit in sector mode, and jump to sector 1024 - I dont' see a dump there or in any of the sectors around that area.

If I search the entire SD card for strings that would be in a dump of the firmware (such as "meminfo" or something else I randomly snag out of my dump file) - I don't find anything - which leads me to believe that the WriteSDCard function on the SD870 is taking arguments differently than it is on the other cameras... or that I'm doing something wrong.

I'll get the exact address that the signature is finding and post it here - at first glance at the blinking, it seems like it is matching up to the one I find in my dump file.

................
...............

................
...............
..........

[jeff666]

How is this supposed to work?

It works like this:

The Firmware (both VxWorks and DryOS) has a function called WriteSDCard. This function works without running OS and writes sectors on the card. This function has to be found. WriteSDCard itself differs a little on different devices, so checking for it using signatures is not an option.

A pointer to WriteSDCard (and its companion ReadSDCard), as well as some other (on each model identical) numbers are written to RAM during startup by some other function. This function also exists in both VxWorks and DryOS, but differs slightly between OSes - it's absolutely identical in all DryOS-dumps, though.

Ewavr's method is to check the RAM for those numbers and get the pointer to WriteSDCard from there. A problem I encountered was that the location in the RAM was very near after the diskboot-entrypoint (0x1900) and could easily be overwritten by the large zero-padded diskboot-program. Still diskboot.bin had to be padded (on my A720) to certain extend or StartDiskboot wouldn't load it. It's possible that your 40k diskboot.bin will overwrite the numbers in RAM we are looking for. The maximum size for my device would be about 25k.

Another method would be to locate the function that initializes the pointers and extract the address from it. I started on this approach but liked ewavr's method more as it is OS-independent.

Code examples have been posted in this thread.

Cheers.

[RyeBrye]

Jeff - thank you for your thorough explanation... but I think I should have been more specific in my question.

I understand how it searches the memory to find the address of the function... that part makes sense. I also understand that by calling the write function, it should write something out to the card... this makes sense.

The part I don't understand is - how do you find the file that is written out to the card? Is it at sector 1024 (0x0080000)?

I've run it - and even with my 40k diskboot, it's clearly found an address by the signature (meaning my diskboot didn't overwrite what it was looking for) - and then it turns on the debug LED before writing... and since the write function doesn't return - the LED will stay on indefinitely. After about 20 or 30 seconds I pull the battery and the card and look at that sector and see nothing

(With a 100k+ diskboot, the scanner does not find the address)

The memory-scanning signature card method definitely does work. It finds the correct address from my dump (0xFF9182FC)

The part that isn't working, it seems, is the part that is supposed to actually write to the card... On my 32 meg card, it's incredibly easy to scan the entire thing for ASCII strings... that is time-consuming to do on my 2GB card.

Should I test it out by hard-coding the address and using a larger diskboot to get it to work?

Since I already have a dump, it's not critical for me to get another one by dumping to the SD card - but if I can get the kinks ironed out on mine with this universal dumper it might help to make it more truly "universal"

[ewavr]

Do you fill memory with zero bytes before WriteSDCard call?

[RyeBrye]

Do you fill memory with zero bytes before WriteSDCard call?

I do... although in my case I have to start at a higher location to avoid overwriting my code. I guess now I will go back and strip down my sd dumper to try again with a more bare-bones approach like the one posted above.

Since I was lazy, and wanted to make it easy to output the hex address that it was finding - I linked in with some convenience methods that are probably overkill (i.e. using sprintf to spit out the hex, then using atol to get it back into a digit ) - so my diskboot actually has about 32 or 40k of code in it from those libraries. I have to then increase the starting value that I'm writing 0's from or else I find that the execution hangs - likely because I just overwrote my code with 0's

Now that I've verified that it is actually finding the right address, I can strip out all of that unneeded code to get back to a really really small diskboot and then write 0's the way it was specified before.

Although... I did use that code first and when it didn't work is when I started adding in more code to figure out what exactly was going on...

Perhaps the issue is that I need to increase the number of 0's that are written to memory to simulate the large diskboot...

I'll play around with some more things later. But... if it works - something should be written to 0x0080000 on the SD card right? (not the partition, but the main sd card)?

How does the RAM map on these? What would be the largest value that I should write 0's to? 0xF000000?