Skip to main content
The AttackWorker interface defines the contract for implementing attack methods. Each attack type (HTTP flood, TCP flood, Slowloris, etc.) implements this interface to integrate with the engine.

Interface Definition

Fire Method

Sends a single attack payload. Called concurrently by the engine for each packet.

Parameters

Return Value

error
Error if the attack failed. Current implementations return nil even on failure to avoid disrupting the attack flow.

Implementation Requirements

Performance Critical: Fire() is called at high frequency (potentially thousands of times per second). It must:
  • Return quickly (typically < 10ms)
  • Not block on I/O - use short timeouts
  • Handle errors gracefully without panicking
The engine dispatches Fire() calls in goroutines, so blocking briefly is acceptable. However, long-running operations should spawn their own goroutines (see Slowloris example).

Built-in Implementations

HTTP Flood Worker

Location: internal/attacks/http/flood.go
Strategy:
  • Sends GET or POST requests with random payloads
  • Prefers POST for larger packet sizes (> 512 bytes)
  • Uses DialedHTTPClient() with proxy support
  • Discards response body to avoid blocking
Code Example:

HTTP Bypass Worker

Location: internal/attacks/http/bypass.go
Strategy:
  • Randomizes request paths and query parameters to evade caching
  • Sets realistic browser headers (Referer, Cookie, etc.)
  • Mimics resource requests (.js, .css, images)
  • Uses DialedMimicHTTPClient() with browser-like behavior
Key Features:
  • 80% GET, 20% POST distribution
  • Random paths like abc123/xyz.js or random.css
  • Cache-busting query parameters
  • Realistic referers (same origin or popular sites)

HTTP Slowloris Worker

Location: internal/attacks/http/slowloris.go
Strategy:
  • Opens raw TCP/TLS connection via SOCKS proxy
  • Sends HTTP headers slowly (one per PacketDelay)
  • Never completes the request to keep connection open
  • Periodically sends keep-alive headers
Code Pattern:
Slowloris returns immediately after spawning the goroutine. The connection lifecycle is managed by the spawned goroutine, which respects ctx.Done().

TCP Flood Worker

Location: internal/attacks/tcp/flood.go
Strategy:
  • Opens raw TCP connection (via SOCKS proxy if available)
  • Sends random bytes (crypto/rand)
  • Sends multiple bursts (1-3) per fire
  • Uses 2-second write deadline
Code Example:

Minecraft Ping Worker

Location: internal/attacks/game/minecraft_ping.go
Strategy:
  • Sends Minecraft protocol handshake packet
  • Follows with status request (packet ID 0x00)
  • Reads partial response to prevent buffer buildup
  • Defaults to port 25565 if no port specified
Protocol Details:

Implementing a Custom Worker

Step 1: Define the Worker Type

Step 2: Implement the Fire Method

Step 3: Register with Engine

Best Practices

  • Return nil on most errors to avoid disrupting the attack flow
  • Only return errors for critical issues (e.g., invalid parameters)
  • Log errors to logCh if verbose mode is enabled
  • Always respect ctx.Done() in long-running operations
  • Pass ctx to all network calls (http.NewRequestWithContext, netutil.DialedTCPClient)
  • Use select statements when spawning goroutines:
  • Check if proxy.Host is empty before using
  • Pass nil to netutil functions if no proxy:
  • Always set reasonable timeouts on network operations
  • Typical values: 3-6 seconds for HTTP, 2-3 seconds for TCP
  • Use SetDeadline, SetReadDeadline, SetWriteDeadline for raw connections
  • Always defer Close() on connections
  • Discard HTTP response bodies to avoid memory leaks:
  • Use SendAttackLogIfVerbose() helper to respect verbose flag
  • Only send logs after successful operations
  • Use non-blocking sends (helper handles this automatically)

Testing Your Worker

See Also