docs: add basic docs to get started

README.org

@@ -1,18 +1,60 @@
-#+TITLE: Sparse C2 framework
+#+TITLE: Sparse-v2 C2 framework
 
 * Design
-* Goals
-* Setup
-This project uses nix flakes, so make sure to install Nix. [[Building]] is easy to do once Nix is set up, but to set up a development shell a little more work is required; run:
+Sparse v2 is a C2 beacon designed to weaponize libpcap to bypass local host based filtration and auditing. It writes and reads directly from the systems network interface card, creating an alternate TCP/IP stack that does not follow the same rules as the rest of the networking on the host system.
+
+It is designed to take advantage of ideas put forward in this blog post: https://andrew.riouxs.co/articles/20251017-direct-network-access.html
+
+* Developer setup
+This project uses nix flakes. To set up a developer environment, install the Nix package manager (https://nixos.org/download/) and enable Flakes (https://nixos.wiki/wiki/Flakes). With these requirements met, run:
+
 #+BEGIN_SRC sh
 nix develop
 setup-dev-environment
 #+END_SRC
+
 * Building
-Run:
+Building Sparse requires the same developer tooling that a developer shell requires, Nix configured to allow Flakes. To build sparse v2 in its entirety, run:
+
 #+BEGIN_SRC sh
-nix build
+nix build .#sparse-server-docker
+docker load < result
 #+END_SRC
-(this may take ages)
-* Architecture
-[[./architecture.org][Architecture]]
+
+* Listeners, configurations, categories, templates, instances, commands
+These are the abstractions used to represent beacons and the management of beacons deployed on a network.
+- Listeners use a certificate authority and listen on a specific port to allow a beacon to perform callbacks. The port specified must not be changed by any NAT or port forwarding rule, and the IP address must be the public IP address before any NAT
+- Configurations represent how a beacon should perform a callback, whether that is via a specific timetable or only once after executing. Also allows adding random jitter to the callback period
+- Categories are used to sort incoming connections, and when issuing commands can expose a range of targets to apply the command to
+- Templates represent the actual beacon that is to be installed on a system and all the configuration that comes with it
+- Instances are callbacks created by a deployed beacon, and can be issued commands
+- Commands are issued to beacon instances or categories
+
+* Running
+Running sparse will require knowing what ports to use for HTTPS access for the beacons. For the most common use case of port 443, the following Docker compose file should work:
+
+#+BEGIN_SRC yaml
+services:
+  server:
+    image: sparse-server:latest
+    volumes:
+      - ./files:/sparse-server
+    ports:
+      - '443:443'
+      - '3000:3000'
+    restart: always
+#+END_SRC
+
+Once deployed, add the first user with the following command:
+
+#+BEGIN_SRC sh
+docker compose exec server /bin/sparse-server user create -n USERNAME
+#+END_SRC
+
+Once deployed, the management interface is available at port 3000 over HTTP.
+
+** Deploying a beacon
+- Add a listener with a port that matches the port specified in the docker compose and allowed through NAT, and use an IP address that can be routed to this C2 server
+- Add a configuration to perform a periodic callback
+- Add a template, selecting the prior listener and configuration. It will need an IP address that corresponds to the LAN that the beacon will be running on
+- Download the beacon, and install it as a systemd service on Linux. It should be able to perform callbacks, even if blocked locally using iptables. Auditbeat will be unable to detect the beacon performing callbacks

architecture.org

@@ -1 +0,0 @@
-#+TITLE: Sparse Architecture