CSL '0401' Program Binary Disassembly Notes

[karter16]

Update 16/12/24:

Based on the suggestion from heinzboehmer I've setup a (very mvp) GitHub repo to form the basis of tracking this project and make available what I've done to others to use and contribute to.

The repo can be found here: https://github.com/karter16/CSL_0401...assembly_Notes

I've put in very basic information on getting started with Ghidra and what's needed, but will be relying on others calling out where they're getting stuck (if anywhere) to know what additional info to add.

For now I've exported by Ghidra project as an archive which others can then import. For now I'll keep hold of the master and keep it updated.

My ask would be for others to use the "Issues" function on the repo to report either "bugs" with existing decompilation in the archive or "discoveries" of new information.



This way we can keep track of problems and discoveries as they are found, discuss them, and I can add them to the master doc. Depending on how much traction this gets and how many people are regularly contributing I may look at standing up a Ghidra server to allow multiple contributors to work together, but even so that still leaves questions around quality control etc. so will consider that more in the future.

As soon as I get a chance I'll try to add some info to the repo wiki to describe how I've been marking things up as I work on them, although if you have a look you'll probably be able to figure out how I'm labeling things, etc.


This work is being undertaken for my own understanding and as a general good for the community. Please if you're going to use any of this info for any purpose make sure you double check everything and ensure that you know what you're doing with it :-)

[karter16]

Reserved 1

[karter16]

Reserved 2

[karter16]

Reserved 3

[karter16]

Reserved 4

[karter16]

Reserved 5

[heinzboehmer]

Awesome, thanks for sharing! Let me know if you ever need/want help and I can try to jump in.

Would be nice to get this binary publicly disassembled so that we can write some custom features into the DME (e.g. current gear broadcast to retrofit the SMG screen in a manual car, MK60 brake pressure query over D bus and rebroadcast over CAN, etc.).

Can always leverage the wiki on the github repo if that works better than this thread.

[nextelbuddy]

Awesome, thanks for sharing! Let me know if you ever need/want help and I can try to jump in.

Would be nice to get this binary publicly disassembled so that we can write some custom features into the DME (e.g. current gear broadcast to retrofit the SMG screen in a manual car, MK60 brake pressure query over D bus and rebroadcast over CAN, etc.).

Can always leverage the wiki on the github repo if that works better than this thread.

Would love to figure out the oil level read out to be able to get it working on non CSL HP DME tunes

[karter16]

Would love to figure out the oil level read out to be able to get it working on non CSL HP DME tunes

I was actually looking through this function yesterday. It stands out as a feature that was added in afterwards for a couple of reasons.

1: It's a monolithic function - the decompiled C code is 700 lines, this is much larger than most other functions which are much more modular in design.
2: It has repeated calls to lookup the same table values in different if/else statements. The rest of the binary is carefully written to prepare the inputs and do a single table lookup, but this one has clearly been written differently in a different style.

It will be a non-trivial exercise to reverse engineer it completely, however for your purpose the key would be to identify the various inputs and outputs, their relative locations in your target binary and go from there.

[heinzboehmer]

Monolithic you say? Sounds copy-pastable to me!

[karter16]

Monolithic you say? Sounds copy-pastable to me!

haha - maybe - what I'm not sure about is what the code in the non-csl binary looks like that handles the TOG (oil level/temp sensor). Depending on how it was written and how the CSL version replaced it it may or may not be easy to add in the additional functionality. The way the CSL version is written I'm guessing it was a fairly brute-force replacement of the original code, but maybe not. (I'd love to look into it, but this is all very time consuming and trying to take the time to get the basics in place first to aid in better understanding of the code).

[karter16]

Awesome, thanks for sharing! Let me know if you ever need/want help and I can try to jump in.

Would be nice to get this binary publicly disassembled so that we can write some custom features into the DME (e.g. current gear broadcast to retrofit the SMG screen in a manual car, MK60 brake pressure query over D bus and rebroadcast over CAN, etc.).

Can always leverage the wiki on the github repo if that works better than this thread.

The GitHub wiki is a good idea - I will look into that. I'd love as much help as possible, I'm just trying to figure out how I best set everything up that others can access and contribute to it while keeping some semblance of order.

[bmwfnatic]

How do you get started on this, using that leaked A2L and then using a matched binary and then just start cross referencing? Or is there something I am missing.

[karter16]

How do you get started on this, using that leaked A2L and then using a matched binary and then just start cross referencing? Or is there something I am missing.

Pretty much - the A2L/XDF gives you the memory locations and names of the parameters, curves and tables in the data space along with some somewhat questionable details around UOM etc. from there you can find the references to these in the program binary and start working backwards from there. The FunktionsRahmen helps a bit too with identifying some of the global var names, etc.


Sent from my iPhone using Tapatalk

[bmwfnatic]

Pretty much - the A2L/XDF gives you the memory locations and names of the parameters, curves and tables in the data space along with some somewhat questionable details around UOM etc. from there you can find the references to these in the program binary and start working backwards from there. The FunktionsRahmen helps a bit too with identifying some of the global var names, etc.


Sent from my iPhone using Tapatalk

Makes sense, which binary do we use for this?