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

universal dumper - one more idea

  • 63 Replies
  • 57995 Views
*

Offline RyeBrye

  • **
  • 73
  • SD-870
Re: universal dumper - one more idea
« Reply #40 on: 02 / February / 2008, 03:03:32 »
Advertisements
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.

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

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

Logged
*

Offline jeff666

  • ****
  • 181
  • A720IS
Re: universal dumper - one more idea
« Reply #41 on: 02 / February / 2008, 05:31:41 »
Quote from: RyeBrye
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.
Logged
*

Offline RyeBrye

  • **
  • 73
  • SD-870
Re: universal dumper - one more idea
« Reply #42 on: 02 / February / 2008, 14:40:54 »
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"
Logged
*

Offline ewavr

  • ****
  • 1057
  • A710IS
Re: universal dumper - one more idea
« Reply #43 on: 02 / February / 2008, 15:31:12 »
Do you fill memory with zero bytes before WriteSDCard call?
Logged
*

Offline RyeBrye

  • **
  • 73
  • SD-870
Re: universal dumper - one more idea
« Reply #44 on: 02 / February / 2008, 16:17:28 »
Quote from: ewavr on 02 / February / 2008, 15:31:12
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?
« Last Edit: 02 / February / 2008, 16:21:07 by RyeBrye »
Logged
*

Offline RyeBrye

  • **
  • 73
  • SD-870
Re: universal dumper - one more idea
« Reply #45 on: 02 / February / 2008, 22:13:44 »
Here's the code I'm using. When it runs, I have it flash through my LEDs so I know it is working - and I have it flash them all 3 times if it finds the signature at the address my dump predicts it to be.

When it runs, it flashes three times. Then, it turns on the write LED, and does nothing more.

Of course... the part that sucks is that Nothing gets written to the card :(

Code: [Select]
#define FW_ADDRESS      0xFF810000
#define FW_SIZE         0x400000
#define START_SECTOR    256

// maximum number of hex digits this will be outputting
// (there is a fudge factor of 10 additional digits built in
//  to help avoid overrun...)
#define HEX_LENGTH 8
#define LED_PR 0xC02200CC   
#define LED_GR 0xC0220136
#define LED_OR 0xC0220133
#define LED_AF 0xC0223030

#define DOT_DURATION          0.05
#define DOT_PAUSE             0.05
#define DASH_DURATION         0.2
#define DASH_PAUSE            0.2
#define BETWEEN_NUMBER_PAUSE  0.3

#define DEL 50000

// side note...
// wouldn't it be ironic if we inlined the function
// that is supposed to kill time?
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 led_on(long led_addr) {
    volatile long *p;
    p=(void*)led_addr;
    *p=0x46;
}

inline void led_off(long led_addr) {
    volatile long *p;
    p=(void*)led_addr;
    *p=0x44;
}

// output a dot on the given LED address
// (a 'dot' is a quick blip of the LED)
void output_dot(long led_addr) {
delay(DOT_PAUSE);
    led_on(led_addr);
    delay(DOT_DURATION);
led_off(led_addr);
#endif
}

// output a dash on the given LED address
// (dash is longer than a dot)
void output_dash(long led_addr) {
delay(DASH_PAUSE);
    led_on(led_addr);
    delay(DASH_DURATION);
    led_off(led_addr);
}

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;
output_dot(LED_OR); output_dot(LED_GR); output_dot(LED_OR);
output_dot(LED_PR); output_dot(LED_AF);

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) ) {
output_dot(LED_OR);
output_dot(LED_OR);
output_dot(LED_OR);
delay(0.5);

wr=(f_w)*(unsigned int*)(i+0x50);
// blink three times if its at the right address
// (note - on my camera, it blinks 3 times with this function...)
if ((unsigned int)wr == (unsigned int)(0xFF9182FC)) {
int p;
for (p=0;p<3;p++) {
led_on(LED_AF);
led_on(LED_GR);
led_on(LED_PR);
delay(0.1);
led_off(LED_AF);
led_off(LED_GR);
led_off(LED_PR);
delay(0.1);
}
}
else {
// if none of the above addresses match - display error
led_on(LED_OR);
delay(0.1);
led_off(LED_OR);
delay(0.1);
led_on(LED_OR);
delay(0.1);
led_off(LED_OR);
}
// fill some memory with zeroes; "simulate" large diskboot
        // WARNING: the starting address is a guess
for (j = 0x2e20; j<0x27100; j+=4) {
p = (int *) j;
*p = 0;
}

// delay to allow time to unlock the memory card
// if I'm trying to do that...
int q = 0;
for (q=0; q<50; q++) {
led_on(LED_GR);
delay(0.01);
led_off(LED_GR);
delay(0.01);
}
delay(0.1);

led_on(LED_OR);
wr(0,START_SECTOR,FW_SIZE/512,FW_ADDRESS);
led_off(LED_OR);

}

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

while(1);
return 0;
}

I don't see anything I'm doing wrong... I changed the sector to sector 256 because that one is full of zeroes on my SD card and it's easier to check quickly to see if it wrote anything.
Logged
*

Offline GrAnd

  • ****
  • 916
  • [A610, S3IS]
    • CHDK
Re: universal dumper - one more idea
« Reply #46 on: 03 / February / 2008, 02:41:03 »
Quote from: RyeBrye on 02 / February / 2008, 16:17:28
How does the RAM map on these? What would be the largest value that I should write 0's to? 0xF000000?

0x02000000. The memory size is 32MB. The addresses 0x0 - 0x1900  are reserved.
Logged
CHDK Developer.
*

Offline ewavr

  • ****
  • 1057
  • A710IS
Re: universal dumper - one more idea
« Reply #47 on: 03 / February / 2008, 03:52:27 »
Quote from: RyeBrye on 02 / February / 2008, 22:13:44
I don't see anything I'm doing wrong...

All is correct, but...
WriteSDCard() is complex function, it uses different memory locations, semaphores etc - I was surprised that it could work after OS death.
Logged
*

Offline whim

  • ******
  • 2046
  • A495/590/620/630 ixus70/115/220/230/300/870 S95
Re: universal dumper - one more idea
« Reply #48 on: 21 / February / 2008, 08:25:00 »
@Jeff666
You wrote in reply #35 - 26/Jan/2008:
Quote
I already considered running the whole firmware in a virtual machine that is started via diskboot Smiley
Hi!
I was about to post a question if anybody has experience with / ever tried to boot a Canon primary and/or
CHDK on an ARM emulator, did a search for virtual machine, and found this thread.
So, about the quote above, have you ever tried this ?
So far I found this sympathetic-looking open source project:
 
Wiki Manual
Source and binaries

but you, or other posters here might know others/better ones.

oh, and sorry to butt in on this thread with something only
remotely related to the subject.

wim
« Last Edit: 21 / February / 2008, 10:40:35 by whim »
Logged
*

Offline quietschi

  • ***
  • 116
  • Ixus70 102a
Re: universal dumper - one more idea
« Reply #49 on: 12 / March / 2008, 19:58:28 »
Hi

Only for information. I tried the udumper.zip on my Ixus70_sd1000 and get a correct dump on my first try.
Really nice, much easier than the blinker version

quietschi
Logged
Pages: 1 2 3 4 [5] 6 7   Go Up
« previous next »
 

Related Topics
SimplePortal 2.3.6 © 2008-2014, SimplePortal