Pages: [1]
Author Topic: ST10VAR, Find variables in ME7.1.1 ST10F275 ECUs  (Read 705 times)
Artemisia
Full Member
***

Karma: +13/-0
Offline Offline

Posts: 59



« on: October 27, 2024, 12:53:14 PM »

ST10VAR for ME7.1.1 with ST10F275 processor
------------
The goal of ST10VAR is to find variables and their address by providing a readout of the processor content and/or the flash file

ST10VAR uses pre-defined patterns/signatures and evaluates the matches through basic statistics to determine the most plausible location for X variable. It is not as quick or efficient as ME7Info, although I do plan to optimize the way the application analyze the file to optimize the selection of possible signatures (Ex. Projekt and Programmstand detection). I will also be adding more signatures to cover more ECU if there is interest


How can this be useful?
------------
Retrieving variables (measurements) data can be used for advanced logging through R32Logger or to speed up code implementation (I still recommend doing proper disassembly and double-checking results, especially for critical application)

R32Logger link : http://nefariousmotorsports.com/forum/index.php?topic=19670.0


How to read the ECU
------------
Thanks to R32Dude for R32Logger, he has also shared ST10Ripper which allows reading both the processor and flash file by OBD2 (K-Line connection is required, pin 43)

ST10Ripper link: http://nefariousmotorsports.com/forum/index.php?topic=21785.0


How to use ST10VAR
------------
- Execute ST10VAR.exe

- Select either a processor or flash readout, ST10VAR will ask if you wish to load an additional file

- A list of found variables with their occurrences and a "certainty" ratio is output to the console. As well as the signature files that has been used to determine the address of the variable. (Prone to interpretation, ex. 1 occurrence and 100% certainty doesn't mean 100% trustable)

- At the end of the execution, ST10VAR will ask if you wish to save the variables (measurements). This will output an .ecu. You can pick the variables you wish to log through R32Logger

I recommend loading both the processor and flash as they work in pair and this will improve the detection


Limitations
------------
It doesn't detect bitwise variables such as boolean, ex: B_brems. Detection accuracy could be improved

If you require 99% precision, I would suggest to look into commercial solutions such as VehiCAL

VehiCAL link: https://www.vehical.net/products/logger/


If you encounter an issue or want more support, please feel free to leave a message with your software number. If you can provide a similar .a2l, it would also help to implement new patterns/signatures (Please attach a readout of your mpc and flash, as I might not have a .sgo that match your ECU)

This has been tested on 022906032LT and a few 07K906032 (BH, BK, S, T, R)


ST10VAR download link : https://mega.nz/folder/ZdVjkaoC#1s4SUQpR5aQLav81ewn4KQ


« Last Edit: October 27, 2024, 01:03:31 PM by Artemisia » Logged
prj
Hero Member
*****

Karma: +1069/-476
Offline Offline

Posts: 6011


« Reply #1 on: October 27, 2024, 07:24:29 PM »

You can parse the signal table like ME7Info parses.

The better approach is the one I am using which is via automated disassembly and matching all variables. Doing it via manual signatures is ... time consuming and inefficient, because you can just generate those on the fly.
Then if you have any somewhat similar a2l you can find the majority of the variables. It's also pretty much ECU agnostic.

The same algorithm works for any ECU, but you have to write a module for each processor type that translates instructions into an intermediate language/logic layer.

All in all huge job to get right/improve. If you need to do it manually just for a couple softwares you can get pretty good results using bindiff and loading stuff into Ghidra or IDA manually.
I have a bit larger scale so I have coded my own disassemblers for each ECU architecture...
Logged

PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
Artemisia
Full Member
***

Karma: +13/-0
Offline Offline

Posts: 59



« Reply #2 on: October 27, 2024, 10:35:20 PM »

You can parse the signal table like ME7Info parses.

I have never really looked into the inner working of ME7Info, although I have done some research based on this suggestion. Feel free to let me know if I got it right or if I am overcomplicating things

To parse the variables directly from the signal table (that would be the RAM table in %TKMWL if I understand correctly), I find the function that is responsible for creating that table by looking up for the code snippet that contains TKMWLNA, TKMWLNW, TKMWLMW:



From this, I gather the function is at 82AADE, and I can lookup for every call to that function in order. Then based on F0B9C, F0B9D, F0B9E and when 82AADE is called, I can determine what variable that is and its address

0: empty (first call to 82AADE)
1: nmot (second call)
2: rl (third call)
etc.

Example of second call to determine nmot


To be honest, I think this might be it, but I tend to overcomplicate thing and I feel you have a simpler / better approach up your sleeve. Fun part about that approach is that everything is on the flash, mpc readout wouldn't be needed anymore


The better approach is the one I am using which is via automated disassembly and matching all variables. Doing it via manual signatures is ... time consuming and inefficient, because you can just generate those on the fly.
Then if you have any somewhat similar a2l you can find the majority of the variables. It's also pretty much ECU agnostic.

The same algorithm works for any ECU, but you have to write a module for each processor type that translates instructions into an intermediate language/logic layer.

All in all huge job to get right/improve.

This is what I would do if I were to entertain commercial ventures for multiples ECU, but as you said, this requires a lot of work and I couldn't afford to spend that time on developing something like this. At this point, I am not looking to re-invent the wheel and it just makes more sense to support you. I am really appreciative of VehiCAL and I praise you for that, sincerely, impressive work prj!

I did it with manual signatures as it was something I could do over the weekend


If you need to do it manually just for a couple softwares you can get pretty good results using bindiff and loading stuff into Ghidra or IDA manually.
I have a bit larger scale so I have coded my own disassemblers for each ECU architecture...

For the moment, I load it into IDA and run a script that find and creates the signatures. Most of the time, it works well on C167/ST10 and I can get going. Not the same results on Tricore though. In all honesty, I am a bit lazy, I should definitely try out bindiff instead of doing everything manually
« Last Edit: October 27, 2024, 10:43:48 PM by Artemisia » Logged
prj
Hero Member
*****

Karma: +1069/-476
Offline Offline

Posts: 6011


« Reply #3 on: October 28, 2024, 02:10:28 AM »

To be honest, I think this might be it, but I tend to overcomplicate thing and I feel you have a simpler / better approach up your sleeve. Fun part about that approach is that everything is on the flash, mpc readout wouldn't be needed anymore
This is how ME7Info works.

Quote
I did it with manual signatures as it was something I could do over the weekend
The problem is that then you have a very limited number of variables available.

Quote
For the moment, I load it into IDA and run a script that find and creates the signatures. Most of the time, it works well on C167/ST10 and I can get going. Not the same results on Tricore though. In all honesty, I am a bit lazy, I should definitely try out bindiff instead of doing everything manually
If you are already loading it into IDA / Ghidra then bindiff is the way to go.
Logged

PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
R32Dude
Full Member
***

Karma: +45/-10
Offline Offline

Posts: 248



« Reply #4 on: October 28, 2024, 06:12:45 AM »

Great work Artemisia, this is the essential missing part of  R32Logger.
I gave up very early on as I found finding signatures way too much work ( I never knew of the 'signal table' prj mentioned).
I've improved the logger heaps BTW, it uses code prj released that is similar to one used in the me7logger for very fast acquisition of variables, can log over 200 variables at once and can operate at 100 readings per second (depending on the number of variables) .The caveat is that I slacked off this time and didn't make it universal, it just works on the CE version, which is what is in my car. I haven't shared it as its too specific and Vehical can now do ST10 anyway.
Very grateful for all the info shared on this forum, especially by prj and other knowledgeable people.
Logged
prj
Hero Member
*****

Karma: +1069/-476
Offline Offline

Posts: 6011


« Reply #5 on: October 28, 2024, 06:16:45 AM »

Making it universal is the hard part unfortunately.

I don't use the me7logger method on ST10, I do the $2C exploit because it's the same on all newer ECU's.
The $2C method does not work on some older ECU's because they have a bug in the $2C handler, so there the me7logger method is required that is detailed now on my github.
Logged

PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
Artemisia
Full Member
***

Karma: +13/-0
Offline Offline

Posts: 59



« Reply #6 on: October 28, 2024, 04:57:23 PM »

Great work Artemisia, this is the essential missing part of  R32Logger.
I gave up very early on as I found finding signatures way too much work ( I never knew of the 'signal table' prj mentioned).
I've improved the logger heaps BTW, it uses code prj released that is similar to one used in the me7logger for very fast acquisition of variables, can log over 200 variables at once and can operate at 100 readings per second (depending on the number of variables) .The caveat is that I slacked off this time and didn't make it universal, it just works on the CE version, which is what is in my car. I haven't shared it as its too specific and Vehical can now do ST10 anyway.
Very grateful for all the info shared on this forum, especially by prj and other knowledgeable people.

I am mainly making this to makes R32Logger a reliable solution for enthusiast and for porting code quicker from one firmware to another. I also didn't think of using it prior to yesterday. I was aware of such table in MED17 as I have been using it for conversion factor on a CAN project I was working on, but I never thought on using it to find variables

Once I get more time, I will redo everything and make a table parser instead. It will be more efficient, and it will provide more variables as prj mentioned. For the moment, it gives most common variables that would likely be logged on most setups that run ME7.1.1

For your new version of R32Logger, are you using a custom service handler? I could look to create functions to dynamically creates it. I often use R32Logger for diagnostics, if I can somehow help to improve it, I would be happy to help
Logged
prj
Hero Member
*****

Karma: +1069/-476
Offline Offline

Posts: 6011


« Reply #7 on: October 29, 2024, 12:45:00 AM »

Just do the $2C exploit, then the only thing you need to find dynamically is the location of the DID table in RAM, which is trivial.

It's same speed as the handler. Uses a bit more CPU cycles, but on a ST10 it doesn't matter.
Logged

PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
R32Dude
Full Member
***

Karma: +45/-10
Offline Offline

Posts: 248



« Reply #8 on: October 29, 2024, 06:19:32 AM »

For your new version of R32Logger, are you using a custom service handler? I could look to create functions to dynamically creates it. I often use R32Logger for diagnostics, if I can somehow help to improve it, I would be happy to help

You are very welcome to improve the R32LOGGER as you wish!! VB6 is outdated and some of the methods I used back then can be improved immensely.
 I'm not a coder, I did play with Turbo Basic and Pascal in the 80s and when windows 3.1 took over VB3. I didn't know a thing about how ECUs in cars worked and didn't understand (still don't much of the time) what was being said on here but after many months of reading, much trial and error, one step at a time I miraculously  got it done and could finally log the car.  The 'breakthrough'  was in discovering how to write to RAM, since the usual service is blocked. Overall a massive job for me but Setzi could have done it overnight I bet!
In version 2 ,  I no longer use the flash RAM, but the a segment in the processor RAM, which is never used in the ECU code. It does use a  custom service, as detailed here:
 https://github.com/prj/me7log
But I skip a step or two, as I copy over my own modified service table and, in the process, made it specific for the CE version.  It connects at a much faster baud (89k from memory).  Its got a few other improvements but I'm beginning to forget. Version 1 is rough but after making v2, I find that v1 still did the job.
Not sure what the DID table is, haven't come across it before.
Logged
prj
Hero Member
*****

Karma: +1069/-476
Offline Offline

Posts: 6011


« Reply #9 on: October 29, 2024, 07:24:35 AM »

Have a look at this thread:
http://nefariousmotorsports.com/forum/index.php?topic=271.0title=

There's a table that you can dynamically define identifiers in - $2C service. It normally supports 3 or 10 values.
But you can just write the ram and redirect it to somewhere else and log 100 values if you want by defining the data directly instead of using the service to do it for you.
The service doesn't care how many entries are in the table.

So all you need to find is the location of this table, change the pointer and off you go...
Logged

PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
R32Dude
Full Member
***

Karma: +45/-10
Offline Offline

Posts: 248



« Reply #10 on: October 30, 2024, 05:08:49 AM »

Have a look at this thread:
http://nefariousmotorsports.com/forum/index.php?topic=271.0title=

There's a table that you can dynamically define identifiers in - $2C service. It normally supports 3 or 10 values.
But you can just write the ram and redirect it to somewhere else and log 100 values if you want by defining the data directly instead of using the service to do it for you.
The service doesn't care how many entries are in the table.

So all you need to find is the location of this table, change the pointer and off you go...

Ahh, yes, that's the method I used.
Logged
prj
Hero Member
*****

Karma: +1069/-476
Offline Offline

Posts: 6011


« Reply #11 on: October 30, 2024, 06:36:17 AM »

Ahh, yes, that's the method I used.

The method on the github is completely different.
Btw, if you use the github service injection method you can fix the double baud rate function call bug in the firmware and set the baud to e.g. 115200 or any other number.
I do that on Porsche ME7.8, because there you can't change baud rate without a patch anyway.

Also because the github method is a code execution exploit, then on a non-bricked ECU it is possible to use this method to inject a loader into the ECU and then use it to reflash the ECU at very high speed without opening it or caring about the immobilizer.
It also allows to bypass the immobilizer and do a number of other shenanigans.
« Last Edit: October 30, 2024, 06:38:35 AM by prj » Logged

PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.053 seconds with 15 queries. (Pretty URLs adds 0.001s, 0q)