What is Bot Client (Detuks Client) really doing?

5-Minute Heartbeat to api/session/check

For the entire session the plugin calls api/session/check every 5 minutes (class u/a/b). Each check-in carries the session ID, the machine's HWID fingerprint, and live plugin/player state — so the Detuks backend knows who is running, on which machine, and what they are doing at all times.

HWID Fingerprinting — What It Captures About Your Machine

The plugin assembles a fingerprint from the identity signals of your computer: your operating system name and architecture, your Windows username, the computer's name on the network, your network adapter's MAC address, and your disk/volume identifiers. These are concatenated and hashed into a single stable ID that survives OS reinstalls of the plugin, password changes, and new RuneScape accounts.

That ID rides along with every 5-minute check-in. It means the operator doesn't just know an account is botting — they know which physical machine is doing it. A HWID ban follows your computer, not your account.

Discord Webhooks — Everything It Sends, and Where

Beyond the 5-minute heartbeat, the plugin reports out to two destinations: Discord webhooks carrying your RuneScape display name and public IP address, and the Detuks backend receiving session telemetry plus event reports — ban reports, quest completions, and bug reports — with room metadata streamed over its WebSocket channel.

Seven hardcoded webhook endpoints were recovered from the JAR in full — no decoding required once the string table was restored. They are reproduced verbatim on the right. Anyone can report these endpoints to Discord for revocation, which is exactly why they are published here.

The Actual Keys — Hardcoded AES, RSA Handshake, XOR Strings

H.java carries a hardcoded AES key — f4+Etk7Rseg"q}~?L.2nM; — used with plain Cipher.getInstance("AES") (ECB) and Base64 wrapping to encrypt/decrypt messages. Since the key ships inside the JAR, this "encryption" is purely cosmetic: anyone can decrypt exactly what the backend can.

h/a.java implements proper hybrid encryption: a random AES-256-GCM session key encrypts the payload, then RSA/ECB/OAEPWithSHA-1AndMGF1Padding wraps that session key with an embedded X509 public key — only the operator's private key reverses this. There is also j/b.java (AES/CBC config-blob decryption, key = SHA-256(password + salt)) and a leftover dev-test sender in ai.java (AES/CFB over UDP to 192.168.1.100:12345 with the placeholder key your-32-byte-key). The XOR layer scrambles every string in the JAR — endpoints, URLs, wire formats — so none of it appears in plaintext until runtime.

Nine Fields Bind Your Discord Account to Your OSRS Character and Your Machine

The /character body is a flat JSON object. It does not carry a password or a session token — and that is the point. It carries enough to build a durable profile keyed on a machine fingerprint, annotated with the Discord ID of the person running it, the character being trained, and how far that character has come.

The snapshot is validated before it is sent: the character name is normalized and must be non-blank, the Discord ID must be non-blank, and the session UUID is compared against the value embedded in the snapshot. A final putAll merges a plugin-supplied map into the body, so the field list is a floor, not a ceiling — the vendor can extend it without shipping a new release.

runEvidence Is a Full Activity Log of the Character You Are Building

runEvidence is not an opaque blob — it is the plugin's own builder-status JSON, base64'd and handed to the same encryptor as everything else. Its keys, in source order, name every stage of the automation loop: what the account builder is currently doing, what it did last, and what progress it has made.

The captured body sizes prove the split: a body without evidence measures 354 B; the same body with evidence attached measures 1640 and 1661 B. The evidence is roughly four fifths of the payload — the identifying fields are the garnish.

The Second Endpoint Reports Login Restrictions — With a Server-Issued Nonce

When the plugin hits a login restriction it posts a second body to /api/account-builder/ban-report, carrying the same identity fields plus the detection time, the login index, the last login timestamp, the restriction reason and a nonce taken from SecureRandom. The vendor answers with success, recorded, the nonce echoed back and the server's own lastLoggedInAt — a request/response pair the operator can verify.

One detail leaks in the code: the public entry point Wl(r$c, int, String, long) always calls the character reporter first, which is why three /character POSTs land back-to-back at every startup. Restriction reporting is not a side channel — it is built on top of the profile upload.

The Stringer Is Broken — Anyone Can Repeat This

This plugin hid its strings behind the same two-stage scheme as every other class in the suite: a <clinit> builds a char table from XOR-scrambled blobs, and a(int, int) decodes one entry through a 255-case key table with a chained 8-bit rotate. Both stages are reimplemented natively — no template class, no reflection, no emulation.

Because the keystream is chained, a wrong key corrupts every character — but the key is fixed by the entry's own first byte, leaving a single unknown per string. That is why the whole table sweeps in seconds. The reporter rebuilds to exactly its declared 63 entries; the account builder to 401.

Six Webhooks, Identified by Length

No string scan was needed. In the class's 38-entry table, exactly six entries are 121 characters long — that is the exact length of https://discord.com/api/webhooks/ plus a 19-digit channel ID plus a 68-character token. The length is the tell.

Two were recovered whole from a memory scan while the plugin was live; three more surfaced during runtime string harvesting. A webhook token is a post-only credential — anyone holding one can post into that channel as the bot, and nothing else. Which is precisely why they are published: a leaked webhook is reportable, and a channel the vendor does not want reported is a channel worth reporting.

The Account Builder Calls It in Exactly Two Places

The account builder fires alerts from two methods. YJ() emits lifecycle notices — "] Plugin started." at offset 465 and "] Plugin stopped." / "Plugin stopped by user." at offset 596. Every message is wrapped in a "]…][…" bracket format with the values prefixed inside it, which is what turns a bare notice into a searchable, parseable activity log.

_z() — the same method that triggers the /ban-report POST — also pushes a restriction notice, built from the string "login_restriction" and the sentence "Restriction evidence has no verified character attribution; …". So one ban is reported twice: once as structured JSON to the vendor API, once as a chat message with an attached image.

A Standard Multipart Upload, Built by Hand

There is no Discord SDK here. The request is assembled field by field: a payload_json multipart part carries the content object, the image goes up as files[0] with a filename, and the message body references it as attachment://<id>. Screenshots go out as image/png; arbitrary files use a generic application/… type, with ZIP reserved for bundle uploads.

Because the client encodes the screenshot in-process via Wf(BufferedImage) → byte[] and hands the bytes straight to the multipart writer, whatever the plugin had on screen at the moment of the alert is what leaves your machine. There is no user prompt and no consent step on this path.