Help a n00b get started with disassembly

[E46m3zcp]

I asked claude-code to follow instructions from https://github.com/karter16/CSL_0401...assembly_Notes to set up Ghidra for disassembling my own binary, which I previously dumped with BMWFlash.

Is this a feasible approach? Claude is telling me:

One thing worth your attention: the repo's reference binary (Full 211323000401PD31_TERRA.bin, 1MB) turned out to be two 512KB images concatenated back-to-back — the Master and Slave halves, each with its own CPU32 vector table at offset 0. Your grey_DME_full_v0.2.0.bin is exactly 512KB with the same vector-table shape (SP=0, reset PC=0x200) but a different default-handler address (0x5b0 vs 0x5ce), meaning it's a single Master-or-Slave-equivalent half from a different firmware build — not the combined dump. The load base of 0x0 is correct either way, but I can't tell you from the bytes alone whether it's the Master or Slave side (that matters for which parts of the repo's wiki/identified-functions apply).

Does this make sense? I know I might be able to use the terra binary, but I'd like to:
A. learn
B. disassemble the non-csl binary

So when I dump the full bin with BMWFlash, why is it only 512kb. My dme is mss54hp if that matters.

[karter16]

I asked claude-code to follow instructions from https://github.com/karter16/CSL_0401...assembly_Notes to set up Ghidra for disassembling my own binary, which I previously dumped with BMWFlash.

Is this a feasible approach? Claude is telling me:

One thing worth your attention: the repo's reference binary (Full 211323000401PD31_TERRA.bin, 1MB) turned out to be two 512KB images concatenated back-to-back — the Master and Slave halves, each with its own CPU32 vector table at offset 0. Your grey_DME_full_v0.2.0.bin is exactly 512KB with the same vector-table shape (SP=0, reset PC=0x200) but a different default-handler address (0x5b0 vs 0x5ce), meaning it's a single Master-or-Slave-equivalent half from a different firmware build — not the combined dump. The load base of 0x0 is correct either way, but I can't tell you from the bytes alone whether it's the Master or Slave side (that matters for which parts of the repo's wiki/identified-functions apply).

Does this make sense? I know I might be able to use the terra binary, but I'd like to:
A. learn
B. disassemble the non-csl binary

So when I dump the full bin with BMWFlash, why is it only 512kb. My dme is mss54hp if that matters.

Hey - awesome that you're getting into this! - It is absolutely possible to do what you're suggesting, but there are some considerations.

Although the codebase is very very similar across the MSS54HP software versions, the actual binaries can be quite different. The way that BMW wrote the software is in C, with some bootstrap assembly. This means that the exact placement in ROM of functions, consts, parameters, etc. can all be re-ordered as a result of extremely minor changes to the code. This means for example that function x in 0401 will almost certainly not be in the same memory location as it is in 2701. Likewise for parameters and consts. Also variables (RAM) locations likewise differ between versions.

This means that you can't just take the work that I've already done and easily apply it to your own binary disassembly. You have to figure out the mappings by comparing the two and manually identify everything - this is what I had to do to map from 1801 (for which there is a leaked A2L definition file) to 0401 (CSL) and it took forking ages.

I'd suggest that for learning it would be worth looking at what I've already done, familiarise yourself with Ghidra, familiarise yourself with the layout of the binary, figure out how things fit together and then start tackling your own binary if you decide you want to.

So when I dump the full bin with BMWFlash, why is it only 512kb. My dme is mss54hp if that matters.

Are you 100% sure it's an MSS54HP? I'm not familiar with BMWFlash, is there any way to make it read only one half of the DME?

Feel free to flick it across to me and I can check for you, will be able to tell from opening it in a hex editor.