MobiDeke Fuzzing the GSM Protocol Stack

More documents

Recommendations

Info

$\H1B%-12345X@PJL JOB “HackingPrinters”$

IntroductionFuzzing over-the-airThe MobiDeke FrameworkConclusionProblems• 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 exploitabilityMobiDeke: Fuzzing the GSM Protocol Stack 35/38
IntroductionFuzzing over-the-airThe MobiDeke FrameworkConclusionOur 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 oftestcases and complexity)*DoS: The phone was not respondingMobiDeke: Fuzzing the GSM Protocol Stack 36/38
Page 1: MobiDeke: Fuzzing the GSM Protocol
Page 8 and 9: IntroductionFuzzing over-the-airThe
Page 18 and 19: Let’s fuzz it!IntroductionFuzzing
Page 37: SummaryIntroductionFuzzing over-the
Page 41: IntroductionFuzzing over-the-airThe

MobiDeke Fuzzing the GSM Protocol Stack

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?