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

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

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

Post by tvrfan » Sun Feb 23, 2014 3:54 am

You mean like the tweecer def files ?

I guess I could look at using the data in there to help identify names, funcs,tables etc in a binary.
Not a bad idea to add a tool to use that format - I do have a sort of test convertor I made in a few minutes a long time ago for the A9L. Perhaps I should make that into a proper add-on... hmmm.... I think I kept it in my backup....er... somewhere...
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

XantheFIN
Gear Head
Posts: 56
Joined: Mon Mar 24, 2014 5:13 pm
Location: Finland

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

Post by XantheFIN » Mon Mar 24, 2014 5:28 pm

Well... i have looked this thread for while and now i registered because i bought today license for Hex Workshop to continue building definition file for my Escort. :mrgreen:


I got bin for my ENVY. Then i did bought one gearbox and got two EEC-IV ecus with it. One Mondeo (ACHE/with PATS and EDIS inside ECU) and one for Sierra but i am just sucking bins via DLC so i can't yet suck other one.
Attachments
ENVY.BIN
Pure Full *.bin
(Zetec - EDIS4 chip inside ECU)
(64 KiB) Downloaded 482 times
ACHE.bin
(56 KiB) Downloaded 493 times
Last edited by XantheFIN on Wed May 21, 2014 3:33 am, edited 1 time in total.
European Zetec - GSAZ1 - ENVY

*ForDiag
*Homebrew - J3 Adapter w/ TunerPRO RT
*Innovate LC-2 WB

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

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

Post by cgrey8 » Mon Mar 31, 2014 10:15 am

tvrfan,
I don't know a lot about the disassembler you have worked on, but I have a question about it's ability. I want to add some hack code to a GUFB tune. This code requires some RAM, but I don't know exactly what RAM offsets are used and which ones aren't. Is there any way your disassembler can be outfitted with the ability to give a RAM usage report?

For instance, what I'd like to give the disassembler is a bin and the start&end address range of RAM, then have it analyze every read/write made to that address range and spit out a report of which memory offsets within that range are referenced and by what area of the bin. More important to my intentions, I want to know which memory addresses within the range are NOT referenced (i.e. available for use).

Is there any chance this is possible with your disassembler or is that a massive amount of work that it just wasn't written to be able to do?
...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

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

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

Post by tvrfan » Sat Apr 05, 2014 4:36 pm

The quick answer to that question is "..partly.."

The disassembler does a STATIC analysis, but does not do a full emulation of the code. So any RAM address which is embedded directly in the code will be captured (including psuedo RAM addresses for those extra comms chips) . However there are also a lot of data structures, like tables, functions, timer arrays, and so on, and only the start address of each of those structures are embedded.

The disassembler makes an estimate of size for tables and functions, as they are of a consistent structure, or have extra size parameters available, but for others (e.g. timer arrays, injection control) there is no way to guess how big they are.

GUFB (A9L etc) generation and onwards typically use a set of indirect pointers for most (all?) of their data structures, which seems to be for the purpose that a cal console can replace those pointers to replace a block of lookup data easily. That's my guess why, anyway....

Therefore most (all?) of the true calibration data is within the range given by those indirect pointers at the front (the approx 2020 to 2030 ones).
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

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

Post by cgrey8 » Sat Apr 05, 2014 7:01 pm

So, how would I go about getting a list of which bytes within an A9L are definitely used? Between the def file's datalogging tab and the disassembler, I'd like to think I could eliminate most of the addresses. The ones that are left, I could add to a def file, datalog them, and look for usage while I drive. If I ever see them changing, then I know they are also being used by something. Now I know this isn't a bullet-proof way of figuring this out. Obviously there could be some test code or some other mostly-inactive code that uses a section of memory at a time I was never datalogging for, but that's fine. If the memory is rarely used, then my using those areas should work most of the time. If it quits working because of fundamental changes I make in the tune, I'll notice that the memory locations I'm using (and datalogging) are suddenly jumping to values that don't make sense. And I'll go back to looking for more available memory locations. I'd like to have 6-8 available bytes. But if I had to, 2 bytes might be 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

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

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

Post by tvrfan » Sun Apr 06, 2014 6:52 pm

Hmmm.... There's no easy way to be absolutely certain.

[NB. I only mentioned RAM above, the same goes for ROM addresses - the cal pointers (2020 on) go to ROM of course, not RAM]

Even an emulation would need to go through all possible code paths, which means all possible input combinations and circumstances, and it's well known that testing of software NEVER achieves this, even when source code available.

I can add a separate list of addresses from disassembler which are definitely (and directly) accessed.
This is already there for ROM as the directives output in the messages file, where it prints out the commands which it worked out automatically e.g.

Code: Select all

byte    9000  9000 
word    9002  9003 
word    9006  9009 
byte    900a  900c 
word    900e  900f 
byte    9010  9015 
word    9016  903b 
byte    903c  903c 
word    903e  9041 
byte    9042  9049 
word    904a  9065 
byte    9066  9067 
table   9069  90b8  :Y O +10 
func    90b9  90c4  :Y  :Y 
func    90c6  90e1  :W  :W 
func    90e2  9101  :W  :W 
table   9102  9147  :Y O +10 
func    9148  915f  :W  :W 
table   9160  91af  :Y O +10 
byte    91b9  91b9 
func    91c1  91ca  :Y  :Y 
table   91cb  9202  :Y O +8 
func    9204  922b  :W  :W 
anything which is not 'code' is data.

Unused RAM/register addresses ....

Lower RAM addresses are often used as byte, word and even longs in various calcs, so this would take some thought.
Perhaps a way is that disassembler adds auto symbol names for plain numbers in the same way it does for subroutines, tables, etc.

** Thinking **
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

ender11
Gear Head
Posts: 58
Joined: Fri Jan 06, 2012 10:14 am
Location: Krasnoyarsk, Russia

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

Post by ender11 » Wed Apr 16, 2014 11:03 am

well, is it possible to define table lookup subroutine by hand? alas every .bin I'm interested in is not recognized.
upd: oh, well, it's possible :)
Attachments
C3P2.bin
(56 KiB) Downloaded 483 times

XantheFIN
Gear Head
Posts: 56
Joined: Mon Mar 24, 2014 5:13 pm
Location: Finland

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

Post by XantheFIN » Tue May 20, 2014 12:33 pm

Couple more bins if interested. Found around internet and last one on the list i killed by accident via J3 port.
Attachments
0FAB.BIN
Ford Fiesta RS Turbo
(56 KiB) Downloaded 455 times
1AGB.BIN
Ford Escort RS2000 (-- model did not have DLC)
(56 KiB) Downloaded 478 times
3AAB.BIN
Ford Escort Zetec (Same than ENVY which i did post earlier but this has not yet EDIS4 chip inside ECU)
(64 KiB) Downloaded 464 times
European Zetec - GSAZ1 - ENVY

*ForDiag
*Homebrew - J3 Adapter w/ TunerPRO RT
*Innovate LC-2 WB

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

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

Post by tvrfan » Tue May 20, 2014 7:14 pm

Thanks, haven't seen the 3AAB before...

Yes, you should be able to set all the data structures by manual commands (as per the instructions with SAD), including things like a scale factor if you wish, so that the values represent realworld numbers (like ignition timing on all the binaries so far seem to be times 4, giving a 1/4 degree resolution.)

Even mixed strctures can be defined (the A9L has some which have subroutine call addresses, word addresses, masks, and byte values)

Also if there are parts which seem to be code but missed off, add a SCAN instruction so that SAD will look at it.

Despite my best efforts, and version I'm working on now, there are still some things which don't work automatically, and some things which get interpreted as the wrong thing. There are some clever shortcuts in the different binaries, which I can appreciate as an IT developer, but are *VERY* hard to decode with another program !

Also some of the subroutine calls with embedded parameters can be a real b-st-rd to decode correctly. (you can tell these because they fiddle with the call stack).
If you get invalid opcodes close to (just after) a subroutine call, chances are it has embedded parameters. You can define these subroutines manually as well.

At least I got the multibanks to work (mostly), but they have a new set of tricks and shortcuts to sort out, so other things to get wrong.

I have been wondering whether mpaton and others were right after all. Their view was that I should emulate the code to get the trickier bits analysed - I am currently trying out a few different ideas on this theme.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

XantheFIN
Gear Head
Posts: 56
Joined: Mon Mar 24, 2014 5:13 pm
Location: Finland

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

Post by XantheFIN » Wed May 21, 2014 3:57 am

I updated ENVY.BIN on my previous post with full *.bin if that makes different.


3AAB - GSAZ1M4 - 93AB-12A650-AB - SMO-270 (EDIS4 outside ecu as own module)
ENVY - GSAZ1GD - 94AB-12A650-EB - SME-105 (EDIS4 inside ecu)

For SMO-270 some Russian made schematics here.


Nice to hear progress tvrfan!


P.S. I have year 98 Mondeo / zetec EEC-V *.bin and it's full size is 64K. But i think its not needed here.
Last edited by XantheFIN on Thu May 29, 2014 4:30 am, edited 1 time in total.
European Zetec - GSAZ1 - ENVY

*ForDiag
*Homebrew - J3 Adapter w/ TunerPRO RT
*Innovate LC-2 WB

harold
Gear Head
Posts: 56
Joined: Sat Mar 30, 2013 3:58 pm

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

Post by harold » Thu May 22, 2014 7:46 am

Here's an LFQ1 from a Ford Focus, KRAF5 strategy. As far as I know, there's a single incomplete TunerPro definition floating around out there.
Attachments
LFQ1 02 Zetec focus (KRAF5 strategy).bin
(256 KiB) Downloaded 487 times
Last edited by harold on Fri May 30, 2014 11:48 pm, edited 1 time in total.
Porsche 944
Stock 302 with a GT40 lower and custom upper, Ford slot MAF, custom headers

ollopa
Gear Head
Posts: 37
Joined: Tue May 18, 2010 2:02 am

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

Post by ollopa » Fri May 30, 2014 11:43 pm

cgrey8 wrote:This code requires some RAM, but I don't know exactly what RAM offsets are used and which ones aren't.
I've done NO hacking on EEC firmware but plenty of debugging on various embedded architectures. A common trick to find buffer overflows is to initialize all of RAM to some non-zero value like 0xFF or 0xA5, run your program for a while, then break it and dump RAM to see which values have been touched. Any way you could apply that technique?

Does the QH have the capability of dumping RAM similar to the way it can dump the ROM or is it only able to return a limited subset via datalogging?
1994 Mustang GT, 351w (377 stroker), TFS heads, hydraulic roller lifters, 1.7 roller rockers, explorer intake, T4M0, Quarterhorse, SLC-DIY wideband AFR meter

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

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

Post by cgrey8 » Sat May 31, 2014 6:14 am

There probably is a way to do that. It'd likely require loading up 2 programs. 1 would clear the RAM and that's all that program would do is initialize the RAM to some value. Then the other is the tune to control the engine.

To get a clear picture of what RAM isn't being used, I'd likely need to run the tune for multiple stop/starts, get a dump of RAM. The reinitialize the RAM to some other value. Then do it all again. And compare the two dumps. This would help eliminate finding addresses that just happened to be the same value as what you set them to, but were actually used bytes.
...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

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

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

Post by tvrfan » Sat May 31, 2014 4:34 pm

That's a good generic solution, I agree.

I do know, however, that most (all?) EEC programs initialise their RAM to defined values or zeroes, as part of their initialisation routine - this is also where they check the KAM, if they have one, and init. that too if necessary. So you can probably get the RAM limits from that first routine. I can see though that this might not give all the RAM, depending upon how its used.

SAD disassembler tracks all data accesses, read and write, RAM and ROM, and then attempts to find any tables or functions as part of that process. This is done as a static analysis of the code itself, not by using a simulator. Just saying this to show there's several ways to do this kind of thing.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

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

Post by cgrey8 » Sat May 31, 2014 8:44 pm

So the disassembler can determine which memory addresses are read/written? If so, is there a way to tap into that and get a "report" of only the addresses that are written to? Since ROM isn't writable, it's a safe assumption that only RAM would have writes. If the disassembler can identify all addresses that are written to by the BIN AND identify whether they are written to as BYTES or WORDS (2-bytes), those addresses can be put in numerical order to determine where "available" memory locations are which would help me in my quest to find an available byte or two in GUFx to use for a hack I want to implement.
...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

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

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

Post by tvrfan » Sun Jun 01, 2014 5:55 am

cgrey8 wrote:So the disassembler can determine which memory addresses are read/written? If so, is there a way to tap into that and get a "report" of only the addresses that are written to?
YES, subject to some limits.

1. For ROM data structures like tables it only gets the start address for certain - the rest is estimated (SAD does get this right most of the time).
2. It won't get addresses for any code blocks that it misses, or messes up. (which is what I'm trying to improve at the moment).
3. For some code loops, it won't get the whole list of addresses, because it won't simulate loops (similar to 1)
4. At the moment, I don't bother with autodetect of addresses in RAM (ie. < 0x2000) , only ROM, for the fixed data structures.
Could change that though.... I guess I could look at autonames for reads/writes between 0x100 and 0x1ffff.

GUFB is A9L family yes ?/ I've got quite some data on the A9L bin if it's any help - I'll see if there are any obvious unused bytes...
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

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

Post by cgrey8 » Sun Jun 01, 2014 6:19 am

More interestingly, how does the EEC use RAM? If EEC code only uses RAM in 1-2byte increments, then what the disassembler gets should be fairly accurate. However my guess is the KAM area of RAM used for adaptive learning IS used as a table and thus would likely be subject to the disassembler not finding all addresses used for KAM. However I would assume that most all things that use large chunks of RAM are fairly well understood how much memory they take. So compensating for them shouldn't be too big of a deal.

Also worth note, you said there's a routine that clears RAM. However there have to be some limits on that code so it doesn't go clearing the area of RAM used for KAM. That would kind of defeat the purpose of KAM if every time the BIN started up, it cleared that area too. Although not to complicate things further, it would be interesting to differentiate which available bytes in RAM are in KAM and which ones aren't. That might be useful info as well.
...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

ranga83
Gear Head
Posts: 53
Joined: Thu Jan 03, 2013 8:33 am

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

Post by ranga83 » Sun Jun 01, 2014 6:25 am

ive noticed with the 2 bank eecv 4TAD.bin that the SAD doesn't find the tables that have already been defined. ie. the fuel startup table @ location C554. would this be because it is skipping code at the start? or does SAD have an issue with the 2 bank eecv's?

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

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

Post by tvrfan » Sun Jun 01, 2014 11:33 pm

ranga83 wrote:ive noticed with the 2 bank eecv 4TAD.bin that the SAD doesn't find the tables that have already been defined. ie. the fuel startup table @ location C554. would this be because it is skipping code at the start? or does SAD have an issue with the 2 bank eecv's?
Sometimes SAD doesn't recognise the routine which does the table and function accesses, or it misses a chunk of code which calls that routine for a table - these are the kind of things I am trying to sort out for next release. Some of the subroutines which have embedded parameters are difficult to decipher...
This applies to all bins, but the later multibanks have some clever code tricks that have so far resisted my attempts to crack them, so they are, unfortunately, more likely to have bits missed.

Cgrey - the A9L has RAM at 0x100-4ff and KAM at 0x700-7ff so distinct and separate ranges - possibly different memory IC/chips ?
Looking again - seems like A9L has a preset list of RAM addresses and values, so may not do a simple clear....
Yes there are a few RAM based tables to deal with..
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

ranga83
Gear Head
Posts: 53
Joined: Thu Jan 03, 2013 8:33 am

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

Post by ranga83 » Mon Jun 02, 2014 2:46 am

tvrfan wrote: Sometimes SAD doesn't recognise the routine which does the table and function accesses, or it misses a chunk of code which calls that routine for a table - these are the kind of things I am trying to sort out for next release. Some of the subroutines which have embedded parameters are difficult to decipher...
This applies to all bins, but the later multibanks have some clever code tricks that have so far resisted my attempts to crack them, so they are, unfortunately, more likely to have bits missed.
so the tables it did find ARE actually tables the eec uses? if so then that's great because those addresses haven't been defined yet.

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

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

Post by tvrfan » Tue Jun 03, 2014 2:17 pm

ranga83 wrote:
tvrfan wrote: Sometimes SAD doesn't recognise the routine which does the table and function accesses, or it misses a chunk of code which calls that routine for a table - these are the kind of things I am trying to sort out for next release. Some of the subroutines which have embedded parameters are difficult to decipher...
This applies to all bins, but the later multibanks have some clever code tricks that have so far resisted my attempts to crack them, so they are, unfortunately, more likely to have bits missed.
so the tables it did find ARE actually tables the eec uses? if so then that's great because those addresses haven't been defined yet.
Yes, should be. SAD looks for the subroutines which are used to read tables, and functions. I did this because the code used is exactly the same (almost) over all the bins. [ Once you have a good fast solution, why change it ? ] . From these subroutines, SAD then logs any addresses fed in to those subrotuines and analyses them to see if they are a table or function. It's possible, but not likely, that it may get one wrong, but it should be obvious from the data. (for clarification - tables are 2D , two lookup variables, functions are 1D, one lookup variable)
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

ranga83
Gear Head
Posts: 53
Joined: Thu Jan 03, 2013 8:33 am

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

Post by ranga83 » Tue Jun 03, 2014 5:10 pm

excellent. I put the tables found into the tunerpro xdf last night, so far I have figured out 2 tables are the trans line pressures. now to work out the rest of them and their conversions.
SAD must have missed some code at the start because there are about 8 tables it didnt find, but they are already defined.

decipha

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

Post by decipha » Tue Jun 10, 2014 5:04 pm

It would be titties if SAD spat out a comma delimited def file that can be opened up directly with BE

if your interested Andy, contact me for specifics

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

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

Post by tvrfan » Wed Jun 11, 2014 12:34 am

decipha wrote:It would be titties if SAD spat out a comma delimited def file that can be opened up directly with BE
if your interested Andy, contact me for specifics
I did write a little test tool to go the other way, to convert those .xdf files into SAD commands, as a test.

If you want to send me an example file, for the format, and what the numbers etc are, then I could look at that.

At the moment, still trying to improve SAD's recognition of data, tables, funcs, vector lists (list of subroutines called), and so on, and making slow but steady progress, so might be a while, but Im still interested if it helps everyone.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

galapogos01
Gear Head
Posts: 1
Joined: Sat Jan 09, 2010 7:44 pm

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

Post by galapogos01 » Wed Jun 11, 2014 12:48 am

If you can share the utility to import an xdf into a SAD file that'd help me greatly! The reverse would also be ideal to stub an xdf with functions/tables/scalars.

Cheers,
Jason

XantheFIN
Gear Head
Posts: 56
Joined: Mon Mar 24, 2014 5:13 pm
Location: Finland

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

Post by XantheFIN » Wed Jun 11, 2014 9:26 am

Oh sorry for that 1AGB.BIN. I think there has been error and it should end at 7FFF so it is (32K).

More uploads..
FALL - another RS2000 - year 90? which i had on my disk.
SEAL - Mondeo - year 96 EEC-IV (Full bin - 64K).
NOAH - Mondeo - year 98 EEC-V (Full bin - 64K).


I have 'EARL' EEC-V ECU (year 95-97? starts with 96AB-) which i got for 10 euros with engine parts but i need first make wiring harness to run on bench. I have too more bins if needed but Later...

I have made (not full) List what here in Europe has


That XDF to SAD sounds great. I have now ~280K XDF file for my GSAZ1 (ENVY, 3AAB, AGED, GURU... which i know uses it). If want something to test.
Attachments
NOAH.BIN
Mondeo - AQAJ0 - EEC-V - Full 64K *.bin
(64 KiB) Downloaded 475 times
SEAL.BIN
Mondeo - GSBA0 - EEC-IV - Full 64K *.bin
(64 KiB) Downloaded 418 times
FALL.BIN
RS2000 - EEC-IV - 32K
(32 KiB) Downloaded 464 times
European Zetec - GSAZ1 - ENVY

*ForDiag
*Homebrew - J3 Adapter w/ TunerPRO RT
*Innovate LC-2 WB

decipha

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

Post by decipha » Thu Jun 12, 2014 10:12 pm

tvrfan wrote:
decipha wrote:It would be titties if SAD spat out a comma delimited def file that can be opened up directly with BE
if your interested Andy, contact me for specifics
I did write a little test tool to go the other way, to convert those .xdf files into SAD commands, as a test.

If you want to send me an example file, for the format, and what the numbers etc are, then I could look at that.

At the moment, still trying to improve SAD's recognition of data, tables, funcs, vector lists (list of subroutines called), and so on, and making slow but steady progress, so might be a while, but Im still interested if it helps everyone.
thats even better, I didnt think of TunerPro defs, that would be most ideal

unrelated, Im working on restructuring my vector listings as well, so I share your pain

vinvin
Gear Head
Posts: 1
Joined: Tue Jul 22, 2014 12:33 pm

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

Post by vinvin » Sun Aug 03, 2014 9:21 am

Hello,
here is the binary of escort 1998 in France, zetec 1.6l 16v eec-iv sme-505 Catch Code: "DARK" downloaded with fordiag.
Fordiag say the SW Version is GSBC1BI, calib. ID: 95E0
I hope it helps..
regards, Vincent.
Attachments
DARK.BIN
(64 KiB) Downloaded 440 times

BillMarkViii
BIN Hacker
Posts: 15
Joined: Fri Jun 19, 2009 5:10 pm

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

Post by BillMarkViii » Fri Aug 08, 2014 1:15 pm

What is the current status of this disassembler project?

I have a toolchain that I was using 2 years ago composed of Micheal Paton's disassembler and my modified assembler along with a bunch of helper tools that could produce the same bin output as we started with.

I have done some custom code in the EEC on my cars and am about to rejoin the EEC hacking community after a hiatus.

I'd like to know where everybody has gotten to and how many are writing software, not just tuning cal codes.

Bill

User avatar
tvrfan
Tuning Addict
Posts: 498
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 Aug 11, 2014 5:05 pm

Disassembler -

I feel like I'm going backwards at the moment.....

Originally I designed the code to recurse down the subroutines, so it could handle binaries with subroutine arguments, especially as some subrs get params on behalf of their calling subr (e.g A9L). The other jumps are done like a tree structure.

The A9L code looks hacked after compilation to me, as it has fixed jumps to subroutines with arguments - not something a compiler would do, I reckon. Anyway, managed to deal with that one, but it still doesn't unscramble the A9L's data structures as much as I would like. I added multibank stuff, which works reasonably well, but doesn't handle calls via altstack automatically (BWAK32 etc).

That's where the last released SAD version was up to.

Then I tried testing the EARS binary, and spotted the variable arg subroutines, and a subr which jumps into the middle of another subr
depending upon the carry bit to get different number of args. [Much Cursing deleted!] I then spotted this and other related tricks in other bins. I realised the recursive mechanism would not work for these 'variable arg' bins.
I have now changed SAD to a 'linked chunk' type setup so it can handle jumps across subrs, but I'm not sure it's right (yet). I'm still testing this.
it was a BIG change to base level, and it's taken a lot longer than I thought.

I did spot a few bugs on the way, and I have (hopefully) speeded up the analysis, as I reckon I'm going to need to do more passes with the linked chunks, and to solve the more advanced data structures.

That last released version should handle every binary, but does need user directives to do so, which is not what I wanted.

I wonder if MPaton was right about doing some of this stuff as a simulation after all !

So progress is slow, but I am back to testing with A9L and EARS right now....
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

Post Reply