05 / FIRMWARE & CODE

Firmware & Source Code Review

Firmware / product code in scope

Targeted review of security-critical firmware and product code, including boot and update logic, parsers, authentication, cryptographic integration, privilege boundaries and exposed services.

We focus review effort on the code paths that enforce product trust or process attacker-controlled input.

FirmwareBoot & UpdateParsersAuthenticationCryptographyMemory Safety
FIRMWARE / CODEBASE 05 REVIEW PATH
review path note execution path: NETWORK INPUT → PARSER → AUTH → COMMAND → PRIVILEGED OP
INPUT / NETWORK
source radio + ethernet
exposure remote
trust assumption none
validation downstream
REVIEW FOCUS

Security-critical code is not evenly distributed.

A small part of a product codebase often controls the most important trust decisions: parsing attacker-controlled input, accepting firmware, establishing identity, handling secrets or exposing privileged functionality. We concentrate review effort on those paths.

review focus selected
INPUT
Where attacker-controlled data enters the code, network, files, update packages, local interfaces.
ASSESSMENT SURFACE

What we review

Boot, update & recovery

Secure-boot logic, firmware verification, update authorization, version enforcement, rollback protection, recovery paths and trust-anchor use.

Parsers & untrusted input

Network messages, file formats, protocol handlers, update packages, management interfaces and other attacker-controlled data paths.

Authentication & authorization

Identity checks, sessions, roles, privilege decisions, management functions and access-control logic.

Cryptography & secrets

Cryptographic API use, randomness, key handling, secret storage, signature verification and implementation of cryptographic trust decisions.

Privilege & memory safety

Memory corruption, unsafe operations, privilege transitions, process boundaries, IPC and code running in privileged contexts.

Product services & security logic

Security-relevant application logic, internal services, management components and code that connects device, application and backend trust.

The review is scoped around security-relevant components and attack paths rather than code volume alone.

REVIEW APPROACH

Architecture first. Code paths second.

We start from the product architecture, attacker-controlled entry points and trust decisions, then trace those paths through the implementation. Static analysis, targeted fuzzing and other tooling can support the review where they improve coverage or verification.

workflow selected
ARCHITECTURE
Understanding product architecture, components, trust boundaries and exposure.
IMPLEMENTATION PATHS

Small implementation flaws can break product-level trust.

01

Network input → Parser → Code execution

A remotely reachable parser trusts a length field before validating the complete message. A protocol-level input becomes memory corruption in a privileged firmware component.

02

Update → Verification → Rollback

Firmware signatures are checked correctly, but version enforcement occurs after a recovery path has already accepted the image. Signed legacy firmware can be restored.

03

Authentication → Role check → Privileged function

Authentication succeeds correctly, but authorization is enforced inconsistently across management handlers. A low-privilege identity reaches an administrative operation.

SCOPING

Scope follows the security-critical code paths.

Components

Firmware modules, bootloaders, update components, protocol handlers, product services or selected application/backend components.

Entry points

Wireless/network input, files, update packages, local interfaces, APIs, IPC, user input or another attacker-controlled source.

Review depth

The engagement may cover a focused subsystem, a security-critical feature or a wider product codebase depending on the question to be answered.

A complete repository review is not always necessary. Selected source trees, firmware images and architecture context can be enough to define a focused review.

Where source is incomplete, binaries and runtime behavior can provide additional implementation evidence.

DELIVERABLES

What you get

Code-level findings

Affected components, functions and relevant execution paths.

Reproducible evidence

Inputs, requests, traces, test cases or proof-of-concept behavior required to verify the issue.

Security impact

How the implementation weakness changes the attack surface or breaks a product trust assumption.

Remediation & retest

Technical remediation guidance tied to the affected path, followed by verification where retesting is in scope.

FINDING 06
Recovery path permits signed firmware downgrade
ENTRY
recovery update package
CODE PATH
parse_image() → verify_signature() → install_image() → enforce_version()
TRUST
signature valid
IMPACT
vulnerable legacy firmware restored
STATUS
reproducible
Typical triggers

When this review fits

New firmware or product release
New boot, update or recovery mechanism
Security-critical protocol parser
New authentication or privilege model
Cryptographic implementation or key-handling change
Major firmware or embedded-software refactor
Legacy security-critical code that has never received focused review
Customer assurance requirement
Need to review a subsystem before penetration testing
Need to understand the root cause of a finding discovered during testing
PRODUCT SECURITY REQUIREMENTS

Need the review to support a regulatory requirement?

Security-relevant implementation evidence can support technical product-security requirements around access control, secure update, cryptography and resistance to exploitable vulnerabilities.

CRAEN 18031IEC 62443
Technical testing and evidence. Certification is outside the scope.
Dr. Ewan Fleischmann
Technical direction

Dr. Ewan Fleischmann

Founder · Product Security & Cryptography

22+ years IT security · PhD cryptography · OSCP · OSCE · CISSP

Building a product that needs serious security testing?

Tell us what you're building, the current development stage and what you want tested. The scope follows from the product.

NDA first if required.