I have working KWP2000 init. Not difficult or impressive given how much info there is online about how to do this, even on this forum. But hey, it's progress.

I didn't realize how powerful binutils was, I've only really used it for checking sizes of sections. I'm using Rust (LLVM) but FFI makes gcc interfacing easy. I dislike .NET, at least it's usually easy to reverse engineer .NET apps...
Would still be interesting to write one from scratch.


Sure, but it sounds like what you are doing is closer to emulation than just pattern matching on assembly. Following going through the code while keeping track of registers, like the stack pointer and program counter, is getting awfully close to emulating the CPU. Ultimately emulating or simulating code can be a form of analysis on binaries.

In the end I don't know, or need to know, how you do it. I am just thinking about how I would do it. If uVision has a good ABI it could be interesting to use it for doing this.

I played with IDA a bit and was not a great experience. The c166 module for ghidra seemed to have some issues, likely user error because I did not spend much time playing with it.

Well I got my bench harness working properly, and immo deleted my unitronic ECU. Bench testing this is much nicer than doing it in the car... Now trying to figure out how to do the rest of the init after 5 baud and maybe read the DTCs.

For some reason the ECU seems to be stuck in session type 0x83, and replies a negatively anytime I send it something.

Wow thank you so much, that logic path is very helpful, I didn't even know about the security access.

I will try to implement all that. Also those two PDFs are incredibly helpful, and basically what I have been looking for. I found a single English one on google but it didn't go into specifics. Luckily my German is just good enough to understand these two.

Why Rust over Java/C++/anything else?

This can very quickly turn into a very very long paper. There is a lot of personal preference involved. I'll try to answer in a somewhat minimal way though. Also my C++ experience is incredibly minimal compared to Java, I learned Java before I was 10, and my C++ experience is mostly limited to reverse engineering device drivers... The one actual project I started in C++ wound up being redone in Rust very early on.

Java runs in a JVM, which is not conducive to running code on embedded hardware/microcontrollers. My goal for the flashing/logging portion of this project is that it could run on something like an ESP32 or one of my STM32 calculators. My choice of Rust over C++ is based on familiarity. The projects I was working on at the time I was starting to learn both were much simpler to implement in Rust, so I never bothered actually learning C++. On the other hand I learned Java before I was 10, and I don't really want to touch it again even after many many years of using it. Same goes for JavaScript and .NET.

As for why I personally prefer one over the other?
- I dislike dealing with the JVM.
- Rust does away with null values, you can have optional values
- I really like Rust's pattern matching functionality, it is incredibly powerful
- I haven't had a project that made me want to truly learn C++ (most of my learning time is spent on languages such as Haskell, Elixir, APL, FORTH) so I never became fluent in it
- Rust's borrow checker makes memory efficient programs very easy to write.
- The trait system in Rust is very flexible, instead of multiple layers of classes that inherit each other, you have a type that implements various functionalities.
- Rust has a very powerful macro system, much nicer (in my opinion) than the text replacement C++ does
- Java and especially C++ have subpar dependency/package management systems, Rust's cargo is incredibly powerful, and platform independant
- Rust has a very large library of "crates" (libraries) with very few compatibility issues
- The built in documentation functionality is easy to use
- Both the unit and integration test systems are very easy to use in Rust

This can be summarized as Rust is low-level, has amazing tooling that is standardized, it is memory safe and efficient, and finally, it is very easy to get setup on microcontrollers.

Update: thanks to the documents from Artemisia I have full KWP2000 encoding and decoding implemented. Communication with the ECU seems to work reliably and it responds to messages correctly. Now that I have a complete KWP2000 over K-line implementation I can start writing flashing and logging code. I will probably also try to implement what VCDS does.

Attached is a screenshot of the output when run with commit aa6f406. Code on github https://github.com/willemml/kwp2000-rs

worthless for ME7, slow and very limited. don't bother. Same with basic kwp logging, you really need direct memory access.

Got security access working. Wound up having to do the $23/$3B hack to disable the security fail timeout because otherwise debugging was too slow, wound up being a byte order issue...

Cannot get into programming mode for some reason though, but developer mode seems to work. Stuck with repeated response pending negative replies until eventual timeout (10 seconds).