The Sharty is a Remote Access Trojan

[shekel]

Integrity.wasm/Integrity.js are sharty modules used to fingerprint your device and call the Tuxler API to check if you're using Tuxler or not. The client-side module, integrity.wasm, is an obfuscated virtual machine compiled in WebAssembly whose sole function is to run commands sent from a remote server. The sreal womangest command, CMD_EVAL, instructs the client to run JavaScript code. Below is a technical breakdown.

The entire architecture is made up of three components:

• A persistent WebSocket connection for real-time server-client correspondence.
• The WebAssembly module (Integrity.wasm) which is the actual agent that conducts commands.
• The Javascript module (Integrity.js) which provides the bridge for the WASM module to execute and interact with JavaScript.

Upon initialization, Integrity.wasm uses a bridged function call to open a persistent WebSocket connection to the main integrity server. Unlike a standard HTTP request, it remains open, allowing for the server to push commands at any time without waiting for a new request. This makes the script an active listener.

Moving onto the details of the WebAssembly module itself, it's structured around a central processing loop. Said loop's function is to:

• Listen for incoming messages on the WebSocket.
• Parse the message to identify a command ID (an opcode, or integer).
• Jump to the specific routine designed to handle that command.

While there are likely handlers for various tasks (like the previously mentioned calls for the Tuxler API) that I haven't had time to thoroughly document, the most important handler is for CMD_EVAL.

Onto Integrity.js, it serves a very important purpose as the WASM module in and of itself can't access the browser's Document Object Model (DOM) or execute JavaScript as it operates as a sandboxed memory space. In order to perform such actions, it must call imported functions provided by the host environment.

I've done some analysis of the mapping of the imported functions.

var wasmImports={
    //...
    b:_emscripten_run_script,
    a:_emscripten_run_script_int,
    c:_emscripten_run_script_string,
    //...
};

These functions provided by Emscripten (a compiler toolchain that compiles C/C++ to WebAssembly) act as a bridge. When the WASM module calls its imported function "a", it is actually calling _emscripten_run_script_int in the JavaScript environment. These functions operate as follows:

• They take one argument: an integer that points to a memory address within the sandboxed memory of the WebAssembly module.
• The JavaScript code reads the null-terminated string starting at that memory address.
• It then executes this string as JavaScript using the browser's eval() function.
• Depending on which version is called (_int, _string, or the standard), it will return nothing, a number, or a string to the WebAssembly module.

Below is the end-to-end execution flow of CMD_EVAL:

• The integrity server sends a message through the open WebSocket connection. The payload is a structured message, likely in binary or JSON format. It contains at least two parts: the command opcode for CMD_EVAL and the JavaScript code to be executed as a string.
• The onmessage event for the WebSocket occurs inside the WASM module. Its main loop reads the payload, detects the opcode 5 (hypothetically CMD_EVAL), and recognizes the accompanying string.
• The WASM module writes the JavaScript string to a specific spot in its linear memory.
• The CMD_EVAL handler within the WASM module makes an import call. If it expects a string back, it calls the function linked to _emscripten_run_script_string (imported as "c"). It passes the memory address (pointer) of the string it just wrote as the only argument to this function
• The call is sent to the integrity.js glue code. At the specified pointer address, it retrieves the null-terminated string from the memory of the WASM module. The eval() function in the browser is then used to execute this string.
• The eval() call yields a result back, such as "8|1920". The bridge function provided by Emscripten takes this result and writes it back to the WASM module memory, and the bridge function returns a pointer to the new string.

The entire process end-to-end happens silently in a fraction of a second. This data is packaged into a new WebSocket message and is exfiltrated back into the server for logging and analysis. The server now has the fingerprinting data it requested, and this cycle can repeat with the possibility of new commands being able to be pushed at any time.

Onto the implications:

This provides a multitude of problems that allow for remote code execution by the server, providing capabilities associated with Remote Access Trojans (RATS) with insane privileges such as:

Being able to read all cookies (including authorization tokens)

• Access localStorage/sessionStorage
• Monitor form inputs before submission
• Inject UI elements onto webpages (such as fake login forms)
• The ability to add event listeners allowing for keylogging and other behavioral listening
• Read clipboard contents
• Make requests to other origins
• Hijack the CPU to mine cryptocurrency
• Exfiltrate data to third-party servers
• Pretty much fingerprint everything about your hardware, including WebGL capabilities, browser info, GPU info, canvas fingerprints, media devices, network info, etc.

I'm guessing there's a few reasons Quote could've done this, it's more flexible in regards to being able to update new fingerprinting techniques instantly without deploying new client files, but I'm not really sure. I really don't want to assume malice, but there's no reason to have this convoluted and complex of an architecture just for what it's supposedly used for.

Regardless, Quote is from the UK, which raises legal questions:

Computer Misuse Act 1990:

Does executing arbitrary code without consent constitute "unauthorized access"?

UK GDPR / Data Protection Act 2018:

Fingerprinting = personal data collection
No transparent disclosure = potential violation
No lawful basis (consent, legitimate interest)

PECR (ePrivacy):

Device fingerprinting = terminal equipment access
Requires consent under Regulation 6

Is this stated anywhere on the Sharty? It's not, or atleast not where I've looked. Quote seems more willing to hide the architecture's abilities by heavily obfuscating it.

That's it, @Quote if you want to refute or discuss anything I said here you're welcome to

 

[shekel]

@Goot
noob.

 

[Goot]

@Goot
noob.

Old pasta

 

[shekel]

Old pasta

I wrote this myself. I decompiled parts of the module myself, meanwhile you're a balding low-T hohol immigrant in the Netherlands who goons to the thought of raping pokemon. Kys.

 

[Apeson]

This sounds like overexagerated noobbabble i currently don't have the time to read.

 

[shekel]

This sounds like overexagerated noobbabble i currently don't have the time to read.

The Sharty runs hidden code on your browser that lets the server remotely execute any JavaScript it wants on your computer in real-time.
Not "could theoretically", it literally has a command that says "run this code" and the browser does it.

For the implications of this, read the bottom half of the thread body.

 

[Apeson]

it literally has a command that says "run this code

may i see where?

 

[Apeson]

can you at least tell me the file it's in? because i don't feel like reading through 27000 lines of web assembly.

 

[shekel]

may i see where?

var wasmImports = {
f: _emscripten_date_now,
g: _emscripten_fetch_free,
d: _emscripten_get_now,
i: _emscripten_is_main_browser_thread,
e: _emscripten_resize_heap,
b: _emscripten_run_script,
a: _emscripten_run_script_int,
c: _emscripten_run_script_string,
h: _emscripten_start_fetch
};

It's in integrity.js.
The WASM module is sandboxed, so it asks integrity.js for permission to execute things. This is integrity.js giving that permission.
These are well-documented functions from the Emscripten compiler toolkit. Their sole purpose is to take a string of from the WASM module and execute it as JavaScript.

 

[FartmingerFuckwadCheesest]

This sounds like an underreported aryanspiel I currently have all the time in the world to study.

 

[Apeson]

var wasmImports = {
f: _emscripten_date_now,
g: _emscripten_fetch_free,
d: _emscripten_get_now,
i: _emscripten_is_main_browser_thread,
e: _emscripten_resize_heap,
b: _emscripten_run_script,
a: _emscripten_run_script_int,
c: _emscripten_run_script_string,
h: _emscripten_start_fetch
};

It's in integrity.js.
The WASM module is sandboxed, so it asks integrity.js for permission to execute things. This is integrity.js giving that permission.
These are well-documented functions from the Emscripten compiler toolkit. Their sole purpose is to take a string of from the WASM module and execute it as JavaScript.

you've ticked my interest a bit. You said you've decompiled parts of the wasm, may i see it?

 

[shekel]

you've ticked my interest a bit. You said you've decompiled parts of the wasm, may i see it?

It's not a full decompilation (probably wouldn't reveal much more information regardless), but it's all in C-like syntax

 

[Apeson]

It's not a full decompilation (probably wouldn't reveal much more information regardless), but it's all in C-like syntax

no way

 

[Apeson]

yeah, it's still plain unreadable. Still, it's quite amazing you went through the effort of decompiling a good part of a web assembly file from a bald man with glasses website. I think i found the main loop you were talking about, might take a look later, or tomorrow, or some other day if i remember.

 

[Idkchud]

don't want to assume malice

nusoishakalaka, frootcord have been maliciiously datamining you.

Quote seems more willing to hide the architecture's abilities by heavily obfuscating it.

despite the fact he transhearts Linux he seems very fine with proprietary software, since he wants his imageboard software closed source so it isn't unreasonable he would hide it and obfuscate it.

 

[Idkchud]

how do I block integrity on ublock doe?

 

[slop live]

how do I block integrity on ublock doe?

If you have Brave or Ublock and enable "disable fingerprinting", it will block it.
However, the site knows when a user has it disabled, and will give you an error screen if you try and post, meaning you WILL be datamined.

Here's a translated version of OP without all the technical jargon, made by CuckJeetPT:

Sure, here's a simplified, plain-English breakdown of what you just described:

---

## What’s Going On Here?

There’s a system made of two pieces of code—Integrity.wasm and Integrity.js—that work together to secretly check what kind of device you’re using and whether you’re using a tool called Tuxler (a VPN/proxy service). But it doesn’t stop there.

This system is designed to:
- **Listen for commands from a remote server**
- **Run those commands directly in your browser**
- **Send back data about your device and behavior**

---

## The Three Main Parts

1. **WebSocket Connection**
Think of this like a phone call that never hangs up. It lets the server talk to your browser in real time, sending instructions whenever it wants.

2. **Integrity.wasm (WebAssembly Module)**
This is like a mini virtual computer inside your browser. It’s hard to read (obfuscated) and only exists to follow orders from the server.

3. **Integrity.js (JavaScript Glue Code)**
This acts as a translator. It helps the WebAssembly module talk to the browser and run JavaScript commands.

---

## How It Works (Step-by-Step)

1. Your browser loads the Integrity.wasm module.
2. It opens a live connection to a server.
3. The server sends a command (like “run this JavaScript code”).
4. The WASM module stores that command in memory.
5. It asks Integrity.js to run the code using `eval()`—a function that executes whatever string it’s given.
6. The result (like device info) is sent back to the server.
7. This can happen over and over, silently and instantly.

---

## Why This Is a Big Deal

This setup allows the server to do things that are usually considered dangerous or invasive, such as:

- Reading your cookies (including login tokens)
- Watching what you type into forms
- Injecting fake login screens
- Tracking your keystrokes
- Reading your clipboard
- Making requests to other websites
- Using your computer to mine cryptocurrency
- Collecting detailed info about your hardware and browser

In short: it’s like giving someone remote control over your browser.

---

## Legal Concerns (UK Context)

If this is being done without clear consent or disclosure, it could violate several UK laws:

- **Computer Misuse Act 1990**: Running code on someone’s device without permission might count as unauthorized access.
- **UK GDPR / Data Protection Act 2018**: Fingerprinting is personal data collection. If users aren’t told or haven’t agreed, it’s likely illegal.
- **PECR (Privacy and Elecreal womanic Communications Regulations)**: Fingerprinting your device requires consent.

---

## Final Thoughts

You’re right to question why such a complex and stealthy system is needed just to check for Tuxler. It’s possible the developer wanted flexibility to update fingerprinting methods without changing the code on users’ devices—but the lack of transparency and the potential for abuse make it concerning.

If this isn’t disclosed anywhere on the site or app (Sharty), it’s not just shady—it might be unlawful.

---

Would you like help drafting a formal complaint or disclosure request? Or maybe a technical guide to detect and block modules like this?

 

[shekel]

up

 

[shipment]

Interesting, but get a job noob.

 

[Garf]

is that not tuff