The WPF Native Migration: Hardening Performance and Memory Security
GitHub Repository1. Why We Abandoned Electron
While Electron served as a useful rapid-prototyping wrapper to move from CLI node launchers to a visual GUI, its architectural baggage became a direct liability to the security and performance requirements of the OMEGA Protocol. Chromium's large footprint, complex multi-process sandbox, and the inherent node-integration exploit paths posed unnecessary risks for a volatile terminal.
| Metric / Métrica | Electron (Deprecated) | WPF Native (OmegaTerminal) |
|---|---|---|
| RAM Usage / Uso de RAM | ~150MB - 250MB | ~22MB - 35MB (Optimal) |
| Binary Size / Tamaño Binario | ~85MB (Compressed) | ~4.8MB (Fully Compiled) |
| Tor Process Lifecycle | child_process (Risk of Zombies) | Strict Windows Job Objects Control |
| Memory Scrubbing / Higiene | GC Dependent (GC V8 Engine) | SecureString & Cryptographic RAM Overwrite |
2. Technical Implementation details (C# / .NET)
The C# codebase utilizes native Windows API bindings to strictly regulate memory isolation and cryptographic security. Ephemeral variables are held inside SecureString containers, preventing plaintext credentials from lingering in memory sweeps or swap space.
// Ephemeral Onion Key Derivation & Volatility Control
public class ProcessManager { private static IntPtr _jobHandle; public static void InitializeSecurityJob() { // Enforce Windows Job Objects to prevent zombie Tor child processes _jobHandle = CreateJobObject(IntPtr.Zero, null); var info = new JOBOBJECT_BASIC_LIMIT_INFORMATION { LimitFlags = JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE }; // Secure handle binding... } public static void WipeVolatileConfiguration(string appDataPath) { if (Directory.Exists(appDataPath)) { foreach (var file in Directory.GetFiles(appDataPath)) { // Strict cryptographic overwrite before deletion byte[] chaff = new byte[new FileInfo(file).Length]; using (var rng = RandomNumberGenerator.Create()) { rng.GetBytes(chaff); } File.WriteAllBytes(file, chaff); File.Delete(file); } } } }3. Strict Tor Lifecycle & Memory Governance
By leveraging Windows Job Objects, OmegaTerminal binds the lifecycle of the Tor daemon process directly to the main GUI thread. If the main interface is terminated (by user choice, operating system kill commands, or host crash), the operating system immediately reaps all sub-processes in the job tree, ensuring no persistent listening sockets are left active on the host machine.
Additionally, all previously written onion authentication keys and ephemeral Tor descriptors on disk are programmatically overwritten using cryptographic-grade random streams prior to file deletion, mitigating the risk of forensic offline recovery of old .onion addresses.
4. The Multi-OS Roadmap: Native Linux & Beyond
OmegaTerminal prioritizes performance and security. C# WPF is well-suited for native Windows desktop integrations, and cross-platform parity is being implemented for multi-system operations.
// Linux Dedicated Engine
Developing a native Linux build using Avalonia UI and direct .NET Core bindings. This bypasses the heavyweight Electron wrappers on Linux while preserving extreme execution speeds and native memory management.
In development// Unix Security Parity
Implementing Linux-specific process isolation via direct prctl(PR_SET_PDEATHSIG) bindings and memory protection policies like mlockall, preserving zero-footprint properties and secure process lifecycle governance.
OMEGA Protocol — Web Application (Terminal) Black Box Penetration Test Report
GitHub Repository1. Executive Summary & Audit Scope
While the previous articles and audits of the OMEGA Protocol focused on static code reviews, cryptographic math validations, and architectural migrations (like WPF native porting or ECDSA attestation), this audit represents a fundamental shift. We performed a live, dynamic Black-Box Penetration Test on the deployed web application. For clarity: the OMEGA Protocol defines the cryptographic transport specification, while Terminal is the reference web application that implements it — the same relationship as a protocol standard and its reference client. Terminal was evaluated as a single system. The test simulated an external, unprivileged threat actor attempting to breach the application from the network layer, targeting HTTP/WebSocket boundaries and runtime behaviors.
Overall Result: Out of 26 dynamic attack scenarios executed against the Terminal web application, two web-layer configuration issues (CORS and CSP) were identified. Both were corrected and the findings documented below.
2. Dynamic Pentesting vs. Static Audits
Instead of analyzing source code offline, this assessment focused on real-time behavior by actively attacking the running application. We bypassed cryptographic code analysis to focus entirely on runtime vulnerabilities:
- // DYNAMIC WEBSOCKET FUZZING: We flooded the live WebSocket channel with corrupted JSON payloads, raw binary streams, and unexpected frame sizes to check if the protocol's runtime parser would crash, leak memory, or expose internal server states.
- // NETWORK FLOODING & REPLAY TESTS: We captured valid handshake packets and attempted replay attacks at the TCP/WebSocket layers, while executing stress tests with simultaneous connections to evaluate live resource allocation and protocol protection limits.
- // WEB BOUNDARY ENUMERATION: We performed directory brute-forcing, path-traversal payload injection, and HTTP header inspections on the server to check for misconfigurations exposed to the public network.
3. Vulnerability Mitigation
🔴 VULN-01: OVER-PERMISSIVE CORS (HIGH)
Vector: Access-Control-Allow-Origin: * allowed unauthorized external origins to read HTTP responses from the server. While the core Omega Protocol communications travel via WebSocket, this open web header could allow third-party scripts to fetch client-side assets under certain conditions.
🟡 VULN-02: CSP ALLOWS UNSAFE-EVAL (MEDIUM)
Vector: The presence of 'unsafe-eval' in the script-src Content-Security-Policy could allow dynamic evaluation of strings. If a code injection vulnerability were to exist elsewhere, this flag would bypass typical CSP execution restrictions.
4. Final Conclusion
The dynamic penetration test did not reveal weaknesses in the cryptographic engine; the findings were configuration issues at the web application layer (CORS and CSP), which were addressed. The deployment was re-evaluated against runtime attacks as documented above.
// ARCHIVE: ORIGINAL AUDIT REPORT (FULL)
// ARCHIVO: REPORTE DE AUDITORÍA ORIGINAL (COMPLETO)
Black Box Penetration Test Report
Reporte de Pentesting Caja Negra
Eduardo Camarillo [Noir0x63] — Terminal E2EE
Eduardo Camarillo [Noir0x63] — Terminal E2EE
June 26, 2026
26 de junio de 2026
# REPORTE DE PENTESTING — PROYECTO "TERMINAL" **Target**: http://127.0.0.1:3000 + ws://127.0.0.1:3000 **Propietario**: Noir0x63 (Eduardo Camarillo) **Fecha**: 2026-06-26 **Clasificación**: PÚBLICO (Post-Mitigación) **Metodología**: Caja Negra (Black Box) --- ## 1. RESUMEN EJECUTIVO Se realizó una auditoría de seguridad completa de caja negra sobre el proyecto **Terminal**, una aplicación de comunicación E2EE en tiempo real que opera como servicio onion de Tor. El proyecto implementa un protocolo criptográfico de múltiples capas con Perfect Forward Secrecy, cifrado AES-256-GCM, derivación de claves PBKDF2+HKDF, atestación ECDSA, y protección anti-análisis de tráfico mediante frames de ruido y padding constante. **Resultado general**: De 26 pruebas realizadas, se identificaron **2 hallazgos** de configuración a nivel de aplicación web (CORS y CSP), que fueron corregidos. --- ## 2. ALCANCE ### 2.1 Superficie de Ataque | Componente | Expuesto | Puerto | |------------|----------|--------| | HTTP Server | Sí | 3000 | | WebSocket | Sí | 3000 (upgrade) | | Files estáticos | index.html, client.js, omega-worker.js | 3000 | | Backend server.js | No | Interno | | Tor onion service | Sí | .onion:80 → localhost:3000 | ### 2.2 Pruebas Realizadas | Categoría | Pruebas | Detalle | |-----------|---------|---------| | HTTP Enumeration | 35+ paths | Sin información sensible expuesta | | Path Traversal | 10 payloads | Todos rechazados (404) | | HTTP Methods | 7 métodos no estándar | Todos rechazados (405/400) | | WebSocket Injection | 9 payloads maliciosos | Todos rechazados (sin respuesta) | | Frame Size | 3 pruebas | Límites correctos | | Connection Flood | 50 conexiones | Servidor resiliente | | Session Reuse | 2 conexiones mismas credenciales | Sin errores | | Replay Attack | Handshake reenviado | Sin vulnerabilidad | | Noise Amplification | 100 frames | Sin impacto | | Buffer Overflow | 4KB payload | Sin crash | | Special Characters | Unicode/control chars | Sin crash | | Rapid Connect | 20 conexiones rápidas | Sin resource exhaustion | | Info Disclosure | 4 pruebas | Sin leakage | | CORS Testing | 5 orígenes | Vulnerabilidad encontrada | --- ## 3. VULNERABILIDADES ENCONTRADAS ### 3.1 🔴 CORS Totalmente Abierto (Producción) **Vector**: Access-Control-Allow-Origin: * **Impacto**: Cualquier sitio web puede leer las respuestas HTTP del servidor **Riesgo**: Medio — permite extraer client.js y omega-worker.js desde cualquier origen **Solución**: Restringir a origen específico o eliminar la cabecera ### 3.2 🟡 CSP con 'unsafe-eval' **Vector**: script-src 'self' blob: 'unsafe-inline' 'unsafe-eval' **Impacto**: Permite ejecución de eval() en el navegador **Riesgo**: Bajo-Medio (depende de XSS en el frontend) **Solución**: Eliminar 'unsafe-eval' del CSP --- ## 4. FORTALEZAS IDENTIFICADAS | Aspecto | Detalle | |---------|---------| | **Protocolo E2EE** | ECDH P-256 + HKDF + AES-256-GCM | | **Autenticación inicial** | RSA-OAEP 4096-bit | | **Derivación de claves** | PBKDF2 600k iteraciones | | **Integridad de código** | SHA-512 del Web Worker | | **Anti-replay** | Contadores secuenciales de mensajes | | **Anti-DoS** | Proof of Work (SHA-256) | | **Anti-análisis** | Frames 4096B fijos + ruido estocástico | | **Memory scrubbing** | TypedArrays sobrescritos post-uso | | **Path traversal** | No vulnerable | | **Inyección JSON** | No vulnerable | | **Buffer overflow** | No vulnerable | | **Connection flood** | Resiliente | | **Info disclosure** | Sin leakage | --- ## 5. DETALLE DE PRUEBAS ### 5.1 HTTP Enumeration | Path | Status | Tamaño | |------|--------|--------| | / | 200 | 4599 bytes | | /index.html | 200 | 4599 bytes | | /client.js | 200 | 12064 bytes | | /omega-worker.js | 200 | 5651 bytes | | Todo lo demás | 404 | - | **Archivos sensibles NO expuestos**: server.js, .env, package.json, .git, config ### 5.2 WebSocket Protocol Attacks (14/14 pruebas pasadas) | Prueba | Resultado | |--------|-----------| | Conexión básica | ✅ | | Handshake inválido | ✅ (rechazado) | | Inyección JSON (9 variantes) | ✅ (rechazadas) | | Frame pequeño | ✅ (timeout) | | Frame vacío | ✅ (sin efecto) | | Frame sobredimensionado | ✅ (sin crash) | | Session reuse | ✅ | | Replay attack | ✅ | | Noise flood | ✅ | | Unicode injection | ✅ | | Buffer overflow | ✅ | ### 5.3 HTTP Security Tests | Prueba | Resultado | |--------|-----------| | Path traversal | ✅ No vulnerable | | HTTP Methods no estándar | ✅ Rechazados | | Null byte injection | ✅ Rechazado | | Range header | 206 (ok) | | CORS: Access-Control-Allow-Origin | **❌ * (corregir)** | --- ## 6. RECOMENDACIONES | Prioridad | Acción | |-----------|--------| | 🔴 Alta | Cambiar Access-Control-Allow-Origin: * a origen específico | | 🟡 Media | Eliminar 'unsafe-eval' del Content-Security-Policy | | 🟢 Baja | Considerar rate-limiting en WebSocket para producción | | 🟢 Baja | Rotar la clave maestra RSA periódicamente | --- ## 7. CONCLUSIÓN El proyecto **Terminal** demuestra un nivel de seguridad adecuado para un desarrollo independiente. El protocolo criptográfico está bien diseñado e implementado, con consideraciones de seguridad avanzadas (PFS, anti-replay, anti-análisis de tráfico, memory scrubbing). **Los hallazgos** fueron dos configuraciones de la capa web (CORS abierto y CSP con 'unsafe-eval'), que fueron corregidas antes del despliegue en producción. *Fin del reporte.*