Platform Architecture
The v4.0.4 Classic Electron + Python and bridge-free Electron + Go runtime layers.
Platform Architecture
WSHawk v4.0.4 has two desktop runtime paths.
Desktop Runtime Paths
| Edition | Runtime path | |---|---| | Classic | Sandboxed Electron renderer -> Electron main -> local Python project services | | Electron + Go | Sandboxed Electron renderer -> allowlisted IPC -> Electron main -> private stdio JSON-RPC -> Go worker |
The Electron + Go worker does not expose a localhost HTTP or Socket.IO bridge.
Main Layers
| Layer | Purpose | |---|---| | Desktop | Electron operator interface for either edition | | Bridge / Daemon | local HTTP and Socket.IO service layer | | Transport | HTTP and WebSocket proxying and traffic capture | | Session | browser capture, replay helpers, identity handling | | Attacks | replay, AuthZ diff, race, and related services | | Protocol | graphing, inference, templates, target packs | | Store | project-backed local persistence | | Evidence | bundles, timeline, export, integrity metadata | | Validation | local benchmark labs and expected outcomes |
Electron + Go adds encrypted project storage, bounded scanners, authorization policies, findings, reports, and WebSocket transports inside its private worker. Playwright remains isolated in the Electron main process for browser evidence and authentication recording.
Route Groups
The daemon is split into route groups so workflow responsibilities stay clearer:
- platform routes
- transport routes
- system routes
- scan routes
- web routes
CLI Compatibility
The top-level CLI still exists. Classic uses the local Python daemon and project services; Electron + Go uses its private worker and direct IPC path.