Shielder research: Hard-coded AES kernel key in U-Boot bootloader of Hi3519-based ARM device recovered via Unicorn Engine emulation

Key facts for Hi3519 U-Boot kernel key

Detection coverage for Hi3519 U-Boot kernel key

As of 2026-11-03, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-5130 across Splunk SPL, Microsoft KQL and Sigma, covering 11 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: Firmware Reverse-Engineering Tooling Execution (Binwalk / vmlinux-to-elf) — U-Boot Kernel Key Recovery

Detects execution of Binwalk, vmlinux-to-elf or ghidra-findcrypt, or command lines referencing u-boot.bin / kernel.img.raw. This is the firmware unpack and kernel-conversion workflow used in the Shielder U-Boot research (TL-2026-5130) to recover an encrypted kernel using a hard-coded AES key (CWE-321). Useful for spotting offline analysis of proprietary firmware on corporate or product-engineering hosts.

• Languages: Splunk SPL, Microsoft KQL, Sigma
• ATT&CK: T1592, T1592.002, T1027, T1027.013, T1552, T1552.001, T1140, T1005
• Data sources: sysmon, sysmon_for_linux, edr_process_telemetry
• Severity: low
• Confidence: medium

Splunk SPL

```Firmware reverse-engineering tooling (TL-2026-5130 Shielder U-Boot research)```
(index=sysmon sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1) OR (index=linux sourcetype="sysmon:linux" EventId=1)
| eval img=lower(coalesce(Image,"")), cmd=lower(coalesce(CommandLine,""))
| where match(img,"(binwalk|vmlinux-to-elf|vmlinux_to_elf)(.exe)?$") OR match(cmd,"(binwalk|vmlinux-to-elf|vmlinux_to_elf|findcrypt|u-boot.bin|kernel.img.raw)")
| stats count min(_time) as first_seen max(_time) as last_seen values(cmd) as command_lines values(ParentImage) as parent_images by host, User
| convert ctime(first_seen) ctime(last_seen)

Microsoft KQL

DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ('binwalk','vmlinux-to-elf','vmlinux_to_elf','binwalk.exe')
    or ProcessCommandLine has_any ('binwalk','vmlinux-to-elf','vmlinux_to_elf','findcrypt','u-boot.bin','kernel.img.raw')
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

Sigma

title: Firmware Reverse Engineering Tooling Execution (Binwalk / vmlinux-to-elf)
id: 5f3a1c2e-8b41-4d67-9a0e-3c7d21b6f501
status: experimental
description: Detects execution of Binwalk, vmlinux-to-elf or ghidra-findcrypt used to unpack firmware and convert a decrypted kernel, as in the Shielder U-Boot hard-coded kernel key research (TL-2026-5130).
references:
    - https://www.shielder.com/blog/2022/03/reversing-embedded-device-bootloader-u-boot-p.2/
    - https://github.com/marin-m/vmlinux-to-elf
author: AII-Detector — ThreadLinqs Intelligence
date: 2026/11/03
tags:
    - attack.reconnaissance
    - attack.t1592
    - attack.t1592.002
    - attack.credential_access
    - attack.t1552
    - attack.t1552.001
    - attack.defense_evasion
    - attack.t1027
    - attack.t1027.013
    - attack.t1140
    - attack.collection
    - attack.t1005
logsource:
    category: process_creation
detection:
    selection_img:
        Image|endswith:
            - '/binwalk'
            - '\binwalk.exe'
            - '/vmlinux-to-elf'
            - '/vmlinux_to_elf'
    selection_cli:
        CommandLine|contains:
            - 'binwalk '
            - 'vmlinux-to-elf'
            - 'vmlinux_to_elf'
            - 'findcrypt'
    condition: 1 of selection_*
falsepositives:
    - Firmware security engineers and QA teams analysing their own images
    - Authorized penetration-test or IoT lab activity
level: low

Known false positives:

• Product-security or firmware engineers legitimately unpacking vendor or in-house firmware
• Authorized IoT penetration tests and security research labs

Tuning notes: Allow-list known firmware-analysis hosts and engineering user groups; on those hosts keep the rule as an inventory/audit signal. Raise priority when it fires on non-engineering endpoints or alongside access to your own product firmware.

• 🔒 Bootloader and Decrypted-Kernel Artifacts Written to Disk ([indicator], [indicator], Binwalk extraction) · unlock with TL Creds
• 🔒 Acquisition of Emulation and Firmware Analysis Toolchain (pip install unicorn/qiling/capstone, git clone vmlinux-to-elf) · unlock with TL Creds
• 🔒 Firmware Entropy Analysis and Crypto-Constant Hunting (binwalk -E, findcrypt, hex/strings on bootloader) · unlock with TL Creds
• 🔒 Ghidra Headless / findcrypt Analysis of Firmware Binaries · unlock with TL Creds
• 🔒 Firmware Image Download via CLI Downloader (curl / wget / PowerShell) · unlock with TL Creds
• 🔒 Qiling / Unicorn Emulator Scripts Launched via CLI (ARM Emulation) · unlock with TL Creds
• 🔒 CPU-Emulator Execution Against Bootloader Binary (Unicorn / Qiling, block_aes_decrypt) · unlock with TL Creds
• 🔒 Bootloader / Flash Modification Utilities on Linux Embedded Hosts (U-Boot env, mtd, mkimage) · unlock with TL Creds

Indicators of compromise for Hi3519 U-Boot kernel key

As of 2026-11-03, Threadlinqs Intelligence tracks 11 indicators of compromise for TL-2026-5130.

How Hi3519 U-Boot kernel key works

In a two-part Shielder blog series (part 1 published 2022-03-08, part 2 published 2022-03-21), the authors analyze the firmware of an embedded device built on a HiSilicon Hi3519 SoC (ARM Cortex-A7, ARMv7). The firmware image was downloaded from the vendor website and unpacked with Binwalk. Entropy analysis showed that the kernel and root filesystem were encrypted while the bootloader was stored unencrypted. The bootloader is a customized, stripped U-Boot. The researchers noted secure boot is enforced and the SoC has no ARM TrustZone implementation.

Using Ghidra with manual interrupt vector table analysis, the ghidra-findcrypt plugin and a custom DataTypes library built from U-Boot open-source headers, they determined that U-Boot is loaded at 0x00800000 (RAM begins at 0x80000000, kernel loaded at 0x82000000) and identified AES decryption in the bootloader combined with SHA-1 based key derivation in a non-standard mode of operation. Rather than fully reimplement the custom scheme, they chose to emulate the bootloader's own routine.

In part 2 they use Unicorn Engine (bare-metal CPU emulation derived from QEMU) with Capstone to run the U-Boot function block_aes_decrypt on ARM 32-bit code, mapping u-boot.bin at 0x80800000. The function takes R0 = pointer to encrypted kernel data, R1 = output buffer, R2 = block size (512 bytes in the PoC). Emulation starts at the branch to the decrypt function (0x80800000 + 0x8c40) and stops after return (0x80800000 + 0x8c44). Because the AES key is hard-coded in the U-Boot binary, no external hardware, UART or flash dump was needed. The PoC decrypted the first 512 bytes of kernel.img.raw and the legacy U-Boot image magic 0x27051956 confirmed success. The decrypted kernel appeared as a raw binary in Ghidra until converted with vmlinux-to-elf. Qiling was mentioned as an alternative, but lacked bare-metal support at the time of the research.

This is security research, not an in-the-wild campaign: no CVE, CVSS, attribution, victim reports or network IOCs are stated by the source. The defensive takeaway is that encrypting a kernel image with a key stored in the same unencrypted bootloader (CWE-321) provides only obscurity; an attacker with a firmware download can decrypt the kernel offline and audit it for vulnerabilities. Device vendor/model is not named in the source.

MITRE ATT&CK techniques by tactic:

Defense Evasion

T1027 Obfuscated Files or Information

Persistence

T1542 Pre-OS Boot

Credential Access

T1552 Unsecured Credentials

Resource Development

T1588 Obtain Capabilities

Reconnaissance

T1592 Gather Victim Host Information

Remediation for Hi3519 U-Boot kernel key

Immediate actions

• Treat the kernel encryption key in affected bootloaders as compromised and do not rely on kernel image encryption for confidentiality
• Restrict distribution of unencrypted firmware/bootloader images where feasible

Workarounds

• Do not store secrets in firmware that is publicly downloadable; assume any secret embedded in a bootloader can be extracted and replayed through emulation

Longer-term hardening

• Store decryption keys in hardware-protected storage (OTP/eFuse, secure element or TEE) instead of the bootloader binary
• Use per-device derived keys rather than a single hard-coded key shared across the product line
• Use standard authenticated encryption modes and signed images with a hardware root of trust instead of custom non-standard modes
• Include firmware reverse-engineering and secret scanning (e.g. hard-coded key detection) in product security testing

Affected and fixed versions

• HiSilicon (SoC); device vendor not named in source — Hi3519-based embedded device with customized U-Boot
  Vulnerable versions: Firmware analyzed by Shielder (specific version not stated)

Timeline of Hi3519 U-Boot kernel key

• 2022-03-08 Researchers opt to emulate the bootloader's own decryption routine instead of fully reverse engineering the custom encryption mode.
• 2022-03-08 U-Boot load address (0x00800000; RAM at 0x80000000, kernel at 0x82000000) deduced from locked-ioc-10 references without UART access or a flash dump.
• 2022-03-08 locked-ioc-10 and locked-ioc-2 analysis identify AES decryption plus SHA-1 key derivation in a non-standard mode within the bootloader.
• 2022-03-08 Shielder publishes part 1: firmware downloaded from the vendor website and unpacked with locked-ioc-9; entropy analysis shows kernel and rootfs encrypted while the U-Boot bootloader is not.
• 2022-03-21 Decrypted output verified via image magic locked-ioc-7; locked-ioc-4 used to turn the decrypted kernel into an analyzable ELF in locked-ioc-10.
• 2022-03-21 Shielder publishes part 2: locked-ioc-3 emulation of block_aes_decrypt (R0 input, R1 output, R2 size 512) decrypts the first 512 bytes of the kernel using the key hard-coded in U-Boot.

Sources cited for Hi3519 U-Boot kernel key

• Reversing embedded device bootloader (U-Boot) - p.2 shielder.com · Research · 2022-03-21
• Reversing embedded device bootloader (U-Boot) - p.1 shielder.com · Research · 2022-03-08
• Ghidra software reverse engineering framework ghidra-sre.org · Research
• Unicorn Engine - CPU emulator framework unicorn-engine.org · Code repository
• vmlinux-to-elf - kernel to analyzable ELF converter GitHub · Code repository
• Qiling Framework GitHub · Code repository
• Capstone disassembly framework capstone-engine.org · Code repository

More in threat intel

• Spamhaus Botnet Threat Update July to December 2025: C&C Activity Up 24%, RATs 42% of Top 20 Botnet Malware
• Spamhaus Botnet Spotlight: Pressure Rises on Botnets (Threat Update July-December 2025) - VenomRAT, Latrodectus, CrazyRDP Takedown
• Spamhaus Botnet Threat Update January–June 2026: Sliver Overtakes Cobalt Strike as Leading C&C Family
• NCSC Warning: AI-Powered Malware Highly Likely to Be Used in Ransomware Attack on UK Critical National Infrastructure by 2028
• Microsoft Security Research: What Exploited Vulnerabilities Have in Common - Data-Driven Analysis of Real-World Attacks