[wawtor]

[GUIDE/WRITEUP] Unlocking the NBT Evo Hard Drive Without the Car — How I Cracked the ATA Password

---

So this all started when I swapped the hard drive in my 2016 M235i's NBT Evo head unit for an SSD. Nothing crazy, just was bored. But once I had that original drive sitting on my bench, I got curious. It had BMW's entire iDrive filesystem on it — and I started wondering: could I browse it? Maybe swap out boot animations? Poke around the UI assets? Even just see what's on there?

Turns out that was way easier said than done.

---

THE LOCK

As soon as I connected the drive to my PC, nothing. No partitions, no filesystem, just a brick. Turns out BMW locks the drive using ATA Security — a feature built into the SATA spec itself, at the hardware/firmware level, completely below the OS. Every read and write command gets rejected until you send the correct unlock command with the correct password. There's no workaround, no live boot that bypasses it. The drive is simply a paperweight until it's unlocked.

After some digging, I found the same three or four threads floating around the forums. They all said the same thing: the password is derived from three values pulled from the head unit's adjustblock (accessible over SSH):

- Ethernet MAC address (E2P.Networking.Eth0MacAddr)
- Bluetooth MAC address (E2P.Networking.Bt0Addr)
- Unit serial number (E2P.ProdLogistic.SerialNo)

Great. I had all three. Job done, right?

Wrong.

---

WHAT THE FORUMS GOT WRONG

Every thread I found stopped there. "Combine those three values and that's your password." No further detail on how to combine them. A couple of posts implied it was just a straight concatenation of the strings. I tried that. Didn't work. Tried various formatting permutations. Nothing.

Here's what's actually happening under the hood — and what nobody seemed to document properly:

The three values aren't used as-is. They go through a specific derivation process:

1. Each value is hex-decoded from its string representation into raw bytes (the serial number in
particular looks like 00334633313131343338 — that's hex-encoded, not the human-readable
string on the sticker)
2. The raw bytes are concatenated in order: ETH MAC → BT MAC → Serial
3. An MD5 hash is computed over those concatenated bytes, producing 16 bytes
4. The first 15 of those 16 bytes are Base64-encoded, producing a 20-character ASCII string
5. That 20-character string is the ATA password — written into a 512-byte security buffer at
offset 2, then sent to the drive via ATA SECURITY UNLOCK (command 0xF2) through
SCSI/ATA Translation

That Base64 step is the part that kills you if you don't know about it. The raw MD5 output is binary data — you can't just type that into hdparm. Base64 encoding it is what turns it into a usable ASCII password, and the spec truncates to the first 15 of the 16 hash bytes before encoding, which gives you exactly 20 characters.

---

THE TOOL

Once I figured this out, I wrote a small Python GUI that handles the whole thing:

- Input your ETH MAC, BT MAC, and serial number
- It derives and displays the password
- It can issue the ATA SECURITY UNLOCK directly from the interface
- After a successful unlock, it shows you the exact hdparm command to permanently remove
the password if you want

One important note: the unlock is temporary by default — it resets on power cycle. If you want to permanently remove the ATA lock (so the drive works like a normal drive going forward), you run:

sudo hdparm --security-disable "<password>" /dev/sdX

The tool outputs that exact command for you after unlocking.

---

A FEW THINGS WORTH KNOWING BEFORE YOU TRY THIS

On getting your values: SSH into the head unit and run:

sysetadjread --get=E2P.Networking.Eth0MacAddr
sysetadjread --get=E2P.Networking.Bt0Addr
sysetadjread --get=E2P.ProdLogistic.SerialNo

Use those exact outputs, don't reformat them. The serial especially must be the raw hex string.

On connection: The drive must be connected via a direct SATA port — not USB. ATA Security
commands require direct ATA passthrough. A USB adapter will silently drop the command.

On frozen state: If your drive is reporting as "frozen" (you can check with
sudo hdparm -I /dev/sdX), the security commands won't work. Cold boot the PC with the drive
already connected to get past that.

On failed attempts: The ATA spec has a built-in attempt counter. Too many wrong passwords and
the drive locks out until the next power cycle. Don't guess. Get your values from the unit first.

On reinstalling: If you permanently remove the password and later put the drive back in the car,
the head unit may log errors or behave oddly. Before reinstalling, you can re-apply the password
with hdparm --security-set-pass using the same derived password — the tool shows you that
command too. Note: I haven't reinstalled the drive myself, so I can't confirm whether removing
the password causes issues. Either way, make sure you save the derived password somewhere
before doing anything permanent.

---

REQUIREMENTS

- Linux (this doesn't work on Windows/macOS — ATA passthrough needs direct SATA access)
- Python 3
- hdparm
- Drive connected via SATA (not a USB adapter)

---

I've tested this on the NBT Evo (HU_NBT2) from my 2016 M235i, running iStep 18-03 (ID5/6).
If your car uses the same NBT Evo hardware, this should work for you. I can't confirm whether
this applies to the standard NBT or any other head unit variants.

The tool itself is currently in a private repo — if there's enough interest here I'm more than happy
to open it up. Let me know in the replies.

Happy to answer any questions.

[Kernel Kurtz]

Interesting, thanks for sharing.

I'm more curious if the SSD swap worked. If there are elements of iDrive on the removed one you would not think the replacement would work without cloning that data first, or now that you have looked is it just dumb storage? Then the obvious question if a working SSD gives any noticeable improvement to the user experience....

[BringBackButtons]

Do you have to be careful on what ssd drive you choose and match partition size? In the CIC days, the sata drive replacements were limited to very specific models for some reason I cant remember....and also needed to be more resilient to the heat Not sure if thats applicable to nbt evo.

CIC limited allocated space for music library was only like 22gb no matter the size. Im not sure if the hex value allocating this could be adjusted or not but I recall people running into not much benefit other than a second or two faster booting.

I also believe Idrive is a derivitive of blackberry os. Im sure its moved on from there since ccc or cic, but its roots stem from that Ive read which would make sense on the ssh.

This was a good post, thanks for bringing me back to ssh sudo hex days. They werent long, but it was fun tinkering back then.

[wawtor]

Originally Posted by Kernel Kurtz

Interesting, thanks for sharing.

I'm more curious if the SSD swap worked. If there are elements of iDrive on the removed one you would not think the replacement would work without cloning that data first, or now that you have looked is it just dumb storage? Then the obvious question if a working SSD gives any noticeable improvement to the user experience....

The swap worked fine. I cloned the original drive and burned the image to the SSD before installing it, so everything was already in place when the unit booted.

From what I can tell, the drive holds more than just maps and media, a good amount of the OS lives on it.

As for speed, I did not notice any real improvement after switching to SSD.
I cloned the drive rather than testing a blank one, so I cannot say exactly what happens if you try to boot without it. But it is definitely not just dumb storage.

Speed-wise, I have not noticed any real improvement. Even though so much runs off the drive, the unit does not seem to get any faster with an SSD, at least in my experience.

[wawtor]

Originally Posted by BringBackButtons

Do you have to be careful on what ssd drive you choose and match partition size? In the CIC days, the sata drive replacements were limited to very specific models for some reason I cant remember....and also needed to be more resilient to the heat Not sure if thats applicable to nbt evo.

CIC limited allocated space for music library was only like 22gb no matter the size. Im not sure if the hex value allocating this could be adjusted or not but I recall people running into not much benefit other than a second or two faster booting.

I also believe Idrive is a derivitive of blackberry os. Im sure its moved on from there since ccc or cic, but its roots stem from that Ive read which would make sense on the ssh.

This was a good post, thanks for bringing me back to ssh sudo hex days. They werent long, but it was fun tinkering back then.

For NBT Evo, you do not need to match the original drive model exactly. I have read that the Evo is not as particular with drives like earlier units. As long as the SSD is at least as large as the original, it should work; any extra space is ignored. I am unsure if the partitions for the music library are still limited, but that is something I might have to look at. And yes the OS is still based on QNX.

Glad you enjoyed the post!