Secrets in the firmware: three flaws, one root cause

Three new DVID trainings to explore secret leaks in embedded systems

An API key hardcoded in the binary. An administrator password displayed in clear text in the debug console. A firmware accepted without any signature check. Taken individually, each of these defects seems obvious to fix. But in the field, these very basic mistakes are precisely what comes up in most IoT/OT device audits.

Three new DVID trainings join our April 2026 catalog around a common theme: how secrets leak from an embedded system, and how an attacker exploits them. Three scenarios, three approaches, but one conclusion — a device's security is often decided at design time, not at deployment.

Hardcoded password: when the binary becomes a keyring

The first training tackles a classic: an administrator credential stored directly in the firmware source code. The developer may have put it there during prototyping, intending to remove it before production. It is still there.

Participants learn how to:

• extract a firmware from a microcontroller through a debug interface or a memory read;
• analyze the binary to identify suspicious strings;
• isolate credentials, API keys or tokens stored in clear text;
• reuse these secrets to authenticate on the device or on the services it consumes.

This module illustrates a reality that firmware teams often underestimate: a compiled binary is not a black box. With a few free tools and a bit of method, any attacker with physical access to the device can extract its secrets in minutes.

This flaw is explicitly targeted by Annex I of the Cyber Resilience Act (CRA) — requirements 2b (default credential management) and 2h (confidentiality of stored data). The training directly covers both points.

Sensitive data in logs: the invisible leak

The second training addresses a more discreet but equally widespread flaw: excessive logging. During development, engineers add printf calls everywhere to follow the firmware's behavior. Passwords, tokens, session keys, network frame contents — everything goes in. And everything stays, because these logs are never cleaned up before production.

This module's scenario simulates an industrial device whose debug output is accessible over UART. Without exploiting any logic vulnerability, participants observe:

• how a simple serial connection is enough to intercept sensitive information in real time;
• how data meant to stay internal (credentials, configuration, application payloads) flows through the logs;
• how these leaks let an attacker map the infrastructure behind the device, without even compromising it;
• how to audit a logging policy to spot what should not be there.

This falls under CRA requirement 2h (confidentiality of processed data) as well as requirement 2k (attack surface minimization). A chatty debug interface is an attack surface that has no reason to exist in production.

Firmware signature verification: when any binary becomes legitimate

The third training deals with a critical mechanism: secure boot and signature verification. Many devices implement an OTA update process. Far fewer correctly verify the signature of the firmware they receive.

The failure cases are numerous and the training reviews them concretely:

• a check present in the code… but never actually called;
• a signature checked only on the header, never on the full payload;
• a verification public key stored in a rewritable area;
• a fallback that accepts unsigned firmware when verification fails.

The scenario puts the participant in the role of an attacker holding a modified firmware. The goal: get the device to accept this firmware and achieve arbitrary code execution on the next boot. Once this step is passed, the attacker does not just control a session — they control the device persistently, even after a reset or an update.

This flaw is at the heart of CRA requirement 2j (integrity of updates) and requirement 2c (protection against unauthorized modification). It is also one of the favorite targets of software supply chain attacks.

A 100% hands-on approach, true to DVID's DNA

As with our entire catalog, these three trainings rely on real hardware, real firmware and scenarios representative of what teams encounter in audits or incident response. Learn by doing, not by theorizing — that is the principle behind every module.

Participants work with:

• an ESP32 or an STM32 depending on the scenario;
• a UART interface at 9600 baud to interact with the device;
• standard binary analysis tools (strings, objdump, Ghidra depending on the module);
• Python scripts to automate interaction with the firmware;
• a reproducible environment, in line with the philosophy of the open source DVID board.

Each step is progressive. No advanced prerequisites are required: tools are introduced along the way, and the necessary cryptographic concepts (hash, signature, chain of trust) are explained in the context of the exercise.

Key takeaways for participants

Beyond each scenario, these three modules build essential reflexes for designing and auditing embedded systems:

• never hardcode a secret in a production firmware;
• use the secure storage areas provided by the silicon (secure element, eFuse, OTP);
• systematically review log levels before each release, and disable debug output in production;
• set up a signature verification chain without a permissive fallback;
• build these checks into CI/CD rather than relying on individual vigilance.

These best practices are at the heart of CRA compliance and of any serious security by design approach.

Who is it for?

These three modules are designed for teams that design, audit or maintain embedded systems:

• firmware engineers and embedded developers;
• IoT/OT architects;
• hardware-focused pentesters;
• product security managers;
• teams in charge of CRA compliance.

No advanced prerequisites are needed: everything is explained, demonstrated and put into practice. Familiarity with C, Python and serial interfaces makes it easier to get started, but is not a blocker.

Available now

These three trainings fit naturally into an IoT/OT upskilling path, whether to strengthen an internal team, prepare for CRA compliance or structure a security-by-design approach.

Learn more: https://dvid.eu
Contact us: https://dvid.eu/#contact
Follow our news: https://www.linkedin.com/company/dvid/