Limitations & Considerations

ZeroTrace HID is a blind keystroke- and cursor-injection platform. It emulates input devices; it does not read the target's screen, filesystem, or process state (beyond the lock-key and USB status the host reports back over HID). Understanding what that means in practice is the difference between a payload that runs first-try and one that types into the wrong window.

This page documents the real constraints. Read it before building anything you intend to run in front of a client.

Keyboard layout dependence

HID keyboards transmit scancodes, not characters. The host translates each scancode through its active keyboard layout. If the target's layout doesn't match the layout your script assumes, the output is silently wrong, symbols and shifted characters diverge the most.

• Set the layout explicitly with keyboardLayout '<language>' (18+ layouts supported).
• The device cannot detect the host's layout. You must know it or set it deterministically.
• A mismatched layout is the single most common cause of a "corrupted" payload, e.g. = arriving as ), \ as `, : as >. If a payload comes out garbled but structurally intact, suspect layout before anything else.

The payload is blind and focus-dependent

Injection types into whatever window currently has focus. The device has no feedback on what that is.

• A payload that opens a terminal must wait for it to actually be focused before typing — use delay generously, or OS-branch timing (see OS detection).
• If the operator's assumptions are wrong (an unexpected dialog, a slow machine, a notification stealing focus), keystrokes land in the wrong place.
• Lock and USB status (Caps/Num/Scroll Lock, connection state) are the only signals the host returns. There is no "did this command succeed" acknowledgement.

No silent autorun on a locked or unattended host

USB-HID injection begins when the device is plugged in and its autostart script fires, but it still types into a live session:

• A locked screen blocks payloads. The device can wake the host (systemKey 'wake_host') but cannot log in without valid credentials.
• Modern operating systems do not AutoRun removable media; delivery is via emulated keyboard/mouse, which requires an interactive, unlocked session with a usable focus target.
• UAC / sudo / polkit elevation prompts require credentials the device does not have unless supplied in the payload for a system you're authorized on.

Detection and endpoint controls

The device is designed for physical plausibility (HID descriptor spoofing, stealth form factors), but it operates against real defenses:

• USB device-control policies (e.g. Group Policy blocking new HID devices, or allow-listing by VID/PID) can block enumeration outright. HID spoofing helps against descriptor-based rules, not against a deny-by-default posture.
• EDR/behavioral detection can flag machine-speed typing, scripted input bursts, or known payload patterns. Use accurateWrite / delayedWrite and realistic delays to reduce signal; this reduces but does not eliminate detectability.
• Every keystroke the device sends is visible to host audit logging exactly as if a human typed it. bruteForce in particular is loud in the host's security log.

Transport constraints (USB vs BLE)

SilentTrace picks USB-HID or BLE-HID based on connectivity, but the two transports are not equivalent. See the full matrix in Compatibility. Summary:

• Cursor work (mouseMove, mouseDraw, mouseJitter, live mouse), gamepad, and mass-storage spoofing are USB-only. They are skipped, not downgraded, over BLE.
• BLE-HID depends on the host's Bluetooth stack. Some UEFI/BIOS pre-boot environments, hardened kiosks, and restricted mobile configurations will not accept a BLE HID peripheral.
• Keyboard and media-key payloads work over both transports.

Wireless range and reliability

• BLE control link (phone → device): roughly line-of-sight room scale; walls, bodies, and 2.4 GHz congestion shorten it. It is a control channel, not a guaranteed real-time link.
• TraceNetwork mesh (ESP-NOW, AES-128-GCM): single-hop, line-of-sight, degrading sharply with obstacles. It is channel-pinned and shares the 2.4 GHz front end, so congested RF widens the timing window for synchronized runs.
• All radios share the single 2.4 GHz front end. Heavy WiFi/BLE/ESP-NOW activity at once trades off against each other.

Storage

• 10 MB on Kit; 2 MB on Mini and Ghost (LittleFS user filesystem).
• Large multi-layout payloads, embedded blobs, or many resident scripts are bounded by this. Mini and Ghost are meaningfully tighter, plan payload size for the smallest device you target.

Power

• High power mode (240 MHz / 19.5 dBm) draws the most current and can brown out on a weak or long USB supply, presenting as spontaneous resets mid-payload. Drop to Normal (160 MHz / 17 dBm) if you see unexpected reboots on marginal power.
• When delivering over USB to a target, the target port must supply enough current; unpowered hubs and current-limited ports can be unreliable.

Timing is best-effort, not real-time

The firmware is not a hard-real-time system. delay values, per-character rates, and synchronized-fire windows are targets, not guarantees; host scheduling, RF conditions, and radio contention all introduce jitter. Build payloads with margin rather than tight timing assumptions.

What the device explicitly cannot do

• Read the screen, exfiltrate files on its own, or make decisions based on on-screen content. It is an input device.
• Bypass full-disk encryption, log into a locked session, or defeat authentication it hasn't been given credentials for.
• Guarantee a payload ran correctly, there is no host-side success acknowledgement beyond lock-key/USB state.
• Operate against a host whose policy blocks unknown HID devices by default.