BMW MG1CS003 ISN Transfer: Step-by-Step Case Guide

Scope and Limits

This guide restates the supplied Mg1cs003 isn patch.txt case notes for an authorized donor-ECU replacement using the vehicle's original identity.

It applies only to EEPROM files that match the documented record structure and integrity checks. It is not an OEM procedure or a universal MG1CS003 method. The notes report one successful donor test, but do not define exactly what in-vehicle checks established success. The referenced binaries were not supplied for independent verification here.

This is a file-editing guide, not instructions for connecting, unlocking, or programming an ECU. Use the supported procedure for your programming equipment and independently establish donor compatibility before any hardware write.

What You Are Changing

In each of two matching donor records:

• Replace the 16-byte DME ISN with the original ECU's ISN.
• Replace the immediately following eight-byte field with the original's field.
• Recalculate and replace that record's four-byte integrity word.
• Preserve every other donor byte.

The secondary 16-byte field was NOT transferred in the documented successful test. Its suggested EGS-related meaning is unproven.

Before You Start

Have an untouched original-ECU EEPROM dump, an untouched donor EEPROM dump, a hex editor supporting overwrite mode, and a calculator supporting hexadecimal XOR. Your checksum tool must implement the CRC32/IEEE parameters below.

Preserve both original dumps, their hashes, and the ECU identification/read details. Work on a separate copy of the donor file. Do not overwrite your only backup. Stop if a read is incomplete or its identity is uncertain.

Step 1: Locate the Records in Each File

Search for this sample-specific 10-byte header:

A5 3C 96 01 E4 1A 00 50 3B D4

Call the first byte of a candidate header R. Offsets beginning with 0x are hexadecimal, and all file offsets are zero-based.

Check the complete structure before accepting a match:

Also check that the six-byte footer starting at R + 0x5A is:

6A 02 00 00 FF FF

In the supplied samples, there are two matching-layout records, 0x60 bytes apart. Confirm the original record against the known original ISN, as the case notes did. A header match or an isolated 80 is not sufficient evidence.

Locate records separately in the original and donor. Their absolute offsets can differ. Stop if the structure, number of records, or spacing does not match this case; do not force this method onto a different layout.

Step 2: Validate the Untouched Records First

For each original and donor record, select exactly 80 bytes:

Start: R + 0x0E
End:   R + 0x5D, inclusive
Length: 0x50 bytes

Calculate:

integrity word = CRC32_IEEE(selected 80 bytes) XOR F7ACAC92

The result must match the existing four bytes at R + 0x0A when interpreted as big-endian. Validate both copies independently. If any original record does not match, stop: a layout mismatch, incompatible checksum rule, or damaged read must be investigated before patching.

Use these CRC parameters, matching the supplied notes:

• CRC width: 32 bits.
• Polynomial: 04C11DB7; reflected implementation polynomial: EDB88320.
• Initial internal state: FFFFFFFF.
• Reflected processing.
• Standard final XOR: FFFFFFFF.
• Then apply the additional record XOR F7ACAC92 once.

This is not CRC32C. The additional record XOR does not replace the standard CRC32 final XOR. Exclude the header, the stored integrity word, and the final two FF FF bytes from the selected payload.

Step 3: Copy the Original Identity Data

From the verified original record, copy these 24 consecutive bytes:

Start: R_original + 0x0E
End:   R_original + 0x25, inclusive
Length: 0x18 bytes = 24 bytes

[16-byte original DME ISN][following 8-byte original field]

Check both original copies. If their identity data disagrees, stop and resolve which record is authoritative; this guide does not cover that situation.

Do not copy the original record's checksum or the entire 96-byte record.

Step 4: Overwrite Those 24 Bytes in Both Donor Records

Open the working copy of the donor file. Use OVERWRITE, not insert mode.

At each independently verified donor record, replace only:

R_donor + 0x0E through R_donor + 0x25, inclusive

Use the original identity data from Step 3 for both matching donor copies. The overall file length must remain unchanged.

Step 5: Preserve the Rest of the Donor Record

Do not change the header, 80 spacer, secondary 16-byte field, remaining payload, or footer. In particular, do not copy the original secondary field merely because it was previously described as an EGS ISN.

The documented successful test preserved that donor field even though the original ECU's corresponding field was zero. The notes do not establish a universal rule for other ECU variants or different repair cases.

Step 6: Recalculate Each Donor Record's Integrity Word

After the 24-byte replacement, select that donor record's final 80-byte payload using the range from Step 2. Calculate its CRC32/IEEE, then XOR the result with F7ACAC92 using a hexadecimal calculator.

Calculate each donor copy separately. Do not assume equal ISNs mean equal checksums: the rest of the covered payload matters too.

Worked example from the supplied successful-test notes:

CRC32 of that record's final payload: 9B5CF0C8
Additional record XOR:               F7ACAC92
Result:                             6CF05C5A
Bytes to store, big-endian:          6C F0 5C 5A

Overwrite the four bytes at R_donor + 0x0A through R_donor + 0x0D with your calculated result. Big-endian means the most significant byte comes first. The example result is not a value to reuse on another file.

Step 7: Save, Reopen, and Compare

Save under a new filename and reopen it. Verify:

• File length is identical to the untouched donor.
• Both donor records contain the intended original 24-byte identity data.
• Both stored integrity words match independently recalculated results.
• The only changed byte positions are inside each record's R + 0x0A through R + 0x25 range.
• All other donor bytes, including both secondary fields, are unchanged.

Each allowed change range is 28 bytes. The supplied case reports exactly 56 changed bytes across two records. Other files could have fewer actual byte differences if some replacement bytes already match; 56 is not a universal required diff count.

Do not infer correctness just because the two records match each other or the checksum passes. Neither establishes ECU compatibility or successful operation.

Step 8: Hardware Verification Is a Separate Stage

Only after the file checks and independent compatibility checks pass should a qualified operator consider writing it using the equipment's supported method. Retain the untouched donor for recovery. Perform the tool-supported read-back and relevant diagnostic/vehicle checks, and record the actual outcomes rather than documenting only that the repair "worked."

Source

Supplied case note: Mg1cs003 isn patch.txt, dated 11 September 2026. This guide reorganizes that note; it does not add independent binary or in-vehicle verification.