[Diy_efi] Re: if YOU were bored enough to disassemble...

Jeffrey Engel jengeltx at yahoo.com
Fri Oct 18 16:43:32 GMT 2002


Brian,

I was looking at your disassembly out of curiousity (I
run a Ford EEC which has a proprietary CPU), when I
saw this chart (digraph) that linked all the jump
points with their respective routines.  Something like
that would be very helpful to my "reverse engineering"
efforts.

Are your scripts generic enough that they could be
modified for a different disassembler?  The one I'm
using does generate a file with all the labels and
jump points in it.

By now, you should have figured out that I'm more of a
hacker than a programmer.  I'm not sure I could write
something like that from scratch.  So now to the
Newbie-type questions:

Is a digraph common enough that there is reference
material on it?

Are you willing to share your Perl scripts, so I can
ask a million more questions and maybe learn Perl?

If your answer is "go away, kid", I could generate the
digraph (or something similar) manually, but it
wouldn't be dynamic.

Thanks, whatever your answer is.  The concept hadn't
even occured to me until I looked through your e-mail.

Jeff Engel

--- Brian Dessent <brian at dessent.net> wrote:
> "Dave Gallant, 12 Point Racing" wrote:
> 
> > And with this map, I can't even wager an educated
> guess. Possibly this is a
> > correction map of some sort...Overall, I am
> missing the location of the
> > secondary fuel map, however my first guess would
> be this is a timing
> > adjustment map for the coolant temperature sensor.
> (I am told timing is
> > pulled out as the bike's coolant gets hotter and
> hotter, and it is not
> > linear. I would LOVE to kill this calibration
> factor at some point). Of
> > course, this is just a guess, and it quite
> possibly could be some strange
> > correction map for the secondary fuel map. This is
> where having a CLUE as to
> > what the code was doing would be worth its weight
> in gold. :/
> > 
> > Keep the thoughts coming - it has only taken you
> guys 1 day to get as far as
> > I have gotten in 1 month. :)
> 
> Well, I've been tinkering with this, I guess because
> I'm bored or
> something... :-)
> 
> Anyway, I've been using Peter Gargano's DHC11
> disassembler
> (http://www.techedge.com.au/utils/dhc11.htm) because
> I think the output
> is prettier.  Beware that it renames a few opcodes
> from the "standard." 
> Anyway, my setup is currently a huge kludge of Perl
> scripts, but I've
> been making progress.  You can see my current
> disassembly here:
> 
> http://www.dessent.net/tmp/748.DIS
> 
> As you can see I've assigned names to the
> subroutines that are a little
> easier for a human to understand.  I've also poked
> around in a few of
> them and given them a meaningful name.  Same with
> some of the variables,
> although most of them are still Lxxxx.
> 
> The biggest problem with getting a meaningful
> disassembly is the use of
> jump tables.  This makes things pretty frustrating
> because the
> disassembler has to know about all the entry points,
> otherwise the
> listing is either a bunch of un-disassembled bytes
> (dw, db, etc) or
> gibberish because it's trying to disassemble stuff
> that isn't opcodes. 
> I think I've gotten all the entry vectors covered
> now, but there are
> probably a few subroutines left.  It's an iterative
> process, every time
> you uncover some code you have to go and check any
> new dreaded "call 0,
> X" statements -- or even worse: "ldx <var>; call 0,
> x"  This is the
> worst because it's jumping to an arbitrary pointer. 
> So then you have to
> track down any possible values for <var> and make
> sure the disassembler
> knows about them.  But even worse then that are
> these stupid
> 3-byte-per-entry vector tables where the code
> searches for a lookup
> index value (the first byte) and then calls the
> corresponding address
> (the other 2 bytes.)  I resorted to just adding a
> 1-entry vector (to the
> .cfg file) for each entry in these type tables. 
> This is an example of
> what I'm talking about:
> 
> C903    vec9_00-0
> C903            ldX     #$C83E
> C906            call    sub-41
> C909    vec9_00-1
> C909            ldaA    #$09
> C90B            staA    L00A2
> C90D            bset    L0081, #%10000000
> C910            jmp     0, Y
> 
> "sub-41" searches through the table pointed to by X
> for a value that
> matches A, and returns the corresponding jump
> pointer in Y.  A big mess
> if you ask me.
> 
> Other stuff:
> 
> I tried give meaningful names where possible.  I've
> also added the
> mneumonics for the HC11's registers, which helps to
> interpret the code. 
> Note that the ECU maps the HC11 registers to the
> first 4k page, so they
> show up as $0000 - $005f, instead of the usual $1000
> - $105f.  I'm
> assuming we're dealing with a "F1" family (ie
> mc68hc511f1) since I
> noticed from your pics that the MCU is a 68 pin
> plcc, and the only
> family with this package is the F1, accoring to
> motorola's site.  (BTW
> if you haven't gone there yet and grabbed all the
> tech manuals, do that
> now, there's a buttload of stuff.)  Oh and if you
> want to start poking
> around with tracing pins, start with the A/D inputs,
> pins 59-66 (see
> datasheet for a picture of how to identify the
> pins.)  Surely these are
> connected to something interesting...
> 
> Anyway, (one of...) my config file for dhc is here:
> 
> http://www.dessent.net/tmp/748.cfg
> 
> That doesn't include all the renaming that I do
> (it's a multi-step thing
> I do with some scripts) but it's enough to get the
> basic disassembly. 
> There's also some notes where I was analyzing some
> of the
> interpolation/math assembly stuff (and other random
> junk):
> 
> http://www.dessent.net/tmp/notes.txt
> 
> Also, I hacked together some perl to use the
> GraphViz library to make a
> neat digraph of all the function calls.  Check it
> out: (you'll want to
> zoom in with your PDF viewer to make sense of it
> all.)
> 
> http://www.dessent.net/tmp/748-asm-graph.pdf
> 
> The interrupt routines are differentiated from
> normal subroutines by the
> polygons vs. ellipses.  Edges correspond to "CALL"
> instructions.  The
> routines named "vec_..." were derived from the
> vector jump tables, the
> "sub-...." routines are ordinary subroutines.  And
> if you must know, I
> numbered the sub-'s in order of call frequency, so
> the low numbered ones
> are called most (in the static disassembly at
> least.)
> 
> Brian
> 
> _______________________________________________
> Diy_efi mailing list
> Diy_efi at diy-efi.org
> http://www.diy-efi.org/mailman/listinfo/diy_efi


__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

_______________________________________________
Diy_efi mailing list
Diy_efi at diy-efi.org
http://www.diy-efi.org/mailman/listinfo/diy_efi



More information about the Diy_efi mailing list