RomRaider

I was on vacation last week and I spent quite a bit of time getting to know the Renesas "High performance Embedded Workshop," or HEW. Two of the biggest things holding me back from ECU hacking were not having a compiler and not having a simulator, but HEW includes both. I finally I have what I need to start making changes.

To get started:

* Install the "High performance Embedded Workshop" installer from:
https://www.renesas.com/en-us/products/ ... e/hew.html
Or use this copy of v4.8.0: http://www.romraider.com/roms/dl.php?fi ... ntc_v1.exe
Incremental update to v4.9.0: http://www.romraider.com/roms/dl.php?fi ... update.exe
Incremental update to v4.9.1: http://www.romraider.com/roms/dl.php?fi ... update.exe

* Register at https://gcc-renesas.com/sh/download-latest-toolchains/
Activation code information is here: https://gcc-renesas.com/help/faq/

* From gcc-renesas, get the "Windows Toolchain (ELF)" installer for the SH microcontroller. Currently you'll find it under Products / SH / Download Toolchains / Latest Toolchains.
Or use this copy: http://www.romraider.com/roms/dl.php?fi ... 01-ELF.exe

* Install the SH toolchain, and tell the installer to integrate with HEW.

* Download the attached zip file, uUnzip it somewhere
Or get my latest from https://github.com/LegacyNsfw/EcuHacks

* Start HEW and open the HEW.hws project from the zip file

...and now it might get tricky. There are a few steps to getting the debugger to work, and I *think* that the files in the zip will mean that you can skip most of them, but I'm not certain.

Under the Build menu, click "build all."
Under the Debug menu, click "Reset CPU."
Right-click "EcuHacks.x" in the project tree, and click Download.
Open a Disassembly window (see the View menu).
You should see a highlighted MOV.L instruction at 0xA0000000, labeled "_ResetHandler." This is basically the "main" function for my hack test harness.
At the top of the disassembly window are three buttons, click the middle one to view source mixed with the disassembled code.
You should be able to step through the tests for my LC/FFS hack.

Also, try downloading a factory ROM instead of (or over the top of) EcuHacks.X, so you can step through factory ROM code.

If the simulator doesn't work, try these:

1) Under the Setup menu: Simulator, System, set "Step Unit" to Instruction.
Otherwise you don't see effects of instructions (like changes to register
values) until one or two instructions later, which makes life harder.

2) Under the Build menu, KPIT GNUSH Toolchain, C/C++ tab:
Pick "Object" from the dropdown, and pick Assembly.
Pick "Optimize" from the dropdown, make sure the box is unchecked.
(This isn't strictly required, but it makes life easier.)

3) Under the Build menu, KPIT GNUSH Toolchain, CPU tab:
Pick CPU = SH-2E

4) Under Setup, Simulator, Memory, add a read/write memory resource:
0xFFFF0000 to 0xFFFFFFFF

5) In the 'download modules' section of the project, add EcuHacks.x (the
project output file) to location 0.

Also, note that the simulator sometimes gets into a state where the 'stop' button is enabled, but clicking it does nothing. And then you can't close HEW because it wants you to stop the simulator first. But you can't. So you have to kill it with Task Manager. This is annoying, and I'm not sure what causes it, but it seems to be related to starting the debugger without having it properly set up (no files downloaded yet, perhaps?). Thankfully it's pretty rare.

To be continued...

If you're not familiar with linker "sections" you will be soon. Basically it's a way to tell the linker to decorate the code with metadata that tells the operating system where to place code/data in memory. This project uses sections to get a better simulation of the execution of patched ROM code.

RevLimiters.c holds the LC/FFS hack, with consists of two functions:

RevLimitPatch contains the code that would written over the stock ROM. The code lives in a section called .RevLimitPatch which starts at 0x318D0. That's roughly where the rev limiter code lives in my ROM (A2WC522N). RevLimitPatch starts with a few nop instructions, so that the first real instruction is positioned at 0x318DC, which is exactly where the stock rev limiter code is. RevLimitPatch just executes a JSR to my new rev limiter code. RevLimitPatch also contains some additional nop instructions and a JMP instruction to the rest of the ECU's rev limit code. The original rev limiter at 0x318DC also ended with a JMP - it's a bit odd that they used a JMP rather than a JSR but I suspect that's the result of a compiler optimization (JMP takes fewer instructions than JSR).

RevLimitCode, as you might guess, contains the redline/LC/FFS logic. RevLimitCode is in a section that starts at 0x85BB0, which is empty in the factory ROM. RevLimitPatch had to be coded in assembly since it is the interface between the factory code and my code, but RevLimitCode was written in C.

The actual RPM numbers for the various thresholds are unrealistically low, but they are what I plan to use for testing, so that I won't actually get anywhere near the engine's limits until I'm certain that the patch works like it should.

RevLimitTests.c contains tests for the RevLimiter, to simulate LC, FFS, and normal redline code paths.

Quirks:

References to memory locations in the ECU are done using #define macros (in EcuHacks.h) rather than the simple pointer variables you'd expect, because the #define trick causes the compiler to generate the simplest instructions. If you use a local variable to hold the pointer, the compiler will allocate space on the stack. If you use a global variable to hold the pointer, the compiler will put the pointer at 0x70000000 - even if you make it a const pointer. Enabling compiler optimizations might fix that, but non-optimized code is a lot easier to work with.

There seems to be a compiler bug when you try to read an 8-bit value from memory under certain circumstances. See GetFuelCutFlag for some extra detail about this. I didn't run into that bug in the rev limiter code itself, but I did in the test code.

We must step through every single instruction of an ECU hack to make sure the compiler is generating correct code. Plus that often showed the compiler generating references to variables at 0x7000000, or extra stack variables, etc. Stack variables are tolerable if there aren't too many of them (the stock code uses them too) but variables at 0x70000000 seems like a recipe for confusion when it comes time to merge the hack code with the factory code.

I've created a utility called RomPatch to facilitate creating and applying patches. RomPatch.exe has its own thread now, in the Tuning Utilities forum. That thread is aimed at end users - the information below explains how to use RomPatch to ease patch development.

It generally expects three parameters, like so:



The "test" command will tell you whether the patch file can be applied to the ROM file. The patch file contains the bytes that it expects to find in the unmodified version of the ROM, in all of the locations that the patch will overwrite - if those bytes are actually present in the ROM, then the patch is assumed to be safe. If not, the test command will print an error message.

The "baseline" command exists to get the expected data. When you build an S-record file with HEW, the file contains your changes only, and RomPatch.exe will append the data from the ROM that you're going to be overwriting (the "baseline" data). The main reason for this is to prevent users from accidentally applying a patch to the wrong ROM. If the ROMs are different, the baseline data will be different, and RomPatch will exit with an error message.

For each of the regions to the patched, RomPatch will read the ROM file and print what it finds to the console in S-record format. So, you build your project using HEW, and specify the start and end addresses of each patch using a format that I'll clarify below, then run this command against a stock ROM and copy-paste the output to the end of the S-record file generated by HEW. Presto, your patch file now has the baseline data that it needs.

The "apply" command is basically "test" with the additional step of actually writing the patch bytes into the ROM. It actually operates on a copy of the ROM file, and it only overwrites the given ROM file if everything worked. If all does not go well, the ROM file will not be modified at all. Either way, you should end up with a file that can be flashed to your car.

Better yet, download the patched ROM into the HEW simulator, and step from the original code into the hacked code, and step back out again. That sounds greatly preferable to flashing your ECU, crossing your fingers, and turning the key.

HEW saves your code as a ".mot" file, because Motorola came up with the S-record format. So, a sample session looks like this:

Glad to hear from you.

I had to write a "custom" primary bootloader for SH7055F without debugger\simulator...
Striped down HEW was directly downloaded from Renesas.
About 300 "protocol B" bootmode reflashes before SH7055F behaves as protocol C "GenericBootDevice" WITHOUT self-erasing the whole flash just after FlashDevelopmentTool connected.

A similar aimed M32R project is on it's way currently.

I've been using the command line GNUSH compiler -> Check code in IDA -> and lauterbach's simsh simulator.

Also using Tiny's patcher for testing. I wrote a small app to create the difference files.

Will check this out, thanks!

Tis the season for ROM hacking! lol... This is awesome though, I'm excited to see some developments for the 32bit ECUs.

Lauterbach's simsh simulator is very handy.
PM me it you need a fixed version with the proper SH7058 peripheral definitions (otherwise it mimics the 7055 which is different, enough).

Thanks, I had never heard of Lauterbach's emulator until just now. I found some other threads on it, not sure how I missed those... But I think I'm going to stick with HEW, because I really like the quick turnaround between writing code and stepping through it.

There's an option in HEW to have the linker generate a Motorola S-record file in addition to the x file. I wrote a simple S-record parser tonight, and figured out a way to encode patch start and end addresses in the SH4 executable.

Sample assembly source file showing how to declare the ROM ID and patch start/end addresses:



Sample output from the parser:



The stuff in the 318D0 range will replace the factory rev limiter.
The stuff in the 85BB0 range is the LC/FFS rev limiter.
(Source for both is in the zip file attached to the first post in this thread.)

The stuff in the 80001000 range is instructions for the ROM-patching tool.

1234000 = the next 8 bytes are the calibration ID, A2WC522N
(followed by some zeros for byte alignment)

1234001 = the next 8 bytes are the start and end addresses of a range that needs to be copied from the s-record file into the ROM file.
(followed by some nop instructions (0009) added by the linker, for alignment)

Hopefully by the end of the week I'll have a patched ROM that I can step through as a proof-of-concept. I'll post the source to the patching tool at that point.

I really don't want to break my car before Halloween weekend, so I probably won't actually flash a hacked ROM until then.

I was going to suggest that I can write a patch utility into the RomRaider Editor. I think the patch should be in S-record format then everything we need to know can be included in one file.
We just need to have a validation check to ensure the patch for ROMID x is being applied to ROM x rather than a patch for ROM y. This can be specified in an S0 entry.
Thoughts?

I like that idea a lot. I still want a command-line tool for testing patches, but it should be straightforward to integrate the logic onto RR when I'm done. Gimme a couple days and I'll see what I can come up with.

I've added the patching utility to the 3rd post. But I have to stress that it's basically just a proof-of-concept at this point. It is ready for experimentation and testing, but I won't have full confidence in it until I've flashed a modified ROM on my car, and that's a few weeks away (it would be sooner, but I have a road trip coming up). I'm posting it for feedback and simulation testing, not for reflashing!

I'm pretty excited about HEW as a tool for the aspiring ROM hacker. Like I said in the first post, it removed some of the biggest obstacles that kept me from trying this stuff. You still have to know enough SH4 assembly to set the hooks that call into the compiled-from-C code, and of course you have to know enough to understand the ECU code that you're integrating with, but at least the new code can be written in C.

Watching Merp's video reminded me of another thing that intimidated me a lot - manually applying patches with a hex editor. I just know that in ten iterations of that, I'd screw up at least one of them. I remember reading about someone who did an "insert" in the hex editor when he meant "overwrite," which bricked his ECU. There's still going to be some manual steps with my utility (like entering the start and end addresses for hooks in the factory code) but I'm trying to automate as much as I can.

Rom patch utility and sample project updated. There were indeed bugs in v1, related to specifying and extracting the correct byte range from the SRecord data. After fixing those I was able to I step into, through, and out of the patch code in the modified ROM file.

I still want to add some extra verification to the "apply" processing, to lower the odds of bugs and human error, but it's getting close to trustworthy now.

Will you be updating the checksum byte on each S-record line for official use?

Are you talking about each S-line of the patch? Any line with incorrect checksum may not be applied.
The relocated image should have S-line checksums corrected (since destination addresses are modified).