REESXSS_V1: O MOTOR DE OFUSCAÇÃO BINÁRIA (WASM + TINYGO) // Rysha Database

[ 0x00 ] THE_EVAL_WARS

Se você já tentou injetar um <script>alert(1)</script> num campo de busca e o site te barrou com um erro 403, você encontrou seu primeiro WAF (Web Application Firewall). Esses caras são treinados para caçar palavras-chave como eval, cookie, e fetch.

A maioria dos hackers para por aí ou tenta um Base64 bobo. Mas aqui no reesXSS, é definitivamente diferente. Este projeto é a minha jornada para transformar um ataque web numa peça de engenharia binária indetectável.

[ 0x01 ] POR QUE WEBASSEMBLY? (THE BINARY SHIELD)

O problema do JavaScript é que ele é... bem, texto. Qualquer F12 revela sua estratégia. Mas o WebAssembly (WASM) mudou o jogo.

WASM é um bytecode. Quando você move a lógica de "desembaralhar" o código para um binário compilado, você cria uma Caixa Preta (Blackbox). O analista de segurança abre o console e vê um monte de números aleatórios e um blob binário. Ele não sabe se aquilo é um motor de jogo, um minerador de cripto ou, no nosso caso, um script de exfiltração de dados de elite.

[ 0x02 ] O MOTOR: TINYGO NO COMANDO

Para criar o core do reesXSS, eu usei TinyGo. Por que não Go puro? Porque o Go padrão embuti um runtime gigante (2MB+) no WASM. Para um payload XSS, isso é um elefante no meio da sala.

Com TinyGo, o binário fica com poucos KB. A lógica que implementei (decrypt_byte) faz rotação de bits, XOR dinâmico baseado no index e um salt matemático (0x1337). * Polimorfismo: Cada vez que você gera o payload, ele é diferente. Se o seu script tem 10 letras "a", no payload final elas viram 10 números totalmente distintos. Análise estatística? Morta.

[ 0x03 ] ARQUITETURA DO SISTEMA

O reesXSS não é só um gerador; é um sistema de Monitoramento e Exfiltração completo: 1. Backend (Python/Flask): O cérebro que gerencia as vítimas, salva os logs e serve o dashboard em tempo real. 2. Persistence (PostgreSQL): Nada de JSON no disco; usamos banco de dados real para lidar com milhares de requisições de exfiltração.

[ 0x04 ] O BLOCO "THE VOID" (ULTIMATE OBFUSCATION)

Para aqueles casos onde o WASM é bloqueado por políticas de segurança (CSP), eu criei o modo The Void. Ele usa Opaque Predicates — condições lógicas que sempre dão verdadeiro (como [] === []... mentira, essa dá falso, mas você entendeu a ideia kkk) mas que confundem completamente os scanners estáticos. Junte isso com Junk Code Injection e você tem um script que parece um labirinto infinito de lógica inútil protegendo o prêmio real no centro.

[ 0x05 ] CASO DE TESTE: BYPASSING LABS

Testar em ambiente controlado é fácil. O desafio foi o testphp.vulnweb.com. O limite de caracteres nos campos deles matava nossos payloads WASM embutidos (27k chars). * Solução: Implementei o WASM Ghost (External). O payload injetado é um loader de 150 caracteres que dá um fetch no binário /engine.wasm do meu servidor. Resultado? Conexão estabelecida e cookies capturados com sucesso.

[ 0x06 ] FINAL_LOGOUT

Este projeto me mostrou que a segurança web é um jogo de gato e rato. No momento que você cria uma barreira, alguém vai criar uma escada binária para pular. O reesXSS é o meu laboratório vivo para entender essas escadas.

Se você é desenvolvedor, a dica é: não confie em filtros de string. Sanitização Real é a única saída. Se você é entusiasta de segurança: o WASM é o futuro da ofuscação (e da detecção).

"If it runs in the browser, it can be hidden." — SYSTEM_ADMIN

[ 0x00 ] THE_EVAL_WARS

If you've ever tried to inject a <script>alert(1)</script> into a search field and the site blocked you with a 403 error, you met your first WAF (Web Application Firewall). These guys are trained to hunt for keywords like eval, cookie, and fetch.

Most hackers stop there or try a silly Base64 encode. This project is my journey to transform a web attack into an undetectable piece of binary engineering.

[ 0x01 ] WHY WEBASSEMBLY? (THE BINARY SHIELD)

The problem with JavaScript is that it's... well, text. Any F12 reveals your strategy. But WebAssembly (WASM) changed the game.

WASM is bytecode. When you move the "unscrambling" logic to a compiled binary, you create a Blackbox. The security analyst opens the console and sees a bunch of random numbers and a binary blob. They don't know if it's a game engine, a crypto miner, or, in our case, an elite data exfiltration script.

[ 0x02 ] THE ENGINE: TINYGO AT THE HELM

To create the reesXSS core, I used TinyGo. Why not pure Go? Because standard Go embeds a giant runtime (2MB+) into the WASM. For an XSS payload, that's an elephant in the room.

With TinyGo, the binary is only a few KB. The logic I implemented (decrypt_byte) uses bitwise rotation, dynamic XOR based on index, and a mathematical salt (0x1337). * Polymorphism: Every time you generate the payload, it's different. If your script has 10 "a" letters, in the final payload they turn into 10 totally distinct numbers. Statistical analysis? Dead.

[ 0x03 ] SYSTEM ARCHITECTURE

reesXSS isn't just a generator; it's a full Monitoring and Exfiltration system: 1. Backend (Python/Flask): The brain that manages victims, saves logs, and serves the real-time dashboard. 2. Persistence (PostgreSQL): No JSON on disk; we use a real database to handle thousands of exfiltration requests.

[ 0x04 ] "THE VOID" BLOCK (ULTIMATE OBFUSCATION)

For those cases where WASM is blocked by security policies (CSP), I created The Void mode. It uses Opaque Predicates — logical conditions that always evaluate to true (like [] === []... wait, that's false, but you get the idea lol) but completely confuse static scanners. Combine that with Junk Code Injection and you have a script that looks like an infinite maze of useless logic protecting the real prize at the center.

[ 0x05 ] TEST CASE: BYPASSING LABS

Testing in a controlled environment is easy. The challenge was testphp.vulnweb.com. The character limit in their fields killed our embedded WASM payloads (27k chars). * Solution: I implemented WASM Ghost (External). The injected payload is a 150-character loader that fetches the /engine.wasm binary from my server. Result? Connection established and cookies successfully captured.

[ 0x06 ] FINAL_LOGOUT

This project showed me that web security is a cat-and-mouse game. The moment you build a wall, someone will build a binary ladder to climb it. reesXSS is my living laboratory for understanding those ladders.

If you're a developer, the tip is: don't trust string filters. Real Sanitization is the only way out. If you're a security enthusiast: WASM is the future of obfuscation (and detection).

"If it runs in the browser, it can be hidden." — SYSTEM_ADMIN