![hackrf one realtime bandwidth hackrf one realtime bandwidth](https://media.springernature.com/lw685/springer-static/image/art%3A10.1007%2Fs11277-020-07080-0/MediaObjects/11277_2020_7080_Fig3_HTML.png)
If you captured at another rate, like 20MHz, put 20000000 here. "custom" sample rate of 8M (since we captured at 8MHz / 8M samples wide). Use right-click, "input->open file." then select the file and set the format to "raw" instead of "auto detect". So we've got a smaller chunk of our file, let's open it up in baudline. The tool "split" can also be used to break the file up into parts. $ dd if=foo.iq of=trimmed.iq bs=1M count=50 skip=50 $ dd if=foo.iq of=trimmed.iq bs=1M count=50 To get the first 50MB of the sample file, So we need to make a smaller file for baudline - fortunately, "dd" handles this very well. My baudline launcher script looks like: !/bin/shĪnd ~/bin/disable/ contains a "file" script which contains simply: !/bin/sh
![hackrf one realtime bandwidth hackrf one realtime bandwidth](https://images-na.ssl-images-amazon.com/images/I/6194QanTrbL.__AC_SY300_SX300_QL70_ML2_.jpg)
This is slow, so a quick fix for that is to alter your $PATH variable before launching baudline. There are a few quirks with baudline - one of them is that it doesn't handle large files (over about 50MB) very well, another is that it runs "file" (the file autotype detection) on any file you provide for it.
HACKRF ONE REALTIME BANDWIDTH DOWNLOAD
Unfortunately the licensing terms for baudline prevent its inclusion in distributions, so you'll need to download it independently. Now we've got a big file of capture data what can we do with it? One good tool is baudline. Better to name it properly to begin with. I suggest naming your files carefully - the capture data itself is raw IQ samples, and doesn't contain any indication of how wide the samples are (8M), what the center frequency is (312MHz), or how it's encoded (for HackRF, all the captures are 8bit). After a few seconds, hit control-c to stop capturing. 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.
![hackrf one realtime bandwidth hackrf one realtime bandwidth](https://www.rtl-sdr.com/wp-content/uploads/2014/08/2014-08-18-20.59.37.jpg)
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 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.