CardTricks v1.36 cardtricks136.exe - 0.40MB Slightly too late to celebrate 10k+ downloads for version 1.34 Grin, but:- support for udumper2008 (thanks, chr) --- this should mean that there's a fair chance that owners of the NewDryOS generation cams (anybody got a better name?) can dump their firmware. (that should mean (roughly) A580 & later, ixus80_sd1100 and later) - updated bootable.exe to be usable for Canon DSLR users: besides the 'BOOTDISK' stamp at 0x40 in the 1st sector, it now additionally writes 'EOS_DEVELOP' at 0x24. This has caused no problems on my VxWorks cams so far (A620, A630, and ixus70_sd1000). Please report if you're sure it doesn't work for your cam. (Note: previous version of 'bootable.exe'is also included in the CardTricks directory (just rename bootable.exe -> bootable.exe.new and bootable.exe.org -> bootable.exe to restore previous version)- improved detection of an already running CardTricks.enjoy,wim
Hi Postfach777 !Not sure if anybody tested it, but CT uses Win32 cmdline commands for all the 'real' work.If Wine can handle that, I'd say your chances are decent. The GUI stuff is done in AutoIt,and I read several topics in it's forum that claimed simple AutoIt progs worked.Sorry, I realise that's kind of vague, but it's the best I can do for the moment.Another approach would be to install a slimmed down Windows in a virtual machinelike VirtualBox to do the job (ideally Win2000, that's relatively small)wim
Quote from: dlw on 05 / July / 2008, 15:14:14So -- putting more of the firmware into CHDK hasn't helped and neither has putting less of it in. I'm fresh out of ideas. Anybody out there have a new approach? Sorry for replying so late.Observation:* you have a program and expect it to behave in a specific way* this program behaves differently than you expected.* you (i.e. we) are sure that our little devices do exactly what they're told to doConclusion 1: The device executes a program that differs from what you have developed.Conclusion 2: The program you developed is changed at some point, most probably on the device.Resolution: Test what the device actually executes and fix your program if necessary.You may want to use the function WriteSDCard which is used for the udumper, as well. It writes a portion of memory to a specific sector on the SD. WriteSDCard is part of the official firmware. Ask if you have trouble locating it.Syntax: WriteSDCard(int drive, int startsector, int sectorcount, int memstart);drive is always 0startsector is the first sector on the SD that is writtensectorcount is the number of sectors that are written (1sector = 512bytes)memstart is the first byte of memory that has to be written.You may have trouble writing the first few bytes of memory. In case your dump doesn't work, try 0x1900 as memory start: WriteSDCard(0, 1024, 2048, 0x1900);Writes 1mb (2048 sectors) of memory, starting at 0x1900 to the sd starting at sector 1024.Make sure your card is empty so you don't overwrite data you still need.further code example:typedef int (*f_w)(int, int, int, int); // drive(?), start sector, number of sectors, addressf_w WriteSDCard; // "variable" declarationWriteSDCard=(f_w)(0xFFxxxxxx); // set function pointer, use firmware-specific addressAfter you have the memory extracted, load it in IDA as additional file to the firmware. Now you can check if the device executes exactly the same code that you have written.Cheers.
So -- putting more of the firmware into CHDK hasn't helped and neither has putting less of it in. I'm fresh out of ideas. Anybody out there have a new approach?
Started by PhyrePhoX General Discussion and Assistance
Started by oldie1kslowbie Hello, I'm a NEWBIE - HELP!! (Newbies assistance, User Guides and thank you notes)
Started by manojmohan General Discussion and Assistance
Started by thangggg123 Hello, I'm a NEWBIE - HELP!! (Newbies assistance, User Guides and thank you notes)
Started by waterwingz General Discussion and Assistance