elias
Full Member
Karma: +20/-3
 Offline
Posts: 65
|
 |
« on: June 20, 2023, 01:04:04 PM »
|
|
|
Hello i am proudly release the first version of my MED9Toolchain, which is basically a framework for writing code patches for MED9: https://github.com/EliasKotlyar/MED9ToolchainIt took me a bit to get there, but now i hope that it can teach someone else in this community, as User "Basano" did for me. Most important section would be the FAQ, where the whole process is described: https://github.com/EliasKotlyar/MED9Toolchain/blob/master/FAQ.mdIts basically a Framework for code-changes, and i am really wondering why such things were not released to the public in the past. It can be easily adapted to any other ECU, without rewriting much. A small bonus Feature: It includes a sample "patch" for "mapswitch using cruise control" (LDRXN Table only) into almost any MED9.1 binary. Its not intended to work properly, its more a "proof of concept". PS: Feel free to add new signatures/patches as MR. |
|
|
|
|
Logged
|
|
|
|
toxictuning
Newbie
Karma: +0/-0
Offline
Posts: 4
|
|
« Reply #1 on: June 27, 2023, 07:16:57 AM »
|
|
|
Hi Elias!
Seems to be a good concept!
going to give this a go!
|
|
|
|
|
Logged
|
|
|
|
d3irb
Full Member
Karma: +134/-1
Offline
Posts: 195
|
|
« Reply #2 on: June 27, 2023, 11:41:07 AM »
|
|
|
i am really wondering why such things were not released to the public in the past.
Follow the dollars, and get ready for the flood of clueless "professionals" asking for handholding and stealing your work  This is great work, nicely done. Adding a little disassembler phase on the front can really help to find locations in more complex situations also, versus just matching "needle" bytes. |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #3 on: June 27, 2023, 04:00:06 PM »
|
|
|
IMO this is a lot of code for something very simple.
I also don't think recompiling every time makes much sense, because the only thing that changes are addresses, and you already need to splice in the jumps.
I insert placeholders into patches and use programmatic asm to replace the address accesses, and then match the needles in binaries usually via just bytemasks...
|
|
|
|
|
Logged
|
|
|
|
nihalot
Full Member
Karma: +41/-3
Offline
Posts: 117
|
|
« Reply #4 on: June 27, 2023, 11:27:34 PM »
|
|
|
with ghidra you can statically find out exact registers which are free at any point you want to hook in a patch, and compile your code to use those only
with MG1 getting updates every few weeks, registers keep moving around, so a precompiled patch which doesnt inspect used regs in a routine becomes redundant quite quickly
|
|
|
|
|
Logged
|
www.tangentmotorsport.commultimap/LC/rolling antilag for MG1/MED17/EDC17/MED9/EDC15 contact for reverse engineering services of any ECU/TCU
|
|
|
|
prj
|
|
« Reply #5 on: June 28, 2023, 03:07:28 AM »
|
|
|
with ghidra you can statically find out exact registers which are free at any point you want to hook in a patch, and compile your code to use those only
with MG1 getting updates every few weeks, registers keep moving around, so a precompiled patch which doesnt inspect used regs in a routine becomes redundant quite quickly
This is taken care of by using code that does not clobber registers and picking insertion points with knowledge of the EABI. Upper context is saved on call, lower context can be saved and restored manually. Never an issue in TriCore. PowerPC no problem either if using NXP toolset and checking some options so it does not trash the stack or registers in subroutines. |
|
|
|
|
Logged
|
|
|
|
nihalot
Full Member
Karma: +41/-3
Offline
Posts: 117
|
|
« Reply #6 on: June 28, 2023, 04:43:49 AM »
|
|
|
That's not always possible, especially when you cant use calls(where pointers for maps need modification for example). Using jumps and regs that are free in the present "stock" code context has least chances of disrupting stock ecu operation(using calls assumes that you have free CSA and also increases code size for simple patches where modifying lower context registers is required- for example pointers being passed to interpolation routines)
|
|
|
|
|
Logged
|
www.tangentmotorsport.commultimap/LC/rolling antilag for MG1/MED17/EDC17/MED9/EDC15 contact for reverse engineering services of any ECU/TCU
|
|
|
R32Dude
Full Member
Karma: +45/-10
Offline
Posts: 248
|
|
« Reply #7 on: June 28, 2023, 06:16:25 AM »
|
|
|
Good job elias! Basano 2.0 in the making.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #8 on: June 28, 2023, 08:11:30 AM »
|
|
|
That's not always possible, especially when you cant use calls(where pointers for maps need modification for example). This example is always possible, because you can simply replace the call into the map read subroutine and do your work there. Using jumps and regs that are free in the present "stock" code context has least chances of disrupting stock ecu operation(using calls assumes that you have free CSA and also increases code size for simple patches where modifying lower context registers is required- for example pointers being passed to interpolation routines) Competely disagree. Stack depth is not affected in any way by calling a different subroutine and then jumping to the routine that was originally going to be called after modifying the registers. Modifying random registers by eyeballing them instead of making use of the EABI convention is the best way to mess things up. For switching maps there is never any need to touch any registers. On Bosch this is done using the double pointer autosar functionality that is already in the ECU. On conti the above approach works perfectly fine. For older stuff, on PowerPC there is no issue with the stack depth. Furthermore, if you need to insert shit into places where you do not want to use EABI, then a compiler is completely useless anyway because it's going to use registers according to the EABI. You lose all the ability to write code in C. Or need crazy workarounds. |
|
|
|
« Last Edit: June 28, 2023, 08:13:34 AM by prj »
|
Logged
|
|
|
|
nihalot
Full Member
Karma: +41/-3
Offline
Posts: 117
|
|
« Reply #9 on: June 28, 2023, 08:40:33 AM »
|
|
|
Modifying random registers by eyeballing them instead of making use of the EABI convention is the best way to mess things up.
For switching maps there is never any need to touch any registers. On Bosch this is done using the double pointer autosar functionality that is already in the ECU.
On conti the above approach works perfectly fine.
Furthermore, if you need to insert shit into places where you do not want to use EABI, then a compiler is completely useless anyway because it's going to use registers according to the EABI.
You lose all the ability to write code in C. Or need crazy workarounds.
That's the whole point of using Ghidra to get free regs, no eyeballing involved. Not all maps/vars are loaded using double pointer method to load addrs. In fact BMW uses direct addrs in most MG1 functionality Also I was referring to MCU CSA, not the one maintained by EABI/OS. You can even pass on available regs to C compiler and limit it to use only from a given list while maintaining EABI conventions |
|
|
|
|
Logged
|
www.tangentmotorsport.commultimap/LC/rolling antilag for MG1/MED17/EDC17/MED9/EDC15 contact for reverse engineering services of any ECU/TCU
|
|
|
|
prj
|
|
« Reply #10 on: June 29, 2023, 01:33:26 AM »
|
|
|
That's the whole point of using Ghidra to get free regs, no eyeballing involved.
Not all maps/vars are loaded using double pointer method to load addrs. In fact BMW uses direct addrs in most MG1 functionality So does Ford. But this does not change the fact that the easiest patch point is in 99% cases simply replacing the map lookup routine call and modifying the arguments to it. No need to do anything with registers other than creating headers one single time, and the patch does not need to be recompiled for every ECU revision. Only the ram cell and asw addresses updated, which can easily be done with an automatic assembly framework. |
|
|
|
|
Logged
|
|
|
|
elias
Full Member
Karma: +20/-3
Offline
Posts: 65
|
|
« Reply #11 on: September 12, 2023, 03:02:43 PM »
|
|
|
Hello together
Finally i got some time to tinker around again with the MED9.
Regarding the whole "compile every time vs precompile once" topic:
I think it depends on the goals of the project and there is no "all fit all" solution. There are arguments on each side.
@R32Dude and @d3irb: Many thanks for your comments, it warms my heart that people appriciate my work.
@prj: Thanks for pushing me into the right direction. I appreciate your comments and your denial of "half backed" solutions.
I have commited a new "patch" which adds my personal holy grail: 0x23(readMemoryByAddress) and 0x3D(writeMemoryByAddress) KWP-Services. With them development becomes fairly easy in comparison to before. You dont need to wait until you can test some code, as you can instantly patch it into RAM and run it directly without having to "flash" it to the ECU.
For the calibration folks, i have some news. If someone would write some "double pointer-patches" for various maps, it should be possible to "livetune" the ECU with the help of the services mentioned above.
A bird told me that following maps are sufficient for tuning the ECU:
LDRXN
LDRXNZK
KFZW
KFZW2
KFPED
KRKATE
KFLDRL
Writing such patch should be really straight forward, but might be time consuming:
1. Find all places where the address of a map is used
2. Patch all places to use a pointer which will be located in ram
3. Set the real map address to the pointer on startup of the ECU
As soon the patch is done, you can write your own map into ram and then "redirect" the pointer to its address.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #12 on: September 17, 2023, 01:22:48 PM »
|
|
|
Choice of maps is very strange, seems like you do not have experience with calibration (or whoever suggested those).
The real solution is very different.
MED9 ECU's have CCP, which has predictable response times and built in download/upload commands.
To implement live tuning on this ECU you need to hook into output and modify the end parameters.
E.g. wgdc, camshaft setpoint, ignition setpoint, fuel correction, maf correction.
Then build it over a CCP bridge (probably have to change the CCP CAN ID's to something the gateway likes) and implement a real time measurement protocol and 2D maps for the corrections.
Essentially allowing to define an overlay or bypass map on the PC that the ECU is reading in real time instead of what is in the ECU.
But honestly, I don't see much point in it. Nr1 priority should be modifying the bootloader to flash the cal only. Then you can flash the ECU in under 60 seconds, so all the live tuning stuff becomes pretty unimportant.
|
|
|
|
|
Logged
|
|
|
|
|
BlackT
|
|
« Reply #13 on: September 17, 2023, 01:27:01 PM »
|
|
|
Choice of maps is very strange, seems like you do not have experience with calibration (or whoever suggested those).
The real solution is very different.
MED9 ECU's have CCP, which has predictable response times and built in download/upload commands.
To implement live tuning on this ECU you need to hook into output and modify the end parameters.
E.g. wgdc, camshaft setpoint, ignition setpoint, fuel correction, maf correction.
Then build it over a CCP bridge (probably have to change the CCP CAN ID's to something the gateway likes) and implement a real time measurement protocol and 2D maps for the corrections.
Essentially allowing to define an overlay or bypass map on the PC that the ECU is reading in real time instead of what is in the ECU.
But honestly, I don't see much point in it. Nr1 priority should be modifying the bootloader to flash the cal only. Then you can flash the ECU in under 60 seconds, so all the live tuning stuff becomes pretty unimportant.
How to achieve that? |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #14 on: September 18, 2023, 12:44:27 AM »
|
|
|
How to achieve that? By modifying the ECU to allow it to boot when the full checksum is not correct and some other conditions in the CBOOT. And also writing a custom flash tool. |
|
|
|
|
Logged
|
|
|
|
|
