Blog

  • March 2026 – WarDragon Pro Update, DragonScope Introduction, and What’s Next

    It’s been a while since the last post here, and a lot has happened behind the scenes.

    Some of that was expected. Some of it definitely wasn’t. But overall, progress has been steady, and in some areas, much faster than I initially thought possible.

    WarDragon Pro – Current State

    WarDragon Pro continues to evolve as a compact, SDR-based system focused on drone detection and RF awareness.

    At its core, the system still supports:

    • Remote ID (WiFi and Bluetooth, including long range)
    • DJI DroneID detection
    • ADS-B (optional configuration)
    • Integration into TAK environments via CoT

    But the biggest recent effort has been focused on pushing beyond just detection.

    DragonScope

    A new optional service called DragonScope has been introduced.

    DragonScope enables enhanced DJI detection, including extracting additional information from newer drone links, even in cases where Remote ID is unavailable or disabled.

    This has been a major focus area, and getting it working reliably required building out a full chain from SDR ingest to processing and delivery.

    Important note on how this works:

    DragonScope requires an active internet connection. Data is sent from the WarDragon Pro to a server that I personally maintain under my physical control, running software I have personally designed and built for this purpose.

    Data is processed in real time and is not stored.

    Reality Check – Existing Kits

    As with some things in life, free does not always translate to easy.

    For existing WarDragon Pro kits, enabling DragonScope and newer capabilities will require some manual setup, including:

    • Reflashing and reprogramming the SDR
    • Updating system-side code
    • Applying a generated license

    This is not a one-click upgrade, but it is manageable with some guidance.

    Next-Gen WarDragon Pro

    Alongside software and processing improvements, work has been ongoing on an updated version of the WarDragon Pro hardware.

    • Broader detection across additional signal types
    • Improved reliability and layout
    • External 12V power with support for inline components such as LNAs
    • Locking power connectors
    • Improved visibility into system status, including SDR, dongles, and connectivity

    There will also be multiple variants moving forward, as some newer capabilities, including model-based detection approaches and expanded features, may require additional SDR resources.

    What’s Coming

    There is still a lot in progress.

    • Expanded FPV detection, including DSP-based confirmation and image capture
    • Additional signal detection methods
    • Improved data integration, including MQTT, Lattice, and others
    • Continued refinement of TAK integration via the plugin

    Closing

    This project has always been a mix of experimentation, frustration, and progress.

    Some things took far longer than expected. Others came together faster than they should have.

    Either way, it is moving forward.

    If you are an existing WarDragon Pro user and would like to obtain access to test DragonScope, or if you have been following along and want to reach out as things continue to evolve, you can contact me here:

    https://cemaxecuter.com/?page_id=563

    More to come.

    – Aaron

  • May 20th to May 26th, 2024 – Welcome Post

    This week in DragonOS…

    Highlight of the Week: DragonOS Tests Support for RemoteID Decoding…

    Using YateBTS on a BladeRF to Place International Calls…

    Pull Request Makes Improvements to SigDigger’s Panoscope…

    Airspy Promises Release of a New SDR Dubbed “Ranger”…

    Welcome to the first post of the DragonOS blog. Since its origin in 2019, DragonOS has aimed to deliver valuable and accessible tools to those who use softhttps://cemaxecuter.com/?p=320#ib-toc-anchor-1ware-defined radio (SDR) radios. The creator, Cemaxecuter, hopes DragonOS will become the go-to resource for SDR just as Kali Linux is a one-stop-shop for the offensive security and digital forensics fields.

    This blog adds to the extensive resources that DragonOS provides by publishing weekly content covering the latest developments in the SDR world and their impact on DragonOS. If you are not already familiar, below are links to all of the sites where you can currently engage with DragonOS:

    Share this post:

    Highlight of the Week: DragonOS tests support for RemoteID Decoding…

    Drones are everywhere. They present dazzling light shows at concerts, provide engaging cinematography shots, and have many functional uses in construction, farming, and medicine. Unfortunately, drones can also present significant personal safety risks at home, airports, and even the battlefield. To deter malicious and negligent behavior with drones the FAA mandated all drone operations outside of FAA Recognized Identification Areas (FRIAs) must have Remote ID. Read more about the background and rules here: https://www.faa.gov/uas/getting_started/remote_id.

    DragonOS tested Remote ID packet broadcast decoding this week and proved the ability for detection and decoding 772m away using a standard 3 dBi omnidirectional stub antenna. The Remote ID transmitter used during the test was Holy Stone’s Drone Remote ID module. DragonOS tunes into these broadcasts using off-the-shelf hardware from ElectronicCats combined with Sniffle software and a Wireshark dissector to decode a drone’s serial number, GPS position, velocity, and GPS position of the ground station. This means that DragonOS will be able to provide its users with real-time situational updates for any drones with Remote ID in nearly a half-mile radius, which is well beyond the range at which anyone could normally see or hear a drone.

    RemoteID Detection is coming to the WarDragon soon: https://cemaxecuter.com/?product=dragontooth-remote-id-receiver-kit

    Watch Cemaxecuter demonstrate this capability on YouTube:

    Using YateBTS on a BladeRF to Place International Calls…

    Capabilities-wise 2G cellular technology is nowhere close to competing with modern 5G implementations, but there are still areas of the world that rely on 2G for communication. YateBTS runs in DragonOS and can emulate a base transceiver station (BTS) on either the BladeRF xA4 or xA9. This week, Cemaxecuter used his BladeRF xA9 as a BTS to make a 6-minute call from a Samsung S4 end-user device (EUD) in the United States to South Africa and Australia. The recent development came thanks to making the switch from session initiation protocol (SIP) to inter-asterisk exchange (IAX) service using DiamondcardUS as the backend service.

    Pretty much all US 2G service is gone, but the functionality of YateBTS allows for the BladeRF to act as a BTS and relay a connection from a compatible EUD to DiamondcardUS for international routing. This adds yet another feature to DragonOS that could come in handy. In one of his recent videos, Cemaxecuter was able to join a conference call between himself in Georgia, Rob from Nuand in California, and Rob VK8FOES in Australia. There are some limitations where external users cannot yet dial the EUD on the BladeRF BTS and the BTS cannot directly call cell phone numbers within the US, but it is possible Cemaxecuter could resolve these bugs in the future.

    Watch Cemaxecuter use YateBTS on YouTube:

    Part 1 – Setting up YateBTS
    Part 2: Making a Group Call with YateBTS

    Pull Request Makes Improvements to SigDigger’s Panoscope…

    SigDigger is a popular signal analyzer that runs in DragonOS. Pending updates to the panoramic spectrum view feature will allow for seamless spectrum scanning. Thanks to some open-source contributions from sultanqsim the panoramic spectrum feature no longer experiences random lags and unresponsiveness. It’s a bonus for quick spectrum analysis without the headache.

    See the pull request here: https://github.com/BatchDrake/SigDigger/pull/245

    Airspy Promises Release of a New SDR Dubbed “Ranger”…

    The Airspy developers are teasing the release of their “Ranger” SDR claiming that it will be an improvement on their HF+ Discovery. Reviewing their specifications, it seems that the Ranger will combine the performance of the HF+ Discovery, R2, and SpyVerter to enable a scan range from 0.5 kHz to 1.75 GHz, a sample rate of 36 MSPS, and -140 dBm sensitivity. This will allow users to view a wider portion of the spectrum than both the R2 and HF+ Discovery without sacrificing the ability to analyze weak signals in all available bands. While it is feasible for users to connect a SpyVerter to the R2 to extend range into the HF band, this extension sacrifices frequency range for sensitivity and adds some connection loss. AirSpy does not advertise the cost of the Ranger, but the HF+ Discovery costs $169 so you should assume it will cost at least as much. Based on their other offerings, it is not likely that the SDR will cost more than $400 given the HF+ Discovery and R2 contain many of the same components.

    The Airspy R2 is currently the core default SDR within the WarDragon. For those who are not aware, the WarDragon is the hardware extension to DragonOS’ stellar software suite. Where DragonOS itself makes SDR tools easy to use and access, the WarDragon gives you the hardware you need to play with these tools right away. Cemaxecuter has been pouring improvements into the platform since the first one was sold in early 2024. After selling over 20 WarDragons, his contributions are still going strong. If the Ranger truly expands the available frequency range at no cost to performance, it would be a good opportunity to expand the WarDragon’s frequency range down into the HF band.

    Airspy’s Ranger product page is here: https://airspy.com/airspy-ranger/

    Share this post:

  • May 27th to June 2nd, 2024 – RF is Not Magic and More Fun with RemoteID

    This week in DragonOS…

    Highlight of the Week: Tinkering with the RF Not Magic Lime Daughterboard…

    Expanding Drone Detection Coverage Area with Mesh Networking…

    Explore More with DragonOS…

    Share this post:

    Highlight of the Week: Tinkering with the RF Not Magic Lime Daughterboard…

    Talks of RF Not Magic (RFNM)  software-defined radios (SDR) began as early as March 2023, and after the tedious and detailed work of the RFNM team, customers received their boards this past week. Cemaxecuter was able to get hands on the RFNM Motherboard and Lime daughterboard. After testing the newly arrived boards with SigDigger and GNU Radio, the boards performed as well as their designers intended. Plan to see more detailed projects and videos with the RFNM Motherboard and Lime daughterboard soon.

    RFNM is taking a different approach to the consumer SDR market by separating the design of the SDR from the processing unit, such as a CPU or FPGA. This approach creates a modular and expandable interface that can be swapped based on each user’s desired application. Therefore, RFNM has three important components within its ecosystem: the motherboard, the daughterboards, and the interface.

    The RFNM motherboard has an ADC/DAC for converting between analog and digital signals, a timing chip, CPU, e-SIM, and RF switching logic. The motherboard exposes all of these components to its connected daughterboards which can implement an SDR, signal generator, oscilloscope, or any other desired application that relies on this fundamental set of integrated circuits.

    Daughterboards are independent of one another and provide specific functionality that the end-user requires. Currently, RFNM supports two daughterboards: The Lime and The Granita. RFNM plans to design more daughterboards in the future, and if you are an ambitious RF PCB designer, you can develop custom daughterboards. RFNM provides a template board as a starting point, but you must join their Discord to download the files from the board-design-rf112 channel. As for the Granita, it boasts an impressive 10-7200 MHz operational range with two SMA ports that can simultaneously receive. Alternatively, one port can receive and the other can transmit. Cemaxecuter owns the Lime daughterboard which covers 1-3500 MHz with only one SMA port available for either transmit or receive.

    The RFNM interface connects the motherboard to the daughterboards. There are two interface slots on the RFNM motherboard: the primary and secondary. It is not immediately clear whether users can connect multiple application daughterboards to the motherboard simultaneously; however, the purpose of the primary interface is to offer higher performance to the daughterboard while the secondary interface offers display and other ancillary features.

    Orders for new RFNM boards are closed as the developers focus on delivering to their current backers. The developers will open up pre-orders again as long as the hardware is in high demand. At that point, a new manufacturing batch can take place and boards could be delivered in as little as 2-3 months. The easiest way to signal demand is to sign up for RFNM’s newsletter on their website and engage RFNM on Twitter and Discord. When the pre-ordering window does open back up, users must purchase an RFNM motherboard for $299 and buy any combination of the Lime ($179) or Granita ($249) daughterboards. A breakout board is also available for $29, but the main purpose of this add-on will be for testing.

    RFNM Website: https://rfnm.io/

    RFNM twitter: https://twitter.com/rfnotmagic

    RFNM GitHub: https://github.com/rfnm

    Expanding Drone Detection Coverage Area with Mesh Networking…

    After boasting a 772m RemoteID decode two weeks ago, Cemaxecuter wanted to continue to expand the applicability of decoding these packets in real time. The idea for increasing the applicability of RemoteID decoding is to create a network of nodes that can collectively decode RemoteID packets for a larger coverage area. The first step in this direction involved sharing Bluetooth packets decoded by Sniffle over a HaLow mesh network. The simple test last week involved two Alfa HaLow-U nodes. One node was connected to a base station and the second node was connected to a WarDragon 400m away from the base station. The WarDragon contained a SONOFF CC2652P to decode RemoteID packets and send the decoded packet to the WarDragon over HaLow.

    The base station was able to receive decoded RemoteID packets and unpack position information about the drone, as expected. During the test, Cemaxecuter reached a new max distance at which the WarDragon decoded RemoteID: 1000 meters! This means the total separation between the base station and the drone was 1400 meters, almost 1 mile.

    The current workaround to share RemoteID packets over the network requires running Sniffle via the command line and then using Netcat to pipe Sniffle’s output file across the network. The “To-Do” for the future involves real-time mapping support so that multiple WarDragons can feed a single map on the base station.

    Rokland Alfa HaLow-U Documentation and Support: https://store.rokland.com/pages/alfa-halow-u-tube-ah-802-11ah-support-page

    Explore More with DragonOS…

    Share this post:

  • June 3rd to June 9th, 2024 – Meshtastic SDR, DragonTooth, and Artemis

    This week in DragonOS…

    Highlight of the Week: Meshtastic Receiver Implementation in GNU Radio…

    DragonTooth Addition to the WarDragon…

    Artemis Version 4 Released…

    Explore More with DragonOS…

    Share this post:

    Highlight of the Week: Meshtastic Receiver Implementation in GNU Radio

    Josh Conway, aka “crankylinuxuser”, aims to implement a full transceiver stack for a software defined radio (SDR) to enable it to act as a node on a Meshtastic radio network. Currently, the transmit functionality is still in development, but you can experiment with his receive capabilities by cloning his GitLab repository: https://gitlab.com/crankylinuxuser/meshtastic_sdr. Meshtastic uses LoRa at the physical layer, but it is important to note that Meshtastic’s network layer is not LoRaWAN. LoRaWAN is a specification maintained by the LoRa alliance. Meshtastic does not comply with this specification, you can read more about why its developers chose to diverge from the LoRaWAN standard and other facts about the frequencies, bandwidth, and power available on Meshtastic Networks here: https://meshtastic.org/docs/overview/. Lastly, Conway’s solution to implementing a full transceiver stack for Meshtastic on a SDR is not as trivial as connecting up a GNU Radio Source block to gr-lora_sdr: https://github.com/tapparelj/gr-lora_sdr. gr-lora_sdr is a dependency of the transceiver stack, but crankylinuxuser’s implementation builds a network decoder on the physical layer transceiver provided by gr-lora_sdr.
     
    Meshtastic_SDR can run on any SDR that is supported by the Soapy driver, which means if you have a HackRF, BladeRF, SDRPlay, PlutoSDR, Airspy, or RTLSDR you can try out this project. The benefit of implementing this transceiver on a SDR rather than a microcontroller connected to a LoRa chip, like the SX1262, is that you can look at multiple channels simultaneously. This includes each of the seven presets! Contrast this with a Meshtastic-specific device that is configured to operate on one channel at a time. This means, with enough processing power, you can:
    • Implement a sniffer to monitor for Meshtastic traffic near you
    • Create a node that siphons all preset channel traffic and feeds it into Meshtastic’s public MQTT server. Here’s a map of all nodes connected to this public server: https://map.technicallyrural.com/. 
    • Visualize and troubleshoot your Meshtastic-specific device without needing to purchase multiple devices
    As a final note, if you decide to run Meshtastic_SDR on DragonOS, be careful not to install the most recent version of protobuf with Python when testing out Meshtastic_SDR. Other applications, like Kismet, depend on older version of the protobuf that is already installed on DragonOS. Therefore to run this you should be within a virtual environment. Watch Cemaxecuter walk trhough this process in his recent video:

    DragonTooth Addition to the WarDragon

    Cemaxecuter is back at it again with the updates to the WarDragon. This last week he officially released a new listing of the WarDragon that includes the capability for RemoteID drone detection, aptly named “DragonTooth”, that was mentioned in the blog from last week and the week before. Check out the new listing: https://cemaxecuter.com/?product=wardragon-w-case.

    Among the various key features that Cemaxecuter lists on his website, special care was taken to ensure that interference from the addition of the DragonTooth would be limited. Cemaxecuter experimented with various internal layouts of the WarDragon and used a separate SDR to determine whether interference was present or not. In some misconfigurations, interference was noticeable in the 100 MHz range. If you purchase the newest edition of the WarDragon and want to make custom changes to the layout, keep this aspect in mind to save yourself from hours of troubleshooting.

    Coming soon to the WarDragon, Cemaxecuter plans updates to the internal custom 3D printed framing. PETG plastic will be substituted for PLA to provide for greater temperature resistance, and some framing modifications will ensure that all peripheral components are seated in the optimal position to prevent components from jarring loose in rugged outdoor travel conditions.

    Artemis Version 4 Released

    Last week the developers behind Artemis, software for assisting “radio frequency (RF) signal identification and storage”, released version 4. Check it out here: https://aresvalley.github.io/Artemis/. It currently contains nearly 495 recognized signals and also provides some assistance for space weather tracking. You can review the full changelog between version 3.2.4 and their version 4 release, but the RTLSDR blog did a good job of summarizing recent improvements: https://www.rtl-sdr.com/tag/artemis/.
     
    After some troubleshooting with the developers, Artemis can run on DragonOS which means that its users will have the ability to search this offline database when trying to identify signals on the radio spectrum. Perhaps in the future, contributions will pair signals to the various tools that reside in DragonOS to enable quick analysis.
     
    If you want to try out Artemis on DragonOS, let us know whether or not it ends up working for you. Here are the steps that should allow you to run v4.0.3:
    ~$ git clone https://github.com/Aresvalley/Artemis.git
~$ cd Artemis
~/Artemis$ git checkout v4.0.3
~/Artemis$ sudo apt-get install libxcb-cursor0
~/Artemis$ python3 -m venv .venv
~/Artemis$ source .venv/bin/activate
(venv) ~/Artemis$ pip3 install -r requirements.txt
(venv) ~/Artemis$ python3 app.py

    If successful, you should see the Artemis window below appear. To exit the Python virtual environment, simply enter the command deactivate in the terminal.

    Explore More with DragonOS…

    Share this post:

  • June 10th to June 16th, 2024 – Updates to GNU Radio, Meshtastic SDR TX, and RFNM Software

    This week in DragonOS…

    Highlight of the Week: GNU Radio Updates for DragonOS are In Progress…

    Meshtastic SDR Adds Transmit Functionality…

    Recent Developments with the RFNM Board…

    Explore More with DragonOS…

    7/1/2024: Added YouTube link that covers Meshtastic transmit and receive functionality with a SDR

    Share this post:

    Highlight of the Week: GNU Radio Updates for DragonOS are In Progress

    DragonOS comes with 30 GNU Radio Out-of-Tree (OOT) modules ready-to-go out of the box, in addition to the Core blocks themselves. Take a look at the difference between a fresh install of GNU Radio on Ubuntu versus a fresh install of DragonOS

    One thing to note, however, is that DragonOS currently is packaged with GNU Radio Version 3.10.4 which was released in September 2022. GNU Radio has not released a new major or minor version since then, but their most recent release of 3.10.10 this past April comes with some improvements in functionality including:

    • upgrades to QT GUI (gtk front end will be deprecated in the future) which includes the ability to save some plots as images
    • some upgrades to gr-soapy
    • Python minimum version changed from 3.6.5 to 3.7.2 to support type hinting
    • text labels to specify types for block parameters, instead of background colors which were difficult to read and remember

    Here is the change log for just the 3.10.10 release: https://github.com/gnuradio/gnuradio/releases/tag/v3.10.10.0

    Thankfully, there has not been a minor version change since January 2022 with the release of v3.10.0. GNU Radio follows a slightly different development model than other software you might be familiar with, such as semantic versioning, because a minor version update is not always backwards compatible. You can read the philosophy of the GNU Radio developers on this topic here: https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide#Development_Model

    The differences in minor versions, i.e. 3.9 and 3.10 or 3.8 and 3.10, is why it is hard to include all 3rd party OOTs in DragonOS. OOTs that GNU Radio supports can be found on their GitHub while all 3rd party OOTs are found here: https://www.cgran.org/. To further complicate things many apps in DragonOS are dependent on GNU Radio such as GQRX, QRadioLink, op25, and trunk-recorder. This means that with every GNU Radio update each of the OOTs and dependent apps must also be rebuilt. Thankfully, DragonOS makes it so that you don’t need to do this process yourself.

    For the DIYers, GNU Radio wiki also has some information about upgrading flow graph versions if you really find an old flow graph that you want to run on the updated version of GNU Radio in DragonOS: https://wiki.gnuradio.org/index.php?title=Porting_Existing_Flowgraphs_to_a_Newer_Version.

    DragonOS would like to thank the many awesome contributors of the GNU Radio Project for these updates. If you are interested in GNU Radio, they are hosting their annual conference in Knoxville, TN from September 16th to September 20th. You can buy tickets now through August 30th at the early bird rate of $450 before it increases in the days immediately before the conference. They also extended their call for proposals until July 8th if you are interested in contributing a talk, workshop, paper, poster, or lightning talk.

    Meshtastic SDR Adds Transmit Functionality

    While the changes from GNU Radio 3.10.4 to 3.10.10 alone were enough justification to upgrade, recent developments on Meshtastic SDR also motivated the version upgrade on DragonOS. Meshtastic SDR runs GNU Radio Version 3.10.9.2 and this past week the developer added transmit functionality. That was fast! Just last week we discussed successful receive experiments in DragonOS using Meshtastic SDR. Here is the commit with the addition of TX functionality on the US LongFast channel: https://gitlab.com/crankylinuxuser/meshtastic_sdr/-/commit/dffdef3d7dbc9dd97e1af5b97b14de2e64f1ff2d.

    If you enjoy the Meshtastic SDR project make sure to give the repository a star on GitLab so you can keep up with the developments that Josh is sure to add in the future.

    Recent Developments with the RFNM Board

    A couple of weeks ago, we mentioned the release of the RFNM board and promised future updates. The first of those updates is here. Where the first post focused on the RFNM hardware itself, this post addresses some of the software that can interface with the board. The main piece of software is librfnm, the host driver allowing your computer to recognize and communicate with the board: https://github.com/rfnm/librfnm

    Looking at this repository, the developer of Sniffle and developer of SDR++ are clearly interested in RFNM. To no surprise, SDR++  works well with the RFNM right now. You can see the recent commits and issues addressing further improvements with the RFNM board here:  https://github.com/AlexandreRouma/SDRPlusPlus.

    Cemaxecuter showed us on X just how well SDR++ works with the RFNM’s Lime Daughterboard. 122.8 MHz of instantaneous bandwidth is just a ridiculously high value for a consumer grade SDR: https://twitter.com/cemaxecuter/status/1801981663779438595

    In addition to a host driver, RFNM also released a driver that is compatible with soapy: https://github.com/rfnm/soapy-rfnm. An interesting application of the Soapy driver for the RFNM came from viperbjk on X. The post shows that GNU Radio can use this driver to dump captures from the 2.4GHz band into Wireshark, which then detected Bluetooth packets: https://twitter.com/viperbjk/status/1802009731327742114

    viperbjk doesn’t seem to have a GitHub repo with this project, but the picture makes it pretty clear how you could recreate this behavior if you have a RFNM lime daughter board.

    Lastly, since the RFNM has an ARM core, it is a perfect candidate for SDR4Space’s ARM release. Even though this release was originally intended for the Pi, there are only a couple of dependencies that require installation for SDR4Space to work on the RFNM board. One major difference between this approach and the approach with librfnm and soapy-rfnm is that the software runs native on the RFNM itself – no host required. However, the no host functionality required a small hack that tricked the RFNM to recognize itself via a USB cable connected to its own port in a loop. Check out the gist for this here: https://gist.github.com/inganault/054fe1ec482b63352db61d3925c76e49. The arm core doesn’t really stand a chance against processing 122.8 MHz of IQ capture, but it is still a cool example showcasing the capability of the RFNM board. The clunkiness of connecting a USB cable in a loop will likely be resolved by a RFNM firmware patch in the future, but it is an acceptable workaround for the time being. It is also possible that, if the application demands, a compute-intensive add-on board to the RFNM could enhance native processing on the RFNM. In applications where the ARM core can handle the IQ data streaming from the RF daughter board, it is convenient to operate in the absence of a connected host.

    Explore More with DragonOS…

    Share this post:

  • June 17th to June 23rd, 2024 – Testing the Updated ISO

    This week in DragonOS…

    Highlight of the Week: Updated DragonOS Image Available for Testing…

    Explore More with DragonOS…

    Highlight of the Week: Updated DragonOS Image Available for Testing

    An updated version of DragonOS is available for download here: https://drive.google.com/drive/folders/1X-NAxJFIN9XNheomV-69aHwJTWQK9t2U. On Linux, you can verify the integrity of the file with the command sha256sum DragonOS_FocalX_R36_test3.iso or md5sum DragonOS_FocalX_R36_test3.iso from the same directory as the download. If you are on Windows, you can use the command prompt to check the SHA256 or MD5 hash with certutil -hashfile DragonOS_FocalX_R36_test3.iso SHA256 or certutil -hashfile DragonOS_FocalX_R36_test3.iso MD5. The table below is a summary of the updates to the new image.

    Tool NameVersion ChangeLink to SourceDescriptionLink to Videos
    Whisperv1.5.2 to v1.6.0https://github.com/ggerganov/whisper.cpp/tree/v1.6.0Whisper.cpp is a high-performance implementation of OpenAI’s Whisper voice to text model that can infer multiple languages.https://www.youtube.com/watch?v=AKAfKgERqzY
    Lua Radiov0.10.0 to v0.11.0https://github.com/vsergeev/luaradioSimilar to GNU Radio, Lua Radio is a flowgraph-based signal processing framework. Unlike GNU Radio, Lua Radio offers a fraction of GNU Radio’s memory footprint and also has fewer dependencies than GNU RadioN/A
    Iridium ToolkitCommit hash 0598b80abf6e1c5644813f726e9c96425d5fdee7 to 47cd09784c987bc0250b701508599485651c364dhttps://github.com/muccc/iridium-toolkit/tree/experimental-new-pkt | Iridium toolkit is a simple toolkitTool to decode and analyze Iridium signalshttps://www.youtube.com/watch?v=1cU3CXF8hxg
    SDRplayv3.14.0 to v3.15.2https://www.sdrplay.com/api/The SDRplay API is required by all applications to communicate with SDRplay hardwarehttps://www.youtube.com/watch?v=A_aqA377i2w&list=PLXjRrYsXOd9ctb2Xo56YxZy2oNs3-SkT2
    SoapySDRPlay3Commit hash cd79b32ace2e9e34f198693fcc7c0028bf27add0 to 8ef31b232a904ac3061edaa70d96f0155c0bba45https://github.com/pothosware/SoapySDRPlay3This was updated to comply with the new API so it can be used with the Soapy driverN/A
    DumpVDL2no version changehttps://github.com/szpajder/dumpvdl2Rebuilt the binary given that dependencies for this were also updatedN/A
    LinRadCommit hash e4cbf20ca585693aa0e94401e8795469852e534f to 11f8bb5dcd7e69202305181891e2605cc5c43a7ahttps://github.com/fventuri/linradLinRad is a SDR receiver that supports the SDRplayN/A
    RSP-TCPno version changehttps://github.com/SDRplay/RSPTCPServerUpdated to comply with SDRplay API 3.15. This application enables streaming of your RSP over TCPhttps://www.youtube.com/watch?v=_l5mYVz_kw4
    SDR++v1.1.0 to v1.2.0https://github.com/AlexandreRouma/SDRPlusPlusSDR++ is a SDR receiver GUI application that makes it easy to interact with and identify signals on the spectrumhttps://www.youtube.com/watch?v=kV042kcCzic
    SatDumpv1.1.4 to v1.2.1https://github.com/SatDump/SatDumpSatdump is a generic satellite data processing softwarehttps://www.youtube.com/watch?v=vfx1XM4BhUA
    Spikev3.9.0 to v3.9.6https://signalhound.com/spike/Spike is a free spectrum analyzer software from SignalHound that is compliant with their hardware offeringshttps://www.youtube.com/watch?v=QkfiALAUIhA
    SDRTrunkv0.6.1 to nightlyhttps://github.com/DSheirer/sdrtrunkSDRTrunk is a cross-platform java application for decoding, monitoring, recording and streaming trunked mobile and related radio protocols using Software Defined Radios (SDR)https://www.youtube.com/watch?v=1EAVdWCZUes
    PySDRN/Ahttps://pysdr.org/An updated version of the free and open resource for learning more about how to apply DSP to SDRs using PythonN/A
    Sparrow WiFiCommit hash 741dfceb2b584bf83baca07b45b6a5cf11ef1f43 to f9a39210eed9141707760ffd4fb31e79f991a15chttps://github.com/ghostop14/sparrow-wifiSparrow Wi-Fi is a graphical Wi-Fi analyzerhttps://www.youtube.com/watch?v=TmsT373vULM&list=PLXjRrYsXOd9f5GZGfl4LwRdyidQ6ThlLS
    SDRAngelv7.19.1 to v7.21.3https://github.com/f4exb/sdrangelSDRAngel is a GUI software analysis tool for various SDRshttps://www.youtube.com/watch?v=cm7diML4JhM&list=PLXjRrYsXOd9eZiem2rLf41jJkoYcDorFd
    HackRFv2023.01.01 to v2024.02.1https://github.com/greatscottgadgets/hackrf/releasesUpdated hackrf software tools. Note, for this release to function on your HackRF, you must also update your firmware to this version. libhackrf and hackrf-tools have been updated for youhttps://www.youtube.com/watch?v=GzpVKCiZqsY&list=PLXjRrYsXOd9cgWQo0mKymyqgdDJ6ERlQ1
    GNU Radiov3.10.4 to v3.10.10https://github.com/gnuradio/gnuradiosee last week’s blog post for more details. All OOTs were rebuilt, and the OOTs that are listed in this table were tested and/or addedhttps://www.youtube.com/watch?v=s6jLoGNqtzA&list=PLXjRrYsXOd9fLcpuf9kGMZrXSWlG7xzQ0
    GR-Iridium (tested)N/Ahttps://github.com/muccc/gr-iridiumThis module provides blocks to build an Iridium burst detector and demodulatorN/A
    GR-ieee802-11 (tested)N/Ahttps://github.com/bastibl/gr-ieee802-11An IEEE 802.11 a/g/p transceiver for GNU Radio that is fitted for operation with Ettus N210s and B210sN/A
    GR-Foo (tested)N/Ahttps://github.com/bastibl/gr-fooA collection of custom blocks that are not directly associated with a projectN/A
    GR-NRSC5 (tested)N/Ahttps://github.com/argilo/gr-nrsc5This project implements an HD Radio transmitter in GNU RadioN/A
    GR-Smart_Meters (tested)N/Ahttps://github.com/BitBangingBytes/gr-smart_metersContains various decoders for smart meter manufacturersN/A
    GR-Lora_SDR (tested)https://github.com/tapparelj/gr-lora_sdrImplementation of a LoRa transceiver with all the necessary receiver components to operate correctly even at very low SNRsN/A
    GR-Lora (added)N/Ahttps://github.com/rpp0/gr-loraGNU Radio blocks for receiving LoRa modulated radio messages using a Software Defined Radio (SDR)N/A
    GR-SDRplay3 (tested)N/Ahttps://github.com/fventuri/gr-sdrplay3The GNU Radio OOT module for the SDRplay sink/source was updated to reflect the GNU Radio version that was also updated in this new releaseN/A
    LTESnifferv2.1.0 to v2.1.1 (develop branch)https://github.com/SysSec-KAIST/LTESnifferLTE Sniffer is an open-source LTE downlink/uplink eavesdropperhttps://www.youtube.com/watch?v=mRWpxzNnKQw
    QRadioLinkno version changehttps://github.com/qradiolink/qradiolinkQRadioLink is a VOIP SDR transceiver application using Internet protocols for communication, built on top of GNU radio. It needed rebuilt due to the updated GNU Radio versionhttps://www.youtube.com/watch?v=UKQu6B4Ofqc

    Lastly, a recent change that is not included in the ISO was the addition of https://github.com/deeptho/neumodvb which is a DVB Settop box and dx-program for Linux. If you would like this capability in your release of DragonOS, the build instructions are here: https://github.com/alphafox02/neumodvb.

    It is important to note that this ISO is still based on Ubuntu 22.04 LTS. Despite the release of Ubuntu 24.04 LTS this past April, 22.04 will be supported until April 2027. Ubuntu 24.04 LTS will be supported until 2029, so it does not make sense to upgrade just yet. You can read more about Ubuntu’s release cycle here: https://ubuntu.com/about/release-cycle. It is possible the next base image upgrade will not take place until Ubuntu 26.04 to avoid the need to refactor upgrades and migrations of software between LTS versions every two years.

    If you notice any strange behavior or something doesn’t work with the new ISO, send a message to @cemaxecuter on X https://x.com/cemaxecuter or email him at cemaxecuter@protonmail.com. You’ll get a shoutout for your help and improve the next release of DragonOS

    Explore More with DragonOS…

  • June 24th to June 30th, 2024 – Parsing RemoteID Output and Exploring NeumoDVB

    This week in DragonOS…

    Highlight of the Week: RemoteID JSON Decoding…

    Exploring DVB with NeumoDVB…

    Explore More with DragonOS…

    Highlight of the Week: RemoteID JSON Decoding

    RemoteID continues to be a hot topic. Following DragonOS initial support for RemoteID, extending the range at which RemoteID packets were detected, and the addition of the DragonTooth to the WarDragon, this week it is now possible to parse the JSON output of RemoteID packets.

    Previously, the setup for RemoteID involved Sniffle decoding the BlueTooth packets, followed by a Wireshark dissector that would enable users to breakdown the contents of the packet in Wireshark. Cemaxecuter tweaked this process to instead go from Sniffle decoded BlueTooth directly to Tshark which prints JSON data in real time to stdout. The key advantage to this approach that the JSON data can be leveraged in a custom application to parse information that you care about. Watch Cemaxecuter walk through the steps you need to take in order to replicate this flow – you don’t even need to have a RemoteID transmitter because there is a packet you can test on in the wireshark dissector repo.

    You can use the script below to test this on your WarDragon, DragonTooth, or custom instance of DragonOS. If you just want to test with a pre-captured packet, you can omit the second and third lines – just make sure to specify the correct path to your packet capture in the first line.

    $ pcap_path='/tmp/pcap_fifo'  #replace with anything, including a precaptured pcap
$ mkfifo $pcap_path  #for live capture
$ ./sniff_receiver.py -l -e -o $pcap_path  #for live capture, from Sniffle/python_cli
$ tshark -r $pcap_path -X lua_script:opendroneid-dissector.lua -T json  #from wireshark-dissector repo

    Do you have an interesting idea for what you might be able to do with this JSON data? Let us know! It seems the FAA is using this information to enforce drone flight restrictions in sensitive areas. It is hard to determine the authenticity of this letter, but nonetheless, it is not a good idea to violate FAA flight restrictions: https://www.reddit.com/r/drones/comments/1dnkaof/the_faa_sent_me_a_letter_today/. If you are a drone pilot and want to ensure that you are operating within the FAA’s guidelines, you can use the FAA’s B4UFLY service or any of the other supported flight restriction notification services, such as UASSidekick. With the Fourth of July holiday just days away, make sure you are practicing good drone safety!

    Exploring DVB with NeumoDVB

    Last week, the blog covered the various updates to DragonOS but also briefly mentioned the addition of one new tool: NeumoDVB. According to Artemis, Digital Video Broadcasting Terrestrial (DVB-T), is “a digital broadcast television format used in Europe and in many other countries in the world.” In addition to DVB-T, there is also DVB-C (cable), DVB-H (handheld/mobile), DVB-T2 (terrestrial version 2), DVB-S (satellite), and DVB-S2 (satellite version 2).

    NeumoDVB interfaces with DVB tuners that are based on ST Microelectronics STID135-WB (discontinued) or STV091X, Texas Instruments’ TAS2110, or Silicon Labs’ SI2183. According to the NeumoDVB GitHub, some compatible cards are as follows:

    Rob VK8FOES on YouTube managed to have a tuner that was compatible with NeumoDVB and was able to verify that the process works on DragonOS. Here is a screenshot from Rob’s system.

    You can read the following instructions for how to install on DragonOS. The instructions were verified to work on the WarDragon as well: https://github.com/alphafox02/neumodvb/blob/master/docs/INSTALL.md.

    As a bit of interesting history, the RTL-SDR is based on the RTL2382U chip which was originally a DVB-T tuner. You can read more about its history here: https://www.rtl-sdr.com/about-rtl-sdr/. Unfortunately, tuners from common SDRs such as the RTL-SDR (Rafael Micro’s RTL2382U), AirSpy (Rafael Micro’s R820T2), SDRPlay (Mirics’ MSI2500) are not directly compatible with NeumoDVB. Where SDRs aim to deliver a variety of software applications, DVB included, the tuners compatible with NeumoDVB listed above are built for DVB applications only. You might want a standalone tuner if you are very dedicated to DVB applications and want the service support that a company like TBS could provide in the case of misconfigurations. If you are interested in exploring DVB with a SDR, this is possible through software installed on DragonOS like SDRAngel, LeanSDR, GNU Radio Core Blocks, or SatDump and on other 3rd party software such as gr-dvbs2rx, gr-dvbgse, or dvb-gse.

    Explore More with DragonOS…

  • July 8th to July 14th, 2024 – Map Visualization for RemoteID and Reimaging the WarDragon

    This week in DragonOS…

    Highlight of the Week: Map Visualization Now Available for RemoteID…

    WarDragon Reimaging Instructions Coming Soon…

    Explore More with DragonOS…

    Highlight of the Week: Map Visualization Now Available for RemoteID

    In the very first blog post, we highlighted the utility of Sniffle to decode RemoteID packets. bkerler, aka @viperbjk, has recently extended the functionality of this firmware with updates to the Python CLI. Check out his updates here: https://github.com/bkerler/Sniffle. His updates add two key features:

    • sending parsed remoteID output to ZMQ
    • ability to transmit from a Sonoff for testing purposes

    The reason why sending parsed output to ZMQ is useful is because applications like NodeRed can receive the published JSON and parse it in order to do things like updating the position of the detected drone on a map. Watch Cemaxecuter walk though this process in his recent YouTube video:

    With the DragonTooth, WarDragon owners can now monitor for RemoteID packets and visualize updates on a map. This application is similar to the ADSB, VDL2, and ACARS visualization applications contained within Flight View GUI; in fact, the NodeRed flow is based off of one of the Docker containers within the flightviewGUI application. Check out the modifications here: https://github.com/alphafox02/flightview_gui

    Cemaxecuter is also working on a version to parse the ZMQ output of the Sniffle receiver into TAK, but that is still in development. If you’d like to contribute, his latest progress is here: https://github.com/alphafox02/RIDtoTAK

    WarDragon Reimaging Instructions Coming Soon

    With the new version of DragonOS Focal released recently and now available on SourceForge, the WarDragon owners are also due for an update.

    There will be a video released soon that will show how to update the computer inside the WarDragon as well as how to store any files youre interested in backing up to take to the next version. If you do not get an email by July 19th (this Friday) and purchased a WarDragon, please reach out to Cemaxecuter to receive the files you’ll need. The video instructions will alert you to this, but just to make it clear ahead of time, you will not use the USB hub to conduct the reimage. The drive and Clonezilla Live USB will need to be connected directly to the WarDragon’s USB ports.

    The process will use Clonezilla to reimage the WarDragon to R36, so in the meantime, back up any key files you wish to take to the new update. To help facilitate a backup, DragonOS comes with Timeshift by default.

    Alternatively, you can send Cemaxecuter a drive with return shipping for a free upgrade as shown in the X post below: https://twitter.com/cemaxecuter/status/1813364075914547403

    Explore More with DragonOS

  • July 1st to July 7th, 2024 – End-of-Train Decoding and RFNM’s Second Production Run

    This week in DragonOS…

    Highlight of the Week: Decoding End-of-Train (EOT) Packets…

    RFNM Campaign Round 2 Now Open…

    Explore More with DragonOS…

    Highlight of the Week: Decoding End-of-Train (EOT) Packets

    Trains use more than just stoplight signaling to report status and relay information. Head-of-Train (HOT), End-of-Train (EOT), and Distributed Power Units (DPU) are the names of radio telemetry signals that trains emit to monitor “brake status and accidental separation information to the head locomotive” (Artemis). These signals emit from trains roughly every 40 seconds but will immediately send a signal if an accident occurs. The Association of American Railroads (AAR) assigned the frequency 457.9375 MHz to these signals, but some rail companies use different frequencies such as Norfolk Southern’s 161.115 MHz. You can read more about EOT in Robert McGonigal’s blog post on Trains.com or directly from the AAR. Shown below is the EOT signal’s profile in Artemis, which has recently been patched to v4.0.5 from v4.0.3.

    Cemaxecuter released a video nearly a year ago covering decoders such as SoftEOT for Windows (note you must join the group before you can download the software) and PyEOT for Linux. bkerler updated the old flowgraph for PyEOT to comply with GNU Radio 3.10.X. Thankfully it did not involve a rewrite of the decoder itself! The next helpful open-source contribution would be creating a proper GNU Radio Out-of-Tree module for PyEOT to decode train packets within GNU Radio itself. Currently, PyEOT requires that the user runs a flowgraph to demodulate FSK before running a Python script to decode the demodulated packets from GNU Radio.

    In the post below, you can see the output of PyEOT running with the new GNU Radio 3.10.X flowgraph. Thanks bkerler for the contribution!

    RFNM Campaign Round 2 Now Open

    If you missed the first release of the RFNM board and were inspired by some of the recent open-source developments with RFNM, you will be happy to hear that the project is now open for round two of production. You can visit the main project page if you are interested in buying a motherboard, a daughterboard, or both: https://rfnm.io/campaign.

    RFNM states that they will start manufacturing when this round is 50% funded, and as of this writing, they are already 4% funded. It is unclear how long the campaign window will be open, and it is important to know that backing the campaign does not guarantee you will receive a device. However, given the success of the first manufacturing run, the risk of this is much lower.

    Explore More with DragonOS

  • July 15th to July 21st, 2024 – Dragon Drone Takes Flight, WarDragon Update Released, and a Feature Review of Tempest

    This week in DragonOS…

    Highlight of the Week: Dragon Drone Takes Flight…

    WarDragon Updates for DragonOS R36 Released…

    Feature Review: Tempest…

    Explore More with DragonOS…

    Highlight of the Week: Dragon Drone Takes Flight

    Canine Defense Technologies aims to “bridge the U.S. Defense Tech hardware gap.” This week they released the video below showing the Dragon Drone in flight: https://x.com/K9DefenseTech/status/1815904436469793026

    The Dragon Drone is a project that is still in development through a collaboration between Cemaxecuter, Canine Defense Technologies, and ARK Electronics. The objective of the project is to increase radio survey capabilities within DragonOS through a highly mobile platform. While the WarDragon can be carried or driven around, the DragonDrone can quickly deploy from the ground to high altitudes for favorable RF reception and traverse space in a more flexible manner than the WarDragon.

    ARK Electronics provides the flight computer through its Jetson Orin PAB Carrier, which also enables a Jetson Orin running DragonOS to operate on board. Canine Defense is doing a great job integrating the aircraft body and electronics – we’re looking forward to more updates including specifications, hardware detail shots, and more videos as the drone continues towards its release. The best place to monitor updates is by following Cemaxecuter and Canine Defense Technologies on X.

    WarDragon Updates for DragonOS R36 Released

    Last week, we mentioned that the WarDragon is due for its update to DragonOS Focal R36. That update is now released. Don’t worry, this one doesn’t create a kernel panic, let alone a global one, like CrowdStrike’s update that went out to Windows systems this past week. If you own a WarDragon and did not receive update instructions from Cemaxecuter, please reach out to him directly via the contact information below to resolve your issue.

    Included with the update is a sha256sum hash for the update file as well as a video for how to update the computer inside the WarDragon. After downloading both the download file and hash file, you can verify the integrity of the download by running the command below:

    sha256sum --check WarDragon_2024-07-16-11-img.tar.gz.sha256.txt

    The output should appear as follows:

    dragon@dragon:~/Downloads$ sha256sum --check WarDragon_2024-07-16-11-img.tar.gz.sha256.txt 
WarDragon_2024-07-16-11-img.tar.gz: OK

    If you see the below output, please contact Cemaxecuter directly because the download file’s hash does not match the original value:

    dragon@dragon:~/Downloads$ sha256sum --check WarDragon_2024-07-16-11-img.tar.gz.sha256.txt 
WarDragon_2024-07-16-11-img.tar.gz: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

    When updating your WarDragon, you will not use the USB hub to conduct the reimage. The video instructions for updating your WarDragon will alert you to this. The drive and Clonezilla Live USB will need to be connected directly to the WarDragon’s USB ports.

    The process will use Clonezilla to reimage the WarDragon to R36, so before you update, back up any key files you wish to take to the new update. DragonOS comes with Timeshift by default, so you can use that tool if you prefer.

    If you prefer, you can send Cemaxecuter a drive with return shipping for a free upgrade as shown in the X post below: https://twitter.com/cemaxecuter/status/1813364075914547403

    Feature Review: Tempest

    Wikipedia defines TEMPEST as a “a U.S. National Security Agency specification and a NATO certification referring to spying on information systems through leaking emanations, including unintentional radio or electrical signals, sounds, and vibrations.” The specification also includes how to prevent equipment from spying attempts. In 2014, Martin Marinov developed TempestSDR which brought the capability of eavesdropping on HDMI, DVI, and VGA to SDRs such as the SDRPlay and Ettus series. TempestSDR ships with DragonOS Focal R36.

    In 2021, Federico Larroca implemented TempestSDR in GNU Radio, creating gr-tempest. gr-tempest also ships with DragonOS Focal R36 and you can watch Cemaxecuter demonstrate the capability of eavesdropping with gr-tempest on electronic equipment emissions with a RTL-SDR or eavesdropping on a monitor with SDRPlay. This out-of-tree (OOT) module was updated within DragonOS to version 3.10.10 a couple of weeks ago with the rest of GNU Radio’s OOT modules. gr-tempest essentially makes the usage of Martin’s original TempestSDR in GNU Radio, which is a nice feature to have for those that are used to the GNU Radio development ecosystem. If you are interested in how gr-tempest works, you can watch Federico deliver a talk during GNU Radio’s 2021 Conference about his project.

    In a separate project in 2024, Martin’s TempestSDR also became the basis of EMEye. EMEye was developed by Yan Long and Qinhong Jiang, students at the University of Michigan and Zhejiang University, respectively. Their work extended the capability of EMEye to detect images from specific camera models that have spurious radio frequency emissions. DragonOS Focal R36 ships with EMEye and you can watch Cemaxecuter demonstrate this experimental research against one of his vulnerable cameras.

    Recently, researchers from the Facultad de Ingenieria (a.k.a Fing) in Uruguay developed Deep tempest. Their draft paper can be found on Arxiv and their experiments show Deep Tempest can reduce the character error rate for displaying words from digital video images using only spurious RF emissions. Deep Tempest does not yet ship with DragonOS, but you can experiment with the researchers code base using their GitHub repository: https://github.com/emidan19/deep-tempest. Deep Tempest improves on TempestSDR by using the DRUNet convolutional neural network (CNN) to infer the original video image from a set of training data rather than relying on AM demodulation and channel equalization. Deep Tempest also claims to make quality-of-life improvements on gr-tempest and TempestSDR by automatcially determining the best center frequency for image decoding and automatically determining the start of image frames by avoiding the blanking period that digital video signals use for audio and control data.

    Deep Tempest relies on gr-tempest to train the CNN and for the time-being is only meant to infer text-based images. Therefore, it is suggested that users employ a GPU to accelerate the training time for Deep Tempest. Furthermore, while the developers included sample training data for experimentation, this training data only pertains to the image settings that the developers used for their tests: 1920x1080p at 60 Hz. Any modifications to these settings would likely throw off the inference accuracy. Lastly, even after users obtain training data, Deep Tempest is not able to infer images in real-time.

    Comparison of gr-tempest (top), Deep Tempest (middle), and the original image (bottom). From Fig.9 of “Deep Tempest: Using Deep Learning to Eavesdrop on HDMI from its Unintended Electromagnetic Emanations”

    Explore More with DragonOS