8 files changed, 710 insertions, 0 deletions
diff --git a/2010/osmocombb-phneutral2010/c123_pcb.jpg b/2010/osmocombb-phneutral2010/c123_pcb.jpg
new file mode 100644
index 0000000..a9f24fc
--- /dev/null
+++ b/2010/osmocombb-phneutral2010/c123_pcb.jpg
diff --git a/2010/osmocombb-phneutral2010/calypso-block.pdf b/2010/osmocombb-phneutral2010/calypso-block.pdf
new file mode 100644
index 0000000..27f8be8
--- /dev/null
+++ b/2010/osmocombb-phneutral2010/calypso-block.pdf
diff --git a/2010/osmocombb-phneutral2010/gsm_network.png b/2010/osmocombb-phneutral2010/gsm_network.png
new file mode 100644
index 0000000..c5f6399
--- /dev/null
+++ b/2010/osmocombb-phneutral2010/gsm_network.png
diff --git a/2010/osmocombb-phneutral2010/osmocombb-abstract.txt b/2010/osmocombb-phneutral2010/osmocombb-abstract.txt
new file mode 100644
index 0000000..497e495
--- /dev/null
+++ b/2010/osmocombb-phneutral2010/osmocombb-abstract.txt
@@ -0,0 +1,24 @@
+OsmocomBB: A tool for GSM protocol level security analysis of GSM networks
+
+By: Harald Welte[1]
+
+The OsmocomBB project[2] is a Free Software implementation of the GSM
+protocol stack running on a mobile phone.  
+
+For decades, the cellular industry comprised by cellphone chipset makers and
+network operators keep their hardware and system-level software as well as GSM
+protocol stack implementations closed.  As a result, it was never possible
+to send arbitrary data at the lower levels of the GSM protocol stack.
+Existing phones only allow application-level data to be specified, such as
+SMS messages, IP over GPRS or circuit-switched data (CSD).  
+
+Using OsmocomBB, the security researcher finally has a tool equivalent
+to an Ethernet card in the TCP/IP protocol world:  A simple transceiver
+that will send arbitrary protocol messages to a GSM network.
+
+Well-known and established techniques like protocol fuzzing can finally
+be used in GSM networks and reveal how reliable and fault tolerant the
+equipment used in the GSM networks really is.
+
+[1] http://laforge.gnumonks.org/
+[2] http://bb.osmocom.org/
diff --git a/2010/osmocombb-phneutral2010/osmocombb-security.pdf b/2010/osmocombb-phneutral2010/osmocombb-security.pdf
new file mode 100644
index 0000000..892cd76
--- /dev/null
+++ b/2010/osmocombb-phneutral2010/osmocombb-security.pdf
diff --git a/2010/osmocombb-phneutral2010/osmocombb-security.snm b/2010/osmocombb-phneutral2010/osmocombb-security.snm
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/2010/osmocombb-phneutral2010/osmocombb-security.snm
diff --git a/2010/osmocombb-phneutral2010/osmocombb-security.tex b/2010/osmocombb-phneutral2010/osmocombb-security.tex
new file mode 100644
index 0000000..848b889
--- /dev/null
+++ b/2010/osmocombb-phneutral2010/osmocombb-security.tex
@@ -0,0 +1,645 @@
+% $Header: /cvsroot/latex-beamer/latex-beamer/solutions/conference-talks/conference-ornate-20min.en.tex,v 1.7 2007/01/28 20:48:23 tantau Exp $
+
+\documentclass{beamer}
+
+\usepackage{url}
+\makeatletter
+\def\url@leostyle{%
+  \@ifundefined{selectfont}{\def\UrlFont{\sf}}{\def\UrlFont{\tiny\ttfamily}}}
+\makeatother
+%% Now actually use the newly defined style.
+\urlstyle{leo}
+
+
+% This file is a solution template for:
+
+% - Talk at a conference/colloquium.
+% - Talk length is about 20min.
+% - Style is ornate.
+
+
+
+% Copyright 2004 by Till Tantau <tantau@users.sourceforge.net>.
+%
+% In principle, this file can be redistributed and/or modified under
+% the terms of the GNU Public License, version 2.
+%
+% However, this file is supposed to be a template to be modified
+% for your own needs. For this reason, if you use this file as a
+% template and not specifically distribute it as part of a another
+% package/program, I grant the extra permission to freely copy and
+% modify this file as you see fit and even to delete this copyright
+% notice. 
+
+
+\mode<presentation>
+{
+  \usetheme{Warsaw}
+  % or ...
+
+  \setbeamercovered{transparent}
+  % or whatever (possibly just delete it)
+}
+
+
+\usepackage[english]{babel}
+% or whatever
+
+\usepackage[latin1]{inputenc}
+% or whatever
+
+\usepackage{times}
+\usepackage[T1]{fontenc}
+% Or whatever. Note that the encoding and the font should match. If T1
+% does not look nice, try deleting the line with the fontenc.
+
+
+\title{OsmocomBB}
+
+\subtitle
+{Sending arbitrary protocol data to GSM networks}
+
+\author{Harald Welte}
+
+\institute
+{gnumonks.org\\gpl-violations.org\\OpenBSC\\airprobe.org\\hmw-consulting.de}
+% - Use the \inst command only if there are several affiliations.
+% - Keep it simple, no one is interested in your street address.
+
+\date[ph-neutral 2010] % (optional, should be abbreviation of conference name)
+{ph-neutral 2010, May 2010, Berlin/Germany}
+% - Either use conference name or its abbreviation.
+% - Not really informative to the audience, more for people (including
+%   yourself) who are reading the slides online
+
+\subject{GSM Security}
+% This is only inserted into the PDF information catalog. Can be left
+% out. 
+
+
+
+% If you have a file called "university-logo-filename.xxx", where xxx
+% is a graphic format that can be processed by latex or pdflatex,
+% resp., then you can add a logo as follows:
+
+% \pgfdeclareimage[height=0.5cm]{university-logo}{university-logo-filename}
+% \logo{\pgfuseimage{university-logo}}
+
+
+
+% Delete this, if you do not want the table of contents to pop up at
+% the beginning of each subsection:
+%\AtBeginSubsection[]
+%{
+%  \begin{frame}<beamer>{Outline}
+%    \tableofcontents[currentsection,currentsubsection]
+%  \end{frame}
+%}
+
+
+% If you wish to uncover everything in a step-wise fashion, uncomment
+% the following command: 
+
+%\beamerdefaultoverlayspecification{<+->}
+
+
+\begin{document}
+
+\begin{frame}
+  \titlepage
+\end{frame}
+
+\begin{frame}{Outline}
+  \tableofcontents[hideallsubsections]
+  % You might wish to add the option [pausesections]
+\end{frame}
+
+
+% Structuring a talk is a difficult task and the following structure
+% may not be suitable. Here are some rules that apply for this
+% solution: 
+
+% - Exactly two or three sections (other than the summary).
+% - At *most* three subsections per section.
+% - Talk about 30s to 2min per frame. So there should be between about
+%   15 and 30 frames, all told.
+
+% - A conference audience is likely to know very little of what you
+%   are going to talk about. So *simplify*!
+% - In a 20min talk, getting the main ideas across is hard
+%   enough. Leave out details, even if it means being less precise than
+%   you think necessary.
+% - If you omit details that are vital to the proof/implementation,
+%   just say so once. Everybody will be happy with that.
+
+\begin{frame}{About the speaker}
+\begin{itemize}
+	\item Using + playing with Linux since 1994
+	\item Kernel / bootloader / driver / firmware development since 1999
+	\item IT security specialist, focus on network protocol security
+	\item Board-level Electrical Engineering
+	\item Always looking for interesting protocols (RFID, DECT, GSM)
+\end{itemize}
+\end{frame}
+
+\section{GSM/3G Network Security Introduction}
+
+\begin{frame}{GSM/3G protocol security}
+\begin{itemize}
+	\item Observation
+	\begin{itemize}
+		\item Both GSM/3G and TCP/IP protocol specs are publicly available
+		\item The Internet protocol stack (Ethernet/Wifi/TCP/IP) receives lots of scrutiny
+		\item GSM networks are as widely deployed as the Internet
+		\item Yet, GSM/3G protocols receive no such scrutiny!
+	\end{itemize}
+	\item There are reasons for that:
+	\begin{itemize}
+		\item GSM industry is extremely closed (and closed-minded)
+		\item Only about 4 closed-source protocol stack implementations
+		\item GSM chipset makers never release any hardware documentation
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\subsection{The closed GSM industry}
+
+\begin{frame}{The closed GSM industry}{Handset manufacturing side}
+\begin{itemize}
+	\item Only very few companies build GSM/3.5G baseband chips today
+	\begin{itemize}
+		\item Those companies buy the operating system kernel and the protocol stack from third parties
+	\end{itemize}
+	\item Only very few handset makers are large enough to become a customer
+	\begin{itemize}
+		\item Even they only get limited access to hardware documentation
+		\item Even they never really get access to the firmware source
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{The closed GSM industry}{Network manufacturing side}
+\begin{itemize}
+	\item Only very few companies build GSM network equipment
+	\begin{itemize}
+		\item Basically only Ericsson, Nokia-Siemens, Alcatel-Lucent and Huawei
+		\item Exception: Small equipment manufacturers for picocell / nanocell / femtocells / measurement devices and law enforcement equipment
+	\end{itemize}
+	\item Only operators buy equipment from them
+	\item Since the quantities are low, the prices are extremely high
+	\begin{itemize}
+		\item e.g. for a BTS, easily 10-40k EUR
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{The closed GSM industry}{Operator side}
+\begin{itemize}
+	\item Operators are mainly banks today
+	\item Typical operator outsources
+	\begin{itemize}
+		\item Billing
+		\item Network planning / deployment / servicing
+	\end{itemize}
+	\item Operator just knows the closed equipment as shipped by manufacturer
+	\item Very few people at an operator have knowledge of the protocol beyond what's needed for operations and maintenance
+\end{itemize}
+\end{frame}
+
+\subsection{Security implications}
+
+\begin{frame}{The closed GSM industry}{Security implications}
+The security implications of the closed GSM industry are:
+\begin{itemize}
+	\item Almost no people who have detailed technical knowledge outside the protocol stack or GSM network equipment manufacturers
+	\item No independent research on protocol-level security
+	\begin{itemize}
+		\item If there's security research at all, then only theoretical (like the A5/2 and A5/1 cryptanalysis)
+		\item Or on application level (e.g. mobile malware)
+	\end{itemize}
+	\item No open source protocol implementations
+	\begin{itemize}
+		\item which are key for making more people learn about the protocols
+		\item which enable quick prototyping/testing by modifying existing code
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Security analysis of GSM}{How would you get started?}
+If you were to start with GSM protocol level security analysis, where and
+how would you start?
+\begin{itemize}
+	\item On the network side?
+	\begin{itemize}
+		\item Difficult since equipment is not easily available and normally extremely expensive
+		\item However, network is very modular and has many standardized/documented interfaces
+		\item Thus, if equipment is available, much easier/faster progress
+		\item Has been done in 2008/2009: Project OpenBSC
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Security analysis of GSM}{How would you get started?}
+If you were to start with GSM protocol level security analysis, where and
+how would you start?
+\begin{itemize}
+	\item On the handset side?
+	\begin{itemize}
+		\item Difficult since GSM firmware and protocol stacks are closed and proprietary
+		\item Even if you want to write your own protocol stack, the layer 1 hardware and signal processing is closed and undocumented, too
+		\item Known attempts
+		\begin{itemize}
+			\item The TSM30 project as part of the THC GSM project
+			\item mados, an alternative OS for Nokia DTC3 phones
+		\end{itemize}
+		\item none of those projects successful so far
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Security analysis of GSM}{The bootstrapping process}
+\begin{itemize}
+	\item Read GSM specs day and night (> 1000 PDF documents)
+	\item Gradually grow knowledge about the protocols
+	\item Obtain actual GSM network equipment (BTS, MS tester, ...)
+	\item Try to get actual protocol traces as examples
+	\item Start a complete protocol stack implementation from scratch
+	\item Finally, go and play with GSM protocol security
+\end{itemize}
+\end{frame}
+
+\subsection{The GSM network}
+
+\begin{frame}{The GSM network}
+  \begin{figure}[h]
+  \centering
+  \includegraphics[width=100mm]{gsm_network.png}
+  \end{figure}
+\end{frame}
+
+\begin{frame}{GSM network components}
+  \begin{itemize}
+    \item The BSS (Base Station Subsystem)
+    \begin{itemize}
+      \item MS (Mobile Station): Your phone
+      \item BTS (Base Transceiver Station): The {\em cell tower}
+      \item BSC (Base Station Controller): Controlling up to hundreds of BTS
+    \end{itemize}
+    \item The NSS (Network Sub System)
+    \begin{itemize}
+      \item MSC (Mobile Switching Center): The central switch
+      \item HLR (Home Location Register): Database of subscribers
+      \item AUC (Authentication Center): Database of authentication keys
+      \item VLR (Visitor Location Register): For roaming users
+      \item EIR (Equipment Identity Register): To block stolen phones
+    \end{itemize}
+  \end{itemize}
+\end{frame}
+
+\begin{frame}{GSM network interfaces}
+  \begin{itemize}
+    \item Um: Interface between MS and BTS
+    \begin{itemize}
+	\item the only interface that is specified over radio
+    \end{itemize}
+    \item A-bis: Interface between BTS and BSC
+    \item A: Interface between BSC and MSC
+    \item B: Interface between MSC and other MSC
+  \end{itemize}
+  GSM networks are a prime example of an asymmetric distributed network,
+  very different from the end-to-end transparent IP network.
+\end{frame}
+
+
+\subsection{The GSM protocols}
+
+\begin{frame}{GSM network protocols}{On the Um interface}
+  \begin{itemize}
+    \item Layer 1: Radio Layer, TS 04.04
+    \item Layer 2: LAPDm, TS 04.06
+    \item Layer 3: Radio Resource, Mobility Management, Call Control: TS 04.08
+    \item Layer 4+: for USSD, SMS, LCS, ...
+  \end{itemize}
+\end{frame}
+
+\section{Security Problems and the Baseband}
+
+\subsection{Theory}
+
+\begin{frame}{Known GSM security problems}{Scientific papers, etc}
+\begin{itemize}
+	\item No mutual authentication between phone and network
+	\begin{itemize}
+		\item leads to rogue network attacks
+		\item leads to man-in-the-middle attacks
+		\item is what enables IMSI-catchers
+	\end{itemize}
+	\item Weak encryption algorithms
+	\item Encryption is optional, user does never know when it's active or not
+	\item DoS of the RACH by means of channel request flooding
+	\item RRLP (Radio Resource Location Protocol)
+	\begin{itemize}
+		\item the network can obtain GPS fix or even raw GSM data from the phone
+		\item combine that with the network not needing to authenticate itself
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\subsection{The Baseband}
+
+\begin{frame}{Known GSM security problems}{The Baseband side}
+\begin{itemize}
+	\item GSM protocol stack always runs in a so-called baseband processor (BP)
+	\item What is the baseband processor
+	\begin{itemize}
+		\item Typically ARM7 (2G/2.5G phones) or ARM9 (3G/3.5G phones)
+		\begin{itemize}
+			\item Runs some RTOS (often Nucleus, sometimes L4)
+			\item No memory protection between tasks
+		\end{itemize}
+		\item Some kind of DSP, model depends on vendor
+		\begin{itemize}
+			\item Runs the digital signal processing for the RF Layer 1
+			\item Has hardware peripherals for A5 encryption
+		\end{itemize}
+	\end{itemize}
+	\item The software stack on the baseband processor
+	\begin{itemize}
+		\item is written in C and assembly
+		\item lacks any modern security features (stack protection, non-executable pages, address space randomization, ..)
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{A GSM Baseband Chipset}
+  \begin{figure}[h]
+  \centering
+  \includegraphics[width=100mm]{calypso-block.pdf}
+  \end{figure}
+  \url{http://laforge.gnumonks.org/papers/gsm_phone-anatomy-latest.pdf}
+\end{frame}
+
+
+\subsection{Observations}
+
+\begin{frame}{Interesting observations}{Learned from implementing the stack}
+While developing OpenBSC, we observed a number of interesting
+\begin{itemize}
+	\item Many phones use their TMSI from the old network when they roam to a new network
+	\item Various phones crash when confronted with incorrect messages.  We didn't even start to intentionally send incorrect messages (!)
+	\item There are tons of obscure options on the GSM spec which no real network uses.  Potential attack vector by using rarely tested code paths.
+\end{itemize}
+\end{frame}
+
+\subsection{GSM Protocol Fuzzing}
+
+\begin{frame}{GSM Protocol Fuzzing}{Theoretical basis}
+How to do GSM protocol fuzzing
+\begin{itemize}
+	\item From the handset to the network
+	\begin{itemize}
+		\item Basically impossible due to closeness of baseband
+		\item However, some incomplete projects working on it
+	\end{itemize}
+	\item From the network side
+	\begin{itemize}
+		\item Easy in case of {\em rogue network} attacks
+		\item Fuzzing target is the GSM stack in the baseband processor
+	\end{itemize}
+	\item As an A-bis man in the middle
+	\begin{itemize}
+		\item Needs access to an A-bis interface of an actual network
+		\item Very attractive, since no encryption and ability to fuzz both network and handset
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{scapy GSM support}{The actual fuzzing}
+How to actually craft the packets for the fuzzing
+\begin{itemize}
+	\item GSM has many, many protocols
+	\item Writing custom code will be a hard-coded special case for each of them
+	\item Solution: Use scapy and implement the GSM protocols as scapy "layers"
+	\begin{itemize}
+		\item IPA protocol header
+		\item RSL protocol layer
+		\item RLL data indication / data request
+		\item GSM 04.08 RR / MM / CC messages
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\section{OsmocomBB Project}
+
+\subsection{OsmocomBB Introduction}
+
+\begin{frame}{OsmoocmBB Introduction}
+\begin{itemize}
+	\item Project was started in January 2010
+	\item Implementing a GSM baseband software from scratch
+	\item This includes
+	\begin{itemize}
+		\item GSM MS-side protocl stack from Layer 1 through Layer 3
+		\item Hardware drivers for GSM Baseband chipset
+		\item Simple User Interface on the phone itself
+		\item Verbose User Interface on the PC
+	\end{itemize}
+	\item Note about the strange project name
+	\begin{itemize}
+		\item Osmocom = Open Source MObile COMmunication
+		\item BB = Base Band
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\subsection{OsmocomBB Architecture}
+
+\begin{frame}{OsmoocmBB Software Architecture}
+\begin{itemize}
+	\item Reuse code from OpenBSC where possible (libosmocore)
+	\begin{itemize}
+		\item We build libosmocore both for phone firmware and PC
+	\end{itemize}
+	\item Initially run as little software in the phone
+	\begin{itemize}
+		\item Debugging code on your host PC is so much easier
+		\item You have much more screen real-estate
+		\item Hardware drivers and Layer1 run in the phone
+		\item Layer2, 3 and actual phone application / MMI on PC
+		\item Later, L2 and L3 can me moved to the phone
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmoocmBB Software Interfaces}
+\begin{itemize}
+	\item Interface between Layer1 and Layer2 called L1CTL
+	\begin{itemize}
+		\item Fully custom protocol as there is no standard
+		\item Implemented as message based protocol over Sercomm/HDLC/RS232
+	\end{itemize}
+	\item Interface between Layer2 and Layer3 called RSLms
+	\begin{itemize}
+		\item In the GSM network, Um Layer2 terminates at the BTS but is controlled  by the BSC
+		\item Reuse this GSM 08.58 Radio Signalling Link
+		\item Extend it where needed for the MS case
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\subsection{OsmocomBB Software}
+
+\begin{frame}{OsmoocmBB Target Firmware}
+\begin{itemize}
+	\item Firmware includes software like
+	\begin{itemize}
+		\item Drivers for the Ti Calypso Digital Baseband (DBB)
+		\item Drivers for the Ti Iota TWL3025 Analog Baseband (ABB)
+		\item Drivers for the Ti Rita TRF6151 RF Transceiver
+		\item Drivers for the LCD/LCM of a number of phones
+		\item CFI flash driver for NOR flash
+		\item GSM Layer1 synchronous/asynchronous part
+		\item Sercomm - A HDLC based multiplexer for the RS232 to host PC
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmoocmBB Host Software}
+\begin{itemize}
+	\item Current working name: layer23
+	\item Includes
+	\begin{itemize}
+		\item Layer 1 Control (L1CTL) protocol API
+		\item GSM Layer2 implementation (LAPDm)
+		\item GSM Layer3 implementation (RR/MM/CC)
+		\item GSM Cell (re)selection
+		\item SIM Card emulation
+		\item Supports various 'apps' depending on purpose
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\subsection{OsmocomBB Hardware Support}
+
+\begin{frame}{OsmoocmBB Supported Hardware}
+\begin{itemize}
+	\item Baseband Chipsets
+	\begin{itemize}
+		\item TI Calypso/Iota/Rita
+		\item Some early research being doen on Mediatek (MTK) MT622x
+	\end{itemize}
+	\item Actual Phones
+	\begin{itemize}
+		\item Compal/Motorola C11x, C12x, C13x, C14x and C15x models
+		\item Most development/testing on C123 and C155
+		\item GSM modem part of Openmoko Neo1973 and Freerunner
+	\end{itemize}
+	\item All those phones are simple feature phones built on a ARM7TDMI based DBB
+\end{itemize}
+\end{frame}
+
+\begin{frame}{The Motorola/Compal C123}
+ \begin{figure}[h]
+  \centering
+  \includegraphics[width=100mm]{c123_pcb.jpg}
+  \end{figure}
+\end{frame}
+
+
+\subsection{OsmocomBB Project Status}
+
+\begin{frame}{OsmoocmBB Project Status: Working}
+\begin{itemize}
+	\item Hardware Drivers for Calypso/Iota/Rita very complete
+	\item Layer1 
+	\begin{itemize}
+		\item Power measurements 
+		\item Carrier/bit/TDMA synchronization
+		\item Receive and trnasmit of normal bursts on SDCCH
+		\item Transmit of RACH bursts
+	\end{itemize}
+	\item Layer2 UI/SABM/UA frames
+	\item Layer3 Messages for RR / MM / CC
+	\item Cell (re)selection according GSM 03.22
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmoocmBB Project Status: Not working}
+\begin{itemize}
+	\item Actual SIM card reader inside phone (WIP)
+	\item Layer1 
+	\begin{itemize}
+		\item Automatic Tx power control (APC)
+		\item Automatic Rx gain control (AGC)
+		\item Frequency Hopping
+		\item Neighbor Cell Measurements
+		\item Traffic Channels (TCH)
+	\end{itemize}
+	\item Layer2 Asynchronous Balanced Mode (ACK/retransmissions)
+	\item Actual UI on the phone
+	\item Drivers for Audio/Voice signal path
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmoocmBB Project Status: Executive Summary}
+\begin{itemize}
+	\item We can esetablish control/signalling channels with non-hopping cells
+	\begin{itemize}
+		\item Used in small single-TRX cells in rural areas
+		\item Used in GSM-R networks
+		\item As provided by OpenBSC + OpenBTS
+	\end{itemize}
+	\item We can send arbitrary data on those control channels
+	\begin{itemize}
+		\item RR messages to BSC
+		\item MM/CC messages to MSC
+		\item SMS messages to MSC/SMSC
+	\end{itemize}
+	\item Adding frequency hopping support not very hard
+\end{itemize}
+\end{frame}
+
+
+\section{Summary}
+
+\subsection{What we've learned}
+
+\begin{frame}{Summary}{What we've learned}
+\begin{itemize}
+	\item The GSM industry is making security analysis very difficult
+	\item It is well-known that the security level of the GSM stacks is very low
+	\item We now have multiple solutions for sending arbitrary protocol data
+	\begin{itemize}
+		\item From a rogue network to phones (OpenBSC, OpenBTS)
+		\item From an A-bis proxy to the network or the phones
+		\item From custom GSM phone baseband firmware to the network
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\subsection{Where we go from here}
+
+\begin{frame}{TODO}{Where we go from here}
+\begin{itemize}
+	\item The basic tools for fuzzing mobile networks are available
+	\item No nice interface/integration from OsmocomBB to scapy yet
+	\item It is up to the security community to make use of those tools (!)
+	\item Don't you too think that TCP/IP security is boring
+	\item Join the GSM protocol security research projects
+	\item Boldly go where no man has gone before
+\end{itemize}
+\end{frame}
+
+\subsection{Further Reading}
+
+\begin{frame}{Further Reading}
+\begin{itemize}
+	\item \url{http://laforge.gnumonks.org/papers/gsm_phone-anatomy-latest.pdf}
+	\item \url{http://bb.osmocom.org/}
+	\item \url{http://openbsc.gnumonks.org/}
+	\item \url{http://openbts.sourceforge.net/}
+	\item \url{http://airprobe.org/}
+\end{itemize}
+\end{frame}
+
+\end{document}
diff --git a/2010/osmocombb-phneutral2010/outline.txt b/2010/osmocombb-phneutral2010/outline.txt
new file mode 100644
index 0000000..d7799fa
--- /dev/null
+++ b/2010/osmocombb-phneutral2010/outline.txt
@@ -0,0 +1,41 @@
+
+what is osmocombb
+ name
+ goals
+
+supported hardware
+ baseband chipset
+ actual phone
+
+gsm phone anatomy
+
+OsmocomBB software architecture
+ libosmocore
+ firmware
+ l1ctl interface
+ layer23 on the host
+
+ firmware
+  calypso hardware drivers
+   clock, dma, dsp-api, i2c, irq, keypad, rtc, spi, timer, tpu, tsp, uart, uwire, backlight
+  LCM driver
+  CFI flash driver
+  ABB driver (TWL3025)
+  RF driver (TRF6151)
+  GSM layer1 sync/async
+  sercomm (HDLC variant)
+  
+
+ host software ('layer23')
+  l1ctl protocol wrapper
+  layer2 (LAPDm) implementaiton
+  layer3 (RR/MM/CC) imcplementation
+  GSM 03.22 cell (re)selection
+  
+
+project status
+
+help needed
+ actual UI on the phone
+ port layer1 to Mediatek/MTK chipsets (lots of reversing)
+