Device and Firmware Security Testing

What this is about

Connected devices ship with layers of attack surface

Connected devices combine firmware, companion applications, network protocols, and cloud backends into a single product. A vulnerability in any layer can compromise the entire ecosystem. Firmware that ships with hardcoded secrets, companion tools that expose cryptographic material, or update mechanisms that don't validate integrity can all give attackers a path from the network to the device - or from the device to the broader environment it operates in. Casaba evaluates device security across all of these layers, from static analysis of firmware images through runtime testing of network services and the applications used to configure and manage them.

What we test

Eight focus areas

Firmware Image Analysis

Static analysis of firmware packages to understand the architecture - unpacking container formats, identifying encryption schemes, evaluating cryptographic signatures, and examining metadata for information disclosure. We map the firmware's structure to understand how components are protected and where gaps exist.

Companion Application Security

The desktop and web applications used to configure, update, and manage devices are often as critical as the firmware itself. We decompile and reverse-engineer companion tools to identify hardcoded secrets, insecure key derivation, exposed credentials, and weak inter-process communication patterns.

Cryptographic Implementation Review

Evaluating encryption at rest and in transit - key generation algorithms, certificate validation, key storage mechanisms, and whether the device uses hardware-backed security features like Trusted Execution Environments (TEE) or Hardware Security Modules (HSM). We assess whether cryptographic implementations follow established standards or introduce weaknesses through custom schemes.

Firmware Update Mechanism

Testing the integrity and authenticity of the firmware update process - whether updates are signed and validated, whether downgrade attacks are possible, and whether the delivery channel is protected against interception or tampering.

Network Service Assessment

Identifying open ports, unauthenticated endpoints, and services accessible without encryption. We map the network footprint of the device and test each exposed service for information disclosure, authentication bypass, and protocol-level vulnerabilities.

Configuration and Hardening Review

Evaluating device configuration against security best practices - certificate validation settings, logging verbosity, authentication requirements, default credentials, and security level configurations that may be set below their most secure option.

Binary Security Protections

Analyzing compiled binaries on the device and in companion tools for standard security protections - ASLR, DEP/NX, PIE, stack canaries, and RELRO. Devices shipping binaries without these protections have a larger attack surface for memory corruption exploits.

Compliance and Certification Assessment

Evaluating whether devices meet relevant security certifications such as ISA/IEC 62443 for industrial control systems, and whether the manufacturer's development processes have obtained recognized security certifications.

How we approach it

Black-box testing with reverse engineering depth

Casaba typically performs device assessments as black-box engagements where no source code is available. We start with the firmware package itself - unpacking layered container formats, identifying encrypted regions, and extracting metadata and configuration artifacts. Where companion tools are .NET or Java applications, we decompile them for thorough code review.

For embedded Linux systems, we analyze the root filesystem for SOUP (Software of Unknown Provenance), checking third-party components against known vulnerability databases and cross-referencing with publicly available exploit code. We validate SOUP findings through selective spot-checking rather than trusting scanner output at face value.

Network testing combines port scanning with protocol analysis using tools like Wireshark to observe device communications and identify cleartext traffic, unauthenticated services, and certificate validation failures. When hardware access is available, we examine debug interfaces like JTAG and UART for direct memory access and process manipulation.

Testing is always evaluated in the context of the device's deployment environment. A vulnerability on an air-gapped industrial controller carries different risk than the same issue on an internet-connected consumer device.

What we find

Typical finding patterns

Hardcoded Secrets in Companion Tools

Device management applications containing embedded cryptographic keys, default passwords, master credentials, and static encryption salts in their compiled code. Even when these secrets are for legacy functions, their presence provides a foothold for attackers targeting any device not fully updated.

Insecure Key Derivation

Custom encryption key generation that derives keys from predictable inputs like public version numbers or build strings rather than using hardware-backed key storage or secure random generation. This allows anyone who reverse-engineers the algorithm to decrypt firmware or protected data.

Cleartext Communication Channels

Device endpoints serving configuration files, application binaries, or management interfaces over unencrypted HTTP alongside encrypted HTTPS endpoints on the same device. Attackers on the local network can intercept and tamper with this traffic.

Unauthenticated Service Endpoints

Web servers, API endpoints, or management interfaces on the device that respond to requests without requiring authentication, exposing system configuration, version information, or application binaries to any user on the network.

Missing Certificate Validation

Devices configured to encrypt communications but not validate the certificates of their communication partners. This enables man-in-the-middle attacks despite the presence of TLS encryption.

Binaries Lacking Security Protections

Firmware binaries compiled without ASLR, stack canaries, DEP/NX, or other standard memory protection mechanisms, increasing the exploitability of any buffer overflow or memory corruption vulnerability.

Insufficient Logging Configuration

Device logging set to minimal verbosity by default, reducing the ability to detect and investigate security incidents after they occur.

Weak Update Integrity Controls

Firmware update mechanisms that verify authenticity through signatures but use key derivation or encryption schemes that can be reverse-engineered from companion tools, undermining the confidentiality of firmware contents.

How we work

Our process

1. Scoping

We map your device ecosystem - firmware versions, companion tools, network protocols, deployment environment, and any relevant certifications - to define the attack surface and prioritize testing objectives.

2. Kickoff

We acquire device samples or remote access, set up test environments, and work with your engineering team to understand the architecture, communication flows, update mechanisms, and security controls.

3. Execution

Layer-by-layer testing from firmware through network services and companion tools. Firmware unpacking and analysis, binary decompilation, network traffic capture, service enumeration, and configuration review. Critical findings are reported immediately.

4. Reporting

Detailed findings with reproduction steps, severity ratings contextualized to the deployment environment, and recommended mitigations. We present findings to both security and engineering stakeholders and support remediation planning.