Can I decompile a Motorola chip to understand its code?

[TexanJohn]

I have several files which are essentially 'dumps' from a Motorola chip. I believe the chip is a 68xxx or 683xx (although I guess a 683xx is within the 68xxx family). Anyway, I can view the file in a hex editor, but it doesn't mean much. Is there a way to decompile the code to get a better view of what is in there? Just looking for ideas, suggestions, help ... Thanks.

 

[berkeman]

Sounds like you need a reverse assembler for the object code dumps that you have. Maybe try googling that, or go through Motorola's website and look at their tool vendor list for those chips.

You can also do it by hand, or write your own reverse assembler. Those are a lot easier than a reverse compiler! You can get a list of the opcodes for those processors in their documentation at the Motorola website -- look in their databooks or software programmer manuals or some such thing.

 

[TexanJohn]

Sounds like you need a reverse assembler for the object code dumps that you have. Maybe try googling that, or go through Motorola's website and look at their tool vendor list for those chips.

You can also do it by hand, or write your own reverse assembler. Those are a lot easier than a reverse compiler! You can get a list of the opcodes for those processors in their documentation at the Motorola website -- look in their databooks or software programmer manuals or some such thing.

I simply don't have enough knowledge to do it myself (and my real job seems to get in the way :) ). I did use Google, and have tried several different decompilers/disassemblers. However, the results have not been quite what I was looking for. So, I was hoping someone else here with experience might be able to take a look and/or help point me in a better direction.

 

[berkeman]

I simply don't have enough knowledge to do it myself (and my real job seems to get in the way :) ). I did use Google, and have tried several different decompilers/disassemblers. However, the results have not been quite what I was looking for. So, I was hoping someone else here with experience might be able to take a look and/or help point me in a better direction.

Maybe someone else here will have some suggestions, but in my experience, dissasemblers just aren't all that common. They aren't really used for anything other than reverse engineering, so there's not much of a market for them.

When you run a compiler, you can often click on an option to "generate assembly listing" to check how well your code is being optimized. But using a stand-alone tool to convert object code back to assembly is an unusual thing. It can be done, but I don't think it's done very often.

 

[TexanJohn]

Yeah, my best results so far look something like this:

[SIZE="2"][SIZE="1"]00000000   78da                             MOVEQ     #0xda,D4

00000002   249b                             MOVE      (A3)+,(A2)

00000004   7940                             MOVEQ     #0x40,D4

00000006   1377 deff 93cc                   MOVE.B    (D_ff,A7,A5.L*8),(D_93cc,A1)

0000000C   7c8f                             MOVEQ     #0x8f,D6

0000000E   9984                             SUBX      D4,D4

00000010   a46a                             DATA.W    0xa46a   ;  'A-line' opcode (unassigned)

00000012   0e02 1e24                        MOVES.B   D1,D2

00000016   e152                             ROXL.W    #8,D2

00000018   130e                             MOVE.B    A6,-(A1)

0000001A   0fb4 bba2 2297 275e              BCLR      D7,([D_2297,A3.L*2]D_275e)

00000022   55db                             SCS       (A3)+

00000024   ae47                             DATA.W    0xae47   ;  'A-line' opcode (unassigned)

00000026   420e                             CLR.B     A6

00000028   8e40                             OR.W      D0,D7

0000002A   2052                             MOVE      (A2),A0

0000002C   ed76                             ROXL.W    D6,D6

0000002E   5741                             SUBQ.W    #3,D1

00000030   3972 2042 ef3d                   MOVE.W    (D_42,A2,D2.W),(D_ef3d,A4)

00000036   1ead 02bd                        MOVE.B    (D_02bd,A5),(A7)

0000003A   0b58                             BCHG      D5,(A0)+

0000003C   759f                             MOVEQ     #0x9f,D2

0000003E   ee3e                             ROR.B     D7,D6

00000040   fbb3                             DATA.W    0xfbb3   ;  'F-line' opcode (unassigned)

00000042   ad17                             DATA.W    0xad17   ;  'A-line' opcode (unassigned)

But I was hoping for something more like:

 if (eax <= 5) {
  switch(eax) {
      case 0:
        L004010a0("Two!\n");
        return(0);
      case 1:
        L004010a0("Two!\n");
        return(0);
   ...

I would just like to know if this is a pipe dream, or 'how' I should go about attempting. Thanks for the feedback.

 

[berkeman]

Converting (especially undocumented) assembly code into C is more of an art than a science, IMO. You write the C to try to match the assembly, and use the previously mentioned assembly listing output of the compiler to see how close you are getting. Are you just doing this for fun and learning, or is there another reason?

 

[TexanJohn]

Well, the computer is actually from a 2001 Corvette. It controls all the functions like spark, fuel, etc. I am a hotrod enthusiast. I own a couple of software applications that can communicate through a standard port (OBD-II) and allow manipulation of the file. However, there are definitely differences between the programs, and most them admit that they don't have all the code reverse engineered. I am a 'how' and 'why' kind of guy. So, it is mostly for me. I would just like to actually see how some of the code works. I am not interested in all of it. In fact, after seeing some of it, I might not be that interested. Right now, it is definitely a bug in my ear, and I can't seem to just leave it. A couple of hurdles that I have are: I am not familiar with C, assembler, etc. and have no idea how one would go about doing this in the correct order (i.e. simply programming the computer); therefore, I have no idea about trying to do it in reverse order either. I don't know anything about checksums, registers, memory locations, etc. So, I was trying to either get direction, help, or possibly hire someone to work on it with/for me.

Right now, I am trying to build a 700HP motor for my car, and tuning it correctly is of great interest. There is sooo much hype on the net regarding 'how' the computer functions. It is simply too hard to wade through it all. I just don't have the time to take some assembler classes, quit and work for GM for a couple years, etc.

I am still not for sure of the actual 'method' that one would follow to do what I am attempting.

 

[es]

I would just like to know if this is a pipe dream

Long story short, yes, it is a pipe dream. Forget decompilers.
(atleast until you can find a way to assign readability to c-code.)
The basic reason why is because there is not a one-to-one mapping
of assembly code to c-code. (Just think of how many ways there
are to rewrite just that short little snippet of c-code you wrote.
Perhaps with only if-statements, or instead of if-statements use
for-loop statements that always exit on the first iteration, etc, etc)

And don't even bring up compiler optimaztions of the assembly
which futher scramble things up...

There are some toy decompilers out there because it is
possible to find c-code that correlates to the assembler (albeit only in some
restricted cases). But their output often less readable (IMHO) than the origional assembly code. Think spagetti assembly code with c types. Why? AFAIK there is no effective algorithm (keyword being effective) to assign "readability" (whatever that even means) to c-code.

On the other hand the disassembler works because there is a
one-to-one mapping of binary object code to the text representation,
by definition.

 

[TexanJohn]

Thanks for the info. So, is my only hope then to learn that assembly language and start hacking?

Better yet, is there anyway to actually identify "tables" in the language? There are many 2 dimensional tables that control things like fuel where one axis is RPM and the other is MAP (manifold absoulte pressure). Is there a way to start identifying items like that?

 

[berkeman]

I'm not comfortable with most cases of reverse engineering, so I guess I'm out of this thread. I'm very much on the IP (intellectual property) end of the engineering business, and I don't like it when folks hack into my work to try to avoid having to spend the $Ms of R&D. But I will admit that reverse engineering part of a Corvette has its appeal...

 

[TexanJohn]

I'm not comfortable with most cases of reverse engineering, so I guess I'm out of this thread. I'm very much on the IP (intellectual property) end of the engineering business, and I don't like it when folks hack into my work to try to avoid having to spend the $Ms of R&D. But I will admit that reverse engineering part of a Corvette has its appeal...

Understood. AFAIK, there are 4 commercially available products out there that allow communication (up/download and altering of the file). I own all 4, and all seem to have their own quirks. I guess that is because they are all reverse engineering as I am proposing. They (the software creators) admit they don't have it all done. It is just frustrating. The problem is that I am a 'tweener'. I am somewhere between full-out racing and remaining street legal. For full out racing, I would simply yank the stock computer and wiring harness, and replace it with an aftermarket system. The aftermarket systems are much simpler in that they don't have to meet EPA requirements, daily driving concerns, MPG, etc. and therefore have significantly reduced functionality (i.e. less code and tables to understand). So, I was just trying to see what I could learn by looking at the stock computer.