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

Re: [canondigicamhacking] Initial Exploration of A:\CAMERA.EXE

Expand Messages
  • Alex Bernstein
    You are right. A: CAMERA.EXE is most definetely an RXE executable. On page 12 of RXETO.DOC, RXE header is described. seg000:0000 starts with string XIP
    Message 1 of 4 , Dec 11, 2003
    View Source
    • 0 Attachment
      You are right. A:\CAMERA.EXE is most definetely an RXE executable. On page 12
      of RXETO.DOC, RXE header is described. seg000:0000 starts with string XIP
      (eXecute In Place) that indicates RXE header.

      But I've tried before to disassemble parts of dseg as code and have failed to
      produce anything meaningful. We need to find out what gets loaded into
      8d00:0000. That's why I'm working back from firmware loader in b:\camera.exe to
      determine differents part of the upgrade file and figure where they are copied.

      -- Alex
      --- eos_hacker <eos_hacker@...> wrote:
      > I did some analysis of A:\CAMERA.EXE, which I presume, is the main
      > camera firmware. It was puzzling to me at first, because upon
      > initial inspection it looks like it's just a tiny routine and a huge
      > data segment. The tiny routine just saves a software interrupt
      > vector (INT 90h), sets it to point to its own service routine @
      > CS:00E6, and then exits. Then I finally realized what it's doing at
      > the end. It's not really terminating, because it's pushing the
      > return address before it does the RETF. Thus, it's really doing a
      > far jump to absolute address 8D00:0000
      >
      > seg000:009B push cs:word_1000C ; 8D00
      > seg000:00A0 push cs:word_1000E ; 0000
      > seg000:00A5 retf
      > seg000:00A5 start endp ; sp = -4
      >
      > So what's at 8D00:0000? We're going to need a memory dumping utility
      > to decode it, but I suspect it's just some RXE-related management
      > code. I found a doc called RXETO.PDF from Datalight, and it
      > describes the theory of operation for RXE, which is their method of
      > enabling in-place execution of programs. In a normal PC, programs
      > are held in secondary storage, such as hard drives, and then loaded
      > entirely into RAM before they are executed. In the camera, the A:\
      > drive resides in flash memory..thus, using judicious techniques, it
      > can be run in place instead of being copied into RAM first. There is
      > a string inside A:\CAMERA.EXE referring to RXE, so I'll assume that
      > it indeed has been processed to be an RXE program. This explains the
      > tiny code segment and huge data segment...this is how RXE programs
      > are structured, because it's part of the technique they use to fool
      > the DOS EXE loader into not copying the whole program into RAM before
      > executing it...thus the huge data segment actually contains tons of
      > code.
      >
      > The interrupt 90h service routine is rather short, so I don't think
      > it's the main program. The main program is probably reached upon
      > return to our code segment from the mysterious 8D00:0000 code. So
      > it's time to start digging into that huge data segment and figure out
      > what parts of it are actually code.
      >
      >
      >


      __________________________________
      Do you Yahoo!?
      New Yahoo! Photos - easier uploading and sharing.
      http://photos.yahoo.com/
    • eos_hacker
      I think your efforts on reverse-engineering the .FIR files is going to be instrumental, since so far, I haven t been sucessful in my efforts to put or change
      Message 2 of 4 , Dec 11, 2003
      View Source
      • 0 Attachment
        I think your efforts on reverse-engineering the .FIR files is going
        to be instrumental, since so far, I haven't been sucessful in my
        efforts to put or change any files in the A: and B: drives.

        can you give us a synopsis of what you've found in B:\CAMERA.EXE so
        far?

        --- In canondigicamhacking@yahoogroups.com, Alex Bernstein
        <pofig37@y...> wrote:
        > You are right. A:\CAMERA.EXE is most definetely an RXE executable.
        On page 12
        > of RXETO.DOC, RXE header is described. seg000:0000 starts with
        string XIP
        > (eXecute In Place) that indicates RXE header.
        >
        > But I've tried before to disassemble parts of dseg as code and have
        failed to
        > produce anything meaningful. We need to find out what gets loaded
        into
        > 8d00:0000. That's why I'm working back from firmware loader in
        b:\camera.exe to
        > determine differents part of the upgrade file and figure where they
        are copied.
        >
        > -- Alex
      • Alex Bernstein
        Here s what I know so far about the structure of firmware header: typedef struct { uint32 length; uint32 field4; char string1[32]; char string2[32]; char
        Message 3 of 4 , Dec 11, 2003
        View Source
        • 0 Attachment
          Here's what I know so far about the structure of firmware header:
          typedef struct {
          uint32 length;
          uint32 field4;
          char string1[32];
          char string2[32];
          char pad[80];
          } header_t;

          Firmware loader first reads and decrypts 0x98 bytes of header and checks that
          string1 == "Header" and string2 == "FirFileSigntature". Then, it continues
          reading/decrypting in 0x98 byte chunks, until it finds header with string1 ==
          "ExtApp" and string2 == "Program". In the 10d and 300D this 2nd header
          immediatelly follows the first. I don't know if it is possible for more than
          one to be present. It then looks like it proceeds to read and decrypt length
          bytes from file in 0x4000 byte chunks but using different initial "decryption
          offset" of 0x6000. This part I haven't verified yet, and I'm not sure yet where
          this decrypted program file is stored.

          -- A.



          --- eos_hacker <eos_hacker@...> wrote:
          > I think your efforts on reverse-engineering the .FIR files is going
          > to be instrumental, since so far, I haven't been sucessful in my
          > efforts to put or change any files in the A: and B: drives.
          >
          > can you give us a synopsis of what you've found in B:\CAMERA.EXE so
          > far?
          >
          > --- In canondigicamhacking@yahoogroups.com, Alex Bernstein
          > <pofig37@y...> wrote:
          > > You are right. A:\CAMERA.EXE is most definetely an RXE executable.
          > On page 12
          > > of RXETO.DOC, RXE header is described. seg000:0000 starts with
          > string XIP
          > > (eXecute In Place) that indicates RXE header.
          > >
          > > But I've tried before to disassemble parts of dseg as code and have
          > failed to
          > > produce anything meaningful. We need to find out what gets loaded
          > into
          > > 8d00:0000. That's why I'm working back from firmware loader in
          > b:\camera.exe to
          > > determine differents part of the upgrade file and figure where they
          > are copied.
          > >
          > > -- Alex
          >
          >
          >


          __________________________________
          Do you Yahoo!?
          New Yahoo! Photos - easier uploading and sharing.
          http://photos.yahoo.com/
        Your message has been successfully submitted and would be delivered to recipients shortly.