Announcement

Collapse
No announcement yet.

CSL '0401' Program Binary Disassembly Notes

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • karter16
    replied
    Original post is now updated with link to the GitHub repo and some basic information on getting started. For anyone who is interested please have a look and let me know where you might need more info/guidance on getting up and running.

    Click image for larger version

Name:	Screenshot 2024-12-16 at 6.30.47 PM.png
Views:	333
Size:	238.1 KB
ID:	287211

    Leave a comment:


  • karter16
    replied
    Originally posted by bmwfnatic View Post

    I know there isn't one for the CSL binary, I am still trying to figure out which binary it does belong to 😂
    This is why I shouldn't reply to comments at work. Sorry. Yes interesting question - I haven't seen that information anywhere. I guess a way to do it would be to load each binary against it and see how much of it aligns, but that would be a huge amount of effort. Also I guess it's entirely possible the A2L is from during development and doesn't align exactly to any production binary.


    Sent from my iPhone using Tapatalk

    Leave a comment:


  • bmwfnatic
    replied
    Originally posted by karter16 View Post

    Ah I'm with you apologies - afaik there was never a correct A2L leaked for the CSL binary - others have pieced it together from the A2L that was leaked. It is incomplete and there are a range of parameters/curves and tables that seem specific to the CSL that are not identified by the A2L. This is part of the fun and as I'm going through I'm discovering where the XDF/A2L is incorrect.


    Sent from my iPhone using Tapatalk
    I know there isn’t one for the CSL binary, I am still trying to figure out which binary it does belong to 😂

    Leave a comment:


  • karter16
    replied
    Originally posted by bmwfnatic View Post

    Sounds good, but I meant more which binary belongs to the A2L.
    I understand we intend to reverse the CSL bin.
    Ah I'm with you apologies - afaik there was never a correct A2L leaked for the CSL binary - others have pieced it together from the A2L that was leaked. It is incomplete and there are a range of parameters/curves and tables that seem specific to the CSL that are not identified by the A2L. This is part of the fun and as I'm going through I'm discovering where the XDF/A2L is incorrect.


    Sent from my iPhone using Tapatalk

    Leave a comment:


  • bmwfnatic
    replied
    Originally posted by karter16 View Post

    Off the back of Heinz's suggestion I'm setting up a GitHub repo with the basics to enable multiple people to contribute to this. I'll share here as soon as it's good enough to share as a start. This will include the binary, etc (I'm using Terra's modified 0401 binary)


    Sent from my iPhone using Tapatalk
    Sounds good, but I meant more which binary belongs to the A2L.
    I understand we intend to reverse the CSL bin.

    Leave a comment:


  • karter16
    replied
    Originally posted by bmwfnatic View Post

    Makes sense, which binary do we use for this?
    Off the back of Heinz's suggestion I'm setting up a GitHub repo with the basics to enable multiple people to contribute to this. I'll share here as soon as it's good enough to share as a start. This will include the binary, etc (I'm using Terra's modified 0401 binary)


    Sent from my iPhone using Tapatalk

    Leave a comment:


  • bmwfnatic
    replied
    Originally posted by karter16 View Post

    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?

    Leave a comment:


  • karter16
    replied
    Originally posted by bmwfnatic View Post
    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

    Leave a comment:


  • bmwfnatic
    replied
    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.

    Leave a comment:


  • karter16
    replied
    Originally posted by heinzboehmer View Post
    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.
    Last edited by karter16; 12-14-2024, 11:16 AM.

    Leave a comment:


  • karter16
    replied
    Originally posted by heinzboehmer View Post
    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).

    Leave a comment:


  • heinzboehmer
    replied
    Monolithic you say? Sounds copy-pastable to me!

    Leave a comment:


  • karter16
    replied
    Originally posted by nextelbuddy View Post

    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.

    Leave a comment:


  • nextelbuddy
    replied
    Originally posted by heinzboehmer View Post
    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

    Leave a comment:


  • heinzboehmer
    replied
    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.

    Leave a comment:

Working...
X