removed some uneeded argument definitions, and updated the readme

README.md

@@ -8,8 +8,20 @@ This is really meant to be used once you have initial access to a machine during
 
 Rust already seems to get around EDR/AV pretty easily, but I do also intend to add some evasion features later on.
 
+# Usage
+Download the release binary from the release section, or clone this repository and build it with cargo. On first run it will check for a config file in ~/.config/tetanus, if none exist it will prompt for install. During install it will clone this repository and copy the various files needed into ~/.config/tetanus. After first run give it the -c flag to run it in client mode, and the -s flag to run it in server mode. Running in both modes with the same command is not supported at the moment, but I plan to implement that at a later time. If you need to run both the client and the server spawn each in a seperate terminal.
+
+Modules are loaded at launch time. If you write a new module and want to load it there is a reload_modules command for this.
+
+Other command flag options are:
+- -p port number to run the server on
+- -i the ip address to run the server on
+- -P the password to set for the server
+- -C a path to a custom config file
+- -n the name to set for the client or server (will be reported to the other servers/clients)
+
 # Design considerations
-Clients and the server will be wirtten in rust. The core modules will all be written in rust. I intend to design a system that will allow custom modules to be written in dotnet, python, powershell, and rust.
+Clients and the server will be wirtten in rust. The core modules will all be written in rust. Plugins are written in RHAI script (javascript like).
 
 The server will keep the states of all clients, projects, and notes. The clients will interact with the server. Each client will have it's own handler thread. I intend to manage the threads with either Tokio or some sort of agent system. MPSC channels will be utilized to talk to all threads. 
 
@@ -26,4 +38,55 @@ I plan to document how to properly write the network communications so that user
 This repo will be empty for a bit while I get the initial client/server communications working.
 
 # WIP
-This is very much a work in progress. Nothing works yet. If you want the original tool, head over to my pyro pentest tool repository and clone the stable branch.
+This is very much a work in progress. The current status of features is shown below.
+
+## Working
+- project life time management (creation, promotion, and removal)
+- distrobox management (creation on promotion, destruction on removal)
+- TUI interface (might add enhancements later)
+- relay style server
+- client/server communications via beacon style TCP connections
+- TLS Encryption for network communications
+
+## Working but needs review and testing
+- password based authentication between client and server (DO NOT USE ON THE OPEN INTERNET UNTIL THIS IS TESTED!)
+- re-authentication easy checkin
+- basic obfuscation compile time techniques (mostly just stripping debug symbols)
+
+## Planned but not implemented yet
+- string mangling for the victim client
+- upload/download files for the victim client
+- staging HTTP server to serve the binaries
+- in memory execution of tools for the victim client
+- portscan automation for attacker and victim client
+- SOCKs5 proxy functionality for the client
+- more victim automation
+  - Kerberos ticket exfil
+  - initial enum commands
+  - file system searching
+  - bloodhound (maybe)
+  - interactive shell
+- more attacker client automation
+  - dns and directory bruteforcing
+  - attack automation (common basic exploits like ftp anonymous login, smb attack automation, etc..)
+- Microsoft Online integration
+  - get scope from sharepoint file
+  - upload password protected zip file for the project on completion
+
+# Writing custom modules
+Modules at the moment are written in RHAI script (javascript like). Each module should be stored in it's own directory, the directory structure should be as follows:
+
+module directory
+ - config.conf 
+  - contains the following information
+  - name: {name} - the command that calls this module
+  - output_type: {type} - the type that is returned to tetauns (string should be your default).
+  - new_thread: {bool} - whether this should run on a new thread or not.
+  - args: {argument1},{argument2} - the arugments the module needs from tetanus to do its job.
+  - calls: {command name or none} - if this scirpt calls another command to do more stuff after it's completion.
+ - help.txt
+  - contains the text for the help message for this command.
+ - script.rhai
+  - the actual script itself.
+
+Once a module is written the entire directory should be placed in your tetanus_config/modules/custom directory to load them into the tool. A few default modules are provided as examples in the tetanus_config/modules/default directory.