universal dumper - one more idea

[mx3]

1) there is a code in FLASH(ROM) which can load files from SD card without loading of OS (Rescue Loader code)
2) it is unknown if Rescue Loader contain code which can write to SD card when OS unitialized ( it is logical there must be no one)
3) when diskboot.bin is loaded and executed SD card controller (if it exists) already initialized
4) Running OS must have some primitive functions to read/write sectors which can work without OS initialized
5) my camera(a630) can work with SD and MMC cards . I don't know how camera operates with any of them and if there is a difference

lets get to the point:
1) we load .bin file
2) OS is unitialized
3) .bin file code finds SD/MMC sector read/write functions using signatures
4) .bin file writes dump into SD/MMC card

[jeff666]

1) there is a code in FLASH(ROM) which can load files from SD card without loading of OS (Rescue Loader code)

Funny thing. I went over my A720-Dump yesterday, noticed the Rescue loader and had the same Idea

It seem to me like the rescue loader is started by default by the camera and checks if the original firmware is "ok" (just checks one byte, as far as I understand), jumps to the real firmware if the check is successful or loads DISKBOOT.BIN, ROMWRITE.BIN, UPGRADER.BIN from SD otherwise.

The rescue loader is pretty much at the end of the firmware.  The initial function refers to the string #RomStarter Ver1.02 for EC226\n\r (version and ECxx may differ).

2) it is unknown if Rescue Loader contain code which can write to SD card when OS unitialized ( it is logical there must be no one)

Indeed there's no need for code to write to the card, but the rescue loader is pretty small and should get us an idea about how card access works. It should be possible to get the rest of the pieces from the regular firmware.

3) when diskboot.bin is loaded and executed SD card controller (if it exists) already initialized

Maybe. I made a boot-loop in my A720 by copying the restart function to my own code (as suggested by CHDK). We could also take the main function of the rescue loader, strip it of the firmware-ok-check and have our code rerun by the rescue functions.

I noticed a difference in the rescue loader from regular SD access. The rescue loader refers to the files by their name. The regular functions refer to the files by a device indicator ("A/") plus the filename. It might not mean much, I just mentioned for completeness.

4) Running OS must have some primitive functions to read/write sectors which can work without OS initialized
5) my camera(a630) can work with SD and MMC cards . I don't know how camera operates with any of them and if there is a difference

4) I don't think that works, but analyzing the rescue loader might get useful results.
5) Probably it doesn't make any difference to the software.

lets get to the point:
1) we load .bin file
2) OS is unitialized
3) .bin file code finds SD/MMC sector read/write functions using signatures
4) .bin file writes dump into SD/MMC card

As already stated, there may be no code to write to the card in the rescue loader. I suggest:
3) ...finds functions using signatures, extracts necessary addresses for IO and uses own functions for accessing the card that were derived from the original firmware.

Cheers.

[mx3]

so what is the next step?

- find sector read/write functions (analyse several dumps)
- make signatures (I m not sure how)
- bring the pieces together - make the dumper

have i missed something?

[mx3]

of course it is required to include into dumper support of FAT16
there are some opensource projects which can be used

[jeff666]

I'm not sure if SD-access is actually sector based. It may also be file-based (leaving low-level access to the chipset).

I would
1. try jumping into the sd-init-functions in the rescue-loader and try some file-access using them.
2. compare different firmware versions for (IO-)address differences.
3. write own SD-IO using fixed addresses for own camera model, Implement writing
4. use signatures to find a cam's own functions and extract their IO-addresses. Use them.

I'm busy right now trying to get dryos booting, but I'll do tests and compare your results with the firmware I'm familiar with.

I discovered some minor problem. Some of the firmware files are incomplete and lack the rescue loader. Thus they can't be examined.

Another problem may be the write-protect that triggers the bootdisk-loader and may prevent writing the card.

Cheers.

[GrAnd]

I discovered some minor problem. Some of the firmware files are incomplete and lack the rescue loader. Thus they can't be examined.

Yes. The firmwares (the link to which I posted) does not have boot loader block which is loacated at 0xFFFF0000 address. But I should have a couple with this block intact.

[GrAnd]

Firmwares with boot loader - http://www.zshare.net/download/590221805aee35/

[RyeBrye]

Another problem may be the write-protect that triggers the bootdisk-loader and may prevent writing the card.

It would be rather ugly - but if you got the rest of it working you could have the user boot the camera, and then after a few seconds remove the SD card and replace it with the lock switch turned off...

While working with the blinker code, I learned that my SD870 will at least not read from the SD card after the program is loaded into memory, and the SD card could be removed without any problems.

For a dumper, it would be hard to indicate when exactly it was safe to pull the card (can't exactly blink an LED, since no addresses are known) - but I assume that the program would read into memory very quicky, and you could throw a 30-second wait in there for someone to pull the card, unlock it, and reinsert it before you attempt to dump it.

[intrinsic]

It would be rather ugly - but if you got the rest of it working you could have the user boot the camera, and then after a few seconds remove the SD card and replace it with the lock switch turned off...

Bearing in mind that some cams (like my S5) have their SD card in the battery bay, this would complicate things...

I don't know enough about the USB hardware in the cams to be able to state categorically whether this is feasible or not, just throwing the idea out there, has anybody thought about streaming the firmware out the USB port?

Depending on how much of the USB interface is implemented in hardware it may be simpler than the SD card route, particularly if the USB interface is built into the uP in the cam, in which case it would almost invariably appear at the same address(es) in all cams.

[ewavr]

How about this? It works on my A710, but don't works on G7 (signarure search failed, but if I assign correct function address, all works).  Of course, it has its drawbacks - dumper uses absolute sector writing instead of  filesystem.
This is reference project only, it should be added signature for DRYOS cams and changed signature search algorithm.
edit: this works only for "small" diskboot.bin (not for "firmware update"). WriteSDCard() as low level function ignores card lock.

[GrAnd]

How about this? It works on my A710, but don't works on G7 (signarure search failed, but if I assign correct function address, all works).

The longer the signature, the less chance to match it for other models. Did you try to cut the signature a bit and to match a shorter version for G7?

[ewavr]

The longer the signature, the less chance to match it for other models. Did you try to cut the signature a bit and to match a shorter version for G7?

Difficulty in the fact that the functions ReadSDCard (0xFF88BCD0 G7 all f/w) and WriteSDCard (0xFF88BE6C G7 all f/w) are really very similar 

edit: Ok, I reduce signature size to 20 instructions. But however each camera works with own signatures 

[RyeBrye]

How about this? It works on my A710, but don't works on G7 (signarure search failed, but if I assign correct function address, all works).  Of course, it has its drawbacks - dumper uses absolute sector writing instead of  filesystem.
This is reference project only, it should be added signature for DRYOS cams and changed signature search algorithm.

Having just spent a long long time getting to dump my firmware, I can say that efforts on this front would be a very good use of time.

At the very least, I wouldn't mind helping with this so that I can get a dump that I fully trust...

Since I'm new to this project, I doubt I'll be much help for a while though

 

[ewavr]

Second variant - works on G7 and A710 too. It calls both ReadSDCard() and WriteSDCard()  . Can anybody verify it on other VxWorks camera?

[jeff666]

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

The locations (A720) are:
* FFCF5058 ReadSDCard
* FFCF51B0 WriteSDCard

Parameters are identical. The starting point to locate the functions manually is task_InitFileModules (on both, VxWorks and DryOS).

Edit:
I just had a look at the WriteSDCard-functions of the A720 (1.00C), the S5 (1.01B) and the G9 (1.00d) and it seems that A and G are (mostly) equal while the S has at least one additional command quite at the beginning (see attached file).

Another way to find the location of WriteSDCard could be the function that actually refers to ReadSDCard and WriteSDCard. It looks identical on each firmware - maybe even os-independent (didn't check this).

I'm referring to sub_FFC3EC9C (A720). Could the signature-finder locate this function and we read the actual location(s) from there?

Cheers.