Full Report
Welcome back to part 2.2 of this series! If you have not yet checked out part 1 or part 2.1, please do so first as they highlight important reconnaissance steps as well as the first half of the disassembly analysis! Let's recall the current functionality we&
Analysis Summary
# Research: Breaking the D-Link DIR-3060 Firmware Encryption (Part 2.2: Dynamic Analysis and Decryption Routine)
## Metadata
- Authors: [Identified as 0xricksanchez based on context and provided links, although explicit author list for part 2.2 is not present]
- Institution: [Inferred: Independent or academic researcher]
- Publication: [Blog Post Series on 0x434B.dev]
- Date: [Implied: Recent, contextually relating to firmware analysis series]
## Abstract
This technical analysis, presented as Part 2.2 of a series, details the dynamic analysis of a decrypted D-Link router firmware routine, focusing on uncovering the methods used for initial data processing—specifically involving cryptography setup and integrity checks. The analysis reveals the exact hardcoded constants for the Initialization Vector (IV), AES key, and pre-encrypted data block utilized by the embedded system. Key steps involve reversing assembly instructions to determine values required for setting up RSA public key structures, calculating subsequent data lengths using MIPS unaligned memory access instructions (`lwl`/`lwr`) combined with endianness conversion (`htonl`), and preparing for a SHA512 integrity check on the firmware image segment. The research ultimately leads to the full decryption and unpacking of the D-Link DIR-3060 firmware.
## Research Objective
The primary objective of this research segment is to complete the analysis of the firmware decryption routine initiated in previous parts, specifically focusing on:
1. Identifying the hardcoded cryptographic constants (IV, AES key).
2. Understanding the assembly logic used to calculate data lengths and prepare for integrity checks (SHA512).
3. Achieving full decryption of the D-Link DIR-3060 firmware image.
## Methodology
### Approach
The research employs dynamic analysis, building upon prior static analysis (disassembly). The analysis involves tracing the execution flow of the relevant decryption function within the extracted and partially understood MIPS binary. Critical sequences of MIPS assembly instructions are mapped back to their C language equivalents or functionalities (e.g., OpenSSL calls, network byte order conversions).
### Dataset/Environment
The analysis focuses on the firmware binary for D-Link routers, specifically cited examples include the **D-Link DIR-3060** and **DIR-882**, demonstrating consistent security mechanisms across different models. The investigation utilizes the disassembled code structure and specific byte sequences extracted from the firmware headers.
### Tools & Technologies
- **Disassembler/Decompiler:** Tools like IDA Pro were presumably used for disassembly, reconstructing C-like code snippets.
- **Debugging Tools:** GDB was suggested for dynamic debugging of the MIPS embedded binary.
- **Reconstruction & Verification:** Custom C code snippets were developed to mimic and test the observed decryption and processing logic (e.g., OpenSSL functions, memory operations). Python/Shell scripting for verification of file sizes and byte manipulation.
## Key Findings
### Primary Results
1. **Hardcoded Cryptographic Constants Identified:** The analysis successfully extracted and confirmed the following hardcoded values used within the firmware's decryption setup:
* **IV (Initialization Vector):** `0x98, 0xC9, 0xD8, 0xF0, 0x13, 0x3D, 0x06, 0x95, 0xE2, 0xA7, 0x09, 0xC8, 0xB6, 0x96, 0x82, 0xD4`
* **AES Key:** `0x35, 0x87, 0x90, 0x03, 0x45, 0x19, 0xF8, 0xC8, 0x23, 0x5D, 0xB6, 0x49, 0x28, 0x39, 0xA7, 0x3F`
* **Preamble/Encrypted Data Block:** Block used for testing/validation, starting with `0xC8, 0xD3, 0x2F, 0x40...`
2. **Security Header Validation Check:** The firmware image must pass an initial check of its header, where the byte sequence `0x53 0x48 0x52 0x53` ("SHRS") is expected at a specific offset.
3. **Data Length Calculation:** Two specific 4-byte values (`datalen_1` and `datalen_2`) are derived from the firmware header using MIPS unaligned load instructions (`lwl`, `lwr`) and then processed by `htonl` (network byte order conversion) to determine segment lengths.
4. **Integrity Check Setup:** The function `calcSha512Digest` is subsequently called using one of the calculated lengths (`datalen_2`) and an offset within the mapped file (`0x6dc`), indicating a verification step for the payload.
5. **Successful Decryption:** The process culminates in cracking a password protecting the key and fully decrypting the firmware, yielding the embedded Linux file system structure.
### Supporting Evidence
- The direct translation of MIPS assembly sequences (like `lwl`/`lwr` for unaligned loads) into their resulting byte values (e.g., yielding `0xb0d9d100` and `0xa6d9d100`) provided concrete evidence for the length calculations.
- The successful extraction of the password and subsequent decryption confirms the accuracy of the identified cryptographic parameters and routine logic.
### Novel Contributions
- Complete mapping of the unique decryption routine, especially the unconventional method for deriving data segment lengths using MIPS unaligned loads followed by network byte order conversion.
- Confirmation that the **encryption mechanism, security header structure, and decryption key remained static** across D-Link models (DIR-882 and DIR-3060) spanning several years.
## Technical Details
The core technical challenge involved reversing the MIPS assembly that handles reading unaligned data. For instance, loading a 32-bit value from an unaligned address involved a sequence of:
1. `lwl $v1, 11($v0)`: Loads the most significant bytes of the target value into the upper portion of the register.
2. `lwr $a0, 8($v0)`: Loads the least significant bytes of the target value into the lower portion of the register.
These results are then merged and passed to `htonl`. This contrasts the typical pattern expected for calculating file lengths, suggesting a highly customized or obfuscated initial data processing stage before standard cryptographic functions (AES/SHA512) could operate.
## Practical Implications
### For Security Practitioners
- Firmware updates for D-Link devices utilizing this specific header/encryption scheme are vulnerable to unauthorized modification if the attacker gains initial physical access to determine the hardcoded decryption constants or if the authentication mechanism is bypassed (as was done here).
- The consistency of the security mechanism across device generations suggests a systemic lack of evolution in D-Link's firmware security practices over the observed period.
### For Defenders
- **IoT Security Teams:** Organizations deploying D-Link hardware should audit for the presence of this specific "SHRS" header and associated static cryptographic keys in running firmware or during update processes if attempting to perform integrity checks.
- **Patch Priority:** Hardware using this scheme should be considered high risk, as the key is static and extractable via physical analysis.
### For Researchers
- Further research should investigate why the security relies on hardcoded constants accessible via simple physical analysis (dumping the flash).
- Investigation into the proprietary RSA certificate mechanism used in `check_cert` should be prioritized to understand the full authentication chain, beyond the demonstrated static decryption path.
## Limitations
- The research relied on **physical access** to the device (serial console/firmware dumping) to obtain the necessary binary for analysis.
- The analysis focused strictly on the firmware decryption component; other potential security vectors like the Over-The-Air (OTA) update mechanism or the web GUI were noted as being out of scope.
- The decryption required interacting with OpenSSL/crypto libraries, but the specific MIPS implementation details beyond the register operations are summarized through functional equivalence (C code).
## Comparison to Prior Work
This work is explicitly positioned as Part 2.2, continuing previous reconnaissance and static analysis (Part 1 and 2.1). The novelty here is the successful dynamic mapping of the remaining assembly logic, which confirms the structure found earlier and leads to the final payload extraction, providing a complete end-to-end reverse engineering achievement where previous stages only laid the groundwork.
## Real-world Applications
- **Firmware Integrity Verification Tools:** The identified constants and logic can be incorporated into automated tools (like the referenced FACT) designed to unpack and verify proprietary IoT firmware images.
- **Vulnerability Research:** Serves as a template for analyzing other consumer router firmware that might employ similar initialization routines based on static keys protecting AES CBC modes.
## Future Work
- Investigate the role and implementation of the RSA public key loading mechanism (`check_cert`) more deeply to determine if it provides a secondary layer of *runtime* authentication that was bypassed by focusing on the static decryption key.
- Analyze the OTA update process to see if a similar (or different) decryption mechanism is enforced there.
## References
- Part 1: Breaking the D-Link DIR-3060 Firmware Encryption: Recon (Linked internally)
- Part 2.1: Breaking the D-Link DIR-3060 Firmware Encryption: Static Analysis of the Decryption Routine (Linked internally)
- FACT (Firmware Analysis Toolkit) by fkie-cad (Mentioned as incorporating the decryption logic)
- Author's GitHub repository containing the final decryption script and C reconstruction.