|
|
Copyright Michael Cowan 2002
All Rights Reserved
|
|
|
Structure |
The structure of WebWalker starts with the GUI. The GUI is responsible for the creation of a thread for each function type (Leech, Crack etc). These threads are the control threads.
The control threads are firstly responsible for loading, resolving and preparing any common data. By common data I mean data that does not change between attempts (eg when cracking the target does not change).
They are also responsible for controlling the thread pool. The thread pool is an array of thread pointers which carry out the work. These are called worker threads.
The control thread, once all data has been prepared, creates the pool and gives each of the worker threads work and a copy of the common data. Once all threads are busy it sleeps for one second. It then goes throught the worker threads checking to see if they are idle. If they are work is distributed, other wise the next one is checked. This continues untill either there is no more data to distribute, the stop button is pressed or a kill signal is received.
The worker threads can send signals to the GUI. This is how the results are displayed when the worker thread completes. A kill signal can be sent from a worker thread to indicate that an external error has occured. This is the same as pressing the Stop button. When the stop button is pressed, the control thread stops creating and checking the worker threads. This does not however mean that all work is stopped. Any currently running worker threads will continue to do so until they complete.
|
|
Function |
The GUI class creates an instance of each of the functions (Leech, Crack etc). These instances are used throughout, until the program is closed. When play is pressed, the appropriate class instance is given pointers to the entered data (targets etc). Included in this is a pointer to a receiver, which is used to send event signals back to the GUI thread. Next the run() function is called to execute the controller thread.
The controller thread starts by declaring the worker thread pool. Then starts gathering common data. Firstly it resolves the network library then the plugins functions. Then it loads any files into buffers before calling network socklib_initialise() and plugin entry_whatever_init(). Now the controller thread enters a while(1) loop which checks the worker threads.
It starts by checking to see if any process buttons (eg, Stop, Pause etc) have been pressed. The process buttons simply change the state of a class BOOL variable. Secondly it checks each of the worker threads to see if there idle. Any idle thread is given work and started. Once they are all checked the loop sleeps for one second before starting again.
When the while(1) loop is exited (for whatever reason) the controller thread waits for the worker threads to complete. The plugin entry_whatever_kill() function is called followed by the network libriaries socklib_destroy(). Then all memory is free'd before terminating the thread.
The worker threads enter a loop too, which can only be exited by either completing or an external error where execution cannot continue. This loops gets any thread specific data (eg the next proxy) and calls the plugin entry point. The return code is analysed and either cause the loop to continue (failure) or exits and reports the results before freeing any memory (sucess).
|
|
|
