NefMoto

Hello everyone,

Here is my first contribution for this forum. I have made some scripts for easier disassembly of MED9.1 ECUs.

https://github.com/EliasKotlyar/Med9GhidraScripts

The Script called "AddJsonMaps.py"(Add Maps from WINOLS to Ghidra) can be useful for other ECUs as well. PRs are welcome in the repository.

Instead of WinOLS add A2L import.

IDA sample posted here:
http://nefariousmotorsports.com/forum/index.php?topic=13749.0title= (http://nefariousmotorsports.com/forum/index.php?topic=13749.0title=)

A2L actually has the useful stuff. And a huge amount of A2L's for MED9 float around online as well.

I managed to create a RAM-Writer for my binary, which is based on Basanos-Can-Mapswitch Code.

It works like that:
1. Send a CAN Message with the ID 0x539 to the ECU (1337 in decimal ;) )
2. Can-Message format should be as following:

Example Message:
"01 80 47 00 66 66 66 66"
Byte1 = fixxed value 01
Byte2-4 = Address which you want to write(in example 0x804700)
Byte 4-8= 32 Bit value which you want to write. (in example 0x66666666)
3. As soon as you send it, it will be processes by the ECU and it will write the 32bit value into the RAM

Unfortunately , its not possible to write to anything below 0x800000 as this regions are write protected. However, i assume that it can be fixxed by doing some more research.

Its good enough for development purposes, as you can modify ram values on the fly and see the outcome.

I included two binaries:
original_file_bwa contains the original file, unmodified
canbus_ram_write.bin contains the file which was modded for ram-writing. If someone want to modify it to his binary, it should be easy possible if you correct the adresses of the functions.

Greatings
Elias

It's not going to work in car though. Gateway will filter the message.
And either way it's not the way, just modify KWP stack and add a function to some existing service.

Hello PRJ,

I appreciate your comment, and i know its the way to implement. However its not possible with my skillset. I would love to do it correctly, but i dont even understand where the KWP Stack starts. Even with the A2L its not possible for me to locate the exact function where the KWP Messages are being processed. If you would point me into the right direction, i would really appreciate that. My current goal is to find a way of "unlocking" the flash, so i can modify any code/maps on the fly.

I am really strugling understanding the code which Basano wrote, but i was able to adjust it to my binary(as his has completely different addresses as mines)

As far as i see it, nobody has wrote/shared any "ramwriter" for MED9 yet. I hope that i can make someones life easier with my work. As Basano made my life easier with his tutorials.

Okay well, this is a good example of the XY problem (https://xyproblem.info/).

You can not write to the flash when the ECU is running.
That's not how flash memory works.

First of all, Flash memory works based on pages. You can only erase an entire page.
Furthermore, while you are programming/erasing the flash, the majority of microcontrollers do not allow executing from it.

So no, you can't just magically send a write command to the flash. While the ECU is running.
The only way is to redirect the flash reads to RAM (and then write RAM), this can be done on code level e.g. Bosch MEDC17 or it can be done on processor level (Overlay functionality).
On MED9 it was done by adding extra hardware (ETK) and remapping the SDA (iirc) accesses there.

If you want to do it without extra hardware, then you have very limited RAM to work with, so you can't just remap the whole calibration area.
It means for every single map and/or parameter that you want to alter that way you need to write extra code to do so.

There is something older called "verstellsystem", which has conveniently placed intercept points in many functions that allow to alter the basic outputs of the ECU at given operating points.
E.g. a flat offset to injection time, or timing or a fixed WGDC.
These can be used on a dyno - you can monitor the current ECU operating conditions and feed a constant custom overlay over the current parameters.
Does not work if you make very fast and sudden changes in operating conditions, but works well enough to tune in steady state or on pulls with a relatively low ramp rate.

Hello PRG,

many thanks for pointing out this whole process. I finished working on my project without a proper way of modifiying code on the fly. H
owever i am still wondering, if there is a way of testing code without having to flash it using the "traditional" method by a flashtool(mpps, kess etc)? I really want to speed up the process of "trying" out code changes.

Could you suggest something to speed up the process? There are no shortcuts,thats clear, but maybe some different approaches..

I could think of attaching a debugger to the MED9 using the BDM-Pins. In Debugging Mode, you could at least stop the execution flow with breakpoints to rethink your next steps. Also it would help understand the assembler code.

not unless the watchdog timeout is taken care of
Also JTAG is usually password protected, not sure if it is on MED9

If you just want to test a piece of code and you need something to run it on, then a simulator is definitely the way to go.
Because PowerPC is pretty widely used, then I'm sure something like QEMU will work.

If you want to inject code into the ECU, then you need a diagnostic service (or CCP) to write RAM and then you need to be able to make it execute from there.
This still does not show very well whether code that you splice in somewhere will work, just that if you write a subroutine, that it won't blow up.

That said, you can save a ton of time and make much fewer mistakes by just using a C compiler. It's very viable to do that on PowerPC.

hey, im having some trouble using your json maps stuff... when I use it, some areas of the bin get defined as "db" and gets skipped when I try to decompile. to be fair i cant even decompile the bin properly, tried selecting several powerpc options and the best i got was considering VLE, but i dont think its accurate. can you give me some pointers? attaching the bin just in case. its a med9.1.1 (mpc563).

thanks in advance :)

There is no VLE on MED9.

thanks for the info, i tried it from reading it was implemented in mpc56x somewhere. still, weirdly that dissembled more of the file than the regular ppc big 32 option  ???

@lgtmeto:

I would suggest that you try to read all Basano Posts before you even try to do some steps.

Generally speaking codechanges of MPC5** goes this way:
1. Start with a known binary with a matching A2L
1. Figure out values of R2 and R13
2. Figure out the memory map and setup the mem-map correctly in Ghidra
3. Add all symbols from the A2L into Ghidra
4. Do your code changes
5. Validate that codechanges are working as expected on Bench
6. Validate that codechanges are working as expected in Car
7. Transfer the codechanges into your binary.

The scripts which you can find in the repository, will just help you with setting everything up.
You will still have to figure out all other things on your own.

i got r2 and r13 from basano, and tried using his addresses for ram/rom, at first, but it didnt work.

also got a memory map from an actual mpc563 full of other addresses, and it still wont work. attaching it here in case it helps someone.

unfortunately i never got the damos for my bin, but i have a full mappack which i used to generate a json and use with your tool. but it ends up turning some undefined symbols into "db" and ghidra just skips it. I even tried setting r2 and r13 without your tool (so that id still keep the bin at 0x0 instead of moving to 0x00400000), plus reinserting the bin again (starting at 0x1c0000) into 0x5c0000, but still got nothing.

Your ECU is 2.5mb, you're trying to load a 2mb file.
All this stuff here is useless for you and until you get a full read there's nothing to load. You're missing the whole intflash that contains the majority of the code.
And the flash layout is not compatible with the 2mb MED9.1.

So first of all, i would suggest starting a new thread for documenting your progress on your project
Some informations like "what exactly are you trying to achieve" would be a great start for further help.

Second of all: you will have to do as Basano, and not blindly copying his results/values. Your ECU is different, and his posts are about approaches and the results posted by him are only examples.

Third: Getting a Full-Read as prj told you, is a requirement.

yes, it was my mistake, i didnt know the ecu was different. i got the full read, now gotta make it work :)