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

Re: 40D firmware decryption

Expand Messages
  • soldeersmurfje
    I checked, there is not that much of continuous text. But there is a way out, we can generalize the method. Suppose we have split the text into blocks of
    Message 1 of 19 , Dec 20, 2007
    View Source
    • 0 Attachment
      I checked, there is not that much of continuous text.
      But there is a way out, we can generalize the method.

      Suppose we have split the text into blocks of 512*513 bytes, say A, B,
      C, ...
      Now xor every pair together to obtain A^B, A^C, etc.
      By finding clear text, like english (or some other language) strings,
      we can find segments in say A^B, where either A or B must be 0.
      Typically, from the text, we can say derive which one it is, because,
      say B^C also shows some text, or because A^C shows the same text, or
      because strings are related (e.g. text having to do with printing,
      network, or other).

      From this, we get many segments of zeros.

      Now let the keys be K and L, of length 512 and 513 resp.
      Suppose position i in A is proven to be zero.
      Then we know that

      Kk^Ll^0 = Ai, k = i % 512, l = i % 513.

      This gives us a system of equation of 512+513 = 1025 variables Kk and Ll.

      In this system, we can choose one value still freely.
      If we know say Kk, we can compute Ll, and from this possibly some
      other Kk', etc.
      If the system is rich enough, we can compute all key values.

      If not, we are left with some unknown values. If there are relatively
      few of them, we can decode the fir file with the ones we know, leaving
      us with some undecoded entries. Typically, there will be some of these
      holes inside strings, were we can deduce the missing letters (like in
      a string Shut.er). From this, we get more keys and we can proceed with
      the extended system, hoping we will ventually have enough positions to
      solve all.

      Well, this is what I am currently doing...

      Lex

      --- In canondigicamhacking@yahoogroups.com, "Szabolcs Berecz"
      <szaber@...> wrote:
      >
      > The same for 400D except for the first 32 bytes which is not
      > encrypted. The same goes for 40D but it has more unencrypted data
      > there.
      >
      > My only problem with the method is how to get the 1024 bytes of
      > continuous plain text. I haven't checked, yet, but I'm not sure if
      > it's always feasible to find the pieces to create that much continuous
      > plain text...
    • soldeersmurfje
      By the way, I see many strings in languages I do not know well enough to be sure that all characters are correct. I may need some help if I cannot find enough
      Message 2 of 19 , Dec 20, 2007
      View Source
      • 0 Attachment
        By the way, I see many strings in languages I do not know well enough
        to be sure that all characters are correct. I may need some help if I
        cannot find enough keys in identifying strings in foreigh languages.

        Also, text in say eastern European languages contain non-ascii
        characters which I cannot dsiplay correctly at the moment.
        Anyone knowing how to view those on a Linux box?
      • James Washer
        Most likely, they ll just be hi-bit-set (i.e. 128dec or 0x80)... though there is a chance that they could be multi-byte. Check out
        Message 3 of 19 , Dec 20, 2007
        View Source
        • 0 Attachment
          Most likely, they'll just be hi-bit-set (i.e. >128dec or 0x80)... though there is a chance that they could be multi-byte.
          Check out http://en.wikipedia.org/wiki/Unicode
          On Thu, 20 Dec 2007 21:46:22 -0000
          "soldeersmurfje" <a.augusteijn1@...> wrote:

          > By the way, I see many strings in languages I do not know well enough
          > to be sure that all characters are correct. I may need some help if I
          > cannot find enough keys in identifying strings in foreigh languages.
          >
          > Also, text in say eastern European languages contain non-ascii
          > characters which I cannot dsiplay correctly at the moment.
          > Anyone knowing how to view those on a Linux box?
          >
          >
          >
          >
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
        • soldeersmurfje
          I hope so. But looking at the set of languages supported by the 40D, there are even eastern languages, probably Japanese, Korean, Chinese and one other. Also
          Message 4 of 19 , Dec 20, 2007
          View Source
          • 0 Attachment
            I hope so. But looking at the set of languages supported by the 40D,
            there are even eastern languages, probably Japanese, Korean, Chinese
            and one other. Also there is Greek and Russian.
            It could still be one byte, if the decoding is dependent on the
            language setting.


            --- In canondigicamhacking@yahoogroups.com, James Washer <washer@...>
            wrote:
            >
            > Most likely, they'll just be hi-bit-set (i.e. >128dec or 0x80)...
            though there is a chance that they could be multi-byte.
            > Check out http://en.wikipedia.org/wiki/Unicode
          • James Washer
            I doubt kanji fits in a single byte... On Thu, 20 Dec 2007 22:46:17 -0000
            Message 5 of 19 , Dec 20, 2007
            View Source
            • 0 Attachment
              I doubt kanji fits in a single byte...

              On Thu, 20 Dec 2007 22:46:17 -0000
              "soldeersmurfje" <a.augusteijn1@...> wrote:

              > I hope so. But looking at the set of languages supported by the 40D,
              > there are even eastern languages, probably Japanese, Korean, Chinese
              > and one other. Also there is Greek and Russian.
              > It could still be one byte, if the decoding is dependent on the
              > language setting.
              >
              >
              > --- In canondigicamhacking@yahoogroups.com, James Washer <washer@...>
              > wrote:
              > >
              > > Most likely, they'll just be hi-bit-set (i.e. >128dec or 0x80)...
              > though there is a chance that they could be multi-byte.
              > > Check out http://en.wikipedia.org/wiki/Unicode
              >
              >
              >
              >
              >
              > Yahoo! Groups Links
              >
              >
              >
              >
            • Szabolcs Berecz
              So, when you are ready, let me know! I will be interested in (re)using your code :) I have also started to write the code but I won t be able to work on it in
              Message 6 of 19 , Dec 20, 2007
              View Source
              • 0 Attachment
                So, when you are ready, let me know! I will be interested in (re)using
                your code :)

                I have also started to write the code but I won't be able to work on
                it in the next week and I suppose you will be ready with it by that
                time...

                Szabi


                On Dec 20, 2007 4:43 PM, soldeersmurfje <a.augusteijn1@...> wrote:
                >
                >
                >
                >
                >
                >
                > I checked, there is not that much of continuous text.
                > But there is a way out, we can generalize the method.
                >
                > Suppose we have split the text into blocks of 512*513 bytes, say A, B,
                > C, ...
                > Now xor every pair together to obtain A^B, A^C, etc.
                > By finding clear text, like english (or some other language) strings,
                > we can find segments in say A^B, where either A or B must be 0.
                > Typically, from the text, we can say derive which one it is, because,
                > say B^C also shows some text, or because A^C shows the same text, or
                > because strings are related (e.g. text having to do with printing,
                > network, or other).
                >
                > From this, we get many segments of zeros.
                >
                > Now let the keys be K and L, of length 512 and 513 resp.
                > Suppose position i in A is proven to be zero.
                > Then we know that
                >
                > Kk^Ll^0 = Ai, k = i % 512, l = i % 513.
                >
                > This gives us a system of equation of 512+513 = 1025 variables Kk and Ll.
                >
                > In this system, we can choose one value still freely.
                > If we know say Kk, we can compute Ll, and from this possibly some
                > other Kk', etc.
                > If the system is rich enough, we can compute all key values.
                >
                > If not, we are left with some unknown values. If there are relatively
                > few of them, we can decode the fir file with the ones we know, leaving
                > us with some undecoded entries. Typically, there will be some of these
                > holes inside strings, were we can deduce the missing letters (like in
                > a string Shut.er). From this, we get more keys and we can proceed with
                > the extended system, hoping we will ventually have enough positions to
                > solve all.
                >
                > Well, this is what I am currently doing...
                >
                > Lex
                >
                > --- In canondigicamhacking@yahoogroups.com, "Szabolcs Berecz"
                >
                > <szaber@...> wrote:
                > >
                > > The same for 400D except for the first 32 bytes which is not
                > > encrypted. The same goes for 40D but it has more unencrypted data
                > > there.
                > >
                > > My only problem with the method is how to get the 1024 bytes of
                > > continuous plain text. I haven't checked, yet, but I'm not sure if
                > > it's always feasible to find the pieces to create that much continuous
                > > plain text...
                >
                >



                --
                DRM: Digital Restrictions Management -- learn about the dangers at
                http://www.defectivebydesign.org/what_is_drm
              • soldeersmurfje
                I am on a short vacation right now. Hopefully I can continue next week. I will release the source code of the analyzer. Lex ... using
                Message 7 of 19 , Dec 22, 2007
                View Source
                • 0 Attachment
                  I am on a short vacation right now.
                  Hopefully I can continue next week.
                  I will release the source code of the analyzer.

                  Lex

                  --- In canondigicamhacking@yahoogroups.com, "Szabolcs Berecz"
                  <szaber@...> wrote:
                  >
                  > So, when you are ready, let me know! I will be interested in (re)
                  using
                  > your code :)
                  >
                  > I have also started to write the code but I won't be able to work on
                  > it in the next week and I suppose you will be ready with it by that
                  > time...
                  >
                  > Szabi
                • Jonathan Sylvestre
                  If you need help to check strings in french, I would be glad to help. Let me know. [Non-text portions of this message have been removed]
                  Message 8 of 19 , Dec 23, 2007
                  View Source
                  • 0 Attachment
                    If you need help to check strings in french, I would be glad to help. Let me know.

                    [Non-text portions of this message have been removed]
                  • Szabolcs Berecz
                    I can help with Hungarian. Anyway, the way I gonna implement it (not before january) is to dump the strings to a file with position and block information.
                    Message 9 of 19 , Dec 24, 2007
                    View Source
                    • 0 Attachment
                      I can help with Hungarian.

                      Anyway, the way I gonna implement it (not before january) is to dump
                      the strings to a file with position and block information. Filter and
                      fix these by hand and run the decrypter with these strings.
                      This way the work could be split up between more people. So less
                      boring work in the end...

                      Szabi

                      On Dec 23, 2007 6:34 PM, Jonathan Sylvestre <josylvestre@...> wrote:
                      >
                      >
                      >
                      >
                      >
                      >
                      > If you need help to check strings in french, I would be glad to help. Let me
                      > know.
                      >
                      > [Non-text portions of this message have been removed]
                      >
                      >



                      --
                      DRM: Digital Restrictions Management -- learn about the dangers at
                      http://www.defectivebydesign.org/what_is_drm
                    • soldeersmurfje
                      I finished the 40D decryption, no more help needed on finding clear text in the firmware. It appeared I had plenty of text, which helped in detecting any
                      Message 10 of 19 , Dec 25, 2007
                      View Source
                      • 0 Attachment
                        I finished the 40D decryption, no more help needed on finding clear
                        text in the firmware. It appeared I had plenty of text, which helped
                        in detecting any inconsistencies, since there was a lot of redundancy.

                        Now it's Christmas time, but I will publish the decode table soon.

                        Lex

                        --- In canondigicamhacking@yahoogroups.com, "soldeersmurfje"
                        <a.augusteijn1@...> wrote:
                        >
                        > I am on a short vacation right now.
                        > Hopefully I can continue next week.
                        > I will release the source code of the analyzer.
                        >
                        > Lex
                      • soldeersmurfje
                        I uploaded the 40D (and 20D, depending on an include file) decrypter to the file section. Merry Xmas! Lex
                        Message 11 of 19 , Dec 25, 2007
                        View Source
                        • 0 Attachment
                          I uploaded the 40D (and 20D, depending on an include file) decrypter
                          to the file section.

                          Merry Xmas!

                          Lex
                        • alex_polushin
                          ... Good work! :)
                          Message 12 of 19 , Dec 28, 2007
                          View Source
                          • 0 Attachment
                            --- In canondigicamhacking@yahoogroups.com, "soldeersmurfje"
                            <a.augusteijn1@...> wrote:
                            >
                            > I uploaded the 40D (and 20D, depending on an include file) decrypter
                            > to the file section.
                            >
                            > Merry Xmas!
                            >
                            > Lex
                            >

                            Good work! :)
                          Your message has been successfully submitted and would be delivered to recipients shortly.