jcsbanks

To fully finish the disassembly of one ROM with the number of people that were/are doing it is not viable or interesting to them, and commercially also not viable. Nice idea, but who is going to do it? I struggled to get people to test things that were handed to them on a plate for nothing, although now a few are developing the stuff I worked on further. I reckon from where the Evo ECU is now, it would take a few full time person years to do a complete disassembly of one ROM where every line and variable is 100% understood like the earlier DSM. There is much more code in these later model ROMs than was in the earlier EEPROM based ECU which could also be emulated to help discovery.

codgi

iTrader: (22)

Focus the few who are serious about it in that direction instead of the mods. I'd also argue that in fact fully understanding what its in the ECU today is more important than those same mods. E.g Mrfred doesn't find that "Gear based boost control" and someone wastes time down the road implementing what was already there to begin with.

It depends on the quality of who is doing the disassembly. If you have people who are learning this on the fly (as we mainly have here) then I'd agree with you to some extent. If these are full time security software specialists (do the most disassembly professionally) I would say no. And if they are, and they take years, then there's a probably a reason they are out disassembling car ECUs and not working front line security anymore .

Anyway, I won't derail further.

jcsbanks

I think you will struggle to find someone who can adapt to the role you propose for sensible money. I won't do it full time because I can't attract the rates I can in my main job, and the industry can't afford to pay them, yet I've managed to make developments commercially that haven't happened until now. It is targetted work without a complete disassembly like happens in the entire chip tuning industry. It is often much easier to bin a load of spaghetti code and bypass it to write a simple tuner friendly routine. Then you can get a small project done in a week that literally turns the tuning world on its head. Such a project on the GTR has rewritten the rule book on boost control, it saves people 20 hours labor to pull their engines out to fit actuators, and also the need for an EBC. I would still be faffing about disassembling just the GTR boost control, but as it is the records have already come tumbling down because I was pragmatic in my approach rather than idealistic/unrealistic.

You could have a really good x86 disassembler who knows little about engines, ECUs or microcontrollers. Some of these people already work in the chiptuning industry and find they rapidly need a new skill set, or struggle to deliver on things that are useful to tuners. I also think you underestimate the complexity of embedded device reverse engineering, and overestimate the usefulness of a complete disassembly in terms of making engines run better. I certainly don't think it is commercially viable.

I think you also underestimate what has been achieved by a bunch of amateurs. I don't know of any other ECU platform that has a disassembled OEM knock control routine for example, commercial or open source. Most commercial efforts ignore this area, it isn't viable for them. I think open source Evo ECU development has set the trend, and is by no means a laggard. It is the regard in which this work is held by commercial organisations that got me a job after a few emails that showed how I could contribute to a commercial project.

I think you'd need to try personally disassembling some of these routines before you could comment on how long it would take, by an x86 security expert or not. And if you do think it is commercially viable, I wish you every profit, but I think if you investigated it, the benefits that would be achieved and what income that would attract vs the cost to do it you would back well away.

acamus

I think it would be easier for x86 security professional to hack into mitsu source code servers and get the complete code instead :P

jcsbanks

LOL, that would be right!

Raceghost

iTrader: (4)

My vote is for the 96420011, it is the latest revision for the 8's in the US. This is the rom that should be used for all eights. Obviously that guy in japan that compiles all the roms, was givin information to change and so the latest revision is released. Like someone else said, why build on a first release, or mid release rom. It makes no sense. Issues in these roms are still there even though we have a lot of tables out there for the roms in question. Lets go with the 96420011.

logic

iTrader: (2)

(Note: you're bumping a thread that's been dead for a month and a half, and most of the participants have moved on to other things to argue about.)

9642-derived ROMs were released for USDM '04 vehicles; if you really want the "latest" ROM for the US market (something I can fully understand), you'd really want to start with the '05 9694-derived versions. To the best of my knowledge, the latest release for them was 96940013, which suffers from the same problem that the earlier USDM '05 ROMs had: no free space available.

96530006, what a lot of recent work has been based off of, is an EDM ROM for '05 VIIIs, making it the latest known '05 EDM ROM (I suspect there's a newer version, given how long 96530006 has been floating around, but I've never seen anything newer posted). 96530006 is "interesting" in that unlike the later USDM ROMs, it has a ton of free space for additional code, making it almost perfect for the job.

--

At the end of the day, though, there's no "voting" here. If someone cares enough about a 9642 ROM, they'll port the current collection of patches to it and provide support. My interest is solely in 9653-derived ROMs at this point, unless someone provides a compelling reason for me to look at something else, but that doesn't mean you can't make the effort if it's interesting enough to you.

Evo_Jay

iTrader: (17)

94170015 will be the universal USDM ROM.

Raceghost

iTrader: (4)

Sorry, didn't look at the dates there Logic. My apologies. lol.