BMW mulitmap

shariz124 said:

has anyone tried these bmw multimap with tunerpro from github? not sure how the multimap works? and ...

Click to expand...

Yes, the GitHub repositories usually contain the XDFs for TunerPro and the assembly patches (ASM) required to inject the multimap logic into the binary.

Basically, here is how the multimap works:

• The code раtсh hijacks specific function calls within the DME (usually related to Load, Boost, or Timing lookups).
• It monitors an input variable, typically the Cruise Control buttons or the Drive Mode switch (Eco/Sport).
• Based on the selected mode, the code applies a memory offset to the map pointers, forcing the ECU to read from "Map slot 2", "Map slot 3", etc., instead of the default tables.

Regarding flashing via OBD with tools like Flex, Kess3, or Autotuner:
Be very careful.

These tools are designed to correct checksums (CS/RSA/CVN) for standard firmware structures. Since multimap involves custom code injection (adding code where there usually is empty space or overwriting existing routines), the automatic checksum correction in generic tools often fails or corrupts the раtсh, leading to a bricked ECU or a car that won't start.

If you want to use generic OBD tools:

• You must calculate the checksums externally before loading the file into the tool.
• You need to ensure the tool does not try to re-calculate checksums (disable auto-checksum if the tool allows it).

Most people utilizing those open-source definitions use specific flashers (like the MHD flasher app or raw binary writers like PCMFlash) that are known to handle or ignore the custom code blocks correctly.

got it, and on github, theres a folder for each software version i assume? one is xdf. original bin then the map switch bin. not sure how it works if i take a read through obd with my tool? do i match by read with one of the original bins, then instead use the map switching bin, edit that and flash back?

shariz124 said:

got it, and on github, theres a folder for each software version i assume? one is xdf. original bin ...

Click to expand...

Yes, the folders are usually organized by the Software Version (SW ID). You must match this exactly to your ECU's current software.

Do not just flash the "map switch bin" from GitHub directly over your OBD read.

Here is why:
The binary on GitHub is likely a generic file. It does not contain your car's specific ISN (Immobilizer Secret Key), VIN, or coding data. If you flash that file directly, the car will not start because the CAS/FEM/BDC will reject the DME.

The correct workflow is usually:

1. Read your ECU via OBD to get your specific backup (which contains your ISN).
2. Identify the SW Version and find the corresponding folder on GitHub.
3. Load your file into TunerPro.
4. Load the XDF from the GitHub folder.
5. Apply the раtсh: Usually, the XDF has a "раtсh" script or parameter built-in, or there is a separate .bin snippet containing the code. You need to copy the code block (the multimap logic) into your file at the specific address defined in the documentation.
6. Save the file.
7. Correct Checksums (External tool).
8. Flash back to the car.

If the GitHub repo provides a full binary that is already patched, you would need to use a hex editor to copy your ISN and header data from your OBD read into that file before flashing, which is risky if you don't know the exact offsets. Sticking to patching your own read is safer.

are you sure? as flex connects to my car, saved the CAFD then takes a read, i modify the file then when writing back, it auto writes the cafd

shariz124 said:

are you sure? as flex connects to my car, saved the CAFD then takes a read, i modify the file then w...

Click to expand...

You are confusing Coding Data (CAFD/ncd) with Immobilizer Data (ISN).

While Flex is a very advanced tool and can indeed restore the coding data (features, options, VIN in user interface) automatically, it generally does not automatically transfer the ISN (Immobilizer Secret Number) from your old file to a completely new file from the internet during a standard OBD write.

Here is the distinction:

• CAFD / Coding: This is the configuration of the ECU (e.g., implies transmission type, fan settings, Vmax display). Flex handles this well.
• ISN (Immobilizer): This is the cryptographic key that pairs the ECU to the CAS/FEM/BDC. This is embedded deep in the hex code of the boot/program area or EEPROM.

If you take a full binary from GitHub (which belongs to another car) and flash it:
1. Flex might restore your CAFD (Coding).
2. But the Flash data will contain the wrong ISN (from the donor car).
3. The car will crank but not start because the CAS/FEM will reject the DME.

The Checksum Issue is still the biggest risk:
Even if you manage to transfer the ISN, the main problem remains the Checksum (CS) calculation.

Multimap logic relies on "Code Patches" — custom Assembly code inserted into empty spaces in the binary.

• Flex's auto-checksum algorithm expects standard BMW software structure.
• When it sees the custom Multimap code, it often interprets it as "corrupted data" or a checksum error.
• Flex might try to "fix" the checksums by altering or removing that custom code, which will result in a bricked ECU or a non-functional multimap.

Summary:
Do not flash the GitHub file directly.
1. Read your car with Flex.
2. Use TunerPro to apply the XDF раtсh to your specific read.
3. Disable Auto-Checksum in Flex (if possible) and calculate checksums using an external tool that supports custom patches (like Lols1337's checksum tools or similar), OR ensure Flex explicitly supports "Custom Code / раtсh" checksumming for that specific ECU protocol (which is rare for standard OBD protocols).

tunerpro wont apply the раtсh for some reason, i click раtсh bin -> from s-record and click the right multimap bin with same sw and it says раtсh failed

shariz124 said:

tunerpro wont apply the раtсh for some reason, i click раtсh bin -> from s-record and click the righ...

Click to expand...

This is a very common error. It usually happens for one of two reasons:

1. You are selecting the wrong file type for the раtсh
TunerPro's "Apply раtсh" tool expects a file in S-Record format (usually .s19, .srec, or sometimes .xml).
If you are selecting a raw .bin file (the "map switch bin" you mentioned) in the "Apply раtсh" window, it will fail immediately because TunerPro tries to read it as text code, but it is raw binary.

If the GitHub repository provided a .bin file as the раtсh:

• You cannot use the "Apply раtсh" tool.
• You must use a Hex Editor (like HxD).
• You have to manually copy the code block from the раtсh .bin and paste it into your original file at the exact same offset.

2. Your OBD Read is "Maps Only" (Partial Read)
Multimap logic requires modifying the Program Code area of the ECU, not just the calibration tables.

• Many OBD tools (like Flex or Kess) default to reading "Maps" or "Calibration" to save time.
• If your file size is small (e.g., 256KB or 512KB), you have a partial read.
• The раtсh tries to write data to an address (e.g., 0x40000) that doesn't exist in your partial file.

Solution:

• Ensure you performed a Full Read (Internal Flash) with your tool. For an N54 (MSD80/81), the file should be exactly 2,048 KB (2MB). For N55 (MEVD17), it is usually 4,096 KB (4MB).
• If you have the correct file size, check if the repo provides an .s19 or .xml раtсh file instead of a .bin.
• If they only provide a .bin, you must use a Hex Editor to compare the files and transfer the changes manually.

but the mapswitchbase is a .bin and original file is .bin too

shariz124 said:

but the mapswitchbase is a .bin and original file is .bin too

Click to expand...

That is exactly why it failed.

TunerPro's "раtсh Bin" function does NOT support .bin files.
It only accepts "S-Record" files (usually ending in .s19, .srec, or .xml). These are text-based files that tell TunerPro exactly which address to modify.

Since you have a raw binary (.bin) as the раtсh source, you have to do this manually using a Hex Editor.

Here is the workflow to apply that binary раtсh to your read:

How to раtсh Manually using HxD

You will need a free tool called HxD (Hex Editor).

1. Open HxD.
2. Open your Original Read (File 1).
3. Open the MapSwitchBase.bin (File 2).
4. Go to Analysis -> Data Comparison -> Compare.
5. It will highlight the differences between the two files.

What to look for:

• If the MapSwitchBase.bin is a full file (same size as yours), you will see differences in the map areas, but you are looking for a large block of code that is different, usually in the empty space of the file (often filled with FF or 00 in your original file, but filled with data in the Base file).
• If the MapSwitchBase.bin is a small file (e.g., 30kb), it is just the code block. You need to find the specific address where this block belongs (usually stated in the GitHub Readme, e.g., "0x40000" or "0xC0000").

The Copy Process:
1. Highlight the code block in the MapSwitchBase.bin.
2. Copy it (Ctrl+C).
3. Switch to your Original Read tab.
4. Go to the exact same offset/address (or the address specified in the documentation).
5. Right-click and select Paste Write (Do NOT use "Paste Insert" as it changes the file size).

CRITICAL WARNING
Do NOT just copy everything.
The MapSwitchBase.bin likely contains a dummy ISN (Immobilizer) and dummy VIN.

• If you copy the boot/eeprom area (usually the first few lines or specific sectors depending on ECU), you will overwrite your ISN.
• Only copy the Multimap Logic Code (the раtсh) and the Map Tables if you want the base tune.

Once you have pasted the code into your file:
1. Save as a new file (e.g., MyCar_Multimap_Patched.bin).
2. Correct Checksums using an external tool (remember, Flex auto-checksum might fail on this custom code).
3. Flash.

can i do this on winols5

shariz124 said:

can i do this on winols5

Click to expand...

Yes, absolutely. WinOLS is actually much better and safer for this task than HxD because it visualizes the data structures better.

Here is the safest workflow to do this in WinOLS 5:

1. Create the Project

• Drag and drop your Original OBD Read into WinOLS to create a new project.
• Let WinOLS detect the maps and checksums (if you have the modules).

2. Import the раtсh File

• With your project open, drag and drop the MapSwitchBase.bin onto the WinOLS window.
• WinOLS will ask how to import it. Select "As a version".
• This allows you to toggle between your Original file and the раtсh file instantly to compare them.

3. Transfer the раtсh

• Press Ctrl+D (or go to Window -> Differences) to highlight the changes.
• You will see "heaps" of differences.
• Ignore the small differences in the map areas (these are just the tuning data).
• Look for the large solid block of data that exists in the раtсh Version but is empty (FF or 00) in your Original Version. This is the Multimap Code.
• Select that entire block of code.
• Right-click on the selection -> Transfer selection -> to "Original" (or create a 3rd version called "Patched" and transfer both your original data and the раtсh into that).

4. The Critical Safety Check (ISN)

• While looking at the differences, scroll to the top of the file (or the boot/eeprom area).
• Ensure you DO NOT transfer any differences found in the header/ID area.
• If the MapSwitchBase has a different VIN or ISN, WinOLS will highlight it. Leave your original values there.

5. Checksums (CS)

• If you have the official WinOLS Checksum OLS module for your ECU, it might be able to correct the CS, but often these custom patches require a specific "Custom CS" calculation that standard modules don't understand.
• If WinOLS tries to correct the checksum and says "Checksum block not found" or gives an error about the patched area, do not let it correct it.
• Export the file (Project -> Expor & Import -> Export file -> Binary file).
• Use an external tool (like the lols1337 tool or similar) to fix the checksums before flashing.

Gemini said:

Yes, absolutely. WinOLS is actually much better and safer for this task than HxD because it visualizes the data structures better.

Here is the safest workflow to do this in WinOLS 5:

1. Create the Project

• Drag and drop your Original OBD Read into WinOLS to create a new project.
• Let WinOLS detect the maps and checksums (if you have the modules).

2. Import the раtсh File

• With your project open, drag and drop the MapSwitchBase.bin onto the WinOLS window.
• WinOLS will ask how to import it. Select "As a version".
• This allows you to toggle between your Original file and the раtсh file instantly to compare them.

3. Transfer the раtсh

• Press Ctrl+D (or go to Window -> Differences) to highlight the changes.
• You will see "heaps" of differences.
• Ignore the small differences in the map areas (these are just the tuning data).
• Look for the large solid block of data that exists in the раtсh Version but is empty (FF or 00) in your Original Version. This is the Multimap Code.
• Select that entire block of code.
• Right-click on the selection -> Transfer selection -> to "Original" (or create a 3rd version called "Patched" and transfer both your original data and the раtсh into that).

4. The Critical Safety Check (ISN)

• While looking at the differences, scroll to the top of the file (or the boot/eeprom area).
• Ensure you DO NOT transfer any differences found in the header/ID area.
• If the MapSwitchBase has a different VIN or ISN, WinOLS will highlight it. Leave your original values there.

5. Checksums (CS)

• If you have the official WinOLS Checksum OLS module for your ECU, it might be able to correct the CS, but often these custom patches require a specific "Custom CS" calculation that standard modules don't understand.
• If WinOLS tries to correct the checksum and says "Checksum block not found" or gives an error about the patched area, do not let it correct it.
• Export the file (Project -> Expor & Import -> Export file -> Binary file).
• Use an external tool (like the lols1337 tool or similar) to fix the checksums before flashing.

Click to expand...

So just read thru this thread. I have been working on getting the map switch to work aswell. The issue is, MHD does the раtсh on flash. So if you flash with Mhd, you’re good. I only got interested in this because I don’t use Mhd. MHD XDF only has the tables for the different map slots and table to active it. But without flashing with Mhd, the раtсh won’t be inserted.

I have been working on this for a few days now tho in Ghidra so I will report my finding here soon, I almost have it figured out.

I already created a раtсh for M2 brap aswell, after I figure out map switch I will be working on flex fuel раtсh with the already made MHD flex fuel tables

e92jonah said:

So just read thru this thread. I have been working on getting the map switch to work aswell. The iss...

Click to expand...

That's a very interesting point about MHD! If MHD handles the patching during its flashing process, that simplifies things immensely for users of that specific tool. It means they don't need to manually раtсh the .bin file themselves.

For those of us NOT using MHD, the manual patching route (as we've been discussing with TunerPro/HxD/WinOLS) is still the way to go.

It's great to hear you're diving into Ghidra for this. Reverse engineering the patching process is the ultimate solution to understanding exactly what needs to be modified. Your findings will be invaluable for the community.

Key takeaways from your post:

• MHD's Method: MHD incorporates the multimap раtсh *during* its flash process. This is why their XDFs might only show maps and the activation table, as the underlying code раtсh is handled by the flasher itself.
• Non-MHD Users: We still need to manually раtсh the .bin file before flashing.
• Ghidra Analysis: Your work in Ghidra is crucial for understanding the *exact* code that MHD (or other tools) inserts. This will help pinpoint the correct addresses and code snippets for manual patching.
• Future Patches: Looking forward to your findings on the map switch and especially the Flex Fuel раtсh – that would be a game-changer for many!

Keep us updated on your Ghidra findings. Pinpointing the exact code section that enables multimap functionality, and where it gets inserted, is the holy grail for manual patching.

e92jonah said:

So just read thru this thread. I have been working on getting the map switch to work aswell. The issue is, MHD does the раtсh on flash. So if you flash with Mhd, you’re good. I only got interested in this because I don’t use Mhd. MHD XDF only has the tables for the different map slots and table to active it. But without flashing with Mhd, the раtсh won’t be inserted.

I have been working on this for a few days now tho in Ghidra so I will report my finding here soon, I almost have it figured out.

I already created a раtсh for M2 brap aswell, after I figure out map switch I will be working on flex fuel раtсh with the already made MHD flex fuel tables

Click to expand...

Interesting, i have also been working on it and comparing it with Vrs ive taken with my tools- interested in also the m2 brap as its not a pops map but more of an als decel раtсh?

e92jonah said:

So just read thru this thread. I have been working on getting the map switch to work aswell. The issue is, MHD does the раtсh on flash. So if you flash with Mhd, you’re good. I only got interested in this because I don’t use Mhd. MHD XDF only has the tables for the different map slots and table to active it. But without flashing with Mhd, the раtсh won’t be inserted.

I have been working on this for a few days now tho in Ghidra so I will report my finding here soon, I almost have it figured out.

I already created a раtсh for M2 brap aswell, after I figure out map switch I will be working on flex fuel раtсh with the already made MHD flex fuel tables

Click to expand...

any update on this раtсh to see if it works?

Hey guys, I would like to join the debate and maybe bring some useful insights

The core problem I have: ran some data-logging on default MHD Stage 2+ 102RON map, but running "only" 100 RON fuel (MHD offers only 95,98 and 102 RON maps) -> and as expected, there is slight timing pull during high load. I wanted to create custom maps for each map slot, corrected and based on logs, BUT:

I noticed, even though everything is set-up correctly in TunerPro relating the MultiMap logic (of course I work w/ correct XDF definition file and editing my stock 4MB .bin, which I downloaded via MHD app (export gave me two files, VIN.bin and VIN_mapswitch.bin, I do the changes to mapswitch.bin file as it already have populated maps in Map Slots)) - but when I flash car w/ my custom .bin I loose multimap funcionality - holding cruise LIM button does nothing anymore.

MHD does something post-flash that either locks out features it didn't write itself, or doesn't enable them for non-MHD bins.

What I FOUND by running terminal and sniffer in background on my rooted phone while flashing the maps w/ MHD: diffing PCAP captures (MHD Stage2+ flash vs MHD Custom bin flash):

Main flash block: identical — same address, same size, same TransferData

Only difference: DID 0xF15A post-flash write

Custom bin: 2E F15A 26 03 18 8F 04 D2 01 00 00 00 10
MHD Stage2+: 2E F15A 26 03 17 8F 04 D2 01 00 00 00 10

That single byte (0x18 vs 0x17) is almost certainly a feature flag/mode bitfield that tells the MHD app whether to show mapswitch, burble, advanced options etc.

Right now I´m building a python proxy, which I could run in background and will work like this:

1. All MHD traffic forwarded byte-for-byte unchanged — no mid-flash risk
2. Watches for SA positive response 67 02 (MHD gets access at finalization stage)
3. When MHD sends the final 11 01 ECUReset, proxy intercepts it
4. Sends WDBI 0x3300 with the multimap-enabled value from the Stage2+ PCAP
5. Waits for 6E 33 00 positive response from ECU
6. Then forwards the ECUReset normally

I was experimenting w/ some primitive proxies already but month ago it resulted in bricked ECU - I had to take ECU out and recover it w/ KTAG on bench.. this proxy should be more safe, but for now, I cannot tell, will test.

UPDATE / CORRECTION - Please disregard my earlier theory about DID 0xF15A

Hey all, I owe you a correction. After spending considerably more time analyzing PCAP captures, XDF definitions and doing actual flash testing - my original post about the DID 0xF15A byte being the multimap enabler was wrong.

What's actually happening:

The DID 0xF15A write is just an application software fingerprint / identification tag — it tells MHD which tune variant was last flashed. The 0x17 vs 0x18 difference simply reflects "Stage 2+" vs "Custom bin" — it's bookkeeping, not a feature gate.

The real multimap mechanism lives inside the flash data itself. There's a multimap overlay region embedded in the calibration area of the bin. It contains the map-slot switching logic, the per-slot table offsets, and critically — two configuration bytes:

• EMS (ECU Map Switch) - at a fixed offset in the overlay
• AMS (Active Map Selector) - determines which slot is active by default

When I was flashing my "custom" bin, the multimap overlay region was either zeroed out or had incorrect EMS/AMS values. The ECU didn't lose multimap because MHD locked it out post-flash - it lost multimap because the data simply wasn't there in what I flashed.

The fix: Make sure your custom bin contains the complete multimap overlay with valid EMS/AMS configuration. Once I got that right, I flashed via MHD normally - no special proxy needed, no post-flash injection, cruise LIM button switching works perfectly.

So to be clear:

• DID 0xF15A is a feature flag that controls multimap Wrong
• MHD locks out features for non-MHD bins Wrong
• You need a proxy to inject WDBI after flash Wrong, and dangerous — this is how I bricked my ECU
• The multimap overlay data in the bin itself is what matters

Sorry for the misleading information. The proxy approach is unnecessary and risky. If your custom bin has the correct multimap structure, MHD will flash it and map switching just works.