Loading ...
Sorry, an error occurred while loading the content.

Re: 20D encryption - some details here

Expand Messages
  • alex_polushin
    1. Initial assumption I beleeve that encryption algorithm is same as used in previous versions, and only key are changeg (as it was with S70). So key are
    Message 1 of 34 , May 30, 2005
      1. Initial assumption
      I beleeve that encryption algorithm is same as used in previous
      versions, and only key are changeg (as it was with S70). So key are
      repeated each 512*513 bytes. I'm get firmware file and split it into
      512*513 bytes pieces, then xor this pieces each other in different
      combinations. I can see strings somewhere in results, so assumption
      is true.

      2. Some encryption algorithm feature
      If we xor all 512+513 bytes of both subkeys with same arbitrary byte,
      we get same result key because (a xor x) xor (b xor x) == a xor b.
      Keep it in mind.

      3. That we are needed to restore encryption key ?
      We are needed only 1024 bytes of continuous plaintext (equivalent to
      1024 bytes of encryption key). Assume for simplicity that we have
      first 1024 bytes of key (if we have some other 1024 bytes, we need
      only adjust offsets late).
      XOR first half of it (512 bytes) this second half.
      key1 values are equal in same positions of both halves, so in result
      first byte is key2[512] xor key2[0], second byte is key2[0] xor key2
      [1], and so on up to last byte is key2[510] xor key2[511]. Now
      remember algorithm feature and assign arbitrary value to key2[512].
      We can then get all key2 and key1 values. These may be not same as
      used by Canon, but produce same encryption key. (if we have 1024
      bytes of key not at the beginning, we just start not from key2[512],
      but from some place at middle of key2).

      4. Where to get plaintext
      It's simply. We are have many pieces from first step.
      If A xor B give us some strings, and A xor C give some other strings
      at same place, then there are definitely zeroes at this place in A.
      So we only need to find some long enough farment.

      --- In canondigicamhacking@yahoogroups.com, Alex Bernstein
      <pofig37@g...> wrote:
      > Awesome! Would be great to hear how you've accomplished it.
      > I've noticed that S1IS firmware ended with a long section of FFs, so
      > the last thing I've tried last night was to take the tail end of 20D
      > firmware starting on 512*513 boundary and XOR it with FFs hoping
      > this would give me a long section of the key. Unfortunately, that
      > didn't lead anywhere, and I gave up and went to sleep as it was past
      > 4am. Looking at the firmware decrypted with your decrypter there
      > no FFs at the end so this indeed was a dead end.
      > --AlexB
      > On 5/30/05, alex_polushin <polushin@n...> wrote:
      > > I'm upload working 20D firmware decryptor into files section.
    • el_yopo
      First of all, is good to see some activity for the newer ARM-based cameras is going on. I ve been dissassembling (using IDA) the firmware updates of the
      Message 34 of 34 , Aug 3, 2005
        First of all, is good to see some activity for the newer ARM-based
        cameras is going on.
        I've been dissassembling (using IDA) the firmware updates of the
        Powershot SD400 and SD500. I own an SD300, so first I needed Softice
        live-cracking of the updater (was update.exe?) to "convince" to save
        the firmware in the SD card (it would check for an SD400/500 and would
        fail with my SD300 if not forced).

        So I ended up with the firmwares, decrypted them (thanks again Alex
        Bernstein and Alex Polushin!!!) and started dissassembling with IDA.

        But as you may already know, it is extremelly painful.

        Now I see you got some usefull offsets where to start loading to
        automate the task a bit. Could you please comment a bit deeper your
        findings? (maybe we can do it in the Powershot hacking group)...

        I'm still struggling against separating what's pure-camera related
        code from that just used by the Vxworks OS...

        Any comments on LDA? I've never used it yet... Should I?

        Thanks everybody,

        Alex, el_yopo. (the third Alex)

        --- In canondigicamhacking@yahoogroups.com, Alex Bernstein
        <pofig37@g...> wrote:
        > No question IDA is great, especially the interactivity aspect of it.
        > But once you gain some insight into the structure of the code and
        > would like to apply it to the resto of the code, it becomes very
        > tedious. I suppose IDC could help, but LDA offered the ultimate
        > customizability taking care of RXE references, Canon's EMS
        > architecture, etc. Also LDA text files were easier to share than
        > unwieldy .idb files. Much of the success of the Undutchables is
        > probably due to the work that went into LDA.
        > That said, I recently took a look at the latest 20D with IDA. It looks
        > that if you load the decrypted file at the address 0x800000 it starts
        > to disassemble quite nicely as 32-bit little endian ARM code. That
        > first part of it seems to be the upgrade procedure itself, that
        > possibly copies the rest of the file into different memory regions.
        > The next part of the .fir that starts at the offset 0xbc1c0 looks like
        > it should be in the memory at the offset 0xFF810000.
        > --Alex
      Your message has been successfully submitted and would be delivered to recipients shortly.