Developing a disassembler. Send me your binaries to test

This is where the BIN Hackers and definition junkies discuss the inner workings of the EEC code and hardware. General tuning questions do not go here. Only technical/hardware-specific/code questions and discussions belong here.

Moderators: cgrey8, EDS50, Jon 94GT, 2Shaker

tvrfan
Tuning Addict
Posts: 368
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Developing a disassembler. Send me your binaries to test

Post by tvrfan » Sun Apr 15, 2012 5:21 pm

I'm now testing my disassembler and I am looking for more binaries to use for testing.

I am therefore asking for any (eec-IV) binaries that you wish to send me, please.

I have quite a few from the web, but am always interested in more.

In return I will release the disassembler with instructions on how to use it, for all those who want to understand how their EEC boxes work (and possibly tune them).

I am close to a version which is good enough to release.

Thanks to all.
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

User avatar
cgrey8
Administrator
Posts: 10565
Joined: Fri Jun 24, 2005 5:54 am
Location: Acworth, Ga (Metro Atlanta)
Contact:

Re: Please send me your binaries !!

Post by cgrey8 » Sun Apr 15, 2012 5:56 pm

2012-04-13_MFA.bin
GUFB/X3Z based tune with FN1360 patch applied. I think there is another patch applied, but I can't remember now.
(56 KiB) Downloaded 533 times
Will you be posting the compiled disassembler or also the source code? I'd be more interested in looking at the source than using it to do disassembly.

Also is there any chance you wrote the reassembler? Or did you write the disassembler to disassemble into a format that is reassembled using existing assemblers for 8061/5? The thing I've often wanted to do is to be able to add code to my binary, in essence making a completely custom strategy, but do so in an easy to do way that can be easily reassembled back into a bin file. Currently the only way to do this is strategic placement of raw HEX that's been manually configured. I'd like an IDE that understands that as code "moves around" all the affected memory references also need to be updated throughout the code as well. I think all the jumps are relative jumps anyway in the HEX. However all the disassembly I've seen labels the jump to absolute addresses or to labels.

Another neat addition to such a disassembler/assembler would be to allow a user to open an existing def file along with the BIN file. And as code is being modified/added, have the tool automatically "fix up" the def file as well to keep them in sync. That would be awesome!!! But just having a working disassembler that didn't require you maintain a descriptor file to keep it from tieing its shoe laces together on stack-manipulated code would still be a major improvement over what we have today.
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

tvrfan
Tuning Addict
Posts: 368
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Please send me your binaries !!

Post by tvrfan » Mon Apr 16, 2012 4:20 pm

Thanks Cgrey8...

I'll have a look at that binary and see what the tool does with it. If it looks good, I'll post the results here.

I wrote the tool as a way to understand what the code (and data) does, and for it to be able to identify code and data structures automatically with as few commands as possible. This way our human brains can see what's going on. Later binaries may still need a few directives, but FAR fewer than a 'dumb' disassembler.

At present the format it produces would not be very useful for reassembly. I guess I could change it to produce re-codeable output...

I understand what you are saying. If you want to add code or data, rather than just changing what's there already, then you would have to do a lot of work to change the relative addresses etc. and it's a pain to do all that hex.

Yes, jumps are ALL relative to current opcode, and I've seen several comments around that says that the lawrence disassembler doesn't always decode the jumps correctly. I think that's confusion over signed/unsigned values. Mine works correctly as far as I can tell.

Later binaries also use 'register + offset' opcodes a lot, and use more stack fiddling, whereas earlier ones tend to use direct addresses. The only obvious reason I can see for this is that Ford changed their build tools/environment. This makes later binaries harder to decipher.

My intent was to release the tool as a Windows executable.... but I might consider the source as well. It's written in C, compiled with an old Borland C++ IDE.

Hmmmm. A full 'EEC-IV IDE' would be quite a challenge !! It would need to be able to sort code from data also as a first step ... Engage OCD mode.....

Andy.
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

tvrfan
Tuning Addict
Posts: 368
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Please send me your binaries !!

Post by tvrfan » Mon Apr 16, 2012 4:50 pm

as promised....

This is the output my tool produced with NO DIRECTIVES AT ALL. Just the binary, with no clues or anything. As you can see it's not perfect,
- some of the subroutine embedded parameters missed
- should have cut off at 0x9ffff,
- hasn't defaulted to Hex either, which it should have....now that's really strange....

It has identified quite a lot of the code and data, functions and tables, and the main lookup functions, and quite a few embedded subroutine parameters... not too bad I think.

Good - some more bugs to find !!

Comments welcome !

(zipped 'cos out here in the country the bandwidth can be terrible)

Andy.
Attachments
MFA.zip
(183.59 KiB) Downloaded 546 times
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

User avatar
cgrey8
Administrator
Posts: 10565
Joined: Fri Jun 24, 2005 5:54 am
Location: Acworth, Ga (Metro Atlanta)
Contact:

Re: Please send me your binaries !!

Post by cgrey8 » Mon Apr 16, 2012 5:52 pm

Another thing to see if the disassembler can determine automatically is to find dead/orphaned code...code that Ford left in the tune, but isn't referenced or accessed by any of the loops. There's a number of scalars in the GUFx defs that indicate the strategy doesn't use the scalar because it was later determined the code was not used. But the references were left in the def for others that wanted to decipher the code and determine that for themselves.

As for the C code being in Borland. I tried using Borland a while back but gave up and used C#.NET instead. But then again, what I was doing was very UI-intensive, not algorithmic intensive. C# just handed the job so much better than the old Borland stuff could. Once you get the issues worked out, I think it would be neat to get the code ported to C#. Why? Clint programs in C# and I'd be really interested to see what he could do with a disassembler. He's not strong with the assembly stuff, but he knows UI programming like the back of his hand after programming EA and BE. So I think once he had some already-written code working and all he had to do was take the code and fit it into a tool, I think he could do a lot with it...that is assuming he wants to.
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

DonMaximo
Regular
Posts: 104
Joined: Mon Apr 06, 2009 9:57 pm
Location: Dallas/Ft.Worth Texas

Re: Please send me your binaries !!

Post by DonMaximo » Mon Apr 16, 2012 8:02 pm

tvrfan wrote:I'm now testing my disassembler and I am looking for more binaries to use for testing.

I am therefore asking for any (eec-IV) binaries that you wish to send me, please.

I have quite a few from the web, but am always interested in more.

In return I will release the disassembler with instructions on how to use it, for all those who want to understand how their EEC boxes work (and possibly tune them).

I am close to a version which is good enough to release.

Thanks to all.
Attachments
4-13-12a.BIN
I had lots of help from Decipha Mike - I still have some Cold start adjustments to make, but have it. Very curious to see what you're working on ?
(56 KiB) Downloaded 500 times

-D
1992 Mustang LX Conv, T&L 347, DART PRO-1 heads,
MAC Performance CAI + 76mm MAF setup for 30lb injectors + 75mm TB,
GT40 Upper/Lower intake-(Extrude honed)
MAC ceramic coated long tubes + ProChamber,
PA Performance 240A Alt, Mark VIII fan w/ DC Controller,
TKO 600, SSBC Big Brake System,
A9L, Moates-QH, Innovate LC-1, EEC Analyzer & BE

tvrfan
Tuning Addict
Posts: 368
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Please send me your binaries !!

Post by tvrfan » Tue Apr 17, 2012 12:02 am

cgrey8 wrote:Another thing to see if the disassembler can determine automatically is to find dead/orphaned code...<snip>
Well, my tools does this automatically, sort of. It scans through the code looking for jumps and subroutine calls etc. and on the way it does check for data accesses. Code which is not accessed will not be disassembled (unless you tell it to), and data not accessed will be the same.

The A9L and siblings though have a kind of 'encoded' address in some of their subroutine calls, which messes things up. Also it's sometimes impossible to tell if a direct value (a constant) is an address or just a calculation scalar. So it can't be right always. There are some small unused bits in the A9L, but most of the code and data is used (as far as I can tell - there are option flags all over the place however)

There was also some obvious talent at work in the binaries, with some very neat and clever code and data, lists etc, which can also be tough to understand...

(C versus C++ and C#).

My background is UNIX and so C is my 'home' language, and I find it very easy to write. I got a copy of Borland C++ a while ago, can't remember where, I think it was a licence free copy on a compilation CD ? So I have a C++ module for the Windows GUI, but a 'core' disassembler written in C. Bit of a dinosaur when it comes to newer languages, except perl, which I have also used quite a lot for various script type jobs in UNIX.

It may well be possible to keep the 'core' in C and simply call it from another UI module ?? That's kind of what happens now...

DonMaximo - thanks for binary, will try that out too
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

decipha

Re: Please send me your binaries !!

Post by decipha » Tue Apr 17, 2012 12:20 am

i have a j2e1 cal i'd like you to run, its a speed density binary from a 92 f150

on the audio computer now and don't have access to my laptop, will post asap

tvrfan
Tuning Addict
Posts: 368
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Please send me your binaries !!

Post by tvrfan » Wed Apr 18, 2012 10:56 pm

I knew my tool should have decoded A9L siblings correctly, so didn't understand why the MFA didn't work - I found I had managed to put in a new bug with my last changes....now fixed.

attached is a new MFA listing, and a 4-13-12a as sent. Both of these look very like the A9L code...
both zipped...

Both of these decoded with NO directives at all.
Attachments
MFA2.zip
(147.51 KiB) Downloaded 461 times
4-13-12a.zip
(145.16 KiB) Downloaded 660 times
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

User avatar
cgrey8
Administrator
Posts: 10565
Joined: Fri Jun 24, 2005 5:54 am
Location: Acworth, Ga (Metro Atlanta)
Contact:

Re: Please send me your binaries !!

Post by cgrey8 » Thu Apr 19, 2012 8:01 am

So what's the basis behind the algorithm? Does it simulate exectuion and keep up with stack manipulations the way a real processor does?

Or does it make use of some kind of multi-pass technique learning from mistakes of previous passes, remembering those mistakes and trying again with a different tactic in the areas where it realized it went astray?

I always envisioned if I wrote a disassembler, it'd be more of an emulator than a traditional disassembler. The only difference is it would make a list of all the conditional jumps it encountered and what the jump address was, and iteratively "revisit" each of those addresses later. This would've meant maintaining all the internal registers, keeping up with a working stack, as well as maintaining a list of every conditional jump hit. I imagine I'd also want to maintain a list of addresses already disassembled so I could clean my jump list of addresses already explored.

Once I'd walked through the code as far as I could (background loop and all interrupts), I'd circle back to all the jump addresses in my list, clean which ones were hit just by walking the code, and continue on walking the code at whatever jump addresses were still left that hadn't been explored. Once all encountered conditionals had been explored, whatever code was left that hadn't been analyzed was either filler or orphaned/abandoned code. But because the emulator would have a list of all addresses it explored, it could easily report the "holes" and possibly analyze whatever was left over to see if it was abandoned code or patternous filler as you often see at the end of BINs. I'm sure there's holes in my logic or additional things that would need to be done/maintained. But that's kind of what I envisioned a configureless disassembler for these BINs would be. Looking at your disassembly, it appears you are even keeping up with how data is handled so you know whether data was accessed as a scalar, function, or table. And it appears any un-referenced data is marked filler. That's pretty neat there, or am I mis-interpreting what's going on?

What I don't know is if runtime values from I/O would ever decide specific code paths or if all conditional code paths are fixed addresses. If every possible jump is to a hard coded address then I think this technique would work. But if runtime logic manipulates register pointers such that the same jump instruction doesn't always jump to the same address, then my technique might not decipher all possible code paths...particularly if that practice was rampant through the code. What little I know about assembly, I believe all jumps are to the same location. For example, when you have a section of code that's evaluating a function or a table. That piece of code always interpolates values in the function by jumping to the function handler at very specific locations depending on whether the function is byte or word sized and whether the input or output is signed or unsigned. Where it jumps to in the function handler is always the same because the function is always what it is. However what I don't know is if there are creative code configurations that are similar to a C switch...where code might load up any of 4 or 5 different addresses into a jump register, then a given jump instruction jumps to whatever got loaded into that register. My deciphering of that code may only find one or two of those possible addresses particularly if those addresses are based on I/O values. But if knowing that is a possibility then a brute-force exhaustive reiteration of the code could be done with every possible I/O combination. It might take hours, possibly days, to disassemble every possible combination, but in a 16-bit machine, the combinations would not be infinite nor out of the abilities of the high speed machines we have today...at least I don't think.

Anyway I've rambled on enough...
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

decipha

Re: Please send me your binaries !!

Post by decipha » Thu Apr 19, 2012 8:24 pm

try this j2e1


i have no idea what strategy it is, that alone would be a significant help in me getting some information on it
Attachments
J2E1.BIN
(56 KiB) Downloaded 507 times

tvrfan
Tuning Addict
Posts: 368
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Please send me your binaries !!

Post by tvrfan » Fri Apr 20, 2012 1:54 am

So what's the basis behind the algorithm? Does it simulate exectuion and keep up with stack manipulations the way a real processor does?

- - - - -


I'll answer from a slightly different angle if that's OK...

I'll just say first, these are my opinions, and I'm sure there are better brains out there, so any suggestions/arguments welcome !

When I studied the design options, I realised that there is an inherent catch 22 in them all. There is no easy way to decode perfectly (without directives and a human brain). Guesses have to be made, and they aren't always correct. But you can get close ....

Option 1. Emulation.

You emulate the code exactly to execute everything that is code, and then flag everything that's accessed as data. You then do a pass to label data, code etc....

The problems with this approach are -

A lot of binaries have sections switched off, Optional Sensors (EGR,FAN,VSS), ignition options, number of cylinders, auto/manual trans. That's just for starters. Some have options for alternate algorithms, and 'dead' code too. It's easy to spot subroutines with 'embedded' parameters and shortcuts (i.e. stack fiddlers) however.

To emulate you have to build an environment which simulates the engine environment, sparks in, sensors in, the CPU itself (HSOUT, interrupts, ...), the sensors....

Then, how do you decide what is a table/function data structure just from the fact it gets a few, or just one, data access ?

Then remember there are specific code blocks to handle cranking, overrev, trans gear changes, goosing throttle, full throttle, ALL of which would have to be simulated to excercise all the code.

I have actually written an emulator which does work. but I'm sure it's not totally faithful to a real environment. It's useful for those "what does this lump of code do ?" questions.


Option 2. Scan and log

This is the method that my tool uses. Your description is correct at the basic level.

It starts at 0x2000, and decodes each instruction. It then checks the operands and logs anything that might be a data access. Each jump is logged to a jump ('scan') list. It also maintains a 'data' list. It checks to see if a data access is subsequently used in an indexed PUSHW instruction, as that is a subroutine/jump address list (a Vector list). There are other lists too, symbols (names), subroutine definitions, etc.

A 'static' jump (i.e. JMP) or a RET ends the current scan block, and it then scans the next 'jump' list entry. 'Logical' jumps (i.e. JGT) are also logged, but the scan process continues to the next instruction, as this jump may or may not occur. It then checks to see if jumps go to sections already scanned, and so on.

A subroutine call causes a new nested scan, and at this point the tool has to check if the stack is fiddled ( with POP-PUSH) to see if the subroutine has 'embedded' parameters. This is recursive, as several levels of subroutines may be called, and the A9L is a nasty bugger, because it has subroutines which get parameters from their GRANDCALLER (i.e it POPs twice) which takes some extra special handling to get right (see 0x3695 and 0x77be). The A9L also has some very nasty shortcut tricks (POP, RET, see 0x245a ), which can return back to a Grandcaller subroutine. (I suspect this is their equivalent of 'break' as used in C.)

I also added a process which I call a 'signature match'. The code Ford uses for a table lookup hasn't changed much at all over the various binaries. It's a small efficient, fast block of code, so they quite rightly reused it everywhere. The same applies for the function lookups. So you can write a variable matcher which recognises these subroutines and flags them, and then it can also make a list of functions and tables. This is also how it knows word/byte, signed/unsigned combos. The process can't be an exact match, as there were some small changes over the binaries, but the principle is still valid.

There's also some other details, like recognising that A9L and later binaries use some registers as 'base' pointers and then use indexed address instructions, filling out tables and functions to their boundaries, etc. and I could write a whole paragraph about how symbols (=names) are handled and recognising bit flags with their names.

The tool uses the above approaches even with directives, unless specifically told not to, so that with a few well chosen clues, it can do most of the work automatically with a 'boss' to stop it going wrong.

What's then left over is either 'dead' code, filler - which can be recognised because it's all 0xff, or unused data.

Early code like my 'AA' is really easy compared to the A9L, as it has no stck fiddling, and all straight calls and returns...but it still takes a while to work out what the code is actually doing.

The problems with this approach are -

It's VERY, VERY hard to write code with intelligence !!

There's no way to know if an operand is a real address (to a data item) or a scalar for a calculation.
The stack on 8061 is used for both addresses and data - no assumptions can be made on what's there.

(When your human brain looks at the listing, it thinks "that number is odd, it must have significance, if I multiply that by 2.4 I get 1 million, Ah! 1 second.....") which a tool can't easily do.

Coding tricks used by clever coders....

Some of the stack tricks are hard/impossible to decipher automatically, and getting it wrong will almost always cause the instruction after subroutine to go awry. You can do a little bit of guessing, but not always. Tool will recover on the next 'jumped-to' address, but will then leave a small (hopefully !) lump not decoded.

Some of the PUSHW lists have odd gaps in them which can cause incorrect jumps to be logged. (A9L).

There ARE some points when an address is PUSHed onto the stack and then executed. As these addresses have to be stored somewhere, with a bit of care they can be mostly sorted, but again not always totally correctly.

The A9L uses a encoded address for some of it's subroutine calls. I had to add a special option to handle these, and that is the worst problem, there are logic tricks which have to be specifically handled, and can't always be recognised.


I have a later binary (EARS) which gets addresses for function calls differently to all the others... AARGHHHH !!

- - - - - - -
That's not ALL the detail, but I hope it gives a good overview and flavour of what's going on.

I've still got a list of extra things which tool can/should do, which is ongoing...

What you say about a C switch statement - you are right, in most cases the compiler builds a 'vector list' for each case, but this list is not necessarily built on the fly, it's often included as a static list within the code, and addresses are in fact fixed (just like A9L). If you build it as dynamic library (ie. a DLL) then it uses fixed offsets from a known point, the start of the subroutine (as far as I know), which can still be deciphered.


I hope that lecture wasn't too long and boring !!
Apologies if I've bored anyone, but it's great to be able to discuss this type of stuff, and keep the brain working.
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

decipha

Re: Please send me your binaries !!

Post by decipha » Fri Apr 20, 2012 11:36 pm

this pretty much sums up why i stayed away from disassembly, its less headache to just assemble, then you make it do exactly what you want when where and how you desire, at least in my opinion/experiences.


im suprised no one has come out publically with their own code to execute on one of these ecu's

tvrfan
Tuning Addict
Posts: 368
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Please send me your binaries !!

Post by tvrfan » Sat Apr 21, 2012 1:43 am

decipha wrote:try this j2e1
i have no idea what strategy it is, that alone would be a significant help in me getting some information on it
And just to prove exactly what I said above, the J2e1 appears to be very like the EARS binary I have, and my disassembler doesn't do this right at all - it still manages quite a lot of code, but doesn't pick out the functions and tables...... SIGH !

More stuff to do then .....
Attachments
J2e1.zip
(202.45 KiB) Downloaded 492 times
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

tvrfan
Tuning Addict
Posts: 368
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Please send me your binaries !!

Post by tvrfan » Sat Apr 21, 2012 1:48 am

decipha wrote: .....im suprised no one has come out publically with their own code to execute on one of these ecu's
Yeah, I think there is enough knowledge around to COMPLETELY replace the code, but I reckon testing would be a challenge, and companies probably want to stay away from liability issues.

I'm just thinking that starting with a simple base (like the AA or similar early European code) may be do-able, it's only 3K and does nothing fancy at all. But then it doesn't have sequential injection or 'waste spark' module driver code or toothed wheel handler, so probably is no good for more modern engines.
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

mpaton
BIN Hacker
Posts: 370
Joined: Mon Jun 23, 2008 1:39 pm

Re: Please send me your binaries !!

Post by mpaton » Sun Apr 22, 2012 12:12 am

decipha wrote:try this j2e1
i have no idea what strategy it is, that alone would be a significant help in me getting some information on it
So how would you go about getting information on it, based on knowing its strategy. It has the Data Control Link, so you could connect a scanner, and it would tell you what it;s up to.

It's a reasonably modern, later SD OBD-1 bin, very similar to the LHB* bins.

But surely you're teasing us here; haven't you been messing around with it already?

I did have a 400ci engine in my 79 Town Coupe, but it had a carburettor. I wasn't aware of an
injected 400 engine. What is J2E1 from?

mpaton
BIN Hacker
Posts: 370
Joined: Mon Jun 23, 2008 1:39 pm

Re: Please send me your binaries !!

Post by mpaton » Sun Apr 22, 2012 12:26 am

decipha wrote:this pretty much sums up why i stayed away from disassembly, its less headache to just assemble, then you make it do exactly what you want when where and how you desire, at least in my opinion/experiences.

I don't think you appreciate just how much effort is involved in getting these things to be correct. Getting it to do what you want it to do when you give it the inputs you want is less than half the work. And if you can't understand, or don't want to do the work to disassembly, I don't think you should be writing assembly code.

Most people never consider getting it to NOT DO what you don't want it doing, when it gets inputs you didn't think of is something else. Ford code gets hundreds of thousands of aggressive beta testers!

Think about:

1 Why do all scaling functions have to give sensible values for any input, even if sane values
are a four hundredth of the max input value?

2 Why did I get a new input file for Caledit so I could data log, and then I find my transmission
won't shift any more? I wasn't logging any transmission variables.

decipha wrote:im suprised no one has come out publically with their own code to execute on one of these ecu's
I wouldn't touch it if they did; see Item #2 above.

Aside from that, the later Ford code has most of what you want, especially for Normally Aspirated cars. Code you don't want executed, is left in there, but disabled by setting data constants. Seems to work well enough. Of course you do have to spend a LOT of time decoding and understanding the program.

User avatar
cgrey8
Administrator
Posts: 10565
Joined: Fri Jun 24, 2005 5:54 am
Location: Acworth, Ga (Metro Atlanta)
Contact:

Re: Please send me your binaries !!

Post by cgrey8 » Sun Apr 22, 2012 7:16 am

I see both sides of the argument. But I do have to admit, it's easier writing new code than it is understanding existing code written by someone else. I have to deal with a gigantic codebase at work mostly written by others, some of which don't work for the company anymore. And making heads or tails of what the original programmer was trying to do even when you have the original source code and maybe a comment or two is very difficult sometimes. It takes not just understanding the language of the code, but also the application that's being coded for in order to make any intelligent change. And when the original developer didn't leave any comments to fill in a new guy years later, putting all those pieces together in your head is difficult. Single-stepping through the code helps. But if the code is written particularly badly, sometimes it's easier just to abandon it.

Working with Ford disassembled binaries is one of the worst case scenarios. Without a good disassembler, you don't even have lucid code. So before you can even begin to understand what the code was doing, you've got a massive mess to untangle. For the uninitiated, think a 2000 foot water hose or extension cord that was thrown in a pile and dragged around a bit and you've got to get it straightened out. If you've ever untangled a 100 foot one, you know exactly what I'm talking about. And even once it is straightened out, you still don't have the original source code organized in a way that makes sense with variables and function names that are named intelligently. You don't have original developer comments. You don't know what the data conversion of the things you can decipher as being data are. And without a strategy doc, you often don't have a clear picture of exactly what it was the developer was trying to do. Oh and it's assembly you have to decipher in the 1st place which is particularly tedious in an ideal development setting.

So I get how he feels that it's just easier to write new than to untangle the disassembly especially when once it is untangled, you still have to understand what the code was trying to accomplish. That takes a LOT of patience and so it's not a difficult leap for someone to just decide to abandon and rewrite. I'm just saying I get how others could come to that conclusion because I've been there myself and I think both sides have merit.
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

tvrfan
Tuning Addict
Posts: 368
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Please send me your binaries !!

Post by tvrfan » Sun Apr 22, 2012 4:45 pm

I have to agree with mpaton here.

Whilst I said it *could* be do-able to completely replace the code, I have to ask the question "would YOU drive it afterwards ?" because I wouldn't, not without a sh*tload of verified testing.

Even with all of Ford's resources, you can see that reading the GUFB and other strategy documents, they too got things wrong in production boxes. How can an amateur compete with that ?

That's why I was trying to come up with a disassembler which was aimed at UNDERSTANDING what the code does, FIRST, and THEN [possibly] modifying it, when you know what you are doing.

I know that some EEC modifiers claimed money for a modded box, and all they did was raise the rev limit and then claim more power... and they got away with that for quite a while.

Sure, there's power available, as I'm sure Ford used conservative settings because they wanted no trouble over a wide range of uses, so timing can probably always be reworked, but if you go just that bit too far, you've got a trashed engine...

I can't help but think the old stone age methods (head ports, cams, turbo, superchargers) are still the only reliable ways to get loads of power, and then mod the EEC to match, or use an existing one already set up for that.

Anyway enough preaching. I will continue to try to get a tool which is able to decipher and help understand what the code does - and it looks like I'll be at this for a while yet...
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

tvrfan
Tuning Addict
Posts: 368
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Please send me your binaries !!

Post by tvrfan » Sun Apr 22, 2012 4:53 pm

Another thought just occurred to me.... I remember the story about good IT testing,
it goes like this ...

A large software team write software which can fly a plane automatically, without a pilot. They test and test and test, and eventually it gets signed off as a semi-automatic system to aid pilots, like a cruise control with extra warnings.... it works well.

The team was asked " How many of you would fly in that plane without the pilot ?"

Guess how many put their hands up.....Yep, you got it..... NONE.

And if you're an IT person, you will probably nod and smile.....
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

User avatar
cgrey8
Administrator
Posts: 10565
Joined: Fri Jun 24, 2005 5:54 am
Location: Acworth, Ga (Metro Atlanta)
Contact:

Re: Please send me your binaries !!

Post by cgrey8 » Sun Apr 22, 2012 5:31 pm

Oh I fully agree, there'd need to be a ton of testing. And if you are talking about reprogramming one of these old boxes, I'd be right there in the same position saying no way. But if you are working in a more convenient hardware architecture with lots more processor power and memory, then you get the benefit of working in an easier programming language like C/C++. And you wouldn't be under the same constraints Ford was with having to program once for hundreds of thousands of cars, programming for a tight/constrained environment, little live debugging ability, programming for warranty, etc etc. Granted being able to program in an easier environment doesn't excuse you from testing. But if you did program such an animal, then release the code as open source on a platform that is easy to acquire, then many more eyes will look at the code and any bugs found can be fixed and resubmitted to the community. It'll take a LONG time, but if you could make it decent enough for people to work with, you'll eventually get a distribution of your code that's had many eyes looking over it and has been tried-n-trued over many vehicles in many different configurations. Not to mention, with open source, the community can help in adding new features as they are needed. That's how the Linux kernel came to power.

Practically speaking, would anybody actually trust the code enough to begin to test it? Who knows. But I applaud anybody willing to attempt a venture like that.
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

tvrfan
Tuning Addict
Posts: 368
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Please send me your binaries !!

Post by tvrfan » Sun Apr 22, 2012 6:35 pm

As much as it's painful to type these words,

IT'S ALREADY BEEN DONE ! -> it's called Megasquirt. (look it up on web)

It's a totally open source injection system. With the adapator board, it can also replace an EEC-IV and use all the existing sensors. (I think it can now even handle a TFI distributor !). Code is open source too, and full instructions on how to fiddle with it. And it's CHEAP by comparison with some other options. I'm not sure if it's quite up to the latest advanced setups, but it covers a wide range of GM and Ford stuff.

Huge respect and Kudos to those guys - they deserve it. Yes, truly.

It's VERY, VERY tempting to go that way for tuning. It's just so much simpler than EEC-IV.

I can cover my embarassment by saying I now know the Ford settings of my engine to plug in, now I've decoded my box.... (yeah, yeah)
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

User avatar
cgrey8
Administrator
Posts: 10565
Joined: Fri Jun 24, 2005 5:54 am
Location: Acworth, Ga (Metro Atlanta)
Contact:

Re: Please send me your binaries !!

Post by cgrey8 » Sun Apr 22, 2012 6:50 pm

I knew about MegaSquirt, but I guess I never looked into it enough to know that it was open sourced. Interesting...

But MegaSquirt hasn't been maintained well if it is open source. It doesn't have SEFI does it? I'm curious if they've maintained the code to support VVT, coil-on-plug ignition, and all the latest technologies. I should go read up on them more. If it's written in C, it may be portable to other platforms. Although the only thing I'd want to port to would be an ARM based processor running Linux. But to get real-time control, you need to write Linux Kernel Modules (drivers). But with AM335x based Beaglebone dev boards, you can do a lot. There's just not enough I/O on those chips to get ALL the I/O a vehicle has. So additional hardware would have to be added to MUX the analog inputs and control the outputs.

But this is getting WAY off topic. As it relates to this topic. I'm just glad there are still people looking to make disassembly easier for those looking to disassemble BINs and make def files. Adam's done a great job of supporting LOTS of Ford BINs but all his are proprietary and licesable. And I understand why. But I'm hoping there'll be some people that make more open source defs.
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

tvrfan
Tuning Addict
Posts: 368
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Please send me your binaries !!

Post by tvrfan » Sun Apr 22, 2012 6:53 pm

Back to main thread...

I added the extra method for getting at function/table subroutines and their addresses, and here is reworked j2e1.

Better, but still lots of unknown stuff. There seems to be several data structures to decode - probably an injector table like A9L, and an initialistion list (a448) and a couple of other data lists I found (like the AD read table) and have added by directives.

You can see some of the scaling functions now (0xb000 onwards)

After all that, there is still the issue of finding out what all the code actually does....
Attachments
j2e1.zip
(196.74 KiB) Downloaded 481 times
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

tvrfan
Tuning Addict
Posts: 368
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Please send me your binaries !!

Post by tvrfan » Mon Apr 23, 2012 1:28 am

cgrey8 wrote:I knew about MegaSquirt, but I guess I never looked into it enough to know that it was open sourced. Interesting...

But MegaSquirt hasn't been maintained well if it is open source. It doesn't have SEFI does it? I'm curious if they've maintained the code to support VVT, coil-on-plug ignition, and all the latest technologies.
Just to confirm, a quick look at their main page shows they DO have sequential inj. and coil on plug options in latest version. Neat....

Not quite sure about code format of latest version, but M. II has source code in c and downloadable, and it uses a decent microprocessor too.
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

99gmq
Gear Head
Posts: 16
Joined: Thu Apr 19, 2012 11:20 pm
Location: Central VA, USA

Re: Developing a disassembler. Send me your binaries to test

Post by 99gmq » Sat Apr 28, 2012 3:15 pm

Megasquirt is an excellent option for a racecar. If I had an EEC4 car and really just wanted to control the engine, it would probably be my first choice. I have a '92 Toyota that I'll probably drop a megasquirt into at some point for just that reason. Megasquirt is comparatively simple, platform-agnostic, and is really quite well supported. It's also a lot cheaper to do a megasquirt than buy a QH, the software you need, and maybe some template files too.

OTOH, my Ford product is an EEC5 street car with lots of integration - the EEC controls the transmission, the air conditioner, the power steering, the cooling fans - lots of stuff on this car. A single megasquirt simply can't do all that, at least not well. I've seen mention of people using a second megasquirt to control the transmission. That looks like a lot of work when I am mostly happy with the stock strategy and really just want the ability to dial the tune around to cope with the relatively mild mods I've done.

So I'll hack the EEC on the Grand Marquis, and I'll replace the ECU entirely on the Toyota with a megasquirt II. In both cases, this is the lower-stress approach to get where I want to go.
1999 Mercury Grand Marquis LS HPP with mild mods

decipha

Re: Please send me your binaries !!

Post by decipha » Tue May 01, 2012 1:38 am

if i know the strategy i could see if someone has done it already

its from a 92 f150, its not a 400 though, only 6, that makes her a 300 :)


i know how much work it is to make a def file, its more so that i don't have the patience to do it just to end up with the working of one strategy in which i can't completely change and then as soon as i move on to another vehicle i have to start all over at 0, not fun in my book, much props to all who do it on a daily basis, me, myself, i cant devote that much time knowing the end result i can't claim as my own, i'd rather just start from scratch and make my own altogether, in which im doing and im taking it above and beyond as i already have it tuning itself, im perfectly fine being the only one driving it, thats not a problem as im doing it more so for fun but mainly because i want an engine management computer to do exactly what i want and there is none in existence that can do exactly what i want except my own which im currently working on :)

to be completely honest its actually really simple, theres nothing hard about it at all, just time consuming, when you get down to it, its only math and variables, i'd rather write assembly and get frustrated knowing that im actually creating something thats my own. Not to mention the learning experience, i've learned more from writing my own program than i ever have from reprogramming the already written ecu's, i realized why a bunch of scalars exist that i thought were pretty much useless or stupid. Like the half number of cylinders scalar for example, prior to me writing my own code it didn't make sense to me, why couldn't the ecu just divide the num cylinder by 2 and be done with it? well when i was writing my pulsewidth algorithm i understood why, it was only logical to have a scalar to reference instead of diving by 2 each time it calculated injection, or why they have wot rpm shift scalars when the ecu has shift schedule functions which is due to sections of the transmission strategy being skipped at WOT, and why they have max speed in gear scalars for when the ecu powers up and the vehicle is moving so it won't shift into 1st in case you have a momentary power failure while cruising on the interstate, stupid things like that which aren't so stupid anymore when you realize why they are there, and what better way to figure it out than having to cross the same bridge

again, im not trying to take away anything from the folks that disassemble, i have a great respect for you all, derek, fraser, paton, etc.. but i personally perfer to just continue making my own as i know exactly what its doing how, when, where, and why i want it to

mpaton
BIN Hacker
Posts: 370
Joined: Mon Jun 23, 2008 1:39 pm

Re: Please send me your binaries !!

Post by mpaton » Thu May 03, 2012 6:12 pm

decipha wrote:if i know the strategy i could see if someone has done it already

its from a 92 f150, its not a 400 though, only 6, that makes her a 300 :)
And I finally worked out how I got that wrong; Forgetting that SARCH was a per cylinder value and not looking up NUMCYL. :oops:

I don't want to stop you doing this giant rewrite, but I do believe that if you were to completely disassemble an existing bin, AND understand everything it's doing, and why it does it, then you would have learned a lot of good stuff, and be much better prepared to write your own.

But go for it.

teal95
Regular
Posts: 98
Joined: Fri Oct 18, 2002 2:46 pm
Location: Walkerton, IN

Re: Developing a disassembler. Send me your binaries to test

Post by teal95 » Mon May 21, 2012 10:39 am

What binary vintage would you like? I have several from the early 2.3t engines (TA, P series and L series) and range up to the last of the 5.0 in the Explorer with a few 4.6 EECs in the mix (for coil on plug). The TA would be very basic ('83 & '84) the P are the next gen (late '84 through '89) and the L were '87/8 only all for 2.3t. Then I go into 5.0 stuff (A9P, T4M0 etc). I also have a handful of early '90s Escort 1.9 EECs (these would also be OBD-I).

You almost have to have separate versions for the different vintages. The early EEC-IV (through A9*) do calls differently from the OBD-I EECs and then EEC-V is another animal.

steve
'95 GT - T4M0 x3
'93 notch - A9P
'87 TC - 8UA or LB2 or LA3 x2
'85.5 & '86 SVO - PE x2
'83 & '84 GT turbo - TA x2

tvrfan
Tuning Addict
Posts: 368
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Developing a disassembler. Send me your binaries to test

Post by tvrfan » Mon May 21, 2012 4:11 pm

teal95 wrote:What binary vintage would you like? steve
Thanks Steve, I have a few A9L types, and some 2.3T (PE etc) and some early European ones (2.0 and 2.8/2.9 Granada).

I would be interested in the 1.9 Escorts and the very early US types (to see if they are similar to European ones) , I don't think I've got any of those family types.

I have only one version of the disassembler code, which can handle right through from my very early 'AA' (Granada 2.8 1985) through to A9L , but A9L and similar need a few directives to keep it on track.

The feedback has been great, and I've been quiet because I've found a few bugs to fix with the binaries sent, which is always a good thing, but progress has slowed with a couple of tricky 'catch 22' type issues..... I'll sort it out though !!
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests