EE dissection

**steveo** · 02-26-2014

right now i've kind of put specific disassembly on hold to try to document and comment the code a bit better; just so i can break things into code blocks and figure out what variables tie into what (which memory locations are fuel related, timing related, etc).

i figure if i grind at that for a few hundred hours it'll make my life easier in the long run, instead of just doing it as i go.

this is all a big learning experience for me too, never been this deep into this type of assembly code.

**fbody_Brian** · 02-26-2014

I'm sure it would make it easier in the long run, though I'm sure none of it will ever be truly easy. Wish I could help, but I know virtually nothing about assembly, only know c/c++, and some scripting languages like bash.

**steveo** · 02-26-2014

that's what im working with too, though. luckily c is low level enough where a good c programmer will recognize most machine code, at least in terms of how it's structured.

they're both weakly typed languages that rely on memory addressing (pointers) for reference, and data structres are built manually with pointer math-like things; no object orientation, just sets of instructions with jumps and compares to do loops or branching

remember c was written to be as close to machine code, it was from a time when compliation time and memory use were critical

should look some over!

if you are a unix lt1 guy you should check out my dash logger, i want someone else to build one, it's a fun toy, and since its in c you can hack it up to do whatever you want...

**fbody_Brian** · 02-27-2014

Originally Posted by steveo

that's what im working with too, though. luckily c is low level enough where a good c programmer will recognize most machine code, at least in terms of how it's structured.

they're both weakly typed languages that rely on memory addressing (pointers) for reference, and data structres are built manually with pointer math-like things; no object orientation, just sets of instructions with jumps and compares to do loops or branching

remember c was written to be as close to machine code, it was from a time when compliation time and memory use were critical

should look some over!

if you are a unix lt1 guy you should check out my dash logger, i want someone else to build one, it's a fun toy, and since its in c you can hack it up to do whatever you want...

Most definitely a unix guy. I actually teach linux classes at a local junior college and have used it as my primary os since around 92. I was looking at your code on github and will check it out more when I have the time.

**steveo** · 02-27-2014

some of its pretty scabby, but the results are good!

**steveo** · 02-27-2014

you know, brian, if you wanted to poke at it, you could learn this stuff pretty easy if you wanted

im still way behind, but you can figure a lot out just reading through the instruction set. it's all just a bunch of addressing and simple instructions, very similar to the ones that are spit out of your c code when you compile it.

there's an A and B register (8 bits each), and a D register that is just A and B together making a single 16 bit register, and a few others, X, Y, whatever.

these are for stupid fast temporary working storage of stuff, you have to load a memory address's contents into them, then operate on that register.

you just have to watch out for this special persistent set of bits called 'condition bits', which may or may not be changed or set by the results of practically any operation. they're whats used for branching.

the mnemonics of the disassembly is pretty englishy, ldaB is LoaDAddressB, cmpB is CoMPare to B, bcs is Branch if Carry bit Set, bne is Branch if Not Equal to zero

http://www.ele.uri.edu/Courses/ele20...ons/index.html

so just for example (but i'll probably screw it up)

Code:

E2B6	F6 1D 28        @3	ldaB	L1D28    ;    the B register now contains whatever is in address @ 1D28
E2B9	F1 24 8F        	cmpB	L248F    ;    compare B to memory address @ 248F (sets the condition register)
E2BC	25 0E           	bcs	@6        ;    if carry was set (meaning B was >= 248F) jump 14 bytes ahead
E2BE	F6 1D 29        	ldaB	L1D29    ;    B = address @ 1D29; but also sets the 'if zero' register
E2C1	26 04           	bne	@4        ;    if B != 0, then jump 4 bytes ahead
E2C3	86 02           	ldaA	#$02      ;   the A register now contains 0x02 (a static value)

so in c that would be like (pretending stuff like L1D28 is #define'd memory, which it is, ram is stored in all the low bytes):

Code:

char A,B;
B = L1D28;
if(B >= L248F) {
  goto //fourteen_bytes_ahead;
};
B = L1D29;
if(B != 0) goto //four_bytes_ahead;
A = 0x02;

and obviously once you've jumped, A and B still equal whatever they did when they left, there's no actual blocks of code, braces, or 'scope of variables'...

**fbody_Brian** · 02-27-2014

Originally Posted by steveo

http://www.ele.uri.edu/Courses/ele20...ons/index.html

so just for example (but i'll probably screw it up)

Code:

E2B6    F6 1D 28        @3    ldaB    L1D28    ;    the B register now contains whatever is in address @ 1D28
E2B9    F1 24 8F            cmpB    L248F    ;    compare B to memory address @ 248F (sets the condition register)
E2BC    25 0E               bcs    @6        ;    if carry was set (meaning B was >= 248F) jump 14 bytes ahead
E2BE    F6 1D 29            ldaB    L1D29    ;    B = address @ 1D29; but also sets the 'if zero' register
E2C1    26 04               bne    @4        ;    if B != 0, then jump 4 bytes ahead
E2C3    86 02               ldaA    #$02      ;   the A register now contains 0x02 (a static value)

.

That doesn't actually look too bad.

**steveo** · 02-27-2014

no it doesnt, because it's motorola code! it's easy

and if you learn it you can...... write raw code for early 1990s macs! im sure there's tons of job prospects for that.........

**kur4o** · 03-26-2014

Hi to all.

I am trying to dissasemble some ee bins with IDA pro. The problem is I don`t know for sure what type of processor is used and how much is the ram.
It is 6811 series but there is 50+ different variations. Also where in the bin is the entry point.
Any input will be appreciated.

I found some similarities betwwen the l32 v6 bins and the ee code.
That way i discovered some tables described in the v6 xdf are in the same configuration in the ee code.

28A4-29C4 /3-2 BASE DC/
28C5-29D5 /3-2 DC TEMP COMP/
29D6-28E6 /UNKNOWN ADDED AT EE/
289A /3-2 TEMP CORRECT FLAG, 3-2 A/C COMP FLAG/
289B /MIN 3-2 DC/
289C /MAX 3-2 DC/
289D /3-2 DC WHEN SHIFTER IN 1ST/
289E /3-2 DC WITH LOST VSS SIGNAL/
28A3 /A/C ON 3-2 MOD TO DC/

As described in the v6 xdf.
Credits go to the author of this xdf.
This still need to be verified but whatever they do in v6, they do the same in the ee, because they are mapped identicaly.

Caibration part number is located at
E20-E23 , converted from hex to decimal.

**steveo** · 03-26-2014

it's a 68hc11, any revision of 68hc11 will do in IDA i think? (not using ida right now)

so you're looking into some auto trans stuff? awesome; that's the one part in EE im not interested in looking at (my only ee car is a manual), but could definitely use some fresh info

i'd be really interested in anything else you find.

i dont have the disassembly in front of me, but i think i remember that 0x2000 is the entry point? (or something simple like that)

**fbody_Brian** · 03-26-2014

More auto trans stuff would be great!

**RobertISaar** · 03-26-2014

the 6811s used in the 94-95 LT1 PCM are both 68HC11F1 models.

L32? that would be the 93-95 F-body 3.4, which i released a pretty significant XDF for already, perhaps i never defined those tables?

**steveo** · 03-26-2014

hmm never actually looked at that 3.4 xdf, i'll have to check 'er out

**kur4o** · 03-28-2014

Thanks for the input.
This is how the software is organized.

Both flash chips code are very similar and capable of operating indipendently.
So it`s good idea to be dissasembled separately.

First 64k of Bin or split1

0000-0400 looks like some defaullt values loaded in the ram./exactly how much ram the processor has/
0400-1000 empty space with some random data bytes
1000-2000 not sure what it is.again some random data.
2000-3B03 all this is tables and caibration data
3B04-3C3D Code instructions
EC3E-3F10 Messages for flashing purposes
3F11-EED1 Code instructions
EED1-FFD6 some data likely connected with serial communication /not sure about that, definitely not calibration data/
FFD6-FFFF not sure

second 64k of bin or split2

0000-0400 looks like some defaullt values loaded in the ram./exactly how much ram the processor has/
0400-1000 empty space with some random data bytes
1000-2000 not sure what it is.again some random data.
2000-2E07 all this is tables and caibration data
2E07-2E93 Code instructions
2E93-3266 Messages for flashing purposes
3266-7FED Code instructions
7F3D-8328 some data likely connected with serial communication /not sure about that, definitely not calibration data/
8328-FF9F Empty
FF9F-FFFF not sure

split1 data and code for transmission, diagnostic, serial communiction, sensor inputs.
split2 data and code for spark and fuel calculations

there is built in 486 bytes eeprom in each processor
Probably Vin and Cal id encoded there

Now I am trying to find how the hardware part is structured and working.
Without that there is no way i can understand the software part.
There is
3 68hc11 processors on board
-2 c94r - 68hc11f1
-1 d84g - ?
there is
2 that look like custom delco processors
-66285
One more that looks like processor
-ncr 129170

something that looks like memory chips in 28-plcc pakage
-delco 64606
-delco 27474
-ncr 144436

I tried that entry point but it didn`t worked
Here is a file from ida with auto settings.
I am still far from reading it but learning fast.
Does it look correctly dissasembled.

I am thinking of adding nitro spark retard switch.
There is existing circuit in the pcm that takes signal from Ebcm for spark retard request.
Typical value for that pin is B+ /pin is red 23 if someone is interested in testing/
So the signal must be b+ or ground, still to find out.
I need help finding the traction control tables associated with that hardware signal, so there is no hidden suprises.

That v6 xdf is the best cracked code i`ve seen so far.
robertisaar i see your the author so big greetings to you.
I hope some day we crack the EE code that far.