How to Really Audit an Embedded Device for GPL Compliance

When you buy a router, a smart thermostat, or an Android TV box, you’re not just getting a piece of hardware. You’re getting a software stack—often a messy, cobbled-together pile of code—and a big chunk of it is open source. The GPL governs a lot of that code, from the Linux kernel to essential userspace libraries. If you’re a developer or just a technically minded user, checking whether a device actually respects those licenses isn’t just a legal box-ticking exercise. It’s about protecting software freedom and basic engineering honesty. This guide lays out a practical, hands-on method for auditing a device, based on real reverse-engineering work.

What the GPL Actually Demands

Before you crack open a case or fire up a terminal, you need to know what you’re looking for. The GPL’s central requirement is straightforward: if you distribute binaries built from GPL code, you must make the corresponding source code available. For embedded devices, “corresponding source” means the complete, buildable code for the kernel, any modified GPL libraries, and all the scripts and toolchain bits needed to recompile it and get it running on the hardware. A bare firmware binary dump is a warning sign. A source tarball that compiles but produces a kernel that panics on the target device is also a failure. Compliance means the recipient can genuinely modify the code and run the modified version on the same hardware.

Plenty of manufacturers slap a “source code” link on a support page. Your first move is to download that archive and poke around. Is it just a vanilla kernel tree with no board-specific patches? Are the drivers for the Wi-Fi chip or power management IC missing, with only pre-compiled kernel modules (.ko files) shipped instead? A proper release contains the exact source used to build the firmware image on your device, not a generic upstream snapshot.

Getting the Firmware Off the Device

To compare what the vendor promised with what’s actually running, you need to extract the firmware. The easiest route is often through a firmware update file published on the manufacturer’s website. These are typically compressed archives that contain a filesystem image—SquashFS, JFFS2, or UBIFS are common. Use binwalk to scan the binary blob for magic bytes and pull out the filesystem.

binwalk -e firmware_update.bin

If the vendor doesn’t offer downloadable firmware, you’ll have to go after the flash memory on the device itself. That means physical access. Find the serial console pins—usually labeled TX, RX, and GND—and hook up a USB-to-UART adapter. Open a terminal emulator like minicom or screen, interrupt the bootloader (U-Boot is the usual suspect), and drop into its command shell. From there, you can dump each flash partition to a TFTP server or an SD card. Focus on the kernel partition and the root filesystem partition.

Kernel Analysis: Version Strings, Modules, and Hidden Symbols

Once you’ve got the kernel image—usually a compressed zImage or uImage—extract it and start digging. Run strings on the binary to pull out the kernel version string. That tells you the exact upstream release the vendor started from. A compliant source release has to match this version, right down to the sub-level patch number. Next, check for loadable kernel modules. On the extracted root filesystem, look in /lib/modules/. Run modinfo on each .ko file to see its vermagic and any license tags. If a module’s license field says “proprietary” but it links against GPL-only kernel symbols, that’s a violation. The kernel’s symbol export mechanism explicitly marks certain functions as off-limits to non-GPL modules. A common trick is to use a shim module or patch the kernel to weaken those export checks. It’s still non-compliant.

To go deeper, disassemble the kernel and its modules. Look for functions that have been stripped of their GPL-only export status. In the kernel source, functions like dma_buf_export are guarded by EXPORT_SYMBOL_GPL. If the running kernel’s symbol table shows them as plain EXPORT_SYMBOL, the vendor has modified the kernel to let proprietary modules link against them. That modification itself is a GPL violation—it changes the licensing terms of the kernel code.

Userspace Libraries and the GPL’s Long Arm

The kernel gets most of the attention, but userspace isn’t off the hook. The GPL’s copyleft effect reaches any program that’s a derivative work of GPL code. For libraries, the LGPL is more common, but full GPL libraries like readline or certain multimedia frameworks do show up. Use readelf or objdump to examine dynamically linked binaries on the root filesystem. Identify every shared library they link against. Then, for each library, figure out its license. If a binary links to a GPL library, the whole program must be distributed under a GPL-compatible license, and its source code has to be offered.

Here’s a practical check: look for BusyBox. This single binary packs in a bunch of standard Unix utilities and is GPL-licensed. If the device uses BusyBox, the vendor must provide the exact BusyBox source, including any custom applets they added and the configuration file used to build it. A common dodge is shipping a BusyBox binary with a tweaked configuration that enables or disables features, but only linking to the upstream BusyBox website. That doesn’t cut it. The vendor has to provide the precise source that matches the binary on the device.

Verifying Buildability: The Real Test

Having the source code is only half the story. The GPL requires that the source be the “preferred form of the work for making modifications.” For embedded software, that means the source has to be practically buildable. Set up a cross-compilation environment that matches the device’s architecture—ARM, MIPS, whatever—and try to build the kernel and root filesystem from the provided source. Does it compile without errors? Does the resulting kernel binary match the one you pulled off the device? A byte-for-byte match is the gold standard, but at a minimum, the functionality has to be identical. If the provided source is missing the correct .config file, device tree blobs, or essential build scripts, it fails the buildability test.

Pay attention to the toolchain. The GPL covers “scripts used to control compilation and installation of the executable.” If the vendor used a specific, patched version of GCC to build the firmware, that toolchain source and the patches have to be provided. A common oversight is offering the source but leaving out the proprietary linker script or the exact compiler flags that make the build work. Without those, the source isn’t the preferred form for modification—it’s an incomplete puzzle.

Documenting What You Find and Taking Action

As you work, keep a detailed audit log. For each potential violation, note the file name, the specific GPL component involved, the evidence (like a kernel module with a proprietary license tag linking to GPL-only symbols), and the steps to reproduce the finding. This documentation does two things. First, it gives you a clear, technical basis for a compliance request to the vendor. Second, if the vendor ignores you, it becomes the foundation for a report to the copyright holders or a community enforcement group.

When you contact the vendor, be precise and professional. State the device model and firmware version. List the GPL components you’ve identified. Explain exactly what’s missing or non-compliant, and reference the specific GPL version text. Offer to verify any corrected source release they provide. A lot of violations come from ignorance or sloppy internal processes, not deliberate malice. A well-documented audit can help a company fix its compliance pipeline and avoid future headaches.

FAQ: Common Questions on GPL Auditing

What if the vendor provides source code, but it’s for a different kernel version?

That’s a violation. The GPL requires the source code to correspond exactly to the binary version distributed on the device. A mismatched kernel version means the source can’t be used to reproduce or modify the running software. You should request the exact source, including all patches and the specific configuration used for the build.

How can I tell if a kernel module is proprietary?

Use the modinfo command on the extracted module file. Look for the “license” field. If it says “Proprietary” or is empty, the module isn’t GPL-compatible. Then, check the kernel’s symbol table (often /proc/kallsyms on a running system) to see if that module uses any symbols marked with a “G” (GPL-only). If it does, the module is in violation. You can also disassemble the module to look for deliberate circumvention of GPL symbol checks.

Does the GPL require vendors to provide the signing keys for secure boot?

This is a tricky area. The GPLv3 explicitly addresses “Installation Information,” which includes keys and procedures needed to install modified software on the device. But many embedded devices use GPLv2 code (like the Linux kernel), which lacks this explicit requirement. For GPLv2, the consensus in the compliance community is that if the vendor uses code signing to prevent modified versions from running, they must provide the signing keys or a way to disable the signature check. Otherwise, the “preferred form for modification” isn’t truly being provided, because modifications can’t be practically executed. This remains a contested point, but it’s a strong argument in enforcement discussions.

What if the device uses a GPL library but the main application is proprietary?

If the library is licensed under the full GPL (not LGPL), the application linking to it becomes a derivative work and must also be licensed under the GPL. The vendor has to release the application’s source code. If the library is LGPL, the application can stay proprietary, but the vendor must still provide the source for the LGPL library itself, including any modifications, and must allow relinking against modified versions of the library. Check the actual license file included with the library to be sure which version applies.

What tools are essential for a firmware audit?

A minimal toolkit includes binwalk for extracting firmware images, a cross-compilation toolchain for the target architecture, objdump and readelf for binary analysis, and a serial console adapter for physical access. For deeper analysis, a disassembler like Ghidra or IDA Pro is invaluable. A hex editor and familiarity with filesystem structures (SquashFS, JFFS2, UBIFS) are also important. The most critical tool, though, is a thorough understanding of the GPL text and its practical implications.