|
|
willemml
Full Member
Karma: +10/-0
 Offline
Posts: 50
|
 |
« Reply #46 on: March 07, 2025, 05:16:16 PM »
|
|
|
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.
|
|
|
|
« Last Edit: March 07, 2025, 05:18:39 PM by willemml »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #47 on: March 07, 2025, 05:18:41 PM »
|
|
|
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. |
|
|
|
|
Logged
|
|
|
|
willemml
Full Member
Karma: +10/-0
Offline
Posts: 50
|
|
« Reply #48 on: March 07, 2025, 05:22:13 PM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
willemml
Full Member
Karma: +10/-0
Offline
Posts: 50
|
|
« Reply #49 on: March 07, 2025, 05:26:47 PM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
willemml
Full Member
Karma: +10/-0
Offline
Posts: 50
|
|
« Reply #50 on: March 08, 2025, 05:14:56 PM »
|
|
|
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 |
|
|
|
|
Logged
|
|
|
|
willemml
Full Member
Karma: +10/-0
Offline
Posts: 50
|
|
« Reply #51 on: March 08, 2025, 10:02:46 PM »
|
|
|
Got changing of timing parameters working, as well as proper reading by memory layout definition. Next up is writing, encryption, and checksuming.
|
|
|
|
|
Logged
|
|
|
|
willemml
Full Member
Karma: +10/-0
Offline
Posts: 50
|
|
« Reply #52 on: March 09, 2025, 12:50:49 AM »
|
|
|
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.)
|
|
|
|
« Last Edit: March 09, 2025, 01:05:26 AM by willemml »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #53 on: March 09, 2025, 10:48:50 AM »
|
|
|
And also I am running linux on aarch64 which will prevent me from using the me7logger library. That is just false, you can run the library even on ARM, and it can be done on Linux completely transparently via multiarch/qemu. |
|
|
|
|
Logged
|
|
|
|
willemml
Full Member
Karma: +10/-0
Offline
Posts: 50
|
|
« Reply #54 on: March 09, 2025, 11:06:03 AM »
|
|
|
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.
|
|
|
|
« Last Edit: March 09, 2025, 11:27:13 AM by willemml »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #55 on: March 09, 2025, 12:38:51 PM »
|
|
|
Sorry, I should have said inconvenient. 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  |
|
|
|
|
Logged
|
|
|
|
willemml
Full Member
Karma: +10/-0
Offline
Posts: 50
|
|
« Reply #56 on: March 09, 2025, 12:55:09 PM »
|
|
|
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.
|
|
|
|
« Last Edit: March 09, 2025, 12:58:45 PM by willemml »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #57 on: March 09, 2025, 01:08:44 PM »
|
|
|
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. 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. 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. 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. WBLI, and start routine by local identifier. Does not exist. it's just reading datasheets and other documentation. 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. |
|
|
|
« Last Edit: March 09, 2025, 01:10:46 PM by prj »
|
Logged
|
|
|
|
willemml
Full Member
Karma: +10/-0
Offline
Posts: 50
|
|
« Reply #58 on: March 09, 2025, 01:22:44 PM »
|
|
|
My disassembly toolkit is closed source No surprises there. So probably at least ME7Info you will have to run 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. DDLI does not work on many older bootrom ECU Good to know. I knew it was limited on older ones, but I didn't know it outright didn't exist on some. Does not exist. You are wrong. It's how NefMoto verifies flash checksums. I am already using it. remote code execution 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. |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #59 on: March 09, 2025, 03:31:07 PM »
|
|
|
Good to know. I knew it was limited on older ones, but I didn't know it outright didn't exist on some. It exists, but there is a bug in the code and it doesn't work. You are wrong. It's how NefMoto verifies flash checksums. I am already using it. Now you are mixing bootloader and asw. Overall it sounds like you don't want me to be doing this myself, or maybe I am misreading your tone. 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. |
|
|
|
|
Logged
|
|
|
|
|
