phdays.com, phdays.ru Moscow, 2012 Day2, Track1, 09:00 Sylvain Munaut, Abusing Calypso phones Sylvain Munaut last 3 years with GSM doing it as a hobby Why modify hardware cheap way to play with the protocol there are tools, but with limitations access to only layer2 and up require expensive hardware Target hardware motorola c123 chosen because supported by osmocombb it's a reference implementation there are plenty phones based on calypso ti really cheap phone, easy to find even if broken Will look into Um interface between MS and BTS GSM Um layer1 several GSM bands uplink (UL): phone -> network downlink (DL): network -> phone freq domain duplexing there are channels -> frequency translation GSM Um layer1 Fully synchronous BTS is the clock master it is a TDMA (nightmare) frames -> timeslots -> bursts of transmission 4 types of bursts: normal bursts -> more than 90% of the traffic frequency correction burst (FCCH): sent by BTQ sync burst (SCH): sent by BTS access burst (RACH): sent by MS to request a channel History OsmocomBB - FOSS implementation of a BB gives control ONLY over layer2 and layer3 didn’t provide enough flexibility for Sylvain’s research Why Layer1? Ciphering is applied in Layer1 Gives power to play with bits for various ciphering/crypto attack Follow freq hopping Save uplink and downlink Typical RX chain Antenna - can be replaced RX filter - can be removed if needed ignore the problem - in a lab the signal is strong, the filter cannot filter efficiently otherwise - requires removing, soldering skills RF mixer - selects which freq the phone is received for UL - it is designed for it, works fine for DL - needs removal to be able to tune to required freq Analog baseband - no problem to remove, it's just an ADC DSP-core ROM based, cannot change :( ARM-core running the OsmocomBB firmware, can be modified just fine, we have full control (break the keys, send traffic to wireshark, etc.) DSP-core problems TI has/needs a way to patch bugs means there is way to patch the ROM ARM is the master -> DSP will execute the tasks from ARM There is NO "sniff the network" task Need to implement one DSP has a bootloader to upload code and execute in RAM didn't work " - TI security feature, when executing from RAM, the ROM is locked :( the fix is - in ROM there must be a memcpy() so that it can be used to bypass bruteforced the location of the memcpy() location in the ROM (neat! – bruteforcer source is lost, but can be recreated based on TODO.c by going over memory location, calling the address as if it was memcpy and see if the memcpy occured) took about one day/evening to dump so, using memcpy able to read/dump the ROM -> then load into RAM DSP ROM have the word by word copy of the ROM loaded into IDA PRO known entry point (how?) CPU of DSP is supported by IDAPro seems like written by different teams/devs no calling conventions some routines are very optimized reading ASM code for an unknown architecture is a pain there are a lot of indirect calls calls a function pointer and the pointer is in the RAM DSP patching works by modifying a DSP function pointer tables idea is to modify the function pointers the modified table/pointers are load in the bootloader process uses interrupts and IO access to trace importan functions RAM interrupt DMA interrupt A5 unit IO DMA unit IO – for burst RX buffer RIF unit IO – for burst TX buffer putting it all together allows to write any bits we want to the ARM without any modulation problems Current work modify a phone to act as a BTS not interested in doing FULL COMPLIANT BTS but want SMS, voice calls, etc i.e. provide minimal service BTS motivation another cheap tool for GSM research portable fake BTS just prove it's doable idea is not new first theoretical post about 2 years ago on the list (TODO find the post) MS vs BTS the roles/frequencies are reversed the upper layers can be run on the PC and modified in the FOSS sources receiving bursts and the low level functionality at layer1 is harder to do layer1: annoying is that BTS is continuously transmitting even though it has nothing to transmit because phones look for a high-power RF channel to tune into to keep it cheap, BTS not necessarily tx/rx simultaneously (receive, 3 frames later can switch to transmit) transmit FCCH/TCH receive RACH clock master requires a stable enough reference, otherwise the phones will not lock onto your fake (phone-emulated!) BTS Phone as a BTS the TX/RX chain is pretty much there in the hardware create DSP patch look at TX path for transmit arbitrary data required multi slot TX cannot transmit all the time but need to do your best drives the power amplifier a little bit since it's above the specs re-use OpenBTS as it is for the upper layers 1st process - does the main job, calls smaller tasks 2nd process - a small task _tranceive_ job need just to reimplement the _tranceive_ job duplex sol1: use 3 phones, hard because need to externally synchronize all of them, TODO recall other reasons sol2: not 100% reliable, but works most of the time - tx as much as you can, and then RX and do your best Tt.R.ttt (T) real BTS-like transmit, then (t) noise to be there on the channel, then switch to RX which is (.) a dead slot, then (R) receive RX from captured mobile phones, then switch again (.) to transmit, then 3 more noise (t) transmits TX it provides ONLY 1 channel, but works it doesn't allow voice calls but SMS, LU, etc. are supported clock sync brilliant idea - use a commercial cell to lock onto because the phone already has this code and functionality, then it's the first thing they tried :) use this clock reference and our fake BTS/sniff phone will relay to other phones the clock reference (acquired from the commercial/surrounding BTS) other option remove the 64mhz oscillator and replace with a very precise, temperature-stable clock source, would be nice to be able to hook suck a clock directly to some exposed pins of the phone and with smallest hardware modifications to deliver this clock signal to appropriate pins on the board Stability issues when it works -> works reliably when it doesn't work -> it doesn't work reliably either :) the random behaviour is dictated by the Fn(the clock reference cell, the current cell the phone camps on), result may vary demo registered to the demo then got the welcome SMS form the OpenBTS Thanks Dieter Spaar LaF0rge David Burgess Andreas "jolly" TODO Docs wiki with Sylvain Munaut Present @ hackspace neuron friday 19:30 (calypso, gsm, openbts) staruday 17:30 (tetra, gmr)