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 @@ | |||
1 | |||
2 | -[ Design of wellenreiter ]- | ||
3 | |||
4 | written by: Martin J. Muench <mjm@codito.de> | ||
5 | |||
6 | -[ Introduction | ||
7 | |||
8 | This is just a short overview of the new design of wellenreiter. | ||
9 | There will for sure be some changes and most parts will be specified | ||
10 | in more detail. | ||
11 | |||
12 | |||
13 | -[ Program | ||
14 | |||
15 | wellenreiter 1.7 | ||
16 | (will be named 2.0 after all the functions are implemented and the code | ||
17 | is cleaned up and audited) | ||
18 | |||
19 | |||
20 | -[ Short description | ||
21 | |||
22 | Wellenreiter is a wireless sniffing tool like netstumbler, kismet et al. | ||
23 | It discovers Access Points and Ad-Hoc networks and displays all available | ||
24 | information about them so that you can simply join unencrypted network | ||
25 | (without access restrictions) with the given informations. | ||
26 | For the latest version of wellenreiter look at: | ||
27 | http://wellenreiter.sourceforge.net. | ||
28 | |||
29 | |||
30 | -[ Overview | ||
31 | |||
32 | The software is divided into 2 sections, the daemon and the GUI. | ||
33 | The daemon does the active sniffing, analying stuff etc.pp. and | ||
34 | sends the informations to the GUI which displays the results. | ||
35 | |||
36 | |||
37 | -[ Configuration | ||
38 | |||
39 | The configuration is done by both, the GUI and the daemon so that the | ||
40 | GUI only provides the graphical interface to the configuration library | ||
41 | of the daemon. That means that the daemon loads the config file on | ||
42 | startup and sends the informations to the GUI. The GUI contains an option | ||
43 | "configure" where the settings can be changed. They will be sent to the | ||
44 | daemon which actually changes the configuration file. | ||
45 | The configuration file is placed in /usr/local/etc/wellenreiter.conf. | ||
46 | The whole content of this file cannot be specified yet. | ||
47 | |||
48 | OPIE specific: Opie contains a bunch of high-level configuration classes, | ||
49 | which are used by most Opie applications. It should be discussed whether | ||
50 | to use this structure / API (preferred) or use a proprietary one. | ||
51 | |||
52 | |||
53 | -[ Interaction GUI<->daemon | ||
54 | |||
55 | The GUI and the daemon will talk actively with eachother, meaning that | ||
56 | everyside who has informations for the other part will send it and not | ||
57 | wait for the other part to poll. | ||
58 | For example the sniffing function of the daemon is startet when a | ||
59 | "start_sniff" from the GUI arrived. And when the daemon found a network | ||
60 | it will be directly send to the GUI to be able to sniff in realtime. | ||
61 | |||
62 | |||
63 | -[ Communication GUI<->daemon | ||
64 | |||
65 | The GUI and the daemon run as threads within one process, where the GUI | ||
66 | thread will be the main thread. Both the daemon and the GUI thread are | ||
67 | (mostly) "free-running". Once the GUI thread is started and has finished | ||
68 | its initializations, it jumps into the Qt event loop ( QApplication::exec() ). | ||
69 | |||
70 | If the daemon thread is actively working and - | ||
71 | for instance - has acquired interesting data for the GUI thread to display, | ||
72 | it calls a special reentrant method of the GUI thread ( QApplication::postEvent ) | ||
73 | either transmitting the whole data structure or saying "Hey, there's interesting data | ||
74 | for you", which the GUI thread then retrieves. | ||
75 | To enable a free running daemon thread to actually receive messages from the | ||
76 | GUI thread, it's useful to to include a non-blocking check-for-messages-function | ||
77 | within the daemon main loop <since it is waiting for messages from a GUI thread, | ||
78 | this function has not be called very often>. If applicable, the daemon thread must | ||
79 | not call this function but only monitor some guarded variables from time to time | ||
80 | which the GUI thread can modify to alter the behaviour of the daemon thread. | ||
81 | |||
82 | IMHO this is a much more leightweight design than to use a proprietary udp-socket protocol. | ||
83 | |||
84 | |||
85 | -[ Setting card modes | ||
86 | |||
87 | One of the most interesting parts is the switching of the wirelesscards to | ||
88 | different channels, to monitor mode and so on. In the older versions this | ||
89 | actions were done by the calling of external programs, that is now obsolete. | ||
90 | We will use the API of the wireless drivers to set it up. | ||
91 | |||
92 | |||
93 | -[ Sniffing | ||
94 | |||
95 | The sniffing will be done by capturing and analyzing all packets using the | ||
96 | pcap library. The sniffer itself will be a function of the daemon which will | ||
97 | probably be threaded so that this function is non-blocking. | ||
98 | If a packet is found the sniffer sends it to an analyzer function which | ||
99 | analyzes the packets, strips the results and sends it to the GUI. | ||
100 | |||
101 | |||
102 | -[ Logging | ||
103 | |||
104 | The GUI should not need to log that much so it logs to STDERR. The daemon | ||
105 | will be able to run in foreground and log to STDERR and syslog but normally | ||
106 | it will only log to syslog (INFO/ERR). | ||
107 | Logging of found networks, packets and so on will also be done by the daemon | ||
108 | but set up by the GUI. | ||
109 | |||
110 | |||
111 | -[ GPS | ||
112 | |||
113 | The gps daemon software will be used, hopefully by their API if they provide | ||
114 | that. If not, we have to use system() calls, hope we do not. | ||
115 | |||
116 | |||
117 | -[ Security | ||
118 | |||
119 | The programm and the daemon will have to run with SUID privileges for being | ||
120 | able to change card modes etc. so the code has to be audited several times. | ||
121 | Setuid 0 will only be called when really needing the privileges and dropped | ||
122 | directly after every single systemcall. | ||
123 | The daemon will implement an access control list where it specifies which | ||
124 | IPs or network interfaces will have access to it. | ||
125 | The configuration file will be chmod'ed 0400, for writing the configuration | ||
126 | library will change the mode. Of course the file will be locked during | ||
127 | writing so no race conditions can occur. | ||
128 | |||
129 | |||
130 | -[ Documentation | ||
131 | |||
132 | Wellenreiter will have it's own wellenreiter(8) manpage with most parts of | ||
133 | the README file in there. | ||
134 | Also we will provide general documentation about wireless scanning, security | ||
135 | risks with wireless devices and so on. | ||
136 | Most documentation will be intern like this one. The GUI and the daemon | ||
137 | should have a non-technical documentation and a developers version so we | ||
138 | can easily develope with other peoples code without having to read it | ||
139 | completely. | ||
140 | |||