Differences between revisions 1 and 9 (spanning 8 versions)
⇤ ← Revision 1 as of 2006-01-06 14:42:59 →
Size: 3364
Editor: RadekPodgorny
Comment:
← Revision 9 as of 2006-01-07 17:15:55 → ⇥
Size: 4070
Editor: RadekPodgorny
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Semestralni prace =
== Analyza protokolu ustredny Siemens EWSD ==		 = Analyza protokolu ustredny Siemens EWSD =
Line 4: 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).

== Preambule ==
Line 22: 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 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.
Line 39: Line 31:
||1||||2||?||something!!! - parsuj jako blok||
dir==2 && subseq>1 Continued answer - interpretuj primo
dir==2 && pltype==1 && subseq<=1 Long answer - parsuj jako blok
dir==2 && pltype==2 Short answer - parsuj jako blok
dir==3 && pltype==1 Command confirmation - parsuj jako blok
dir==4 && pltype==0 Login attempt ? - parsuj jako blok
dir==0x0c && pltype==1 Login accept ? - parsuj jako blok
dir==0x0e && pltype==0 Something!!! - parsuj jako blok
dir==3 && pltype==6 Answer confirmation, send more data - datova cast neexistuje		 ||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||
Line 49: Line 41:
== Datova cast ==
Line 50: Line 43:
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. 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 54: Line 53:
x - nejvyssi uroven bloku ma, zda se, nahodne ID
x-3 && direction==0x0c && pltype==1
x-4
x-4-3 && dir==4 && pltype==0
x-4-3-2 && dir == 4 && pltype==0
x-5 && dir==2 && pltype==0
x-5 && dir==0x0e && pltype == 0
x-6
x-8
||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||?||?||
Line 65: Line 66:
x-2
offset/delka/vyznam
3 2 unknown1
5 2 job number
7 ? unknown2
Line 71: Line 67:
x-3-1 Exchange name
x-3-2 APS version
x-3-3 Patch version
x-3-5 Username		 ||x-2||unknown||
Line 76: Line 69:
x-4-1 && dir==4 && pltype==0 Terminal name  ||offset||delka||vyznam||
 ||3||2||unknown1||
 ||5||2||job number||
 ||7||?||unknown2||
Line 78: Line 74:
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 82: Line 79:
x-4-3-2-2 Username ||x-4-1||dir==4||pltype==0||Terminal name||
Line 84: Line 81:
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 89: Line 85:
x-4-4 Terminal name
x-4-5 Username		 ||x-4-3-2-2||Username||
Line 92: Line 87:
x-4-6
3 1 Year
4 1 Month
5 1 Day		 ||x-4-3-2-3||
Line 97: Line 89:
x-4-7
3 1 Hour
4 1 Minute
5 1 Second		  ||3||6||Date (string)||
 ||9||6||Time (string)||
 ||15||?||unknown||
Line 102: Line 93:
x-5-2 && family==COMMAND && dir==2 && pltype==0 Command error ||x-4-4||Terminal name||
||x-4-5||Username||
Line 104: Line 96:
x-6-1 && family==COMMAND Command ||x-4-6||
Line 106: Line 98:
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||

== Poznamky k implementaci dissectoru pro Ethereal ==

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

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 cas 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 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.

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

Poznamky k implementaci dissectoru pro Ethereal

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