Diffstat (limited to 'noncore/net/wellenreiter/docs/specification') (more/less context) (ignore whitespace changes)
| -rw-r--r-- | noncore/net/wellenreiter/docs/specification | 140 |
1 files changed, 0 insertions, 140 deletions
diff --git a/noncore/net/wellenreiter/docs/specification b/noncore/net/wellenreiter/docs/specification deleted file mode 100644 index 0766ef4..0000000 --- a/noncore/net/wellenreiter/docs/specification +++ b/dev/null @@ -1,140 +0,0 @@ - --[ Design of wellenreiter ]- - -written by: Martin J. Muench <mjm@codito.de> - --[ Introduction - -This is just a short overview of the new design of wellenreiter. -There will for sure be some changes and most parts will be specified -in more detail. - - --[ Program - -wellenreiter 1.7 -(will be named 2.0 after all the functions are implemented and the code -is cleaned up and audited) - - --[ Short description - -Wellenreiter is a wireless sniffing tool like netstumbler, kismet et al. -It discovers Access Points and Ad-Hoc networks and displays all available -information about them so that you can simply join unencrypted network -(without access restrictions) with the given informations. -For the latest version of wellenreiter look at: -http://wellenreiter.sourceforge.net. - - --[ Overview - -The software is divided into 2 sections, the daemon and the GUI. -The daemon does the active sniffing, analying stuff etc.pp. and -sends the informations to the GUI which displays the results. - - --[ Configuration - -The configuration is done by both, the GUI and the daemon so that the -GUI only provides the graphical interface to the configuration library -of the daemon. That means that the daemon loads the config file on -startup and sends the informations to the GUI. The GUI contains an option -"configure" where the settings can be changed. They will be sent to the -daemon which actually changes the configuration file. -The configuration file is placed in /usr/local/etc/wellenreiter.conf. -The whole content of this file cannot be specified yet. - -OPIE specific: Opie contains a bunch of high-level configuration classes, -which are used by most Opie applications. It should be discussed whether -to use this structure / API (preferred) or use a proprietary one. - - --[ Interaction GUI<->daemon - -The GUI and the daemon will talk actively with eachother, meaning that -everyside who has informations for the other part will send it and not -wait for the other part to poll. -For example the sniffing function of the daemon is startet when a -"start_sniff" from the GUI arrived. And when the daemon found a network -it will be directly send to the GUI to be able to sniff in realtime. - - --[ Communication GUI<->daemon - -The GUI and the daemon run as threads within one process, where the GUI -thread will be the main thread. Both the daemon and the GUI thread are -(mostly) "free-running". Once the GUI thread is started and has finished -its initializations, it jumps into the Qt event loop ( QApplication::exec() ). - -If the daemon thread is actively working and - -for instance - has acquired interesting data for the GUI thread to display, -it calls a special reentrant method of the GUI thread ( QApplication::postEvent ) -either transmitting the whole data structure or saying "Hey, there's interesting data -for you", which the GUI thread then retrieves. -To enable a free running daemon thread to actually receive messages from the -GUI thread, it's useful to to include a non-blocking check-for-messages-function -within the daemon main loop <since it is waiting for messages from a GUI thread, -this function has not be called very often>. If applicable, the daemon thread must -not call this function but only monitor some guarded variables from time to time -which the GUI thread can modify to alter the behaviour of the daemon thread. - -IMHO this is a much more leightweight design than to use a proprietary udp-socket protocol. - - --[ Setting card modes - -One of the most interesting parts is the switching of the wirelesscards to -different channels, to monitor mode and so on. In the older versions this -actions were done by the calling of external programs, that is now obsolete. -We will use the API of the wireless drivers to set it up. - - --[ Sniffing - -The sniffing will be done by capturing and analyzing all packets using the -pcap library. The sniffer itself will be a function of the daemon which will -probably be threaded so that this function is non-blocking. -If a packet is found the sniffer sends it to an analyzer function which -analyzes the packets, strips the results and sends it to the GUI. - - --[ Logging - -The GUI should not need to log that much so it logs to STDERR. The daemon -will be able to run in foreground and log to STDERR and syslog but normally -it will only log to syslog (INFO/ERR). -Logging of found networks, packets and so on will also be done by the daemon -but set up by the GUI. - - --[ GPS - -The gps daemon software will be used, hopefully by their API if they provide -that. If not, we have to use system() calls, hope we do not. - - --[ Security - -The programm and the daemon will have to run with SUID privileges for being -able to change card modes etc. so the code has to be audited several times. -Setuid 0 will only be called when really needing the privileges and dropped -directly after every single systemcall. -The daemon will implement an access control list where it specifies which -IPs or network interfaces will have access to it. -The configuration file will be chmod'ed 0400, for writing the configuration -library will change the mode. Of course the file will be locked during -writing so no race conditions can occur. - - --[ Documentation - -Wellenreiter will have it's own wellenreiter(8) manpage with most parts of -the README file in there. -Also we will provide general documentation about wireless scanning, security -risks with wireless devices and so on. -Most documentation will be intern like this one. The GUI and the daemon -should have a non-technical documentation and a developers version so we -can easily develope with other peoples code without having to read it -completely. - |