supplierdeeply

VerifyAndDecryptFirmware() Found! Maybe...

  • 36 Replies
  • 8007 Views
*

Offline _MAG_

  • *
  • 47
  • Publish
    Re: VerifyAndDecryptFirmware() Found! Maybe...
    « Reply #30 on: 29 / May / 2008, 01:40:43 »
    Advertisements
    mx3 if you need fast bruteforce - tell me. I set up cluster 24 mashines with 1,8 Mhz processor = 43 Mhz computer :)
    but 1 problem -they run Linux OS (from live cd)
    « Last Edit: 29 / May / 2008, 01:42:18 by _MAG_ »

    *

    Offline mx3

    • ****
    • 372
  • Publish
    Re: VerifyAndDecryptFirmware() Found! Maybe...
    « Reply #31 on: 29 / May / 2008, 02:10:13 »
    If you could work on figuring out the decrypter I can work on blinking out part of FF810000. We can use which ever way comes first. That may be your way because I won't have much time until next week, but I'll do what I can now.

    I don't have much time also.

    Plus, this is educational for me.

    I don't have DSLR so this whole thing educational to me too.

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

    *

    Offline DataGhost

    • ****
    • 314
    • EOS 40D, S5IS
      • DataGhost.com
  • Publish
    Re: VerifyAndDecryptFirmware() Found! Maybe...
    « Reply #32 on: 29 / May / 2008, 05:32:53 »
    I didn't try with AUTOEXEC.BIN.
    why not to try?
    I tried it just now. It didn't do anything.
    Are you sure the card is still bootable, or bootable at all? Please verify it by dumping the partition header or any other method, the string BOOTDISK must be there. The presence of both the strings AUTOEXEC.BIN (instead of DISKBOOT.BIN) and BOOTDISK tells me that at least something should happen... Even if it's CF, it should work unless it's really looking for a header or something. A Powershot S50 (DIGIC I, x86) camera with CF hangs when I make it bootable and have the DISKBOOT.BIN file on the card, so it shouldn't really matter.

    One thing you could try... I'm assuming you have a huge card which requires FAT32. Try a smaller card or a smaller partition (max 4GB) with FAT16 and make that bootable. Powershots etc don't boot from FAT32 cards, only FAT12 and FAT16.

    *

    ASalina

  • Publish
    Re: VerifyAndDecryptFirmware() Found! Maybe...
    « Reply #33 on: 29 / May / 2008, 13:37:02 »

    Are you sure the card is still bootable, or bootable at all? Please verify it by dumping the partition header or any other method, the string BOOTDISK must be there.

    I made it bootable myself by following the instructions at:
    Bootable SD card - CHDK Wiki

    Quote
    The presence of both the strings AUTOEXEC.BIN (instead of DISKBOOT.BIN) and BOOTDISK tells me that at least something should happen... Even if it's CF, it should work unless it's really looking for a header or something. A Powershot S50 (DIGIC I, x86) camera with CF hangs when I make it bootable and have the DISKBOOT.BIN file on the card, so it shouldn't really matter.

    Did you do anything special (hold any buttons down, etc.) during power up?
    The 40D starts up in "record" mode. I've tried holding various buttons down with no success, except for the Direct Print button, and that was inconclusive.

    Quote
    One thing you could try... I'm assuming you have a huge card which requires FAT32. Try a smaller card or a smaller partition (max 4GB) with FAT16 and make that bootable. Powershots etc don't boot from FAT32 cards, only FAT12 and FAT16.

    I'm using an old 128meg card. "EOS_DIGITALFAT16" is in the header of the disk.
    Is there anything else you can think of? This would be a great way to run programs. I have to leave for work now, but I don't know if the camera will start up in playback mode when there are images on the card. When I get home tonight I'll try that (I don't think it does though).


    *

    ASalina

  • Publish
    Re: VerifyAndDecryptFirmware() Found! Maybe...
    « Reply #34 on: 04 / June / 2008, 00:49:48 »
    I vote for the blink ;-)

    In fact - If you'll menage to blink the 0xFF810000 segment (even a small part) you can get the XOR table out of it and decode the rest - am I thinking right ?

    Ok, I just finished blinking out 64K bytes of data starting at 0xFF810000 into an audio program. I can easily get more data if needed. The photodiode -> MIC input seems to work great. I used owerlord's base64 blinker, though I'm not quite sure how it works. :-)

    The thing is, what do I do with this data now? :-)

    *

    Offline DataGhost

    • ****
    • 314
    • EOS 40D, S5IS
      • DataGhost.com
  • Publish
    Re: VerifyAndDecryptFirmware() Found! Maybe...
    « Reply #35 on: 04 / June / 2008, 05:35:11 »
    Why a base64 blinker? I just output every bit and a checksum every 1024 bytes. I just let my cam work for a couple of hours and after that I was rewarded with a full dump of my camera's firmware. Just do that and we can figure out the decryption later :)
    It'll still be very hard, though, since the XOR tables aren't the same length and 'rotate over eachother'.. Maybe it's easier to just find them in the fw :P

    *

    ASalina

  • Publish
    Re: VerifyAndDecryptFirmware() Found! Maybe...
    « Reply #36 on: 04 / June / 2008, 07:37:52 »
    Why a base64 blinker? I just output every bit and a checksum every 1024 bytes. I just let my cam work for a couple of hours and after that I was rewarded with a full dump of my camera's firmware. Just do that and we can figure out the decryption later :)

    I don't know why owerlord is using base-64. I think it's part of something much bigger than what I'm trying to do.

    Quote
    It'll still be very hard, though, since the XOR tables aren't the same length and 'rotate over eachother'.. Maybe it's easier to just find them in the fw :P

    If I can dump the whole firmware from ROM then we won't need decryption at all.
    I had no luck capturing data from the serial port, but the audio port method is working well (I need to aim the photodiode better to get a stronger signal). I'm just not sure what timings to use to get optimum reliable throughput, and then how to convert the raw audio data into a dump. I've been looking at the source for  adc and dec, and figure that's the best way to go (I'll have to port the code to this linux box, though).

    BTW: I don't know if you've been following the discussion, but I think I've finally resolved the linker option problem in my Makefile for mkfir, etc.

    I'm now using -Wl,-N,-Ttext,800120 in the link command for programs that run on the camera. I was getting strange results with -fPIC for relocatable code output. Since the original flasher is getting loaded at 0x00800000 (header included) and the header is 0x120 bytes long, then 0x00800120 is the start of the text section of the actual program.

    (EDIT: And that's pretty much what owerlord was saying)

    It seems to work reliably so far, and it conforms to the offset in the header.
    « Last Edit: 04 / June / 2008, 07:40:42 by ASalina »

     

    Related Topics