hash-dude

Images

• itytophile/hash-slave The slave which cracks the hashes.
• itytophile/hash-server The server which shares equally the ranges to each slave to crack a hash. It offers an UI at http://localhost:3000
• itytophile/monitor The monitor which observes the server's request queue. It asks docker to scale the slave service replicas.

Why is the slave linked to glibc ?

glibc is harder to deal with when we do static linking however it is much faster than musl (the binary is bigger though).

Code

• src/main.rs The server.
• src/server/to_dude.rs The task that manages dudes.
• src/server/to_slave.rs The task that manages slaves.
• src/slave.rs The slave.
• src/monitor.rs The monitor.
• src/alphabet.rs Functions that help us to generate words to crack hashes.

Run the server

cargo run
# or cargo run -- --help

--release is good but not necessary.

Run the slave

cargo run --release --bin slave
# or cargo run --release --bin slave -- --help

We add the --release to make the slave fast.

Build the docker images

Before building:

cargo vendor

Then:

docker build -f docker/Dockerfile.slave -t itytophile/hash-slave .

docker build -f docker/Dockerfile.server -t itytophile/hash-server .

Why other Dockerfiles for CI?

Because using cargo vendor within a runner is not easy. The CI has to update crates.io index for each build.

Monitoring

Initialize the swarm:

docker swarm init

After creating the swarm:

docker stack deploy --compose-file docker-compose.yml stackhash

To delete the stack:

docker stack rm stackhash