His first steps were to search for the frequency which he found active at 390 MHz. He then moved on to analyzing the signal with Inspectrum, discovering the OOK modulation, then working his way towards the binary control strings. One thing that helped with his reverse engineering was the use of the 9-bit DIP switches on the remote that configure the security code that opens up a specific door as this allowed him to control the transmitted bits, and determine which bits were used for the security code. With this and a bit of GNU Radio code he was able to recreate the signal and transmit it with his HackRF.
Finally Maxwell wanted to see how vulnerable this door is to a brute force attack that simply transmits every possible security code. Through some calculations, he discovered that brute forcing every possible security code in the 9-bit search space would only take 104 minutes to open any garage using this opener.
Most interestingly the software works via the WebUSB interface, which allows for USB devices like a HackRF SDR to connect directly to the software through USB via the Chrome web browser. So no external app or software needs to be downloaded, all you need to do to run the code is open the hosted aprs-sdr page at https://xakcop.com/aprs-sdr with a Chrome browser, and connect the HackRF to your device.
Radoslav writes further:
The tracker is using the HTML Geolocation API to fetch the device’s location and WebUSB to talk with the SDR. The code which generates the packets is written in C++ and compiled to WASM. You can find the source at https://github.com/rgerganov/aprs-sdr.
And now to some results. I have successfully transmitted packets from my home to LZ0DOE (15km away!) using my Pixel phone, HackRF and ANT500. I find it amazing given the low TX power of HackRF.
Radoslav also notes that in the future he hopes to add other SDRs as well. He also notes that the script seems to work best on desktop Chrome. On mobile Chrome there may be a bug which stops transmission after a few packets.
Over on the Great Scott Gadgets blog Michael Ossmann, the lead creator of the original HackRF has put out a post comparing his original HackRF with one of the many clones on the market. The HackRF is a low cost wideband transmit capable SDR that was released via Kickstarter crowd funding back in 2014. Even up until today it is one of the most popular SDRs for radio experimenters due to it's versatility, open source nature, and low cost.
Within the past few years Chinese clones of most SDRs including the HackRF have appeared on the market often at substantially reduced pricing. As the HackRF is fully open source hardware, copies are legally allowed, however buying a clone does not support the original developer and can put strain on their support services. The general consensus amongst clone purchasers is that they work fine, but when there are problems you take the risk of not being able to expect any sort of support or warranty from the the cloner. Also while the clones work fine, up until now we have not yet seen any performance comparisons yet.
In his post Michael Ossmann tests a clone which is even advertised to have improved upon the original design. Michaels post goes into more detail, but long story short, the clone has clear transmit performance issues above 1 GHz, and at the worst point produces 22 dB (150x) less power out compared to the original. In terms of receive performance the clone performs even worse, showing very poor sensitivity when compared to the original. Michael notes that this clone would not have passed the QC procedure used for the original.
We believe that the original HackRF has created significant value to the RF community through software, tutorials and their hardware. Over the years countless projects and research/conference papers have been enabled by the HackRF. So even regardless of potential performance and warranty issues we think it is ethical to support the original creators if your budget allows it.
A few weeks ago we posted about Reddit member u/OlegKutkov who used his HackRF supercluster to receive Starlink beacons, but details on the HackRF supercluster project itself were a little sparse. Now Oleg has posted a full description about the HackRF supercluster, noting that the 8 HackRF's in the system can provide up to 160 MHz of live monitoring bandwidth.
Oleg shows how each of the boards are connected to the same GPS disciplined 10 MHz clock source, how it uses an RF splitter with LNA and how it requires 8 separate host controllers connected to individual PCIe lines in his computer system to overcome the USB2.0 data bandwidth limits. He also shows the GNU Radio script he's created that combines the 8 sources into one.
Oleg writes how he's using the HackRF supercluster together with a TV Ku-Band LNB and satellite dish for wideband satellite monitoring.
In the latest video on the Signals Everywhere YouTube channel, Sarah investigates how a PlutoSDR can be used as a Spectrum Analyzer with the SATSAGEN software. The SATSAGEN software is able to work as a spectrum analyzer by rapidly sweeping over multiple frequencies and stitching the spectrum slices together. It support SDRs like the HackRF, PlutoSDR and RTL-SDR (in receive mode only). The PlutoSDR can transmit, so it is able to work as a full spectrum analyzer with tracking generator, allowing users to measure RF devices such as filters, tune antennas, and work as a frequency generator.
In the video Sarah demonstrates how to use the PlutoSDR and SATSAGEN to measure our RTL-SDR Blog Broadcast FM filter, and to tune our multipurpose dipole antenna.
Spectrum Analyzer and Tracking Generator with Pluto SDR
Over on Reddit member u/OlegKutkov has recently posted about his success at receiving Starlink beacons at 11.325 GHz with his HackRF "supercluster". Starlink is an Elon Musk / SpaceX venture that aims to provide fast global satellite internet access for low cost. The venture is advanced enough that in most locations the service is now operational, and there will be Starlink satellites in the local sky at any given time.
Oleg's setup to receive the satellite beacons consists of a small hand tracked satellite dish with LNB feed connected to his HackRF "supercluster". The supercluster is 8 HackRFs connected to the same antenna via a splitter, resulting in 160 MHz of bandwidth. Oleg's blog post from last year appears to contain a bit more information about the start of the supercluster. The 11.325 GHz beacon frequency is out of range for the HackRF which covers up to 6 GHz, so a standard satellite TV LNB is used to downconvert the frequency. The LNB had to first be converted to circular polarization, and is fed via an 'invacom' feedhorn.
Update Notes: Thank you to @dereksgc for pointing out that the HackRF supercluster and modified LNBs aren't actually required to receive Starlink beacons. Derek notes that the Starlink beacons are actually very easy to receive. All you need is an RTL-SDR V3 and a stock "astra" LNB (or the Bullseye LNB) which will convert the 11325 MHz beacon frequency to 1575 MHz which is in the range of the RTL-SDR. The bandwidth of the beacons including doppler shift is also small enough for the RTL-SDR. The beacons are circularly polarized, but strong enough to be received with an unmodified linear LNB and small offset TV dish. So receiving the beacons is possible with modest hardware, provided you have a way to power the LNB. Oleg's setup appears to be gearing up to receive the actual wideband data from Starlink, or some other wideband satellite signals.
In the spectrum waterfall image, the doppler shift of the beacons is clearly visible due to the speed at which the satellites orbit.
More information about his setup is available from his followup Reddit comment and the Twitter links he provides there. You can also visit his Twitter directly at @olegkutkov where he shows more images of his HackRF supercluster and the hardware he' using.
In the past we've posted about how IU2EFA and Jan de Jong were able to track the Starlink satellites via an alternative means involving reception of the European GRAVES space radar being reflected off the satellite body.
The idea behind the attack is that ethernet cables can act as an antenna, leaking signals at frequencies which can easily be sniffed by a SDR. The specific technique in the paper does not decode normal network traffic, instead it requires that malicious code which modulates a custom signal over the ethernet cable be installed on the PC first. The technique used appears to be similar to what the Etherify software by SQ5BPF uses, which modulates data in morse code by turning the network card on and off.
Remote SDR V2 is software that allows you to easily remotely access either a PlutoSDR, HackRF or RTL-SDR software defined radio. It was originally designed to be used with the amateur radio QO-100 satellite, but version 2.0 includes multiple demodulation modes, NBFM/SSB transmission capability, CTCSS and DTMF encoders, modulation compression and a programmable frequency shift for relays.