Firmware Security Analysis

Multiple Vulnerabilities . ZKTeco Inc WL2 Biometric Attendance Systems 📅 January 2025 → August 2025 🔹This journey started with a chip-off analysis, where I desoldered the NAND flash and extracted the Firmware for a deep-dive. After rigorous Reverse Engineering, I even re-soldered the chip back and validated the findings directly on the hardware with testing probes ensuring every vulnerability was not only theoretical but practically verifiable. 🔹But what made this disclosure special was the step-by-step firmware evolution. Each version showed progress, yet critical gaps remained until the final advisory. 🔄 Firmware Evolution Across the Journey: 🔹FIRST Firmware 🧱 Contained cleartext Wi-Fi configuration, hardcoded superuser credentials, private key exposure, and embedded MQTT secrets. 🔓 High risk of unauthorized access and device compromise. 🔹Second Firmware 📦 Vendor patched plaintext credential storage and removed some MQTT broker details. ✅ Security improved, but private keys and Wi-Fi data were still exposed. 🔹Final Assessment 🔐 Despite repeated improvements, hardcoded private keys and cleartext Wi-Fi storage remained unresolved. 📢 Disclosure escalated to CERT-In , leading to official advisory: https://lnkd.in/dZU97ibv 🔍 Vulnerabilities Disclosed (ZKTECO Device) 🔹Cleartext Storage Vulnerability (CVE-2025-54464) 🔹Hard-coded Credentials Vulnerability (CVE-2025-54465) 🔹Hard-coded Private Key Vulnerability (CVE-2025-55279) 🔹Information Disclosure Vulnerability (CVE-2025-55280) 🤝Collaboration NOTE 🔹The vendor remained supportive and engaged throughout the disclosure journey providing firmware updates, assisting in validation, and coordinating on fixes. At times, the impact was understandably downplayed as being “less likely in real-world use” since these devices are often deployed indoors or within offices. 🔹Nevertheless, their cooperation, combined with CERT-In’s guidance, ensured that the vulnerabilities were formally addressed and responsibly disclosed. 📢 Official Disclosure: 🔗 CERT-In Advisory: CIVN-2025-0172 https://lnkd.in/dZU97ibv 🗓️ Published: August 2025 🔐 This journey is a reminder that securing IoT/biometric devices requires layered protection, removing hardcoded secrets, encrypting sensitive configs, and hardening firmware protection. #ZKTeco #IoTSecurity #FirmwareSecurity #ChipOff #CERTIn #ResponsibleDisclosure #VulnerabilityResearch #CyberSecurity #HardwareHacking #EmbeddedSecurity #CVEs #BugBounty #HackerNews #InfosecCommunity #ExploitDev #MalwareResearch #RedTeam #BlueTeam #ZeroDay

I’ve discovered a significant vulnerability in the Arm® TrustZone® CryptoCell 310 AES-128 hardware engine within the Nordic Semiconductor nRF52840 SoC, which has been acknowledged in the Nordic Security Advisory SA-2025-380-v1.0. By inducing precisely timed voltage fault injection, I was able to bypass the AES encryption and recover plaintext in ECB, CBC, and CTR modes. This vulnerability exposes sensitive data, making cryptographic methods like key rotation and CBC initialization vectors ineffective. Additionally, observed error byte diffusion under fault conditions could be potentially exploited for Differential Fault Analysis (DFA), particularly in ECB mode. This is a hardware vulnerability that cannot be patched easily without a redesign of the silicon. However, I proposed several firmware-level countermeasures to mitigate the attack's impact. These techniques, while effective, come with performance trade-offs and should be evaluated based on the specific use case. The attack was performed using my custom low-cost voltage fault injection tool based on the crowbar technique. As physical access is required for such attacks, minor hardware modifications like capacitor removal are not a significant barrier. Still, I achieved successful results without needing to remove any capacitors, demonstrating the practicality and repeatability of this approach. Discovery Reported to Nordic Semiconductor ASA on Nov 13, 2024. Public Disclosure Coordinated with Vendor on Apr 11, 2025. Full Research: https://lnkd.in/dZuMmp2C Nordic Security Advisory: SA-2025-380-v1.0 https://lnkd.in/dNCrabzK Sharing this to inform and support the embedded and hardware security community. #cybersecurity #infosecurity #hardwaresecurity #penetrationtesting #cyberdefense #cyberattack #redteam #redteaming #vulnerabilities #cryptography #hardwaredesign #hardwareengineering #softwareengineering #iotdevices #iotsecurity #hardware #development #communication #embeddedsystems #embeddedsoftware #iot

Security assessment of the Furbo pet camera: DES-encrypted password and 17 issues found. 👨🏻💻🔬📷🐺🐱 Security researcher Julian B shares in a series of posts his research on the interactive pet camera Furbo 360. The author conducted a full-spectrum security assessment analyzing hardware, firmware, mobile app logic, BLE, cloud integrations, and backend messaging systems. The strongest part of this research is its coverage: every aspect of the device architecture was reviewed, all the interfaces were examined, tested, and the findings were presented. If you plan to do security research and are looking for an example of how to write it up - this is the way :) Enjoy the read, happy learning, and please share with colleagues and others who want to learn hardware hacking! More details: Hacking Furbo - A Hardware Research Project Part 1: Acquiring the Hardware [Blog]: https://lnkd.in/dF6Se8BF Part 2: Mobile and P2P Exploits [Blog]: https://lnkd.in/dx8f9_Zq Part 3: Chip Off and Persistence [Blog]: https://lnkd.in/djVc_5Y8 Part 4: Debugging, DeviceIDs, and Dev Tools [Blog]: https://lnkd.in/dRQtsHAw Part 5: Exploiting BLE [Blog]: https://lnkd.in/d-fg9HE7 Part 6: The Finale [Blog]: https://lnkd.in/dXWDyVGB #cybersecurity #Furbo #hardware #embedded #research #infosec #tech #data #surveillance #hacking #BLE #DES

Potential LPE/RCE in CrowdStrike ❓❓❓ This analysis reveals intriguing insights into CrowdStrike's internal mechanics, highlighting potential Local Privilege Escalation (LPE) and Remote Code Execution (RCE) vulnerabilities. Here are the key highlights of the analysis: ➡️ Directory Structure: CrowdStrike components are located in two main directories. `C:\Program Files\CrowdStrike` contains user mode components, services, and scanning tools, while `C:\Windows\System32\drivers\CrowdStrike` houses kernel drivers and rule files. 🛡️ Core Component - CSAgent.sys: At the heart of CrowdStrike's Windows probe is CSAgent.sys, a highly complex driver. Key functionalities include: 1. A rule engine based on a custom virtual machine, providing flexible security policy execution. 2. Kernel network communication via kernel sockets for secure data exchanges. 3. TLS protocol implementation for encrypted communication, supporting both HTTPS and HTTP proxy protocols. 4. Comprehensive X509 certificate analysis and revocation checks. 5. Network filtering through Windows Filtering Platform (WFP) for managing network events, DNS redirection, and RPC interception. 6. Performance monitoring with CPU performance counters, and tracing via ETW, WMI, and Clfs. 🔄 Dynamic Driver Loading: CSAgent.sys utilizes a dynamic driver loading and unloading process, enabling the use of firmware files that act as rule data rather than standard drivers. 📂 Rule Files: Files like C-00000001-00000000-00000025.sys serve as three-layered rule sets for CSAgent.sys, differing from typical kernel drivers and essential for rule execution and monitoring. ⚠️ Security Concerns: - The virtual machine engine within CSAgent.sys is Turing-complete, allowing control of system memory and enabling code execution permissions. - Lack of signature verification for rule files, increases the risk of exploitation. - CrowdStrike does not have a self-protection mechanism, allowing unrestricted reading and writing of the C-00000291-00000000-00000009.sys file. - C-00000291-00000000-00000009.sys is directly downloaded from the Internet by CSAgent.sys, making it susceptible to manipulation. - Proxy settings can be exploited, with CSAgent.sys able to read from IE AutoProxy, enabling potential network hijacking. 🔑 Key Takeaway: Offensive security experts must scrutinize security solutions like CrowdStrike for vulnerabilities that could lead to LPE or RCE. Understanding these risks and the interactions between system components is essential for effective attack simulations. 👥 If you're navigating the complexities of digital security across various domains—be it phishing, web applications, infrastructure, or cloud services—and seeking insights or support, I invite you to connect, follow, or reach out to me directly on LinkedIn. I'm here to assist in any way possible. 🔗 For an in-depth exploration of this technical analysis, check out the full article on https://lnkd.in/dP4ufW57

When you ship firmware updates over the air, you’re not just sending code. You’re also opening a door. And that door is visible to everyone. A man-in-the-middle (MITM) attack doesn’t need to be sophisticated. It just needs a weak link. Maybe an unverified signature, a missing checksum, or an insecure transport layer. Once that’s found, your firmware update pipeline becomes the attacker’s delivery system. Remember, firmware updates aren’t dangerous. Insecure firmware updates are. If you want to do OTA safely, you need to treat it like any other critical system. Here are 4 best practices to follow: - Encrypt everything. Your firmware is intellectual property. Without encryption, it’s an open book waiting to be studied, copied, or exploited. - Reject rollbacks. An old version is a known weakness. Allowing a rollback is like reopening the same hole you just patched. - Secure your bootloader. If it can’t verify the firmware’s integrity and authenticity, nothing should run. - Build a chain of trust. Every stage should verify the next. That way, when your device boots, you know every byte came from you. You can’t bolt on security after the first breach. It has to be part of your embedded development DNA.

Your firmware signing key just leaked. Not in theory. Not maybe. It is on the internet. A coworker copied it to another system, connected to the main company network. That system was compromised. The whole directory is now public. From this moment on, anyone can sign firmware that looks legitimate. If your device accepts it, the attacker owns the product. This is not a rare scenario. It has already happened with: - leaked code signing certificates - test keys accidentally promoted to production - signing keys stored on build servers - developers copying master keys to "unblock the release" You can do many things right and still assume that one day a key will leak. So the real question is not "how do I protect the key", but "what happens next". Can you: - invalidate the compromised signing key? - prevent devices from accepting firmware signed with it? - (difficulty++) recover devices already deployed in the field? - (difficulty+++) prove which devices were updated before the leak? Many embedded products cannot. They trust a signing key forever. No expiry. No revocation. No plan B. And that works. Until it does not. Robust designs plan for failure: - key rotation so new keys can be introduced and old ones disabled - revocation mechanisms with protected lists of revoked key hashes, updated through authenticated updates - anti rollback to prevent installing firmware from before the revocation - main signing keys kept on separate machines, without network access Today is Thursday, the day of the Embedded Security Challenge. 👉 Your task for this week: pick one signing or authentication key in your system. What would happen if the private key leaked tomorrow? Note: this will probably not show up in pentests. It only shows up when it is already too late.

A debug password is not a physical security boundary. Quarkslab published a very good hardware attack write-up on bypassing the 16-byte IDCODE debug protection on Renesas RH850 microcontrollers using voltage fault injection. That matters because RH850 is everywhere in automotive ECUs. The normal security assumption is simple: Production ECU. Debug access locked. Firmware protected. But “locked” only means the chip follows the intended path when it is operating normally. Fault injection is about making it operate slightly abnormally at exactly the right moment. In this case, Quarkslab targeted the RH850 debug unlock flow. The debug protocol uses UART. The tool sends the unlock sequence, including the IDCODE password, and the chip decides whether debug access should be granted, password-protected, or prohibited. The attack was not “guess the password.” It was “glitch the decision.” They used voltage fault injection against the internal regulator path, first on a Renesas RH850 development board, then on real RH850-based ECUs. The important part is how they made it reliable. A naive UART trigger had too much jitter. So they moved to side-channel analysis, monitored the chip’s power consumption, found a repeatable pattern during password handling, and used that as a better trigger for the glitch. That is the difference between a lab curiosity and an assessment technique. With the improved trigger, they bypassed the IDCODE protection in about a minute on the development board. They then confirmed the pattern across multiple RH850-based ECUs and reported bypasses in minutes after adapting the threshold per board. They also showed a lower-cost version using a Pico Glitcher-style setup, which is the uncomfortable part. Because this is not a million-euro lab fantasy. The evaluation lesson is straightforward: If an ECU’s firmware confidentiality depends on debug lock bits and a password check, you need evidence that the implementation resists fault injection. Not a datasheet statement. Not “debug is disabled.” Not “the password is 16 bytes.” Evidence. A serious automotive ECU assessment should ask: - Which debug interfaces remain physically reachable in production? - Is the debug unlock flow observable over UART or another interface? - Can power traces reveal a repeatable point in the password check? - Are internal regulator pins, VCAP/VREG-style pins, or decoupling layouts helping the attacker? - Does the chip fail closed under voltage/clock/EM fault conditions? - Can a successful glitch restore debug access or rewrite the protection state? - Was this tested on the real PCB, not only on a dev board? This is why physical evaluation matters. The attacker does not need the firmware password if they can fault the moment where the chip decides whether the password matters. Sources https://lnkd.in/epR2fd_d

Vulnerability Management - Systems which cannot be scanned by regular scanners These devices often run embedded OSes with limited visibility and security features. Here's a structured approach to vulnerability management for these types of devices: 1. Asset Inventory and Classification -> Document Devices: Maintain an up-to-date inventory of all such devices connected to your network, including details like make, model, firmware version, IP addresses, and device location. -> Categorize by Risk Level: Prioritize devices based on their criticality to operations, exposure to external networks, and potential impact if compromised. 2. Manual Vulnerability Assessment -> Vendor Documentation & Firmware Analysis: Regularly check the vendor’s site for known vulnerabilities or patches. Many vendors release security bulletins or advisories. -> Vulnerability Databases: Use databases like the NVD or vendor-specific bulletins to look for disclosed vulnerabilities related to your devices. -> Firmware Hash Analysis: Download and analyze the firmware images from the vendor to see if they match known vulnerabilities or contain outdated software components. 3. Network Segmentation and Isolation -> Isolate Devices: Place these devices in their own network segments with restricted access to critical systems, limiting their potential attack surface. -> Use Firewalls and ACLs: Use ACLs and firewalls to restrict communication between these devices and the rest of the network, allowing only the necessary protocols (e.g., SNMP, HTTP). 4. Monitoring and Anomaly Detection -> Network Traffic Monitoring -> Log Collection 5. Configuration Management and Hardening -> Change Default Settings: Disable unused services and change default passwords. Ensure that unnecessary open ports are closed. -> Update Firmware Regularly: Regularly check for and apply firmware updates to patch known vulnerabilities. -> Use Strong Authentication 6. Regular Penetration Testing and Vulnerability Assessments -> Targeted Penetration Tests -> External Audits 7. Device Replacement and Lifecycle Management -> Retire EOL Devices -> Plan for Obsolescence: Maintain a lifecycle management policy that includes replacing or upgrading devices at the end of their support life. 8. Vendor Collaboration -> Request Support: Work closely with device vendors to ensure they provide timely updates and security advisories. Some vendors may also provide custom scripts or agents to assist in vulnerability management. -> Demand Security Transparency: Advocate for better security practices, such as secure firmware updates, encrypted communications, and improved authentication mechanisms from the vendor. 9. Security Policies and Training -> Develop Security Policies -> Educate Staff 10. Use of Specialized Tools -> IoT Vulnerability Scanners -> Agentless Security Tools 11. Incident Response Plan Happy Learning !! #VulnerabilityManagement #CyberSecurity

#Part2 4️⃣Security Mechanisms UDS implements robust security to prevent unauthorized access: ☑️Seed-Key Authentication: ⏩Tool sends SecurityAccess (0x27) request. ⏪ECU responds with a seed (random number). ⏩Tool computes a key using a secret algorithm (shared with OEM). ⏪ECU validates the key to grant access. ➡️Secure Onboard Communication (SecOC): Ensures message integrity/authenticity (aligned with AUTOSAR). ✔️Cybersecurity Protocols: ISO 21434 compliance for threat analysis and risk mitigation. 5️⃣Transport Protocols ☑️UDS over CAN (ISO-TP) ✔️Segmentation: Splits large messages into CAN frames. ✔️First Frame (FF): Indicates total length. ✔️Consecutive Frames (CF): Carry subsequent data. ✔️Flow Control (FC): Manages timing and frame pacing. ☑️UDS over IP (DoIP) ✔️Diagnostics over IP (DoIP): Uses TCP/IP or UDP for high-speed communication. ✔️Vehicle Discovery: DoIP entities broadcast their presence via UDP. ✔️Payload Types: Supports up to 4 GB for firmware updates. 6️⃣Session Management ☑️Session Types: ✔️Default (0x01): Basic diagnostics. ✔️Programming (0x02): Firmware updates. ✔️Extended (0x03): Advanced diagnostics (e.g., actuator tests). ☑️Timing Parameters: ✔️P2 Server Timeout: Max time for ECU to respond (default: 50ms). *P2 Client Timeout**: Max time for tool to send next request. 7️⃣Error Handling & Negative Responses ✅Negative Response Codes (NRCs): 0x11 = ServiceNotSupported. 0x22 = ConditionsNotCorrect. 0x31 = RequestOutOfRange. ✔️Error Recovery: Retries, session restarts, or fallback to default mode. 8️⃣Real-World Implementation ☑️ECU Reprogramming Workflow ⏩Start Programming Session: 10 02. ⏪Security Access: 27 01 → Seed, 27 02 [Key]. ⏩Erase Memory: 31 01 FF 00. ✅Download Firmware: 34 [Address] [Size] → Prepare. 36 [Data Block] → Transfer. ✔️ Reset ECU: 11 01. ✅OTA Updates Uses UDS over DoIP for wireless firmware updates (e.g., Tesla, BMW). Combines UDS with AUTOSAR middleware for secure, reliable transfers. 9️⃣Challenges & Solutions ❌Large Data Transfers: ISO-TP and DoIP handle segmentation for multi-gigabyte firmware. ✅Proprietary Extensions: OEMs define custom DIDs and services (e.g., 0xF200 for battery data in EVs). ❌Cybersecurity Risks: Secure boot, encryption, and intrusion detection systems (IDS) mitigate threats. 🔟UDS in AUTOSAR & Modern ECUs ✅AUTOSAR Integration: UDS services map to AUTOSAR Diagnostic Communication Manager (DCM). Dem (Diagnostic Event Manager) handles DTCs and freeze frames. Adaptive AUTOSAR: Extends UDS for high-performance ECUs (e.g., ADAS, infotainment). 🔆Tools for UDS Development ✅Vector CANoe/CANalyzer: Simulate and analyze UDS traffic. ✅Peak PCAN-USB: Low-cost CAN interface for UDS testing. ✅OEM-Specific Tools: e.g., BMW ISTA, Ford IDS. 🔆Future Trends 💡AI-Driven Diagnostics: ML models predict failures using UDS data. 💡Ethernet-Centric Architectures: DoIP replaces CAN for faster communication. 💡ISO 21434 Compliance: Mandates UDS-based security for connected vehicles.