Differences between revisions 4 and 15 (spanning 11 versions)
⇤ ← Revision 4 as of 2006-01-06 15:06:27 →
Size: 3454
Editor: RadekPodgorny
Comment:
← Revision 15 as of 2006-02-06 13:44:07 → ⇥
Size: 5207
Editor: RadekPodgorny
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Nebudu su zde zabyvat nizsimi transportnimi vrstvami. V praxi je pro transport vyuzit protokol X.25 nebo jeho IP verze XOT (X.25 over TCP). 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).
Line 7: Line 7:
Kazda datova zprava zacina sekvenci 11-ti bytu, nazyvejme je preambuli. Volitelne pak nasleduje datova cas nesouci uzitecnou informaci. O tom, jestli se datova cast objevi, ci ne, rozhoduje prave obsah 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.
Line 23: Line 23:
family
Zda se, ze v komukaci 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.		  * '''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.
Line 52: Line 43:
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. Ja jsem jiz predeslal, nektere kombinace ID vypovidaji o tom, ze uzitecna cast bloku se ma opet parsovat a vyhledat v ni dalsi bloky. 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||
Line 59: Line 57:
||x-4|| ||x-4||?||?||
Line 64: Line 62:
||x-6||
||x-8||		 ||x-6||?||?||
||x-8||?||?||
Line 100: Line 98:
||3||1||Year||
||4||1||Month||
||5||1||Day||		  ||3||1||Year||
 ||4||1||Month||
 ||5||1||Day||
Line 106: Line 104:
||3||1||Hour||
||4||1||Minute||
||5||1||Second||		  ||3||1||Hour||
 ||4||1||Minute||
 ||5||1||Second||
Line 115: Line 113:


= 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)

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

?

>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)