Differences between revisions 20 and 27 (spanning 7 versions)
⇤ ← Revision 20 as of 2006-11-26 14:22:37 →
Size: 5528
Editor: RadekPodgorny
Comment:
← Revision 27 as of 2007-01-07 18:28:12 → ⇥
Size: 5793
Editor: RadekPodgorny
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
 * command completion  * command completion - cleanup
Line 5: Line 5:
 * login bez replay  * login bez replay (./)
Line 7: Line 7:
 * reconnect
 * address parsing
 * username parsing
 * logout primitivum do IProto a emulace ENDSESSION
 * skutecny login success parse a reakce
 * synteticky header do tela zpravy		  * reconnect (./)
 * address parsing (./)
 * username parsing (./)
 * username parsing from ewterm? (./)
 * logout primitivum do IProto a emulace ENDSESSION (./)
 * skutecny login success parse a reakce (./)
 * synteticky header do tela zpravy? (./)
 * uprava xotd, aby umel prijmout odpoved na call na jinem LCI (./)
 * multiplexing pro vice nezavislych ewtermu
 * multiplexing smerem k ustredne?
 * zasilat/nezasilat alarmy

TODO

  • command completion - cleanup
  • logout

  • login bez replay (./)

  • napsat kecy

  • reconnect (./)

  • address parsing (./)

  • username parsing (./)

  • username parsing from ewterm? (./)

  • logout primitivum do IProto a emulace ENDSESSION (./)

  • skutecny login success parse a reakce (./)

  • synteticky header do tela zpravy? (./)

  • uprava xotd, aby umel prijmout odpoved na call na jinem LCI (./)

  • multiplexing pro vice nezavislych ewtermu
  • multiplexing smerem k ustredne?
  • zasilat/nezasilat alarmy

Analyza protokolu ustredny Siemens EWSD

Nebudu se zde zabyvat nizsimi transportnimi vrstvami. V praxi je pro transport vyuzit protokol X.25 nebo jeho IP verze XOT (X.25 over TCP).

Preambule

Kazda datova zprava zacina sekvenci 11-ti bytu, nazyvejme je preambuli. Volitelne pak nasleduje datova cast nesouci uzitecnou informaci. O tom, jestli se datova cast objevi, ci ne, rozhoduje prave obsah preambule.

Rozbor preambule:

offset

delka

vyznam

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

unknown3

10

1

tail

Preambule podrobneji:

  • family - Zda se, ze v komunikaci se vyskytuji dve hlavni rodiny zprav. Rodina COMMAND (family == 0xf1) a ANSWER (family == 0xf2).

  • direction - Zprvu se zdalo, ze tento byte ma neco spolecneho se smerem komunikace (ustredna->terminal nebo opacne), ale dalsi nasbirana data to nepotvrdila.

  • payload type - Tento byte vypovida o typu datove casti nebo o jeji samotne existenci, zatim vsak neni presne popsano jakym zpusobem.

  • connection id - Zda se, ze tento word je unikatni pro kazdou sub-komunikaci (pozadavek+odpoved).

  • sub-sequence - Pokud je odpoved prilis dlouha, je nutne ji rozfragmentovat. Zda se, ze k identifikaci poradi fragmentu slouzi tento byte.

Tabulka podminek pro dalsi operace:

dir

pltype

subseq

operace

1

2

?

something!!! - parsuj jako blok

2

0

?

command - parsuj jako blok

2

?

>1

Continued answer - interpretuj primo

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

?

Answer confirmation, send more data - datova cast neexistuje

Datova cast

Datova cast se sklada z nekolika bloku, ktere mohou byt dokonce obsazeny rekurentne samy v sobe. Kazdy takovyto blok je uvozen trojici bytu, kde prvni byte identifikuje cislo bloku (ID) a nasledujici word jeho delku (LEN). Nasleduje uzitecna informace o delce LEN. Jak jsem jiz predeslal, nektere kombinace ID vypovidaji o tom, ze uzitecna cast bloku se ma opet parsovat a vyhledat v ni dalsi bloky.

Struktura bloku:

offset

delka

vyznam

0

1

id

1

2

delka uzitecnych dat

3

?

data

Rekurentni bloky se objevuji pro sekvence ID bloku (x oznacuje, ze na ID nezalezi):

level

dir

pltype

komentar

x

?

?

nejvyssi uroven bloku ma, zda se, nahodne ID

x-3

0x0c

1

x-4

?

?

x-4-3

4

0

x-4-3-2

4

0

x-5

2

0

x-5

0x0e

0

x-6

?

?

x-8

?

?

Dalsi bloky se jiz neparsuji rekurentne a maji nasledujici vyznam:

x-2

unknown

  • offset

    delka

    vyznam

    3

    2

    unknown1

    5

    2

    job number

    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

  • 3

    6

    Date (string)

    9

    6

    Time (string)

    15

    ?

    unknown

x-4-4

Terminal name

x-4-5

Username

x-4-6

  • 3

    1

    Year

    4

    1

    Month

    5

    1

    Day

x-4-7

  • 3

    1

    Hour

    4

    1

    Minute

    5

    1

    Second

x-5-2

family==COMMAND

dir==2

pltype==0

Command error

x-6-1

family==COMMAND

Command

x-7

family==ANSWER

Answer

Implementace dissectoru pro Ethereal

Pro analyzu samotneho protokolu byl zvolen postup pres implementaci rozsireni do open-source programu Etherealu. Ten jiz obsahuje mnozstvi protokolu a proto nam usetri praci s protokoly nizsich vrstev (v nasem pripade Ethernet-IP-TCP-XOT-X.25) a budeme se moci soustredit pouze na servisni protokol ustredny. Plugin bude implementovan v jazyce C coz sice neni nejvhodnejsi reseni vzhledem k neexistenci datoveho typu string a snadnosti "vyrobeni" chyby, ale na druhou stranu si usetrime eventualni problemy s okolni kompatibilitou, nebot samotny Ethereal je v jazyce C napsan.

Pro samotnou analyzu paketu se v Etherealu pouzivaji tzv. dissectory. Jedna se o skupinu funkci, ktere jako svuj argument prijmou datovou cast paketu, provedou analyzu a pripadne zavolaji na payload dalsi dissectory. Bohuzel neni architektura Etherealu dostatecne flexibilni a proto bylo nutne modifikovat dissector protokolu X.25 tak, aby vzdy rovnou volal nas dissector EWSD.

V hlavni funkci dissectoru (dissect_ewsd()) se pouze vola funkce dis_preamble(). Ta analyzuje preambuli podle vyse uvedenych pravidel, nastavi se globalni promenne hf_ewsd_??? a v pripade potreby se zavola jeste dissektor bloku (dis_ewsd()). Tato funkce pak podle specifikovanych pravidel bud vola rekurzivne sama sebe, nebo uz interpretuje koncova data.

Soubory

  • attachment:ethereal-0.10.13-ewsd.diff - patch proti Etherealu (verze 0.10.13)
  • attachment:ethereal-0.10.14-ewsd.diff - patch proti Etherealu (verze 0.10.14)