by vampyr » Tue May 19, 2009 8:00 am
About controlling cheating, Lets go the slightly botnet-ish approach shall we?
About the network, the tracker keeps track of uptime of the peers.
Once in a while (1-2 hours) the tracker promotes random nodes to supernodes. Every previous supernode will no longer be a supernode.
These supernodes are marked in the peer list. ONLY SUPERNODES can send work to nodes. Nodes request work from their nearest supernode.
This allows for grouping of hashes etc. Nodes reply back to the supernode with a result, supernode checks it, if neccasary updates the tracker with cheaters,
and sends the result back to the client requesting the cracking of the hashes.
There's a few things we'd need for this to be successful tho.
--A SIMPLE API, in essence we only require 3 api calls.
@@-ProcessWork(work)
@@-AcceptingWork(workType)
@@-NumberOfDevices(workType)
this would make it easy for anyone to extend the cracker with their own algorithms.
--a GUI (yea i know that sounds shitty to code, and it IS, but we're going to need a GUI coder, or at least a simple interface)
--some algorithms to start with (i think that's sorted already)
--a network architecture (c++) --Someone's going to be coding this (And i wouldn't mind doing so)
--a tracker architecture (LAMP)-- Yep, thats right, trackers. (And if you want SQLi bugs, yeah you should probably ask me to do this;) )
So essentially we'd need 2-3 coders for this. It's a BIG project tho, so we'll first have to see which code we can borrow (libraries;) )
The GUI could probably be made in c#, as long as the extensions are in c.
The network architecture could be added as an extension itself, plus speed is kind of essential, so i recommend c++ (c# would probably do too).
Tracker's by far the easiest, nothing special about it.
[edit]Also, a massively distributed cracker like this would make rainbow tables practically obsolete. [/edit]