1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
|
-[ 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.
|
