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

User avatar
cgrey8
Administrator
Posts: 10565
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 » Thu Feb 21, 2013 9:30 am

But once someone has done that, it sure would be nice if they released that to the open community to make it easier for someone else to make a similar directive file for a similar strategy. I understand if there are those that choose not to. But I also have to believe there are some people that wouldn't mind releasing that amount of info particularly since having a directive alone doesn't even get you CLOSE to a def file. It gets you maybe 10% of the way. And that assumes you are using the exact strategy the def file was intended for. If the def file is being used as a basis for a similar strat, it's probably less than that. But it at least would give some insight to people unfamiliar with disassembly as to common places the disassembler needs help, and what that help looks like in a directive form. If the example strategy directive file and the uncharted strategy being looked at are similar, the directives described in the sample may not be that far away in the uncharted strategy.
...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

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 Feb 22, 2013 8:25 pm

Here are a pair of ROM dumps, both the main 4 bank software plus the flash programming 'hidden' bank.
Attachments
BWAK3N2-Original.zip
BWAK3 in 256k 00118899 bank order
(142.22 KiB) Downloaded 310 times
BWAK3_flash_bank.zip
Flashing bank from BWAK3
(12.41 KiB) Downloaded 341 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 Feb 22, 2013 8:32 pm

And for some fun and to compare your output with another disassembler here is a directives file and a disassembler listing for the BWAK3N2 binary
Attachments
BWAK3N2.lst-def-02-21-13.zip
BWAK3N2 listing ( disassembler output ) plus a definitions file for it
02-21-2013
(929.08 KiB) Downloaded 326 times

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 » Sun Apr 14, 2013 4:34 pm

NEW VERSION as requested in another thread.

Main changes made to previous version of SAD.
Filenames changed so that they open immediately in Wordpad or Notepad via Windows.

Code: Select all


- read only -
xxx.bin		binary file		(unchanged)
xxx_dir.txt 	directives file	(changed from xxx.dir)
xxx_cmt.txt		comments file 	(changed from xxx.cmt)

- written to -
xxx_lst.txt		output file		(unchanged)
xxx_msg.txt       information       (unchanged - info,messages,errors from disassembly process)



Main menu 'properties' option added, which gives a quick summary of the binary file
and its calculated address map (banks and file offsets) without a full disassembly.
Useful to check if file is accepted as a valid EEC binary.

A lot of internal code changed to make the disassembly run a lot faster, especially with lots of symbol names.

Different read and write names/symbols supported for standard CPU locations (not implemented in directives yet). More names for std locations added for 8065 CPUs.

Proper decoding of the 'ALT' range of instructions for 8065 (the 0xfe prefix), but NO tracking of the ALTSTACK yet, which means some stuff may not work automatically.
Main example spotted so far is some binaries use ALTSTACK to run their background task list.

Output file shows bank number before address for multibank binaries.

Partial support for automatic detection of Timer lists and subroutine. Only works for single bank binaries at the moment, and even then not always - still under development.

Should be better at spotting signed/unsigned combinations of functions and tables, still being tested.

Minor changes made to directives, but should be backwards compatible.

Included documentation as a .pdf - it's neat that Openoffice can do that !!
Attachments
sad.zip
(329.72 KiB) Downloaded 389 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: Developing a disassembler. Send me your binaries to test

Post by tvrfan » Fri Dec 06, 2013 2:03 pm

Following a request, here is the latest released version of SAD, which got lost after the restore.

This one should do multibanks, but still doesn't handle everything quite right, but with some extra directives as per instructions, should be able to decode all binaries. Have included instructions again.

This version is dated 10 June 2013. Standard zipped format.
Attachments
SAD.pdf
instructions
(138.35 KiB) Downloaded 884 times
sad.zip
program file (zipped)
(200.06 KiB) Downloaded 376 times
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

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

drapieznik
Gear Head
Posts: 1
Joined: Wed Feb 15, 2012 4:28 am
Location: L'viv, Ukraine

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

Post by drapieznik » Sat Dec 07, 2013 9:22 am

tvrfan wrote:Following a request...
Thanks!

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 Dec 23, 2013 2:24 pm

A quick update....

As you can see that last released version of SAD was not quite 6 months ago.
I haven't stopped trying to improve things, but have hit a 'catch 22' with the way I designed the original code.

Early EEC binaries are very simple, with all subroutine parameters being passed by registers. Then came the A9L family types, which use parameters on the stack, and also have subroutines which get data on behalf of a 'parent' subroutine, which took quite a bit of unpicking, but I got that to work.

Now I have a problem with the generation after that, many of which are 4 letter ids (like LAWN, ANTI, EARS, RUTH and so on), because they have subroutines which have VARIABLE numbers of parameters, some using the carry flag, some with number of arguments stored in a register, so params can be different for each call. These subroutines also appear in the multibank 8065 code as well, with extra BANK instructions built in. The extra difficulty with some of these is that these subroutines jump into the middle of another routine, so their stack fiddling is split over a jump, which I didn't allow for.

I have been trying to keep the original code structure the same as I know it works well, but each attempt to solve the "split jump" trick hits a similar problem. I'm up to about try number eight so far . So now I realise I need to take a deep breath and rewrite part of the base program, to allow some new methods of analysis to get this code recognised correctly.

From a more geek perspective, I can see how Ford (and Intel ?) seem to have developed better compilers for each generation, this made their code more complex to analyse, but more efficient and probably quicker for development.

So in the words of a certain famous character ..... "I'll be back"...... but it may be 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: Developing a disassembler. Send me your binaries to test

Post by tvrfan » Mon Dec 23, 2013 2:34 pm

OH, forgot to add, the current SAD release will handle these subroutines, but not automatically, it needs directives to tell it what to do.
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

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

jsa
Tuning Addict
Posts: 519
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

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

Post by jsa » Mon Dec 23, 2013 6:42 pm

Thanks for the update & continued effort.
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

User avatar
cgrey8
Administrator
Posts: 10565
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 Dec 23, 2013 6:52 pm

...and thanks for the technical explanations. I wasn't aware of the technical nuances of the newer stuff to realize that arguments are variable length and that they can do sophisticated stuff like jump around between subroutines. I don't know if this is assembler "optimization" doing this or if this was just Ford's spaghetti code coding practice that resulted in that kind of behavior. But I can certainly see why deciphering it would be more difficult, and then add there's banks of memory AND more code & functionality to have to swim through.

Please don't hesitate to elaborate more on these coding practices as you find them or think of them. If I ever do get back to trying to read assembly, knowing these details and as much info about them would be quite helpful (i.e. if specific registers are always the argument-call register or all arguments of variable length calls are the same size/datatype, etc).
...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: Developing a disassembler. Send me your binaries to test

Post by tvrfan » Mon Dec 23, 2013 8:56 pm

No worries - if you are interested, I can post a couple of code examples of what I'm talking about. Just ask. Always happy to explain code so that it helps as many people as possible, and hey, chances are someone will find a mistake, which is always useful.

A long time ago, on proprietary operating systems in UK, I did a bit of work on compiler and code optimisation. The types of code tricks I can see in the EEC code might be Ford spaghetti, but might also be the results of an 'advanced' compiler, which itself might have some spaghetti/patched code in it !!

I was splitting up code by tracking jumps, and ending a 'block' at a jump, or subr call, or a return. I had to modify that for A9L a bit, but now I'll have to find a better way, as I need to be able to follow a jump/call as if it was part of the same code block under defined conditions, but also be able to treat it as an "end" for other conditions. It's mainly getting the new logic straight and making sure it's sound, and then the actual coding....

(Oh, yeah, and some of the parameters in the A9L and later subroutines are also ENCODED in various ways, making the correct decoding just that little extra tough...thanks Ford !)
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: Developing a disassembler. Send me your binaries to test

Post by cgrey8 » Tue Dec 24, 2013 5:26 am

Feel free to post code examples of commonly done routines.

I'm somewhat familiar with the loading of registers with calls in preparation for a function call or a table call. That's pretty standard fare for any programming in assembly.

And I'm familiar with the stack manipulation where a disassembler would assume that return positions on the stack are actual return positions, but are being used as pointers to data and the code is responsible for popping those values off, using them, and re-pushing the correct return position to the stack so the RETURN at the end of the subroutine actually returns where it is supposed to.

The above technique, I believe, may be used for more than 1 piece of data. The code just has to know that and of course the BIN has to be setup with this expectation...lots of coordinated behavior which is odd because the whole purpose of subroutines is to isolate behavior, at least in normal code patterns.

That's about the extent of my familiarity with the oddities of Ford code. And it sounds like there is a good bit more.
...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: Developing a disassembler. Send me your binaries to test

Post by tvrfan » Tue Dec 24, 2013 2:46 pm

OK - here's a couple of things to chew on....

Here is an example of a variable argument/parameter subroutine - these from ANTI

R38 is used as a loop count via DJNZ, and times 2 (two extracts from stack via R3a for each loop). Sub204 appears to be some kind of init routine (could be something else, only done a quick scan)

Code: Select all


40df: cc,3a             pop   R3a            R3a = pop();
40e1: 71,fd,2c          an2b  R2c,fd         R2c &= fd;
40e4: ae,3b,14          ldzbw R14,[R3a++]    R14 = (uns)[R3a++];
40e7: b2,3b,17          ldb   R17,[R3a++]    R17 = [R3a++];
40ea: e0,39,03          djnz  R39,40f0       R39--;
                                             if (R39 !=  0) goto 40f0;
40ed: 91,02,2c          orb   R2c,2          R2c |= 2; }
40f0: 28,10             scall 4102           Sub204();
40f2: e0,38,ef          djnz  R38,40e4       R38--;
                                             if (R38 !=  0) goto 40e4;
40f5: c8,3a             push  R3a            push(R3a);
40f7: f0                ret                  return;

Continuing on from that code, you can see that the code at 4102 can also be called with just 2 parameters in a more 'classic' manner, so already we have two 'prefixes' for the same code

Code: Select all


  Sub166:
40f8: cc,18             pop   R18            R18 = pop();
40fa: ae,19,14          ldzbw R14,[R18++]    R14 = (uns)[R18++];
40fd: b2,19,17          ldb   R17,[R18++]    R17 = [R18++];
4100: c8,18             push  R18            push(R18);
  Sub204:
4102: 3f,17,11          jb    B7,R17,4116    if (!B7_R17)  {
4105: ac,17,34          ldzbw R34,R17        R34 = (uns)R17;
4108: 41,07,00,34,1a    an3w  R1a,R34,7      R1a = R34 & 7;
410d: ad,01,16          ldzbw R16,1          R16 = (uns)1;
4110: 19,1a,1            ...

and last, here is a subroutine using carry flag to change number of arguments from 4 to 6, by pushing a new address onto the stack for the RET instruction. It doesn't even JUMP !! (and I haven't checked what sub174 does yet, so could be even more stack fiddling in there)

Code: Select all


  Sub199:
4456: f8                clc                  CY = 0;
4457: 20,01             sjmp  445a           goto 445a;

  Sub189:
4459: f9                stc                  CY = 1;
445a: cc,18             pop   R18            R18 = pop();
445c: b2,19,1a          ldb   R1a,[R18++]    R1a = [R18++];
445f: b2,19,1b          ldb   R1b,[R18++]    R1b = [R18++];
4462: b2,19,1c          ldb   R1c,[R18++]    R1c = [R18++];
4465: b2,19,1d          ldb   R1d,[R18++]    R1d = [R18++];
4468: d3,05             jnc   446f           if (CY == 1)  {
446a: c9,fa,40          push  40fa           push(40fa);
446d: 20,02             sjmp  4471           goto 4471; }

446f: c8,18             push  R18            push(R18);
4471: 91,02,2c          orb   R2c,2          R2c |= 2;
4474: ad,1a,3e          ldzbw R3e,1a         R3e = (uns)1a;
4477: 28,26             scall 449f           Sub174();
4479: ad,1c,3e          ldzbw R3e,1c         R3e = (uns)1c;
447c: 28,21             scall 449f           Sub174();
447e: a2,1a,42          ldw   R42,[R1a]      R42 = [R1a];
4481: 8a,1c,42          cmpw  R42,[R1c]      
4484: d1,0b             jleu  4491           if ((uns) R42 <= [R1c]) goto 4491;
4486: 39,2c,0b          jb    B1,R2c,4494    if (B1_R2c) return;
4489: a0,1e,1a          ldw   R1a,R1e        R1a = R1e;
448c: 91,02,2c          orb   R2c,2          R2c |= 2;
448f: 22,99             sjmp  472a           goto Sub186;

4491: 71,fd,2c          an2b  R2c,fd         R2c &= fd;
4494: f0                ret                  return;

These are the kinds of tricks which are causing me grief and need a better approach to deciphering automatically
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: Developing a disassembler. Send me your binaries to test

Post by cgrey8 » Tue Dec 24, 2013 7:02 pm

Understanding what the code does is hard enough. It would be nice to understand they why behind they way the code does what it does since it isn't intuitive at all. Some might choose to believe it was purely for obfuscation to slow down people/competitors from accomplishing what you are doing. But then another part of me thinks that might be giving them too much credit. After all, someone bent on deciphering Ford's code, even back then, will do so...as you are doing.

This reminds me of a story a guy at work told me about a previous job he worked at where he had some "horribly" written assembly code that his boss needed him to untangle and make some changes to. After spending a week with it, he was convinced the guy that wrote it was either incompetent or a sadist bent on purposefully obfuscating to stump programmers OR because he though that would give him job security.

So he decided to rewrite it rather than wrap his mind around the code. He got something together that he felt would do the same job but do so in a much more readable and organized form. He went to run it and found that it didn't work. Logically the code was doing what it was supposed to, but the processor was just too slow to meet the timings required for what it was doing. So he went back and analyzed why the old code was working and his wasn't. It was then that he realized why it was written the way it was. The original guy had calculated out the number of processor clock cycles each instruction took, and strategically inserted time-critical code in the middle of unrelated code since the processor was just too slow to service the time-critical stuff using a timer interrupt ...it just had too much interrupt latency.

Upon making this discovery, the guy had a whole new appreciation for the original coder with one exception...the guy should've documented what he was doing better so people coming along behind him didn't have to go through the brain-damage of figuring out they whys associated with his spaghetti code. This is why some argue that comments are almost as valuable, and in some cases, more valuable than the code WHEN the code has to be maintained over many years and by multiple developers. Otherwise the company wastes time and resources reinventing the wheel needlessly.

Now in our case, we don't have original source. We are working with raw binary, converted to assembly. There's no comments to be had. Perhaps if we had the original code (with comments), the why's behind what the code is doing would be far more obvious.
...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: Developing a disassembler. Send me your binaries to test

Post by tvrfan » Tue Dec 24, 2013 9:05 pm

Yeah, heard similar stories too - also remember one with someone saying "hey, why does this code do a LDX and then a SRC, 0 (shift right cyclic of zero) ? SRC, 0 *HAS* to be redundant doesn't it ? Later it was discovered that the SRC was the fastest way to set condition codes on that particular CPU....

For EEC, I don't think FORD deliberately obfuscated the code, but it is very possible they did some nasty shortcuts with GOTO here and there, and then compilers can do some indirect obfuscation by removing redundant and duplicated code. I know that most 'C' compilers will crunch code within switch statements for example. There are a few odd points here and there in the A9L which are never called, which look like they have been jumped over afterwards, but that's just my guess, there may be some other valid reason.

Anyway, I just want to get a method which can decipher those above bits of code correctly to get the right number of arguments......
TVR, Triumph (cars), kit cars, classics. 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 » Thu Jan 09, 2014 2:10 am

are you still after binaries? i have a handful of Australian eecv and eeciv. however i think our eecv is different to the us ones, as ours isnt obd2.

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 » Thu Jan 09, 2014 2:30 pm

Yes. I have a few already, from TI Performance website, but always interested in more !
TVR, Triumph (cars), kit cars, classics. 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 » Fri Jan 10, 2014 2:59 am

ok so i have in the ef falcon 104 pin ecu 94-96, 4TAD, 4TAC, (both ef falcon inline 6 5 speed manual edis 104 pin eecv, but not obd2) 4DBG, 4DCC, (both ef falcon auto), 4DDF, 4DEF (GAS I THINK) 4DKF and 4Teg
also in the EL falcon, distributer ignition, 60 pin ecu yet later than the ef. 96-98. 6DAC (manual), 6DBA, 6DBD, 6DFC, 6DFD, 6DGC, 6DGD, 6DGE, 6DJC, 6DKA, 6DMA, 6TAC, 6TEE, 6TGD, 6TJC.
let me know which ones you want and ill send them through

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 » Mon Jan 13, 2014 10:55 am

when in doubt, send them all.
wat idea I had today -- as far, as functions are recognised, it may be possible to recover some kind of "data flow"? say, perfom an analysis, which functions are took part in given variable?

jsa
Tuning Addict
Posts: 519
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

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

Post by jsa » Wed Jan 15, 2014 3:37 am

tvrfan wrote:OK - here's a couple of things to chew on....
Been prodding at this to see if I could identify what the purpose of that code section was. I'm none the wiser.

Read this recently and thought of what your trying to achieve with the disassembler.
Fourth post down might help.

http://www.eng-tips.com/viewthread.cfm?qid=240973
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

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 Jan 20, 2014 5:20 am

here are some EF ones, ill upload the EL ones later.
4DCC_01.bin
(256 KiB) Downloaded 272 times
4DEF_256K_140710.bin
(256 KiB) Downloaded 267 times
4TAD.bin
(256 KiB) Downloaded 269 times
4DKF_256k.bin
(256 KiB) Downloaded 275 times
4TEG_256_NEW.bin
(256 KiB) Downloaded 275 times
also as i havent taught myself to read code yet, are you able to find the injector timing table from the disassembly?
cheers

Provaider
Gear Head
Posts: 1
Joined: Tue Feb 04, 2014 5:34 pm

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

Post by Provaider » Tue Feb 04, 2014 7:20 pm

Hi

Thx for the good tool! Here is my dump.
Attachments
FIFA_EEC-V_LP4_msg.txt
(4.16 KiB) Downloaded 257 times
FIFA_EEC-V_LP4_lst.txt
(393.64 KiB) Downloaded 230 times
FIFA_EEC-V_LP4.bin
(256 KiB) Downloaded 256 times

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 » Sun Feb 16, 2014 6:18 pm

Everyone,

Sorry for the recent absence, had a tech disaster on my PC ....

[ Yeah, Yeah, Windoze XP, I know.... and worse, obsolete Borland Builder ...... but I'm too mean to pay for Win 7, and Win 8 looks like a mobile phone.... Oh, ...right, yes, of course I'm a dinosaur ! Anyway, it's just not for me....] .

Moved to Ubuntu, I worked with UNIX machines for work for a long time anyway, so I'm comfortable with that interface, and it's FREE !!
I did have backups, but have had some issues with hard drive. New disc installed. Now investigating [free] compilers which can handle 'C' code without too much modding from Borland flavour.

Watcom seems quite good so far, but I now have to learn how to do Windows programming for real instead of hidden behind the Borland libraries (although there are some free ones which are supposed to replace/simulate them. Investigating, but haven't got them working yet....)

So next few versions may be non window version, but will run as a DOS32 program, and will operate the same way, just needs a filename to be typed in.

Codewise, have got A9L working again without directives after some big code changes to SAD, and making progress on EARS (which does some even sneakier tricks than A9L !), and then I'll double check the multibanks. I also need to sort the multibanks which use the ALTSTACK for diagnostics.

My aim is to get this tool to work as automatically as possible, just from a bare binary dump/image.


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

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

jsa
Tuning Addict
Posts: 519
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

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

Post by jsa » Sun Feb 16, 2014 8:58 pm

Nothing wrong with XPasaurus, don't mind 7, but avoiding vista2 as well.

Do they have a command line on that phone OS ;))

I hope you reach the goal of auomatic decoding.
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

User avatar
cgrey8
Administrator
Posts: 10565
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 Feb 16, 2014 9:41 pm

I looked into ways to port some old Borland C++ Builder stuff a few years ago and gave up. I wound up manually recreating the program in .NET which I found to be far superior. The online documentation is absolutely phenomenal, the features, and ease of use are a developers dream come true in comparison.

As a result, if you are now running a Linux based OS like Ubuntu, then consider the open source .NET alternative. I think it's Momo? I haven't used it myself, but I wouldn't hesitate to look into it if I had to do .NET development again particularly given I am also now on Ubuntu at work as well. And if I had trouble with it, I do still have my WinXP dinosaur laptop to fall back on for development.

The only other language I've ever found that was near as easy to develop in as .NET (C#, VB, ASP, and the other various .NET flavors) is Java. Java is almost as nice to develop in...almost. UI stuff is easier in .NET.
...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: Developing a disassembler. Send me your binaries to test

Post by tvrfan » Mon Feb 17, 2014 12:19 am

Thanks for that - Yeah, doesn't seem to be an easy conversion path...Ah well...

Did you know one of the chief developers of .NET was also (apparently) a chief developer for Borland's VCL library ??? Interesting....

Will have a look at Momo (or nearest name !).

Open Watcom claims to be able to compile (almost) the same code for Win32, Linux, and other OSes, even DOS, and has some visual design tools, and runs on Win or Linux, so I'm checking that out at the moment. Lots of other tools for Linux too....

As most of my UNIX work was a database server type environment, didn't do any visual stuff, but some C, and a lot of shell scripts. I used PERL for most of those scripts - a fantastic language IMHO....

jsa - Yes, to be fair, XP was/is a very good platform, but getting quite old now, and for some reason my Borland Builder now causes it to lock up.
This is only after the XP reinstall, which I don't understand - it was all fine before the disc crash....weird. Tried all the obvious stuff - no solution (yet).
May try out a VMware virtual machine inside Ubuntu, and set it for Win98 (I still have a CD !!) so it's right for Borlandc version....you never know...
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

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

jsa
Tuning Addict
Posts: 519
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

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

Post by jsa » Mon Feb 17, 2014 1:08 am

tvrfan wrote: This is only after the XP reinstall, which I don't understand - it was all fine before the disc crash....weird.
I had some problems with a re-install of XP, turned out to be windows update substituting a Microsoft driver for the OEM version. I don't imagine a driver being the cause of the problem with Borland. None the less might be worth disabling win update and being selective about updates before installing Borland.
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

decipha

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

Post by decipha » Mon Feb 17, 2014 10:08 am

Andy... check out dev c++ from http://www.bloodshed.net its one of them love/hate compilers

I find .net to be too unstable and SLOOOOOWWWW

Java is ok but for an independent platform i just dont like it, i feel java needs to stay internet based

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 Feb 17, 2014 4:47 pm

Sorry about getting a bit off topic ! Thanks for suggestions.

Search of web shows there are apparently some odd problems with Borland and XP to do with some video drivers. It probably is an update or something like that - good idea.

Found a good simple tutorial for Win32, for me anyway, "theForger's Win32 API Tutorial" and pitched at about right level.
I now see it's not that hard really.

Anyway, back on topic -

I now have one of the two (spotted so far) EARS/LAWN/ANTI type variable argument subroutines decoded correctly and automatically, and working on next one.

I notice I do need to tidy up some of the command structures and some of the messier bits of code before doing another release.
Will probably add a simple SAD.CNF file for default config and directories etc. as well, so it survives over each run of SAD.
TVR, Triumph (cars), kit cars, classics. 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 » Fri Feb 21, 2014 6:12 am

maybe, not dos32, but flat model win32 console app? and extra editor, allowing to do some definitions, adding them to directives file, and running SAD on demand, when you are ready? I've had experience writting some graphical shell on TCL/TK. it's impressed me in it's "zx-spectrum-way": you can drop togerher some quick and dirty GUI in two hours on your first effort.
as I understand, SAD runs in several passes over input file? maybe, it's a good idea to add an option to resolve recent additions in definitions file?

Post Reply

Who is online

Users browsing this forum: No registered users and 5 guests