Category: Applications

Cheating at Pokémon Go with a HackRF and GPS Spoofing

“Pokémon Go” is the latest in smartphone augmented reality gaming crazes. You may have already heard about the game on the news, or seen kids playing it in your neighborhood. To play, players must walk around in the real world with their GPS enabled smartphone, collecting different virtual Pokémon which appear at random spots in the real world, replenishing the virtual items need to collect Pokemon at “Pokéstops” and putting Pokémon to battle at “Gyms”. Pokéstops and gyms are often city landmarks such as popular shops, fountains, statues, signs etc. For those who have no idea what “Pokémon” are: Pokémon are fictional animals from a popular children’s cartoon and comic.

Since the game is GPS based, Stefan Kiese decided to see if he could cheat at the game by spoofing his GPS location using a HackRF software defined radio. When playing the game, players often walk from Pokéstop to Pokéstop, collecting Pokémon along the way, and replenishing their items. By spoofing the GPS signal he is able to simulate walking around in the physical world, potentially automating the collection of Pokémon and replenishment of items at Pokéstops.

To do this he used the off the shelf “GPS-SDR-Sim” software by Takuji Ebinuma which is a GPS Spoofing tool for transmit capable SDR’s like the HackRF, bladeRF and USRP radios. At first, when using the software Stefan noticed that the HackRF was simply jamming his GPS signals, and not simulating the satellites. He discovered the problem was with the HackRF’s clock not being accurate enough. To solve this he used a function generator to input a stable 10 MHz square wave into the HackRF’s clock input port. He also found that he needed to disable “Assisted GPS (a-gps)” on his phone which uses local cell phone towers to help improve GPS location tracking.

Next he was able to use the GPS-SDR-Sim tools to plot a simulated walking route and see his virtual character walking around on the real world map. A warning if you intend on doing this: Remember that 1) spoofing or jamming GPS is highly illegal in most countries outside of a shielded test lab setting, so you must ensure that your spoofed GPS signal does not interfere with anything, and 2) the game likely has cheating detection and will probably ban you if you don’t simulate a regular walking speed.

GPS spoofing is not new. One attempt in 2013 allowed university researchers to send a 80 million dollar 213-foot yacht off course, and it is suspected that hackers from the Iranian government have used GPS spoofing to divert and land an American stealth drone back in 2011. In past posts we also showed how security researcher Lin Huang was able to spoof GPS and bypass drone no fly restrictions.

[Also seen on Hackaday.com]
The "Pokemon Go" GPS spoofing set up.
The “Pokemon Go” GPS spoofing set up.

Using the Airspy as a Network Analyzer for Characterizing Antennas

Over on YouTube user Mile Kokotov has uploaded a very nice tutorial video that shows how the Airspy can be used as a low cost scalar network analzyer from between 0.1 – 1800 MHz. A network analyser allows you to characterize the performance of antennas, by determining the antenna SWR curve. A low point on an SWR graph indicates the frequency at which an antenna is resonant/tuned, so a network analyzer is very useful for tuning homemade or adjustable antennas.

Dedicated scalar network analyzers can costs thousands of dollars. Together with a cheap noise source and cheap directional coupler, the Airspy can be used as a very low cost scalar network analyzer for analyzing antennas. If you are interested in this we also have a similar tutorial on our blog that shows how to do this with an RTL-SDR. However, the Airspy R2 or Mini is of course a better tool for this job as it can scan the spectrum much faster than the RTL-SDR with its Spectrum Spy software. Mile writes:

In this video I am showing how Airspy SDR can be used for measuring Return Loss, Antenna SWR and Antenna Bandwidth of several commercial and homemade antennas.

The impedance of the Radio Station (transmitter or receiver) must be well matched to the antenna’s impedance if we want maximum available power to be delivered to antenna.

The return loss and SWR measurements show us the match of the system.

A poorly matched antenna will reflect costly RF energy which will not be available for transmission and will instead end up in the transmitter. This extra energy returned to the transmitter will not only distort the signal but it will also affect the efficiency of the transmitted power and the corresponding coverage area.

Return Loss and SWR both display the match of the system, but they show it in different ways. The return loss displays the ratio of reflected power to reference power in dB.

The return loss view is usually preferred over the SWR linear scale, because is easier to compare a small and large number on a logarithmic scale.

More than 20 dB system return loss is considered very efficient as only less than 1% of the power is returned and more than 99% of the power is transmitted. In that case the SWR is around 1.2

For radio amateur usage, Return loss more than 14 dB is acceptable. This is adequate to SWR of 1.5 which means that 4% of the power is returned and 96% of the power is transmitted.

0 dB Return loss represent an open or a short antenna terminal, while 45 or more dB Return loss would be close to a perfect match.

Many different methods can be used to measure standing wave ratio. Professionals usually use a vector network analyzer or frequency analyzer with sweep signal generator and directional coupler.

In this video I will show you very cheap and very good method for antenna characterizing which means measuring the Return loss versus frequency and usable antenna bandwidth like measuring with much, much more expensive, state of the art Network Analyzers and similar measuring equipment.

https://www.youtube.com/watch?v=EDbS-zlLPxw

EDIT: It has been pointed out that we incorrectly used the term vector network analyzer in the previous title, when we should have instead used scalar network analyzer. A scalar network analyzer can measure amplitude, but a vector network analyzer can measure amplitude and phase and is a more complex device. Apologies for any confusion.

IBM’s Horizon Decentralized Autonomous Edge Compute using RTL-SDR

IBM’s “Horizon” is an Internet of Things (IoT) networking technology based on decentralized peer to peer technologies that are already used in successful apps like BitCoin and BitTorrent. It works by using a Horizon app which accesses your local data and sends and receives data from the Horizon P2P system. Currently Horizon is an experimental project, but they already have up and running two proof of concept projects that utilize the RTL-SDR.

In their first RTL-SDR based proof of concept demonstration they show how they have used the RTL-SDR to create a decentralized Horizon based ADS-B aircraft tracker which runs on a Raspberry Pi 2. A Horizon user can contribute data to the cloud and the data will be aggregated from users all over the world to create a complete map of aircraft. To see data from current contributors go to bluehorizon.network/map/.

ADS-B data received by IBM Horizon servers.
ADS-B data received by IBM Horizon servers.

The second RTL-SDR based proof of concept is a radio spectrum analysis application which scans the spectrum from 24 MHz to 1.75 GHz and sends the waterfall data to the cloud. This also runs on the Raspberry Pi 2. You can contribute spectrum to the cloud and you can also search the cloud for a device anywhere in the world that will allow you to listen to its RTL-SDR server. Currently the implementation allows you to view the waterfall of a remote RTL-SDR server and capture a 30 burst of audio from any frequency.

Remote Radio Scan with IBM Horizon and an RTL-SDR.
Remote Radio Scan with IBM Horizon and an RTL-SDR.

To try the radio spectrum app on a real server go to bluehorizon.network/map/, click the cog icon in the top left and deselect everything but the ‘sdr’ check box. Then search the map for an SDR (there are only contributors in the USA and one in Germany at the moment), click on the blue dot, and select the radio tower icon that pops up. In the new screen you can use the mouse wheel and click and drag on the mouse to move the frequency. You can use the capture waterfall and Radio capture buttons on the left menu. After clicking the button the job will take a few seconds to run and complete.

It will be an interesting future when SDRs all over the world are accessible on the cloud and this could lead to many new interesting applications. Apart from RTL-SDR based applications, they are write about using Horizon to share weather station data, and to measure internet network speed.

IBM Horizon data flow
IBM Horizon data flow

A Guide to Listening to CB Radio with an RTL-SDR Dongle

In the June edition of The Spectrum Monitor, SDR enthusiast and ham Mario Filippi N2HUN published an article titled “Your New CB ‘Good Buddy’, the SDR Dongle”. While the CB radio heyday is well and truly over, Mario discusses how an RTL-SDR dongle can be used to have some fun listening to CB without needing to go out and buy a full CB radio. If you don’t know what CB radio is, Mario explains what it is, and its rise and fall in these excerpts:

In the mid-1970’s an early form of social media was sweeping across the country known as CB (Citizens Band) radio. In those years the FCC required CB radio operators to obtain a license, easily gotten by filling out FCC form 505, paying the fee ($20 or $4 depending on what year you applied), and waiting very patiently, usually two to three months for your license to arrive by mail with your call sign.

The concept of wirelessly communicating with others without studying for a licensing exam somehow caught on and was embraced by the American public. As a result, in the mid-70’s CB sets started flying off the shelves by the millions to appease this new insatiable appetite of Americans to talk over the air with their “good buddies” (CB slang for friend). Other major factors played into the oncoming tsunami of CB’ers: gasoline was getting scarce as a result of the recent oil embargo, prices were quickly escalating at the pump, and the Interstate Highway maximum speed was lowered to 55 MPH prompting drivers with heavy feet to communicate the whereabouts of radar-enabled local police (CB slang: Smokies or Smokey Bears) or the cheapest place to fill up. In addition, traffic information such as road conditions, accidents, speed traps and the best greasy spoon location was now available to the commuting public by simply turning on the CB radio and tuning to the trucker’s Channel 19, the epicenter for the latest road-related poop.

By the late ‘70’s there were so many CB’ers congregating on the air causing non-stop channel chatter and ignoring FCC regulations (C.F.R. Part 95) that Uncle Charlie (CB slang for the FCC) eventually dropped the license requirement. The American public now ruled the airways with expanded 40 channel radios and pandemonium. Call signs were replaced by nicknames or “handles” and everyone prided themselves with their own, unique self-descriptive moniker when “ratchet-jawing” (slang for talking a lot) on their CB radio. But when the early 80’s rolled around the public’s fleeting romance with this mode of communication had dwindled markedly and only the diehards remained on the air in happy solitude.

The article goes over several points which may be useful to those who did not play around on CB back in its popular days. He explains how CB radio exists on frequencies between 26.965 MHz to 27.115 MHz and how you should use an appropriate (large) CB antenna, such as an 43 foot S9 vertical antenna. He also notes how CB radio conditions can be affected by ionospheric conditions, and how on a good day (CB is usually open during the day as opposed to the night for the lower frequencies) you can actually receive CB radio from all over the world including Europe, the Caribbean and the US. 

As the article is a part of The Spectrum Monitor magazine it is not free to read, but each monthly edition only costs $3 USD, and comes with multiple articles from other authors too, which makes it quite a good bargain read every month. You can find the June edition at http://www.thespectrummonitor.com/june2015tsm.aspx.

CB Radio coming in with an RTL-SDR and CB antenna on SDRSharp.
CB Radio coming in with an RTL-SDR and CB antenna on SDRSharp.

Decoding a Garage Door Opener with an RTL-SDR

After listening to dock workers with his RTL-SDR for a few days, RTL-SDR.com reader Eoin decided that he wanted to try a more practical experiment. He decided to see if he could reverse engineering the wireless protocol on his garage door opener. Upon opening his remote he discovered a bunch of DIP switches, which are presumably used to program the remote to a particular garage door. Eoin’s next step was to determine at what frequency the garage door opener was transmitting at. He made an assumption that it would be in the 433 MHz unlicenced ISM band as this is where many handheld remotes transmit at. He was right, and found the signal.

The garage door remote showing the DIP switches.
The garage door remote showing the DIP switches.

His next step was then to record the signal audio in Audacity. From the audio waveform he could see a square wave which looked just like binary bits. By manually eyballing the waveform and translating the high/low squarewave into bits he was able to get the binary data. He then confirmed this data with the dipswitch positions and discovered that a 010 binary code matched with the UP position on the dip switch and 011 matched with the DOWN position.

Having decoded the signal manually fairly easily, Eoin decided his next challenge would be to automate the whole decoding in GNU Radio. In the end he was successful and managed to create a program that automatically determines the position of the DIP switches from the signal. His post goes into detail about his algorithm and GNU Radio program.

Showing the decoded DIP switch positions from his GNU Radio program.
Showing the decoded DIP switch positions from his GNU Radio program.

Updates on using an RTL-SDR for GPS on a High Powered Rocket

Back in April we posted about Philip Hahn and Paul Breed’s experiments to use an RTL-SDR for GPS logging on their high powered small rockets. As GPS is owned by the US military, a standard GPS module cannot be used on a rocket like this, as they are designed to fail if the GPS device breaches the COCOM limit, which is when it calculates that it is moving faster than 1,900 kmph/1,200 mph and/or higher than 18,000 m/59,000 ft. The idea is that this makes it harder for GPS to be used in non-USA or home made intercontinental missiles. As SDR GPS decoders are usually programmed in open source software, there is no need for the programmers to add in these artificial limits.

In their last tests they managed to gather lots of GPS data with an RTL-SDR, but were only able to decode a small amount of it with the GNSS-SDR software. In this post Philip discovers a flaw in the way the GNSS-SDR performs acquisition and retracking that GNSS-SDR decodes in such a way that makes it difficult to obtain a location solution with noisy high-acceleration data. By using a different GPS implementation coded in MATLAB, he was able to get decoded GPS data from almost the entire ascent up until the parachutes deploy. Once the parachutes deploy the GPS has a tough time keeping a lock as it sways around. His post clearly explains the differences in the way the code is implemented in GNSS-SDR and in the MATLAB solution and shows why the GNSS-SDR implementation may not be suitable for high powered rockets.

In addition, they write that while the flight was just under the artificial COCOM GPS fail limits for speed and height, the commercial GPS solution they also had on board failed to collect data for most of the flight too. With the raw GPS data from the RTL-SDR + some smart processing of it, they were able to decode GPS data where the commercial solution failed.

GPS data acquired from the RTL-SDR on the rocket.
GPS data acquired from the RTL-SDR on the rocket (blue line shows solution from MATLAB code, yellow shows GNSS-SDR solution, and red shows commercial GPS receiver solution).

LuaRadio: New Flowgraph Based Digital Signal Processing Framework for SDR

LuaRadio is a new Digital Signal Processing (DSP) framework for software defined radios such as the RTL-SDR. It is similar to GNU Radio in that the flowgraph is composed of graphical blocks that can be visually connected to one another in an editor. However compared to GNURadio it aims to be very lightweight in terms of disk space used (1 MB footprint) and the number of dependencies required (zero dependencies required unless you need real time highly optimized libraries). It is also written purely in the Lua programming language. The authors of LuaRadio write “LuaRadio is more inclined towards scripting and prototyping than GNU Radio, and emphasizes fast block development.”

On their website there are already several example application flowgraphs uploaded, such as decoders for WBFM Mono/Stereo, NBFM, AX.25, POCSAG, RDS, AM and SSB. Looking and building such flowgraphs is extremely helpful for learning DSP, and DSP languages like this are excellent for prototyping new signal decoders. In addition, if you are new to SDR they also have a very useful page that explains basic SDR and radio concepts.

A LuaRadio based POCSAG decoder flowgraph.
A LuaRadio based POCSAG decoder flowgraph.

Building an ESP8266 Based Plane Spotter with an RTL-SDR Feeder

Living near Zurich airport, Daniel Eichorn wanted an easy way to show his house guests what planes are flying near him. Usually he opens up his Flightradar24 app on his phone, but he wanted a more permanent always on display. To do this Daniel has built an ESP8266 based OLED display which automatically displays the ADS-B flight information of aircraft outside his window. The ESP8266 is a very cheap and highly popular WiFi module which can give a microcontroller access to WiFi networks.

Daniel feeds his locally received ADS-B data to adsbexchange.com using a Raspberry Pi and RTL-SDR. While actually feeding ADS-B data with an RTL-SDR is not required to make the ESP8266 module work, this step ensures that he has good local coverage of his area. The ESP8266 module then queries the adsbexchange.com database via WiFi for information about planes in his area and displays the information on the OLED screen.

In previous posts we also showed how the ESP8266 could be used to transmit data like NTSC TV in a similar way to Rpitx.

ESP8266 + OLED screen displaying ADS-B data.
ESP8266 + OLED screen displaying ADS-B data.