summaryrefslogtreecommitdiffstats
path: root/Tex/Content/Detection.tex
blob: 0ffa67a9ebe41d09012047b448f9c581c13783f1 (plain) (blame)
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
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
\chapter{IMSI Catcher Detection System}

This chapter will give outline the \gls{icds} and the technologies and techniques used.
The first part summarises the frameworks and hardware upon which the system has been developed.
From this point on the second part explains how this framework can be used to harvest information and describes the process that is used by the \gls{icds} to evaluate this information.
The last part shows how to configure and use the system to gather information from the surroundings and unveil IMSI catchers.

\section{Framework and Hardware}
The following section will give an overview of the OsmocomBB framework and how it works in conjunction with the Motorola C123 mobile phone to enable information harvesting for the \gls{icds}.
OsmocomBB is one of many \gls{osmo} projects\footnote{Osmocom, \url{http://osmocom.org/} [Online; Accessed 04.2012]}. It delivers an open source implementation for the base band chip for certain mobile phones.
Another \gls{osmo} project is OpenBTS which delivers software for configuring and operating a \gls{bts}.
OpenBTS was used to realise the open source IMSI Catcher \cite{dennis} and the base station that will be used later to evaluate the performance of the \gls{icds}.

\subsection{OsmocomBB}
OscmocomBB implements the baseband part of \gls{gsm} as an open source project.
Baseband part in this case means that it is an open source software to control the baseband chip inside the mobile phone.
The baseband chip is the processor that manages the radio functionality of a mobile device.
The goal is to have a phone, when using compatible hardware, operating on open source software only as opposed to proprietary baseband implementations.
Therefore the project scope is implementing \gls{gsm} Layer 1--3 as well as hardware drivers for the baseband chipset.
A simple user interface on the phone is planned but not yet implemented.
At this stage a verbose user interface on the computer is used.
The implementation being open source is beneficial to multiple areas \cite{osmo_rationale}:
\begin{itemize}
	\item \textbf{Security:} The software running on the baseband chips is highly proprietary and closed.
	The source is often disclosed only to the mobile phone manufacturers using the specific chipset.
	One cannot be sure that this software does not have bugs that could be exploited and ultimately pose a security risk to the subscriber.
	\item \textbf{Education:} Currently knowledge about \gls{gsm} and its layers on a technical level is not very well spread.
	An open source implementation as a reference could serve to educate more developers generally interested in the subject of mobile communications and thus improve products and software.
	Additionally this implementation enables universities to hold practical lab courses and interested individuals to do hands-on experiments.
	\item \textbf{Research:} A free implementation can decouple research on \gls{gsm} technologies from the industry since key technologies are no longer only available to researchers employed by a specific company.
	Additionally this way security holes can be uncovered and fixed more easily.
	Modifications to the protocol stack can be deployed and tested in a real environment.
	It is also possible to redirect all received and sent packages directly to Wireshark\footnote{Wireshark, \url{http://www.wireshark.org/} [Online; Accessed 04.2012]} for further analysis.
\end{itemize}

\subsubsection{Project Status}
At this point Layer 2 and Layer 3 do not actually run on the phone but rather on a computer to which the phone is connected via a serial cable.
Layer 1 runs inside the custom firmware on the \gls{me} itself, since the procedures involving Layer 1 are time critical.
This has advantages as well as disadvantages.
The disadvantage is that in order to run an application written using OsmocomBB you always have to have a computer in addition to the phone.
The benefit however is that during the development process, the phone does not have to be touched after an initial deployment of the firmware.
This means code can be modified, compiled and tested locally without the need of remote debugging.
Experimenting is considerably easier this way.
This separation however would not work in the original \gls{gsm} specification, therefore an extra interface layer between Layer 1 and 2 had to be implemented to handle messaging over the serial interface between the two original layers.
It is called Layer 1 Control, L1CTL.

The current state of the project is, according to a presentation given on the 27$^\text{th}$ chaos communication congress\footnote{27C3 public wiki (Day 3), \url{http://events.ccc.de/congress/2010/wiki/Welcome} [Online; Accessed 04.2012]} by Dieter Spaar and Harald Welte, that the network Layers 1--3 are fully implemented, SIM cards can be accessed or emulated and \gls{gsm} cell selection and reselection are working.
A3/A8 as well as A5/1 and A/52, Full Rate and Enhanced Full Rate codecs are there, so it is possible to do voice calls with an OsmocomBB application written for that purpose, called \texttt{mobile}.
It features a terminal\,/\,telnet based interface much like Cisco routers however there is no user interface for the phone so far.

\subsection{Motorola C123}
\label{sec:osmo_phones}
Since the general idea behind OsmocomBB was to become a vendor independent open source \gls{gsm} implementation for everyone to use, there were certain requirements the targeted hardware would have to meet.
For the consumer side requirements these were having a low price and a good availability.
This criterion rules out \gls{diy} approaches since the number of produced devices would be low and thus costly or a significant technical knowledge would be expected from all users to assemble the hardware.
For the developer side this would also mean implementing a lot on the lower levels of analog logic.
Therefore the Motorola C123 was chosen, an old, very cheap phone that is well spread.
It has the advantage of being very simple on the hardware side and very well documented since the technical documentation for the Texas Instruments Calypso Chipset \cite{osmo_slides} has been leaked.
Table \ref{tab:c123_specs} shows an overview of the main specifications for the phone.
\begin{table}
\centering
	\begin{tabular}{ll}
	\toprule
	Component			&Specification\\
	\midrule
	Band 				&GSM 900, GSM 1800\\
	Size				&$101\times 45\times 21$ mm\\
	Weight				&86 g\\
	Battery				&920mAh Li-Ion battery\\
	Digital Baseband	&Texas Instruments Calypso\\
	Analog Basenand		&Texas Instruments Iota TWL3025\\
	GSM Transceiver		&Texas Instruments Rita TRF6151C\\
	\bottomrule
	\end{tabular}
	\caption{Technical specifications for the Motorola C123.}
	\label{tab:c123_specs}
\end{table}
The OsmocomBB framework should work well or with small adjustments for any phone that is based on the same components.
Figure \ref{fig:osmo_c123} shows an image of the Motorola C123 circuit board with the components mentioned before.
\begin{figure}
\centering
	\includegraphics[width=.9\textwidth]{../Images/c123_pcb}
	\caption{Circuit board of the Motorola C123 with its components \cite{osmo_wiki_c123}.}
	\label{fig:osmo_c123}
\end{figure}
Another reason for choosing this hardware platform was that during the start of the OsmocomBB project an open source implementation of \gls{gsm} Layer 1 was already available on Sourceforge (TSM30 Project) that could be used as a reference. 
At this point the original project has been removed from the Sourceforge site.

In order to use the Motorola C123 in combination with the OsmocomBB framework the custom firmware implementing Layer 1 and L1CTL has to be flashed onto the board.
This has to be done using a RS332 serial cable that is connected to the 2.5\,mm audio jack.
The audio jack of the Motorola C123 and other Calypso based mobile phones typically have a 3.3 V serial port on their audio jacks.
These cables are normally referred to as T191 unlock cables.
A variety of stores around the internet sell the cables ready made for about \$10--\$15.
One must be careful when using the PC's serial port to communicate with the phone though.
Since the phone's serial operates at 3.3\,V and is internally connected to the 2.8\,V IO-pins of the baseband processor, directly connecting it to the computer's 12\,V serial port will destroy the hardware.
Therefore it is recommended to use a USB serial cable.
Schematics for such an unlock cable are given in Appendix \ref{sec:osmo_serial_schematics}.

\subsection{OsmocomBB and ICDS}
The setup that is used for the \gls{icds} project can be seen in Figure \ref{fig:osmo_setup}.
It was build and tested in a Xubuntu 11.10 environment\footnote{Xubuntu, \url{http://xubuntu.org/} [Online; Accessed 04.2012]} which is a more lightweight variant of the popular Debian based Ubuntu Linux distribution.
The process of acquiring, compiling and running the OsmocomBB framework itself in this environment is explained in Appendix \ref{sec:osmo_install}.

When setting up the system it is recommended \emph{not} to use a virtual machine.
The bootloader and the firmware can fail to be deployed correctly if a virtual machine is used as development system.
This is because the protocol used by Motorola to do the actual flashing process is \emph{very} time critical and thus timeouts can occur that are caused by the overhead the virtual machine imposes on the hardware\,/\,software communication.

As can be seen in Figure \ref{fig:osmo_setup} Layer 1 of the OsmocomBB \gls{gsm} stack runs on the phone which is connected via a serial cable to the computer running the \gls{icds}.
On the computer side the \texttt{osmocon} program provides a general interface to the phone.
\texttt{Osmocon} is also used to load the firmware up to the Motorola C123.
Other software can communicate with \texttt{osmocon} and subsequently with the phone using Unix sockets.
\begin{figure}
\centering
\includegraphics{../Images/OsmoStructure}
\caption{Interaction of the OsmocomBB components with the ICDS software.}
\label{fig:osmo_setup}
\end{figure}

The program \texttt{catcher}, the OsmocomBB part of the \gls{icds}, is a modified version of the \texttt{cell\_log} by Andreas Eversberg that interfaces with \texttt{osmocon} to harvest information from \glspl{bts} and forward it to the core \gls{icds}.
It can be seen as a Layer 3 program that scans through available frequencies and reads information from the \gls{bcch} whenever one such channel is available on the frequency at hand.
The forwarding is done directly via \texttt{stdout} since it runs as a child process of the \gls{icds}.
In a similar way, \texttt{pch\_scan} gathers information on the \gls{pch} of a specific base station.
The functionality of \texttt{catcher} and \texttt{pch\_scan} will be explained in detail in Section \ref{sec:info_gathering} while the implementation and operation of the \gls{icds} will be discussed in Section \ref{sec:icds}.

\section{Procedure}
The main goal of the \gls{icds} is to reach a conclusion on whether it is safe to initiate a phone call or not, in other words if the base station our mobile phone will connect to is trustworthy.
As mentioned before, as soon as a subscriber connects to an IMSI catcher it automatically gives up information on his\,/\,her location.
Therefore this project will use a passive approach on information harvesting, meaning we will only use information that is broadcasted or freely available as to not give up any hints of the \gls{icds} being active.

To that end a four-step process is taken.
First \emph{information is gathered}.
This process is explained in detail in Section \ref{sec:info_gathering}.
After information on the surrounding \glspl{bts} is ready inside the \gls{icds}, a set of checks is evaluated on each base station individually, with each yielding a specific result for the station.
These checks are called \emph{rules} and discussed further along with the next two steps in Section \ref{sec:info_evaluation}.
Afterwards the results the rules yielded for each base station have to be aggregated into one single result for each \gls{bts} by an \emph{evaluator}.
At last, after every \gls{bts} has its evaluation it can be decided whether to \emph{tell the subscriber} if it is safe to initiate a phone call or not.

\subsection{Information Gathering}
\label{sec:info_gathering}
As explained in Section \ref{sec:common_channels} every base station has an associated \gls{bcch} where information about the station and its network is spread.
\gls{bcch} frames are always sent inside a 51-Multiframe.
After the \gls{ms} has synchronised using the values on the \gls{fcch} and \gls{sch} it can determine which kind of information is hosted inside the \gls{bcch} message.
These so called \emph{System Information Messages} originate at the \gls{bsc} and are produced for each \gls{bts} individually and then periodically broadcasted.
Since all the required information would not fit inside a single frame there are different kinds of System Information Messages that are distinguished by their \gls{tc} and host different kinds of information.
The type can be extracted using the \gls{fn} of the frame the message is sent in \cite{GSM2009}:
\[\text{TC}=(\text{FN} \text{ div } 51)\text{ mod } 8\]
Table \ref{tab:tc_mapping} shows how the \glspl{tc} can be mapped on those types.
\begin{table}
\centering
\begin{tabular}{lc}
\toprule
TC		&System Information Type\\
\midrule
0		&Type 1\\
1		&Type 2\\
2,6		&Type 3\\
3,7		&Type 4\\
4,5		&Any (optional)\\
\bottomrule
\end{tabular}
\caption{Type Codes and the corresponding System Information Types \cite{GSM2009}.}
\label{tab:tc_mapping}
\end{table}
For this project the System Information Type 1--4 are of interest because these are available to all \glspl{ms} that tune in to the particular \gls{bcch} of the respective \gls{bts} without actively connecting to it.

The information contained inside the System Information Messages is harvested via the \texttt{catcher} program.
\texttt{Catcher} is implemented inside the OsmocomBB framework and connects over the \texttt{osmocon} application to the Motorola C123.
At first a sweep scan is done over all the \glspl{arfcn} to measure their reception levels in order to determine where base stations and thus \glspl{bcch} are located.
Afterwards \texttt{catcher} tunes the phone to those specific frequencies where a \gls{bts} was found.

At each such frequency it waits until all the System Information Messages are gathered and extracts parameters where possible.
The parameters along with the raw data are forwarded to the main \gls{icds} application for further evaluation.
An example of a fully parsed System Information Type 2 can be seen in Figure \ref{fig:si1} \cite{protocols1999}.
The Neighbouring Cell List which is a very valuable source of information is located in inside the highlighted section of the message.
\begin{figure}
\centering
\includegraphics[width=.8\textwidth]{../Images/sysinfo2marked}
\caption{System Information 2 Message \cite{protocols1999}.}
\label{fig:si1}
\end{figure}
Examples for all the System Information Messages used, along with an interpretation are located in Appendix \ref{sec:system_infos} and information on how they are interpreted can be found in 3GPP TS 44.018 \cite{sysinfos}.
As long as scanning mode is active all the available stations are scanned repeatedly and changes in the \glspl{bts} will continuously update the data model inside the \gls{icds} software.
The parameters harvested so far are:
\begin{itemize}
	\item MCC: The Mobile Country Code the base station is broadcasting.
	\item MNC: The Mobile Network Code the base station is broadcasting.
	\item ARFCN: The \gls{arfcn} on which the base station is located.
	\item rxlev: Receiving strength in dB.
	This parameter is measured by the Motorola C123 and not part of the System Information Messages.
	Even small changes in the location can have a large impact on this parameter due to shadowing and reflection.
	\item BSIC: Because of frequency reuse in a cellular network it is possible that two different base stations can send at the same \gls{arfcn}.
	In order for the \gls{ms} to keep these apart the \gls{bsic} is also broadcasted.
	It consists of a \gls{ncc} identifying the provider, so the \gls{ms} can filter out messages that it does not need beforehand and the \gls{bcc} that must be unique for a given provider over all base station in a large area.
	\item LAC: This is the last part of the \gls{lai} (that consists of \gls{mcc} + \gls{mnc} + \gls{lac}) and is a hierarchical identifier for a given base station.
	The hierarchy is provider wide, meaning two different providers may use \glspl{lac} with a completely different numbering system.
	The \gls{lac} is used by the provider to tell the \gls{me} that it entered a new area and has to announce itself.
	\item Cell ID: The Cell ID is a unique identifier for the cell the \gls{ms} is connected to.
	Unique in this case means unique in a large area so that a mobile phone should never receive the same Cell ID for different base stations. 
	\item Neighbouring Cells: Each base station keeps a list of other base stations in the perimeter  for the \gls{ms} to scan and determine if there is a \gls{bts} with a better reception in the area.
\end{itemize}
Note that there are different formats for the Neighbouring Cell List since the original number of 17 bytes could only present a bit mask for 124 neighbouring \glspl{arfcn}.
This works for the 900 MHz band, but for the extended 900\MHz and the 1800\MHz band the System Information Type 2bis and System Information Type 2ter have to be harvested additionally to construct the Neighbouring Cell List.

The \texttt{pch\_scan} tool does not rely on the \gls{bcch} but rather on information available on the \gls{pch} as the name implies.
If a mobile phone is connected to a base station and not actively participating in a communication process, it is in a passive mode to save battery waiting for either the user to initiate communication or the network to contact it.
As mentioned in Section \ref{sec:common_channels} the network contacts the \gls{ms} on the \gls{pch} if there is a text message or a call waiting to be delivered.
\begin{figure}
\centering
\includegraphics{../Images/Paging}
\caption{Procedure taken when the network has a call\,/\,text waiting for a passive subscriber.}
\label{fig:paging}
\end{figure}
The procedure is outlined in Figure \ref{fig:paging}.
A paging request by the network is answered by the \gls{ms} by requesting a dedicated channel, which is assigned by the network in turn with an \gls{ia}.
From this point on the connection can be set up.

The \texttt{pch\_scan} listens for activity on this channel and harvests the following information:
\begin{itemize}
	\item Pagings: Informs the \gls{icds} about every Paging Message that has been caught.
	\item Immediate Assignment: If an \gls{ia} is caught, it is logged and parsed.
	The \gls{tmsi} that got the \gls{ia} as well as the assigned channel number and whether it is a frequency hopping channel or not is forwarded to the \gls{icds}.
\end{itemize}

\subsection{Information Evaluation}
\label{sec:info_evaluation}
Each base station is evaluated the moment the data completely arrived at the \gls{icds} application.
Additionally when a new \gls{bts} has been found and added all formerly discovered stations are also re-evaluated since new discoveries can have an impact on the rules that evaluate the context surrounding an old base station.

As mentioned above, evaluation is done based on constructs called \emph{rules}.
Each rule represents one check that can be performed on a base station and yields a result based on its findings.
A rule can also be seen as a mapping from a set of input parameters to one of the values \emph{Ok}, \emph{Warning}, \emph{Critical}, \emph{Ignore}.
\[\lbrace \text{Base station parameters}\rbrace \mapsto \lbrace \text{Ok}\lvert\text{Warning}\lvert\text{Critical}\lvert\text{Ignore}\rbrace\]

A \emph{Critical} result means that the base station evaluated has a critical configuration error or critical settings that are not found on normal base stations, \eg unknown provider names or empty neighbourhood lists.
This station should not be trusted.

If a \emph{Warning} status is yielded the \gls{bts} at hand has some concerning features but it could not be said whether it really is an IMSI catcher or sheer coincidence.
An example would be a base station having a  Neighbouring Cell List of which none of the cells therein have actually been discovered up to that point.
The list could either be a fake or it could simply be coincidence that the scan has not found any.
They could have been out of range for example.

In some cases a rule cannot yield a finding.
That is when the state is explicitly set to \emph{Ignore} so the evaluator knows that this rule should have no influence on the final outcome.	
This is the case for example when a rule refers to a parameter that has not been looked up or scanned.

If everything went as expected, \emph{Ok} is returned.

The rules can be divided into four different categories depending on how they work and which situations they are tailored to.
Most of the rules are parametrised so they can be tweaked to different environments and standards.
The different rule categories are \emph{Configuration Rules}, \emph{Context Rules}, \emph{Databse Rules} and \emph{Scan Rules}.

\subsubsection{Configuration Rules}
The first set of rules called \emph{Configuration Rules} targets the base station itself.
Rules in this category are meant to check parameters that concern the \gls{bts} for integrity and configuration mistakes that could have been made by an IMSI catcher operator.
An overview of which Configuration Rules are currently implemented inside the \gls{icds} is given in Table \ref{tab:config_rules}.
\begin{table}
\centering
\begin{tabular}{ll}
\toprule
Rule					&Functionality\\
\midrule
Provider Known			&Checks whether the provider is in a list of known \\
						&providers.\\
Country\,/\,Provider Map	&Checks whether the given provider is a valid provider\\
						&for the given country.\\
LAC\,/\,Provider Map		&Checks whether the LAC of the station is in the normal\\
						&LAC range for that provider given the area.\\
ARFCN\,/\,Provider Map		&Checks whether the ARFCN is in the officially registered\\
						&range of the provider.\\
\bottomrule
\end{tabular}
\caption{Configuration Rules implemented inside the ICDS.}
\label{tab:config_rules}
\end{table}

A few things have to be noted when configuring these rules.
Since there is no official listing or rule how the \gls{lac} is derived the LAC\,/\,Provider Mapping Rule needs knowledge of the area in which the \gls{icds} is used.
The \gls{icds} itself can be used to gather that knowledge but it has to be done prior to using the rule for base station evaluation. 
The \gls{arfcn} range each provider has registered in Germany can be looked up at the website of the Bundesnetzagentur\footnote{Bundesnetzagentur Vergabeverfahren, \url{http://www.bundesnetzagentur.de/cln_1911/DE/Sachgebiete/Telekommunikation/RegulierungTelekommunikation/Frequenzordnung/OeffentlicherMobilfunk/VergabeVerfahrenDrahtlosNetzzugang/vergabeVerfahrenDrahtlosNetzzugang_node.html} [Online, Accessed 04.2012]} which is needed for the ARFCN\,/\,Provider Mapping Rule.

The main problem at this point is that all the parameters that can be checked by these rules can also be set by the operator of the IMSI catcher.
If these are set in a consistent way this set of rules is not sufficient to identify a catcher.
Therefore another set of rules has to be added that incorporates information of the surrounding nodes.

\subsubsection{Context Rules}
The second set of rules is called \emph{Context Rules}.
As the name suggests these rules serve the purpose of checking how well a given \gls{bts} fits into its neighbourhood.
Table \ref{tab:context_rules} shows which rules have been implemented.
\begin{table}
\centering
\begin{tabular}{ll}
\toprule
Rule					&Functionality\\
\midrule
LAC Median Deviation	&Checks whether the LAC of the given BTS deviates\\
						&more than a certain threshold from the median LAC of\\
						&that provider.\\
Pure Neighbourhoods		&Checks whether all found stations in the Neighbouring\\
						&Cell List share the same provider.\\
Neighbourhood Structure	&Checks the structure of the Neighbouring Cell List for\\
						&certain patterns.\\
Discovered Neighbours. 	&Checks whether a certain amount of the cells in the\\
						&Neighbouring Cell List have actually been found.\\
Cell ID Uniqueness 		&Checks whether there are other cells with the same\\
						&Cell ID.\\
\bottomrule
\end{tabular}
\caption{Context Rules implemented inside the ICDS.}
\label{tab:context_rules}
\end{table}

For the LAC Median Deviation the median was chosen over the average since an extreme value (ill configured IMSI catcher) would have too strong an impact on the average to which all the \gls{bts} are compared.
It could even have such a strong effect on the average that legitimate base stations would fall below the threshold and be recognised as catchers.
The threshold when a deviation is evaluated as being \emph{Critical} can be set in the configuration section for the rule.
A value of 0 would mean that no deviation from the median is allowed.
This could lead to problems as some experimental scans have shown.
However in none of the scans more than two different \glspl{la} have been found per provider and since these were neighbouring areas, the difference in the code was only 1.
For the Freiburg area a 1\% threshold for the deviation yielded good results.

\paragraph{Neighbourhood Structure}
The Neighbourhood Structure is the graph that is described by the Neighbouring Cell List located in the System Inforamtion 2\,/\,2bis\,/\,2ter constructs.
Figure \ref{fig:neighbourhood_example} shows an extract of the neighbourhood graphs at the Faculty of Engineering of the University of Freiburg\footnote{Georges Koehler Allee, Freiburg}.
The E-Plus subgraph has been enlarged.
\begin{figure}
\centering
\includegraphics[width=.9\textwidth]{../Images/neighbourhoods_fak}
\caption{Some base stations and their neighbourhood connections at the Faculty of Engineering.}
\label{fig:neighbourhood_example}
\end{figure}
It can be seen that for each provider, the neighbourhood forms an isolated, nearly fully connected subgraph.
Nodes with a green background have an \emph{Ok} rating, while the red node has a \emph{Critical} rating.
The bordering white nodes have not yet been discovered and evaluated therefore they have no outgoing edges, they were merely found by extracting the neighbourhood lists.
This could be the case because they are too far away for the Motorola to receive or because of signal damping due to shadowing and reflection effects.
In the \gls{icds} the aspect of isolated subgraphs for neighbourhoods is captured inside the \emph{Pure Neighbourhoods Rule}.

An interesting fact is that one node inside the E-Plus subgraph on the upper right is marked \emph{Critical}.
This is because it is a \gls{bts} of the university's own \gls{gsm} network.
It was set up to be in a E-Plus neighbourhood but is not consistent with the E-Plus nodes surrounding it.
Therefore it is marked by the \gls{icds}.

The node was set up inside the E-Plus neighbourhood for another Master Thesis \cite{richy} at the Chair of Communication Systems where the goal was to estimate the most probably position of a subscriber given his\,/\,her reception levels.

Some of the attacks discussed in Section \ref{sec:attacks} imply a certain structure of the neighbourhood graph.
Since the IMSI catcher tries to lock in \glspl{ms} that have connected from switching back to a normal cell, the neighbourhood list of such a catcher cell would either be empty or would only host neighbour cells that have a lower reception strength than itself.

An empty Neighbouring Cell List is represented in the graph by a node that has been discovered and has no outgoing edges.
A Neighbouring Cell list containing only imaginary nodes serves the same purpose.
\begin{figure}
\centering
\subfigure[Normal neighbourhood]{
\begin{tikzpicture}[->,>=stealth',shorten >=1pt,auto,node distance=3cm,
  thick,main node/.style={circle,fill=blue!10,draw,font=\sffamily\Large\bfseries}]

  \node[main node] (1) {A};
  \node[main node] (2) [below left of=1] {B};
  \node[main node] (3) [below right of=1] {C};

  \path[every node/.style={font=\sffamily\small}]
    (1) edge  node {} (2)
        edge  node {} (3)
    (2) edge  node {} (1)
    	edge  node {} (3)
    (3) edge  node {} (1)
    	edge  node {} (2);
\end{tikzpicture}
}
\subfigure[Tainted neighbourhood]{
\begin{tikzpicture}[->,>=stealth',shorten >=1pt,auto,node distance=3cm,
  thick,main node/.style={circle,fill=blue!10,draw,font=\sffamily\Large\bfseries}]

  \node[main node] (1) {A};
  \node[main node] (2) [below left of=1] {B};
  \node[main node, fill=orange!20] (3) [below right of=1] {C};
  \node[main node, fill=orange!20] (4) [right of=1] {D};

  \path[every node/.style={font=\sffamily\small}]
    (1) edge  node {} (2)
        edge  node {} (3)
    (2) edge  node {} (1)
    	edge  node {} (3)
    (4) edge  node {} (1)
    	edge  node {} (2);
\end{tikzpicture}
}
\caption{Comparison between a normal neighbourhood subgraph and a tainted one.}
\label{fig:structure_comparison}
\end{figure}
Figure \ref{fig:structure_comparison} shows a simplified regular neighbourhood graph compared to a graph with two catcher nodes inside.
In this case catcher C chose the attack where it replaces a previously existent \gls{bts} whereas catcher D opened up a new cell.
Replacing has several advantages, one being already integrated in the neighbourhood of other nodes.
Mobile phones will constantly monitor the reception strength of all neighbouring nodes and thus also the reception strength of the IMSI catcher which replaced one.
For catcher D it is the other way around, it has only outgoing edges.
This means that this cell is not known by any other node of the same provider.
Nevertheless it has some outgoing edges to nodes with significantly less transmission strength to not stick out too much as a completely isolated node.
Combinations of these two approaches are also possible.
These thoughts are basically what is captured inside the \emph{Neighbourhood Structure Rule}.
The procedure the Neighbourhood Structure Rule follows is:
\begin{enumerate}
	\item Check if the node in question has neighbours and check if at least one neighbour has been discovered.
This rules out the cases where IMSI catchers have no neighbours or only an imaginary list.
	\item If no neighbours have been discovered by the \gls{icds}, check if other nodes share some of the neighbours, if yes yield a \emph{Warning}, else yield \emph{Critical}.
If the node is question is a legitimate node and the rare case occurs that none of its neighbours are in reach, most of its neighbours should be shared by other nodes of the same provider.
	\item Check if other nodes of the same provider have the node in question inside their neighbourhood list, \eg if the node in question has incoming edges.
This would not be the case for example for an IMSI catcher that broadcasts on a new \gls{arfcn}.
	\item If all the above criteria are met, yield \emph{Ok}.
\end{enumerate}
This rule cannot find an IMSI catcher that has in- and outgoing edges, in other words a device that replaced a legitimate base station and copied the neighbourhood list from the original cell.
Such a catcher would transmit at a very high strength and thus make sure all its neighbours have a worse reception on the target mobile phone than itself.
It is generally not possible to rule out base stations where all outgoing edges point to base stations with a lower reception, since every legitimate neighbourhood will have one node that excels all other nodes in terms of reception.

The Neighbourhood Structure Rule tests if at least one neighbour has actually be found.to raise this threshold the \emph{Discovered Neighbours Rule} can be used.
It takes a parameter as an input which is interpreted differently depending on its range.
If the threshold is in the interval $[0,1]$ it is interpreted as a percentage.
$0.5$ meaning that at least half the neighbours in the list need to be found for the rule to give an \emph{Ok} rating.
A threshold in the interval $(1,+\infty)$ means that this absolute number of base stations have to be found, if a floating point number is provided the real part is stripped.
As an example $3$ and $3.47$ would both mean that at least $3$ neighbours would have to be found.
This representation cannot cover the 'at least one' case since $1$ equals $100\%$ which is no problem for this case is already covered by the Neighbourhood Structure Rule.

\subsubsection{Database Rules}
Let us do a quick summary of the situation so far.
To investigate the current possibilities unveiling a catcher we will look over the parameters with the two attack types presented in Section \ref{sec:attacks} in mind.
For both attack types presented it is possible to find a parameter configuration that does not raise suspicion, if the operator chooses a compatible \gls{arfcn}, \etc for the mimicked provider.
Therefore the Configuration Rules and most of the Context Rules will yield an \emph{Ok} result.

The Neighbouring Cell List is a bit different.
Since the catcher wants to keep lured subscribers it will normally have an empty list or a list pointing only to \glspl{bts} imaginary neighbours. 
Both of these cases can be detected.
However the operator \emph{may} also choose to set a list consistent with the neighbouring cells, \eg a catcher replacing a cell and copying the neighbourhood list.

A new parameter has to be introduced to yield information in the cases the rules mentioned before fail, the \gls{cid}.
For the \gls{cid} there are basically two possibilities depending on which attack type is used.
The first possibility was that the IMSI catcher opens up a new cell and the second one was that it replaces a formerly existent cell.
In the first case parameters can be chosen in a consistent way although a new \gls{cid} has to be chosen, as the \gls{cid} needs to be unique.
In the second case all parameters can be copied from the original cell.
Both possibilities can be resolved by adding outside knowledge to the \gls{icds} thus circumventing the problem of other parameters being forged.
This is done by rules called \emph{Database Rules}.

\begin{table}
\centering
\begin{tabular}{ll}
\toprule
Rule					&Functionality\\
\midrule
Cell ID Database		&Checks all CIDs in the area against a datbase.\\
Local Area Databse 		&Checks whether the LAC of the given BTS deviates.\\
\bottomrule
\end{tabular}
\caption{Database Rules implemented inside the ICDS.}
\label{tab:database_rules}
\end{table}

Table \ref{tab:database_rules} shows the rules that each handles one of these cases.
The first case is the easier of both.
We know that the catcher cell has a new \gls{cid} that has not been there before.
Therefore the \emph{Cell ID Database Rule} has two different means to exploit this fact:
\begin{itemize}
	\item A database of \glspl{cid} can be learned by the \gls{icds} beforehand. 
	This can be used to detect new \glspl{cid} that have not been seen before.
	\item A commercial or public \gls{cid} database can be used to compare against the \glspl{cid} found by the \gls{icds}.
	A web service also offered by most providers of Cell ID databases.
\end{itemize}
The three largest Cell ID databases are the two commercial ones by Ericson\footnote{Ericson Labs, \url{https://labs.ericsson.com/apis/mobile-location/} [Online; Accessed 04.2012]} and combain\footnote{Mobile Positioning Solutions, \url{http://location-api.com/} [Online; Accessed 04.2012]} as well as the free alternative OpenCellID\footnote{OpenCellID, \url{http://www.opencellid.org/} [Online; Accessed 04.2012]} \cite{wiki_cells}.
Ericson and combain have trial modes, where the first 1000 requests are free for developers afterwards a subscription or a fee per request must be paid.
Another free alternative with a large coverage is Google Mobile Maps, that also offers a web service where \glspl{cid} and their respective \glspl{lai} can be checked against their database to obtain localisation information (or simply check if they are part of the database).
By adding this information new cells can be identified.

The second attack type where an existing cell is replaced is a bit more complicated since its parameters are an exact copy of the old cell.
Attacking by replacing a cell works in a way that the cell with the worst reception is targeted.
That way when the IMSI catcher finished replacing it, the reception goes up a significant amount and the mobile phone will move over to that cell.
The difference in reception can be used to identify this kind of attack.
In general the reception cannot be used well as a parameter because shadowing and reflection can substantially change the reception from one moment to the other.
However if reception intervals are logged for a fixed location like an office then important calls made from that specific location can be protected against this kind of attack.
To that end the \gls{icds} can monitor reception levels to build up databases with information on the reception intervals of the cells in different, fixed locations.
The \emph{Local Area Database Rule} then checks if reception levels differ significantly for a given location.

\subsubsection{Scan Rules}
\begin{table}
\centering
\begin{tabular}{ll}
\toprule
Rule					&Functionality\\
\midrule
rx Change		 		&Watches out for changes in reception.\\
LAC Change				&Watches out for changes in LACs.\\
\bottomrule
\end{tabular}
\caption{Scan Rules implemented inside the ICDS.}
\label{tab:scan_rules}
\end{table}
At this stage, if local information is present, an IMSI catcher should be identified with a high probability.
However if local information has not been gathered in advance, the main idea of Database Rules can still be applied.
In contrast to the other three categories of rules mentioned before, \emph{Scan Rules} evaluate parameter changes over time.
This means parameters are being monitored over the duration of one or multiple sweep scans and changes are noted.
The \emph{rx Change Rule} builds upon the same idea as the \emph{Local Area Database Rule}, only applied to a scan to scan basis.
Changes in reception are evaluated against the last known reception level for each base station.

When watching for parameter changes the \gls{lac} is another interesting parameter.
If a mobile phone connects to an IMSI catcher due to its better reception level the mobile phone will not immediately announce itself thus the IMSI catcher has no knowledge that a new subscriber connected to it.
A mobile phone announces itself by sending Location Updates to the network, this is only done when a certain timeout is reached or when the phone enters a new \gls{la}.
Since this timeout can be very large (the lowest value possible is 6 minutes) an IMSI catcher usually sends a different \gls{lac} than the original cell to force the \gls{ms} to announce itself by sending a Location Update.
IMSI catchers showing this kind of behaviour are uncovered by the \emph{LAC Change Rule}

\subsubsection{Remaining Issues and Paging}
\label{sec:paging}
If a catcher is configured in a consistent way, replaces a cell and by chance has an \emph{appropriate distance} from the subscriber that is its target, the \gls{icds} will not unveil it up to now if it also chooses to maintain a non-suspicious neighbourhood list and shows the patience to wait for the \gls{ms} to announce itself, \eg not changing the \gls{lac}.
\emph{Appropriate distance} in this case means that the distance is chosen in a way that the reception of the catcher does not differ significantly from the reception of the original base station.

An IMSI catcher is not part of a provider's network, it is merely a proxy for a base station.
At best it can route calls into a network but it cannot take calls that are intended for a subscriber and route them.
Therefore an IMSI catcher will not page connected subscribers while a normal base station will have a very high number of pagings depending on the number of subscribers that are connected.
This is a significant difference between a catcher and a regular base station.

This is an additional information that can be used to identify an IMSI catcher.
The program \texttt{pch\_scan} tunes the Motorola C123 to the \gls{pch} of a particular base station and gathers Paging Messages and \glspl{ia}.
If no Paging Messages could be collected during longer period of scanning it is a strong indicator towards being confronted with an IMSI catcher.
Additionally when \glspl{ia} are found the scan extracts whether the assigned channel is a frequency hopping channel or not.
Since frequency hopping is considered a security feature by providers, all German providers always assign frequency hopping channels.
An IMSI catcher however may not support hopping since it does not have multiple frequencies at hand.

The \emph{PCH Scan} feature has not been implemented as a regular rule since each given base station needs some time to be scanned.
If that would be done on a regular basis for every station that has been discovered it would delay the whole scan by a large amount of time and the interval between re-evaluations would be very high.
Therefore it was implemented as an extra feature to be used when needed.
The \gls{icds} also uses this method on particularly filtered base stations in \emph{User Mode} as will be explained in Section \ref{sec:user_mode}.

\subsection{Base Station Evaluation}
\label{sec:evaluators}
All the rules are evaluated for each base station.
Aggregation of these rule results into a single result is done by modules called \emph{evaluators}.
Currently there are two different evaluators implemented inside the \gls{icds}:
\begin{itemize}
	\item Conservative Evaluator: This is a worst-case evaluator.
	It iterates over all the rule findings and yields the most concerning finding as its result.
	By default this evaluator is enabled in the system.
	\item Grouped Evaluator: With this evaluator rules can be grouped together.
	Inside each group the result for the group is found by majority vote whereas the final result is conservatively found by comparing all the group results.
\end{itemize}
Different kinds of evaluators can be used to tweak the whole system more to a specific environment or purpose, if specific rules are grouped together.
They are meant more for experimental purpose if the \gls{icds} is used as a toolbox for analysing base stations, to give more freedom in use to the operator.
In case of the system being used in \emph{User Mode} or for the sole purpose of finding whether an IMSI catcher is active or not, the conservative evaluator should almost always be the evaluator of choice and tweaking should be done on the rule parameters rather than on the evaluator.

After a result has been determined for each station, all the results are again aggregated into a final result.
The overall result depends on which mode the \gls{icds} is used in.
If it is used as analysis tool the final result will be a conservatively aggregated result over all the stations in the list.
If the \gls{icds} is run in \emph{User Mode}, which is the mode an end user would use the system in, the \gls{icds} looks up the provider the user has entered, filter out the base station with the best reception for that provider and yield its evaluation as final evaluation.
This reflects the fact that a subscriber cannot choose the \gls{bts} it connects to, since the \gls{me} will always connect to the best base station available for its given provider.

\section{Implementation}
\label{sec:icds}
This section will discuss some technical aspects of the \gls{icds} software itself.
The first section focuses on architectural aspects and how the architecture can be extended whereas the second and third section will then explain how to configure and operate the application.

\subsection{Architecture}
\begin{figure}
\centering
\includegraphics{../Images/Architecture_software}
\caption{System architecture of the ICDS. The arrows indicate the flow of data.}
\label{fig:architecture}
\end{figure}
Figure \ref{fig:architecture} shows a diagram describing the system architecture, the modules in light blue have been implemented for this project.
The application consists of two main parts.
One part, the \texttt{catcher}, is implemented inside the OsmocomBB framework, the other part, \emph{PyCatcher}, is a Python application that uses \texttt{catcher} and \texttt{pch\_scan} to harvest information and evaluate it afterwards.
Since the way these two sub-programs work has already been described in Section \ref{sec:info_gathering} this section will focus on the Python application part.

As mentioned before Layer 1 of the \gls{gsm} stack is implemented in the firmware running on the Motorola C123.
Layer 2 and Layer 3 are implemented on the computer and are used by the \texttt{catcher} and the \texttt{pch\_scan} software to harvest information from the \gls{bcch} and \gls{pch} respectively.

The PyCatcher application was designed with a \gls{mvc} approach in mind to make it easy to implement new functionality.
The \gls{mvc} pattern is used to separate the data model of an application from the logic as well as from the way it is presented to the user.
That way each of the different components can be exchanged without affecting the other two.
An additional module has been added, the \emph{OsmoConnector} that is loaded by the controller and spawns \texttt{catcher} as a child process.
It takes the output back in and transforms it into an object oriented representation of the discovered base stations.
These are then handed over and update the data model.
This way it can be ensured that only coherent and complete information is incorporated in the data model.
Another benefit is that the parsing module is isolated from the main program logic.
OsmoConnector is also the module that spawns \texttt{pch\_scan} when requested by the controller.

The \emph{controller} is the main part of the program and instantiates all the other modules.
It loads data from the model, triggers the evaluation and sends the results to the view to be displayed.
As discussed before there are several rules that can be evaluated for each base station.
These rules are stored within the controller and can be enabled or disabled by using the view that relays new rule configurations back to the controller to be applied. 
Whenever a new evaluation is requested the controller evaluates the active rules and gives the results to the active evaluator, afterwards the results are send to the view for display to the user.
Note that all the structures used are view independent, this way the current view could easily be exchanged with a web interface for example.

The \texttt{view} in this project consists of a GTK3\footnote{The GTK+ Project, \url{http://www.gtk.org/} [Online; Accessed 06.2012]} window with several forms for user input.
It is bound to the controller using PyGTK\footnote{PyGTK, \url{http://www.pygtk.org/} [Online; Accessed 06.2012]}.
Details on the view and how to use it will be explained in Section \ref{sec:icds_operation}.

Rules and evaluators were designed in a plugin fashion, since these are the main points where the program can be enhanced and new ideas can be realised.
Implementing a new rule or a new evaluator works by extending the rule or evaluator base class and implementing one method inside the derived class that contains the actual logic.
After that they only need to be added to the list of evaluators and rules included inside the controller.
Appendix \ref{sec:extensions} gives an example of how this can be done.

\subsection{Configuration}
\label{sec:configuration}
\begin{figure}
\hspace*{\dimexpr\fboxsep+\fboxrule}% 
\begin{minipage}{\dimexpr\textwidth-4\fboxsep-2\fboxrule} 
\begin{lstlisting}
dictionary = {
	'key_1': value_1,           #single value
	'key_2': (value_2,value_3)  #value range
	'key_3': [value_5, value_6] #list of values
}

variable = value_7              #simple variable
\end{lstlisting}
\end{minipage}
\caption{Configuration Dictionary in the settings file.}
\label{fig:python_dict}
\end{figure}
The configuration of the system is done in the file \texttt{settings.py}.
All configuration is done within the python language, where each module has its own dictionary inside which it can have an arbitrary number of parameters with their respective values or if only few parameters are required they are read in as simple variables.
Figure \ref{fig:python_dict} shows an example with the four common expressions used for parameters in this project.

The file consists of five main sections.
The first one contains parameters that are needed for the correct operation of the \gls{icds} system and have to be edited depending on the environment:
\begin{itemize}
	\item \texttt{Device\_settings}: The setting for the mobile phone that is used.
	In case the Motorola C123 is used, this section does not need to be edited.
	\item \texttt{Osmocom\_lib}: The path to the folder that contains the OsmocomBB framework.
	\item \texttt{Commands}: This is only to be edited when a newer version of the framework is used and the folder structure has changed since the release used in this project.
\end{itemize}
The second and third sections contain parameters for the different rules and evaluators.
This is followed by a section to set some general parameters for the \texttt{pch\_scan} tool and a section where the locations of the different databases can be changed.
A completely documented configuration file with all the rules and evaluator parameters can be found in Appendix \ref{sec:example_config}.
The file is read in as a python file.
This way python code can also be used to change settings dynamically depending on the environment or how the \gls{icds} is started.

\subsection{Graphical User Interface}
\label{sec:icds_operation}
The \gls{icds} main application has to be started with root privileges since it needs to work with Unix sockets and open up connections to the Motorola C123.
This should be done by starting up the \texttt{main} class that initialises everything else.
\[\texttt{sudo python /path-to-project/Src/PyCatcher/src/main.py}\]
After a brief loading time the main window shown in Figure \ref{fig:icds} will appear if a valid configuration is set up.

\begin{figure}
\centering
\includegraphics[width=\textwidth]{../Images/ICDS}
\caption{The ICDS main window.}
\label{fig:icds}
\end{figure}

The different elements shown in the main window are:
\begin{enumerate}
\item Firmware Loader: This button is used to load the OsmocomBB firmware onto the Motorola C123. 
For this to work, the mobile phone must be connected correctly to the computer and available on the configured \texttt{tty} interface.
After pressing the button on-screen instructions will lead the user through the process of flashing.

\item Scanner: This starts the \texttt{catcher} subprocess in the background and fills the data model with information on the discovered base stations.
During this process the Base Station List (11) and the Base Station Graph (13) will also be populated in realtime.
Re-evaluation on all base stations is done for every new \gls{bts} that has been found.

\item Filter Window: This brings up the window shown in Figure \ref{fig:filters_window}, where different view filters for the Base Station List and the Base Station Graph can be set.
Note that these filters do not modify the underlying data model or the behaviour of the scanner, they merely manipulate the view.
Hidden base stations will be scanned and added to the data model independent from the filters set, so they can be viewed at a later point if necessary.
Available filters are:
	\begin{itemize}
	\item Provider Filter: Takes a comma separated white list of providers that should be shown.
	\item ARFCN Filter: Takes a range of \glspl{arfcn} to be shown.
	\end{itemize}
These two filters can arbitrarily be combined together.
Filters are designed the same way as rules and evaluators, a new filter can be implemented by derivation of the base class.

\item Rules Window: All the rules implemented inside the \gls{icds} will be brought up with a check box to enable or disable these rules.
Disabling means that they will not be considered for the evaluation of a base station.
A screenshot can be seen in Figure \ref{fig:rules_window}.
If rules are changed during a sweep scan, everything will be re-evaluated according to the new rules set without interrupting the scan.

\item Evaluator Window: This window will let the user choose  which evaluator already discussed in Section \ref{sec:evaluators} to use for \gls{bts} evaluation.
Choosing a new evaluator will also trigger a re-evaluation of all the data collected so far.

\item Evaluation: This button brings up a separate window showing only the final evaluation of the scan.
The final evaluation shown in this dialog \emph{will} be affected by the filters set.
Base stations that are filtered out are not considered.

\item Databases Window: The window shown in Figure \ref{fig:databases_window} contains settings for all the databases the \gls{icds} uses.
These settings are mandatory if the Local Area Database Rule or the Cell ID Rule is going to be used.
It is also possible here to export the current scan as a \gls{csv} file or a Sqlite database to be used in other programs.

\item PCH Scan Window: This button brings up the dialog illustrated in Figure \ref{fig:pch_window} in which an \gls{arfcn} or a list of \glspl{arfcn} can be scanned to discover Paging Messages and \glspl{ia} on the \glspl{pch}.
The timeout sets the duration of a scan.
Results of the scan will be shows in a list in the lower part of the window after the scan is finished.

\item Save\,/\,Load Project: The current state of the application can be saved as or loaded from a \texttt{.cpf} file.
This enables the user to continue a scan at a later time or to compare different data sets scanned at different points in time or locations with one another.

\item User Mode: The \gls{icds} is ultimately meant to be a tool that can be used by end users to check whether it is safe to initiate a phone call or not.
This dialog presents a way the already configured tool could be shown to end users.
Only the provider is to be entered and a final evaluation will be returned once the \gls{icds} is done with the process.

\item Base Station List: This list gives an overview of which base stations have been discovered so far along with some distinguishing information including its evaluation.
A detailed view of a base station can be brought up by selecting it in the list and pressing the enter or return key.
The report is separated into four main parts, the first being all the harvested parameters, followed by findings the different rules and evaluators yielded and a section with the raw uninterpreted System Information data.
 
\item Log Window: Every important event inside the \gls{icds} is reported in the log together with a time stamp when it occurred.

\item Base Station Graph: This graph displays the base station found in the Base Station List (11).
A node represents a single \gls{bts} and is labelled with its respective \gls{arfcn}.
An edge from note $A$ to $B$ is drawn if node $B$ occurs in the Neighbouring Cells List of $A$.
Nodes with a white background have only been found inside Neighbouring Cell Lists but not yet by the \gls{icds} scanner itself whereas nodes with a red, yellow or green background have been found and evaluated with the colour representing either a critical, a warning or an ok status respectively.

\item Graph Controls: These are meant to make navigating the graph a bit easier.
From left to right the functionality is zoom in, zoom out, fit the whole graph to the viewport and display the graph in original size.
Zooming can also be done with the mouse wheel and it is possible to drag the graph around by clicking and holding it with the mouse and then moving it in the desired direction.
\end{enumerate}
\begin{figure}
\centering
\subfigure[Databases window.]{\includegraphics[width=.4\textwidth]{../Images/databases_window}\label{fig:databases_window}}
\subfigure[Rules window.]{\includegraphics[width=.4\textwidth]{../Images/rules_window}\label{fig:rules_window}}\\
\subfigure[Filters window.]{\includegraphics[width=.4\textwidth]{../Images/filter_window}\label{fig:filters_window}}
\subfigure[PCH scan window.]{\includegraphics[width=.4\textwidth]{../Images/pch_window}\label{fig:pch_window}}
\caption{Dialogs for different settings.}
\label{fig:dialogs}
\end{figure}

\subsection{Usage}
\label{sec:user_mode}
This section will list some common use cases and explain how to setup and operate the system to achieve the desired result.
Button numbering refers back to Figure \ref{fig:icds}.

\paragraph{Conducting sweep scans:} This is the normal mode of operation, scanning and evaluating all base stations in the perimeter.
This is also used for gathering various kinds of information to be used for analysis later.
At first the firmware needs to be flashed onto the device by pressing (1).
After the flashing process is finished the scan can be started by pressing (2).
Either before or during the scan (3),(4) and (5) can be used to customise the output or rules that should be considered during evaluation.
The scan can be stopped at any time.
Resuming the scan will renew the information in the Base Station List.
The scan will continue renewing information until it is terminated by the user.
The number of times a specific \gls{bts} has been scanned is shown in the \emph{Sightings} column of the Base Station List.

\paragraph{Using and obtaining Cell ID Information:} \gls{cid} information can be obtained through several different means.
The Databases window shown in Figure \ref{fig:databases_window} can be brought up by pressing (7).
In the upper part settings concerning the acquisition of \glspl{cid} can be found.
The operator has the choice between three different methods which can also be used in combination.
\emph{Google Mobile Maps Service} compares the stations' \glspl{cid} and \glspl{lai} to the ones in the Google database.
If they are found they are marked as such and additionally their location information will be set.
\emph{OpenCellID Web Service} performs the same task if activated.
As of now OpenCellID has a very low coverage compared to Google's service but it has been included since it is an open source approach that is in development and updated constantly.
The \emph{Use Local Databse} feature allows to use a previously build Local Area Database as Cell ID Database for lookups.
For this purpose the location to be used as database has to be entered in the textfield, \eg 'office' or 'home'.
Offline lookups can be done that way, which are considerably faster that online lookups, the raw data used by the OpenCellID project can also be downloaded and used as a offline version for reference that way.
Since these lookups take some time if performed using webservices, this is not done while the scan is taking place, to not delay the acquisition of information from new base stations.
Pressing the button below the checkboxes will add the Cell ID Database information from the selected sources to all the stations currently in the base station list.
If more than one service is activated lookups will be done starting with the Google service, if active and using the next one in line only if the previous lookup failed.
Having at least one service activated and run on the base station list is a precondition for the Cell ID Database Rule to work.

\paragraph{Building or using a Local Area Database:} Having set up the correct location in the \emph{Current Location} field of the databases window and having a valid database for that location are preconditions for the Local Area Database Rule to work.
To build up a database for a specific location a sweep scan for this location has to be done.
After the sweep scan is finished, the current location has to be set in the dialog and the button for adding\,/\,updating the database has to be pressed.
If there was no existing database for that location it will be created, otherwise the database will be updated with the new information acquired by the sweep scan.
To enhance the quality of a Local Area Database it is recommended to do multiple sweep scans and integrate them rather than relying on a single scan only.
This raises the probability that all \gls{bts} in the perimeter are found is higher and it solidifies the interval in which the base station signal strength varies.

\paragraph{Conducting a PCH Scan:} A \gls{pch} scan can be conducted in addition to a sweep scan or as a standalone method therefore no scan data needs to be present.
Since PHC scans and sweep scans use the Motorola C123 a PCH scan can only be done when no sweep scan is active and vice versa.
The first parameter is a comma separated list of \glspl{arfcn} that will be scanned.
The second parameter is the timeout. 
A scan for a particular \gls{arfcn} will tune in on the \gls{pch} of each \gls{arfcn} given and wait there until the timeout is reached gathering all paging messages and \gls{ia} that are sent in that time interval.
In the lower part of the dialog, after the scan has finished, the statistics for the scanned \glspl{bts} will occur.
If the checkbox is checked, the data acquired by the scan will also be integrated with the data model and will have an impact on the evaluation displayed in the Base Station Graph.
The findings can then also be seen in the report for a base station.

\begin{figure}
\centering
\includegraphics[width=.4\textwidth]{../Images/user_window}
\caption{The User Mode window.}
\label{fig:user_mode}
\end{figure}

\paragraph{Utilising User Mode:} Data needs to be present inside the \gls{icds} either by loading a project file for the corresponding location the system is used in or by having performed a sweep scan in advance.
There is only one input field in the dialog as Figure \ref{fig:user_mode} illustrates.
The user has to enter the provider name in this field and push the \emph{Start Evaluation} button.
From the scan data, the \gls{icds} extracts the base station with the highest reception for the given provider since this would be the station a \gls{ms} would connect to if started up.
If the station already has been evaluated as \emph{Critical}, \emph{User Mode} will instantly yield this as result.
In all other cases it performs an additional \gls{pch} scan on that station to rule out the scenario where a catcher has not been detected by the currently active set of rules.

After the evaluation has been completed, the picture on the bottom will change to reflect the result found.
Additionally if PCH scan integration is enabled the results from \emph{User Scan} will also carry over to the data model if a PCH scan has been carried out in the process.

\section{Related Projects}
IMSI catcher detection is a topic that has not emerged until recently therefore not a lot of work and research has been done upon that subject.
This is mainly due to the fact that is was very hard to get information from the mobile network onto a computer for evaluation and the threat seemed to be not as large as today with cheap self build IMSI catchers.

About the same time as this project, in December 2011, another project was announced with the same goals of detecting an IMSI catcher.
The project is called 'Catcher Catcher'\footnote{Catcher Catcher Wiki, \url{http://opensource.srlabs.de/projects/catcher/wiki/Tutorial} [Online; Accessed 05.2012]} and also builds up on the OsmocomBB framework.
The goals are the same however the means are very different.
As a codebase 'Catcher Catcher' uses the \texttt{mobile} application, a software that implements the firmware part of a mobile phone.
This results in an active approach to IMSI catcher detection.
An active connection is established between the phone and the base station in question.
Basically this means that identification is done be letting a bait-phone get caught.

The advantage compared to the passive approach of this project uses is that one has more sure means at hand of identifying a potential catcher.
Features that are already implemented are \cite{catcher_catcher}:
\begin{itemize}
	\item Encryption: Check whether encryption is enabled when doing a phone call.
	\item IMEI: \gls{imei} is not requested in Cipher Mode Complete message.
	\item LAC: \gls{lac} of a base station changes.
	\item Location Updates: IMEI is requested during Location Updates.
	\item Silent Text: Checks whether a silent text message is received.
	\item Call Setup: Do not receive a Call Setup message while being on a traffic channel for two seconds.
\end{itemize}
As one can see, missing encryption and reception of a silent text message are very strong indicators of being connected to a catcher.
This however comes at the cost of being discovered oneself.
Additionally if the IMSI catcher is configured only to allow specific IMSI numbers an active approach cannot be used to evaluate it.g

It is not clear whether the project has been abandoned or whether it is developed further.
Activity on the Wiki and Git has seized after December 2012.