Automobile ECU reverse-engineering, SuperH SH2...and what a bad architecture it is.

So I have an unnamed car, it has a limiter of the horsepower on the electronic throttle. I wanted it gone but don't want to pay absurd amounts of money to do so.

So what does one do? He searches for a free method first. In doing so I have found out about WinOLS, ECM Titanium and other paid applications to tune an ECU.

And what is tuning exactly? Well apparently it's using the aforementioned software to alter tables of data comprised of a Map,Y-Axis and X-Axis. The data(map) and axises can be anything, RPM, Temperature, Fuel Injection Quantities(IQ), boost, etc.

Great, we know what we have to do and how to do it....except we can't. We don't have any data to edit, so we google how to get to these maps and turns out, you need to buy expensive overpriced proprietary black boxes of hardware to read the ECU data. KESS, Ktag, MPPS, Galletto,Dimsport and bunch more. And in addition to this, even if you somehow managed to get the maps, you have no idea what those maps are. So now you enter the world of tuners, you need to learn what DAMOS,A2L,ORI are, and then you learn...that people who may have these files charge money.

What I've also witnessed is that the tuning community is very secretive, they do not have a concept for free and open source. All the "free" data you can get is password protected RAR files with strings attached, e.g building reputation, and the passwords are then sent via PM, and nobody publicizes this information...anywhere. Fairly toxic for sure.

Anyway, I have a rare version of my car, and as such the ECU is also very very rare, luckily I found one user who had the same car and had dumped everything(code, maps) I need and I managed to get it for free due to sheer luck, because why would I risk opening my ECU and shorting something, causing my car to not work and waiting potentially months to find a replacement, which will not immediately work because it would not contain the same immobilizer data.

#TheDUMP

My ECU is made by Denso, it uses the SuperH RISC architecture, more specifically the MCU I have is SH7055 and as such it uses the SH-2A or SH-2E instruction set. Most ECUs are made by BOSCH and as such have more widespread dumps and information.

This architecture is...for a lack of a better word, utter horseshit. Instructions are a fixed 16-bit length, this wouldn't have been a problem if it wasn't so easy for a disassembler to disassemble data as instructions that seem legit in 80% of the time.

This again wouldn't have been a problem, if the arch was also not using PC-relative addressing while intermixing data and code. Yes, oftentimes a function would reference a constant or some data that is stored just after the function. 

The compiler for this architecture, made by Renesas, is garbage, it decides that after referencing some data by it's PC-relative offset, it would select some part of the data and use addition to get the rest of the offsets. This makes finding where a function is used more difficult, if this method is used on those as well.

 

I am leaving the best for last...it uses delayed branching...this means that when there is a branching instruction, it doesn't get executed right away, but the instruction after it gets executed first.

 

Here instead of the bra instruction getting executed first, the very last instruction(mov.b r3, @r14) in this basic block is executed first and only then does it branch.

What a shitty architecture.

Denuvo - I thought we were over you.

 So I wanted to play a game, it's released, it's nowhere to be found - odd I thought. I go and search online - nothing.

Surprise, surprise when I found out it has Denuvo and has gone uncracked for a long time. What happened? There was such a great track record for this and we are back to square one.

I wanted to practice some Java and Python and what better way for me than writing some RE tools. I decided on my SecuROM protected executable. While I was at it I loaded up the executable in Olly and even x64dbg and to my surprise it no longer ran under a debugger. 

It took me a while to figure out that I had fiddled with Scyllahide's settings a few years back. I found out the reason it didn't work no more. A hook of NtUserFindWindowEx caused SecuROM to detect the debugger somehow, whether intentionally or it's a byproduct of something

So far, no clue but after I finish up my tooling I may find out what it is, could end up being a good anti-debug check.

Binary instrumentation and recompilation of game logic to improve performance.

Fancy title, I know.

I have been interested in recompilation of game logic for specific processors for a while now.

It's probably a no brainer that games are compiled with generic compiler settings for a generic x86 processor, rather than optimizing for a specific microarchitecture(for obvious reasons).
It's also a no brainer that Intel beats AMD in performance when it comes to microarches prior to Zen. This makes a lot of old processors "useless" for gaming as games become more complex and thus require more CPU processing.

But what if you could either reduce or optimize a certain CPU intensive part of the logic so that it executes faster.

I understand that most games today might be more graphically intensive and thus require more GPU horsepower, and thus overclocking the GPU may provide more performance gain, but this won't be the case forever I think.

Battlefield 1 for PC has horrible performance, even on my i5-4670k. It requires so much CPU cycles, that the GPU is actually starved of data. DICE should fix this, but they haven't.