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
![[intrigued]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7 "Intrigued [intrigued]")
