Differences between revisions 3 and 25 (spanning 22 versions)
⇤ ← Revision 3 as of 2006-01-06 14:51:03 →
Size: 3300
Editor: RadekPodgorny
Comment:
← Revision 25 as of 2006-12-22 23:47:43 → ⇥
Size: 5773
Editor: RadekPodgorny
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= 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

----
Line 3: Line 23:
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 27:
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 43:
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 41: Line 52:
||2||0||?||command - parsuj jako blok||
Line 52: Line 64:
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 55: Line 74:
Line 58: Line 78:
||x-4|| ||x-4||?||?||
Line 63: Line 83:
||x-6||
||x-8||		 ||x-6||?||?||
||x-8||?||?||
Line 67: Line 87:
x-2
||offset||delka||vyznam||
||3||2||unknown1||
||5||2||job number||
||7||?||unknown2||
Line 73: Line 88:
x-3-1 Exchange name
x-3-2 APS version
x-3-3 Patch version
x-3-5 Username		 ||x-2||unknown||
Line 78: Line 90:
x-4-1 && dir==4 && pltype==0 Terminal name  ||offset||delka||vyznam||
 ||3||2||unknown1||
 ||5||2||job number||
 ||7||?||unknown2||
Line 80: Line 95:
x-4-1 Exchange name
x-4-2 APS version
x-4-3 Patch version		 ||x-3-1||Exchange name||
||x-3-2||APS version||
||x-3-3||Patch version||
||x-3-5||Username||
Line 84: Line 100:
x-4-3-2-2 Username ||x-4-1||dir==4||pltype==0||Terminal name||
Line 86: Line 102:
x-4-3-2-3
3 6 Date (string)
9 6 Time (string)
15 ? unknown		 ||x-4-1||Exchange name||
||x-4-2||APS version||
||x-4-3||Patch version||
Line 91: Line 106:
x-4-4 Terminal name
x-4-5 Username		 ||x-4-3-2-2||Username||
Line 94: Line 108:
x-4-6
3 1 Year
4 1 Month
5 1 Day		 ||x-4-3-2-3||
Line 99: Line 110:
x-4-7
3 1 Hour
4 1 Minute
5 1 Second		  ||3||6||Date (string)||
 ||9||6||Time (string)||
 ||15||?||unknown||
Line 104: Line 114:
x-5-2 && family==COMMAND && dir==2 && pltype==0 Command error ||x-4-4||Terminal name||
||x-4-5||Username||
Line 106: Line 117:
x-6-1 && family==COMMAND Command ||x-4-6||
Line 108: Line 119:
x-7 && family==ANSWER Answer  ||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)

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)