RomRaider

I've spent a lot of hours reverse engineering my ROM trying to achieve some useful features. I've been using HEW, ODA, and wols. I imagine IDA would be useful but I don't know what I'm missing out on. I've had some success (So far I've determined how to disable the CEL for specific DTCs) but is anyone else working on anything specific?

Ideally, I'm trying to find to find things useful to the whole community. I realize some of these objectives are rather ambitious, but here are the objectives I've got:

Update Feb 11, 2018 with progress thus far!

WORK IN PROGRESS - Define all scalars/axis/maps
Incomplete - Find fuel injector latency
COMPLETE - Find cat efficiency thresholds
COMPLETE - Find O2 heater current thresholds
COMPLETE - Find NATS logic
COMPLETE but untested - Find MAF hi/low voltage logic
COMPLETE - Find VIAS logic
COMPLETE but untested - Toggle DTCs
NEW GOAL - Enable MIL for knock detection

I haven't done anything as of late.

It's interesting that you've knocked out the DTC's without using IDA.

The fuel injector latency should be relatively easy to find from other defined roms in looking at how the code works.

I have hunches, but haven't bothered to dig anything up as I've been busy and disinterested as of late.

Feel free to start posting about your work or discoveries and you may see some interest.

Is there a ROM definition that has fuel injector latency? I didn't see any.

Just so it is clear to anyone browsing; I haven't figured out how to disable DTC logic from running. I have figured out how to disable CEL for most DTC's. I'm not remotely interested in disabling the CEL for DTCs that cause limp mode.

I'm currently testing secondary o2 sensor heater current thresholds, and 3 way catalyst efficiency thresholds.

In my opinion, Nissan has done quite a good job obfuscating the code. They've employed all sorts of little tricks to make things difficult to locate, let alone determine their purpose.

Just out of my curiousity - what does "CEL" mean?
Btw I've managed to find a table which acts like a DTC mask preventing them from beingh triggered during ECU operation but not for all of them it does the trick. For example EGR - related DTC in 1ED09 ROM can be perfectly disabled and no consequences like limp mode follow. But it doesn't work for IMMO-related DTCs You cannot simply disable them.

Nissan ecu similar to Hitachi may implement calculations and not tabulated injector latency.
Hitachi\JECS uses hardcoded latency value at 14V battery voltage and ms\V slope value to calculate latency at different battery voltage.

There are some approaches used for selectable diagnostics programming.
Some system\tests maybe switched off in configuration mask.
Some are compiled conditionally and are to be overcome in the code.
Sometimes you may correct thresholds to switch test branches off.

JECS\Nissan\Hitachi ecu's are from the same origin and use all those variants.

CEL = Check Engine Light (The preferred title on maxima.org)
SES = Service Engine Soon (What it actually says)
MIL = Malfunction Indicator Lamp (What it's called in the FSM)

So far I've only tried testing the behavior of the CEL. If it weren't -33 outside I'd be doing more testing. The DTC mask table points to behavior values for the DTCs. There are DTCs in the ROM tables which are not applicable to the particular engines which they are operating but the behavior of those invalid DTCs is identical to valid DTCs, the ECU either doesn't have the logic for those DTCs or they've been disabled elsewhere in the code. Once it warms up a bit I'll have to do a test with NATS, but I don't think it's going to be straightforward.

Yes, I realize I'm probably only looking for those two values. Doesn't make it easy to find, how did folks find things like the rev and speed limiter in the first place?

Thanks for explanation Don't bother with NATS if it's only because of my question - I already figured it out for my particular case and found a solution.

Hi a33b,
I hope you already knew about this page :
https://nissanecu.miraheze.org/wiki/Firmware_re

In particular the DTC section -- I didn't dig much deeper than what I wrote there due to lack of need, so if there are extra details you could share, it would be a great addition !

Code obfuscation : after a ridiculous amount of time spent looking at SH code, I'm now pretty sure it's not done on purpose, it's just a combination of how the source code was written at Nissan/Denso, and how the compiler (shc) behaves. It could have been much worse if they were actively trying to obfuscate the code !

I have written a few tools to help with these ROMs, you should check "test_findrefs"
https://github.com/fenugrec/nissutils/t ... /cli_utils

Oh yeah fenugrec! I've spent a lot of time on your wiki.

I went through the FSM and correlated the DTC behavior (MIL, 1 trip, fail safe behavior) with the options data. To my delight, that's what the options indicate. The DTCs are indexed identically in both tables; "descriptors" and "options". (I called the options table "xrefs" because the options are actually stored at the longword location in that table.) In my 6y303 rom the options data are scrambled, but don't skip any locations. In my zj05b rom the options data are scrambled and skip some locations. (about 22 or so that aren't used)

This is another example of what I mean about obfuscation, there's enough zero data in the DTC descriptors block, why not just put the options data there?

Man I wish I had IDA, I'd have made good use of the findrefs tool. I've been plodding away through my disassembly in Notepad ++

On a technical note, when using HEW, I've noticed that some mov.w commands don't sign extend the registers (they have all pointed to valid locations in the ROM) but I can't figure out why. For example (attacched) 485e is from the ROM, but 8466 is from RAM???

485e is expanded to 0x0000485e and points to ROM
8466 is expanded to 0xFFFF8466 and points to RAM

In this case I think it's just due to their workflow : imagine the number of different ECU and config permutations, it's bound to be an XML mess (if their consult3 software is any indication) with plenty of auto-generated parts. Like perhaps the config array is generated according to a certain ordering that is different from the DTC sequence, and your "xrefs" array is filled last with just a bunch of pointers.


No no, you can use findrefs regardless of what tool you use : it parses the ROM dump directly !


As Sasha pointed out, it works : mov.w takes bit 15 (0x8000) for the sign extension. This is one optimization by shc combined that benefits from the convenient memory map of most SH705* devices : a large part (or all) of RAM is mapped above 0xFFFF8000 , so it can use 16-bit words ( > 0x8000) in its literal pools and sign-extend very efficiently with mov.w;
My kernels compile with gcc which is a bit less clever : it saves the whole 32-bit address and retrieves with mov.l .

I'm trying out some of the command line utilities now. I'm not sure if I'm compiling correctly though. I've just run findrefs so far and it hangs after finding the refs, and then Windows tells me it has stopped working. What arguments do I need to pass to gcc? Sorry, I'm new to this. Last computer science class was 14 years ago and I don't remember how I passed. It's a shame, I've really come to take an interest in it.

To compile I typed: gcc test_findrefs.c nislib.c -o findrefs.exe

I have no idea what the nislib.c or -o are for

This means you've probably found a bug ! PM me the details, I should be able to find a fix.


"gcc --help" should be, "helpful" : )