Saturday, 15 March 2014

Jam Intercept and Replay Attack against Rolling Code Key Fob Entry Systems using RTL-SDR

For the past 6 months I have been developing a proof of concept attack against rolling code key fob entry systems. Some examples of affected systems would be the key fob you use to unlock your car.





Or the key fob you use to disarm your home security system.


Or even open the garage door.

The oscillators used in these key fobs are typically low cost, meaning that they may not operate at exactly their design frequency throughout the full temperature range. For this reason, the receiver in the car, or home security system is designed to accept signals within a certain pass band. The trick of the attack is for the adversary to jam at some frequency within the receivers passband, but not too close to the frequency of the remote.




If you jam in this manor, when the victim presses the unlock button on their key fob, nothing will happen because the receiver is being jammed by an adversary. The adversary can then use a SDR such as the RTL-SDR, to record the whole transaction.

The following GNU Radio flow graph could be used in conjunction with the RTL-SDR.



GNURadio makes it easy to filter out the jamming signal and obtain the authorized remote signal.



The signal obtained is the Nth rolling code, it is still valid because the receiver has not yet received the Nth rolling code. Therefore the adversary can replay the signal at a later time and unlock the car. But how does one replay the signal on the cheap?

The system that was constructed looks as follows from a high level.


The signal in this case was ASK (Amplitude Shift Keying) encoded data which was decoded using GNU Radio's "AM Demod" block as follows.


The demodulated signal was then played back through the audio interface of the computer.


The signal was then fed into a LM386 op amp to bring the signal from line level (~1V), up to TTL (~3V). The TTL signal was then fed into an ASK RF module operating at the same frequency as the authorized remote. The schematic for the constructed circuit follows.


And the final product was soldered onto some prototyping board.


The board here is powered by USB, and has a switch on the back right portion of the board. This switch allows you to put the board in either "Jamming" mode, or "Signal Replay" mode. In "Jamming" mode, the RF module will continuously transmit bogus data at the carrier frequency. In "Signal Replay" mode, it will transmit the data provided through the audio jack as an ASK encoded signal at the carrier frequency. A 315 MHz ASK module was used, but this module is inexpensive and could easily be swapped out for say a 400 MHz FSK module. A list of the parts used in it's constructed follows.



Does this system actually work? Frighteningly, yes it does. I was able to test this attack against two economy cars and one van, all of which use rolling code security. 


The attack was successful against all three rolling code secured automobiles. I will finish this post by describing a scenario that is of far greater concern.


In a rolling code garage door system, imagine the following sequence of events. The victim presses the button on the RF remote to initiate the closing of the garage door. The adversary jams and intercepts the signal. The garage door therefore does not close. The victim presses the button on the RF remote again. The adversary jams and intercepts the signal again, but then replays the first signal he/she intercepted. The garage door closes, and the victim leaves the area assuming that their garage door is secure. The adversary then replays the second signal he/she intercepted and the garage door opens again.






22 comments:

  1. Were you able to actually test the attack you describe against the garage door (on the vehicles)? Such attacks are fairly well known and easily defeated by requiring a sequence number as part of the protocol, thus transmitting keys out of order won't work. A possible attack would be to jam both attempts to close the garage door, except after the second attempt replay the first code. So the user sees the door close, but the second code remains valid.

    That type of attack is also well known and defeated by having a clock involved on both ends. But such a countermeasure would be difficult to implement on a cheap fob where the battery needs to last a long time.

    ReplyDelete
    Replies
    1. I was unable to test the attack against my garage door, the particular model I have operates based on phase shift keying at 315 MHz and I was unable to find a cheap module that does PSK @ 315 MHz. I could construct one, however I wanted to keep the build to be a simple proof of concept. The price of a SDR is falling and eventually there will be no need for custom hardware for replay. It works on the three vehicles as they operate at either 315 MHz or 434 MHz with ASK.

      I agree, manufacturers are just looking to keep everything cheap and simple. The bidirectional PKES keyfobs have their own issues, and I wonder sometimes if they are even a step forward.

      Delete
  2. Hi, really cool hack. There's one point that's not quite clear regarding the last paragraph. If the key fob has separate lock and unlock button then the ability to jam two commands, to be able to repeat the second one later seems useless. You can lock again something that's been already locked.

    ReplyDelete
    Replies
    1. True, however if you jam for long enough, you will eventually be able to collect an unlock signal when the victim gets frustrated.

      Delete
  3. Hi really interesting work. What if you jam at the same frequency as the fob? Probably you will not be able to filter out the jam signal, how would you solve this?
    I was thinking, if you would use a patron for you jam signal, like a pulse every 25% of the key length, you could minimize the amount of possible codes to a hand full. Because you would knockover only a few bits, that can be quest afterwards. In this way cheap electronics can be used. What do you think about this?

    ReplyDelete
    Replies
    1. You can technically jam at the same frequency of the fob. The resultant signal will just be the superposition of the two signals. Since you know exactly what the jamming signal looks like, you can then subtract the jamming signal to obtain the authorized remote signal.

      This of course is overkill because I can jam at say 315.15 MHz, while the remote is transmitting at 315.16 MHz, and still be able to filter by frequency and obtain the original signal.

      This would work, and in fact my first revision of the hardware was capable of doing this. The issue is that it requires you to have knowledge of what the protocol is. Protocol information is not hard to find online, however it adds a significant amount of time to the whole process. That is why with this revision I moved to more general hardware that would work for a larger class of systems.

      Delete
  4. Whats the value on the ceramic capacitor?
    And what i understand this is a manual process and it require you to know the frequens of the key? Can it be written to a automatic python software?

    ReplyDelete
    Replies
    1. In retrospect, you can get away without using the ceramic capacitor. I do not own an oscilloscope, so that ceramic capacitor was in there from the testing stages when I would hook up a speaker and test the circuit by listening to the output.

      Yes, this requires you to more or less know the frequency of the key. There are only a handful of frequencies that these key fobs operate at though.

      Yes. The first version of the system was purely digital and automatically picked up on when someone pressed their key fob. A few GNURadio blocks had to be written to make this work though. It is beyond the abilities of the average joe.

      Delete
  5. Can you share your flow graph files? Thanks!

    ReplyDelete
  6. This comment has been removed by the author.

    ReplyDelete
    Replies
    1. This comment has been removed by the author.

      Delete
  7. Hello Spencer,

    I have been searching for the right info to implement a proof of concept on decoding the key fob signals and possibly reverse engineer the encryption key.

    Finally found the right place...

    I am new to SDRs...
    Could you please guide me to the required software resources to work with the DSR -RTL for signal capture, demodulation and decoding

    many thanks

    ReplyDelete
    Replies
    1. Hey,

      Everything software side was done in GNURadio, here is the best place to start: http://gnuradio.org/redmine/projects/gnuradio/wiki

      If you are looking for more information on the specifics of attacking these systems, you can check out:

      http://people.scs.carleton.ca/~barbeau/Honours/Spencer_Whyte.pdf

      Delete
  8. can you upload a video tutorial of how to program the components?

    ReplyDelete
  9. I was trying to do Jam intercept and replay according to your instructions. In the beginning it went very well, I got the signal, made Raw_Jammed file with all data. When next making Raw_De-jammed file, after many tries GNU Radio still gives me this - Firdes check failed.

    Could you kindly help me with this? (I am using HackRF, GNU Radio 3.7 and Linux Ubuntu 14.04.).

    Here is my output:

    File "/home/..../top_block.py", line 55, in __init__
    1, samp_rate, 500, 22000, 250, firdes.WIN_HAMMING, 6.76))
    File "/home/linux/target/lib/python2.7/dist-packages/gnuradio/filter/filter_swig.py", line 155, in band_pass
    return _filter_swig.firdes_band_pass(*args, **kwargs)
    RuntimeError: firdes check failed: 0 < fb <= sampling_freq / 2

    Please help me to look into this, what should be done to fix this Firdes error?

    BR,

    Iluta

    My mail: iluta2009@gmail.com

    ReplyDelete
    Replies
    1. The error says that your upper frequency parameter to the filter does not make sense with the sample rate you are using.

      What is the sample rate on your graph?

      What is the upper frequency on the filter block you are using?

      Delete
  10. Thank you very much for your response! For Nth Rolling code flowgraph I'm using:

    Throttle - Sample rate 40e3
    Band Pass Filter - Sample rate 40 mhz, high freq 22e3, low 500

    Upss..I see a mistake - Filter upper frequency (22e3), cannot be lower than sample rate (40e3)...? Or there is anything else I cannot see?

    (Forgive my asking, since I'm not at all IT or radio specialist). All self learned and just recently. :D

    ReplyDelete
    Replies
    1. So if you look at the last line of the error, it says that there is a problem with the following check:

      0 < fb <= sampling_freq / 2

      Now if you substitute the values that you provided...

      0 < 22e3 <= 40e3 / 2
      0 < 22e3 <= 20e3

      You will notice that the inequality above does not hold. Therefore the check fails. Try increasing your sample rate on the throttle, or decrease the upper limit on your band pass filter to something less than 20e3.

      Hopefully I am interpreting your error message correctly. Let me know how it goes!

      Delete
  11. This comment has been removed by the author.

    ReplyDelete
  12. Yes, it works starting up with the lowest Throttle sample rate 44e3, which is logical as sample rate freq 44 / 2 = 22. I even didn' t touch filter limit, didn' t see need for it, since raising them accordingly to sample rate will be OK. Now:

    1. Raw Dejammed file FFT plot shows these very extremely low noises -70 to -100 db? Was it all I got when I picked up in my Raw Jammed file and got as output in Dejammed as well, though I tuned in to 315 mhz initially.

    2. Of course, AM Demod My Attempt file FFT plot shows noise -60 to -130 db.

    Where went my 315 mhz signal...? (I had a good reception, and before checked signal on Constellation plot, it was quite ok).

    ReplyDelete
  13. I added to Get Remote file both Throttle and Constellation sink, and I made my key fob at 868 mhz visible and written to a file. (throttle sample rate 1e6).

    Then made it as Dejammed File (Throttle rate 44k).

    Then Raw Dejammed to AM Demod file (Throttle rate 100e3).

    Could this be that failure to get a decent signal back could be because of:

    1. Different Throttle sample rates.
    2. Making wav file in the end, and not deciphering to Quadrature and Bits?
    Or I might as well missed something.

    ReplyDelete