Tools

= Some software tools = To help with haxing ROMs etc.

freediag

 * Project page and some builds: freediag @ sourceforge
 * Source code : freediag @ github

nisprog
For the moment, nisprog is just the name I give to special freediag builds that include some Nissan functionality. Eventually it will be forked, and link to freediag's "libdiag" backend. I post some of these builds on the RR forums. TODO:link

IDA
'nuff said.

Adding extra processor defines can be useful to show the peripheral register names, and fill in the reset vector (IVT) with vector names.

User dschultz @ RR forums started this with a sh3.cfg file to replace the stock file included with IDA. I expanded on the idea and added definitions for the secondary vector table so popular in Nissan ROMs. That is, they have only a partial vector table at address 0; the power-on reset code then sets the vbr register to point at the complete table either @ 0x1000, 0x2000, or 0x0002 0004 depending on the firmware revision.

I keep my expanded configs on my github repo

WinOLS
Useful even in its demo version, it makes it easier to find, visualize & edit maps in a ROM.

WinOLS Demo Disassembly
'''DISCLAIMER- I do want to note that the screenshots provided are being used for an educational purpose. Thus, falling under fair use.'''

Setup; So to start, WinOLS will look a bit funky. Not very user friendly looking. If you open your ROM and it's just lines (2D Mode), then switch it to text mode. You can do this at the bottom left of your ROM view window. So what you'll want to do is go to the taskbar in WinOLS and click " Miscellaneous " -> " Configuration " -> Enable " For hex values remove leading zeros " What this does is it makes those ugly 0000 values go down to just 0. This will make it so it's easier to distinguish between empty cells and actual values.

Some basic key usages- " a " will let you jump to an address. You do NOT need the 0x in front of it. " k " will create a map wherever you last clicked. If you highlight anything, you will have to right click outside of the highlighted cells in order to create a new map. What I do is right click the potential starting cell of a map/value/table, copy the address, then click " k ", set the axes length, then add the address to my definition file.



You'll also want to change the values from Hex (" FF ") to decimal (" 255 ") as seen above. Don't forget to enable the coloring by click the colored box at the far right. This enables coloring based off the values. This makes it much easier to identify curves, maps, you name it!

Value Types; The data will typically be viewed in either 8-bit or 16-bit mode. There are a few 32-bit values, but nowhere near as many as 8-bit and 16-bit. The main thing to look for with 8-bit is whether you should be in uint8 or int8 (unsigned or signed.) This will be map dependent. 16-bit is a tad bit different, as you can view the data as either LoHi or HiLo. You will need to set this to " HiLo " for 16-bit values. WinOLS doesn't do this automatically most of the time. So whenever you switch from 8-bit to 16-bit, you'll need to switch it back to HiLo. You can do this by clicking the " LoHi/HiLo " box next to the " +/- " (unsigned/signed) box. By default, the values are unsigned. When you click the " +/- " box, it changes the values to signed values.

Typically, the value types will be setup in chunks. For example, the values between 0xA000-0xB000 will be uint8 values (for the most part), while 0xB000-0xD000 could be uint16 values (for the most part.) These ranges aren't legitimate, they're just to show an example. While most of the values within whatever range will be the same type, there will be outliers. So don't just assume that all the values will be the same type. If you're cross referencing with another ROM, this shouldn't be an issue. If needed, you can always view the definition template xml and see what values/tables/maps are what value type.

ROM Disassembly; ROMs from the same market and vehicle will be extremely similar. Both in the values of the maps, as well as the patterns, what maps the ROM has, what flags are active, etc. So if you can find a ROM from the same market and vehicle as yours, then you're set. Do take note, the storage addresses will not be identical. When it comes to the 350z, I've had no trouble at all cross referencing my 06 Automatic (CF48D) with even an 03 Manual (CD002). So any 350z ROMs can be cross referenced with CF48D, which is the best ROM to cross reference besides the A2L.

The one issue with the A2L is the fact that even though the A2L.xml definition template used by CF48D is based on the A2L file, the names are unique. So while you could use the A2L to cross reference, you wouldn't easily be able to add the maps you find to your definition template. I've tried remedying this by including the A2L abbreviation in all the maps' descriptions. So if you cross reference ZB060 (A2L ROM), then you can still use the A2L.xml template. You'll just have to search for the abbreviation inside to figure out what the table name is.

So while same market/vehicle ROMs are easy to cross reference, what are you supposed to do if there isn't a ROM available like that?

Unique ROMs; For this example, I'll be cross referencing 1KA6A (Left- 2010 Nissan Juke) with CF48D (Right- 06 Nissan 350z) Two very different vehicles.



On the right, you'll see the three ignition timing maps inside of CF48D. On the left, you'll notice that it might not look very similar at first glance. But when you start looking deeper, you start to pickup the little things. You might notice that there is a similar pattern at the very top. "128 128 128 0 128 128 128" in 1KA6A, and "128 128 0 128 128 128" in CF48D right before the defined Cold Ignition Trim Map in CF48D. Then following that back a bit, you'll notice that right after the chunk of "60" values, there seems to be a bunch of zeros before those 128's, just like in CF48D.

High Temp Fuel Compensation (0x8DC1 for CF48D ) is the map defined in CF48D. So potentially, 0x994E (the start of the 0 values in 1KA6A ) is the same map! You can verify this in IDA by finding the axes and seeing if they line up with CF48D or any other way of verification. I won't be discussing verification as that's something that you just need to have experience with. So after verifying/presuming, we know that 0x994E is in fact, High Temp Fuel Compensation for 1KA6A !

In CF48D, the three ignition trim maps are right after this map. If you look in 1KA6A, you'll notice three very similar maps with similar values. As we know that the High Temp Fuel Compensation map is right before the beginning of the first map, it would be safe to presume that these three maps are the ignition timing maps. You would want to verify, but it's a safe bet that they're the right maps. So now we have the three timing maps defined. Directly going off of CF48D map patterns, we find the possible Cold 0x995E High Octane 0x9A5E and High Detonation 0x9B5E ignition trim maps.

Due to the vehicles being extremely different, it's not safe to presume that these are the actual order or that they retain the same functionality as in CF48D. So you would have to do further research through IDA/Ghidra, patents, others, etc. But you at least have the maps defined now.



'''So after defining those maps, you'll now notice that they look extremely similar in 1KA6A to CF48D ! So that's why you need to look at the values around a potential map. They will be able to tell you what the map potentially is/help verify your suspicions.'''



'''Here you can see Fuel Compensation defined for CF48D on the right, and a chunk of values that looks awfully similar. It would be safe to assume that 0xB21E in 1KA6A is probably the Fuel Compensation map. You would want to verify this, but it is most certainly a safe bet.

Most importantly, now you have a lower and upper limit setup. So between (High Temp Fuel Compensation Map 0x994E-0xB21E (Fuel Compensation) in 1KA6A will potentially store similar maps as CF48D does from 0x8DC1-0x9471. You'll notice that the gap between maps is significantly larger in 1KA6A . This is due to that ROM having maps not found in CF48D within that range. But there's a very good chance that the maps between 0x8DC1-0x9471 in CF48D will be in 1KA6A within the range of 0x994E-0xB21E.'''



'''Obviously, these two ROMs look extremely different in this side by side. In CF48D, you can see the High Detonation Ignition Trim map, yet there are these weird values in 1KA6A instead of the high detonation map. This is once again due to 1KA6A having maps that CF48D does not have. As both vehicles have different ways of controlling the vehicle, you're not guaranteed to have the same maps.

For manual and automatic Z's, for instance, I've noticed that there are some maps that are completely unique to CF48D that aren't defined in the A2L or an 06 manual 350z. Yet the target drive force maps used for CVT's are in nearly all Nissan ROMs :)

Now, take note of the map in CF48D that has the red outline. The more you look at it, the more obvious the patterns become. '''

So thanks to having that range defined from earlier, we were able to locate three maps that we never would've been able to locate otherwise! Oddly enough, they're in the same order as CF48D. So you could imply that the map locations pattern (the order of the maps in the ROM) in CF48D is worth looking into for 1KA6A.

So now that you have these maps defined, you can shorten the range to find maps between the timing maps and the maps you just defined. You can continue doing this till you either define all the maps you can in that range, define the map you want to define, or conclude that the map doesn't exist at that position in one of the ROMs.

It is crucial that the ROM you're cross referencing your ROM with is defined. Thanks to CF48D being defined, I was able to open up a ROM that was extremely different from mine and still manage to define some maps for it with ease. So it's all about finding similarities and working from those similarities. Those ignition maps are the easiest ones to locate in most ROMs. Once you a point set where you know both the ROMs are the same, you can work off that and grow it into something much larger. It's how I went from a total of 35 maps defined to being well over 2100 maps defined for CF48D. I just started at the timing maps and worked my way from there!

Do take note that just because 1KA6A is able to potentially follow the same map pattern as CF48D doesn't mean that it will be this way for all ROMs. There will be some ROMs that are just too different to cross reference with CF48D (I haven't found any that this was the case, but I'm sure they're out there) If that ever is the case, CF48D could still be used, just not in the same way it can be used for similar ROMs. Also, I defined 3D maps above. These are the easiest things to define when cross referencing. You will start to struggle more once you try to compare 2D tables and 1D values, as the pattern is much more difficult to visualize (If there even is one) as well as the fact that 1D and 2D values are more likely to be ROM specific (whether it's in the ROM or not) than 3D maps.

Do also note that CF48D is a SH7058 ROM. So it has double the space as a SH7055 ROM. So it's pretty much guaranteed that it will have maps that are not found in a SH7055 ROM. If a ROM doesn't have a map, it'll either be zeroed out values or the space where the map would be just won't exist at all.

Saving Your Progress; So how exactly do you go about saving your progress? So WinOLS will just number any ROM you open, with no easy way to identify ROMs when you start having quite a few in your history. So what you'll want to do is go to the taskbar in WinOLS and select " Project " -> " Properties: Version " -> " Name " and then enter in the ECUID / whatever identifier you want. Make sure to check the description box to make sure that you're naming the proper ROM. It will pull up the version properties of whatever ROM window is the current primary one.

So while this isn't a super in depth guide, hopefully it provides others with the basics so that they can at the very least, get started with basic ROM disassembly. I would highly recommend you start by opening up two similar ROMs (same year and model, or same model) and going to the addresses of maps that are defined in both ROMs to compare. You'll be able to see the pattern (what maps are around it) and hopefully be able to utilize it to define more maps. There's an endless amount of possibilities when it comes to ROM disassembly. You'll have different techniques depending on what your goal is. This is just a guide to help get you started if you're brand new and wanting to get into ROM disassembly.

Renesas HEW
Renesas High-performance Embedded Workshop, their complete IDE including compiler, assembler and simulator (very useful for analyzing sections of code). Note, apparently HEW isn't available on its own, but is included with the C compiler package !

NOTE concerning simulator : it simulates the core quite well, but is *very* limited in peripheral support. Only some DMA features and very very simple timers are simulated. Important stuff missing:


 * SCI
 * HCAN
 * Everything ATU related
 * Everything else

Very cool thread on how to get started with HEW : Hacking with HEW

Renesas FDT
Renesas Flash Development Toolkit, utilities for reflashing SuperH mcus.