← THE SRAOSHA SYSTEMMAINELY CODE / THE ADVERSARIAL COUNTERPART

DJINN-SRAOSHA

PENTESTING / KALI CONTROL MODE

See the exposure.
Prove the risk.
Restore the balance.

An engagement, not a terminal. A proposed control mode that brings intent, scope, selected Kali workflows and inspectable evidence into one Windows-facing experience.

IN DEVELOPMENT / CONTROL EXPERIENCE PROPOSED
Approved DJINN-SRAOSHA emblem: dark shield, scales and eye, warm red accents on black.
WINDOWSWSLKALI LINUXOWNER-DIRECTED
THE OWNER’S VISION / WSL ON WINDOWS
What’s better than a little Blue Team vs. Red Team security exercise with Kali Linux?
Automating the hell out of it through WSL on Windows.

The intended loop is repeatable: baseline, challenge, evidence, harden, retest. Budgets, scheduling, pause/resume and drift-triggered checks—not blind command loops.

Blueprint · p. 18
INTERACTIVE CONCEPT / NO LIVE CONNECTION

A visible perimeter.
A living mission.

Explore the proposed engagement lifecycle. Switch the lens or review a stage. Nothing executes, no approval is granted, and no targets are contacted.

Interface and lifecycle · pp. 19–22
DJINN-SRAOSHA MISSION CONTROLILLUSTRATIVE / SYNTHETIC LAB
SCOPELOCAL-LAB-A
AUTHORITYAWAITING OWNER
RUNTIMENOT CONNECTED
STATEPLAN ONLY
01 / DEFINE

Make the boundary explicit.

Record assets, authorization, objectives, exclusions, the testing window, allowed techniques and recovery contacts.

ADVERSARIAL FOCUS

Use the approved snapshot to define the engagement scope. A discovered asset is not automatically an authorized target.

Browser-only walkthrough. No operation executed.
Proudly Built with Mainely Code Buildroom—ADVANCED EDITION
PROPOSED EXECUTION ARCHITECTURE

Kali is the environment.
You stay in command.

Six distinct responsibilities between a goal and an outcome. Intelligence proposes the work; deterministic policy and execution boundaries decide what is permitted.

Blueprint · p. 20
01Mission shell

The objective, visible.

Captures the authorized objective and displays the proposed plan, evidence and approval state.

02Scope broker

Authority, checked.

Checks the exact action, environment, asset scope, time window, risk class and remaining budget.

03Execution adapter

Typed operations.

Builds argument lists from reviewed templates. Model-generated shell strings are not the default execution path.

04Isolated worker

A deliberate environment.

Runs a pinned tool with restricted mounts, credentials and network paths in an explicitly provisioned runtime.

05Result normalizer

Evidence, not noise.

Retains raw artifacts and separates tool failure, parsing ambiguity and evidence gaps.

06Verifier & receipt

A defensible outcome.

Corroborates conclusions and binds limitations and results to the authorized plan and execution record.

ENVIRONMENT POLICY

A dedicated Kali WSL 2 profile is the proposed everyday lane. Mounts, Windows interoperability, network reachability, privileges and resources need explicit inspection and acceptance evidence. Higher-risk or hostile-code jobs belong in a separately hardened, tested VM—or remain unavailable.

WSL installation alone is not a blanket isolation guarantee.
SELECTION OVER SPRAWL

From visibility
to verified resilience.

A capability ladder, not a claim to support every Kali tool. Prove a small tool set first. Expand when the next adapter produces a useful end-to-end outcome.

Blueprint · p. 21
D01

Observe

Review supplied logs, configurations, artifacts and existing inventories. Artifact-only work need not contact a target.

D02

Discover

Bounded service and asset discovery within an explicit scope. New discoveries do not automatically expand authorization.

D03

Assess

Selected application, host, identity and network controls, with declared versions, privileges and expected impact.

D04

Validate

Corroborate a suspected weakness through separately approved, bounded methods and a recovery plan.

D05

Investigate

Correlate events, organize evidence and explain uncertainty without treating one alert as a confirmed compromise.

D06

Guardian fix

Hand verified findings to SRAOSHA for a reviewed, reversible hardening plan and separate change approval.

D07

Retest

Repeat the relevant controlled checks. Close the finding only when the defined retest supports closure.

POWER WITH AN INSPECTABLE BOUNDARY

The strongest demo
is a controlled stop.

Dual-use by nature; operator-directed in practice. The name is not a moral guarantee. Targets, consequences, authority and evidence remain visible in the engineering contract.

Source status: the supplied review reports Kali catalog, WSL inventory and planning—not live target execution.

Assurance requirements · p. 23
Changed scope

Changed addresses, redirects and new hosts outside the sealed scope must be blocked and recorded—not silently admitted.

Expired or revoked authority

No new work should dispatch. Active-worker containment must be attempted and measured; a stop cannot undo packets already sent.

Missing or altered evidence

The finding stays unverified. Missing artifacts, parser failures and changed data are not replaced with a plausible narrative.

Interrupted runtime

End the job truthfully, preserve evidence and quarantine the environment when a worker crashes, stalls or loses connection.

TWO LENSES / ONE INTELLIGENCE

SRAOSHA hardens.
DJINN challenges.
Evidence closes the loop.

PROJECT PREVIEWProudly Built with Mainely Code Buildroom—ADVANCED EDITION