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.

A small boost to this creator.

 It's not often I write here, and not often I give a shout-out but a couple of weeks ago, after I contracted COVID-19 and was in quarantine, I came across a post where a person invented his own algorithm for YT recommendations and his algorithm recommended him a YT channel that youtube's algorithm would not recommend.

 It's a small channel, but deserves more views, and to better give a fighting chance for exposure of up and coming content creators versus big channels. It's not like this blog gets many views, but a boost of 1 or 2 is still a boost, right?

Hi Karolina ^^, you'll probably see this via YouTube's referrals overview. My blog is measly, but hopefully you can gain some more exposure. 

https://www.youtube.com/c/KarolinaSowinska/videos

https://www.youtube.com/watch?v=gwLIjRtRQgE

Sincerely, F

 After some cleanup I managed to get the unique code verification blocks, and narrowed them down to 35. This excludes various junk instructions inserted and different registers/memory locations. Below is the code I used to find the unique instances.

for (int i = 0; i < m.size(); i++) {
    Vertex n = (Vertex) m.keySet().toArray()[i];
    int size = m.get(n).size();
    for (int j = 0; j < size; j++) {
        Vertex v = m.get(n).get(j);
        if(!v.isLoop)
            continue;

        long hash = 0;
        MessageDigest md5 = MessageDigest.getInstance("MD5");
        for (int k = 0; k < v.insns.size(); k++) {

            Instruction in = v.insns.get(k);
            if(in.bytes.length == 2 && in.bytes[0] == (byte)0xEB && in.bytes[1] == (byte)0x0)
                continue;

            md5.update(in.opMnemonic.getBytes());

        }

        hash = ByteBuffer.wrap(md5.digest()).getInt();

        if(occurrences.putIfAbsent(hash, v.insns) == null)
        {
            System.out.println("added");
        }
        else
        {
            System.out.println("not added");
        }
    }
}

However, those 35 unique instances are variations of two operations, xor and add. So xor and add mutated to 35 unique blocks of code, multiplied a bunch of times to 22718.