ˇ ´ VYSOKE ´ UCEN ˇ ´I TECHNICKE ´ V PRAZE CESK E Fakulta elektrotechnick´a
´ PRACE ´ DIPLOMOVA
2007
Radek Podgorn´ y
ˇ ´ VYSOKE ´ UCEN ˇ ´I TECHNICKE ´ V PRAZE CESK E Fakulta elektrotechnick´a Katedra telekomunikaˇcn´ı techniky
Operaˇ cn´ı a dohledov´ e centrum telefonn´ı u ´ stˇ redny Siemens EWSD
leden 2007
Diplomant: Radek Podgorn´ y Vedouc´ı pr´ace: Ing. Pavel Troller, CSc.
ˇ Cestn´ e prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem zadanou diplomovou pr´aci zpracoval s´am s pˇrispˇen´ım vedouc´ıho pr´ace a konzultanta a pouˇz´ıval jsem pouze literaturu v pr´aci uvedenou. D´ale prohlaˇsuji, ˇze nem´am n´amitek proti p˚ ujˇcov´an´ı nebo zveˇrejˇ nov´an´ı m´e diplomov´e pr´ace nebo jej´ı souˇc´asti se souhlasem katedry.
Datum: 19.1.2007 .............................. podpis diplomanta
Anotace Pˇredmˇetem t´eto diplomov´e pr´ace je anal´ yza servisn´ıho protokolu u ´stˇredny Siemens EWSD a n´asledn´a implementace komunikaˇcn´ıho software na z´akladˇe zjiˇstˇen´ ych informac´ı. Podrobnˇe jsou pops´any postup a v´ ysledky anal´ yzy i vlastn´ı implementace. V z´avˇeru je pak kromˇe zhodnocen´ı obsaˇzeno i nˇekolik n´amˇet˚ u pro dalˇs´ı rozvoj vytvoˇren´eho 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ˇ ekov´ an´ı vedouc´ımu diplomov´ e pr´ ace Dovoluji si podˇekovat vedouc´ımu diplomov´e pr´ace Ing. Pavlu Trollerovi, CSc. nejen za odborn´e veden´ı, cenn´e rady a pˇripom´ınky, ale i za moˇznost kontaktu se svˇetem telekomunikaˇcn´ıch sluˇzeb a techniky v re´aln´em provozu.
Obsah Obsah
1
´ 1 Uvod
3
1.1
Historie telekomunikaˇcn´ıch u ´stˇreden . . . . . . . . . . . . . . .
3
1.2
Dneˇsn´ı telekomunikaˇcn´ı u ´stˇredny . . . . . . . . . . . . . . . .
4
1.3
D˚ uvody v´ yvoje softwaru pro u ´stˇrednu Siemens EWSD . . . .
5
1.3.1
Transport dat . . . . . . . . . . . . . . . . . . . . . . .
5
1.4
Struktura pr´ace . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.5
´ Uvod do terminologie . . . . . . . . . . . . . . . . . . . . . . .
6
2 Odposlech
9
2.1
Volba n´astroje . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Dissector pro Ethereal . . . . . . . . . . . . . . . . . . . . . . 10
2.3
V´ ysledek odposlechu . . . . . . . . . . . . . . . . . . . . . . . 10
3 Anal´ yza
9
12
3.1
Preambule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2
Uˇziteˇcn´a data (payload) . . . . . . . . . . . . . . . . . . . . . 14
3.3
V´ ysledek anal´ yzy . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Aplikace
16
1
4.1
St´avaj´ıc´ı aplikace . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2
Volba v´ yvojov´e a operaˇcn´ı platformy . . . . . . . . . . . . . . 17
4.3
Volba n´astroje pro spr´avu verz´ı . . . . . . . . . . . . . . . . . 17
4.4
Rozˇs´ıˇren´ı programu ewrecv . . . . . . . . . . . . . . . . . . . . 18
4.5
4.6
4.4.1
Infrastruktura pro serializaci a deserializaci paket˚ u . . 18
4.4.2
Protokol X.25 a paketov´a komunikace . . . . . . . . . . 19
4.4.3
Multiplexing pro v´ıce nez´avisl´ ych uˇzivatel˚ u . . . . . . . 19
Rozˇs´ıˇren´ı programu ewterm . . . . . . . . . . . . . . . . . . . 20 4.5.1
Re´aln´e odhl´aˇsen´ı . . . . . . . . . . . . . . . . . . . . . 20
4.5.2
Rozliˇsen´ı zpr´av alarm˚ u . . . . . . . . . . . . . . . . . . 20
Napojen´ı na vrstu X.25 v syst´emu Linux . . . . . . . . . . . . 21 4.6.1
Modul x25tap . . . . . . . . . . . . . . . . . . . . . . . 21
4.6.2
D´emon xotd . . . . . . . . . . . . . . . . . . . . . . . . 21
5 Moˇ znosti dalˇ s´ıho v´ yvoje 5.1
22
Vyuˇzit´ı dynamick´ ych knihoven Siemens pro z´ısk´an´ı zak´odovan´eho hesla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2
Smˇer dalˇs´ıho v´ yvoje . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3
Zp˚ usob dalˇs´ıho v´ yvoje . . . . . . . . . . . . . . . . . . . . . . 23 5.3.1
Omezen´ı platformy a architektury . . . . . . . . . . . . 24
5.3.2
Demanglov´an´ı n´azv˚ u metod . . . . . . . . . . . . . . . 24
5.3.3
Konvence vol´an´ı jazyka C++ v syst´emu Windows . . . 25
5.3.4
Rekurzivn´ı importov´an´ı knihoven . . . . . . . . . . . . 26
6 Z´ avˇ er
28
6.1
Celkov´e zhodnocen´ı . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2
Osobn´ı dojmy a pˇripom´ınky . . . . . . . . . . . . . . . . . . . 28
Literatura
30 2
Kapitola 1 ´ Uvod 1.1
Historie telekomunikaˇ cn´ıch u ´stˇ reden
Historie telekomunikaˇcn´ıch u ´stˇreden se odv´ıj´ı od konce 70. let 19. stolet´ı, kdz Alexander Graham Bell a Elisha Gray nez´avisle na sobˇe vynalezli telefonn´ı pˇr´ıstroj a patentovali jej rovnˇeˇz nez´avisle shodou okolnost´ı t´ yˇz den, 14. u ´nora 1876. Bell n´aslednˇe zaloˇzil spoleˇcnost Bell Telephone Company, kter´a nedlouho pot´e v roce 1885 pˇreˇsla po zahrnut´ı Grayov´ ych patentov´ ych pr´av v American Telephone and Telegraph Company, neboli zn´amou AT&T. Hovory jednotliv´ ych u ´ˇcastn´ık˚ u bylo nutn´e spojovat a pˇrepojovat (hlavn´ı funkce u ´stˇreden), coˇz se dˇelo v´ yluˇcnˇe manu´alnˇe prostˇrednictv´ım spojovatelek. Ve 20. stolet´ı se po 1. svˇetov´e v´alce zaˇcalo pˇrech´azet na automatizovan´e rel´eov´e u ´stˇredny, kter´e tehdy umoˇzn ˇovaly pˇr´ımou volbu v r´amci jednoho telekomunikaˇcn´ıho uzlu, tj. vˇetˇsinou jednoho mˇesta, mezimˇestsk´a a mezin´arodn´ı spojen´ı se nad´ale uskuteˇcn ˇovala manu´alnˇe. Po 2. svˇetov´e v´alce zaˇcal velmi pozvoln´ y n´astup polovodiˇcov´ ych u ´stˇreden s pevn´ ym programem, kter´e jiˇz zajiˇst’ovaly automaticky m´ıstn´ı a mezimˇestsk´a spojen´ı, mezin´arodn´ı spojen´ı se nad´ale spojovala pˇrev´aˇznˇe manu´alnˇe. V 70. 3
letech se tak´e zaˇcaly uskuteˇcn ˇovat prvn´ı datov´e modemov´e a faxov´e pˇrenosy na b´azi analogov´eho spojen´ı. V 80. letech 20. stolet´ı nastoupily sice tak´e polovodiˇcov´e, ale procesory ˇr´ızen´e automatick´e telekomunikaˇcn´ı u ´stˇredny, kter´e se pouˇz´ıvaj´ı dodnes, a zajiˇst’uj´ı nejen plnˇe automatizovan´ y provoz v podm´ınk´ach dneˇsn´ıho glob´alnˇe propojen´eho svˇeta, ale hlavnˇe umoˇzn ˇuj´ı plnou digitalizaci hlasov´ ych a datov´ ych pˇrenos˚ u. Toto vedlo nejen k podstatn´emu zkvalitnˇen´ı telekomunikaˇcn´ıho spojen´ı, ale hlavnˇe k zaveden´ı r˚ uzn´ ych sluˇzeb, kter´e by jin´ ym zp˚ usobem nebyly uskuteˇcniteln´e.
1.2
Dneˇ sn´ı telekomunikaˇ cn´ı u ´stˇ redny
Tyto telekomunikaˇcn´ı stˇredny pouˇz´ıvan´e v produkˇcn´ım prostˇred´ı se vyznaˇcuj´ı pˇredevˇs´ım svou spolehlivost´ı a ˇzivotnost´ı v ˇr´adu nˇekolika let. V oblasti v´ yvoje a ˇzivotnosti softwarov´eho vybaven´ı vˇsak doch´az´ı k velmi rychl´ ym zmˇen´am, a udrˇzovat kompatibilitu je velice sloˇzit´e a n´akladn´e. Paradoxnˇe tak doch´az´ı k situac´ım, kdy se plnˇe funkˇcn´ı telekomunikaˇcn´ı u ´stˇredna, kter´a je jeˇstˇe na poˇc´atku sv´e fyzick´e ˇzivotnosti, st´av´a nepouˇzitelnou z d˚ uvodu neexistence ovl´adac´ıho softwaru, kter´ y by byl schopen funkce na modern´ıch poˇc´ıtaˇc´ıch s modern´ım operaˇcn´ım syst´emem. V´ yrobce u ´stˇredny a ovl´adac´ıho softwaru sice vyrob´ı verzi kompatibiln´ı s nov´ ymi trendy, ale prod´av´a ho jako zcela nov´ y produkt naprosto bez vazby na to, ˇze z´akazn´ık si jiˇz dˇr´ıve koupil u ´stˇrednu a oˇcek´av´a jej´ı provozov´an´ı v pr˚ ubˇehu obdob´ı jej´ı ˇzivotnosti bez nutnosti dalˇs´ıch zbyteˇcn´ ych poplatk˚ u v´ yrobci.
4
1.3
D˚ uvody v´ yvoje softwaru pro u ´ stˇ rednu Siemens EWSD
Vzhledem k tomu, ˇze trh v oblasti telekomunikac´ı je pˇrev´aˇznˇe z´aleˇzitost´ı dominance gigantick´ ych spoleˇcnost´ı, nen´ı pro tyto spoleˇcnosti probl´em investovat nemal´e ˇc´astky do nov´e generace program˚ u, m´ısto mnohem racion´alnˇejˇs´ıho a ekonomiˇctˇejˇs´ıho vyv´ıjen´ı tlaku na v´ yrobce. T´ım ovˇsem znaˇcnˇe trp´ı alternativn´ı oper´atoˇri, kteˇr´ı jsou nuceni hospodaˇrit s mnohem menˇs´ımi rozpoˇcty, a nemohou si dovolit zcela zbyteˇcnˇe obmˇen ˇovat programov´e vybaven´ı u ´stˇreden vˇzdy, kdyˇz se v´ yrobce rozhodne ukonˇcit softwarovou podporu nebo v´ yrobce operaˇcn´ıho syst´emu pˇreruˇs´ı kompatibilitu. Pˇr´ıstup tˇechto v´ yrobc˚ u u ´stˇreden je takov´ y, ˇze dokonce i po ofici´aln´ım ukonˇcen´ı v´ yroby ovl´adac´ıch program˚ u odm´ıtaj´ı jakkoliv spolupracovat s majiteli zakoupen´ ych u ´stˇreden na jejich vlastn´ı implementaci. D˚ uvod je zˇrejm´ y; z´ajem v´ yrobce je, aby oper´ator koupil nov´ y software. Pokud oper´ator (majitel u ´stˇredny) z nˇejak´eho d˚ uvodu nechce nebo nem˚ uˇze do zakoupen´ı relativnˇe n´akladn´eho softwaru investovat, jedin´ ym ˇreˇsen´ım je v´ yvoj a implementace vlastn´ıho ovl´adac´ıho programu. A pr´avˇe to je pˇredmˇetem t´eto diplomov´e pr´ace.
1.3.1
Transport dat
Samotn´a komunikace s u ´stˇrednou prob´ıh´a pˇres dnes jiˇz sp´ıˇse ustupuj´ıc´ı protokol X.25. Pr´avˇe z d˚ uvodu ˇcasto chybˇej´ıc´ı X.25 infrastruktury jsou datagramy protokolu X.25 pro samotn´ y pˇrenos zabaleny do protokolu TCP1 , v naˇsem pˇr´ıpadˇe v souladu se zapouzdˇren´ım XOT2 podle firmy Cisco. TCP je pak 1 2
TCP – Transmission Control Protocol XOT – X.25 over TCP – Pˇresn´a specifikace je pˇredmˇetem RFC-1613
5
bˇeˇznˇe pˇren´aˇseno pomoc´ı IP3 , dominantn´ıho protokolu dneˇska.
1.4
Struktura pr´ ace
V n´asleduj´ıc´ıch odstavc´ıch je uveden struˇcn´ y popis celkov´e struktury pr´ace: V kapitole 2 se zab´ yv´am procesem odposlechu a z´aznamu komunikace mezi u ´stˇrednou Siemens EWSD a propriet´arn´ım ovl´adac´ım programem za u ´ˇcelem n´asledn´e anal´ yzy. V kapitole 3 se pak vˇenuji vlastn´ı anal´ yze nasb´ıran´ ych paket˚ u a interpretaci jejich obsahu. V kapitole 4 jsou pops´any zmˇeny, kter´e jsem implementoval do program˚ u ewrecv a ewterm. Zmˇeny jsou zaloˇzeny na poznatc´ıch z kapitoly 3 a pˇrid´avaj´ı funkce pro plnohodnotn´e ovl´ad´an´ı u ´stˇredny, zaloˇzen´em na protokolu X.25. Kapitola 5 nab´ız´ı n´amˇety pro dalˇs´ı pokraˇcov´an´ı v anal´ yze a implementaci. V kapitole 6 pak nakonec shrnuji u ´spˇeˇsnost, n´aroˇcnost a pˇr´ınos vykonan´e pr´ace. Pˇripojuji v n´ı i nˇekolik osobn´ıch n´azor˚ u a pˇripom´ınek.
1.5
´ Uvod do terminologie
Pˇri anal´ yze servisn´ıho protokolu jsem byl nucen z d˚ uvodu absence ofici´aln´ı dokumentace odvodit vlastn´ı pojmenov´an´ı informaˇcn´ıch pol´ı, obsaˇzen´ ych v jednotliv´ ych paketech a bloc´ıch. Pro opakovanou pouˇzitelnost t´eto anal´ yzy i vlastn´ıho programu jsem se rozhodl zav´est oznaˇcen´ı v anglick´em jazyce. Pˇreklad tˇechto pojmenov´an´ı vynech´am, protoˇze na samotn´ ych n´azvech nez´aleˇz´ı. V´ yznam pol´ı je podrobnˇe pops´an v n´asleduj´ıc´ıch ˇc´astech t´eto kapitoly. Oznaˇcen´ı, 3
IP – Internet Protocol
6
uveden´a v t´eto kapitole, odpov´ıdaj´ı oznaˇcen´ı struktur a promˇenn´ ych ve vytvoˇren´em programu. D´ale se v t´eto pr´aci objevuje nˇekolik odborn´ ych term´ın˚ u z oblasti programovac´ıch jazyk˚ u, programov´an´ı a operaˇcn´ıho syst´emu Linux, poch´azej´ıc´ıch pˇrev´aˇznˇe z anglick´eho jazyka. Pro nˇekter´e z nich ˇceˇstina nem´a vhodn´ y ekvivalent, a proto jsem se rozhodl, hlavnˇe z d˚ uvod˚ u konzistentnosti, pouˇz´ıt pouh´ y pˇrepis. Konkr´etn´ı v´ yznam objasn´ım v t´eto ˇc´asti (uvedeno vˇzdy s p˚ uvodn´ım slovem). Term´ıny jsou uspoˇr´adany podle poˇrad´ı prvn´ıho pouˇzit´ı v textu t´eto pr´ace. • dissector (dissector) – skupina funkc´ı, kter´a m´a za u ´kol v obecn´e posloupnosti byt˚ u nal´ezt oddˇelovac´ı znaˇcky a naplnit pˇredem definovan´e struktury rozdˇelen´ ymi daty z p˚ uvodn´ı posloupnosti • preambule (preamble) – i kdyˇz je moˇzn´e anglick´ y origin´al pˇreloˇzit jako ”hlaviˇcka” nebo ”´ uvodn´ı ˇc´ast”, rozhodl jsem se z d˚ uvodu podobnosti pouˇz´ıt ˇcesk´e slovo preambule se stejn´ ym v´ yznamem. • payload (payload) – uˇziteˇcn´a data, nebo-li datov´a ˇc´ast paketu, nesouc´ı uˇziteˇcnou informaci. • parsov´ an´ı (parsing) – proces anal´ yzy vstupn´ıch dat, hled´an´ı oddˇelovaˇc˚ u jednotliv´ ych informaˇcn´ıch pol´ı, a ukl´ad´an´ı oddˇelen´ ych ˇc´ast´ı ve strukturovan´e formˇe. • offline (offline) – tento v´ yraz je oznaˇcen´ım pro zaˇr´ızen´ı, kter´e nen´ı permanentnˇe pˇripojen´e do s´ıtˇe internet. Pouˇz´ıv´a se t´eˇz pro druh pr´ace, kter´ y st´al´e pˇripojen´ı nevyˇzaduje. • modul (module) – v´ yraz je moˇzn´e pˇreloˇzit tak´e jako ”ovladaˇc”, ale ˇcesk´e slovo ”modul” je v oblasti operaˇcn´ıho syst´emu Linux bˇeˇznˇejˇs´ı. 7
• d´ emon (daemon) – aplikace bˇeˇz´ıc´ı dlouhodobˇe v uˇzivatelsk´em proˇ y pˇreklad ”d´emon” je storu, pln´ıc´ı nˇejak´ yu ´kol syst´emov´eho r´azu. Cesk´ ust´alen´ ym v´ yrazem. • hashov´ an´ı (hashing) – transformace vstupn´ı posloupnosti byt˚ u libovoln´e d´elky na posloupnost v´ ystupn´ı s pevnou d´elkou. Doch´az´ı ke ztr´atˇe informace. • disassemblov´ an´ı (disassembling) – proces pˇrevodu bin´arn´ıho spustiteln´eho k´odu do jazyka symbolick´ ych adres (assembleru) • manglov´ an´ı (mangling) – proces zak´odov´an´ı jm´ena metody a jej´ı signatury do jedin´eho ˇretˇezce. • demanglov´ an´ı (demangling) – inverzn´ı operace k manglov´an´ı. • inline assembly (inline assembly) – u ´sek zdrojov´eho k´odu jazyka symbolick´ ych adres (assembleru), vloˇzen´ y pˇr´ımo do zdrojov´eho k´odu vyˇsˇs´ıho jazyka (v naˇsem pˇr´ıpadˇe C). Po kompilaci z˚ ust´av´a tento u ´sek nezmˇenˇen. • loadov´ an´ı (loading) – proces pˇreˇcten´ı dat z pevn´eho disku nebo jin´eho m´edia, a jejich n´asledn´e uloˇzen´ı do pamˇeti. M˚ uˇze t´eˇz obsahovat i proces z´ısk´an´ı nebo nastaven´ı metadat naˇcten´e oblasti.
8
Kapitola 2 Odposlech 2.1
Volba n´ astroje
Pro anal´ yzu datov´e komunikace bylo potˇreba nejprve pakety zachytit na vrstvˇe Ethernet, d´ale postupnˇe vybalit protokoly IP, TCP, XOT, X.25 a nakonec i vlastn´ı protokol u ´stˇredny. Je logick´e, ˇze pro zpracov´an´ı tohoto nˇekolikastupˇ nov´eho zapouzdˇren´ı bylo nejvhodnˇejˇs´ı pouˇz´ıt jiˇz existuj´ıc´ı n´astroj, a pouze ho obohatit o analyz´ator protokolu u ´stˇredny. Nejvhodnˇejˇs´ım kandid´atem se nakonec uk´azal b´ yt open-source program Ethereal (nyn´ı Wireshark [7]), kter´ y patˇr´ı k nejpopul´arnˇejˇs´ım ve sv´e tˇr´ıdˇe (tedy analyz´atory s´ıt’ov´eho provozu). K samotn´emu odchycen´ı paket˚ u jsem vyuˇzil program tcpdump. S´am Ethereal sice odchyt´avat pakety um´ı, ale vzhledem k jeho historii spojen´e s v´ yskytem bezpeˇcnostn´ıch dˇer je doporuˇceno spouˇstˇet ho pouze v odpojen´em reˇzimu nad daty jiˇz odchycen´ ymi.
9
2.2
Dissector pro Ethereal
Pro anal´ yzu samotn´eho protokolu jsem zvolil postup pˇres implementaci rozˇs´ıˇren´ı do open-source programu Ethereal. Ten jiˇz obsahuje mnoˇzstv´ı protokol˚ u a proto uˇsetˇril pr´aci s protokoly niˇzˇs´ıch vrstev (v m´em pˇr´ıpadˇe postupnˇe Ethernet, IP, TCP, XOT a X.25) a mohl jsem se soustˇredit pouze na servisn´ı protokol u ´stˇredny. Rozˇs´ıˇren´ı bylo implementov´ano v jazyce C, coˇz sice nen´ı optim´aln´ı ˇreˇsen´ı vzhledem k neexistenci datov´eho typu string a snadnosti zavleˇcen´ı chyby, ale na druhou stranu jsem minimalizoval eventu´aln´ı probl´emy s okoln´ı kompatibilitou, nebot’ samotn´ y Ethereal je v jazyce C naps´an. Pro samotnou anal´ yzu paket˚ u se v Etherealu pouˇz´ıvaj´ı tzv. dissectory. Jedn´a se o skupinu funkc´ı, kter´e jako sv˚ uj argument pˇrijmou datovou ˇc´ast paketu, provedou anal´ yzu, a pˇr´ıpadnˇe zavolaj´ı na ˇc´ast nesouc´ı uˇziteˇcn´a data (payload) dalˇs´ı dissectory. Protoˇze nen´ı architektura Etherealu dostateˇcnˇe flexibiln´ı, bylo nutn´e modifikovat dissector protokolu X.25 tak, aby vˇzdy pˇr´ımo volal dissector protokolu EWSD. V hlavn´ı funkci dissectoru dissect_ewsd() se pouze vol´a funkce dis_preamble(). Ta analyzuje preambuli podle v´ yˇse uveden´ ych pravidel, nastav´ı se glob´aln´ı promˇenn´e hf_ewsd_family, hf_ewsd_dir, hf_ewsd_pltype, hf_ewsd_connid a hf_ewsd_subseq a v pˇr´ıpadˇe potˇreby se zavol´a jeˇstˇe dissector bloku dis_ewsd(). Tato funkce pak podle specifikovan´ ych pravidel bud’ vol´a rekurzivnˇe sama sebe, nebo uˇz interpretuje koncov´a data.
2.3
V´ ysledek odposlechu
Zaznamen´an´ı paket˚ u servisn´ıho protokolu u ´stˇredny Siemens EWSD probˇehlo bez probl´em˚ u. Vlastn´ı implementace dissectoru byla po sezn´amen´ı se s vnitˇrn´ı struktu10
rou programu Ethereal pˇr´ımoˇcar´a a bez vˇetˇs´ıch komplikac´ı. Bˇehem v´ yvoje m´eho rozˇs´ıˇren´ı zmˇenil autor programu Ethereal licenˇcn´ı podm´ınky a odˇstˇepil dalˇs´ı v´ yvoj pod nov´ ym jm´enem Wireshark [7]. Mnou vytvoˇren´ y patch se sice na nov´e zdrojov´e k´ody aplikuje bez chyb, ale dissector EWSD je neaktivn´ı. Vzhledem k tomu, ˇze nen´ı potˇreba dissector nad´ale udrˇzovat (slouˇzil pouze pro anal´ yzu, kter´a jiˇz byla dokonˇcena), nebylo potˇrebn´e zjiˇst’ovat hloubˇeji pˇr´ıˇciny nefunˇcnosti. Anal´ yza z´akladn´ı struktury servisn´ıho protokolu byla u ´spˇeˇsn´a, podaˇrilo se zjistit obecnou strukturu pˇred´avan´ ych zpr´av.
11
Kapitola 3 Anal´ yza 3.1
Preambule
Kaˇzd´a datov´a zpr´ava zaˇc´ın´a sekvenc´ı 11-ti byt˚ u, naz´ yvejme je preambul´ı. Volitelnˇe pak n´asleduje datov´a ˇc´ast, nesouc´ı uˇziteˇcnou informaci. O tom, jestli se datov´a ˇc´ast objev´ı, ˇci ne, rozhoduje pr´avˇe obsah preambule. offset d´elka v´ yznam 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´ yza byt˚ u preambule
K preambuli podrobnˇeji: • family – zd´a se, ˇze v komunikaci se vyskytuj´ı dvˇe hlavn´ı rodiny zpr´av: 12
rodina COMMAND (0xf1) a ANSWER (0xf2). • direction – p˚ uvodn´ı pˇredpoklad, ˇze tento byte m´a nˇeco spoleˇcn´eho se smˇerem komunikace (´ ustˇredna → termin´al nebo opaˇcnˇe), dalˇs´ı zachycen´a data nepotvrdila. • payload type – tento byte vypov´ıd´a o typu datov´e ˇc´asti nebo o jej´ı samotn´e existenci, nen´ı vˇsak pˇresnˇe pops´ano, jak´ ym zp˚ usobem. • connection id – tento word je unik´atn´ı pro kaˇzdou sub-komunikaci (poˇzadavek + odpovˇed’). • sub-sequence – pokud je odpovˇed’ delˇs´ı neˇz kapacita X.25 paketu, je nutn´e ji rozdˇelit do v´ıce ˇc´ast´ı (fragment˚ u). K identifikaci poˇrad´ı fragment˚ u slouˇz´ı tento byte. • session id – toto informaˇcn´ı pole je nejsp´ıˇse unik´atn´ı pro kaˇzd´e sezen´ı, tedy od pˇrihl´aˇsen´ı aˇz do odhl´aˇsen´ı. Tabulka podm´ınek pro dalˇs´ı operace: dir 1 2 2 2 3 4 0x0c 0x0e 3
pltype 2 1 2 1 0 1 0 6
subseq operace something – parsuj jako blok >1 continued answer – interpretuj pˇr´ımo ≤1 long answer – parsuj jako blok short answer – parsuj jako blok command confirmation – parsuj jako blok login attempt – parsuj jako blok login accept – parsuj jako blok something – parsuj jako blok confirmation, send more – datov´a ˇc´ast neexistuje
Tabulka 3.2: Pˇrehled n´asledn´ ych operac´ı podle preambule
13
3.2
Uˇ ziteˇ cn´ a data (payload)
Datov´a ˇc´ast se skl´ad´a z nˇekolika blok˚ u, kter´e mohou b´ yt dokonce obsaˇzeny rekurentnˇe samy v sobˇe. Kaˇzd´ y takov´ yto blok je uvozen trojic´ı byt˚ u, kde prvn´ı byte identifikuje ˇc´ıslo bloku (ID), a n´asleduj´ıc´ı word jeho d´elku (LEN). N´asleduje uˇziteˇcn´a informace o d´elce LEN. Jak jsem jiˇz uvedl dˇr´ıve, nˇekter´e kombinace ID vypov´ıdaj´ı o tom, ˇze uˇziteˇcn´a ˇc´ast bloku se m´a opˇet parsovat a vyhledat v n´ı dalˇs´ı bloky. Struktura obecn´eho bloku je pops´ana v tabulce 3.3. offset d´elka 0 1 1 2 3 LEN
v´ yznam id d´elka uˇziteˇcn´ ych dat (LEN) data
Tabulka 3.3: Struktura obecn´eho bloku
Dalˇs´ı bloky se jiˇz neparsuj´ı rekurentnˇe a jejich v´ yznam je pops´an v tabulce 3.4, kde ”x” je z´astupn´ y znak pro libovolnou hodnotu.
3.3
V´ ysledek anal´ yzy
I pˇresto, ˇze nebyl beze zbytku zjiˇstˇen v´ yznam nˇekter´ ych byt˚ u nebo dokonce cel´ ych datov´ ych pol´ı, praktick´ ymi zkouˇskami bylo ovˇeˇreno, ˇze jejich obsah nen´ı pro funkˇcnost komunikace podstatn´ y a ve vˇetˇsinˇe pˇr´ıpad˚ u postaˇc´ı dan´e datov´e pole vynechat nebo ho naplnit libovolnou hodnotou. V´ yznam pol´ı nutn´ ych pro spr´avnou funkˇcnost komunikace byl tedy zjiˇstˇen a proto je moˇzn´e anal´ yzu oznaˇcit za u ´spˇeˇsnou.
14
pozice ve stromu offset d´elka x-2 3 2 x-2 5 2 x-2 7 x-3-1 x-3-2 x-3-3 x-3-5 x-4-1 dir=4, pltype=0 x-4-1 x-4-2 x-4-3 x-4-3-2-2 x-4-3-2-3 x-4-4 x-4-5 x-4-6 3 1 x-4-6 4 1 x-4-6 5 1 x-4-7 3 1 x-4-7 4 1 x-4-7 5 1 x-5-2 x-6-1 x-7
v´ yznam unknown1 job number unknown2 exchange name APS version patch version username terminal name exchange name APS version patch version username password terminal name username year month day hour minute second error message command answer
Tabulka 3.4: V´ yznam jednotliv´ ych blok˚ u
15
Kapitola 4 Aplikace V´ yznamnou ˇc´ast´ı diplomov´e pr´ace bylo pouˇzit´ı z´ıskan´ ych znalost´ı o protokolu u ´stˇredny pro implementaci komunikaˇcn´ıho programu.
4.1
St´ avaj´ıc´ı aplikace
Efektivn´ım ˇreˇsen´ım bylo doplnˇen´ı jiˇz existuj´ıc´ı dvojice program˚ u ewrecv a ewterm o funkˇcnost, kter´a vyuˇz´ıv´a kan´al X.25 pro pˇrenos pˇr´ıkaz˚ u a m˚ uˇze tak v budoucnu zcela nahradit komunikaci pˇres s´eriov´e rozhran´ı. Architektura program˚ u ewrecv a ewterm odpov´ıd´a sch´ematu klient/server kdy ewrecv pln´ı roli serveru a realizuje samotnou komunikaci s u ´stˇrednou. Smˇerem ke sv´ ym klient˚ um (ewterm) komunikuje pˇres vlastn´ı stavov´ y protokol vyuˇz´ıvaj´ıc´ı pro transport protokol TCP. S´eriov´e rozhran´ı mezi u ´stˇrednou a ewrecv i mezi ewrecv a ewterm je znakovˇe orientovan´e, coˇz neodpov´ıd´a pˇr´ıstupu pˇres protokol X.25, kde je datov´ y pˇrenos orientovan´ y paketovˇe. Upravovat protokol mezi ewrecv a ewterm na paketovˇe orientovan´ y by bylo asi optim´aln´ı ˇreˇsen´ı, ale hrozilo by velk´e riziko zanesen´ı chyb a ztr´ata kompatibility se starˇs´ı verz´ı. Rozhodl jsem se proto
16
tento protokol nemˇenit (nakonec jsem ho vˇsak musel rozˇs´ıˇrit). Pˇrepisov´an´ı programu ewrecv na plnohodnotnˇe paketov´ y by bylo znaˇcnˇe n´aroˇcn´e a bez st´al´eho testovan´ı, jestli nebyla ohroˇzena p˚ uvodn´ı funkˇcnost, vlastnˇe nemoˇzn´e. Proto z˚ ustala vnitˇrn´ı architektura programu prakticky nezmˇenˇena (st´ale se tedy jedn´a o znakovˇe orientovan´e rozhran´ı), ale pomoc´ı nˇekolika menˇs´ıch u ´prav a rozˇs´ıˇren´ı bylo dosaˇzeno i toho, ˇze je program schopen pˇrij´ımat a odes´ılat cel´e pakety.
4.2
Volba v´ yvojov´ e a operaˇ cn´ı platformy
Vzhledem k tomu, ˇze jiˇz existuj´ıc´ı sada komunikaˇcn´ıch program˚ u je implementov´ana na platformˇe Linux [3], bylo nejvhodnˇejˇs´ı toto prostˇred´ı zachovat. Syst´em Linux je zn´am´ y pˇredevˇs´ım d´ıky jeho v´ yvojov´emu modelu, kdy se na programov´an´ı pod´ıl´ı znaˇcn´ y poˇcet dobrovoln´ık˚ u internetov´e komunity bez n´aroku na honor´aˇr. Tento zp˚ usob v´ yvoje nab´ız´ı v´ yhody, jako volnˇe dostupn´e a modifikovateln´e zdrojov´e k´ody nebo vynikaj´ıc´ı stabilitu. To jsou d˚ uvody, kter´e mimo jin´e rozhodly pro Linux nejen jako operaˇcn´ı prostˇred´ı pro v´ ysledn´ y program, ale tak´e pro jeho v´ yvoj.
4.3
Volba n´ astroje pro spr´ avu verz´ı
Pro usnadnˇen´ı v´ yvoje, sledov´an´ı zmˇen a snadnˇejˇs´ı hled´an´ı vnesen´ ych chyb jsem se rozhodl pro v´ yvoj pouˇz´ıvat n´astroj pro spr´avu verz´ı. Vzhledem ke znaˇcnˇe decentralizovan´e a offline povaze v´ yvoje jsem pˇri v´ ybˇeru hned vyˇradil Subversion[6] a CVS [1], kter´e pro pr´aci vyˇzaduj´ı neust´al´e spojen´ı s hlavn´ım repozit´aˇrem. Nakonec jsem zvolil SCM1 n´astroj Mercurial [4] s distribuovan´ ym pˇr´ıstupem, kter´ y umoˇzn ˇuje se zdrojov´ ymi k´ody pohodlnˇe pracovat 1
SCM – source control management (spr´ava zdrojov´ ych k´od˚ u)
17
i bez pˇr´ıstupu k hlavn´ımu repozit´aˇri. Mercurial je n´astroj multiplatformn´ı, napsan´ y v jazyku Python[5].
4.4
Rozˇ s´ıˇ ren´ı programu ewrecv
Program ewrecv realizuje serverovou ˇc´ast. Star´a se o komunikaci s u ´stˇrednou (pˇres s´eriovou linku nebo protokol X.25) a klient˚ um poskytuje nez´avisl´e komunikaˇcn´ı rozhran´ı zaloˇzen´e na protokolu TCP. Jeho dalˇs´ım u ´kolem je multiplexov´an´ı jednoho spojen´ı (hlavnˇe v pˇr´ıpadˇe s´eriov´e linky, kdy v´ıce neˇz jedno spojen´ı ani nen´ı moˇzn´e) pro v´ıce klient˚ u, aby bylo moˇzn´e s u ´stˇrednou komunikovat z nˇekolika m´ıst najednou.
4.4.1
Infrastruktura pro serializaci a deserializaci paket˚ u
V´ ysledkem anal´ yzy servisn´ıho protokolu u ´stˇredny Siemens EWSD byla definice struktur pos´ılan´ ych paket˚ u. V samotn´em programu, kde bylo potˇreba tyto pakety interpretovat a sestavovat, by bylo velmi nepohodln´e k dat˚ um pˇristupovat nestrukturovanˇe. Proto jsem vytvoˇril sadu funkc´ı, kter´e posloupnost byt˚ u, pˇren´aˇsen´ ych po ethernetov´e lince, uloˇz´ı do definovan´ ych struktur s pojmenovan´ ymi ˇclensk´ ymi promˇenn´ ymi. Nechyb´ı ani sada funkc´ı, kter´e data z tˇechto struktur opˇet uloˇz´ı jako posloupnost byt˚ u ve spr´avn´em form´atu. T´ım se pr´ace s pakety v´ yraznˇe zjednoduˇs´ı a zaˇcne b´ yt intuitivn´ı. J´adro tvoˇr´ı struktury struct packet a struct block, kter´e pˇredstavuj´ı v´ yˇse popsanou abstrakci. Ned´ılnou souˇc´ast´ı jsou pak funkce packet_deserialize() a block_deserialize(), kter´e maj´ı za u ´kol z obecn´e (ale ne n´ahodn´e) posloupnosti byt˚ u naplnit zm´ınˇen´e struktury. Pro nalezen´ı urˇcit´eho uzlu ve stromu blok˚ u slouˇz´ı funkce block_getchild(). 18
Pˇri vytv´aˇren´ı paketu pouˇzijeme funkci packet_alloc() pro alokaci a inicializaci struktury paketu, pot´e pomoc´ı s´erie vol´an´ı funkce block_addchild() pˇrid´ame poˇzadovan´e uzly (strom se vytv´aˇr´ı automaticky). Nakonec pˇrevedeme struktury na v´ yslednou posloupnost byt˚ u, kter´a je jiˇz pˇripravena k odesl´an´ı pomoc´ı funkce packet_serialize(). Pro spr´avnou funkˇcnost cel´eho syst´emu abstrakce jsem samozˇrejmˇe vytvoˇril vˇetˇs´ı mnoˇzstv´ı funkc´ı. Ty ale ve vˇetˇsinˇe pˇr´ıpad˚ u z˚ ust´avaj´ı pro uˇzivatele skryty. Striktn´ı dodrˇzov´an´ı prefix˚ u packet_ a block_ a logick´ y syst´em vrstven´ı zaruˇcuje snadnou orientaci i pro nezasvˇecen´eho program´atora, kter´ y by chtˇel prov´adˇet modifikace.
4.4.2
Protokol X.25 a paketov´ a komunikace
Program ewrecv je ve sv´em j´adru znakovˇe orientovan´ y, coˇz je pro komunikaci pˇres X.25 nevhodn´e. Hlavn´ı u ´prava tedy spoˇc´ıvala ve vytvoˇren´ı funkc´ı packet_deserialize(), kter´a nˇekolik znak˚ u na vstupu pˇrevede na celistv´ y paket a vytvoˇr´ı strom blok˚ u a ProcessExchangePacket(), kter´a tento strukturovan´ y paket zpracuje. Pro realizaci pln´e funkˇcnosti tak´e vzniklo znaˇcn´e mnoˇzstv´ı d´ılˇc´ıch funkc´ı. Bylo by vˇsak zbyteˇcn´e zde popisovat jejich signatury a funkˇcnost.
4.4.3
Multiplexing pro v´ıce nez´ avisl´ ych uˇ zivatel˚ u
Multiplexing pro v´ıce uˇzivatel˚ u je schopnost rozliˇsit nˇekolik nez´avisl´ ych uˇzivatel˚ u (kdy kaˇzd´ y z tˇechto uˇzivatel˚ u m˚ uˇze b´ yt pˇripojen pˇres nˇekolik instanc´ı programu ewterm najednou), a poskytnout jim moˇznost komunikovat s u ´stˇrednami nez´avisle na uˇzivatel´ıch ostatn´ıch. To vˇse bud’ pˇres jedin´ y fyzick´ y X.25 kan´al, nebo pˇres obecn´ y poˇcet spojen´ı, alokovan´ ych po jednom pro kaˇzd´eho uˇzivatele.
19
Program ewrecv jsem rozˇs´ıˇril o pole spojen´ı na u ´stˇredny, kter´e jsou pˇri pˇr´ıpadn´em v´ ypadku jednotlivˇe obnoveny. Data pˇrijat´a z termin´al˚ u jsou pak rozesl´ana pomoc´ı vˇsech spojen´ı v poli. Odpovˇedi od u ´stˇreden jsou postupnˇe naˇc´ıt´any a rozes´ıl´any k jednotliv´ ym termin´al˚ um. Pro spr´avnou funkˇcnost je nutn´e zajistit deaktivaci interaktivn´ıho MML a zaruˇcit, aby pˇrihlaˇsovac´ı u ´daje (jm´eno a heslo) byly na vˇsech u ´stˇredn´ach stejn´e.
4.5
Rozˇ s´ıˇ ren´ı programu ewterm
´ Upravy programu ewterm byly s u ´pravami v programu ewrecv podstatnˇe m´enˇe n´aroˇcn´e, pˇresto vˇsak ne trivi´aln´ı. Vzhledem k tomu, ˇze program ewterm pˇredstavuje klientskou ˇc´ast, nemus´ı se program´ator zab´ yvat n´asobn´ ym pˇripojen´ım a soubˇehem. Mnoˇzstv´ı uchov´avan´ ych stavov´ ych informac´ı je v porovn´an´ı s programem ewrecv tak´e menˇs´ı.
4.5.1
Re´ aln´ e odhl´ aˇ sen´ı
Hlavn´ı zmˇeny se t´ ykaly obohacen´ı komunikaˇcn´ıho protokolu mezi ewrecv a ewterm o povel pro odhl´aˇsen´ı, nebot’ p˚ uvodnˇe bylo odhl´aˇsen´ı ˇreˇseno pouze odesl´an´ım pˇr´ıkazu ENDSESSION; z termin´alu. Tento zp˚ usob odhlaˇsov´an´ı je platn´ y pouze pro p˚ uvodn´ı s´eriovou komunikaci, ale pro X.25 jiˇz platn´ y nen´ı. Bylo proto nutn´e pˇresunout odhlaˇsovac´ı rutiny do programu ewrecv, obohatit vnitˇrn´ı protokol a upravit ewterm tak, aby toto nov´e rozˇs´ıˇren´ı pouˇz´ıval.
4.5.2
Rozliˇ sen´ı zpr´ av alarm˚ u
Dalˇs´ı zlepˇsen´ı, kter´e pˇrinesla komunikace pˇres X.25, je rozliˇsen´ı pˇr´ıchoz´ıho textu na odpovˇedi na zadan´e pˇr´ıkazy a provozn´ı alarmy a zpr´avy u ´drˇzby,
20
kter´e jsou generov´any automaticky. Je nepˇr´ıjemn´e, kdyˇz se tyto automatick´e zpr´avy vmˇeˇsuj´ı do bˇeˇzn´eho povelovac´ıho sezen´ı, a proto je ˇz´adouc´ı tyto zpr´avy rozliˇsit a zpracov´avat pouze specializovan´ ym klientem. Z tohoto d˚ uvodu bylo nutn´e vnitˇrn´ı protokol jeˇstˇe rozˇs´ıˇrit o povely ”zas´ılat alarmy” a ”nezas´ılat alarmy”. Samozˇrejmˇe jsem musel zmˇeny patˇriˇcnˇe zapracovat i do program˚ u ewrecv a ewterm.
4.6
Napojen´ı na vrstu X.25 v syst´ emu Linux
Tato komunikace prob´ıh´a pˇres protokol X.25. Vzhledem k tomu, ˇze nechceme realizovat pˇrenos pˇres fyzickou vrstvu s protokolem X.25, je nutn´e pakety zapouzdˇrit do protokolu XOT a pˇres transportn´ı vrstvu TCP je pak odeslat d´ale do s´ıtˇe, kde jsou tˇesnˇe pˇred u ´stˇrednou opˇet pˇrevedeny na X.25.
4.6.1
Modul x25tap
Pro u ´spˇeˇsn´e zapouzdˇren´ı je nutn´e X.25 pakety pˇrijat´e linuxov´ ym j´adrem pˇredat do uˇzivatelsk´eho prostoru. O to se postar´a modul x25tap[8], kter´ y vytvoˇr´ı virtu´aln´ı X.25 rozhran´ı, a data podle potˇreby vymˇen ˇuje mezi uˇzivatelsk´ ym prostorem a prostorem j´adra.
4.6.2
D´ emon xotd
Kdyˇz jsou pakety protokolu X.25 pˇred´any modulem x25tap z j´adra, pˇrijme je d´emon xotd [8], kter´ y k nim pˇrid´a XOT hlaviˇcku a poˇsle je na definovanou IP adresu (a port) protokolem TCP. Naopak, pokud pˇrijdou z IP s´ıtˇe XOT pakety, d´emon xotd z hlaviˇcky extrahuje potˇrebn´e informace a d´ale pˇred´a uˇzivatelsk´a data, tedy X.25 paket, j´adru pˇres virtu´aln´ı zaˇr´ızen´ı x25tap.
21
Kapitola 5 Moˇ znosti dalˇ s´ıho v´ yvoje 5.1
Vyuˇ zit´ı dynamick´ ych knihoven Siemens pro z´ısk´ an´ı zak´ odovan´ eho hesla
Bˇehem anal´ yzy propriet´arn´ıho protokolu Siemens bylo zjiˇstˇeno, ˇze pˇri pˇrihlaˇsov´an´ı je heslo pos´ıl´ano ve speci´aln´ım zak´odovan´em form´atu, kter´ y znemoˇzn ˇuje jednoduˇse heslo na lince nahr´at a pot´e opˇetovnˇe pouˇz´ıt pro pˇrihl´aˇsen´ı s pr´avy p˚ uvodn´ıho uˇzivatele. Toto heslo je z´avisl´e na ˇcase (s pˇresnost´ı na sekundy) a je hashov´ano pomoc´ı funkce MD5 nebo jej´ı modifikace. I pˇres znaˇcn´e u ´sil´ı, kter´e by odhalilo algoritmus sestaven´ı t´eto posloupnosti byt˚ u, se tento postup nepodaˇrilo odhalit, a tak jedinou funkˇcn´ı metodou pro z´ısk´an´ı hesla, chr´anˇen´eho proti opˇetovn´emu pˇrehr´an´ı, je pouˇzit´ı bin´arn´ıch Win32 knihoven, kter´e dod´av´a pˇr´ımo firma Siemens a tuto funkˇcnost obsahuj´ı. Z d˚ uvodu nepotˇrebnosti pro funkˇcnost celku byla pouze zpracov´ana pˇr´ıprava postupu pro budouc´ı vyuˇzit´ı pˇri implementaci t´eto funkce do programu ewrecv. V n´asleduj´ıc´ıch ˇc´astech uvedu postup vhodn´ y pro vyuˇzit´ı ˇc´asti bin´arn´ı
22
dynamick´e C++ knihovny z prostˇred´ı Windows na architektuˇre x86. Jedn´a se o ˇceskou verzi anglick´eho ˇcl´anku[9], kter´ y jsem pˇri sv´e v´ yvojov´e ˇcinnosti vytvoˇril.
5.2
Smˇ er dalˇ s´ıho v´ yvoje
Knihovny, ze kter´ ych chceme z´ıskat k´od, jsou naps´any v jazyce C++ a jsou tedy objektovˇe orientovan´e. Linkov´an´ı s objektovˇe orientovan´ ymi knihovnami v dobˇe kompilace nen´ı obecnˇe probl´em, ale k tomuto kroku jsou potˇreba statick´e linkovac´ı knihovny, kter´e Siemens nedod´av´a a tak jedinou moˇznost´ı je dynamick´e linkovan´ı za bˇehu programu. To je vˇsak relativnˇe sloˇzit´a situace. Je velmi jednoduch´e pouˇz´ıt exportovanou funkci v ˇcist´em C, protoˇze jedin´e, co je nutn´e udˇelat, je naj´ıt spr´avnou adresu a pot´e funkci prostˇe zavolat s patˇriˇcn´ ymi argumenty (spr´avn´e argumenty a n´avratov´ y typ vˇsak mus´ıme pˇredem zn´at). V pˇr´ıpadˇe C++ jsou metody tˇr´ıd exportov´any jako bˇeˇzn´e funkce v ˇcist´em C, ale jejich n´azvy jsou manglov´any (takˇze je moˇzn´e m´ıt Class1::DoSomething() i Class2::DoSomething() dohromady). Je v´ yhodou, ˇze nemus´ıme pˇredem vˇedˇet spr´avn´e argumenty a n´avratov´ y typ, protoˇze kompletn´ı signatura metody je souˇc´ast´ı manglovan´eho jm´ena. Hlavn´ı probl´em spoˇc´ıv´a v tom, jak tyto funkce pouˇz´ıt s nˇejakou instanc´ı tˇr´ıdy, tedy jako metody a jak tento celek vhodnˇe obalit tak, aby mˇel vlastnosti tˇr´ıdy/objektu.
5.3
Zp˚ usob dalˇ s´ıho v´ yvoje
Popsan´a metoda nepatˇr´ı k tˇem, kter´e by se mˇely pˇri bˇeˇzn´em programov´an´ı pouˇz´ıvat. Je n´achyln´a na zavleˇcen´ı chyby, kterou kompil´ator nezjist´ı, ale kter´a
23
m˚ uˇze zp˚ usobit p´ad programu. Jinou moˇznost ale pravdˇepodobnˇe nem´ame.
5.3.1
Omezen´ı platformy a architektury
Funkˇcnost je zaruˇcena pouze na platformˇe Windows (moˇzn´a dokonce pouze s kompil´atorem Microsoft Visual C++) a to pouze na architektuˇre x86. Podobnou techniku je moˇzn´e pouˇz´ıt i na jin´ ych platform´ach a architektur´ach, ale postupy se mohou m´ırnˇe i znaˇcnˇe liˇsit.
5.3.2
Demanglov´ an´ı n´ azv˚ u metod
V jazyce C++ neexistuje jednoznaˇcnˇe definovan´ y zp˚ usob, jak by mˇela b´ yt jm´ena funkc´ı manglov´ana, takˇze v´ ysledn´e n´azvy jsou specifick´e pro jednotliv´e kompil´atory. Kompil´ator Microsoft Visual C++ mangluje jm´ena napˇr´ıklad do ??0SLNEPasswd@@QAE@ABV0@@Z (a podobn´ ych). S v´ yhodou pro n´as obsahuje takto manglovan´e jm´eno vˇsechny potˇrebn´e informace, kter´e potˇrebujeme k u ´spˇeˇsn´emu importov´an´ı metod a jejich pouˇzit´ı objektovˇe orientovan´ ym zp˚ usobem. Na internetu lze nal´ezt mnoho n´astroj˚ u, vhodn´ ych pro demanglov´an´ı jmen funkc´ı zpˇet na jejich pln´e signatury. J´a zvolil n´astroj IDA Pro[2]. Jedn´a se o velmi uˇziteˇcn´ y disassembler s mnoha funkcemi. Ostatn´ı n´astroje ale budou pravdˇepodobnˇe tak´e fungovat uspokojivˇe. Takto vypad´a vzorek v´ ystupu po disassemblov´an´ı: ; 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´amo, co funkce oˇcek´av´a jako argumenty a co hodl´a vr´atit. 24
5.3.3
Konvence vol´ an´ı jazyka C++ v syst´ emu Windows
Nejprve importujeme knihovnu pomoc´ı LoadLibrary(), kter´e je souˇc´ast´ı standardn´ıho WinAPI. Pot´e najdeme adresu funkce s pouˇzit´ım vol´an´ı GetProcAddress() (zde pouˇzijeme manglovan´e jm´eno). Dostaneme obecn´ y ukazatel na funkci, takˇze je jeˇstˇe nutn´e ho pˇretypovat na korektnˇe typovan´ y funkˇcn´ı ukazatel. Spr´avnou signaturu jiˇz zn´ame z disassembleru. Importovali jsme tedy funkci, ale zat´ım st´ale nejsme schopni ji zavolat. Probl´emem je to, ˇze ve skuteˇcnosti se nejedn´a o funkci, ale o metodu nˇejak´e tˇr´ıdy, a tato metoda oˇcek´av´a, ˇze bude v dobˇe vol´an´ı existovat odpov´ıdaj´ıc´ı instance. Protoˇze nem´ame k dispozici p˚ uvodn´ı hlaviˇckov´e soubory ani statick´e importn´ı knihovny, nem˚ uˇzeme uˇz zpˇetnˇe zjistit, jak pˇresnˇe je instance dan´e tˇr´ıdy rozloˇzena v pamˇeti. Konkr´etn´ı rozloˇzen´ı n´as ale nezaj´ım´a. Dokud budeme pouˇz´ıvat pouze ˇclensk´e metody (nebudeme se snaˇzit pˇristupovat pˇr´ımo k ˇclensk´ ym promˇenn´ ym), je pro n´as struktura tˇr´ıdy skryt´a a nepodstatn´a. Jedin´e, co mus´ıme uˇcinit, je alokovat u ´sek pamˇeti, ve kter´em budou uloˇzena instanˇcn´ı data. Protoˇze nezn´ame p˚ uvodn´ı signaturu tˇr´ıdy, mus´ıme velikost pamˇeti pouze odhadnout. Nez´aleˇz´ı na tom, jestli bude alokovan´ yu ´sek pamˇeti vˇetˇs´ı, hlavnˇe nesm´ı b´ yt menˇs´ı. Velikost jednoho megabytu m˚ uˇze b´ yt povaˇzov´ana za bezpeˇcnou, ale pokud hodl´ame vytvoˇrit mnoho takov´ ychto ”instanc´ı”, m˚ uˇze b´ yt pamˇet’ spotˇrebov´ana velmi rychle (v praxi by mˇel pro vˇetˇsinu pˇr´ıpad˚ u bohatˇe postaˇcit i jeden kilobyte). Pˇri vol´an´ı typu __thiscall je ukazatel this pˇred´av´an v registru ECX, takˇze je nutn´e tˇesnˇe pˇred vol´an´ı vloˇzit ˇc´ast inline assembly, kter´ y se o to postar´a. Volan´a funkce potom pouˇzije ukazatel z ECX jako ukazatel na this a bude pˇredpokl´adat, ˇze n´ami alokovan´a pamˇet’ je blok obsahuj´ıc´ı instanˇcn´ı data. Funkce tedy vlastnˇe bude vol´ana jako metoda. 25
M˚ uˇzeme ovˇeˇrit debuggerem, ˇze pamˇet’ je po vol´an´ı skuteˇcnˇe zmˇenˇena (samozˇrejmˇe pouze pokud takov´ato metoda m´a nˇeco zmˇenit). Je moˇzn´e pouˇz´ıvat metody vracej´ıc´ı jednoduch´e datov´e typy (int, char *, ukazatele na tˇr´ıdy, cokoliv...), ale co metody, kter´e vracej´ı dalˇs´ı tˇr´ıdy (odkazem)? Zde vˇsak naraz´ıme na dalˇs´ı komplikaci. V konvenci vol´an´ı __thiscall funguje vracen´ı tˇr´ıd n´asleduj´ıc´ım zp˚ usobem: Pamˇet’ je alokov´ana pro tˇr´ıdu, kter´a m´a b´ yt vr´acena a ukazatel na tuto pamˇet’ je pˇred´an jako prvn´ı (skryt´ y) argument. Proto mus´ıme zmˇenit signatury vˇsech funkc´ı, kter´e maj´ı vracet tˇr´ıdu tak, aby vracely void a seznam argument˚ u mus´ıme rozˇs´ıˇrit pˇresnˇe o jeden argument typu void * na prvn´ı pozici. Nyn´ı kdykoliv vol´ame takovouto funkci, nesm´ıme zapomenout alokovat pamˇet’ pro navr´acenou tˇr´ıdu (velikost budeme muset opˇet odhadnout). Varov´ an´ı: Nikde jsme nepouˇzili oper´ator new. To znamen´a, ˇze nikde nebyly vol´any konstruktory. Je proto d˚ uleˇzit´e naimportovat kontruktory jako ostatn´ı metody a zavolat je jako prvn´ı, aby byla n´ami umˇele alokovan´a pamˇet’ naplnˇena smyslupln´ ymi daty z pohledu tˇr´ıdy!
5.3.4
Rekurzivn´ı importov´ an´ı knihoven
Pokud importujete knihovnu pomoc´ı LoadLibrary(), loader nejprve prohled´a importn´ı tabulku (seznam jin´ ych DLL, na kter´ ych tato knihovna z´avis´ı) a pokus´ı se je naloadovat rekurzivnˇe. Pro kaˇzdou knihovnu se snaˇz´ı naj´ıt funkci DllMain() a spustit ji. Pokud jedin´e z tˇechto vol´an´ı vr´at´ı false, cel´ y loadovac´ı proces selˇze. V pˇr´ıpadech, kdy jen potˇrebujete nˇeco extrahovat z jednoduch´e knihovny, bude vˇse bezprobl´emov´e. V m´em pˇr´ıpadˇe bylo ale nutn´e loadovat des´ıtky knihoven se znaˇcnˇe sloˇzit´ ymi z´avislostmi a netrivi´aln´ımi funkcemi DllMain(). Protoˇze jsem ale potˇreboval jen zlomek funkˇcnosti asi dvou knihoven (a nebylo jasn´e, jak korektnˇe odstranit ne26
potˇrebn´e z´avislosti nebo skr´ yt funkce DllMain()), musel jsem disassemblovat vˇsechny knihovny a modifikovat jejich bytecode tak, aby jejich DllMain() prostˇe vˇzdy uspˇely. Pokud tedy selˇze loadov´an´ı nˇejak´e knihovny, m˚ uˇze b´ yt skuteˇcn´ y zdroj probl´emu o nˇekolik stupˇ n˚ u ve stromu z´avislost´ı d´ale (tedy v u ´plnˇe jin´e knihovnˇe).
27
Kapitola 6 Z´ avˇ er 6.1
Celkov´ e zhodnocen´ı
Bˇehem pr´ace se podaˇrilo dos´ahnout v´ ysledk˚ u stanoven´ ych zad´an´ım diplomov´e pr´ace na poˇc´atku. Vˇsechny kroky vykonan´e bˇehem v´ yvojov´e i praktick´e ˇcinnosti byly podrobnˇe zdokumentov´any. Pr´ace poskytuje i n´amˇety pro dalˇs´ı pokraˇcov´an´ı.
6.2
Osobn´ı dojmy a pˇ ripom´ınky
Pˇri anal´ yze jsem byl nucen pouˇz´ıt nejr˚ uznˇejˇs´ıch postup˚ u a prostˇredk˚ u z oblasti poˇc´ıtaˇcov´e techniky. Z´ıskal jsem t´ım mnoho cenn´ ych zkuˇsenost´ı s jin´ ymi operaˇcn´ımi syst´emy a architekturami. Tato ˇcinnost vyˇzadovala, ale hlavnˇe rozˇsiˇrovala, analytick´e myˇslen´ı. Proto se c´ıt´ım b´ yt prac´ı na t´eto diplomov´e pr´aci velmi obohacen. Pouˇzit´ı jazyka C pro v´ yvoj dissectoru do programu Ethereal a pro rozˇs´ıˇren´ı funkˇcnosti program˚ u ewrecv a ewterm byla z hlediska ˇcasov´e n´aroˇcnosti nejlepˇs´ı moˇzn´a volba, ale osobnˇe tento jazyk nepovaˇzuji za vhodn´ y pro v´ yvoj
28
sloˇzitˇejˇs´ıch program˚ u. Kdyby bylo u ´kolem pr´ace napsat komunikaˇcn´ı program od poˇc´atku znova, urˇcitˇe bych zvolil nˇekter´ y z modernˇejˇs´ıch, pravdˇepodobnˇe objektovˇe orientovan´ ych jazyk˚ u. Striktnˇejˇs´ı typov´a kontrola a bohatost standardn´ıch knihoven vedou ke znaˇcnˇe vyˇsˇs´ı produktivitˇe pr´ace, neˇz je tomu v pˇr´ıpadˇe jazyka C.
29
Literatura [1] Concurrent versions system. http://www.nongnu.org/cvs/. [2] Debugger a disassembler ida pro. http://www.datarescue.com/idabase/index.htm. [3] Linux. http://kernel.org/. [4] Mercurial. http://selenic.com/mercurial/. [5] Python. http://python.org/. [6] Subversion. http://tigris.org/subversion/. [7] Wireshark. http://wireshark.org/. [8] xotd a x25tap. http://www.fyonne.net/. [9] Radek Podgorn´ y.
Importing classes from windows dlls.
http://podgorny.cz/moin/ImportingClassesFromWindowsDlls.
30
2006.
