distributed (?) programmable brute force harness
Go to file
xenia 280979a479 implement some of the client 2020-12-28 03:41:33 -05:00
agent-deployment fix exported symbol in agent 2020-12-26 03:02:07 -05:00
crossfire implement some of the client 2020-12-28 03:41:33 -05:00
etc another pointless yak shave: autodetect hostname 2020-12-26 03:55:16 -05:00
.envrc implement basic project support 2020-11-16 20:17:42 -05:00
.gitignore implement embedding config params in agent binary 2020-11-15 19:46:29 -05:00
COPYING change gpl to agpl 2020-10-25 02:54:51 -04:00
LICENSE add gpl 2020-10-25 02:53:08 -04:00
Makefile update agent embedding system 2020-11-15 02:28:09 -05:00
README.md begin implementing CLI client 2020-12-27 03:13:43 -05:00
license.template get equipped with: obnoxious 2020-11-07 16:42:43 -05:00

README.md

crossfire

distributed brute force infrastructure

takes the difficulty out of creating custom brute force jobs

status

base

  • 🚧 input space manipulation functions
    • data types: using data/integer-set, pattern (vector of integer-set)
    • basic manipulation functions
    • representation of input space as a flat integer
  • 🚧 #lang for configuration/definitions
    • (input) mode
      • stdio: user program gets input by stdio, integers separated by space, one per line
      • callback: input generator compiled into user program, user main calls crossfire_main with callback function that returns true or false
      • other modes??
    • SMP: performed by crossfire or performed by the user code
      • "performed by user code" can also mean GPU, for example
  • 🚧 codegen for input generator (in C)
    • stdio mode
    • 🚧 callback mode
    • success reporting mechanism
    • low priority: configurable "character" type -- currently a "character" is a uint64_t

server: distribute jobs to workers

  • base definitions of input classes and how to divide them
  • dynamic slicing and scheduling based on agents' reported work rate
  • low priority: randomized input space distribution
  • low priority: store common configuration templates for clients
  • low priority: track upload/download progress
  • streaming interface for file transfers
  • accept submitted projects (with client-compiled input generator) and distribute to agents
    • low priority: support for multiple architectures
  • agent authentication
  • client authentication

agent: accept and run jobs

  • securely connect to server
  • retrieve assigned tasks
  • handle smp correctly
  • report completions
  • 🚧 report errors
  • report successes
  • low priority: defer to external brute force program (eg, hashcat on GPU)
    • this could be implemented on top of the existing project format
  • low priority: support finding all matching inputs for a project, rather than just the first one
    • the architecture currently doesn't stop on the first match so it could be a thing

client: submit jobs and view progress

  • securely connect to server
  • command line interface
    • crossfire new: create new crossfire project
    • crossfire test: test project locally, replicates configuration of server with single local agent to debug issues
    • low priority: crossfire node-test: submit a mini-task to a node that has the necessary resources to debug issues
    • crossfire submit: submit task to server
    • crossfire cancel: cancels submitted task
    • crossfire status: check status of task (or network as a whole)
  • low priority: gui interface (racket/gui & framework time)

misc

porting

currently only linux is supported for the server and agent. the server might run on macOS but it's not guaranteed. if you are interested in porting this to a new platform, take a look at agent-deployment for the embedded build of racket for the all-in-one agent binary, and perhaps create additional makefiles for other platforms. additionally, platform-specific racket code is marked with an XXX comment