universal dumper - one more idea - Firmware Dumping - CHDK Forum

universal dumper - one more idea

  • 63 Replies
  • 58458 Views
*

Offline mx3

  • ****
  • 372
universal dumper - one more idea
« on: 23 / December / 2007, 23:49:42 »
Advertisements
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

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

*

Offline jeff666

  • ****
  • 181
  • A720IS
Re: universal dumper - one more idea
« Reply #1 on: 25 / December / 2007, 06:00:51 »
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).


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

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

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

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

*

Offline mx3

  • ****
  • 372
Re: universal dumper - one more idea
« Reply #2 on: 25 / December / 2007, 08:12:09 »
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?
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

*

Offline mx3

  • ****
  • 372
Re: universal dumper - one more idea
« Reply #3 on: 25 / December / 2007, 08:14:49 »
of course it is required to include into dumper support of FAT16
there are some opensource projects which can be used
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler


*

Offline jeff666

  • ****
  • 181
  • A720IS
Re: universal dumper - one more idea
« Reply #4 on: 25 / December / 2007, 09:03:44 »
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.

*

Offline GrAnd

  • ****
  • 916
  • [A610, S3IS]
    • CHDK
Re: universal dumper - one more idea
« Reply #5 on: 25 / December / 2007, 09:26:17 »
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.
CHDK Developer.

*

Offline GrAnd

  • ****
  • 916
  • [A610, S3IS]
    • CHDK
Re: universal dumper - one more idea
« Reply #6 on: 25 / December / 2007, 10:01:32 »
CHDK Developer.

*

Offline RyeBrye

  • **
  • 73
  • SD-870
Re: universal dumper - one more idea
« Reply #7 on: 21 / January / 2008, 19:29:03 »
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.


*

Offline intrinsic

  • *
  • 29
  • S5IS
Re: universal dumper - one more idea
« Reply #8 on: 21 / January / 2008, 21:55:08 »
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.

*

Offline ewavr

  • ****
  • 1057
  • A710IS
Universal dumper becomes a reality?
« Reply #9 on: 24 / January / 2008, 16:09:48 »
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.
« Last Edit: 24 / January / 2008, 17:04:05 by ewavr »

 

Related Topics


SimplePortal 2.3.6 © 2008-2014, SimplePortal