My initial response (alpha test-release) to Radio Contra EP. 196: A lightweight, multi-platform toolkit for signals intelligence.
Bottom-Line Up Front
The alpha test-release features all software(s) and automated configuration files required to achieve the capabilities outlined under ‘Project Goals’, and was uploaded to its repository with the intention of allowing this project’s supporters to begin to explore capabilities of included tools.
However, many of the so-called “push-button” automated workflows are still in their final phases of development, and scheduled to be released in a later version.
The SIGINT-SAK project was built to provide a lightweight, comprehensive toolkit for the amateur signals intelligence researcher, who has little to no Linux experience, and is working on a budget of less than $350 USD. Ideally, researchers can use SIGINT-SAK to enhance spectral awareness without having to research, locate, install and configure the tools themselves. In its most comprehensive use cases, SIGINT-SAK integrates advanced WiFi (2.4GHz & 5.0 GHz) and Bluetooth tools, software-defined radio (HF/VHF/UHF/FRS) and traditional GPS to achieve both passive and active signals intelligence reconnaissance capabilities.
The project also seeks to bring automation to the use of the tool-kit, by leveraging a combination of Desktop Entry files, Zenity dialogue boxes and some simple bash & python scripts.
While working achieve above project goals, several slight changes to the project’s direction were implemented to make it more immediately feasible for both the developer and user. Among these were considerations toward supply chain constraints for specific hardware, depth of development required for automated workflows and hardware & drivers variation.
Supply Chain Constraints
The Raspberry Pi 4 and 4B have become price-prohibitive for many over the past several years. Though the original scope was made only for the Raspberry Pi, I addressed the constraints by tailoring a separate script for both arm64 (Raspberry Pi 4 series) and amd64 (x86_64: the average modern laptop) installation and configuration, which allows the use of toolkit from a Raspberry Pi as well as a laptop or boot-able USB. The central installation script now detects the users device architecture, then executes the appropriate installation & configuration process.
Removal of Tools for Alpha-Release
As development began on tools which automate workflows, I quickly realized that while this was alignment with the original scope, many of these tools (due to depth of development) would be better served in their own GitHub repository, then included in later releases of SIGINT-SAK.
Hardware & Drivers
Through development, I was able to test both Raspberry Pi 4 (8GB) & Raspberry Pi 4B (4GB) models, with a plethora of screens, cases, wireless keyboards, WiFi & Bluetooth adapters and antennas; as well as the latter for the amd64 (laptop) versions of the project.
While I am comfortable making product recommendations based on my testing, I’ve removed portions of the script which automate the download and installation of drivers unique to the end-users choice of hardware. When selecting a wireless adapter, remember that the device must be capable of “monitor mode”. Additionally, a panel (or “directional”) WiFi antenna is required for directional signal discovery within the 2.4GHz & 5.0 GHz ranges.
Generally speaking, I had a great time working through the majority of the challenges encountered with this project, with few exceptions. However, some of the more frustrating were in the following three:
Limited Use-Case Scenarios
As a well established series of use-cases are fundamental to building and automating any process map or workflow, I had outlined the project’s capability goals and requested use-case scenarios in a few public forums which focus on this topic. Originally, my plan was to use this as a primary dataset collection method to fine-tune the project’s capabilities and components of automation.
However and possibly due to the posts overlapping more than one holiday season, the request went unanswered. As anyone who has developed or managed a project would know, project development with a poorly defined scope is often slow and difficult, and brings a lot of second guessing as with wasted time and materials (in my case: code).
Silver Lining: I learned a lot more than I would probably need to know about Bash, and my personal code library had experienced exponential growth!
This is one of the modules required to run an included tool (Sparrow-WiFi), which works great on Kali, Ubuntu 22+, Ubuntu 22+ arm64 raspi and raspios bullseye – but will NOT install on amd64 or arm64 version of Pop!_OS. I was beating my head against the wall (or keyboard) on this for several days, when a new friend from the Offensive-Security discord channel decided to randomly jump in and help troubleshoot – also for several days.
A very special thanks @OxCwrw for their help.
On of the tools which I had used successfully in early testing phases for DMR decoding, had been taken down by GitHub for utilizing the incorrect license. While upsetting, I’ve bookmarked the project and am excited to include these capabilities when this has been resolved.
Having built many tools to automate processes and workflows for personal use in the past, I probably approached this project with more than a reasonable amount of confidence. A fair summary or my scripting (Bash & Python) philosophy to this point was probably along the lines of “its not pretty, but neither is duct-tape.” Unlike my past scripting experience, this is the first project that I’ve built with the intention of publishing in the public domain.
Because of this, there was a certain level of pressure to build things in a way which would survive that majority of public scrutiny and being readable enough for anyone to pick it up, modify and run with their own adaptation.
While the next several phases of development are already in process, I hope that the reader will explore the capabilities included, and feel free to contact me if they have any questions.