Back in December of last year Corrosive from his YouTube channel SignalsEverywhere showed us a demo video of him receiving unecrypted DECT digital cordless phones with his HackRF.

DECT is an acronym for 'Digital Enhanced Cordless Telecommunications', and is the wireless standard used by modern digital cordless phones as well as some digital baby monitors. In most countries DECT communications take place at 1880 - 1900 MHz, and in the USA at 1920 - 1930 MHz. Some modern cordless phones now use encryption on their DECT signal, but many older models do not, and most baby monitors do not either. However, DECT encryption is known to be weak, and can be broken with some effort.

In his latest video Corrosive shows us how to install GR-DECT2 on Linux, which is the GNU Radio based decoding software required to decode the DECT signal. He then goes on to show how the software can be used and finally provides some optimizations tips.

Recently we've heard of a new Linux distribution called SigintOS becoming available for download. SigintOS is an Ubuntu based distribution with a number of built in signal intelligence applications for software defined radios such as RTL-SDRs and other TX capable SDRs like the HackRF, bladeRF and USRP radios.

The distro appears to be very well executed, with a built in GUI that grants easy access to the some common sigint tools like an FM and GPS transmitter, a jammer, a GSM base station search tool and an IMSI catcher. SigintOS also has various other preinstalled programs such as GNU Radio, gr-gsm, YatesBTS, wireshark and GQRX.

The OS also teases an LTE search and LTE decoder which to access requires that you get in contact with the creators, presumably for a licencing fee. Regarding an LTE IMSI catcher they write:

LTE IMSI Catcher is not myth!

Due to the nature of LTE base stations, the capture of IMSI numbers seems impossible. LTE stations use GUTI to communicate with users instead of IMSI. The GUTI contains the temporary IMSI number called T-IMSI. This allows the operator to find out who is at the corresponding LTE station who is authorized to query T-IMSI information.

Can the GUTI number be found?
Answer Yes!

How to find GUTI and T-IMSI numbers?
Can be found with the help of SigintOS …

For detailed information contact@sigintos.com

The image comes as a 2GB ISO file, and it's possible to run it in WMWare or VirtualBox.

Several years ago back in 2013 and 2014 we uploaded two posts showing how it was possible to use an SDR to listen in to restaurant pagers and collect data from them, and also to spoof their signal and activate them on demand. If you were unaware, restaurant pagers (aka burger pagers), are small RF controlled discs that some restaurants hand out to customers who are waiting for food. When the food is ready, the pager is remotely activated by the staff, and then flashes and buzzes, letting the customer know that their order can be picked up.

Over on YouTube user Tony Tiger has uploaded a video that shows an overview on how to reverse engineer the signal coming from a particular brand of restaurant pagers. The tools he uses include a HackRF SDR and the Inspectrum and Universal Radio Hacker software packages. If you're interested in reverse engineering signals, this is a good overview. Later in the video he shows a GNU Radio and Python program that he's created to control the pagers.

Over on his YouTube channel SignalsEverywhere, Corrosive has just released a new video titled "Software Defined Radio Introduction | What SDR To Buy? | Choose the Right one For You". The video is an introduction to low cost software defined radios and could be useful if you're wondering which SDR you should purchase.

The video includes a brief overview of the Airspy, KerberosSDR, PlutoSDR, LimeSDR Mini, HackRF, SDRplay RSPduo and various RTL-SDR dongles. In addition to the hardware itself Corrosive also discusses the compatible software available for each SDR.

This weeks episode of Hak5 (an information security themed YouTube channel) features Dale Wooden (@TB69RR) who joins hosts Shannon and Darren to demonstrate a zero day vulnerability against Ford keyless entry/ignition. More details about the vulnerability will be presented at this years DEF CON 27 conference, which is due to be held on August 8 - 11.

In the video Dale first demonstrates how he uses a HackRF with Portapack to capture and then replay the signal from a Ford vehicle's keyfob. The result is that the original keyfob no longer functions, locking the owner out from the car. After performing a second process with another keyfob, Dale is now able to fully replicate a keyfob, and unlock the car from his HackRF.

Dale explains that unlike the well known jam-and-replay methods, his requires no jamming, and instead uses a vulnerability to trick the car into resetting the rolling code counter back to zero, allowing him to capture rolling codes that are always valid. Dale also notes that he could use any RX capable SDR like an RTL-SDR to automatically capture signals from over 100m away.

The vulnerability has been disclosed to Ford, and the full details and code to do the attack will only be released at DEF CON 27, giving Ford enough time to fix the vulnerability. It is known to affect 2019 Ford F-150 Raptors, Mustangs and 2017 Ford Expeditions, but other models are also likely to be vulnerable.

The video is split into three parts. In part 1 Dale demonstrates the vulnerability on a real vehicle and in part 2 he explains the story behind his discovery, how he responsibly disclosed the vulnerability to Ford and how to reset the keyfob yourself. Finally in part 3 Darren interviews Dale about his experiences in the RF security field.

Dales discovery has also been written up in an article by The Parallex which explains the exploit in more detail.

Regulus is a company that deals with sensor security issues. In one of their latest experiments they've performed GPS spoofing with several SDRs to show how easy it is to divert a Tesla Model 3 driving on autopilot away from it's intended path. Autopilot is Tesla's semi-autonomous driving feature, which allows the car to decide it's own turns and lane changes using information from the car's cameras, Google Maps and it's Global Navigation Satellite System (GNSS) sensors. Previously drivers had to confirm upcoming lane changes manually, but a recent update allows this confirmation to be waived.

The Regulus researchers noted that the Tesla is highly dependent on GNSS reliability, and thus were able to use an SDR to spoof GNSS signals causing the Model 3 to perform dangerous maneuvers like "extreme deceleration and acceleration, rapid lane changing suggestions, unnecessary signaling, multiple attempts to exit the highway at incorrect locations and extreme driving instability". Regarding exiting at the wrong location they write:

Although the car was a few miles away from the planned exit when the spoofing attack began, the car reacted as if the exit was just 500 feet away— slowing down from 60 MPH to 24 KPH, activating the right turn signal, and making a right turn off the main road into the emergency pit stop. During the sudden turn the driver was with his hands on his lap since he was not prepared for this turn to happen so fast and by the time he grabbed the wheel and regained manual control, it was too late to attempt to maneuver back to the highway safely.

In addition, they also tested spoofing on a Model S and found there to be a link between the car's navigation system and the automatically adjustable air suspension system. It appears that the Tesla adjusts it's suspension depending on the type of road it's on which is recorded in it's map database.

In their work they used a ADALM PLUTO SDR ($150) for their jamming tests, and a bladeRF SDR ($400) for their spoofing tests. Their photos also show a HackRF.

Regulus are also advertising that they are hosting a Webinar on July 11, 2019 at 09:00PM Jerusalen time. During the webinar they plan to talk about their Tesla 3 spoofing work and release previously unseen footage.

GPS/GNSS spoofing is not a new technique. In the past we've posted several times about it, including stories about using GPS spoofing to cheat at Pokémon Go, misdirect drivers using Google Maps for navigation, and even a story about how the Russian government uses GPS spoofing extensively.

You may recall that a few years ago we released a tutorial on how to set up and use [SDRTrunk]. Fast forward a few years and the software has seen numerous changes. This application was designed primarily for tracking trunking radio systems but also has the ability to decode things like MDC-1200, LoJack and more.

The software is compatible with many Software Defined Radios such as our RTL-SDR v3, HackRF and the Airspy. Some of the newer improvements include a bundled copy of java so that an installation of java is not required on the host computer, as well as decoding improvements for P25 among other digital voice modes. You can find a full list of improvements along with the latest release on [GitHub]

The biggest feature many have been waiting for is the ability to import talk groups for their radio system into the application from radio reference. While this has not yet been implemented, user [Twilliamson3] has created a [web application] that will convert table data from radio reference into a format that is supported by SDRTrunk.

There is nothing wrong with your television set. Do not attempt to adjust the picture. We are controlling transmission.

At this years Defcon conference security researcher Pedro Cabrera held a talk titled  "SDR Against Smart TVs; URL and channel injection attacks" that showed how easy it is to take over a modern internet connected smart TV with a transmit capable SDR and drone. The concept he demonstrated is conceptually simple - just broadcast a more powerful signal so that the TV will begin receiving the fake signal instead. However, instead of transmitting with extremely high power, he makes use of a drone that brings a HackRF SDR right in front of the targets TV antenna. The HackRF is a low cost $100-$300 software defined radio that can transmit.

While the hijacking of TV broadcasts is not a new idea, Pedro's talk highlights the fact that smart TVs now expose significantly more security risks to this type of attack. In most of Europe, Australia, New Zealand and some places in Western Asia and the Middle East they use smart TV's with the HbbTV standard. This allows for features like enhanced teletext, catch-up services, video-on-demand, EPG, interactive advertising, personalisation, voting, games, social networking, and other multimedia applications to be downloaded or activated on your TV over the air via the DVB-T signal.

The HbbTV standard carries no authentication. By controlling the transmission, it's possible to display fake phishing messages that ask for passwords and transmit the information back over the internet. A hacker could also inject key loggers and install cryptominers.

Recorded talks from the Defcon conference are not up on YouTube yet, but Wired recently ran a full story on Pedros talk, and it's worth checking out here. The slides from his presentation can be found on the Defcon server, and below are two videos that show the attack in action, one showing the ability to phish out a password. His YouTube channel shows off several other hijacking videos too.

Over on YouTube Andreas Spiess has uploaded a video titled "How does Software Defined Radio (SDR) work under the Hood?". The video is an entertaining introduction to how software defined radio works and begins from the beginning by explaining how basic analogue radios work with components such as modulators, demodulators, frequency generators, mixers and filters. After the basics he goes on to explain the digitization of radio signals that occurs in SDRs, and gives an introduction ADCs and how IQ sampling works.

Later in the video Andreas shows various applications for SDRs, discusses various SDRs on the market like RTL-SDR, HackRF, SDRplay, LimeSDR and PlutoSDR and introduces GNU Radio Companion and other SDR programs from our big list of software post.

At last years Chaos Communication Congress (35C3) Conference, leveldown security presented their findings on multiple security vulnerabilities present in cryptocurrency hardware wallets.  Cryptocurrency is a type of digital asset that relies on computers solving cryptographic equations to keep the network trusted and secure. Popular cyrptocurrencies include Bitcoin, Ethereum and Ripple. To access your cyrptocurrency funds on a computer, a software application called a wallet is used.

However, if a computer holding a wallet is compromised, it is possible that the wallet could be opened by a hacker and funds transferred out. To improve security, hardware wallets are available. These are USB keys that require you to enter a PIN on the key before the funds can be accessed. If the USB key is not inserted and activated by the PIN, the wallet cannot be opened.

All electronic devices including hardware cyrptocurrency wallets unintentionally emit RF signals. One possible attack against a hardware wallet is to analyze these RF emissions and see if any information can be obtained from them.  The team at leveldown found that the Ledger Blue cryptocurrency wallet in particular has a flaw where each PIN number button press emits a strong RF pulse. By using a HackRF and machine learning to analyze the unintentional RF output of each button press, the team was able to retrieve the PIN number with only RF sniffing from more than 2 meters away.

To do this they created a GNU Radio flowchart that records data from the HackRF whenever an RF pulse is detected. A small Arduino powered servo then presses the buttons on the wallet hundreds of times, allowing hundreds of RF examples to be collected. Those RF samples are then used to train a neural network created in Tensorflow (a popular machine learning package). The result is a network that performs with 96% accuracy.

Back in August 2019 the Chaos Communication Camp was held in Germany. This is a 5 day conference that covers a variety of hacker topics, sometimes including SDR. At the conference Osmocom developer Harald Welte (aka @LaF0rge) presented a talk titled "The Limits of General Purpose SDR devices". The talk explains how general purpose TX capable SDRs like HackRFs and LimeSDRs have their limitations when it comes to implementing advanced communications systems like cellular base stations.

If you prefer, the talk can be watched directly on the CCC website instead of YouTube.

Why an SDR board like a USRP or LimeSDR is not a cellular base station

It's tempting to buy a SDR device like a LimeSDR or USRP family member in the expectation of operating any wireless communications system out there from pure software. In reality, however, the SDR board is really only one building block. Know the limitations and constraints of your SDR board and what you need around it to build a proper transceiver.

For many years, there's an expectation that general purpose SDR devices like the Ettus USRP families, HackRF, bladeRF, LimeSDR, etc. can implement virtually any wireless system.

While that is true in principle, it is equally important to understand the limitations and constraints.

People with deep understanding of SDR and/or wireless communications systems will likely know all of those. However, SDRs are increasingly used by software developers and IT security experts. They often acquire an SDR board without understanding that this SDR board is only one building block, but by far not enough to e.g. operate a cellular base station. After investing a lot of time, some discover that they're unable to get it to work at all, or at the very least unable to get it to work reliably. This can easily lead to frustration on both the user side, as well as on the side of the authors of software used with those SDRs.

The talk will particularly focus on using General Purpose SDRs in the context of cellular technologies from GSM to LTE. It will cover aspects such as band filters, channel filters, clock stability, harmonics as well as Rx and Tx power level calibration.

The talk contains the essence of a decade of witnessing struggling SDR users (not only) with running Osmocom software with them. Let's share that with the next generation of SDR users, to prevent them falling into the same traps.

Over on YouTube user HackedExistence has uploaded a video explaining how POCSAG pager signals work, and he also shows some experiments that he's been performing with his HackRF PortaPack and an old pager.

The Portapack is an add on for the HackRF SDR that allows the HackRF to be used without the need for a PC. If you're interested in the past we reviewed the PortaPack with the Havok Firmware, which enables many TX features such as POCSAG transmissions.

POCSAG is a common RF protocol used by pagers. Pagers have been under the scrutiny of information security experts for some time now as it is common for hospital pagers to spew out unencrypted patient data [1][2][3] into the air for anyone with a radio and computer to decode.

In the video HackedExistence first shows that he can easily transmit to his pager with the HackRF PortaPack and view the signals on the spectrum with an RTL-SDR. Later in the video he explains the different types of pager signals that you might encounter on the spectrum, and goes on to dissect and explain how the POCSAG protocol works.

Reddit user [SDR_LumberJack] writes how he was recently featured in his local newspaper [Part2] in Ontario, Canada thanks to his efforts in helping to hunt down the cause of an RF deadspot with an SDR. He began his journey by reading a story in his local newspaper called the [Windsor Star]. The story was about locals having found a ‘dead-spot’ for car key-fobs. In the dead-spot key-less cars wouldn’t start, key-fobs wouldn’t unlock cars, and alarms would go off.

Being intrigued by the story [SDR_LumberJack] investigated by driving around with an RTL-SDR, HackRF and a laptop running SDR#. Eventually he found that there was what appeared to be a WBFM Broadcast radio station interfering at 315 MHz. This frequency happens to fall into the ISM radio band that used by car remotes and key-fobs. The exact source of the interference hasn’t been nailed down just yet though.

While it’s possible a broadcast station is at fault it is also possible that his SDR was just overloading, causing broadcast FM imaging. Perhaps a WBFM filter could be used to prevent signal imaging that could interfere with the investigation.

Hopefully [SDR_LumberJack] will continue his investigation and we’ll get an update on this story.

If you’re interested, back in 2016 we posted a very similar story about the exact same thing happening at a car park in Brisbane, Australia. The conclusion to that story was that the dead-spot only occurred in particular locations in the car park, and this was due to the shape of surrounding building causing the RF signals to reflect off the walls and distort the signal.

Over on YouTube channel Tech Minds has uploaded a short tutorial video that shows how to perform a replay attack with a HackRF and the Universal Radio Hacker software. A replay attack is when you record a control signal from a keyfob or other transmitter, and replay that signal using your recording and a TX capable radio. This allows you to take control of a wireless device without the original keyfob/transmitter. This is easy to do with simple wireless devices like doorbells, but not so easy with any system with rolling codes or more advanced security like most car key fobs.

In the video Tech Minds uses the Universal Radio Hacker software to record a signal from a wireless doorbell, save the recording, replay it with the HackRF, and also analyze it.

Tesla vehicles have a feature where they can copy and mimic a garage door remote via a built in transmitter on the car itself. This frees you from having to carry around a garage door key fob, and you can simply open your garage door by pressing a button on the car's LCD screen.

However, some people have reportedly been having a little trouble with this feature as in some cases the garage door would begin opening, and then suddenly stop opening as if the keyfob button had been pressed twice.

Over on YouTube CWNE88 decided to investigate this problem using his HackRF and GNU Radio. From a simple waterfall he was able to determine that the Tesla actually transmits the mimic'd garage door signal for a full two seconds.

As a keypress from the original keyfob would typically result in a much shorter transmission, CWNE88 believes that the long two second transmission could in some cases be seen as two transmissions by the garage door, resulting in an open, and then close command being detected. 

The Raspberry Pi 4 launched with it's fair share of problems, but a new problem seems to have been recently discovered and documented. It turns out that the Pi 4's WiFi stops working when running at a screen resolution of specifically 1440p.

Suspecting interference generated by the HDMI clock, Mike Walters (@assortedhackery) used a HackRF and a near field probe antenna to investigate. By placing the near field probe on the Raspberry Pi 4's PCB and running a screen at 1440p resolution he discovered a large power spike showing up at 2.415 GHz. This interferes directly with 2.4 GHz WiFi Channel 1.

An article by ExtremeTech article notes:

There’s a giant spike that could easily interfere with Channel 1 of a Wi-Fi adapter. So why is this happening? Because a 2560×1440@60Hz has a pixel clock of 241.5MHz and has a TMDS (transition-minimized differential signaling) clock of 2.415GHz, according to Hector Martin (@Marcan42). And what frequency does the RBP4 use for Wi-Fi? 2.4GHz. Which means… outputting on HDMI over 1440p can cause interference in a Wi-Fi channel.

The ExtremeTech article also notes that this problem is not unique to the Raspberry Pi 4 only. It turns out that USB 3.0 hardware is to blame, and this problem has occurred before with USB3.0 hard driver and on some MacBooks.

While the interference appears to be localized to the near field around the Pi4 PCB, we suspect that you could use TempestSDR to remotely eavesdrop on the Pi 4's video output if the interfering signal was boosted.

A few readers have written in to let us know the role SDRs played in the last season of "Mr. Robot". The show which is available on Amazon Prime is about "Mr. Robot", a young cyber-security engineer by day and a vigilante hacker by night. The show has actual cyber security experts on the team, so whilst still embellished for drama, the hacks performed in the show are fairly accurate, at least when compared to other TV shows.

Spoilers of the technical SDR hacks performed in the show are described below, but no story is revealed.

In the recently aired season 4 episode 9, a character uses a smartphone running an SSH connection to connect to a HackRF running on a Raspberry Pi. The HackRF is then used to jam a garage door keyfob operating at 315 MHz, thus preventing people from leaving a parking lot. 

Shortly after she can be seen using the HackRF again with Simple IMSI Catcher. Presumably they were running a fake cellphone basestation as they use the IMSI information to try and determine someones phone number which leads to being able to hack their text messages. The SDR used in the fake basestation appears to have been a bladeRF.

In season 4 episode 4 GQRX and Audacity can be seen on screen being used to monitor a wiretap via rtl_tcp and an E4000 RTL-SDR dongle.

Did we miss any other instances of SDRs being used in the show? Or have you seen SDRs in use on other TV shows? Let us know in the comments.

Over on the TechMinds YouTube channel a new video titled "GPS Spoofing With The HackRF On Windows" has been uploaded. In the video TechMinds uses the GPS-SDR-SIM software with his HackRF to create a fake GPS signal in order to trick his Android phone into believing that it is in Kansas city.

In the past we've seen GPS Spoofing used in various experiments by security researchers. For example, it has been used to make a Tesla 3 running on autopilot run off the road and to cheat at Pokemon Go. GPS spoofing has also been used widely by Russia in order to protect VIPs and facilities from drones.

During the 2019 IEEE International Symposium on Broadband Multimedia Systems and Broadcasting conference, authors Xuemei Huang, Kun Yan, Hsiao-Chun Wu and Yiyan Wu presented a research paper titled "Unmanned Aerial Vehicle Hub Detection Using Software-Defined Radio". In their work they describe how they were able to use three HackRFs to determine the location of a UAV drone transmitter. The method they use is fairly simple as it makes use of path loss propagation models to determine an estimated distance from each HackRF, so prior knowledge of the transmitter properties is still required.

The applications of unmanned aerial vehicles (UAVs) have increased dramatically in the past decade. Meanwhile, close-range UAV detection has been intriguing by many researchers for its great importance in privacy, security, and safety control. Positioning of the UAV controller (hub) is quite challenging but still difficult. In order to combat this emerging problem for public interest, we propose to utilize a software-defined radio (SDR) platform, namely HackRF One, to enable the UAV hub detection and localization. The SDR receiver can acquire the UAV source signals. The theoretical path-loss propagation model is adopted to predict the signal strength attenuation. Thus, the UAV hub location can be estimated using the modified multilateration approach by only three or more SDR receivers.

A ground penetrating radar (GPR) is a system that uses RF pulses between 10 to 2.6 GHz to image up to a few meters below the ground. A typical GPR system consists of a transmitting radio and antenna that generates the radar pulse aimed towards the ground, and a receiving radio that receives the reflected pulse.

GPR is typically used for detecting buried objects, determining transitions in ground material and detecting voids and cracks. For example, in construction it can be used to determine rebar locations in concrete, and in the military it can be used to detect non-metallic landmines and hidden underground areas. 

These GPR devices are usually very expensive, however researchers Jacek JENDO & Mateusz PASTERNAK from the Faculty of Electronics, Military University of Technology, Poland have released a paper detailing how two low cost HackRF software defined radios can be used to create a simple GPR.

Their system uses a step-frequency continuous waveform (SFCW) signal which scans over multiple frequencies over time, and  the software was written in GNU Radio. In their tests they were able to detect a dry block of sand buried 6 cm below the ground, and a wet block 20 cm below.