BMW Display Key Fob Data Capture

I was about to polish some SDR knowledge and try to capture a - for me unknown - device emissions and see if I could convert that to 'real' data.

The one thing on my desk was a BMW display key fob so let's go for it! 🏃‍♂️‍➡️

Firing up the usual suspects: SDR++ for a first capture with a logarithmic antenna. Fair enough I need to mention that I looked up some details of the key from the interwebs:

When turning the display key on/awaking it from sleep by pressing the side button, it immediately starts to send some bursts centered around 433.200 MHz.

Looks good enough! So off to Gnuradio Companion it goes... 📻

Not going into too much details here but what we do basically is:

  • Using a Low Pass Filter to limit the signal to the bandwidth of the the key.
  • Detect the envelope and demodulate the ASK Signal using a Complex to Mag block.

Complex to Mag gives us a nice output:

 From there we feed this into a

  • Threshold Block which creates zeroes and ones
  • Clock Recovery MM in order to ... well recover the clock and extract a clean binary signal

After that we just shift the binary graph halfway down so we get positive values for a 1 and negative values vor a 0 in order for the

  • Binary Slicer to produce a bit output
  • Custom python script printing the values.

The overall graph looks like this:

Since clock recovery seems never to do what expected, having acquired the Complex to Mag signal and put it into a file sink of Float32, we could go other routes:

inspectrum

A very nice tool for visualising recorded data, derive amplitude and threshold plot ans measure signal changes with cursors:

URH

URH (Universal Radio Hacker) is pretty awesome when it comes to decode radio signals. It takes all the heavy lifting off the job to get to the bits and reverse engineer the contents of the signal:

No matter which route taken, the extracted data packages look something like this (in HEX):

e72d2ce9a5d3950000
e65a565aa739674e752ae7353a95a5959a9cea940000
e65d2e69d2e9950000
e72d2b96a9ce5ce9cd4ab99d4d4ae96567539d528000
e65a59d3a5a72a0000
ce5d2b2d539cb9a73995739d4d4ae972b3a969ca8000
c0
e72e973a74b4cab9556a55555555556aa695673a9d4ad2e573a90000
e72d2b96a99cb2ce5555555555d2aaaaaaab95a72b2ba5a55ce800
e0
ce5a59d34b4e55caaba95555555555d54e55666a752ba5959d480000
e72d2b96a9ce59739555555555695555556732b2e74b9d334e748000
e0
e72e973a69699572aaea55555555557552cab335352ba5cae7520000
e72e9596a99972e72aaaaaaaaad2aaaaaab4ba9cccd52e5caaa80000
c0
ccb4b9d3a5a72acaab52aaaaaaaaab552aab9cd4ea56972b3a900000
e65a565aa73972e65555555555a555555559ce673a72ea9754d20000
e65a59d3a5a72a0000
ce5a565aa739669a72ab9cd4d4ad2e57352acca000
ce5a59d3a5d3950000
ce5d2b96a9ce59d39a956735352ba5cae7539aa50000
ce5a59d34b4e540000
ce5a572d5339674e732ace6a6a569656752e99500000
e72e9674d2e9950000
ce5a565d539cb3a73a95673a9d4ad2cae6a7354a0000
ccb4b9a6974e540000
ce5a572d539cb34e6655ccd4ea56972b3a969ca80000
ce5a59d3a5a72a0000
ce5d2b96a99cb9d39a8ab39d4ea5696573a9cd528000

The data looks somewhat valid without knowing the protocol and the expected payload. For sure there is some rolling code implementation involved as well as some other neat techniques in order to prevent cars from being stolen (at least by evil key fobs).

Looking at the signal it looks like every single sequence has a bunch of 0-1 alternations. My assumption this is a preamble for clock syncing/recovery on the receiving side.

So far I only found two variations of the 8 bit following the preamble. This looks like a sync word and is either

11100111

or

11001100

There are some form of delayed replay attacks which seem still to work (capturing the sent data but not letting it go through to the car, then replaying it). The most preferred way nowadays seem to be to mingle with the CAN bus of the car. At last if the two wire CAN bus can be easily attached to from the outside world without tearing the car apart.

On a side note: I had some issues creating a Python Block in gnuradio since it could never find a text editor. This really sucks as getting a smooth running instance of gnuradio seems to be pain on OS X. Nonetheless for the collective memory: 

A fixed editor needed to be put in the grc.conf (and not the one in home/.gnuradio but the general one of the installation). Some editors seem to work, some don't so at the I figured TextMate works quite good:

[grc]

editor = /opt/homebrew/bin/mate