Getting Started
with Sentrava C2

01Requirements

The verified baseline is Linux/amd64. A directory or build target for another platform is not evidence that its complete runtime workflow has been tested.

GOTOOLCHAIN=local go version
gcc --version
node --version
npm --version
command -v chromium
command -v certutil
curl --version

02Installation

Use an authorized checkout of the repository. Repository access may be restricted. Perform builds in an isolated source copy so existing binaries, databases, and credentials remain intact.

1. Inspect the checkout

   Record the revision and working-tree state. Read README.md and PLAYBOOK.md from that same revision.

2. Build the Go components

   Use the required Go version and the committed module files. The Makefile supplies the component-specific CGO settings.

3. Build the optional dashboard

   The server reads frontend files from a configured asset directory. They are not embedded in the server binary.

git rev-parse HEAD
git status --short

GOTOOLCHAIN=local GOFLAGS=-mod=readonly go mod verify
GOTOOLCHAIN=local GOFLAGS=-mod=readonly go build ./...
GOTOOLCHAIN=local make build GO="$(command -v go)"

cd dashboard
npm ci
npm run build

The local server-and-dashboard bundle includes the server and dashboard/dist. Client and agent binaries are separate. A local bundle is not automatically equivalent to a tested GoReleaser release.

03Quick start

An existing installation needs a matching SQLite database and PKI, an explicit asset path, and separate saved settings for the server and operator client. Consult the built binaries for their exact setup flags.

./bin/sentrava-server --help
./bin/sentrava-client configure-local --help
./bin/sentrava-client --help

The setting order is explicit flag → saved configuration → safe default. Saved paths are absolute. The usual user configuration files are ~/.config/sentrava/server.json and ~/.config/sentrava/client.json, or their equivalents under XDG_CONFIG_HOME.

# Terminal one
./bin/sentrava-server

# Terminal two
./bin/sentrava-client

Saved settings can override these addresses. Check the effective configuration and occupied ports before startup. Stop only processes that belong to your test.

04First session: verify the test boundary

A session requires a recognized certificate, matching AgentID and OperationID, an eligible enrollment, and the applicable operation policy. A trusted CA signature alone does not authorize an unknown agent.

Use the repository’s isolated tests to inspect the lifecycle. The administrative subprocess test covers server/client administration. The tagged mTLS E2E uses an in-process agent model; it is not a real agent subprocess.

GOTOOLCHAIN=local go test \
  -run '^TestAdministrativeSetupThroughCLIAndHTTPS$' \
  -count=1 -timeout=120s ./tests/integration

GOTOOLCHAIN=local go test \
  -tags=e2e -count=1 -timeout=120s ./tests/e2e/...

Additional subprocess coverage is described under Verification. A result is evidence only for the exact scenario and revision that were executed.

Transports

mTLS Supported

The supported runtime path uses mutual TLS and a server-side enrollment record. Check-in and task authorization bind the certificate fingerprint, AgentID, operation, and the applicable target policy. Revocation and operation closure prevent further authorized access.

TCP Disabled

Retained TCP implementation code is not an enabled agent listener in the supported MVP. A transport must preserve enrollment and result ownership guarantees before it can be advertised as available.

HTTP + profiles Disabled / experimental

HTTP transport and profile material remain in the repository, but profiles do not establish a supported HTTP agent workflow. DNS agent listeners are also disabled. The dashboard’s HTTPS API is a separate administrative interface.

OPSEC

Modules

• Sleep masking and memory-related research.
• Process canary checks.
• TLS fingerprint validation.
• Environment guardrails.
• Polymorphic configuration handling.

Presets

Preset definitions and CLI behavior can change independently of the verified enrollment workflow. Read the help for the exact built revision; a preset name is not evidence that a protection is enabled or effective.

Capabilities

Shell

The current tree contains interactive shell work. Fixed-command task tests do not establish complete PTY behavior, resize handling, cancellation, or Windows ConPTY compatibility. Treat these as separate verification items.

Port forwarding

A verified end-to-end TCP tunnel is not claimed by this documentation. A CLI label, interface, or planned feature does not demonstrate a working forwarding path.

File operations

Capability code and task types must be evaluated against their public interfaces, permission checks, and dedicated tests. General lifecycle coverage does not prove every upload, download, path, or error case.

Process list

Process-related capability implementations exist. Validate their output and platform behavior with the corresponding tests rather than inferring support from the capability directory.

Dashboard

The dashboard is an optional frontend to the same server. Disabling its HTTPS listener leaves the administrative gRPC interface available. Production files must exist in the configured dashboard/dist directory.

Web sessions use an opaque, secure, HttpOnly cookie. The server rechecks current permissions, disabled state, and revocation. Mutations require CSRF protection. Restarting the server invalidates in-memory web sessions.

Listeners

A displayed listener record is not proof that a socket is accepting traffic. Confirm runtime status separately. Starting a listener does not enroll or activate an agent.

Agents

Enrollment state and session state represent different things. A prepared record is not an authorized live session, and a reported hostname is not physical-device attestation.

Sessions

Review sessions, tasks, and operations within the current operator role. A rendered button cannot grant permission that the server denies.

Reference

CLI commands

Inspect the exact binary’s help. Server/client local configuration, operations, scope, and enrollment administration are separate command groups. Never assume an older binary on PATH matches the current source tree.

./bin/sentrava-client --help
./bin/sentrava-client operations --help
./bin/sentrava-client agents --help
./bin/sentrava-client generate --help

Generate options and policy

Local generation packages an existing stock Linux/amd64 mTLS binary with separate configuration and unique credentials. It is not the disabled remote generator.

Identity-bound access is disabled by default for new and migrated operations. Without the explicit policy, targetless generation must fail before credentials are issued. Hostname remains display metadata in that mode and never expands an allowlist.

API reference

Administrative gRPC definitions are maintained in proto/rpc.proto and related protobuf files. HTTPS handlers apply the server’s route and permission policy. GET /api/health is public and minimal.

Remote GenerateImplant remains unavailable; the authenticated remote builds creation route is disabled. Do not infer API availability from a generated client method alone.

Verification

Use temporary SQLite, PKI, state directories, and loopback addresses. Inspect test setup before execution. Do not point test code at a working installation.

Durable result recovery and result deduplication do not prove that a task executes exactly once. Termination before result persistence remains a distinct failure window.

About this documentation

Sentrava C2 is a team-built security framework. These pages distinguish the supported administrative MVP from experimental code and historical plans.

For revision-specific evidence, review README.md, PLAYBOOK.md, DEFENSE.md, and the tests in the same checkout. Treat projects/PLAN.md as a historical plan, not a release checklist.