Fakulta elektrotechnická

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická DIPLOMOVÁ PRÁCE 2007 Radek Podgorný

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická Katedra telekomunikační techniky Operační a dohledové centrum telefonní ústředny Siemens EWSD leden 2007 Diplomant: Radek Podgorný Vedoucí práce: Ing. Pavel Troller, CSc.

Čestné prohlášení Prohlašuji, že jsem zadanou diplomovou práci zpracoval sám s přispěním vedoucího práce a konzultanta a používal jsem pouze literaturu v práci uvedenou. Dále prohlašuji, že nemám námitek proti půjčování nebo zveřejňování mé diplomové práce nebo její součásti se souhlasem katedry. Datum: 19.1.2007... podpis diplomanta

Anotace Předmětem této diplomové práce je analýza servisního protokolu ústředny Siemens EWSD a následná implementace komunikačního software na základě zjištěných informací. Podrobně jsou popsány postup a výsledky analýzy i vlastní implementace. V závěru je pak kromě zhodnocení obsaženo i několik námětů pro další rozvoj vytvořeného produktu do budoucnosti. Summary The subject of this final thesis is an analysis of Siemens EWSD switch service protocol and implementation of a communication program based on the information gathered. The procedure and results of both analysis and implementation are described thoroughly. In the final part, there is an evaluation together with few subjects for possible future development of the product.

Poděkování vedoucímu diplomové práce Dovoluji si poděkovat vedoucímu diplomové práce Ing. Pavlu Trollerovi, CSc. nejen za odborné vedení, cenné rady a připomínky, ale i za možnost kontaktu se světem telekomunikačních služeb a techniky v reálném provozu.

Obsah Obsah 1 1 Úvod 3 1.1 Historie telekomunikačních ústředen............... 3 1.2 Dnešní telekomunikační ústředny................ 4 1.3 Důvody vývoje softwaru pro ústřednu Siemens EWSD.... 5 1.3.1 Transport dat....................... 5 1.4 Struktura práce.......................... 6 1.5 Úvod do terminologie....................... 6 2 Odposlech 9 2.1 Volba nástroje........................... 9 2.2 Dissector pro Ethereal...................... 10 2.3 Výsledek odposlechu....................... 10 3 Analýza 12 3.1 Preambule............................. 12 3.2 Užitečná data (payload)..................... 14 3.3 Výsledek analýzy......................... 14 4 Aplikace 16 1

4.1 Stávající aplikace......................... 16 4.2 Volba vývojové a operační platformy.............. 17 4.3 Volba nástroje pro správu verzí................. 17 4.4 Rozšíření programu ewrecv.................... 18 4.4.1 Infrastruktura pro serializaci a deserializaci paketů.. 18 4.4.2 Protokol X.25 a paketová komunikace.......... 19 4.4.3 Multiplexing pro více nezávislých uživatelů....... 19 4.5 Rozšíření programu ewterm................... 20 4.5.1 Reálné odhlášení..................... 20 4.5.2 Rozlišení zpráv alarmů.................. 20 4.6 Napojení na vrstu X.25 v systému Linux............ 21 4.6.1 Modul x25tap....................... 21 4.6.2 Démon xotd........................ 21 5 Možnosti dalšího vývoje 22 5.1 Využití dynamických knihoven Siemens pro získání zakódovaného hesla................................ 22 5.2 Směr dalšího vývoje........................ 23 5.3 Způsob dalšího vývoje...................... 23 5.3.1 Omezení platformy a architektury............ 24 5.3.2 Demanglování názvů metod............... 24 5.3.3 Konvence volání jazyka C++ v systému Windows... 25 5.3.4 Rekurzivní importování knihoven............ 26 6 Závěr 28 6.1 Celkové zhodnocení........................ 28 6.2 Osobní dojmy a připomínky................... 28 Literatura 30 2

Kapitola 1 Úvod 1.1 Historie telekomunikačních ústředen Historie telekomunikačních ústředen se odvíjí od konce 70. let 19. století, kdz Alexander Graham Bell a Elisha Gray nezávisle na sobě vynalezli telefonní přístroj a patentovali jej rovněž nezávisle shodou okolností týž den, 14. února 1876. Bell následně založil společnost Bell Telephone Company, která nedlouho poté v roce 1885 přešla po zahrnutí Grayových patentových práv v American Telephone and Telegraph Company, neboli známou AT&T. Hovory jednotlivých účastníků bylo nutné spojovat a přepojovat (hlavní funkce ústředen), což se dělo výlučně manuálně prostřednictvím spojovatelek. Ve 20. století se po 1. světové válce začalo přecházet na automatizované reléové ústředny, které tehdy umožňovaly přímou volbu v rámci jednoho telekomunikačního uzlu, tj. většinou jednoho města, meziměstská a mezinárodní spojení se nadále uskutečňovala manuálně. Po 2. světové válce začal velmi pozvolný nástup polovodičových ústředen s pevným programem, které již zajišt ovaly automaticky místní a meziměstská spojení, mezinárodní spojení se nadále spojovala převážně manuálně. V 70. 3

letech se také začaly uskutečňovat první datové modemové a faxové přenosy na bázi analogového spojení. V 80. letech 20. století nastoupily sice také polovodičové, ale procesory řízené automatické telekomunikační ústředny, které se používají dodnes, a zajišt ují nejen plně automatizovaný provoz v podmínkách dnešního globálně propojeného světa, ale hlavně umožňují plnou digitalizaci hlasových a datových přenosů. Toto vedlo nejen k podstatnému zkvalitnění telekomunikačního spojení, ale hlavně k zavedení různých služeb, které by jiným způsobem nebyly uskutečnitelné. 1.2 Dnešní telekomunikační ústředny Tyto telekomunikační středny používané v produkčním prostředí se vyznačují především svou spolehlivostí a životností v řádu několika let. V oblasti vývoje a životnosti softwarového vybavení však dochází k velmi rychlým změnám, a udržovat kompatibilitu je velice složité a nákladné. Paradoxně tak dochází k situacím, kdy se plně funkční telekomunikační ústředna, která je ještě na počátku své fyzické životnosti, stává nepoužitelnou z důvodu neexistence ovládacího softwaru, který by byl schopen funkce na moderních počítačích s moderním operačním systémem. Výrobce ústředny a ovládacího softwaru sice vyrobí verzi kompatibilní s novými trendy, ale prodává ho jako zcela nový produkt naprosto bez vazby na to, že zákazník si již dříve koupil ústřednu a očekává její provozování v průběhu období její životnosti bez nutnosti dalších zbytečných poplatků výrobci. 4

1.3 Důvody vývoje softwaru pro ústřednu Siemens EWSD Vzhledem k tomu, že trh v oblasti telekomunikací je převážně záležitostí dominance gigantických společností, není pro tyto společnosti problém investovat nemalé částky do nové generace programů, místo mnohem racionálnějšího a ekonomičtějšího vyvíjení tlaku na výrobce. Tím ovšem značně trpí alternativní operátoři, kteří jsou nuceni hospodařit s mnohem menšími rozpočty, a nemohou si dovolit zcela zbytečně obměňovat programové vybavení ústředen vždy, když se výrobce rozhodne ukončit softwarovou podporu nebo výrobce operačního systému přeruší kompatibilitu. Přístup těchto výrobců ústředen je takový, že dokonce i po oficiálním ukončení výroby ovládacích programů odmítají jakkoliv spolupracovat s majiteli zakoupených ústředen na jejich vlastní implementaci. Důvod je zřejmý; zájem výrobce je, aby operátor koupil nový software. Pokud operátor (majitel ústředny) z nějakého důvodu nechce nebo nemůže do zakoupení relativně nákladného softwaru investovat, jediným řešením je vývoj a implementace vlastního ovládacího programu. A právě to je předmětem této diplomové práce. 1.3.1 Transport dat Samotná komunikace s ústřednou probíhá přes dnes již spíše ustupující protokol X.25. Právě z důvodu často chybějící X.25 infrastruktury jsou datagramy protokolu X.25 pro samotný přenos zabaleny do protokolu TCP 1, v našem případě v souladu se zapouzdřením XOT 2 podle firmy Cisco. TCP je pak 1 TCP Transmission Control Protocol 2 XOT X.25 over TCP Přesná specifikace je předmětem RFC-1613 5

běžně přenášeno pomocí IP 3, dominantního protokolu dneška. 1.4 Struktura práce V následujících odstavcích je uveden stručný popis celkové struktury práce: V kapitole 2 se zabývám procesem odposlechu a záznamu komunikace mezi ústřednou Siemens EWSD a proprietárním ovládacím programem za účelem následné analýzy. V kapitole 3 se pak věnuji vlastní analýze nasbíraných paketů a interpretaci jejich obsahu. V kapitole 4 jsou popsány změny, které jsem implementoval do programů ewrecv a ewterm. Změny jsou založeny na poznatcích z kapitoly 3 a přidávají funkce pro plnohodnotné ovládání ústředny, založeném na protokolu X.25. Kapitola 5 nabízí náměty pro další pokračování v analýze a implementaci. V kapitole 6 pak nakonec shrnuji úspěšnost, náročnost a přínos vykonané práce. Připojuji v ní i několik osobních názorů a připomínek. 1.5 Úvod do terminologie Při analýze servisního protokolu jsem byl nucen z důvodu absence oficiální dokumentace odvodit vlastní pojmenování informačních polí, obsažených v jednotlivých paketech a blocích. Pro opakovanou použitelnost této analýzy i vlastního programu jsem se rozhodl zavést označení v anglickém jazyce. Překlad těchto pojmenování vynechám, protože na samotných názvech nezáleží. Význam polí je podrobně popsán v následujících částech této kapitoly. Označení, 3 IP Internet Protocol 6

uvedená v této kapitole, odpovídají označení struktur a proměnných ve vytvořeném programu. Dále se v této práci objevuje několik odborných termínů z oblasti programovacích jazyků, programování a operačního systému Linux, pocházejících převážně z anglického jazyka. Pro některé z nich čeština nemá vhodný ekvivalent, a proto jsem se rozhodl, hlavně z důvodů konzistentnosti, použít pouhý přepis. Konkrétní význam objasním v této části (uvedeno vždy s původním slovem). Termíny jsou uspořádany podle pořadí prvního použití v textu této práce. dissector (dissector) skupina funkcí, která má za úkol v obecné posloupnosti bytů nalézt oddělovací značky a naplnit předem definované struktury rozdělenými daty z původní posloupnosti preambule (preamble) i když je možné anglický originál přeložit jako hlavička nebo úvodní část, rozhodl jsem se z důvodu podobnosti použít české slovo preambule se stejným významem. payload (payload) užitečná data, nebo-li datová část paketu, nesoucí užitečnou informaci. parsování (parsing) proces analýzy vstupních dat, hledání oddělovačů jednotlivých informačních polí, a ukládání oddělených částí ve strukturované formě. offline (offline) tento výraz je označením pro zařízení, které není permanentně připojené do sítě internet. Používá se též pro druh práce, který stálé připojení nevyžaduje. modul (module) výraz je možné přeložit také jako ovladač, ale české slovo modul je v oblasti operačního systému Linux běžnější. 7

démon (daemon) aplikace běžící dlouhodobě v uživatelském prostoru, plnící nějaký úkol systémového rázu. Český překlad démon je ustáleným výrazem. hashování (hashing) transformace vstupní posloupnosti bytů libovolné délky na posloupnost výstupní s pevnou délkou. Dochází ke ztrátě informace. disassemblování (disassembling) proces převodu binárního spustitelného kódu do jazyka symbolických adres (assembleru) manglování (mangling) proces zakódování jména metody a její signatury do jediného řetězce. demanglování (demangling) inverzní operace k manglování. inline assembly (inline assembly) úsek zdrojového kódu jazyka symbolických adres (assembleru), vložený přímo do zdrojového kódu vyššího jazyka (v našem případě C). Po kompilaci zůstává tento úsek nezměněn. loadování (loading) proces přečtení dat z pevného disku nebo jiného média, a jejich následné uložení do paměti. Může též obsahovat i proces získání nebo nastavení metadat načtené oblasti. 8

Kapitola 2 Odposlech 2.1 Volba nástroje Pro analýzu datové komunikace bylo potřeba nejprve pakety zachytit na vrstvě Ethernet, dále postupně vybalit protokoly IP, TCP, XOT, X.25 a nakonec i vlastní protokol ústředny. Je logické, že pro zpracování tohoto několikastupňového zapouzdření bylo nejvhodnější použít již existující nástroj, a pouze ho obohatit o analyzátor protokolu ústředny. Nejvhodnějším kandidátem se nakonec ukázal být open-source program Ethereal (nyní Wireshark[7]), který patří k nejpopulárnějším ve své třídě (tedy analyzátory sít ového provozu). K samotnému odchycení paketů jsem využil program tcpdump. Sám Ethereal sice odchytávat pakety umí, ale vzhledem k jeho historii spojené s výskytem bezpečnostních děr je doporučeno spouštět ho pouze v odpojeném režimu nad daty již odchycenými. 9

2.2 Dissector pro Ethereal Pro analýzu samotného protokolu jsem zvolil postup přes implementaci rozšíření do open-source programu Ethereal. Ten již obsahuje množství protokolů a proto ušetřil práci s protokoly nižších vrstev (v mém případě postupně Ethernet, IP, TCP, XOT a X.25) a mohl jsem se soustředit pouze na servisní protokol ústředny. Rozšíření bylo implementováno v jazyce C, což sice není optimální řešení vzhledem k neexistenci datového typu string a snadnosti zavlečení chyby, ale na druhou stranu jsem minimalizoval eventuální problémy s okolní kompatibilitou, nebot samotný Ethereal je v jazyce C napsán. Pro samotnou analýzu paketů se v Etherealu používají tzv. dissectory. Jedná se o skupinu funkcí, které jako svůj argument přijmou datovou část paketu, provedou analýzu, a případně zavolají na část nesoucí užitečná data (payload) další dissectory. Protože není architektura Etherealu dostatečně flexibilní, bylo nutné modifikovat dissector protokolu X.25 tak, aby vždy přímo volal dissector protokolu EWSD. V hlavní funkci dissectoru dissect_ewsd() se pouze volá funkce dis_preamble(). Ta analyzuje preambuli podle výše uvedených pravidel, nastaví se globální proměnné hf_ewsd_family, hf_ewsd_dir, hf_ewsd_pltype, hf_ewsd_connid a hf_ewsd_subseq a v případě potřeby se zavolá ještě dissector bloku dis_ewsd(). Tato funkce pak podle specifikovaných pravidel bud volá rekurzivně sama sebe, nebo už interpretuje koncová data. 2.3 Výsledek odposlechu Zaznamenání paketů servisního protokolu ústředny Siemens EWSD proběhlo bez problémů. Vlastní implementace dissectoru byla po seznámení se s vnitřní struktu- 10

rou programu Ethereal přímočará a bez větších komplikací. Během vývoje mého rozšíření změnil autor programu Ethereal licenční podmínky a odštěpil další vývoj pod novým jménem Wireshark[7]. Mnou vytvořený patch se sice na nové zdrojové kódy aplikuje bez chyb, ale dissector EWSD je neaktivní. Vzhledem k tomu, že není potřeba dissector nadále udržovat (sloužil pouze pro analýzu, která již byla dokončena), nebylo potřebné zjišt ovat hlouběji příčiny nefunčnosti. Analýza základní struktury servisního protokolu byla úspěšná, podařilo se zjistit obecnou strukturu předávaných zpráv. 11

Kapitola 3 Analýza 3.1 Preambule Každá datová zpráva začíná sekvencí 11-ti bytů, nazývejme je preambulí. Volitelně pak následuje datová část, nesoucí užitečnou informaci. O tom, jestli se datová část objeví, či ne, rozhoduje právě obsah preambule. offset délka význam 0 1 family 1 1 unknown1 2 1 direction 3 1 payload type 4 2 connection id 6 1 sub-sequence 7 1 unknown2 8 2 session id 10 1 tail Tabulka 3.1: Analýza bytů preambule K preambuli podrobněji: family zdá se, že v komunikaci se vyskytují dvě hlavní rodiny zpráv: 12

rodina COMMAND (0xf1) a ANSWER (0xf2). direction původní předpoklad, že tento byte má něco společného se směrem komunikace (ústředna terminál nebo opačně), další zachycená data nepotvrdila. payload type tento byte vypovídá o typu datové části nebo o její samotné existenci, není však přesně popsáno, jakým způsobem. connection id tento word je unikátní pro každou sub-komunikaci (požadavek + odpověd ). sub-sequence pokud je odpověd delší než kapacita X.25 paketu, je nutné ji rozdělit do více částí (fragmentů). K identifikaci pořadí fragmentů slouží tento byte. session id toto informační pole je nejspíše unikátní pro každé sezení, tedy od přihlášení až do odhlášení. Tabulka podmínek pro další operace: dir pltype subseq operace 1 2 something parsuj jako blok 2 > 1 continued answer interpretuj přímo 2 1 1 long answer parsuj jako blok 2 2 short answer parsuj jako blok 3 1 command confirmation parsuj jako blok 4 0 login attempt parsuj jako blok 0x0c 1 login accept parsuj jako blok 0x0e 0 something parsuj jako blok 3 6 confirmation, send more datová část neexistuje Tabulka 3.2: Přehled následných operací podle preambule 13

3.2 Užitečná data (payload) Datová část se skládá z několika bloků, které mohou být dokonce obsaženy rekurentně samy v sobě. Každý takovýto blok je uvozen trojicí bytů, kde první byte identifikuje číslo bloku (ID), a následující word jeho délku (LEN). Následuje užitečná informace o délce LEN. Jak jsem již uvedl dříve, některé kombinace ID vypovídají o tom, že užitečná část bloku se má opět parsovat a vyhledat v ní další bloky. Struktura obecného bloku je popsána v tabulce 3.3. offset délka význam 0 1 id 1 2 délka užitečných dat (LEN) 3 LEN data Tabulka 3.3: Struktura obecného bloku Další bloky se již neparsují rekurentně a jejich význam je popsán v tabulce 3.4, kde x je zástupný znak pro libovolnou hodnotu. 3.3 Výsledek analýzy I přesto, že nebyl beze zbytku zjištěn význam některých bytů nebo dokonce celých datových polí, praktickými zkouškami bylo ověřeno, že jejich obsah není pro funkčnost komunikace podstatný a ve většině případů postačí dané datové pole vynechat nebo ho naplnit libovolnou hodnotou. Význam polí nutných pro správnou funkčnost komunikace byl tedy zjištěn a proto je možné analýzu označit za úspěšnou. 14

pozice ve stromu offset délka význam x-2 3 2 unknown1 x-2 5 2 job number x-2 7 unknown2 x-3-1 exchange name x-3-2 APS version x-3-3 patch version x-3-5 username x-4-1 dir=4, pltype=0 terminal name x-4-1 exchange name x-4-2 APS version x-4-3 patch version x-4-3-2-2 username x-4-3-2-3 password x-4-4 terminal name x-4-5 username x-4-6 3 1 year x-4-6 4 1 month x-4-6 5 1 day x-4-7 3 1 hour x-4-7 4 1 minute x-4-7 5 1 second x-5-2 error message x-6-1 command x-7 answer Tabulka 3.4: Význam jednotlivých bloků 15

Kapitola 4 Aplikace Významnou částí diplomové práce bylo použití získaných znalostí o protokolu ústředny pro implementaci komunikačního programu. 4.1 Stávající aplikace Efektivním řešením bylo doplnění již existující dvojice programů ewrecv a ewterm o funkčnost, která využívá kanál X.25 pro přenos příkazů a může tak v budoucnu zcela nahradit komunikaci přes sériové rozhraní. Architektura programů ewrecv a ewterm odpovídá schématu klient/server kdy ewrecv plní roli serveru a realizuje samotnou komunikaci s ústřednou. Směrem ke svým klientům (ewterm) komunikuje přes vlastní stavový protokol využívající pro transport protokol TCP. Sériové rozhraní mezi ústřednou a ewrecv i mezi ewrecv a ewterm je znakově orientované, což neodpovídá přístupu přes protokol X.25, kde je datový přenos orientovaný paketově. Upravovat protokol mezi ewrecv a ewterm na paketově orientovaný by bylo asi optimální řešení, ale hrozilo by velké riziko zanesení chyb a ztráta kompatibility se starší verzí. Rozhodl jsem se proto 16

tento protokol neměnit (nakonec jsem ho však musel rozšířit). Přepisování programu ewrecv na plnohodnotně paketový by bylo značně náročné a bez stálého testovaní, jestli nebyla ohrožena původní funkčnost, vlastně nemožné. Proto zůstala vnitřní architektura programu prakticky nezměněna (stále se tedy jedná o znakově orientované rozhraní), ale pomocí několika menších úprav a rozšíření bylo dosaženo i toho, že je program schopen přijímat a odesílat celé pakety. 4.2 Volba vývojové a operační platformy Vzhledem k tomu, že již existující sada komunikačních programů je implementována na platformě Linux[3], bylo nejvhodnější toto prostředí zachovat. Systém Linux je známý především díky jeho vývojovému modelu, kdy se na programování podílí značný počet dobrovolníků internetové komunity bez nároku na honorář. Tento způsob vývoje nabízí výhody, jako volně dostupné a modifikovatelné zdrojové kódy nebo vynikající stabilitu. To jsou důvody, které mimo jiné rozhodly pro Linux nejen jako operační prostředí pro výsledný program, ale také pro jeho vývoj. 4.3 Volba nástroje pro správu verzí Pro usnadnění vývoje, sledování změn a snadnější hledání vnesených chyb jsem se rozhodl pro vývoj používat nástroj pro správu verzí. Vzhledem ke značně decentralizované a offline povaze vývoje jsem při výběru hned vyřadil Subversion[6] a CVS[1], které pro práci vyžadují neustálé spojení s hlavním repozitářem. Nakonec jsem zvolil SCM 1 nástroj Mercurial[4] s distribuovaným přístupem, který umožňuje se zdrojovými kódy pohodlně pracovat 1 SCM source control management (správa zdrojových kódů) 17

i bez přístupu k hlavnímu repozitáři. Mercurial je nástroj multiplatformní, napsaný v jazyku Python[5]. 4.4 Rozšíření programu ewrecv Program ewrecv realizuje serverovou část. Stará se o komunikaci s ústřednou (přes sériovou linku nebo protokol X.25) a klientům poskytuje nezávislé komunikační rozhraní založené na protokolu TCP. Jeho dalším úkolem je multiplexování jednoho spojení (hlavně v případě sériové linky, kdy více než jedno spojení ani není možné) pro více klientů, aby bylo možné s ústřednou komunikovat z několika míst najednou. 4.4.1 Infrastruktura pro serializaci a deserializaci paketů Výsledkem analýzy servisního protokolu ústředny Siemens EWSD byla definice struktur posílaných paketů. V samotném programu, kde bylo potřeba tyto pakety interpretovat a sestavovat, by bylo velmi nepohodlné k datům přistupovat nestrukturovaně. Proto jsem vytvořil sadu funkcí, které posloupnost bytů, přenášených po ethernetové lince, uloží do definovaných struktur s pojmenovanými členskými proměnnými. Nechybí ani sada funkcí, které data z těchto struktur opět uloží jako posloupnost bytů ve správném formátu. Tím se práce s pakety výrazně zjednoduší a začne být intuitivní. Jádro tvoří struktury struct packet a struct block, které představují výše popsanou abstrakci. Nedílnou součástí jsou pak funkce packet_deserialize() a block_deserialize(), které mají za úkol z obecné (ale ne náhodné) posloupnosti bytů naplnit zmíněné struktury. Pro nalezení určitého uzlu ve stromu bloků slouží funkce block_getchild(). 18

Při vytváření paketu použijeme funkci packet_alloc() pro alokaci a inicializaci struktury paketu, poté pomocí série volání funkce block_addchild() přidáme požadované uzly (strom se vytváří automaticky). Nakonec převedeme struktury na výslednou posloupnost bytů, která je již připravena k odeslání pomocí funkce packet_serialize(). Pro správnou funkčnost celého systému abstrakce jsem samozřejmě vytvořil větší množství funkcí. Ty ale ve většině případů zůstávají pro uživatele skryty. Striktní dodržování prefixů packet_ a block_ a logický systém vrstvení zaručuje snadnou orientaci i pro nezasvěceného programátora, který by chtěl provádět modifikace. 4.4.2 Protokol X.25 a paketová komunikace Program ewrecv je ve svém jádru znakově orientovaný, což je pro komunikaci přes X.25 nevhodné. Hlavní úprava tedy spočívala ve vytvoření funkcí packet_deserialize(), která několik znaků na vstupu převede na celistvý paket a vytvoří strom bloků a ProcessExchangePacket(), která tento strukturovaný paket zpracuje. Pro realizaci plné funkčnosti také vzniklo značné množství dílčích funkcí. Bylo by však zbytečné zde popisovat jejich signatury a funkčnost. 4.4.3 Multiplexing pro více nezávislých uživatelů Multiplexing pro více uživatelů je schopnost rozlišit několik nezávislých uživatelů (kdy každý z těchto uživatelů může být připojen přes několik instancí programu ewterm najednou), a poskytnout jim možnost komunikovat s ústřednami nezávisle na uživatelích ostatních. To vše bud přes jediný fyzický X.25 kanál, nebo přes obecný počet spojení, alokovaných po jednom pro každého uživatele. 19

Program ewrecv jsem rozšířil o pole spojení na ústředny, které jsou při případném výpadku jednotlivě obnoveny. Data přijatá z terminálů jsou pak rozeslána pomocí všech spojení v poli. Odpovědi od ústředen jsou postupně načítány a rozesílány k jednotlivým terminálům. Pro správnou funkčnost je nutné zajistit deaktivaci interaktivního MML a zaručit, aby přihlašovací údaje (jméno a heslo) byly na všech ústřednách stejné. 4.5 Rozšíření programu ewterm Úpravy programu ewterm byly s úpravami v programu ewrecv podstatně méně náročné, přesto však ne triviální. Vzhledem k tomu, že program ewterm představuje klientskou část, nemusí se programátor zabývat násobným připojením a souběhem. Množství uchovávaných stavových informací je v porovnání s programem ewrecv také menší. 4.5.1 Reálné odhlášení Hlavní změny se týkaly obohacení komunikačního protokolu mezi ewrecv a ewterm o povel pro odhlášení, nebot původně bylo odhlášení řešeno pouze odesláním příkazu ENDSESSION; z terminálu. Tento způsob odhlašování je platný pouze pro původní sériovou komunikaci, ale pro X.25 již platný není. Bylo proto nutné přesunout odhlašovací rutiny do programu ewrecv, obohatit vnitřní protokol a upravit ewterm tak, aby toto nové rozšíření používal. 4.5.2 Rozlišení zpráv alarmů Další zlepšení, které přinesla komunikace přes X.25, je rozlišení příchozího textu na odpovědi na zadané příkazy a provozní alarmy a zprávy údržby, 20

které jsou generovány automaticky. Je nepříjemné, když se tyto automatické zprávy vměšují do běžného povelovacího sezení, a proto je žádoucí tyto zprávy rozlišit a zpracovávat pouze specializovaným klientem. Z tohoto důvodu bylo nutné vnitřní protokol ještě rozšířit o povely zasílat alarmy a nezasílat alarmy. Samozřejmě jsem musel změny patřičně zapracovat i do programů ewrecv a ewterm. 4.6 Napojení na vrstu X.25 v systému Linux Tato komunikace probíhá přes protokol X.25. Vzhledem k tomu, že nechceme realizovat přenos přes fyzickou vrstvu s protokolem X.25, je nutné pakety zapouzdřit do protokolu XOT a přes transportní vrstvu TCP je pak odeslat dále do sítě, kde jsou těsně před ústřednou opět převedeny na X.25. 4.6.1 Modul x25tap Pro úspěšné zapouzdření je nutné X.25 pakety přijaté linuxovým jádrem předat do uživatelského prostoru. O to se postará modul x25tap[8], který vytvoří virtuální X.25 rozhraní, a data podle potřeby vyměňuje mezi uživatelským prostorem a prostorem jádra. 4.6.2 Démon xotd Když jsou pakety protokolu X.25 předány modulem x25tap z jádra, přijme je démon xotd[8], který k nim přidá XOT hlavičku a pošle je na definovanou IP adresu (a port) protokolem TCP. Naopak, pokud přijdou z IP sítě XOT pakety, démon xotd z hlavičky extrahuje potřebné informace a dále předá uživatelská data, tedy X.25 paket, jádru přes virtuální zařízení x25tap. 21

Kapitola 5 Možnosti dalšího vývoje 5.1 Využití dynamických knihoven Siemens pro získání zakódovaného hesla Během analýzy proprietárního protokolu Siemens bylo zjištěno, že při přihlašování je heslo posíláno ve speciálním zakódovaném formátu, který znemožňuje jednoduše heslo na lince nahrát a poté opětovně použít pro přihlášení s právy původního uživatele. Toto heslo je závislé na čase (s přesností na sekundy) a je hashováno pomocí funkce MD5 nebo její modifikace. I přes značné úsilí, které by odhalilo algoritmus sestavení této posloupnosti bytů, se tento postup nepodařilo odhalit, a tak jedinou funkční metodou pro získání hesla, chráněného proti opětovnému přehrání, je použití binárních Win32 knihoven, které dodává přímo firma Siemens a tuto funkčnost obsahují. Z důvodu nepotřebnosti pro funkčnost celku byla pouze zpracována příprava postupu pro budoucí využití při implementaci této funkce do programu ewrecv. V následujících částech uvedu postup vhodný pro využití části binární 22

dynamické C++ knihovny z prostředí Windows na architektuře x86. Jedná se o českou verzi anglického článku[9], který jsem při své vývojové činnosti vytvořil. 5.2 Směr dalšího vývoje Knihovny, ze kterých chceme získat kód, jsou napsány v jazyce C++ a jsou tedy objektově orientované. Linkování s objektově orientovanými knihovnami v době kompilace není obecně problém, ale k tomuto kroku jsou potřeba statické linkovací knihovny, které Siemens nedodává a tak jedinou možností je dynamické linkovaní za běhu programu. To je však relativně složitá situace. Je velmi jednoduché použít exportovanou funkci v čistém C, protože jediné, co je nutné udělat, je najít správnou adresu a poté funkci prostě zavolat s patřičnými argumenty (správné argumenty a návratový typ však musíme předem znát). V případě C++ jsou metody tříd exportovány jako běžné funkce v čistém C, ale jejich názvy jsou manglovány (takže je možné mít Class1::DoSomething() i Class2::DoSomething() dohromady). Je výhodou, že nemusíme předem vědět správné argumenty a návratový typ, protože kompletní signatura metody je součástí manglovaného jména. Hlavní problém spočívá v tom, jak tyto funkce použít s nějakou instancí třídy, tedy jako metody a jak tento celek vhodně obalit tak, aby měl vlastnosti třídy/objektu. 5.3 Způsob dalšího vývoje Popsaná metoda nepatří k těm, které by se měly při běžném programování používat. Je náchylná na zavlečení chyby, kterou kompilátor nezjistí, ale která 23

může způsobit pád programu. Jinou možnost ale pravděpodobně nemáme. 5.3.1 Omezení platformy a architektury Funkčnost je zaručena pouze na platformě Windows (možná dokonce pouze s kompilátorem Microsoft Visual C++) a to pouze na architektuře x86. Podobnou techniku je možné použít i na jiných platformách a architekturách, ale postupy se mohou mírně i značně lišit. 5.3.2 Demanglování názvů metod V jazyce C++ neexistuje jednoznačně definovaný způsob, jak by měla být jména funkcí manglována, takže výsledné názvy jsou specifické pro jednotlivé kompilátory. Kompilátor Microsoft Visual C++ mangluje jména například do??0slnepasswd@@qae@abv0@@z (a podobných). S výhodou pro nás obsahuje takto manglované jméno všechny potřebné informace, které potřebujeme k úspěšnému importování metod a jejich použití objektově orientovaným způsobem. Na internetu lze nalézt mnoho nástrojů, vhodných pro demanglování jmen funkcí zpět na jejich plné signatury. Já zvolil nástroj IDA Pro[2]. Jedná se o velmi užitečný disassembler s mnoha funkcemi. Ostatní nástroje ale budou pravděpodobně také fungovat uspokojivě. Takto vypadá vzorek výstupu po disassemblování: ; private: class CLBinary thiscall SLNEPasswd::GetMD5Encryption( \ class CLBinary const &) public?getmd5encryption@slnepasswd@@aae?avclbinary@@abv2@@z?getmd5encryption@slnepasswd@@aae?avclbinary@@abv2@@z proc near Nyní je tedy známo, co funkce očekává jako argumenty a co hodlá vrátit. 24