Leave hackrf_transfer running for a while, while pressing the lock (or unlock) button on your key fob a few times. Recent firmware has made this significantly smaller, but it's still easy to avoid entirely, so lets do that. Since we're capturing 8MHz wide, we'll get our signal, but by offsetting from center we avoid the DC offset which causes a spike at the center of the HackRF tuning band. Notice we're capturing slightly off-center from 315MHz. The quickest way to do this is hackrf_transfer: So we know something is going on now we want to record it. So, now we know where to look - what do we do with that? First off, I fired up GQRX to get an idea of what was going on pressing the keyfob returned data (sorry, don't have a screenshot handy of that specifically, but here's an example of gqrx capturing OOK data): It turns out Kia runs at 315MHz, while Toyota and Subaru run at 433.847MHz (for many models, at least). To start with, I did some searching to find out what frequency they operate at. It's definitely an area where more research is needed. I wouldn't assume they've all implemented this properly, of course, as some conferences and speakers are pointing out. For my testing I used a 2006 Subaru keyfob, and my friend's Kia keyfob - they use different encodings, so this is a fairly interesting test.īeyond academic interest, keyfobs may not be that useful to play with - they (should) all use rolling codes so that a captured unlock sequence can't be used more than once. They're something everyone has, and tend to put out a nice clean signal.
I've been wanting to play around with my car keyfobs for a while mostly out of idle curiosity. The expected output with no clock detected is -> 0x51.The HackRF is on Kickstarter, so here's a little write-up of some of the awesome stuff yo can do with it, and why you should go get one. The expected output with a clock detected is -> 0x01. To verify that a signal has been detected on CLKIN, use : hackrf_debug -–si5351c -n 0 -r The switch to or from CLKIN only happens when a transmit or receive operation begins.
HackRF One uses CLKIN instead of the internal crystal when a clock signal is detected on CLKIN. You may directly connect the CLKOUT port of one HackRF One to the CLKIN port of another HackRF One. Do not connect a clock signal at a frequency other than 10 MHz (unless you modify the firmware to support this). Do not exceed 3.3 V or drop below 0 V on this input. The CLKIN port on HackRF One is a high impedance input that expects a 0 V to 3 V square wave at 10 MHz. The signal is a 10 MHz square wave from 0 V to 3 V intended for a high impedance load. HackRF One produces a 10 MHz clock signal on CLKOUT. Instead of using an internal TCXO, you can use an external clock.
Sudo apt-get install hackrf HackRF external clocks To install the hackrf package under Raspbian or Armbian:
If the answer is: -> Ox01 perfect TCXO taken into accountĪs a reminder, you can find out more about your hackRF with the command: If the answer is: -> Ox51 no TCXO taken into account In a terminal window type: hackrf_debug -–si5351c -n 0 -r If your HackRF is connected to a Raspberry PI or an Orange PI under Linux and you have installed the hackrf package you can test that the TCXO is taken into account. For HackRF mounted in a black metal box, there is a model of TCXO reduced in height to be able to install.