Over on YouTube the web show Hacker Warehouse have created a video explaining wireless pagers and how RTL-SDRs can be used to sniff them. In the video host Troy Brown starts by explaining what pagers are and how they work, and then he shows how to decode them with SDR# and PDW. We have a tutorial on this project available here too.
Later in the video he shows some examples of pager messages that he's received. He shows censored messages such as hospital patient data being transmitted in plain text, sports scores, a memo from a .gov address claiming allegations of abuse from a client, office gossip about a hookup, a message about a drunk man with a knife, a message from a Windows server with IP address and URL, a message from a computer database, and messages from banks.
In the past we've also seen an art installation in New York which used SDR to highlight the blatant breach of privacy that these pager messages can contain.
Last week we posted news about the "SirenJack" radio security vulnerability which was released by Balint Seeber of the Bastille security research agency. SirenJack describes how a cheap TX capable SDR or a $30 handheld radio could allow an attacker to take over wirelessly controlled emergency sirens that are found in many cities around the US. In particular, it was discussed how Acoustic Technology, Inc (ATI Systems) sirens' were the first to be found as vulnerable.
Today Dr. Ray Bassiounim, President & CEO of ATI Systems wrote to us (and presumably other news agencies that ran the SirenJack story) a rebuttal which we paste below.
ATI Siren Vulnerability Misrepresented by Bastille Networks
Balint Seeber of Bastille Networks, Inc. has released information that he has been able to hack Acoustic Technology, Inc.’s wireless protocol. ATI believes that Seeber misrepresents his claims that he did so using only a $35 radio and a laptop. ATI understands the great lengths, time, effort, and expertise that Seeber and Bastille went through. However, their claim trivializes the fact that Seeber is a radio frequency expert with over a decade of training, knowledge, and access to advanced equipment. Bastille’s statement intended to maximize public fear and anxiety by purposefully omitting and simplifying information they released.
Seeber says he identified this vulnerability over 2 ½ years ago but decided not to notify ATI or the City of San Francisco until recently. If he truly believed this was a serious vulnerability, why did he wait so long to disclose it, effectively leaving the public at risk? Other discrepancies discovered include:
Bastille’s SirenJack white paper states in part “...nor was there access to equipment...” However, pictures in the white paper and videos on Bastille’s YouTube page clearly show Seeber utilizing ATI’s equipment in his Proof of Concept.
Seeber also states multiple times that anyone “…with a $35 transmitter…” can perform this hack. The white paper, however, confirms he used “…a number of Ettus Research Universal Software Radio Peripheral (USRP) and Software Defined Radio (SDR)….”. This equipment costs upwards of thousands of dollars for each unit, not merely the $35 radio as claimed.
In multiple YouTube videos, ATI’s equipment is blurred out during Seeber’s demonstration. For full disclosure, what was blurred out and why?
In Seeber’s YouTube demonstration of the SirenJack hack, it shows him with an embedded CPU debug cable plugged into the ATI siren. Since this cable is only used for programming and diagnostics of the ATI siren, why is this cable needed? There is no reason for it to be used while demonstrating siren activation through over-the-air hacking.
None of Bastille’s videos show any Over-The-Air (OTA) transmissions of malicious packets because transmitting on a licensed frequency is illegal. Yet the Motorola CM200 radio in the ATI siren is very easy to re-program to a different frequency (or a license free radio could have been used), and it could have been easily changed in order to legally demonstrate sending malicious packets OTA.
When the San Francisco system was installed in 2004, over 14 years ago, it was state-of-the-art. Since then, ATI has upgraded protocols to incorporate a 128-bit AES variable key with an additional ATI proprietary security layer that is now being implemented.
“For the past 30 years ATI has had thousands of clients, both nationally and internationally. Even though we have never experienced any fails or hacking incidents, ATI responded to Bastille’s false claims by raising security safeguards, and ATI encourages its clients to update their systems to ensure maximum security. We believe that Bastille’s representations are totally fabricated,” comments ATI’s CEO, Dr. Ray Bassiouni.
It's true that Balint and Bastille do have years of knowledge and the equipment to find vulnerabilities, however we believe that Bastille was only claiming that a $30 radio can be used to take over the system now that the vulnerability is already known. If a more malicious hacker found the vulnerability first, and then released the details to 'script kiddies' or other malicious people, it could have caused major issues.
The white paper on SirenJack is now available and can be found at sirenjack.com. From the white paper it appears that Bastille analyzed the RF spectrum to find the weekly siren test signal. Once found they were able to characterize the modulation scheme, and since no encryption was used, they were able to dissect the packet. They then determined that the packets could easily be reproduced and thus any transmit capable radio could be used to attack the system. Also although Bastille used USRP SDRs in the reverse engineering stage, it seems that the same reverse engineering work could be done with a simple RTL-SDR.
Balint Seeber from security research firm Bastille has recently disclosed a major security vulnerability found in wirelessly controlled emergency sirens called "SirenJack". These sirens are used in many states and cities within the USA to warn large populations of disasters or other dangers, although at the moment only sirens by ATI System in San Francisco have been identified as vulnerable. The vulnerability stems from the fact that the wireless protocol used to activate the sirens is not encrypted, so a bad actor could record the monthly test activation transmissions, analyze them and forge control signals of his own. This would allow a hacker to take control the sirens at will using a simple $30 handheld radio and a laptop, or a transmit capable software defined radio.
This security research release comes after the Dallas tornado siren hack, which occurred in early 2017. During that hack a hacker activated 156 tornado sirens placed around the city of Dallas, Texas. In contrast to SirenJack, the Dallas siren hack was most likely caused by a more standard replay or brute force attack, since simple DTMF tones are used to activate Dallas' siren system.
ATI Systems have indicated that they have already patched the vulnerability as Bastille responsibly disclosed the vulnerability to them 3 months prior. However, it is likely that sirens created by other contractors in other states may have the same or similar vulnerabilities.
In the video below Balint shows the SirenJack vulnerability in action on a test siren setup. During the test he is able to take control of the siren and transmit any arbitrary audio to it using a software defined radio. Several other SirenJack video are available on Bastille's YouTube channel.
The PortaPack is a US$220 add-on for the HackRF software defined radio (HackRF + PortaPack + Accessory Amazon bundle) which allows you to go portable with the HackRF and a battery pack. It features a small touchscreen LCD and an iPod like control wheel that is used to control custom HackRF firmware which includes an audio receiver, several built in digital decoders and transmitters too. With the PortaPack no PC is required to receive or transmit with the HackRF.
Of course as you are fixed to custom firmware, it's not possible to run any software that has already been developed for Windows or Linux systems in the past. The official firmware created by the PortaPack developer Jared Boone has several decoders and transmitters built into it, but the third party 'Havoc' firmware by 'furrtek' is really what you'll want to use with it since it contains many more decoders and transmit options.
As of the time of this post the currently available decoders and transmit options can be seen in the screenshots below. The ones in green are almost fully implemented, the ones in yellow are working with some features missing, and the ones in grey are planned to be implemented in the future. Note that for the transmitter options, there are some there that could really land you in trouble with the law so be very careful to exercise caution and only transmit what you are legally allowed to.
Although the PortaPack was released several years ago we never did a review on it as the firmware was not developed very far beyond listening to audio and implementing a few transmitters. But over time the Havok firmware, as well as the official firmware has been developed further, opening up many new interesting applications for the PortaPack.
Testing the PortaPack with the Havoc Firmware
Capture and Replay
One of the best things about the PortaPack is that it makes capture and replay of wireless signals like those from ISM band remote controls extremely easy. To create a capture we just need to enter the "Capture" menu, set the frequency of the remote key, press the red 'R' Record button and then press the key on the remote. Then stop the recording to save it to the SD Card.
Now you can go into the Replay menu, select the file that you just recorded and hit play. The exact same signal will be transmitted over the air, effectively replacing your remote key.
We tested this using a simple remote alarm system and it worked flawlessly first time. The video below shows how easy the whole process is.
In this talk Samy Kamkar shares the exciting details on researching closed systems & creating attack tools to (demonstrate) wirelessly unlocking and starting cars with low-cost tools, home made PCBs, RFID/RF/SDR & more. He describes how to investigate an unknown system, especially when dealing with chips with no public datasheets and undisclosed protocols. Learn how vehicles communicate with keyfobs (LF & UHF), and ultimately how a device would work that can automatically detect the makes/models of keyfobs nearby. Once the keyfobs have been detected, an attacker could choose a vehicle and the device can wirelessly unlock & start the ignition. Like Tinder, but for cars.
Most modern vehicles use some form of rolling code security on their wireless keyfobs to prevent unauthorized replay attacks. When the car owner presses a button on the keyfob, a unique rolling code is sent to the car. If it matches one of the codes currently stored in the car, the car will unlock and then invalidate that code so it can never be used again, thus preventing a replay attack. On the next press the keyfob sends a new code. In most designs when a code is used up, a new code is added to the list of valid codes via a random number generator based on a secure algorithm only known (presumably) to the engineers.
Essentially Tom found that instead of producing a randomly generated rolling code, the Subaru keyfob simply increments the rolling code number each time. This allows an attacker to perform a second key press simply recording an initial real key press, decoding the packet, increasing the decoded rolling code by one, then re-transmitting. It also means that the attacker could continually raise the rolling code value on the car himself, which would eventually make the real keyfob useless as the codes on the keyfob would be outdated and no longer match the same number range as the car.
The entire exploit was found on a super low budget. Tom used only an RTL-SDR and Raspberry Pi. The receive is obviously handled by the RTL-SDR, but the transmit side is handled by RPiTX which is software that allows the Raspberry Pi to transmit RF signals directly from a GPIO pin without the need for any additional transmitting hardware. Tom writes that the exploit probably affects the 2006 Subaru Baja, 2005 - 2010 Subaru Forester, 2004 - 2011 Subaru Impreza, 2005 - 2010 Subaru Legacy and the 2005 - 2010 Subaru Outback. Tom also writes that various dealers and spokes people have contacted him stating that the exploit probably only affects US models. If you have one of the affected models and are worried the only way to stay safe is to simply not use wireless entry on the keyfob, at least until/if Subaru fixes the issue with a recall. Although so far no statement from Subaru has been released.
Tom has also uploaded a demonstration video to YouTube which is shown below.
The PandwaRF (formerly known as GollumRF) is an RF analysis transceiver tool that can be very useful for investigating ISM band devices that communicate with digitally modulated RF signals. It can be used for applications such as performing replay attacks, brute force attacks, and other analysis. The RX/TX frequency range of the device is from 300 – 928 MHz, with a transmit power of up to +10 dBm.
The PandwaRF is based on the CC1111 chip which is the same chip used in devices like the Yard Stick One from Great Scott Gadgets (creators of the HackRF). Compared to the YS1 the PandwaRF is essentially the same, but designed to be much more portable, with a built in battery and an Android app that you connect to via Bluetooth. This makes it very useful for taking out in the field as no laptop is required to use it, just a phone or tablet. The PandwaRF can be used just like a YardstickOne when plugged into a PC however.
We should also clarify that CC1111 based devices like the PandwaRF and YS1 are not classed as SDRs. Rather they are RF transceiver chips that can demodulate, decode and transmit a fixed set of digital modulation schemes, such as OOK/ASK, 2-FSK, 4-FSK, GFSK, and MSK. While these devices are not able to receive or transmit any arbitrary signal like an SDR, they make reverse engineering, analysis, replay attacks, brute force attacks etc much simpler for common modulation schemes compared to using an SDR for the same purpose.
Early on in the year PandwaRF sent us a sample of their device for review. Unfortunately during that time their Android software was extremely buggy and we were simply unable to use the device properly. Others reported similar troubles on forums and blog comments. However fast forward to today and it now seems that the Android software is stable and functioning properly.
We first tested the PandwaRF on a simple task which was a replay attack. The goal was to record the signal of a cheap wireless RF alarm, and see if we could replay it back. The wireless alarm is controlled with a keyfob.
First we used the Spectrum Analyzer tool in the PandwaRF app to try and get the frequency of the keyfob. The Spectrum Analyzer tool allows you to see about 1.2 MHz of bandwidth. We assumed the signal would be around 433 MHz. After pressing the button a few times the peak showed up at about 433.9 MHz on the spectrum analyzer. The refresh rate of the spectrum analyzer is quite low, so if the signal is not continuous it’s possible to miss the signal, which is we why we had to try several presses before the signal showed. A standard SDR like an RTL-SDR might be better for this initial frequency searching. We confirmed the frequency to be at 433.893 MHz on an RTL-SDR blog V3.
Next we switched to the RX/TX tool. Here you can enter the frequency of interest and set the expected modulation. We know that this device is ASK/OOK modulated, so we chose this setting. You also need to set the data rate. If you don’t know this value then the app has a data rate measuring tool. So we just pressed on the Measure button, and then pressed a button on the remote until it converged to a data rate of 5,121.
Next you need to set the ‘desired payload’. This is how many bytes long the packet is and determines how long the capture is. As we were unsure we simply set it to 250 bytes to ensure that a longer capture was taken. The PandwaRF will keep on receiving until it receives the desired payload of 250 bytes or is stopped manually. Setting it longer allows us to capture a longer signal, and ensure that the replayed signal is received. For this alarm device it is okay if the same signal is played multiple times in a short time frame.
The final setting is the RX Frame length. This determines how many bytes will be captured before transferring the data to Android. So for example, if you set the desired payload to 100 Bytes, and the RX Frame length to 52 bytes, then in total you will capture 104 Bytes of data. The PandwaRF can only transfer in 14, 33, 52, 71 or 90 bytes, so select one that is closest to a multiple of your desired payload.
Finally we pressed on ‘Sniff’ and pressed the ‘bell’ button on the remote. The PandwaRF detected the signal and recorded the data. Now pressing Xmit replays the signal successfully causing the alarm bell to sound.
Brute Force Attack
The PandwaRF can also be used as a brute forcing tool. With cheap alarms the alarm code is relatively short, so can be brute forced in a matter of minutes. The PandwaRF already had a preset mode for our cheap Forecum door alarm, so we simply selected this mode and started the brute force. It gave an estimated brute force time of 28 minutes, which is the time it takes to run through every possible alarm code.
The PandwaRF app currently supports the Idk and PT2262 chipsets, as well as some models of DIO, Extel and Forecum house alarms. If the device that you want to brute force is not yet in their database, then you’ll probably need to do some analysis first on the PC with an SDR. Software like Universal Radio Hacker and DSpectrumGUI are good tools for this. Once you know the structure of the data, then you can program PandwaRF to perform the brute force attack.
Note that their newer ‘PandwaRF Rogue’ product is supposed to be significantly faster at brute forcing. For example the Android software gives us a estimated duration of 28 minutes with the standard PandwaRF, and only 3 minutes with the Rogue.
The Rogue is also able to brute force 32 bit codewords with zero delay in between transmissions. The standard PandwaRF has a minimum delay of 100 ms which can really slow things down. It also allows for function mask bit skipping, enable more brute force patterns and can split the brute force attempt into several steps. Also as we’ve seen from their videos the Rogue has more pre-set commercial devices built into its app.
So if brute forcing is your main use for the PandwaRF then it seems to make sense to get the Rogue. Unfortunately the Rogue is significantly more costly, coming in at 990 euros, vs 145 euros for the standard PandwaRF. Of course you could still use the standard PandwaRF on a PC with tools like rfcat to perform a faster brute force attack as well, just like you would with a YardstickOne.
The code runs on the Android device and not on the PandwaRF, so each RF command generates a bluetooth transfer which can be quite slow. They write this is why they have created a specific brute force implementation in the app, so that they can run their native brute force code on the PandwaRF itself, which is must faster than transferring the RF command for every brute force step.
Overall the PandwaRF is a very handy tool for doing replay and brute force attacks while in the field. It can also be converted back into a PC based CC1111 device, like a Yardstick One simply by plugging it into a computer with a USB cable so you’re not missing out on that functionality either.
Compared to the Yardstick One the cost is a bit more, with the Yardstick One costing $99 USD at most outlets, and the PandwaRF costing 145 Euros (~$173 USD). So it is probably only really worth it if you are doing field testing.
That said, now that the PandwaRF software seems stable it is an excellent tool for investigating wireless devices in a simpler way compared to with an SDR. An SDR is still much more powerful, but tools like this simplify the process significantly. The best set of tools for reverse engineering would be a SDR combined with a device like this.
In the future it looks like they plan to implement new features such as De Bruijn (OpenSesame) attack’s and rolling code attacks and we look forward to testing those out.
Over on his YouTube channel Tysonpower (aka Manuel) has uploaded a video showing how he was able to use his PlutoSDR to perform some simple replay attacks that open his garage and car doors. To do this he records the signal from the wireless keyfobs with the PlutoSDR, and then uses a GNU Radio program to replay that signal again at a later time. From the tests he concludes that the PlutoSDR can be a great cheaper alternative to a HackRF, with the PlutoSDR coming in at $100 vs $300 for the HackRF.
To get around the rolling code security on his car he records the keyfob with the PlutoSDR while it’s out of the wireless range of his car, so that the rolling code will not be invalidated. Then later closer to the car the PlutoSDR is used to replay the car keyfob signal which opens the door.
Note that Tysonpower’s video is narrated in German, but English subtitles are available through the YouTube interface.
[EN subs] Hacken eines Autos und Garagentors – AdalmPluto Replay Attacke