1. The document describes a framework called MobiDeke that was created to fuzz the GSM protocol stack over-the-air by generating and mutating malformed GSM messages and monitoring the target's behavior for crashes or errors. 2. MobiDeke addresses limitations with existing fuzzing methods by automating the generation, mutation, transmission and monitoring processes. 3. The key components of MobiDeke are modules for generating and mutating GSM messages, transmitting payloads over-the-air via a software-defined radio, and monitoring the target phone and base station for crashes or abnormal behavior.

1. MobiDeke: Fuzzing the GSM Protocol Stack
S´ebastien Dudek
Guillaume Delugr´e
Sogeti / ESEC
Hack.lu 2012

2. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Who we are
S´ebastien Dudek
• Has joined the ESEC R&D lab this year (2012) after his internship
• Subject: Attacking the GSM Protocol Stack
• Developer of a GSM fuzzing framework (‘MobiDeke’)
Guillaume Delugr´e
• Researcher working at Sogeti ESEC R&D lab
• Working on embedded devices / reverse engineering
• Developer of ‘qcombbdbg’ (Qualcomm 3G key Icon255 debugger) and
‘Origami’
MobiDeke: Fuzzing the GSM Protocol Stack 2/38

3. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Summary
1 Introduction
2 Fuzzing over-the-air
3 The MobiDeke Framework
4 Conclusion
MobiDeke: Fuzzing the GSM Protocol Stack 3/38

4. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
The GSM (2G) network
MobiDeke: Fuzzing the GSM Protocol Stack 4/38

5. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
User Equipments (mobile phones)
Radio control functions are highly timing dependant, so most of the phones use
two separated CPUs nowadays
The application processor
• Runs the user OS: Android, iOS, Windows Mobile, and so on
• Documented (often)
The baseband processor
• Responsible for handling telecommunications
• Includes stacks for telephony protocols
• Closed binary blob running RTOS
See the talk of Guillaume at 28c3 (Chaos Computer Congress) for more
information.
MobiDeke: Fuzzing the GSM Protocol Stack 5/38

6. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Existing attacks
Many papers have been published:
• Harald Welte: Fuzzing your GSM phone using OpenBSC (2009);
• Collin Mulliner: Fuzzing the Phone in your Phone (2009);
• Collin Mulliner, Nico Golde and Jean-Pierre Seifert : SMS of Death: from
analyzing to attacking mobile phones on a large scale (2011);
• Nico Golde: SMS Vulnerability Analysis on Feature Phones (2011);
• Ralf-Philipp Weinmann: Baseband Attacks, WOOT 2012
• ...
MobiDeke: Fuzzing the GSM Protocol Stack 6/38

7. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
What we are looking for
• The baseband: new angle of attack
• Setup a network is easy today thanks to SDR contributions (OpenBTS,
OpenBSC, and so on)
⇒ Attacking a cellphone ‘over-the-air’ could be fun! (+ not completely
explored)
Typical scenario
• The attacker controls a rogue base station
• The victim joins the cell and gets remotely exploited
*SDR: Software-Defined Radio
MobiDeke: Fuzzing the GSM Protocol Stack 7/38

8. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
To reach our goal
• Baseband code is proprietary
How to find bugs?
• Reverse-engineering: Hard because the code is very complex
• Fuzzing: The easier way, but need some knowledge and a radio device like
the USRP (we’ve won one at hack.lu;) or a nanoBTS, UmTRX, Phi card...
For more information: Harald Welte’s presentation at SSTIC 2010 gives also a
good overview of the GSM industry and security
MobiDeke: Fuzzing the GSM Protocol Stack 8/38

9. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Fuzzing
4 very important points
• Choose your target
• Targeting the baseband GSM stack (2G), not 3G, HSDPA, LTE...
• SMS are usually not parsed by the baseband (passed as raw PDUs to the APP)
• Smartphones: HTC Desire S, Desire Z, iPhone 4S. . .
• Inject malformed data
• Monitor target activity
• Classify bugs, behaviours
MobiDeke: Fuzzing the GSM Protocol Stack 9/38

10. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Fuzzing
4 very important points
• Choose your target
• Inject malformed data
• Smart generation of GSM packets (specs, existing librairies. . . )
• Mutate each field of the generated message (describe a structure with Sulley)
• Monitor target activity
• Classify bugs, behaviours
MobiDeke: Fuzzing the GSM Protocol Stack 9/38

11. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Fuzzing
4 very important points
• Choose your target
• Inject malformed data
• Monitor target activity
• Quite difficult because we don’t have a debugger
• Check if the phone is responding
• Look for strange behaviors / side-effects
• ...
• Classify bugs, behaviours
MobiDeke: Fuzzing the GSM Protocol Stack 9/38

12. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Fuzzing
4 very important points
• Choose your target
• Inject malformed data
• Monitor target activity
• Classify bugs, behaviours
• Crash reporting: report with indicators
• Replay the recorded payload and see what happens
MobiDeke: Fuzzing the GSM Protocol Stack 9/38

13. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Summary
1 Introduction
2 Fuzzing over-the-air
3 The MobiDeke Framework
4 Conclusion
MobiDeke: Fuzzing the GSM Protocol Stack 10/38

14. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
GSM layers
Layers
• Layer 3
• Radio Ressource: Channel set up and
tear-down
• Mobility Management: User location...
• Connection Management: Call (CC),
SMS and other services
• Layer 2
• Fragmentation
• Integrity check
• Layer 1
• Transfers data over the air interface
• Uses GMSK modulation
• F/TDMA for multiple accesses
MobiDeke: Fuzzing the GSM Protocol Stack 11/38

15. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
L3 Messages structure
There are 5 standards defining information elements (described in 11.1.14 in the
TS 04.07)
MobiDeke: Fuzzing the GSM Protocol Stack 12/38

16. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
State Machines: Originating a Call example (simplified)
SETUP
ASSIGNMENT
MS:CALL_CONFIRMED
END
RELEASE
RELEASE
CONNECT
ASSIGNMENT_COMPLET
RELEASE SPEAK
BTS:CONNECT_ACK
RELEASE
Observations
• There is often a way to exit from a
state machine (e.g.: The RELEASE
message)
• Sometimes a state requires user
interaction
• There are ‘obscure’ elements: present
in specs, but never seen in real life. . .
MobiDeke: Fuzzing the GSM Protocol Stack 13/38

17. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Message exchanges
Some message exchanges can be considered as stateless, but there are also finite
state machines
Stateless exchanges
• Simple to fuzz
Finite state machines
• Complex and harder to fuzz
• Also harder to program correctly: potential surprises
MobiDeke: Fuzzing the GSM Protocol Stack 14/38

18. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Let’s fuzz it!
We have set up our network with OpenBTS as follows
But how to send a payload to a targeted cellphone? ⇒ Use the ‘testcall’
feature
MobiDeke: Fuzzing the GSM Protocol Stack 15/38

19. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
The ‘testcall’ feature
The ‘testcall’ feature
• Included in OpenBTS (since 2.5 version) and OpenBSC
• Opens a channel for each targeted IMSI*
• The channel ties to an UDP socket on local computer
• Takes packets as Layer 3 messages and forwards them to the mobile
*IMSI: International Mobile Subscriber Identity
MobiDeke: Fuzzing the GSM Protocol Stack 16/38

20. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Fuzzing problems...
Testcall exists for fuzzing handsets, but it’s not enough because
• It works for a limited time
• OpenBTS crashes a lot
• The reserved channel is not very stable
• You’re stuck to your chair while trying to send all your testcases...
• What about the monitoring?
MobiDeke: Fuzzing the GSM Protocol Stack 17/38

21. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Testcases generation and mutation
Monitoring
Report
Future enhancement
Summary
1 Introduction
2 Fuzzing over-the-air
3 The MobiDeke Framework
Testcases generation and mutation
Monitoring
Report
Future enhancement
4 Conclusion
MobiDeke: Fuzzing the GSM Protocol Stack 18/38

22. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Testcases generation and mutation
Monitoring
Report
Future enhancement
MobiDeke?
To perform our fuzzing tests, we created a framework that:
• Generates and mutates L3 messages
• Sends payload ‘over-the-air’
• Checks if a handset is ready to receive our payload
• Monitors states (Phone and BTS)
• Records a final report
MobiDeke: Fuzzing the GSM Protocol Stack 19/38

23. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Testcases generation and mutation
Monitoring
Report
Future enhancement
MobiDeke Architecture Diagram
MobiDeke: Fuzzing the GSM Protocol Stack 20/38

24. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Testcases generation and mutation
Monitoring
Report
Future enhancement
MobiDeke: Data generation and mutation
MobiDeke: Fuzzing the GSM Protocol Stack 21/38

25. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Testcases generation and mutation
Monitoring
Report
Future enhancement
Methods for data generation and mutation
Creating crafted L3 messages
• Dumb: using captures (MBUS Nokia, OsmocomBB...) and bit-flipping
• Smarter: knowing the structure of the messages
• gsm um for scapy: interesting but not complete
• libmich developed by Benoˆıt Michau: we have chosen this solution for the
most part
Mutations
• ‘libmich’ Mutor
• Sulley mutation engine
It is better to combine multiple generation methods to cover as much testcases as
possible.
MobiDeke: Fuzzing the GSM Protocol Stack 22/38

26. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Testcases generation and mutation
Monitoring
Report
Future enhancement
MobiDeke: Monitoring
MobiDeke: Fuzzing the GSM Protocol Stack 23/38

27. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Testcases generation and mutation
Monitoring
Report
Future enhancement
Methods used to monitor crashes
Problems
• Blackbox monitoring
• Did the baseband crash?
Solutions
• Check if the baseband still responds correctly to ‘AT’ commands
• Look for bugs on the application processor by checking crashlogs
• Check the radio channel state reserved by OpenBTS
MobiDeke: Fuzzing the GSM Protocol Stack 24/38

28. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Testcases generation and mutation
Monitoring
Report
Future enhancement
Check the reserved channel: ’over-the-air’
Motivations
• OpenBTS crashes a lot! During that time your fuzzer continues to send
payloads...
• Is the reserved channel stable enough?
• Is the baseband ready to receive the next payload?
• Did the baseband crash?
Solutions
• Check the radio channel state regularly ⇒ Transaction entries, paging states
in OpenBTS.
• Send ‘ping’ requests to the baseband ‘over-the-air’
• Send a IDENTITY REQUEST, the mobile will respond with an IDENTITY
RESPONSE
MobiDeke: Fuzzing the GSM Protocol Stack 25/38

29. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Testcases generation and mutation
Monitoring
Report
Future enhancement
Check ‘AT’ responses with the ’injecATor’ locally
• We checked for phone responsiveness on the radio side
• What about on the local interface?
We modified Collin Mulliner’s ‘injector’ to forward ‘AT’ responses over the opened
socket.
• Lack of AT response can indicate a baseband crash/reboot
• Can also be used to simulate user interactions (e.g. accept a phone call)
MobiDeke: Fuzzing the GSM Protocol Stack 26/38

30. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Testcases generation and mutation
Monitoring
Report
Future enhancement
Application OS bug report
• Even though we are targeting the baseband, some messages still get parsed
by the application OS
• Can be the case for SMSs, Information Messages.. . .
MobiDeke: Fuzzing the GSM Protocol Stack 27/38

31. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Testcases generation and mutation
Monitoring
Report
Future enhancement
Logfiles: Android logcats
Some useful data...
• When something crashes, it is likely to be reported in the logcat (Android
syslogs)
Extract the information
• Fetch the logs using adb and filter this information
• Check for any known vocabulary in the log that could be related to a crash:
‘***’, ‘uncaught exception’, ‘Error Process’...
MobiDeke: Fuzzing the GSM Protocol Stack 28/38

32. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Testcases generation and mutation
Monitoring
Report
Future enhancement
Logfiles: iOS CrashReporter
• iOS CrashReporter records application bugs
• Path: /var/wireless/Library/Logs/CrashReporter
Note: On Infineon X-Gold (iPhone 1 to iPhone 3) it’s possible to save baseband
core dumps in ‘CrashReporter’ if the CORE option is enabled.
MobiDeke: Fuzzing the GSM Protocol Stack 29/38

33. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Testcases generation and mutation
Monitoring
Report
Future enhancement
The final report
Indicators
• 0: The state changed, but everything is fine
• 1: The baseband takes a little bit longer to respond
• 2: Maybe something happened (takes to long to respond, applicative crash...)
• 3: It is probably a crash (can’t talk with the baseband at all...)
• ...
You can define new indicators depending on your analysis.
MobiDeke: Fuzzing the GSM Protocol Stack 30/38

34. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Testcases generation and mutation
Monitoring
Report
Future enhancement
Sample of a crash in the report
<?xml v e r s i o n =”1.0” ?>
<report >
<i nformat i ons>
<s t art ed>
Fri , 07 Sep 2012 16:18:47
</s t art ed>
<f i n i s h e d>
Fri , 07 Sep 2012 16:21:07
</f i n i s h e d>
</i nformat i ons>
<events>
<event time =”16:18:49” i d =”0” l a s t p a y l o a d=”1658” l e v e l =”0”>
Fuzzing ( re ) s t a r t e d
</event>
<event time =”16:19:52” i d =”1” l a s t p a y l o a d=”1665” l e v e l =”2”>
AT answer : Timeout !
</event>
<event time =”16:19:54” i d =”2” l e v e l=”0”>
AT i s working once again
</event>
<event time =”16:20:00” i d =”3” l a s t p a y l o a d=”1666” l e v e l =”3”>
AT E rror
</event>
<event time =”16:20:04” i d =”4” l e v e l=”0”>
AT i s working once again
</event>
<event time =”16:20:57” i d =”5” l a s t p a y l o a d=”1674” l e v e l =”4”>
AT answer : Strange Oo!
</event>
</events>
</report >
MobiDeke: Fuzzing the GSM Protocol Stack 31/38

35. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Testcases generation and mutation
Monitoring
Report
Future enhancement
Monitoring enhancement
• Hard without a debugger: a lot of states to check
• We lately managed to get a qcombbdbg running on some phones: HTC
Desire S/Z
• It’s also possible to debug using the JTAG interface and additional hardware
(e.g.: RIFFBOX)
• With a debugger: we don’t need heuristics to detect crashes
MobiDeke: Fuzzing the GSM Protocol Stack 32/38

36. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Testcases generation and mutation
Monitoring
Report
Future enhancement
Demo!
The fuzzing platform (injecATor, OpenBTS and MobiDeke)
MobiDeke: Fuzzing the GSM Protocol Stack 33/38

37. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Summary
1 Introduction
2 Fuzzing over-the-air
3 The MobiDeke Framework
4 Conclusion
MobiDeke: Fuzzing the GSM Protocol Stack 34/38

38. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Problems
• Mostly the unstability of OpenBTS for fuzzing tests
• Deadlocked phones can require human intervention to reboot
• Did not have time to test all layers yet:
• A lot of fixes required on the monitoring part
• Checking the phone state slows down fuzzing
• We don’t have debuggers for every phone models
• A debugger is always needed to decide about exploitability
MobiDeke: Fuzzing the GSM Protocol Stack 35/38

39. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Our results
• MobiDeke is a handy way to automate fuzzing tests on GSMs
• Not a lot of bugs have been found with stateless messages
• MM INFORMATION: few DoS and applicative crashes
• TMSI RELOCATION COMMAND: few DoS
• 1 state of Call Origin: 1 crash and a lot of DoS
• LOCATION UPDATING: not tested completely, few DoS
• A fuzzing test takes time: days, weeks or months (depends on the number of
testcases and complexity)
*DoS: The phone was not responding
MobiDeke: Fuzzing the GSM Protocol Stack 36/38

40. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Todo
• There are still plenty of vectors to fuzz
• Integration with a debugger (e.g. JTAG)
• Implement state machines
• Source code not to be released at the moment
MobiDeke: Fuzzing the GSM Protocol Stack 37/38

41. Introduction
Fuzzing over-the-air
The MobiDeke Framework
Conclusion
Thank you! ;)
Any questions?
MobiDeke: Fuzzing the GSM Protocol Stack 38/38