Hi everyone,

As part of my ongoing research into Simos18 I have moved from static analysis (Ghidra only) to dynamic analysis (inspecting code as it executes). This is a very powerful tool and makes things like indirect generated pointer tables or tedious iterative algorithms (like the header/scrambling used to generate the checksummed material in the Simos18 digital signature algorithm) a non-issue as you can simply execute the code which generates them.

To do this, I use "QEMU", a popular emulation/virtualization tool which has Tricore support. A few other Tricore emulators also exist, like the official Infineon one, "Tsim," which is available in the Hightec Tricore GCC package.

To get QEMU working for Simos18, I added a simple "machine configuration" to set up the memory map correctly: https://github.com/qemu/qemu/compare/master...bri3d:tricore-simos18 . In Tsim, this is set up using a memory config file instead. This file should give you a fairly obvious pattern which can be applied to other ECUs as well.

The "one cool trick" that really unlocks using QEMU effectively is learning about the "loader" device, which lets you map files into mem/flash without having to edit the source.

I also used gdb, the GNU debugger. The GDB interface is famously obtuse but is very powerful once you learn it (especially now it has Python built in), but if you wish you can also check out and compile the Ghidra Debugger branch, which plugs GDB into Ghidra to give it a nice UI.

This was all very simple to set up, really - the hardest part was finding a tricore-gdb. I eventually stumbled upon one here: https://github.com/Gigallith/gdb-tricore . I have no idea where it came from but it seems to work great!

I very loosely documented the setup process here: https://gist.github.com/bri3d/5429c0b25346a0830c01042e77d6914c (you will need to read the documentation for QEMU and GDB about which dependencies are required on which platform - I am actually on an Apple Silicon M1 Mac so a lot of my documentation may not be useful to others).

The big "gotcha" when using either Tsim or QEMU is that they correctly implement the CPU, which means you need to have the task context system set up correctly for call/ret instructions to work (otherwise, they will jump into the trap vector table). I have found that the easiest way to do this is to simply jump through the setup code for whichever piece of the software you are trying to inspect - for SBOOT, I just set a breakpoint at the end of the "start" code and set the instruction pointer to the beginning of the start code, and let it run wild. This has the additional advantage of setting the low registers that your compiled code may be using (a0,a8,a9, etc.) as well as the a10 "stack pointer" for free. Pretty cool, huh?

Here's my GDB init script for debugging the Simos18 SBOOT recovery shell, just as an example so you can understand the basic patterns at play:


At this point I have the CPU ready for me to set the $pc to whatever sub-routine in the recovery shell I want to inspect.

When it comes to peripherals, QEMU supports literally _none_ - peripheral register read/writes are just considered as memory read/writes and do nothing but persist. This is where Tsim (as the official Infineon simulator) has an advantage - Tsim tries to implement the STM timer, the interrupt wiring, and the PLLs. This can be really useful in some situations but can also actually be kind of a pain (I usually turn it off) - often times just enough of the tasking / context switch system will start working to confuse and annoy you.

I am working on implementing a few peripherals that I will find helpful (port I/O and CAN) but all peripherals on Tricore are really quite complex so it may be a while before I have more to show.

At any rate, this is already a very powerful tool set that can save you a lot of time manually clicking through stores and defining memory bytes by hand in Ghidra. And even if you are working on another ECU, I hope this gets the gears turning around tools available for debugging and reversing that can save you a ton of time.

 

d3irb, following your Sim18 developments has been absolutely fascinating. I've thought about emulation wrt ECU RE but quite honestly had no idea where to begin. This is awesome.

Out of interest, are you an electronic/computer engineer?

Hmm. I agree and disagree.

For Simos18, which to your point, is quite simple really, there are just a few base pointers in memory and nothing complex is going on code-wise which cannot be statically analyzed. I certainly agree it's more of a novelty than a necessary tool.

But, I will say that emulation has been very useful in exploring some corners of the ECU, like what material is actually checksummed to generate the SHA256-RSA signatures. This is mostly an academic interest rather than a practical one, but it has still provided some insight.

I do find emulation to be a time-saver even for simple things too, once the workflow is well integrated via scripting. For example when starting a new project, it's really convenient to just run the init routines and dump RAM - all of the copy-to-RAM tables and base pointers are already set up that way.

As for peripherals - yes, CAN and the timer-interrupt system would be the most important components to bringing up an ECU in emulation. CAN is tedious but straightforward, since the CAN controller in Tricore is so high-level it is really just a matter of mapping the message object tables to the outside world and defining the structs. But to your point, spending that time just defining the message structures out in IDA or Ghidra will yield pretty much the same result in terms of understanding.

What would really be crucial to getting full-ECU emulation going (i.e. being able to bring up a simulated ECU and talk to it over UDS) would be getting the timers and SRN (Service Request Nodes, basically PICs/interrupt routers) emulated, which would be a slightly more challenging undertaking since they're pretty complex.

I will say that static analysis becomes much harder on the newest TriCore based ECUs which have started doing things that have been common in the PC and mobile phone world for years, like code sections which are compressed and encrypted in flash and loaded at runtime. In these cases dynamic analysis is a really good tool - anyone who's ever done a packer in the PC world will know that the easiest way to deal with most of them is to just let them load themselves up and then dump the executable image from memory.

From what I know, hardware debugging can work on some production PCBs and not others, I have heard of it being possible on some older Bosch ECUs with a few extra components for example. But, without schematics and with the complex multilayer boards in use these days, I would think this would be quite a time sink to sound out the pins. With schematics it could be a viable option. And yes, using a bootstrap loader and a little stub debugger is also a very handy approach which I have been taking advantage of as well.

Another option you didn't mention is to use a TriCore development/debugging sample board with a close or matching CPU and the same sort of "jump through" debugging techniques around setting $pc and a breakpoint.

And as to your last point, yes, of course, I could just dump a commercial tool and have the exploit in seconds - if I actually had a need for it. But what I am trying to do is a hobby, not a need. I have been tuning my own personal car for a long time now, the tools I have already made work great for that, everything since then has just been for fun! Stealing an exploit would be much less fun for me, not to mention not particularly ethical in many senses, as I choose to share my work along the way.

As for my background, I am in software, but nothing related to low-level or ECU programming professionally (which is probably why I still enjoy it as a hobby). As a kid/teenager I reverse engineered game consoles in my spare time which is where I got into RE and analysis. ECUs today are just getting where game consoles were 10+ years ago in terms of low-level protections (although at the same time, ECUs are inherently more secure too since they don't take in a lot of crappy binary file formats to screw up at unpacking). One of my goals in sharing the knowledge I pick up, like running TriCore in QEMU, is to get more folks from that side of the world interested in ECUs too.

nevertheless, even if peripherals are not implemented, it's still useful, especially for the folks just starting out to dive into the assembly and ecu/tcu reverse engineering. Setting all the registers and initializing the RAM (especially the RAM) can save a lot of time and work understanding the ecu. OP and myself are not "need driven", he can tune his car with the tools he got, and I can tune my car with PCMFlash or just purchase an APR 3.0T tune which probably would have been the quickest and the most cost effective option. Seems to me, OP's goal is wider community education and just plain fun. This may not be a top priority for people doing this for a living but these are valid goals nevertheless. I think this can make it easier for some people to understand the tricore ecus.

I think it's just different perspectives here: from an application software developer's point of view (aka someone making useful stuff  ), emulation is mostly useless without peripherals (and even a dev board or bench ECU has limited utility). Since, in ASW development you are usually writing either patches to the generated logic in ASW (switching axes, adding conditions, bypassing sections of the model, etc.) or new UDS functionality. Those pieces of code can't really be well tested without the whole system brought up and playing together.

From an exploit/bootloader developers or curious researcher's point of view, emulation is extremely useful. For example, in SBOOT there is a table (ok not that huge, but like 20+ entries) of data that is used to initialize memory - each block in the table can be copied from one location to another, zeroed, or stored to registers. To set up the execution state of SBOOT in a static analysis tool, you'd have to either correctly reverse the functionality and write a script or painstakingly copy each memory block across by hand. With emulation, you can just jump through the segment and boom, RAM is set up how you want and you can dump it out and import it back into your tools.

Another good example is the Mersenne Twister Seed/Key algorithm in S18 SBOOT. Yes, it turns out the PRNG is just standard Mersenne Twister, but if you aren't experienced enough to see the MT algorithm and recognize it right away, no worries with a debugger - you can also just alter the seed value and run it through the algorithm running in emulation to generate a table of possible values for a given range of seeds.

Alright, I'm trying to play with this stuff, can compile qemu just fine but tricore-gdb compilation with fails with
after
there's an opcodes/tricore-dis.c file, there, though. Running on x86 Apple platform.

Thanks, that worked) I'll try to make a simos 8.4 qemu machine, can't try with simos 18 because I don't have an SBOOT for it.