Encrypted Hilink Uimage Firmware Header -

If you’ve ever run binwalk on a HiLink firmware update (e.g., from an E3372, B310, or AR series router) and seen only high entropy data with no recognizable UImage magic ( 0x27051956 ), you’ve likely encountered this encrypted header.

If the magic appears, you have the correct key. The rest of the firmware may be encrypted in blocks. Many HiLink images encrypt only the header + first block. The remaining data may be plain or compressed. After decryption, run:

strings u-boot.bin | grep -i "aes" Look for key arrays in rodata section. encrypted hilink uimage firmware header

hexdump -C firmware.bin | head -n 20 Look for strings like "HUAWEI" , "HiLink" , or "UPDATE" at offset > 0x1000 (they often appear after the encrypted header). Method A – Static key (older devices) Search U-Boot binary (extracted via JTAG or from a decrypted image):

This article explains what it is, how it works, and practical methods to decrypt and analyze it. A normal, unencrypted UImage header (64 bytes) looks like this: If you’ve ever run binwalk on a HiLink firmware update (e

Key for E3372 (v1): 0x4A,0x6F,0x6B,0x65,0x72,0x73,0x43,0x6F,0x6D,0x65,0x74,0x21,0x2A,0x2A,0x2A,0x00 Key for B310: Derived from serial number + static seed : Modern HiLink devices (2020+) use device-unique keys, making extraction harder but not impossible via hardware glitching. 3.3 Header Structure After Decryption Once decrypted, the header reverts to a standard UImage header with one twist: the ih_name field often contains a secondary signature or a plaintext marker like "SECURE_HILINK_V1" .

magic = struct.unpack(">I", dec_header[0:4])[0] if magic == 0x27051956: print("Decryption successful") with open("dec_header.bin", "wb") as out: out.write(dec_header) The encrypted HiLink UImage header is a modest but effective speed bump against casual analysis. For a determined reverse engineer, it adds a few hours of work—identifying the key source, decrypting, and repacking. However, modern per-device keys and additional signature checks make widespread third-party firmware creation impractical. Many HiLink images encrypt only the header + first block

1. Introduction Huawei’s HiLink protocol powers millions of routers, LTE dongles, and IoT gateways. While standard U-Boot images (UImages) use a well-documented header structure ( struct image_header ), recent HiLink firmware variants employ an encrypted header layer —a deliberate obfuscation to prevent third-party firmware modifications, analysis, and repacking.

Example decrypted header (hexdump):

with open("firmware.bin", "rb") as f: enc_header = f.read(4096)

| Offset | Size | Field | Example Value | |--------|------|---------------|-------------------| | 0x00 | 4 | ih_magic | 0x27051956 | | 0x04 | 4 | ih_hcrc | Checksum | | 0x08 | 4 | ih_time | Timestamp | | 0x0C | 4 | ih_size | Data size | | 0x10 | 4 | ih_load | Load address | | 0x14 | 4 | ih_ep | Entry point | | 0x18 | 4 | ih_dcrc | Data checksum | | 0x1C | 1 | ih_os | OS type | | 0x1D | 1 | ih_arch | Architecture | | 0x1E | 1 | ih_type | Image type | | 0x1F | 1 | ih_comp | Compression | | 0x20 | 16 | ih_name | Image name |