Why GPL Audits Matter for Embedded Devices
Every Linux-based router, smart camera, or IoT widget that ships with GPL-licensed code comes with strings attached. The GNU General Public License isn’t just a block of legalese you click through—it’s a technical contract. If a manufacturer distributes a device with, say, the Linux kernel or BusyBox inside, they’re on the hook to provide the complete corresponding source code. When they don’t, an audit is how you prove it. I’ve spent years tearing apart firmware images and going back and forth with vendors who’d rather pretend the GPL doesn’t exist. The pattern is almost always the same: they slap together some open-source components, toss in proprietary drivers, and ship the product without a word about source availability. A proper audit doesn’t just spot the violation—it builds an evidence package that’s airtight.
Pre-Audit Setup: Tools and Mindset
Before you even power on the device, get your workstation ready. You’ll need a Linux box with binwalk for firmware extraction, strings for hunting down copyright notices, and a cross-compilation toolchain that matches the device’s architecture (ARM, MIPS, etc.). If the firmware is locked down tight, you might also need a logic analyzer or JTAG/SWD debugger to get at the flash chip directly. But let’s be real—most consumer devices aren’t that hardened, and you can often just download the firmware update from the vendor’s site.
Documentation is everything. Create a project folder with subdirectories for original firmware binaries, extracted filesystems, kernel configs, and all correspondence with the vendor. Timestamp every step. If this ever escalates to a legal complaint or a public disclosure, a sloppy chain of custody will sink your case faster than anything.
Step 1: Get the Firmware (Legally)
Start with the obvious: check the vendor’s support page for firmware downloads. Many bury them behind a “Downloads” tab or a product registration wall, but they’re usually there. If the device has an OTA update mechanism, fire up a proxy like mitmproxy and intercept the download URL. For devices with encrypted firmware, you’ll need to get more creative—desolder the flash chip, read it with a programmer, and then reverse-engineer the bootloader to find the decryption key. Encryption itself isn’t a GPL violation, but hiding GPL code behind it and refusing to hand over the source? That’s a different story.
Once you have the binary, hash it. sha256sum firmware.bin gives you a fingerprint that ties your analysis to that exact version. Vendors love to claim they’ve already released source for a “different” build—the hash makes that excuse useless.
Step 2: Find the GPL Components
Run binwalk -Me firmware.bin and let it unpack the filesystem. Then start digging. Look for the usual suspects: the Linux kernel (search for /proc/version strings or linux-* directory patterns), BusyBox, uClibc or glibc, GCC runtime libraries, and common tools like iptables or wpa_supplicant. If you spot /bin/busybox and it’s statically linked, that alone triggers GPLv2 obligations for the whole userspace.
Don’t just check binaries—inspect kernel modules too. Run modinfo on every .ko file and look at the vermagic string. A module compiled against a modified kernel but shipped without source is a smoking gun. Also, run strings across the binaries to find leftover GPL copyright notices. Vendors often strip these, but fragments survive in error messages or debug output. I’ve found notices buried in Wi-Fi driver blobs that the vendor swore were entirely proprietary.
Step 3: Check Source Code Availability
GPLv2 requires that source code be “made available” for at least three years after distribution. So, go look for it. If the vendor has a source download link, grab it and compare the offered code against the binaries on the device. Compile the kernel from their source and check if the resulting binary matches what’s on the hardware. Mismatched checksums, missing drivers, or absent build scripts all point to non-compliance. I’ve seen vendors release a tarball that compiles fine but is missing the one driver that makes the hardware work—that’s not compliance, that’s theater.
If there’s no source link, send a formal written request. GPLv2 Section 3(b) lets vendors provide a written offer instead of bundling source with the device. Quote the license text directly in your email or letter, and give them a reasonable deadline—30 days is standard. Keep every reply. A vendor’s silence or a canned “we’ll look into it” that goes nowhere is evidence in itself.
Step 4: Dig Into Derivative Works
The GPL’s reach goes beyond the kernel. If the vendor tweaked BusyBox, patched uClibc, or added custom kernel subsystems, those changes must be released. Look for signs of modification: extra BusyBox applets, patched kernel files, or proprietary modules that taint the kernel. The modinfo command will tell you if a module claims to be proprietary; a kernel tainted with the P flag while that module is loaded is a red flag.
Static linking is another trap. If a proprietary userspace app links against a GPL library like libgcc_s.so or a modified libc, the whole application might need to be GPL’d. Use readelf -d to check dynamic linking and objdump -T to find undefined symbols that reveal library dependencies. I once found a vendor’s “proprietary” cloud sync daemon that was statically linked against a GPL-licensed JSON parser—they weren’t happy when I pointed it out.
Step 5: Build the Violation Matrix
This is where you turn scattered findings into a compliance report. Create a table—call it a violation matrix—with columns for each GPL component: binary path, detected license, source availability status, and evidence of modification. Add screenshots of the firmware filesystem, terminal output from your analysis commands, and copies of all vendor correspondence. This matrix is the backbone of your case.
Be obsessive about license versions. GPLv2 and GPLv3 have different requirements—GPLv3 adds installation information obligations and anti-tivoization clauses. If the device uses a GPLv3 component like coreutils and the bootloader blocks unsigned kernel execution, that’s a separate violation from the GPLv2 kernel issue. Don’t lump them together.
Step 6: Talk to the Vendor (Without Losing Your Cool)
Send the compliance report to the vendor’s legal or engineering contact. Frame it as a collaborative request, not an accusation: “I’ve identified these GPL components in your product; please provide the corresponding source code as required by the license.” Attach the violation matrix and offer technical help if they need guidance setting up a source repo. Most engineers I’ve dealt with are reasonable—they just didn’t know the rules.
Some vendors will stonewall. When polite requests fail, escalate to the copyright holders. Organizations like the Software Freedom Conservancy and gpl-violations.org have enforcement experience and can apply legal pressure. I’ve seen cases where a single letter from a lawyer got source code released within a week.
Common Mistakes That Trip Up Auditors
Trusting the source tarball. Vendors sometimes release a tarball that compiles but omits critical drivers or build scripts. Always attempt a full build and compare the output to the device binaries. If the build fails or the resulting binary doesn’t match, the source is incomplete.
Ignoring license compatibility. A device might mix GPLv2-only code with Apache 2.0 code, which is incompatible. The resulting binary can’t be legally distributed. Check every license file in the firmware—don’t assume the vendor did their homework.
Forgetting upstream providers. The vendor may have licensed a software stack from a chipmaker like MediaTek or Qualcomm. Those upstream providers also have GPL obligations, and the vendor is responsible for passing through source requests. If the vendor blames their supplier, remind them that the GPL doesn’t let them off the hook.
FAQ
What if the vendor claims the GPL doesn’t apply because the software is in firmware?
The GPL makes no distinction between firmware and other software. If the code runs on a processor and the device is distributed to users, the GPL applies. The “mere aggregation” clause doesn’t shield embedded systems where GPL components and proprietary code share the same executable address space. I’ve heard this excuse dozens of times, and it never holds up.
How do I audit a device with encrypted firmware?
Encrypted firmware requires extracting the decryption key from the hardware. This often means reading the bootloader from flash, analyzing the boot ROM, or using fault injection techniques. Once you have the key, decrypt the firmware image and proceed with standard analysis. Note that encryption itself isn’t a GPL violation, but refusing to provide source code for GPL components inside an encrypted image is.
Can I audit a device without owning it?
You need physical access to the device or a copy of its firmware to perform a thorough audit. However, you can start by examining publicly available source code releases, GPL compliance histories of the vendor, and community reports of violations. Some vendors ship devices with GPL source offers printed in the manual—requesting that source is a valid first step even without the hardware.