- 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:
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):
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
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)
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.
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).
Will test tomorrow and update accordingly!
5k samples/symbol gives desired decoding mentioned by @roscoe but doesn't work for generation
Edit (6): Setting the sample rate to 4M and bandwidth to 2M during recording yielded the following: 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: