MobiDeke Fuzzing the GSM Protocol Stack

More documents

Recommendations

Info

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

IntroductionFuzzing over-the-airThe MobiDeke FrameworkConclusionTestcases generation and mutationMonitoringReportFuture enhancementCheck the reserved channel: ’over-the-air’Motivations• OpenBTS crashes a lot! During that time your fuzzer continues to sendpayloads...• 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 statesin OpenBTS.• Send ‘ping’ requests to the baseband ‘over-the-air’• Send a IDENTITY REQUEST, the mobile will respond with an IDENTITYRESPONSEMobiDeke: Fuzzing the GSM Protocol Stack 25/38
IntroductionFuzzing over-the-airThe MobiDeke FrameworkConclusionTestcases generation and mutationMonitoringReportFuture enhancementCheck ‘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 openedsocket.• 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
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 27: IntroductionFuzzing over-the-airThe
Page 37 and 38: 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?