As cool as it is, the main issue is that peripherals are not emulated.
So if you want to use anything to do with CAN you need to basically implement at least a part of the CAN controller in software.
Until that is done, there is not much use beyond it being a PoC. I do not believe static analysis on TriCore is THAT hard. Usually the structures used are fairly primitive.
It is also possible to run code on the ECU by dumping stuff in RAM and forcing the ECU to jump to it. There is also hardware debugging available, but I have never tried to see if it is possible to make it work on a production PCB.
Furthermore, for what you are trying to do, by far the easiest is to just sniff some tool that has service mode password reading implemented.
There is no need to re-invent something that's already been done.
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.