Portál AbcLinuxu, 5. května 2025 22:06
Je zřejmé, že na bezdrátovém principu není proto vhodné stavět kritické technologie, jako například zabezpečení budov posílající SMS notifikaci a volající policii přes GSM. Leč mnozí tak činí.Rejp do ecallu?
Nefungují mi příchozí hovory (to už prý mají nejnovější implementace IMSI catcherů nějak vyřešené, ale vůbec netuším, jak).Může mobil donutit BTS k nešifrování, nebo musí poslechnout inicializaci od BTS?
A5/1 lze navíc „backclockovat“ – s o něco vyššími nároky na výkon lze obrátit směr, kterým se posouvají bity v posuvných registrech, a po chvíli počítání získat i počáteční stav šifry a z něj klíč. Tedy zjištěním vnitřního stavu v jakémkoli okamžiku používání šifry jste schopni dešifrovat celou komunikaci.Hmm na tohle by to chtělo nedeterministický automat
Případnému útočníkovi, který se snaží komunikaci odposlechnout, tohle ale může způsobit komplikace, protože se musí přelaďovat přesně stejně jako vysílač. ... Buď nahrajeme celé pásmo a až crackneme klíč, doskáčeme si v tom zpětně. To vyžaduje drahé rádio, které dokáže celé pásmo zachytit.Jsem původně reagoval jenom na to první (je to moc daleko od sebe
K nim budou potřeba sériové převodníky (4portový FTDI za 700 Kč)ROFL převodník stojí víc než mobil? :-O
Nejlepší by bylo upgradovat z 25 let starého GSM na nějaký modernější protokol. Bohužel ani 3G, ani UMTS na tom také nejsou s bezpečností zrovna růžově. Nejvíc by se mi osobně líbilo, kdyby operátor poskytoval IP konektivitu a já bych si přes to tuneloval šifrovaný VoIP (SIP přes TLS, RTP přes sRTP nebo ještě lépe zRTP), ale něčeho takového se asi hned tak nedočkám.Šifrovaně můžeš tunelovat i přes současný kanál ne? Jenom místo zakomprimovanýho zvuku přímo do streamu z LFSR ještě zaXORuješ něčím tvrdším. BTW Co ten hack pomocí tý piko(mikro/nano?)BTS jak distribuoval zahraniční operátor?
BTW Co ten hack pomocí tý piko(mikro/nano?)BTS jak distribuoval zahraniční operátor?To bylo na 3G...
Rejp do ecallu?Ne ne, rejp do zabezpečovaček baráků.
Může mobil donutit BTS k nešifrování, nebo musí poslechnout inicializaci od BTS?Mobil poslouchá BTS. Ta pošle Ciphering Mode Command a když telefon nezačne šifrovat, tak mu IMHO přestane rozumět.
Hmm na tohle by to chtělo nedeterministický automatMy si vycrackovali nějaký rámec zprostředka, ale chtěli bychom znát celou komunikaci. A taky bychom chtěli poslouchat následující komunikace, které se inicializují stejným klíčem, ale napajpuje se tam jiný framenumber (to je něco jako IV, akorát hodně slabý, protože se mezi transakcemi inkrementuje jen o málo).. Není to backclockování zbytečný, když už vnitřní bity známe?
Hehe stejně nic se nevyrovná inicializací samejma nulama (nebo aspoň framecounter nulovej)Tak ony defaultně mají ty LFRS nuly… kdyby jich nebylo jenom 64 bitů, ale třeba 128, tak to není zas tak špatná šifra….
Jsem původně reagoval jenom na to první (je to moc daleko od sebeTy jo, DCS (GSM 1800) má v ČR snad 70 MHz v jednom směru? To znamená I/Q ADC s 70 Megasamply. Nebo radši rovnou dva (uplink i downlink).). To se týče přesnosti to by snad problém být neměl (jako naladění PLL, to není jako ladění elektronkovýho rádia, kde byly táhla na jádra cívek!! :-O
).
BTW jak velká prodleva je mezi výzvou o přeladění a samotným zahájením přenosu?Já měl za to, že je to 8 timeslotů, tedy 0,577 (?) ms. Ale vzhledem k tomu, že jak poslouchání, tak samotný GSM stack na Linuxu funguje přes USB, tedy milisekunda žádná míra, tak tam asi bude nějaký delay. Nebo se na začátku neposílá nic důležitého
Nebo několik přijímačů sestavujících celé pásmo.To by šlo, ještě to nikdo asi nezkoumal. Když už jsou k dispozici výkresy krabičky (jak to říct diplomaticky?), která dokáže chytat 8 kanálů. To by jednu BTS dát mohlo.
Jinak šířka kanálu je jen 200kHz? To není problém, snad i bluetooth má mnohem širší pásmo (dokonce na náročnější/vyšší frekvenci). BTW bluetooth umí hopping takyNo poraď, zatím nejlevnější SDR je rtl-sdr s šířkou 2 MHz (když se to hodně ohulí, tak i 3 MHz) a rozsahem 64-1700 MHz, tedy na GSM1800 by se to muselo nějak downmixovat. Navíc BTS mají v ČR kanály přidělené tak, aby se to navzájem nerušilo, takže tam jsou díry → potřebuješ těch SDR hodně..
ROFL převodník stojí víc než mobil? :-ONa ten převodník dáš 4 mobily, ale i tak je to pálka…
Šifrovaně můžeš tunelovat i přes současný kanál ne?Blbě. S rozumným effortem do toho GSM narveš tak pár set bitů za sekundu maximálně.
Jenom místo zakomprimovanýho zvuku přímo do streamu z LFSR ještě zaXORuješ něčím tvrdším.To nejde. Na BTS se totiž zvuk rozbalí do PCM, infrastrukturou operátora putuje jako PCM a na druhé BTS se zase zkomprimuje GSM/EFR/AMR/jaksetozrovnamenuje a pošle. Při nějakém chytrém exploitnutí vlastností toho vokodéru by se z toko pár kb/s vytřískat dalo (takže nějaký nejmizernější speex tím protáhneš), ale to CSD/GPRS/EDGE vyjde fakt líp…
BTW Co ten hack pomocí tý piko(mikro/nano?)BTS jak distribuoval zahraniční operátor?To je UMTS/3G a odkazuju to v závěru (…zrovna růžové). To je fail nad faily, leč GSM pikocely se nedistribuují. Ale kdo má mikrocelu v baráku, pustit si Wireshark po těch drátech, co z toho vedou, by mohlo být zajímavé. Jen jestli tam není ipsec - pak by bylo potřeba hackovat přímo tu stanici…
28c3-4736-en-defending_mobile_phones_h264.mp4
):
Mobil poslouchá BTS. Ta pošle Ciphering Mode Command a když telefon nezačne šifrovat, tak mu IMHO přestane rozumět.Aha tak to asi ne, jsem myslel kdyby to bylo jako třeba telnet nebo analogový modem (ne master slave).
My si vycrackovali nějaký rámec zprostředka, ale chtěli bychom znát celou komunikaci. A taky bychom chtěli poslouchat následující komunikace, které se inicializují stejným klíčem, ale napajpuje se tam jiný framenumber (to je něco jako IV, akorát hodně slabý, protože se mezi transakcemi inkrementuje jen o málo).FN se inkrementuje nějak deterministicky? Jak se přenese první hodnota?
Tak ony defaultně mají ty LFRS nuly… kdyby jich nebylo jenom 64 bitů, ale třeba 128, tak to není zas tak špatná šifra…Jo ale kdyby byl klíč nulový i framenumber nulový, tak lfsr generuje jen samý nuly a přenáší se přímo enkódovaný zvuk/data
Ty jo, DCS (GSM 1800) má v ČR snad 70 MHz v jednom směru? To znamená I/Q ADC s 70 Megasamply. Nebo radši rovnou dva (uplink i downlink).To vybereš z libovolného osciloskopu
Já měl za to, že je to 8 timeslotů, tedy 0,577 (?) ms. Ale vzhledem k tomu, že jak poslouchání, tak samotný GSM stack na Linuxu funguje přes USB, tedy milisekunda žádná míra, tak tam asi bude nějaký delay. Nebo se na začátku neposílá nic důležitého . ... To by šlo, ještě to nikdo asi nezkoumal. Když už jsou k dispozici výkresy krabičky (jak to říct diplomaticky?), která dokáže chytat 8 kanálů. To by jednu BTS dát mohlo.Aha takže přímo hnedka v dalším slotu, zajímavý. A ten ovladač přes linux řídí přímo vysílač? :-O Tak to je masakr
No poraď, zatím nejlevnější SDR je rtl-sdr s šířkou 2 MHzSatelitní přijímač downmixuje tuším z >10GHz na ~1GHz, analogová televize má obrazovou mezifrekvenci 30MHz, takže stáhnout z 1.8G by to šlo horší je prostě ten AD převodník no, ale 100MSps se koupit dá (nebude to levný, ale zase to nebudou miliony).
Na ten převodník dáš 4 mobily, ale i tak je to pálka…A je to UART→USB? To by možná šlo z nějakýho PICu levnějc...
To nejde. Na BTS se totiž zvuk rozbalí do PCM, infrastrukturou operátora putuje jako PCM a na druhé BTS se zase zkomprimuje GSM/EFR/AMR/jaksetozrovnamenuje a pošle.Aha brrrblé. Zajímavý proč si zvyšuje trafic.
FN se inkrementuje nějak deterministicky?No, překvapivě o jedničku s každým frame
To vybereš z libovolného osciloskopuHele postav to SDRko a lidi ti za to utrhaj ruce. Už jsme přemýšleli i o vysílání ve stylu Tempest nebo tadytoho týpka., navíc můžeš dát třeba několik 10MSps. P.S. Ještě možná spíš 140M dle nyquista-shanona-kotelníka
.
A ten ovladač přes linux řídí přímo vysílač? :-OSamotná demodulace se děje v DSP v mobilu, takže po sériáku už tečou jedničky a nuly, ale jinak je všechno ostatní na počítači.
Nebo by se taky možná dala BTS přinutit přejít na jiný kanál pouhým zarušenímBTS mají kanály alokované staticky (buňky musí být po krajině rozmístěné a spočítané tak, aby se to navzájem co nejmíň rušilo - takže se hladá uspořádání, kde každé dvě stejné frekvence budou co nejdál od sebe). Když jednu na chvilku zarušíš, mobil zkusí handover na vedlejší; když ji zarušíš na dýl, přijede bílá dodávka a začne se zajímat, co se stalo..
(nebo když se zaruší příjem změny frekvence)Nic, přeladíš se na vedlejší BTS. A když je to během hovoru, tak asi spadne :).
A je to UART→USB? To by možná šlo z nějakýho PICu levnějc...No jo, jenže tenhle UART nemá 115200, ale dvojnásobek
Aha brrrblé. Zajímavý proč si zvyšuje trafic.Podle mě proto, že (pick one :)
No, překvapivě o jedničku s každým frame . Vysílá se nešifrovaně na broadcast kanálu.Takže se musí někde nejprve inicializovat a pak už můžou jet asynchronně. Pokud bych odchytnul rámec, tak mám další část klíče, ale to se asi bude posílat taky šifrovaně, že?
Hele postav to SDRko a lidi ti za to utrhaj ruce. Už jsme přemýšleli i o vysílání ve stylu Tempest nebo tadytoho týpka.AD9446 s 100MSps nebo si můžeš vybrat z klikatelné tabulky (+1 bod pro Analog Devices).
Samotná demodulace se děje v DSP v mobilu, takže po sériáku už tečou jedničky a nuly, ale jinak je všechno ostatní na počítači.Hmm takže by mohlo jít zpoždění USB maskovat jako větší timing advance.
BTS mají kanály alokované staticky (buňky musí být po krajině rozmístěné a spočítané tak, aby se to navzájem co nejmíň rušilo - takže se hladá uspořádání, kde každé dvě stejné frekvence budou co nejdál od sebe). Když jednu na chvilku zarušíš, mobil zkusí handover na vedlejší; když ji zarušíš na dýl, přijede bílá dodávka a začne se zajímat, co se stalo.Jedině, že bys měl směrovou anténu a věděl, že teďka vysílá mobil co chceš sledovat a rušičku zapínal jen v jeho kanálu a timeslotu. BTW teoreticky jestli se na začátku vysílání mobilu posílá synchronizační pole, tak bys možná mohl stihnout přeladit dřív než začnou data (kterej kanál bys zjistil pomocí spektrálního analyzéru).
No jo, jenže tenhle UART nemá 115200, ale dvojnásobek .UART modul v PICu má asi 8Mbps
Podle mě proto, že (pick one :)Nejspíš ta nedigitální síť, i když já bych vybral spíš to, že odposlouchávat kodek je složitější než PCM
Takže se musí někde nejprve inicializovat a pak už můžou jet asynchronně. Pokud bych odchytnul rámec, tak mám další část klíče, ale to se asi bude posílat taky šifrovaně, že?Framenumber znáš - k získání klíče z generátoru ho totiž potřebuješ. Viděl jsi to video o A5/1? Nejdřív se do toho napajpuje klíč a pak framenumber. Když to backclockuješ, musíš v těch 22 cyklech vyndavat z těch registrů framenumber.
Hmm takže by mohlo jít zpoždění USB maskovat jako větší timing advance.Nejvyšší TA je 35 km, tedy 120 μs.
Jedině, že bys měl směrovou anténu a věděl, že teďka vysílá mobil co chceš sledovat a rušičku zapínal jen v jeho kanálu a timeslotu.To můžu namířit na mobil a gumovat mu BTSku.
BTW teoreticky jestli se na začátku vysílání mobilu posílá synchronizační pole, tak bys možná mohl stihnout přeladit dřív než začnou data (kterej kanál bys zjistil pomocí spektrálního analyzéru).Posílá se DATA-TRAINING-DATA, ale pravda, pomocí rychlého spektráku nebo pomalého spektráku a následného dohopování rádiem by se dalo zjistit, na kterých kanálech a timeslotech probíhá uplink. Teď ještě co s downlinkem, ale i tak může být půlka hovoru cenná. Taky lze zkusit extrahovat echo z mikrofonu a zrekonstruovat druhou půlku, i když GSM kodek je na tohle dost šmejdský.
Framenumber znáš - k získání klíče z generátoru ho totiž potřebuješ. Viděl jsi to video o A5/1? Nejdřív se do toho napajpuje klíč a pak framenumber. Když to backclockuješ, musíš v těch 22 cyklech vyndavat z těch registrů framenumber.Jo viděl, ale není tam napsaný odkud ho vezmu
Nejvyšší TA je 35 km, tedy 120 μs.Kruci, pravda, to mám z toho, že píšu narychlo nepřihlášen
Je jen otázka času, kdy se na černém trhu začnou objevovat hotové krabičky na odstavení levných GSM zabezpečovaček.To zní jako zajímavý podnikatelský záměr :)
Tj. v okamžiku kdy BTS řekne "zapni šifrování", tak to pirátský vysílač přebije svým silným "pojedem bez šifrování"EE, BTS pak už očekává šifrovaná data a protože útočník nezná klíč, tak je ani nemůže transparentně dešifrovat. GSM mobil podle mě šifrování podporovat musí vždy, o (ne)použití šifry rozhoduje BTS. Respektive koukáním na příchozí spojení jsem nabyl toho dojmu, když komunikaci iniciuje mobil, může to být jinak. GSM zas tak moc nerozumím :).
01-03 pro známou trojku a 98 pro jednoho méně známéhoA co 99, tu ma preci CVUT FEL.
230 99 Vodafone Vodafone Czech Republic Operational GSM 1800 R&D Centre at FEE, CTU (educational, experimental)
A nešlo by zamezit hopingu, tak že zarušíš všechny přednastavené kanály sledované BTS a nechal bys jen jediný volný?Hopping se neinicializuje dynamicky podle zarušených pásem, ale prostě nějak a když to pak nevyjde, tak smůla.
A co metoda aktualizace SIM pomocí falešné BTS?Ono „se“ hlavně tvrdí, že mobil lze kombinací úmyslných backdoorů a děr donutit na dálku zapnout mikrofon a poslouchat.
a v případě potřeby by provedl úpravu HW/SW příušnice sledované osoby, protože jak už z televize víme, někteří komunikují po GSM v kryptované podoběTak doufejme, že u normálních chytrých telefonů (hmm, v současnosti asi jenom věci z OpenMoko a N900) se nedá exploitem GSM napadnout zbytek systému - AT rozhraní pro komunikaci s modemem je tak jednoduché, že tam snad nikdo žádný buffer overflow nezapomněl :). A protože šifrované hovory jsou data (normální SIP přes SSL a šifrované RTP), dá se ze strany operátora udělat tak maximálně DoS.
Ono „se“ hlavně tvrdí, že mobil lze kombinací úmyslných backdoorů a děr donutit na dálku zapnout mikrofon a poslouchat.Můj ne, teda pokud neobjevili způsob jak obejít zákony termodynamiky a zabránit mému mobilu, aby se soustavným vysíláním za pár minut vybil
AT rozhraní pro komunikaci s modemem je tak jednoduché, že tam snad nikdo žádný buffer overflow nezapomněl :)To by ses možná (u non open výrobků) divil
Ono „se“ hlavně tvrdí, že mobil lze kombinací úmyslných backdoorů a děr donutit na dálku zapnout mikrofon a poslouchat.
Něco na tohle téma bych strašně rád viděl, nedá se na to moc nic pořádně vypátrat.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.