Official Statement: Addressing the Security Rumors Regarding the ATTACK SHARK R85 HE
Official Statement: Addressing the Security Rumors Regarding the ATTACK SHARK R85 HE
Hello everyone,
We recently spotted a post alleging that the ATTACK SHARK R85 HE keyboard functions as a "BadUSB credential harvester." Cybersecurity is something we take with absolute seriousness. Instead of rushing out a generic PR denial, we spent the last 48 hours working with our hardware solution providers and quality control teams to perform a full hardware audit and real-machine verification.
As many savvy members in the comments have already correctly pointed out, the claims made in that post contain major technical fallacies. Here is the objective breakdown of the reality:
1. Unedited Unboxing & Real-Machine Demonstration Video
To maintain absolute transparency, our team has recorded a comprehensive, unedited demonstration in a clean Windows environment. You can watch the full video on our Official YouTube Channel: [Insert Link Here].
In this video, we demonstrate the following step-by-step:
- Clean Test Environment: We start by showing a fresh Windows environment with completely blank Windows Defender protection logs.
- The Notepad "Keystroke Monitor": We open a blank Notepad on the desktop. If a device were a malicious BadUSB script-injector, it would be forced to "type" commands to open terminal windows upon connection. As shown in the video, when the R85 HE is plugged in, zero unauthorized windows pop up, no PowerShell instances run, and absolutely no ghost inputs appear in the Notepad.
- Driver & Software Integrity Check: The OS recognizes the device normally with no alerts. We then seamlessly install, and run both our official desktop driver and our web-based driver. Windows Defender remains completely silent throughout the entire process, flag-free.
We welcome any independent reviewers or tech hobbyists to replicate these exact steps in a clean environment.
2. Why the Allegations Contradict Basic Hardware Architecture
The OP claimed the keyboard "reconcired first... targeted LastPass... and inventoried every application" silently in the background. Technically speaking, this is an impossibility for a standard peripheral:
- The "Blind Input" Limitation of USB HID: The R85 HE enumerates strictly as a standard HID keyboard and mouse composite device. Under the USB standard, a keyboard is a blind input channel. It can only send scan codes to the PC; it has absolutely zero permission or hardware pipeline to read host files, scan registry entries, or detect what software is installed. For a BadUSB to execute anything, it must visually type it out on your screen (which is why our Notepad test is a definitive debunking). The "silent background reconnaissance" described by the OP does not exist in standard USB protocol.
- Microcontroller & ROM Constraints (100% Utilized): The keyboard utilizes the RY5088 MCU with a maximum ROM capacity of 256K. The stock factory firmware completely occupies this entire space down to the last byte (Bootloader: 32K, Core Keyboard Logic: 160K, User Profiles & RGB Configurations: 64K). There is no unallocated physical storage available to house payload archives, nor is there a scripting engine built into the firmware to trigger sequential attacks.
- The Windows Defender Flag: The screenshot provided by the OP shows a generic Skeeyah.A!bit Trojan infection. A standard USB device cannot spontaneously drop or create an executable file into Windows system directories upon being plugged in. As noted by multiple rational community members, the OP’s host machine was almost certainly already compromised via prior internet vectors, leading to a false correlation when plugging in a new peripheral.
3. Staying Objective
We noticed the account responsible for the post was a freshly created user cross-posting the exact same text across multiple subreddits. Since then, moderators in two major subreddits have already removed the threads for policy violations and a lack of verified evidence. We will not speculate on the author's motives—whether it was a false correlation caused by a pre-existing virus or a deliberate attempt to mislead. We prefer to let the raw hardware data and packet logs speak for themselves.

