NefMoto

Hey there!

While I wait for a spare ECU and some bench flashing hardware to arrive so I can start actually tuning, I played around with TunerPro in a VM a bit.

Anyways, I didn't like that I had to use windows to do the tuning and view diffs between tunes while reading the community projects (trying to learn what is being changed and why).
So I decided to write my own tuning software that works on all platforms. Currently all it does is load a bin, an XDF, and then display all the maps. It does have the ability to write bins, but there isn't a button for that (yet).
Currently it runs purely in the terminal, which is nice for me as it's a purely keyboard based UI.

All in all, its a very very WIP piece of software, and as such I am not distributing any executables, but it is there and in active development, I plan on adding built in checksumming, and possibly built in flashing (hopefully both bootmode and kwp2000). The goal is to make a very simple open source (and more importantly, multi platform) package for tuning Bosch's ME7 ECUs.

For now I have called it "HEXTuner" (I happened to have a hex editor opened) and the source is available on GitHub here (https://github.com/willemml/hextuner/tree/master)

It turns out that displaying large tables in a terminal window gets a bit confusing and unruly. So I have switched to a graphical interface. Editing doesn't work yet but tables can be displayed.

There is now a fully functional GUI, it isn't pretty but it allows tiling editing windows (tables/scalars) and editing/writing to bins now works.

Added some rudimentary support for getting categories from XDF files and displaying them. Does not work well with nested categories (un-nests them).

I am probably going to create my own file format and have a built in converter for XDFs. This will eliminate most of the road blocks I've been running into. Unfortunately the XDF format seems to be very hacky (though I dislike XML/heavily generic data structures given my primarily embedded background, so I am biased) and a lot of things seem like they were an afterthought.

Also I will try to remove axis definitions, I already support editing axis directly from an opened table, so having the extra tables makes little sense.

Also added in file pickers, so the bin/xdf paths aren't hard coded.

Cool, project. Have not had the chance to look into it but by the sounds of it you are keeping up on the project, nice job.

Thanks. It is a fun project, and I get to look forward to eventually not needing to use my windows laptop at all. KWP flashing will be interesting when I get around to it. Gives me something easy to do in between tweaking my tune and trying to learn how ME7 works. Once I have a better understanding of tuning I'll probably move on to writing my own assembly patches, which should be much easier as I already have a strong understanding of low level computing (having written several instruction sets/architectures of my own). It would be nice to give myself some more room in some of the maps just as a starter project.

Hopefully other people will find it useful when its more mature, although I do not recommend using it right now, while everything does work, it's very clunky and lacks some important QoL features (like mass editing cells, comparing bins, graphing...)

Next up I will be adding graphs though.

Love what you are trying to do here.... a standalone linux based kwp flasher would be amazing... or an open source version of me7logger than can run on say, a pi

That is the end goal, most development is happening from an arm64 MacBook running Linux. I eventually want to get kwp flashing and logging from something embedded like an ESP32. Once I figure out how kwp works over serial with these vag kkl cables I'm sure it will be fairly straightforward.

My next step is to assemble the bench harness I got parts for and then flash the stock software to my unitronic ECU so I don't have to worry about any oddities with that. I don't have much use for the unitronic software anymore anyways, my own tune seems to run noticeably (hesitant to say much) smoother even with my very minimal knowledge from a couple weeks reading this forum and the wiki. Glad the PO payed for the OTS tune and not me.
Once I have the bench setup I'll be able to iterate pretty quickly with flashing/logging implementations.

Also, I added graphing capabilities earlier this evening before I went and messed with the load tables in my car. I haven't actually pushed the code yet though. I will probably do that tomorrow after some cleanup.

A lot of this wouldn't be possible in such short amounts of time without the amazing amount of libraries people have made for rust. A lot of things (like the graphing) are turned into an exercise of reading documentation instead of designing and implementing entire packages. This is just to say that I can't take credit for everything.

Well I was planning on testing some KWP2000 stuff tonight, that might have to wait. I put together the bench harness, but wired everything upside down! That's a bit embarrassing... Oh well. Might have killed the ECU, will put it in the car when I get a chance to see if I actually killed it or if I just have the harness wired wrong still. Hoping it's the latter so I don't "have" to buy a third. I could do all of this in the car, but it would be much nicer to be able to do the development from my desk.

ECU is fine, something wrong with the harness. Probably missed something in all the guides I read...

Question 1: so while I am heavily leaning towards designing my own open file format for map definitions, does anybody have recommendations of existing open formats to consider? Even if I don't use it directly I may write a converter so this app can use it.

Question 2: how does ME7Info actually work? If I write a logger I would want to implement its functionality.

Also for now I am avoiding reading any GPL code, as my goal is to release this as MIT or BSD0, but that may change if/when I make a final decision on licensing and well I progress without looking at the existing projects like the Nefmoto flasher. Ultimately I don't really care what the license is, but it would be nice if it were truly free.

XDF is the defacto "open" standard but it is cumbersome and has issues. ecuxplot has a kp->xdf converter you can look at as a reference if you like.

KP is totally useless. Binary blobs, proprietary, closed, opaque. Total garbage. I detest companies like EVC who show zero interest in anything but their own bottom line.


Combination of disassembly and pattern matching. prj has written a much much better tool... dont have the link handy


meh, im the defacto "owner" of the flasher. I am considering a license shift since the author has mostly abdicated it to me. Let me know if you feel like there cleanroom implementation problems (from a license standpoint). I'm sure we can work something out trivially.

ME7Info works by parsing the structure defined in TKMWL.
Tool I wrote for pattern matching was an idea, but it's quite useless tbh, as you needed to define patterns in xml.

Internally these days I have something much better.
It can take any C166/ST10/PowerPC/TriCore binary, automatically detect the code areas and registers.
It can then disassemble it in-process, and with a bunch of clever algos and false positive rejection go through the code on a known and unknown binary and match all the memory accesses.
It tracks subroutines, calls, jumps, registers, copies between registers and so on.

This is the basis of being able to provide the Logger advanced service, because it is impossible to have the exact A2L for every file.
Been working on it for years. Unfortunately I don't think I can ever opensource it nor does it find maps, because I never intended for it to do that (I just work with measurements).

As shown in the screenshot, this takes just 4 seconds on ME7 on my mid tier laptop.

Alternative when you have a lot more time, is to use bindiff in Ghidra or Ida. It can also do a lot for finding symbols between files.
This of course takes much longer, as you have to load every binary correctly and process it. So what takes my tool under 30 seconds can easily take an hour using this method.
Good if you need to get the addresses for one car, but not viable commercially.

I've always wanted to write a disassembler. At least I won't be short of projects for a while. I really just need to write the KWP flasher and logger. I will just use ecu files from ME7Info. For now at least.

prj: it sounds like you wrote an automated C166 emulator/debugger combo.

I wonder if I could do some analysis knowing what input/output pins do what and then I would know which subroutines read/write the corresponding registers. Then using the FR to find out what functions use what I could probably map each function to a group of linked subroutines that access the required info... Much easier said than done of course, and I am dumbing it down from the full idea. Finding execution patterns would probably be easier than finding relevant IO access. Anyways, both require writing what would effectively be a disassembler and emulator.

Good to know about the formats. I will just create a documented format of my own. Probably using TOML. XDF has been hard to find documentation for.

nyet: I'll let you know how I fare in my "cleanroom" flasher implementation.

I'm saying you don't have to :) nobody is going to sue you

Ahhh I misunderstood. Thanks :)

Pushed the graphing capability. It is broken for 3D maps. I'll fix that soon. I have not yet implemented editing values by dragging graph points, but that is a future planned feature. Again, this is an extremely rough proof of concept.

Values are rounded to a detected precision, the code figures out how any decimal places can be reliably stored and then adds one, and rounds everything to that. This is done in a somewhat hacky way, but it works, and also removes the requirement for specifying decimal places in a definition file.

Screenshot from the readme attached.

Edit: I just noticed that I forgot to actually set values for the axis labels on graphs, it seems to be using arbitrary ranges... whoops

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.

For a lot of disassembly you can use binutils. Takes a ton of massaging to bind it to .NET, but if you're using straight gcc then should be easier.
Emulator/debugger already exists, it's called Keil uVision.

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.

I would not call it emulation, but there is a certain intermediate layer that understands some of the program flow.

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.

Hope this documentation helps. For flash programming, the logic path would be something like that:

- Start diagnostic session 0x85
- Evaluate response
- If ECU responds that security access haven't been granted yet: Request security access with access mode 1 (requestSeed)
- Use the SA2 instruction tape to solve the seed and send the response to the ECU. Re-try session 0x85 once security access is granted

The SA2 instruction tape can be retrieved in .sgo files. Often the same for similar controllers

Flashing segments:
- RequestDownload
- StartRoutine 0xC4 (Erase flash)
- RequestRoutineResult until positive response
- TransferData
- Checksum

Before flashing a segment, the data needs to be compressed using Bosch BCB Type 1 compression.
The compression use a flag to indicate if the byte doesn't repeat or if it repeats and how many times. Then the compressed data needs to be encrypted, it uses XOR encryption with the following key: GEHEIM (literary "SECRET" in German). A header needs to be added to the encrypted segment to let the ECU know this is compressed/encrypted data (0x1A 0x1 IIRC)

Checksum is done on the raw data segment using CRC32B, you send the last two bytes

Once all segments have been downloaded, StopDiagnosticSession.


Off-topic, I saw you have worked with Java and C++. What do you prefer from Rust over those two languages? I am seeing more interest and have been contemplating fiddling with it

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.

Interesting project.

I like C# for a GUI.

There are so many styles to write C++, but I really appreciate std::map, std::vector, std::string, std::find etc in microcontrollers with a heap. C99 with no heap for an ECU.

I suspect I'm a candidate for becoming a Rust lover, but I'm juggling JS, Python, assembler, C#, C99, C++, PHP and a few other scripting methods plus more I'm forgetting already. I only use what is necessary to cover the paradigms from various servers and serverless services down to ECUs, but it has evolved over time of course.

I dislike Java too.

IDA and bindiff work for hundreds of versions in production with automation for characteristics, measurements, function and hooking various of them, but I have a love/hate relationship with it and it benefits from combining with pattern matching of data in addition to its function matching strategies. The old versions of IDA needed IDC scripts to properly resolve flash accesses in particular, and there are breaking changes that have prevented me upgrading as well as incompatibilities with bindiff. IDC can fly along well, but it is certainly quicker to develop with IDA python though. Ghidra I like, but it is just deathly slow... Java related presumably.

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

Thanks! It's been very fun so far. Lots of learning.


Never tried it, I tend to avoid C# because of the heavy windows relationship. I have written some simple .NET to break the DRM on some game music, but other than that nothing.


I think you will enjoy Rust, especially given your favourite parts of C++. I used to write a lot of JS, I still write some Python at work (I don't work in software, but Python is helpful for data translation and some CAD stuff). My main experience with assembly is writing my own architectures/instruction sets for fun. PHP is the first language I ever learned, but I haven't touched it since I learned Java, so I wouldn't even know where to start anymore.

Side note, I have been writing my code for the kwp2000 project in such a way that it is only a couple lines to change it from heap based to heapless. And I have been trying to minimize copy operations. This code should work very nicely on microcontrollers.

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

I mean the coding, adaptation, and basic settings functionality. I know VCDS logging is useless, but it would be nice to have a free alternative for VAGCOM. The primary targets of this project are DMA logging and bin flashing. VCDS features are just extra because there is no free competition with that software that I know of.

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).

Is it stuck on the first StartDiagnosticSession 0x85 or after the seed has been resolved? I haven't worked with KWP2000 ECUs, but on some TP2.0 ECU, the following does the trick:

- Once the seed is resolved, let the connection time out
- Once disconnected, re-init the KWP2000 connection
- *You can either try to go straight to RequestDownload or try StartDiagnosticSession 0x85, then RequestDownload

It might be possible the ECU only allow a programming session on specific timing parameters. You could also use ODIS-E to flash a SGO and sniff the communication line. You would get the full payload to handle flash programming


For the SA2 implementation, it seems you are using this one:
0x68,0x05,0x81,0x4A,0x05,0x87,0x5F,0xBD,0x5D,0xBD,0x49,0x4C
(Loop 5 times: rotate shift left (RSL), if carry is clear - skip XOR, XOR 0x5FBD5DBD)

If you plan to expand to more ECU in the future, it could be interesting to do a full implementation. Although, I think most, if not all ME7, uses the same one

    *Removed code suggestion

Great work so far, love to see the frequent updates and a Rust project I can keep up with. Very interesting language

I gets stuck on StartDiagnosticSession, I get a positive response from sending the seed solution. I am wondering if this is maybe because I am starting an 0x89 diagnostic session before I send the seed (so I can use DDLI/WBLI). I'll try your suggestions as well as look into timing. Maybe I will build a sniffer, I have a lot of usb serial cables, and my software should even work with CH340...


Ideally this will support as many ECUs as possible. Once I have a fully functional program for my car's 518AK I will start looking into widening compatibility. I am trying to make the code as generic as possible.

While the change you made to the code makes sense, it doesn't actually work. This is because it affects the result of the if statement.


Thanks! I'll keep up with the updates, good to know they are appreciated.

After the DDLI, you could close the connection, start a new connection into a 0x85 session, solve the seed, start session 0x85. On TP2.0, if I solved the seed on a 0x89 session, I close the communication and restart on 0x85


Totally understandable and apologies for the mistake, I feel foolish for thinking the u32 would preserve the carry after the shift :-[

Have tried that. Re-init works, but I still get the RequestPending (eventually it stops sending that and doesn't send any data at all).
After spending the first half of my morning playing around with that I decided to start writing a much more friendly API for interacting with KWP2000.
It's still a bit messy because I am doing everything in a loop (so order isn't obvious) but that will be fixed soon too.


Haha, to be fair, I did spend a good 15 minutes trying to figure out why your change didn't work  :)

It may be worth mentioning that some tools have a problem finishing the flashing session on the later me7.5 ecus, its not all that common but I have had it happen to me in the past. The end result is the ecu is stuck in programing mode. Normally doing a read again will close the session properly. There is a patch floating around on the forum that fixes this problem too.

Good to know, thanks. I should check that I didn't leave it in programming mode after I cancelled a flash read in Nefmoto. Once I got the bench harness working I boot mode flashed a stock file (the one from the 1.8t community thread) and then used the nef flasher to make sure the ECU was responding to kwp2000. I'll try doing a full readback and proper disconnect like this post (http://nefariousmotorsports.com/forum/index.php?topic=981.msg17325#msg17325) says.

Reason for re-flash is that I have no idea what the previous tuners (used car, previous owner got a Unitronic tune) did but I know that they disabled reading over KWP2000... Made a backup of the tune for good measure, but my DIY noob tune already seems to be running much smoother than the OTS file (though slightly less peak load, but that seems safer...)  Maybe one day I'll map that bin and compare their changes with mine.

I can almost guarantee you that

1) anything you DIY is likely better than ANY tuner OTS. period
2) there is nothing you can learn from an OTS tune. don't bother. Do your own thing, you are on the right track.

I don't doubt #1, given I am actually using logs of my own car. I am curious as to why the OTS tune idles rough (had no idea it was bad until I flashed a stock file, never been in a 1.8T other than my own) and partial throttle is so jerky. I can guess knowing what I do now, but it would still be nice to see what it actually is. Anyways, not going to bother doing that unless I truly get bored, which will be a long ways out given the two software projects I've got going on now.

Makes sense. Just remember this: just about everything "professional" large scale tuners do is a hackjob, because they're trying to cover a ton of different ECUs from multiple platforms all at once.

What does this mean? Generally, anything that you find in an OTS, learn from in the sense of "don't do this" :)

I learned the hard way, by assuming stuff that didn't make sense to me somehow made sense to a "professional". This is rarely the case, in reality.

Well you were right. Even the nefmoto flasher fails to connect with a programming session, exact same issue (tries, then times out). I'm a little pissed at myself for not trying this sooner, that's a lot of wasted debug hours. Oh well, so it goes with projects like this.

Edit: not actually sure what nameless mentioned is the exact issue anymore, but the nefmoto flasher does have the same issue as me.
Edit 2: seems the nef flasher successfully gets security access sometimes, but then when it tries to do a read the ECU reports that it doesn't have security access. I wonder if these issues are because of my DDLI security timeout hack.


That's really good to know before jumping in, thank you :)
I do forget sometimes that professional just means paid, not better.

I believe this is what nameless is referencing to:
http://nefariousmotorsports.com/forum/index.php?topic=6719.0

I don't think this would be your issue. From experience, it would only prevent an engine start, but not getting into 0x85. Do you have 12v on pin 121? Some 1.8T ECUs needs 12v on pin 121 for flash programming

That was the solution (which I eventually figured out when I saw only half my bench harness was plugged in).  I am now in diagnostics mode. I actually had to do a bootmode flash as well, and nefmoto still doesnt work. But at least my kwp2000 works!

Great to hear! Things should go very quick from there, TransferData and the compression will likely be the worst part

Wanted to get my API looking nice before I started to work on the programming functions. Now everything is abstracted away to simple function calls instead of a messy loop. This API will undergo a lot of changes later on, but the way it is now makes it easy to do quick development.

Fixed 3D graphing in the tuning software.

I've been messing with the TransferData service to try and read flash, so far I think I am running into issues with my failed attempts locking me out. Need to make the testing process faster/easier.

Rudimentary flash reading in programming mode works now.

If you want to add logging to the thing.

Some options:
a) Do it yourself. Here's the RCE exploit: https://github.com/prj/me7log (https://github.com/prj/me7log)
b) Integrate my logger. You can use this (a little strange) API to mimic WinOLS and remote control the logger: https://www.evc.de/en/product/ols/visualizer.asp (https://www.evc.de/en/product/ols/visualizer.asp)

Logging is the goal as soon as flashing works. I will then likely add it to the tuning software UI for an all in one solution so I can finally stop using my windows laptop.

From what I can tell your logger is windows only, and requires networked auth and stuff? Didn't look into it much  because of the account requirement.
Anyways, that defeats the point for this library as I want it to run on Linux, Unix (macOS), and micro-controllers. Another goal is no proprietary dependencies whatsoever.

I'll probably do it myself. I'll check out your repo.

Might finish the flashing part tonight, but maybe not, I was planning to learn PID, and maybe try to follow your PID feed forward hack.

Yes, Windows only and networked.
Because it's a commercial application :)

ME7logger has a Linux library. Probably the easiest way for you.
Not open source but without that you're really going to struggle.

It's too bad so many things are tied to windows, but hey, at least they exist...

Worth figuring it out myself if I can log via ESP32 or something though. And also  I am running linux on aarch64 which will prevent me from using the me7logger library.

Am I correct in assuming that DDLI is too slow for useful logging? The only way I can think of getting around that is somehow getting my own code into the ECU RAM that copies the desired data into a continuous section of RAM or something. Definitely not going to be easy. Or go even crazier and implement a custom serial protocol. Too much effort probably.

Someone on Audizine asked me to post a compiled binary of HEXTuner for windows. Figured I might as well post it here as well.
Keep in mind this is a super rough preview version, 3D graphing sort of works but will cause a crash if the window is too small.

It is much easier to compile if you are already using linux/macOS, and my primary dev machine is aarch64 linux, which I doubt many have, hence only posting the windows binary...

https://files.willemml.net/files/software/hextuner/hextuner-preview-edc5f80.exe

Got changing of timing parameters working, as well as proper reading by memory layout definition. Next up is writing, encryption, and checksuming.

Successfully wrote a bin. Just need to do code cleanup now. (And then create a UI of some sort, probably a CLI until I add checksum capabilities to HEXTuner.)

That is just false, you can run the library even on ARM, and it can be done on Linux completely transparently via multiarch/qemu.

Sorry, I should have said inconvenient. There are even things like box64 and FEX-Emu. If that's the route I were going wouldn't be bothering with any of this. Remember a primary goal of this (especially the logger part) is that it will run on micro-controllers.

So yes you can, but it's ultimately not relevant to this specific project.

Don't know what distro you are running, on debian it's a single apt command.

If you just want to make it work on your own ECU (like others have here), you can just sniff the ME7Logger data and replay it. Good luck with all the different bootrom variants though. Going to have to do some real reverse for that and not easy mode stuff ;)

Sure, qemu is easy to setup, as is the x86 translation layer. But it's still another layer of stuff.
Also why even bother doing any of this if in the end I am just making yet another frontend for me7logger...

I'd rather not just replay data, so I guess the true RE will have to be the way to go since apparently this super secret method is not documented publicly.
I guess I am mostly just writing this for my own convenience, I don't expect anyone else will actually want to use it given the heavy windows prevalence. So there is no reason to support other ECUs. But it seems like fun, which is the entire reason I am doing any of this stuff, it's something interesting to do and learn about.
I could also just not post about this at all or publish code, but seems nice to give back even if all I'm doing is reinventing the wheel, other perspectives can be useful.

My actual plan was to do some combo of DDLI, WBLI, and start routine by local identifier. Write some sort of assembly code to dump specified addresses in a single message.

I know that the logging part of this will be much harder, I mean, so far there hasn't been anything difficult it's just tedious debugging. If you have even a basic understanding of serial communications non of this is even remotely complicated, it's just reading datasheets and other documentation.

Yeah you will have to create masks for all the bootroms to find the vars. My disassembly toolkit is closed source, so not going to happen. But I did opensource the exploit and the asm code.

Also if you want to get variable lists without ME7Logger for every ECU version, good luck with that. So probably at least ME7Info you will have to run. Otherwise you will spend around half a year developing just that if you want to support a lot of different variants.
DDLI does not work on many older bootrom ECU's at all, that is why the RCE exploit was used. On those where it does work it is limited to 1 variable in memory mode.
Does not exist.
Proper logging on these is not possible according to datasheets or documentation. It's an exploit with remote code execution and rewriting the internal comms stack on the fly in asm. On newer bootroms with functional DDLI you can hijack the DDLI data structures, again through an exploit.
The only thing you can do without hacks is $23 and that's very slow. With 10 variables you're looking at 5hz.

No surprises there.

I'm fine with that, it's not a runtime dependency. Although it would be cool to write that tooling myself. I have time, and half a year is not much.

Good to know. I knew it was limited on older ones, but I didn't know it outright didn't exist on some.

You are wrong. It's how NefMoto verifies flash checksums. I am already using it.

Which is exactly what I am talking about doing.

Overall it sounds like you don't want me to be doing this myself, or maybe I am misreading your tone.

It exists, but there is a bug in the code and it doesn't work.
Now you are mixing bootloader and asw.
The learning curve is pretty steep here, let's see what you manage to do.
Let's just say it's more difficult than what you have done until now combined, but of course I don't know your level.

And as said before - doing it for one bootrom/software is very simple, the hard part is making code that works on everything.

If you want to make something like ME7Info, I can provide some insight on finding and parsing the signal table. I fiddled with it for the ST10 after prj mentioned that. There is a lot of work involved depending on how many variables you would like to support, it would be a good addition to your software based on your end goal.

Personally, I looked into the signal table parsing for R&D in hopes to save time in the long run, I was 100% wrong. Might be simpler on older C167, but prj's approach totally makes more sense in all aspects for finding measurments / variables



It uses a pre-supported routine (0xC5), but if you want to write a custom function and then call it on runtime, it won't work with StartRoutineByLocalIdentifier

Prj has shared detailed information about his RCE exploit on his repo: https://github.com/prj/me7log

Definitely curious.


This is definitely the route I am most interested in, I have been idly poking at it every now and then.


Ah I see, so it does exist, it just won't be useful to me.

I am considering giving that a shot, but it would be nice to have the satisfaction of figuring it out myself.

No, you thought that you can just write random code into RAM in ASW and execute it via those commands.
So for all intents and purposes what you described does not exist.

One step ahead of you, have been doing this for a while too, you know? ;)

WriteMemoryByAddress works on earlier ECU's, and you need to make the ECU jump to your code by using that.
On newer ECU's that's closed as well, but on those DDLI and WBLI works. Some need security access, especially for speed switching, sometimes that access is blocked on a huge timer, which you have to bypass with another exploit. Or you can call the set baud directly from your code... etc...
As I said, more difficult than all the shit you've done until now combined. I know because I've done it all.

The signal table refer to the %TKMWL Testerkommunikation; Meßwerte lesen

(https://i.imgur.com/SvaFK8j.png)

To create your initial signature / pattern to find the table, I look where TKMWLMW is being used. Then I can see the function that push the measurement value to the table

(https://i.imgur.com/YZdoImh.png)

I named it for PUSH_TO_TABLE. By looking at the first reference to this function, you can find the function that compute this table.

(https://i.imgur.com/NOhrpey.png)

That function looks very similar for all ME7 and even the MED9 (of course different instruction set). You can now identify NA_nr, NORMWERT and the variable that hold the value of the measurement

Under the Jump indirect, you can find your signal table

(https://i.imgur.com/h3KP602.png)

I added some comments, but it is self-explanatory. When a Nr get skipped, it is being processed in the same location (dual-bank system, etc)


If you work on one engine or very similar controller, you could make a script that identify the location of your signal table, then parse it and use signatures to identify your RAM locations. I think this would be the shortest path to achieve what you want

There are surely other ideas out there. Personally, I was looking into making an interpreter for C166 instructions that would go through the function to properly find variables and their RAM location. This way it would support all ME7

This code is also stored into the AM29F800 on the ST10 ECUs which make it convenient as no readout of the processor is required

Those are rough explanations, I am not that great to explain stuff. I hope this helps

Unrelated, but it might also interest you. For reading ECU that are "locked", you can use the checksum routine to map the whole file. There are clever ways to optimize it and have quick readouts as well

As long as WMBA/DDLI/WBLI are not locked you can just inject the RCE payload and read whatever you want.