Photo: Raspberry Pi RLT-SDR receiver

What can you do with a RLT-SDR receiver, dump1090 software, and a Raspberry PI?  Easy, you can capture data like flight numbers, altitude, speed, and position information from ADS-B equipped aircraft in your area.

Ever since I was a kid I always enjoyed listening to my Grandfather’s shortwave radio.  Every twist of the tuner knob would produce a new discovery, aircraft, beeps and bleeps of Morse Code, far away news broadcasts.  Now I’m much older and technology has matured but so have my skills.  Now I have I have a Raspberry Pi, RLT-SDR, and know how to program (which means I’m dangerous).

Awhile back I built a Raspberry Pi project with a 2.8″ display from Adafruit.  I also purchased a low cost RLT-SDR receiver at DEFCON 22.  Shortly after I built my Pi project I could not make up my mind what I wanted to do with it so it sat on my shelf collecting dust.  Same goes with the SDR receiver after I returned from DEFCON.  That is until yesterday evening when I had the bright idea to put the Pi and SDR receiver together and make it do something useful.  Around the time I was searching for more information on Internet to get SDR going on Raspberian I discovered some information about ADS-B.  ADS-B equipped aircraft transmit telemetry on 1090mhz and within my SDR receivers bandwidth.  You can learn more about ADS-B on  I still learning myself so I don’t have a good idea where ADS-B fits into aircraft management just yet but ADS-B is definitely interesting technology.


As you can see in the picture of my Raspberry Pi screen photo (first photo), various information about aircraft flying in my area are presented near my home.  I had no idea if this information was accurate so to verify I opened FlightRadar24 in my web browser (2nd photo on right).  The results were accurate although I only receive a fraction of the plans arriving or departing from San Francisco, Oakland, San Jose, and Sacramento.  I’m still not sure what the negative longitude is just yet.  In any case, I noticed that I receive telemetry from some aircraft almost 100 miles away with a 4″ antenna – wow!  Other aircraft passing over the mountains near my home would drop off my display and to be expected since mountains interfere with radio signals.  I was very impressed with the unit I purchased at DEFCON from Hacker Warehouse and at $20US there’s no reason not to experiment.  I noticed at the conference Hacker Warehouse sold a larger microwave antennas at the conference as well as directional antennas which would be interesting to experiment with.

The software package on the Raspberry Pi that makes detecting ADS-B transmissions possible is dump1090.  Dump1090 is used to tune your RLT-SDR radio and receive the ADS-B.  If you want to get dump1090 running on your Pi I then recommend reading Ferran Casanovas blog.  Following are the command line options for dump1090 so you can get some idea for what it does.

pi@raspberrypi ~/dump1090 $ ./dump1090 –help
|                        dump1090 ModeS Receiver         Ver : 1.09.0608.14 |
–device-index <index>   Select RTL device (default: 0)
–gain <db>              Set gain (default: max gain. Use -10 for auto-gain)
–enable-agc             Enable the Automatic Gain Control (default: off)
–freq <hz>              Set frequency (default: 1090 Mhz)
–ifile <filename>       Read data from file (use ‘-‘ for stdin)
–interactive            Interactive mode refreshing data on screen
–interactive-rows <num> Max number of rows in interactive mode (default: 15)
–interactive-ttl <sec>  Remove from list if idle for <sec> (default: 60)
–interactive-rtl1090    Display flight table in RTL1090 format
–raw                    Show only messages hex values
–net                    Enable networking
–modeac                 Enable decoding of SSR Modes 3/A & 3/C
–net-beast              TCP raw output in Beast binary format
–net-only               Enable just networking, no RTL device or file used
–net-http-port <port>   HTTP server port (default: 8080)
–net-ri-port <port>     TCP raw input listen port  (default: 30001)
–net-ro-port <port>     TCP raw output listen port (default: 30002)
–net-sbs-port <port>    TCP BaseStation output listen port (default: 30003)
–net-bi-port <port>     TCP Beast input listen port  (default: 30004)
–net-bo-port <port>     TCP Beast output listen port (default: 30005)
–net-ro-size <size>     TCP raw output minimum size (default: 0)
–net-ro-rate <rate>     TCP raw output memory flush rate (default: 0)
–net-heartbeat <rate>   TCP heartbeat rate in seconds (default: 60 sec; 0 to disable)
–net-buffer <n>         TCP buffer size 64Kb * (2^n) (default: n=0, 64Kb)
–lat <latitude>         Reference/receiver latitude for surface posn (opt)
–lon <longitude>        Reference/receiver longitude for surface posn (opt)
–fix                    Enable single-bits error correction using CRC
–no-fix                 Disable single-bits error correction using CRC
–no-crc-check           Disable messages with broken CRC (discouraged)
–phase-enhance          Enable phase enhancement
–aggressive             More CPU for more messages (two bits fixes, …)
–mlat                   display raw messages in Beast ascii mode
–stats                  With –ifile print stats at exit. No other output
–onlyaddr               Show only ICAO addresses (testing purposes)
–metric                 Use metric units (meters, km/h, …)
–snip <level>           Strip IQ file removing samples < level
–debug <flags>          Debug mode (verbose), see README for details
–quiet                  Disable output to stdout. Use for daemon applications
–ppm <error>            Set receiver error in parts per million (default 0)
–help                   Show this help
Debug mode flags: d = Log frames decoded with errors
                  D = Log frames decoded with zero errors
                  c = Log frames with bad CRC
                  C = Log frames with good CRC
                  p = Log frames with bad preamble
                  n = Log network debugging info
                  j = Log frames to frames.js, loadable by debug.html

My experience with dump1090 was excellent.  The output is more or less what is shown on my Pi photo (first photo).  I say, more or less, since I made some changes to the program for my smaller display on my Pi.  The problem I had on my 2.8″ screen was that the lines would wrap around past the edge of the screen and into the next line.  All the information was on the screen but it was hard to read in –interactive mode.  To get the Pi display cleaned up I was thinking I could find a command line option and then grep something together for a cleaner display.  Unfortunately, I didn’t notice any easy way to do this.  As a workaround, I made some changes to the program to shorten the output to only the fields of interest within interactive.c.  The code is customized for the 2.8″ PiTFT Mini Kit at Adafruit.  After apply the changes, I recompiled dump1090 and output was shortened to fit my display as I expected.  Next, I made some changes to force the Pi to login automatically and start the dump1090 program running.  I know, not very secure but I don’t have any data on this device.  For now, I just used the default account on the Pi but it would be more secure if I created a new account with less privilege.  Anyway, I was lazy and wanted to get this thing finished before I went to bed so I improvised.

b747-8i_lufthansa_02.jpgOne final thought I have rolling around inside my head, since my profession is application security, is that ADS-B does not seem very secure.  ADS-B telemetry is sent from aircraft real-time in route completely unencrypted so far as I know.  I wonder what would happen if an ADS-B transmitter was built and launched in a ballon or drone by an adversary?  It seems possible for adversaries to fake flight numbers, altitude, air speed, and position at a minimum.  Transmitting on ADS-B band is more than likely highly illegal but then again adversaries give little regard to laws.  I hope critical air traffic management systems don’t use these signals for routing traffic but I really have no idea.  If anyone is an ADS-B expert and would like to post a comment to educate readers please do.  I’m a noob in this area.

Update March 4, 2015, I have since learned other security researchers consider insecure ADS-B a security safety problem, Air Traffic Control Systems Vulnerabilities Could Make for Unfriendly Skies [Black Hat].  Apparently the Government Accountability Office (GAO) is recommending improvements, FAA Must Address Cyber-Security of Air Traffic Control Systems: GAO.

Update April 22, 2015, I discovered a presentation on the ADS-B at a security conference about 2 years ago, “DEFCON 20: Hacker + Airplanes = No Good Can Come Of This“.  The presentation is provided by Brad Haines, Render Man(@iheckedwhat).  Render Man goes a step further to demonstration ADS-B spoofing and does a simulated pass by an airport tower.  The radio transmissions were terminated into a dummy load so no danger of harming any real aircraft.  According to Render Man, FAA representatives where attending his conference session.

Update May 1, 2015, FAA’s answer to aging air traffic infrastructure is NextGen.  Apparently, NextGen is falling short of expectations.  A little digging on NextGen reveals it’s not the deep overhaul expected but more of tune-up.  In fact, NextGen still includes proven insecure technologies like ADS-B.  Unfortunately, the FAA efforts seem to focus on efficiency and safety as opposed to security which is a distinctly different challenge.  FAA continues to press forward with NextGen even after debate on public research and the GAO report noting security concerns.  The price tag for NextGen is around $40 billion but a complete overhaul would likely cost far more.  New infrastructure or sharing military infrastructure may be required to develop a secure solution since foundational technologies like GPS were proven insecure long ago.