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.






14 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
  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