Technical Analysis of Y‑BotManager Anti‑Spam Mechanism and SensorData Reverse Engineering

In 2019 the author began researching the anti‑spam mechanism of a product referred to as X‑Product, which relied on a CDN provider's BotManager service (Y‑BotManager) for defense. Three years later, the technical details of this system are compiled for reference.

Overall Architecture of Y‑BotManager

To use Y‑BotManager, a product must integrate the CDN's SDK, which supports Android, iOS, and Web. All protected requests obtain a SensorData token from the SDK, which is then sent through a CDN node to the backend. The CDN node analyses the token to decide whether the request originates from a human or a bot, routing legitimate traffic to the real server and optionally sending fake responses or errors to bots.

Reverse Engineering the SensorData Generation Process

The first step against Y‑BotManager is to reverse‑engineer how SensorData is generated, which involves decompiling the JavaScript and Android SDKs (approximately 1,000 and 2,000 lines of code respectively) and restoring their logic over about ten days.

Decompilation requires tools and additional work because the code is heavily obfuscated; the analyst must rename variables and functions to improve readability before proceeding to analysis.

SensorData Structure

SensorData := Encrypt(FeatureType,FeatureValue;FeatureType,FeatureValue;...;FeatureType,FeatureValue;Checksum)

SensorData stores a collection of independent feature types, each consisting of a type identifier and a value. The data is designed to be extensible and includes three major categories:

Device‑related features (hardware, software, illegal device, and computational characteristics such as Canvas fingerprinting).

User‑interaction features (touch, keyboard, mouse trajectories, and device motion data).

Additional protocol‑level fingerprints (HTTP, TLS/SSL, TCP/IP stack differences, IP source characteristics).

Gray‑Market Context and Attack Workflow

The author describes infiltrating the gray‑market ecosystem, collaborating with bot sellers, IP proxy providers, and other actors to collect real device feature data. Initial attempts using headless browsers and random feature generation failed, leading to the creation of a feature‑library harvested from real devices.

Subsequent phases focused on improving user‑interaction data, even building a micro‑controller‑driven robotic arm to generate realistic motion trajectories. Despite temporary success, the protection adapted and blocked the bots again.

Further work involved modifying Golang's HTTP/2 and TLS implementations to randomise client fingerprints, and building multi‑language request libraries (Python, Java, Android) that were still intercepted.

Speculation on Y‑BotManager’s Future Enhancements

The author hypothesises that Y‑BotManager may employ machine‑learning models to detect coarse‑grained simulation patterns, and stresses the importance of generating fully consistent, cross‑layer feature sets (e.g., matching device‑level, browser‑level, and TLS fingerprints).

Conclusion

The article provides an attacker‑oriented perspective on anti‑spam defenses, outlining the technical avenues for information gathering, reverse engineering, and evasion, while acknowledging that the described techniques are not exhaustive and that the cat‑and‑mouse game between bots and defenders continues.