6

TL;DR solution

  • Setting 4MHz sample rate and 2Mhz bandwidth in the capture tab (according to the Nyquist theorem the sample rate has to be double the bandwidth)
  • Using the length of a DIP switch position in samples as the samples/symbol parameter
  • Using the DC correction filter
  • Using the generator tab to generate a new refined signal like so:enter image description here

My colleagues and I have taken on a HackRF project for university, using HackRF One. One of the targets is garage door controllers.

We own two controllers with DIP switches for the same door, one has 10 switches while the other one has 12.

The controller has a PIC16C54 chip, broadcasting at 27.015Mhz.

Using hackrf and Universal Radio Hacker we were able to obtain signals from both controllers (top is 10 switches, bottom is 12):

enter image description here We can easily recognize that there is a long wait period after every signal. The DIP switches are 0000111110 and 0000111110000 on the 10-switch and 12-switch controller respectively.

We were able to notice that the long parts of the signal correspond to 0s and the short bursts (probably including some of the 'silence' after them in order to be the same length) are 1s. At this point I am expecting the signal to be like this:

0 1111 0 1111 0 1111 0 1111 0 1100 0 1100 0 1100 0 1100 0 1100 0 1111 0 1100 0 1100

where 1111 is a dip switch set to 0 and 1100 is a dip switch set to one.

Our efforts to replay the signal for the garage door have been futile, even directly in front of it. We tried to import the data in Audacity and normalize the signal in order to get the most power out of it but Universal Radio Hacker does not import it properly from a RAW 8-bit unsigned PCM 48KHz format (this is the expected format right?).

Despite not succeeding in the replay attack with the captured signal from URH without using audacity, the following questions arose:

  • Why are there two short burst (1s) instead of the expected zeroes in the end of the signal?
  • The 10 switches controller has a signal without the two zeroes at the start. The garage code should be 10bit then (?)
  • Why does setting the 12 switch controller's last 2 switches to 1 instead of 0 not open the door?

Are we missing something even more important here?

Edit: the door is not rolling code since we are capturing the same signal on every press (and it's a 30 years old door)

Edit (2): The signal with autodetect parameters is the following:

11111111111111111111111111111111111111111111 011101110111011101100100100100110011101100100 11111111111111111111111111111111111111111111 011101110111011101_001001001001_0011101_00100 11111111111111111111111111111111111111111111 011101110111011101_001001001001_0011101_001(00)

enter image description here

But I believe 2000 samples/Symbol is better since it yields:

111111111111111111111111111111111110110110110110100100100100100110100100 111111111111111111111111111111111110110110110110100100100100100110100100 111111111111111111111111111111111110110110110110100100100100100110100100

The problem is, URH replays samples not bits, so why does the replay not work?

Edit (3): I read that the antennas that come with HackRF are not useful for transmitting in that frequency (27.015Mhz), is this true?

Edit (4): After fiddling around with the URH filters I got some good parameters for the capture of a long press I had named "repeat". The same information is repetitively transmitted for the duration of the press.

enter image description here which resulted in getting from this: enter image description here to this: enter image description here

I have not yet tested the attack. Does the way the signal gets decoded into bits change the way it gets repeated? do the parameters affect repetition too? what about the filters?

Update: Test through the repeat option in Interpretation tab failed (check edit 4).

Edit (4): I just realized I can use the Generator tab... enter image description here

Will test tomorrow and update accordingly!

enter image description here

5k samples/symbol gives desired decoding mentioned by @roscoe but doesn't work for generation

enter image description here

Edit (6): Setting the sample rate to 4M and bandwidth to 2M during recording yielded the following: enter image description here Autodetect seems to have gotten the right values, samples per symbol was manually set to 4000 since that is the approximate width of a symbol:

enter image description here

Simply replaying the signal didn't work, but generating a new signal from the Generator tab with autodetect parameters DID ! enter image description here

Improve this question
3
  • Modern garage door openers use Rolling Code to prevent replay attacks.
    – user10216038
    May 27, 2021 at 18:15
  • There's not enough information to know what type of encoding digital signal is using. Use preplay attack instead. Jam and capture 1st signal. Release 1st signal while jam & store 2nd signal. Now you have an unused 2nd signal to unlock the door.
    – defalt
    May 27, 2021 at 18:48
  • I'm pretty sure it's the same since we have captured several times and the exact same signal appears
    – John St
    May 28, 2021 at 19:32

1 Answer 1

Reset to default
7

I believe both keyfobs send the same data which is

1111 0000 0100

Second keyfob is repeating signal 3 times.

DIP encoding to signal would be byte by byte with swapped nibbles.

00001111 10 =>  11 11 00 00 01

enter image description here

Try to use Autodetect parameters in URH.

Improve this answer
11
  • So the lack of signal does not have to be decoded into 0s? This seems to be right then. Also, any idea why the replay attack is not working? Tried several times with different captures (all of them were the same signal).
    – John St
    May 28, 2021 at 19:36
  • 1
    No - parameters should not affect how signal is transmitted (however it is important that record parameters should be valid, i.e. number of samples - see: en.wikipedia.org/wiki/…)
    – roscoe
    May 31, 2021 at 7:14
  • 1
    Correct. If code is not changing, first try to resend recorded signal. If it works - then try to analyze it.
    – roscoe
    May 31, 2021 at 8:10
  • 1
    IT WORKED!!! simply recording and replaying didn't but generating a clean signal did! Thanks a lot for your help!
    – John St
    May 31, 2021 at 10:48
  • 1
    You welcome!!!!
    – roscoe
    May 31, 2021 at 11:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.