40D Disk Dumping. More Trials

ASalina

40D Disk Dumping. More Trials

« on: 08 / June / 2008, 17:45:02 »

Advertisements

I tried several things and still no luck.

Things I tried:

1: I discovered that I did make a bad .fir file the first time, and that's why the camera rebooted.

2: I added code to turn the blue led on before calling save_bup().
I packed this the right way and tried it. The led came on and stayed on until just before I removed the battery. The led went off by itself, after maybe 15 seconds.

3: I added more code to turn the led off after returning from save_bup().
Now the led didn't go on at all. I don't know why. Camera did not reboot.

4: I tried creating DUMP.BUP as an empty file on the CF card (also DUMP, without the extension), and ran the program. DUMP.BUP and DUMP are both still empty.

PS: If it matters, my CF card has been edited to be bootable ("EOS_DEVELOP" and "BOOTDISK" in the header) The card is empty otherwise.

Update: I just tried moving DUMP.BUP and DUMP to the /misc directory.
Still no dump. No led. Camera just hangs.

« Last Edit: 08 / June / 2008, 18:03:55 by ASalina »

Logged

ASalina

Re: 40D Disk Dumping. More Trials

« Reply #1 on: 08 / June / 2008, 22:28:02 »

Do we know what drive letter is assigned to the CF card?
Tracing the subs that set up for writing seem to check for the drive letter in the filename string. I see lots of comparisons to upper and lower case 'c' and tests to be sure that the first char in the string is less than 'd.'

Perhaps the problem is that the file name "DUMP" by itself isn't enough, and it need to have the drive letter, such as "C:\DUMP"
If anyone knows the CF card's drive letter I'll give it a try.

And should it be "C:\DUMP" or "C\DUMP" or what?

Update: I think I've tried all combinations of /A/ /B/ /C/ A:\ B:\ C:\ and
A\ B\ C\

None of them worked.

I should say that the Drive Activity LED (red) flashed briefly (no matter what drive letter I used) after the dumper had loaded, decrypted, and I'm sure started up. This leads me to believe that at least the dumper isn't hanging; it's making an attempt and returning unsuccessfully.

Blue LED still won't light up.

« Last Edit: 08 / June / 2008, 23:43:35 by ASalina »

Logged

mx3

372

Re: 40D Disk Dumping. More Trials

« Reply #2 on: 09 / June / 2008, 03:10:21 »

hm. intresting.
what does it mean?

Code: [Select]

RAM:00807498                 LDR     R3, =drvA_0x1D50
....
RAM:008074B4                 BL      umSearchFile

RAM:008074E4                 LDR     R3, =drvB_0x1D54
....
RAM:00807500                 BL      umSearchFile


if( present_drive_A ) {
 umSearchFile( X, "A:/")
} else if( present drive B){
 umSearchFile( X, "B:/")
} else {
 .....
}

_________________________________________________

and this:

Code: [Select]

[UPD] 0x%x = umGetProperty(PROP_CARD1_EXIST)
[UPD] 0x%x = umGetProperty(PROP_CARD2_EXIST)

RAM:00807420                 MOV     R0, #0x8000001D
RAM:00807424                 LDR     R1, =drvA_0x1D50
RAM:00807428                 MOV     R2, #4
RAM:0080742C                 BL      umGetProperty

RAM:00807450                 LDR     R2, =aUpd0xXUmgetpro


RAM:0080745C                 MOV     R0, #0x8000001E
RAM:00807460                 LDR     R1, =drvB_0x1D54
RAM:00807464                 MOV     R2, #4
RAM:00807468                 BL      umGetProperty

RAM:0080748C                 LDR     R2, =aUpd0xXUmgetp_0

Logged

skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

ASalina

Re: 40D Disk Dumping. More Trials

« Reply #3 on: 10 / June / 2008, 09:07:21 »

More experiments. I got the blue LED working. I have it light up after return from save_bup(). It does light up, proving that save_bup is executed and returns. I tried calling UPD_SaveRasenToFile() to see if I could get anything to be written to a file. Nothing got written but the blue LED went on.

In save_bup(), several strings are output to TryPostEvent that have "find bup" in them. This leads me to think that the .bup file may have to exist on the disk before any writing takes place. I've tried putting empty files on the disk to test that, but did not think to put files of the correct size (filled with 0x0's).
I'll try that next.

There is a status code in R0 on exit from save_bup() and UPD_SaveRasenToFile(). Can I just say:

int status;
status = save_bup(FADDR, FSIZE, "DUMP");

to get the contents of R0??

If so I can at least blink out the return status.
I'll have to read up on accessing the other registers from within C code.

Logged

mx3

372

Re: 40D Disk Dumping. More Trials

« Reply #4 on: 10 / June / 2008, 09:10:11 »

Quote from: ASalina on 10 / June / 2008, 09:07:21

More experiments. I got the blue LED working. I have it light up after return from save_bup(). It does light up, proving that save_bup is executed and returns. I tried calling UPD_SaveRasenToFile() to see if I could get anything to be written to a file. Nothing got written but the blue LED went on.

In save_bup(), several strings are output to TryPostEvent that have "find bup" in them. This leads me to think that the .bup file may have to exist on the disk before any writing takes place. I've tried putting empty files on the disk to test that, but did not think to put files of the correct size (filled with 0x0's).
I'll try that next.

There is a status code in R0 on exit from save_bup() and UPD_SaveRasenToFile(). Can I just say:

int status;
status = save_bup(FADDR, FSIZE, "DUMP");

to get the contents of R0??

If so I can at least blink out the return status.
I'll have to read up on accessing the other registers from within C code.

I suggest you to swich to plan B:
open
write
close

dumper2

Logged

skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

ASalina

Re: 40D Disk Dumping. More Trials

« Reply #5 on: 10 / June / 2008, 09:33:53 »

Quote from: mx3 on 10 / June / 2008, 09:10:11

I suggest you to swich to plan B:
open
write
close

dumper2

I've been working on that too. That's much harder. :-)
I did find functions called FSUabsWrite_90FD4C and cfWriteBlk_919A40. Have you seen them yet? cfWriteBlk is a lower level function with a pointer to it stored in a table
starting at =0x60E0 (+4 for cfWriteBlk) in the function CF_DeviceCreate_918AC0, but I haven't yet found a func that references that table.

Logged

ASalina

Re: 40D Disk Dumping. More Trials

« Reply #6 on: 10 / June / 2008, 10:25:41 »

catFsOpen_930098: called from catFsCreate_93B2CC with R2 = 0x601 (O_TRUNC|O_CREAT|O_WRONLY) = flags.

R0 may have the filename. I don't know. Same for R1, their values get passed in through catfsCreate but since no function that I've found so far calls catfsCreate directly I can't tell what is being loaded into those registers. In Unix, the open syscall is:

open(char *path, int flags, mode_t mode);

For catfsOpen, since R0 = path, and R2 = flags, it seems to be:

catfsOpen(char *path, mode_t mode, int flags);

Update: catfsOpen() sends the string "[CFS] catFsOpen (%s) (%#x)"
to TryPostEvent(), so maybe there is no mode param, and R1 is not used.
I'm still not sure.

Update #2: I gave it a try. I called catfsCreate("A:\DUMP.BIN"), and it returned and the blue LED lit up. No file on the CF card. I then called fd = catfsCreate("A:\DUMP.BIN") and then catfsClose(fd). Now the blue LED did not light up, so execution hung up in catfsClose(). Maybe the returned fd = -1 (error).

« Last Edit: 10 / June / 2008, 11:11:28 by ASalina »

Logged

mx3

372

Re: 40D Disk Dumping. More Trials

« Reply #7 on: 10 / June / 2008, 14:09:03 »

RAM:009925C8 fopen ; CODE XREF: fopen_2+34j
RAM:009925C8 ; DATA XREF: RAM:00001A40o
RAM:009925C8 ; RAM:0099B740o

Logged

skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

mx3

372

Re: 40D Disk Dumping. More Trials

« Reply #8 on: 10 / June / 2008, 14:17:58 »

also i advice you to load into ida file 40d00105.fir_1_flasher.dat in new segment to address 1900

bin_extract 40d00105.fir_1_flasher.dec 19B4E0 2464 40d00105.fir_1_flasher.dat

bin_extract.exe (84 kB - downloaded 132 times.)

bin_extract.cpp (0.5 kB - downloaded 136 times.)

Logged

skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

owerlord

115

Re: 40D Disk Dumping. More Trials

« Reply #9 on: 10 / June / 2008, 16:21:01 »

I don't want to discourage you, but:
The flasher file procedures propably won't work (I many of them in 400D). I think that if ASalina have a working blinking code - the easiest way is to blink the thing out. Or at least a fragment (long enouth to breake the code.)

Logged