Bystroushaak's blog / Czech section / Programování / Cracking telefonních karet / Cesta k emulátoru telefonní karty

Cesta k emulátoru telefonní karty

Prohlášení

Tento článek je něco jako myšlenková hra, cosi jako šachy bez šachovnice. Při této hře se navrhují jednotlivé akce a protiakce, útoky a obrana, v diskuzi se probírá se co by se stalo kdyby ..

Pokud se kdokoliv rozhodne na základě tohoto článku páchat trestnou činnost, je to jen jeho rozhodnutí a autor tohoto článku s tím rozhodně odmítá mít cokoliv společného. Jinak řečeno; Autor na sebe nebere jakoukoliv zodpovědnost za způsob jakým čtenáři mohou naložit s informacemi, které jsou v článku uvedené. Pokud s tímto jakožto potenciální čtenář(ka) nesouhlasíte, plánujete porušit zákon nebo tušíte že by jste nabyté informace nedokázal(a) udržet v teoretické rovině, já jakožto autor vám neuděluji svolení článek dále číst. V opačném případě můžete pokračovat.

Úvod

Tento text jsem sepsal abych si utřídil myšlenky a zároveň shrnul na internetu volně dostupné informace o zabezpečení telefonních karet do krátkého článku v češtině. Článek dále předkládá teoretické možnosti jak toto zabezpečení zlomit, přičemž se (bohužel ;) nejedná o návod, ale pouze o informace, které by měly podnítit další diskuzi a posunout tak tuto myšlenkovou hru do dalšího kola.

Možná že někoho napadne proč se vlastně snažit, když má dnes v podstatě každý svůj vlastní mobil, popřípadě může volat přes VoIP? Obecnou odpověď na tuto otázku nemám, ale za sebe můžu říct, že je docela zábava snažit se proniknout do technologie o které se toho moc neví a která navíc zůstává po dlouhá léta nepokořená (alespoň nevím že by se někomu povedlo emulovat moderní karty).

Telefonní karta

Jak asi každý ví, telefonní karta je zařízení které umožňuje telefonovat, posílat SMS a emaily z tzv. telefonního automatu. Každá karta má v sobě nějakým způsobem uloženy informace o počtu jednotek. Pokud kartu vložíme do automatu, tak jako první proběhne ověření platnosti karty pomocí tzv challenge/response protokolu. Pokud prověrka proběhne správně, automat vám dovolí volat (posílat emaily, SMS, etc..) dokud bude na kartě dostatečný počet jakéhosi kreditu. Pokud ověření karty neproběhne korektně, nebo na kartě nejsou jednotky, automat vydá vysoký pískavý zvuk a na displeji se objeví výzva k vyjmutí karty.

Pokud jste pozorně četli předchozí odstavec, možná vás napadlo, jak jsou jednotky na kartě uloženy a jestli by je nešlo po provolání zase přidat. Bohužel, u moderních karet by něco podobného opravdu nešlo.

V dobách dávno minulých byly jednotky na kartě reprezentovány (EE)PROM pamětí, kterou automat po každém čtení dekrementoval o 1. Jak je asi každému jasné, brzo se našli lidé, kteří zjistili jak na EEPROM zapisovat a začali si karty dobíjet, popřípadě z EEPROM pamětí vytvořili emulátory PROM karet. Telefonní společnosti na to reagovaly tak, že k jednoduché paměti přidali mikroprocesor, který dovolil pouze odečítat jednotky. Aby kartu nebylo možné jednoduše emulovat, byl přidán i mechanismus, který umožnil ověřit jestli je karta pravá. Tento mechanismus se nazývá challenge/response a bude o něm řeč v další části článku.

Pokud někoho zajímají podrobnosti o hardware karty, dají se najít zde; http://gsho.thur.de/gsho/phonecard/bin/phonecards_204.txt, nebo v ISO normách.

Dle článku na serveru hw.cz vypadá průběh ověřování přibližně takto:

Úvod

Tento text jsem sepsal abych si utřídil myšlenky a zároveň shrnul na internetu volně dostupné informace o zabezpečení telefonních karet do krátkého článku v češtině. Článek dále předkládá teoretické možnosti jak toto zabezpečení zlomit, přičemž se (bohužel ;) nejedná o návod, ale pouze o informace, které by měly podnítit další diskuzi a posunout tak tuto myšlenkovou hru do dalšího kola.

Možná že někoho napadne proč se vlastně snažit, když má dnes v podstatě každý svůj vlastní mobil, popřípadě může volat přes VoIP? Obecnou odpověď na tuto otázku nemám, ale za sebe můžu říct, že je docela zábava snažit se proniknout do technologie o které se toho moc neví a která navíc zůstává po dlouhá léta nepokořená (alespoň nevím že by se někomu povedlo emulovat moderní karty).

Popis challenge/response protokolu

Dle článku na serveru hw.cz vypadá průběh ověřování přibližně takto:

Telefonní automat si po vložení karty vyžádá její obsah

Automat na obsah uplatní hash funkci, do které spolu s obsahem karty vstupuje i 48b náhodné číslo

Telefonní automat pošle kartě stejné náhodné číslo (challenge)

Telefonní karta pomocí stejné hash funkce spočítá odpověď (response) a odešle jí automatu

Pokud se obě čísla schodují, je karta uznána jako platná

Poněkud odlišný popis se dá najít zde;

Z výše popsaného postupu vyplývá, že jediné co brání stavbě emulátoru karty je znalost (resp. neznalost) hash algoritmu. Algoritmus se bohužel jen tak sehnat nedá, proto vidím jedinou možnost ho zjistit pomocí níže uvedených metod.

Možnosti prolomení c/r

MITM sniffer

Jedna z lehčích možností je postavit zařízení na odposlech komunikace mezi kartou a automatem. Po nashromáždění určitého počtu záznamů komunikace by pak mělo stačit sestavit bruteforce cracker (rozebráno dále) a pokusit se zlomit algoritmus.

Výhody

Nevýhody

Inspirace

Několik zajmavých fotek:

Reverzní inženýrství automatu

Jednalo by se o ukradení automatu a jeho pitvání a zkoumání, hledání dat v pamětech, zjišťování ochran a v konečném důsledku i o možnost provádět MITM odposlech mezi kartou a automatem doma.

Výhody

Nevýhody

Reverzní inženýrství karty

Falešný automat

V podstatě se jedná o postavení přípravku, který se bude tvářit jako automat. Pokud bude kartě posílat náhodná čísla, může výsledky hash funkce ukládat pro pozdější bruteforce útok do počítače, čímž odpadne nutnost stavět MITM sniffer.

Výhody

Nevýhody

Útok na hardware karty

Výhody

Nevýhody

Získání algoritmu z nasbíraných dat

Z jistých zdrojů vyplývá, že algoritmus je založen na hardwarových funkcích procesoru, přičemž by měl využívat 48b posuvný registr, XOR a NXOR. Procesor také obsahuje tři 9b, 6b a 5b čítače s neznámou funkcí. Dále existuje nezanedbatelná pravděpodobnost, že se algoritmus podobá výpočtu CRC.

Článek na hw.cz se zmiňuje, že pro získání jednoho bitu hashe je nutné poslat kartě 160x CLK pulz. Z toho vyplývá, že algoritmus probíhá sekvenčně pro každý bit zvlášť a je teoreticky tvořen max. 160 instrukcemi.

Z výše uvedeného vyplývá, že algoritmus by měl vypadat nějak takhle:

Možnosti rekonstrukce algoritmu

Podle mě v úvahu připadají pouze tyto dvě techniky:

Jelikož první volba je poněkud mimo možnosti běžného geeka, myslím že útok hrubou silou bude muset stačit.

Bruteforce cracker

Útok hrubou silou by měl být značně zjednodušený, protože známe vstup, výstup, přibližný počet instrukcí a navíc víme které operace nejspíš algoritmus generování hashe využívá a které ne. Jediné co zbývá je napsat program, který se pokusí odhalit v jakém pořadí jsou operace aplikovány, čímž odhalí algoritmus a umožní stavbu emulátoru.

Cracker by měl dle mého názoru vypadat přibližně takto:

Popis crackeru

Do crackeru by možná bylo dobré zabudovat genetické algoritmy, ale jelikož se v nich moc nevyznám, netuším jak moc by jejich implementace byla v tomto případě vhodná.

Závěr

Nakonec bych chtěl ještě zdůraznit že tento článek není dokonalý, já nejsem dokonalý, dokonce nejsem ani odborník na mikroprocesory nebo zabezpečení karet a proto zde existuje poměrně slušná pravděpodobnost že článek obsahuje chyby nebo nepřesnosti. Je možné že některé metody a možnosti které jsem popsal jsou nesmyslné, nebo nefunkční.

Tento článek neměl a nemá sloužit jako návod, ale k podnícení diskuze nad popsanými metodami. Pokud někoho napadne nějaká připomínka nebo věcná kritika, budu rád když jí uvede v diskuzi k článku, nebo mi jí pošle jinou cestou.

Zdroje

Become a Patron