bmw Cas3+ keyless go not working

Marc1907 said:

not working 4kb dumb: https://drive.google.com/file/d/1aZQbD0NVsGxcgoFafzY6JnRDHQid_T9G/view?usp=sha...

Click to expand...

• Download both BIN files to your PC.
• Open them in HxD (or Hex Workshop).
• Run File → Compare (or Analysis → File Compare) to get the “different bytes / offset ranges”.
• Paste here the list of differing offset ranges (start-end), for example:
  
  Code:

  0x0000-0x003F
  0x0100-0x0127
  0x018A-0x01A3
  ...

• Also tell me: in the broken dump, which key is supposed to be in Slot 1 and which in Slot 3 (old/new), and confirm slot numbers you edited.

• In HxD, go to the first differing offset and copy ~256 bytes from working and broken (showing offsets).
• Paste ~3-5 blocks total until we cover the whole slot1/slot3 region.

Gemini said:

I can’t access those Google Drive links from here (and the extracted text shows only “log in”, so the files aren’t readable).

Do this instead so I can pinpoint the exact bytes to restore/swap:

• Download both BIN files to your PC.
• Open them in HxD (or Hex Workshop).
• Run File → Compare (or Analysis → File Compare) to get the “different bytes / offset ranges”.
• Paste here the list of differing offset ranges (start-end), for example:
  
  Code:

  0x0000-0x003F
  0x0100-0x0127
  0x018A-0x01A3
  ...

• Also tell me: in the broken dump, which key is supposed to be in Slot 1 and which in Slot 3 (old/new), and confirm slot numbers you edited.

If you can’t get the diff list easily, an alternative:

• In HxD, go to the first differing offset and copy ~256 bytes from working and broken (showing offsets).
• Paste ~3-5 blocks total until we cover the whole slot1/slot3 region.

Once I have the exact differing offsets, I’ll tell you exactly which “hidden” sync/counter/status bytes didn’t get swapped for your CAS3+ (HW C4, SW 21.3, 4KB) and how to rebuild the correct Slot1↔Slot3 exchange.

Click to expand...

Marc1907 said:

In HxD, it compares the bytes only individually, not as a whole.

Click to expand...

• Open the working BIN.
• Hex -> Search -> Compare (or use Analysis -> Compare files depending on HxD version).
• Select the broken BIN as the second file.
• In the compare result, copy the offset ranges of the differences (HxD typically groups/marks them; if it only shows individual bytes, then copy the first few offsets and I’ll help you reconstruct ranges).

• Find the first offset where they differ (HxD will jump to next difference).
• Copy 16 bytes before and 64 bytes after that offset from BOTH files.
• Paste it here with the offset shown by HxD, e.g.:
  
  Code:

  Offset: 00000120
  Working: XX XX ...
  Broken : YY YY ...

• Repeat for the next 2–4 differing areas only (usually enough to identify the slot/status/counter region).

• Are these dumps exactly the same file size (4KB = 4096 bytes) and same format (raw bin), yes/no?
• In HxD, what are the first 10 differing offsets between working vs broken? (just the offsets numbers are enough to start)

Gemini said:

That’s fine—what you need isn’t “whole-file match”, it’s the list of byte differences with offsets. In HxD you can do it like this:

• Open the working BIN.
• Hex -> Search -> Compare (or use Analysis -> Compare files depending on HxD version).
• Select the broken BIN as the second file.
• In the compare result, copy the offset ranges of the differences (HxD typically groups/marks them; if it only shows individual bytes, then copy the first few offsets and I’ll help you reconstruct ranges).

If HxD insists on marking individual bytes and you still can’t get ranges, do this manual method:

• Find the first offset where they differ (HxD will jump to next difference).
• Copy 16 bytes before and 64 bytes after that offset from BOTH files.
• Paste it here with the offset shown by HxD, e.g.:
  
  Code:

  Offset: 00000120
  Working: XX XX ...
  Broken : YY YY ...

• Repeat for the next 2–4 differing areas only (usually enough to identify the slot/status/counter region).

To proceed, please tell me:

• Are these dumps exactly the same file size (4KB = 4096 bytes) and same format (raw bin), yes/no?
• In HxD, what are the first 10 differing offsets between working vs broken? (just the offsets numbers are enough to start)

Click to expand...

Marc1907 said:

offset: 00000830
working: 86 FC F6 18 7B D7 0F DE CA D6 B0
not working: 7B D7 F6 18 86 FC 0F DE CA D...

Click to expand...

• working: 86 FC F6 18 7B D7 0F DE ...
• not working: 7B D7 F6 18 86 FC 0F DE ...

• working 36 90 8E 65 ...
• not working 3D F9 8E 65 36 90 ...

• working: 02 12 F0 F0 F0 F0 F0 F0
• not working: F0 12 02 F0 F0 F0 F0 F0

• working: 02 12 F0 F0
• not working: F0 12 02 F0

• BMW model + year + engine (or at least: CAS3+ generation)
• CAS3+ HW/SW: (e.g. HW: C4, SW: 21.x) if known

• byte-align shift (move everything by +1 byte)
• word-align shift (swap every 2 bytes)
• or block swap (Slot1/Slot3 region boundaries are wrong by N bytes)

Gemini said:

Got it. From what you pasted, the “not working” dump isn’t just random—it looks like a 2-byte/word swap and mirrored blocks:

1) At 0x00000830, the first 3 bytes swap position-wise in a repeating pattern:

• working: 86 FC F6 18 7B D7 0F DE ...
• not working: 7B D7 F6 18 86 FC 0F DE ...

This is exactly what you get when some region gets rotated by 2-byte words (or a block of 2 bytes swapped with another word pair).

2) Same pattern at 0x00000848, 0x00000860, 0x00000894, 0x00000AB8, 0x00000AD0, etc.:

• working 36 90 8E 65 ...
• not working 3D F9 8E 65 36 90 ...

So it’s consistent: words/pairs are being rearranged, not just corrected.

3) At 0x00000A68:

• working: 02 12 F0 F0 F0 F0 F0 F0
• not working: F0 12 02 F0 F0 F0 F0 F0

So even the “header-like” bytes 02 12 moved by 1–2 byte positions relative to the F0 padding.

4) At 0x00000D4C:

• working: 02 12 F0 F0
• not working: F0 12 02 F0

Again: the same 02 12 pair slid to the “right” by a byte/word boundary.

This strongly indicates your 4KB “dumb” editing likely swapped/copied the wrong alignment (off by 1 byte / 2 bytes), or you swapped Slot1↔Slot3 using a mapping that assumes a different internal layout (or you used an editor operation that swaps endianness / word order).

What I need to tell you the exact correct fix (alignment + slot mapping):

Please provide:
1) Vehicle/ECU side identifiers:

• BMW model + year + engine (or at least: CAS3+ generation)
• CAS3+ HW/SW: (e.g. HW: C4, SW: 21.x) if known

2) For your 4KB region: which bytes you treated as “Slot 1” and “Slot 3” (start offset and length you copied in HxD).

Quick check you can do now (2 minutes):
In HxD, find the first difference offset you listed: 0x00000830.
Copy 32 bytes from both files starting at 0x00000820 (include bytes before the first diff), paste them here.

Example format:
Offset 00000820
Working: .. .. .. ... (32 bytes)
Not working: .. .. .. ... (32 bytes)

With that, I can determine whether the correct operation is:

• byte-align shift (move everything by +1 byte)
• word-align shift (swap every 2 bytes)
• or block swap (Slot1/Slot3 region boundaries are wrong by N bytes)

Send that 0x00000820 32-byte snippet + your Slot1/Slot3 copy offsets, and I’ll tell you precisely what to change.

Click to expand...

Marc1907 said:

1. E70 X5 2011 xDrive50i Cas3+ HW: C4 SW: 21.3

Offset 00000820
Working: FF FF 00 F8 FF FF FF FF 00...

Click to expand...

• At the working side: ... 86 FC F6 18 7B D7 0F DE CA D6 ...
• At the not working side: ... 7B D7 F6 18 86 FC 0F DE CA D6 ...

• you copied a Slot region using an offset that’s off by 2 bytes, or
• you used a procedure that assumes a different word layout (endianness/2-byte chunking) for CAS3+ backup area.

• “I replaced bytes from 0x00xxxx to 0x00yyyy with …”
• and what the donor region offsets were.

Gemini said:

Thanks—this snippet confirms it’s a consistent block reordering by 2-byte words starting at your CAS3+ area.

From 0x00000820, compare:

• At the working side: ... 86 FC F6 18 7B D7 0F DE CA D6 ...
• At the not working side: ... 7B D7 F6 18 86 FC 0F DE CA D6 ...

So the word pair(s) are swapped/moved, not the data “changed”. This is typical when:

• you copied a Slot region using an offset that’s off by 2 bytes, or
• you used a procedure that assumes a different word layout (endianness/2-byte chunking) for CAS3+ backup area.

What to do
1) Re-check your copy source/destination offsets: they must match exactly the original CAS3+ region boundaries you extracted.
2) Align by 2-byte steps:
- If your intended Slot start was e.g. 0x???? try shifting by -2 and +2 bytes in your HxD copy plan (only 2-byte increments).
3) If you swapped two slots (Slot1/S3 etc.), you must ensure you swapped the same word-aligned block—otherwise you’ll see exactly this “pairs moved around” pattern.

One key detail needed
Tell me the exact start offset and length you copied in HxD for your “working template” and which region you replaced (Slot1 vs Slot3 or what you call them). For example:

• “I replaced bytes from 0x00xxxx to 0x00yyyy with …”
• and what the donor region offsets were.

Once you provide those offsets/lengths, I can tell you whether you need +2 or -2 byte correction and which boundary is wrong.

Click to expand...

Marc1907 said:

I swapped the slots using the program CAS3++ Editor v1.2.

Click to expand...

• CAS3++ Editor v1.2 screenshot or text of:
  • ECU/Key type it selected (CAS3+ / type)
  • Slot operation you did (Slot1<->Slot3, “keyless” slots, etc.)
  • Whether you selected “word swap / endian / 2-byte alignment” option (if present)
• Exact file sizes/format you used for input/output:
  • Was it a 4MB, 4KB, or full dump?
  • Did CAS3++ load a BIN or did it generate a temp file?
• The offsets/lengths CAS3++ reports for Slot1 and Slot3 (or whatever you swapped).

Gemini said:

Ok, but I still need the CAS3++ Editor v1.2 details to tell you the exact correction.

CAS3++ can do different slot operations depending on how it maps CAS3+ flash blocks, and your hex pattern (pairs shifted by 2 bytes: 86 FC F6 18 -> 7B D7 F6 18 86 FC ...) usually means the slot boundary/alignment in the tool’s settings doesn’t match your dump’s layout.

Please post:

• CAS3++ Editor v1.2 screenshot or text of:
  
  • ECU/Key type it selected (CAS3+ / type)
    
  • Slot operation you did (Slot1<->Slot3, “keyless” slots, etc.)
    
  • Whether you selected “word swap / endian / 2-byte alignment” option (if present)
    
• Exact file sizes/format you used for input/output:
  
  • Was it a 4MB, 4KB, or full dump?
    
  • Did CAS3++ load a BIN or did it generate a temp file?
    
• The offsets/lengths CAS3++ reports for Slot1 and Slot3 (or whatever you swapped).

If you don’t have a screenshot, just type the two offsets CAS3++ shows for the slot blocks it swapped. With those I can tell you whether you need an alignment adjustment (+2 / -2 bytes) or whether the wrong slot mapping was selected.

Click to expand...

Marc1907 said:

I’ve simply ordered a new key now and will use the HiTag2 to replace Key 2. That should make everyth...

Click to expand...

• The new key programmed/encoded in CAS3+ (learning/authorization via ISTA/ENET or equivalent coding procedure).
• The correct transponder type (CAS3+ usually uses specific RFID/crypto chip; wrong key type won’t authorize even if it “reads”).
• If it’s keyless go: proper FZV/FRM/GM coding and validation (depending on vehicle setup).
• If the previous keyless function was broken due to your CAS3++ slot swap: replacing “Key 2” alone may not fully repair CAS3+ if the slots are now wrong.

• Is your current issue that the car won’t start (ignition fails) or only that keyless/lock/unlock doesn’t work?
• After your CAS3++ slot swap attempt, do you still have the original BIN/dump saved for CAS3+ before the change?
• Do you know the exact key/slot you were targeting (Slot 2 “Keyless go” / Slot 1 / Slot 3)?

Gemini said:

Not guaranteed.

On CAS3+ “keyless go” cars (E70 2011 xDrive50i), simply cloning/transferring the HiTag2 data for a replacement key can still fail if the CAS3+/EWS identity and/or the key’s rolling code state isn’t consistent.

To make it work you must have:

• The new key programmed/encoded in CAS3+ (learning/authorization via ISTA/ENET or equivalent coding procedure).
• The correct transponder type (CAS3+ usually uses specific RFID/crypto chip; wrong key type won’t authorize even if it “reads”).
• If it’s keyless go: proper FZV/FRM/GM coding and validation (depending on vehicle setup).
• If the previous keyless function was broken due to your CAS3++ slot swap: replacing “Key 2” alone may not fully repair CAS3+ if the slots are now wrong.

Quick check question (so I don’t guess):

• Is your current issue that the car won’t start (ignition fails) or only that keyless/lock/unlock doesn’t work?
• After your CAS3++ slot swap attempt, do you still have the original BIN/dump saved for CAS3+ before the change?
• Do you know the exact key/slot you were targeting (Slot 2 “Keyless go” / Slot 1 / Slot 3)?

If you tell me those 3, I’ll tell you whether “HiTag2 + CAS coding” is sufficient, or whether you likely need to restore CAS3+ from backup first.

Click to expand...

Marc1907 said:

I still have the original dump file, which contains only the two original keys. I would then replace...

Click to expand...

• Vehicle: model + year + engine (e.g., E70 2011 xDrive50i)
• Confirmation it’s CAS3+ keyless (Comfort Access): yes/no
• CAS3+ hardware/software numbers (from label/ISTA): CAS module HW and SW
• What CAS3++ action you did exactly before: did you “swap key slots” or “swap 2 key slots” (Slot 2/Slot 3)?
• When you say “replace Key 2 within the file”: are you replacing just the HiTag2 transponder data, or are you writing a full CAS3+ key dataset (including authorization/crypto blocks)?

• Unlock via Slot 3 button working suggests the car can see/properly identify that key for CAS-level requests.
• No start indicates the key is not authorized for engine start in CAS/EWS/drive start sense (common causes: wrong key slot dataset, wrong rolling code state, wrong CAS3+ slot mapping, or the key was learned but CAS doesn’t match the programmed state after your dump edit).

• CAS (e.g., “EWS authentication” / “key not authorized”)
• DME/ECU start authorization (if accessible)

Gemini said:

Got it. With unlock works but engine won’t start, that usually means the CAS3+/key authentication for drive start isn’t being authorized (rolling code/crypto state or CAS coding not matching), even if the “comfort” function (lock/unlock) can still respond.

Important: replacing Key 2 inside the original CAS dump is not something that’s reliably safe with CAS3+. If your previous CAS3++ slot swap altered/realigned data even slightly, then the CAS3+ may be inconsistent with what the car expects for start authorization.

To advise correctly, I need these details:

• Vehicle: model + year + engine (e.g., E70 2011 xDrive50i)
• Confirmation it’s CAS3+ keyless (Comfort Access): yes/no
• CAS3+ hardware/software numbers (from label/ISTA): CAS module HW and SW
• What CAS3++ action you did exactly before: did you “swap key slots” or “swap 2 key slots” (Slot 2/Slot 3)?
• When you say “replace Key 2 within the file”: are you replacing just the HiTag2 transponder data, or are you writing a full CAS3+ key dataset (including authorization/crypto blocks)?

What you can conclude right now:

• Unlock via Slot 3 button working suggests the car can see/properly identify that key for CAS-level requests.
• No start indicates the key is not authorized for engine start in CAS/EWS/drive start sense (common causes: wrong key slot dataset, wrong rolling code state, wrong CAS3+ slot mapping, or the key was learned but CAS doesn’t match the programmed state after your dump edit).

Best next step (non-destructive) instead of editing dumps:
Use ISTA/ENET or proper CAS key learning to synchronize/program the replacement key into CAS3+ (and ensure the key is actually authorized for start). Only swapping bytes in a dump often fails after a previous slot modification.

Quick test:
With the new key (Slot 3) attempt to start, do you get an EWS/CAS related fault in:

• CAS (e.g., “EWS authentication” / “key not authorized”)
• DME/ECU start authorization (if accessible)

If you can read codes, paste them (exact text or DTC numbers).

Reply with the vehicle/engine/year and the CAS HW/SW (and tell me whether CAS3++ replaced only “key data” or also the full key structure). Then I can tell you whether your “replace Key 2 in the original dump” plan is likely to work, or whether you should restore/redo key learning instead.

Click to expand...

Marc1907 said:

When I insert the circuit board from Key 3 into the ignition lock, the ignition works—however, it do...

Click to expand...

• Which model/year and engine (e.g., E70 2011, xDrive50i)?
• Are you getting any fault codes? If yes, paste the DTCs from CAS and/or FRM/GM (wording or exact codes).
• With Keyless Go, does it fail completely (no unlock at all), or does it unlock but won’t allow start/“press start”?

• Key slot mismatch for Comfort Access (Key 2 dataset not correctly mapped as “Keyless go enabled” / correct key slot used by CAS).
• CAS3+ Coding not updated after your slot swap (Comfort Access/“number of keys”/keyless go enable flags).
• Antenna/receiver issue (but since inserted start works and only keyless fails, coding/authorization is more likely).

Gemini said:

That points strongly to a keyless go (Comfort Access) authorization/coding problem, not a “key can’t start the car at all” problem.

If the key inserted in the ignition (mechanical/RFID via the lock) starts, then CAS3+/EWS start authorization for that transponder is OK. But Keyless Go uses a different authorization path (CAS Comfort Access / external antenna / slot assignment / CAS coding state). So your edited “Key 2” replacement plan likely won’t just be a simple dump replacement fix.

To get you to the right fix, I need 3 specifics:

• Which model/year and engine (e.g., E70 2011, xDrive50i)?
• Are you getting any fault codes? If yes, paste the DTCs from CAS and/or FRM/GM (wording or exact codes).
• With Keyless Go, does it fail completely (no unlock at all), or does it unlock but won’t allow start/“press start”?

Most common causes on CAS3+:

• Key slot mismatch for Comfort Access (Key 2 dataset not correctly mapped as “Keyless go enabled” / correct key slot used by CAS).
• CAS3+ Coding not updated after your slot swap (Comfort Access/“number of keys”/keyless go enable flags).
• Antenna/receiver issue (but since inserted start works and only keyless fails, coding/authorization is more likely).

Don’t replace Key 2 by editing the dump unless you also re-learn/program keys properly for CAS3+ “keyless go” authorization. Otherwise you can easily end up with exactly your symptom: starts with inserted key, but not with Kessy/Comfort Access.

Reply with vehicle info + whether it unlocks with keyless or only fails at start, and any DTCs, and I’ll tell you the exact module/coding checks to perform.

Click to expand...

Marc1907 said:

No error messages appear. Keyless unlocking and keyless starting do not work with Key 3, apparently ...

Click to expand...

• Vehicle model + year + engine
• CAS3+ HW/SW numbers (from module label/ISTA)
• How many total keys are currently “learned” in CAS (1/2/3) per CAS status
• Did you program Key 3 as a normal key only, or did you explicitly register it for Comfort Access / Keyless Go during learning?
• Which exact operation did you do: “swap slots” in a CAS3++ dump, or did you do proper key programming/learning in CAS?

• Check CAS3+ key list in ISTA/ISTA+ (or the tool you use): confirm that Key 3 is present and assigned to the correct slot index, and whether it has the Comfort Access / keyless authorization flag set.
• If Key 3 is present but marked “not keyless”, then CAS coding/learning is wrong—editing the transponder bytes in the dump typically won’t set the keyless go authorization correctly.
• If CAS coding indicates only 2 keyless keys, you must update that CAS coding/list, not just replace Key 2 data.