> root@re-bench:~# binwalk -e controller_fw_v04.12.03.bin && strings squashfs-root/usr/bin/link_mgr | grep -i 'pass\|key\|token'<span class="cursor-blink">_</span>_
Over the past three months, we have examined drones from every angle — hijacking control links, harvesting accumulated intelligence, and spoofing the satellite signals they navigate by. Each of those articles targeted the aircraft or the signal environment around it.
This month, we turn to the device in the pilot's hands.
The handheld controller is the component that everybody touches and nobody questions. It is powered on, paired with the aircraft, and used to fly. It connects to the pilot's mobile device. It connects to the manufacturer's servers to download firmware updates. It stores authentication tokens, pairing keys, and configuration data. It runs an embedded operating system with services, libraries, and binaries — a complete computing platform held in two hands.
On this engagement, we did not fly anything. We did not transmit any radio signals. We did not connect to any network. We took the controller to a bench, extracted its firmware, and read what was inside. What we found raises questions not just about this controller, but about the firmware supply chain that underpins the entire commercial drone ecosystem.
The client was a critical infrastructure operator — an energy company that used commercial drones for inspection of transmission towers, substations, and solar installations. Their fleet of six drones and four controllers was managed by an in-house aviation team. Following our previous drone security work — which had gained attention within the industry — the client engaged us to conduct a firmware security assessment of their drone controller hardware.
The scope was deliberately narrow: the controller unit only. No aircraft, no radio links, no flight operations. The assessment was a pure reverse engineering exercise — firmware extraction, static analysis, and identification of security-relevant findings within the firmware image. The client provided two controllers: one current production unit and one retired unit for destructive analysis if required.
The controller was a current-generation model from a major commercial drone manufacturer. It ran an embedded Linux operating system on an ARM processor, with integrated display, physical controls, radio transceiver, and Wi-Fi and Bluetooth interfaces. It retailed for approximately twelve hundred pounds.
Firmware extraction is the process of obtaining a copy of the software that runs on an embedded device. There are several methods, ranging from non-invasive (intercepting an update download) to semi-invasive (accessing a debug interface) to fully invasive (desoldering and reading the flash memory chip directly). We attempted all three, in order of increasing invasiveness.
The controller checks for firmware updates when connected to Wi-Fi. We connected it to a controlled Wi-Fi access point and monitored the traffic.
The firmware update channel used HTTPS for transport — a positive finding that prevents casual interception. However, three critical weaknesses were present. First, the integrity check used MD5 — a hash algorithm that has been cryptographically broken since 2004 and for which collision attacks are practical. MD5 does not provide meaningful integrity assurance. Second, the firmware image carried no digital signature — the controller verified the MD5 hash against the value provided by the update server, but it did not verify that the firmware had been signed by the manufacturer. Third, the HTTPS connection did not implement certificate pinning — the controller accepted any valid TLS certificate for the update domain, making the connection vulnerable to man-in-the-middle attacks using a rogue certificate authority.
The practical consequence: an attacker who could intercept the controller's network traffic — via a rogue Wi-Fi access point, DNS hijacking, or ARP spoofing — could serve a modified firmware image with a matching MD5 hash. The controller would accept it.
The controller verifies firmware integrity using MD5 only (cryptographically broken, collisions practical). No digital signature is applied to the firmware image. No certificate pinning is implemented on the update endpoint. A man-in-the-middle attacker could serve a modified firmware image that the controller would accept as genuine.
Using the retired controller, we examined the printed circuit board for debug interfaces. Embedded devices frequently expose UART (serial), JTAG, or SWD debug interfaces on the PCB — test points left from manufacturing that are sometimes accessible without desoldering components.
An unpopulated UART header on the PCB — four solder pads labelled J3 — provided a serial console. Soldering a four-pin header took thirty seconds. The console displayed the full Linux boot log, revealing kernel version, service names, and a login prompt. The root password — vendor123 — was a manufacturer debug credential. With root access to the running controller, we could examine the live filesystem, running processes, network connections, and memory contents.
We also used the UART root shell to dump the complete firmware from the flash storage — providing a live filesystem image that complemented the update file obtained via network interception.
With both the update file and the live filesystem dump in hand, we began static analysis of the firmware contents.
The firmware image contained a standard embedded Linux structure: a compressed kernel, a read-only SquashFS root filesystem containing the operating system and application binaries, and a writable JFFS2 partition for configuration data. The application binaries — seven key services managing radio links, cloud communication, telemetry, pairing, updates, media transfer, and diagnostics — were compiled ARM ELF binaries.
We subjected each binary to static analysis using standard reverse engineering tools.
The first pass was a string extraction across all binaries and configuration files — searching for patterns indicative of credentials, keys, tokens, and secrets.
Six hard-coded credentials discovered across three binaries and the system password file. An MQTT password for the manufacturer's cloud telemetry broker. A provisioning secret used during initial device registration with the cloud platform. A default pairing key used as a fallback during controller-aircraft pairing. A diagnostics password. A debug enable key that activated a hidden telnet service. And the root password confirmed via hash cracking.
The critical property of hard-coded credentials in firmware is that they are identical on every device of the same model. The firmware image is the same for every controller. The credentials compiled into the binaries are the same for every controller. Extracting them from one device compromises every device running that firmware version worldwide.
| Credential | Location | Purpose | Impact |
|---|---|---|---|
| MQTT password | cloud_agent binary | Authenticate to manufacturer's MQTT broker for telemetry upload | Connect to cloud broker as any controller; read/publish telemetry for all devices on the platform |
| Provisioning secret | cloud_agent binary | Authenticate during initial device registration with cloud | Register rogue devices on manufacturer's platform; impersonate legitimate controllers |
| Default pairing key | link_manager binary | Fallback key for controller-aircraft pairing when primary pairing fails | Pair an unauthorised controller with any aircraft using fallback pairing mode |
| Diagnostics password | link_manager binary | Access hidden diagnostics mode via controller UI | Access low-level radio configuration, spectrum analyser, and protocol debugging |
| Debug enable key | diag_service binary | Activate hidden telnet service on the controller | Remote shell access to any controller on the same network when telnet is enabled |
| Root password | /etc/shadow | Linux root account on the controller | Full system access via UART debug interface on any controller of this model |
The cloud_agent binary managed the controller's communication with the manufacturer's cloud platform. Using the hard-coded MQTT credentials, we examined what access the cloud connection provided.
The MQTT credentials extracted from the firmware were shared across all controllers and provided read access to telemetry from every device on the manufacturer's platform. The MQTT broker did not enforce per-device topic access control lists (ACLs). A wildcard subscription returned real-time telemetry — GPS position, flight status, battery level, connected aircraft serial number, and pilot account identifier — for every active controller and aircraft globally.
This finding extended far beyond our client's six controllers. It was a platform-level vulnerability affecting every customer of this drone manufacturer. We immediately classified this as a responsible disclosure finding and notified the manufacturer through their published security contact, providing full technical details and a ninety-day remediation window before any public discussion.
Hard-coded MQTT credentials in the controller firmware provided read access to real-time telemetry for all devices on the manufacturer's cloud platform — not limited to the client's devices. GPS positions, flight status, and pilot identifiers for all customers globally were accessible with a single credential set extracted from any controller of this model. The manufacturer was notified via responsible disclosure.
The firmware update mechanism warranted deeper analysis. We had identified that the update used MD5 for integrity and lacked cryptographic signature verification. We tested whether a modified firmware image would be accepted by the controller.
We built a modified firmware image containing a benign marker file, served it via a rogue update server (using DNS redirection on our controlled network), and the controller accepted and installed it. The MD5 hash of the new image was provided by our rogue server, and the controller verified the hash — which matched, because we computed the correct MD5 for our modified image. There was no cryptographic signature to prevent this.
In a real attack, the modified firmware could contain anything: a persistent backdoor, modified radio parameters, altered telemetry reporting, a keylogger capturing pilot account credentials, or modified pairing logic that allows an attacker's controller to bind to any aircraft. The controller would install it, reboot, and continue operating — with the attacker's code running alongside the legitimate firmware.
The supply chain implications are severe. An attacker who could intercept the firmware update — via a rogue Wi-Fi access point at a drone show, a compromised hotel network, or a man-in-the-middle position on the pilot's home broadband — could persistently compromise the controller. The compromise would survive factory resets (which do not reflash the firmware) and would only be removed by a legitimate firmware reinstallation from a verified source.
| Step | Action | Weakness Exploited |
|---|---|---|
| 01 | Intercepted firmware update over controlled Wi-Fi | No certificate pinning; firmware URL and MD5 disclosed in cleartext JSON |
| 02 | Obtained root shell via UART debug interface | Unpopulated UART header on PCB; root password 'vendor123' |
| 03 | Extracted 6 hard-coded credentials from firmware binaries | Credentials compiled into binaries; identical across all devices |
| 04 | Accessed manufacturer's MQTT broker — global telemetry exposure | Shared MQTT credentials; no per-device topic ACLs |
| 05 | Built and installed modified firmware via rogue update server | MD5-only integrity check; no cryptographic firmware signature |
The remediation for this engagement has a unique structure: the most critical fixes must be implemented by the manufacturer, not the client. The client cannot add cryptographic signature verification to the controller. The client cannot replace the shared MQTT credentials with per-device certificates. The client cannot remove the hard-coded credentials from the firmware binaries. These are design decisions embedded in the product.
What the client can do is manage the risk. Updating controllers only on trusted networks reduces the firmware supply chain risk. Physical access controls reduce the UART extraction risk. Monitoring vendor advisories ensures that firmware patches addressing disclosed vulnerabilities are applied promptly. And including firmware security as a procurement criterion for future drone equipment ensures that the next generation of controllers meets a higher security standard.
Cryptographic firmware signing is the single most impactful change the manufacturer can make. A signed firmware image — where the controller verifies an ECDSA or RSA signature against a trusted public key embedded in the bootloader before installing any update — makes firmware modification attacks computationally infeasible. The attacker cannot generate a valid signature without the manufacturer's private key. This is standard practice in modern embedded systems and automotive ECUs. It should be standard practice in commercial drone controllers.
Four months ago, we began examining drone security. We attacked the aircraft's control links. We harvested intelligence from its storage. We spoofed the satellites it navigated by. And now, we have read the secrets compiled into the controller's firmware — secrets shared with every other controller of the same model on the planet.
The controller was the component that the client — and, we suspect, the manufacturer's security team — thought about least. It is the device the pilot holds. It is the device that sits on a desk between flights. It is the device that connects to Wi-Fi for updates and never prompts for a password. It is the device that nobody reverse engineers, because it is 'just a remote control'.
It is not a remote control. It is a networked Linux computer that authenticates to a cloud platform, processes telemetry, manages radio links, and installs firmware updates from the internet. It deserves the same security scrutiny as any other computing device in the organisation.
This concludes our drone security series. Across four articles, we have demonstrated that commercial UAV systems present an attack surface that spans radio frequency interception, data accumulation, satellite signal manipulation, and firmware supply chain compromise. The common thread is that organisations deploy drones as tools — cameras, survey instruments, patrol platforms — without recognising that they are also networked computing devices with all the vulnerabilities that entails.
Until next time — stay sharp, stay curious, and the next time someone hands you a controller, remember: the firmware remembers everything the manufacturer compiled into it. Including the passwords.
This article describes a firmware security assessment conducted under formal engagement with full written authorisation from the client. Firmware extraction was performed on hardware owned by the client and provided for assessment. No radio transmissions were made. No manufacturer systems were accessed beyond confirming the platform-level vulnerability using credentials extracted from the client's own hardware. The platform-wide MQTT telemetry exposure was reported to the manufacturer via responsible disclosure with a ninety-day remediation window. All identifying details — including the manufacturer, model, and specific credentials — have been altered or omitted. Reverse engineering of firmware may be subject to the terms of the manufacturer's end-user licence agreement. Unauthorised access to computer systems is an offence under the Computer Misuse Act 1990. Do not attempt to replicate these techniques without proper authorisation and legal review.
Hedgehog Security conducts firmware security assessments for IoT devices, embedded systems, and commercial drone platforms. We extract, analyse, and reverse engineer firmware to identify hard-coded credentials, insecure update mechanisms, debug interfaces, and supply chain vulnerabilities. The findings go beyond one device — they reveal what is present on every device of the same model worldwide.