|
Size: 3300
Comment:
|
Size: 4640
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 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 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 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 55: | Line 53: |
| Line 58: | Line 57: |
| ||x-4|| | ||x-4||?||?|| |
| Line 63: | Line 62: |
| ||x-6|| ||x-8|| |
||x-6||?||?|| ||x-8||?||?|| |
| Line 67: | Line 66: |
| x-2 ||offset||delka||vyznam|| ||3||2||unknown1|| ||5||2||job number|| ||7||?||unknown2|| |
|
| Line 73: | 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 78: | Line 69: |
| x-4-1 && dir==4 && pltype==0 Terminal name | ||offset||delka||vyznam|| ||3||2||unknown1|| ||5||2||job number|| ||7||?||unknown2|| |
| Line 80: | 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 84: | Line 79: |
| x-4-3-2-2 Username | ||x-4-1||dir==4||pltype==0||Terminal name|| |
| Line 86: | 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 91: | Line 85: |
| x-4-4 Terminal name x-4-5 Username |
||x-4-3-2-2||Username|| |
| Line 94: | Line 87: |
| x-4-6 3 1 Year 4 1 Month 5 1 Day |
||x-4-3-2-3|| |
| Line 99: | 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 104: | Line 93: |
| x-5-2 && family==COMMAND && dir==2 && pltype==0 Command error | ||x-4-4||Terminal name|| ||x-4-5||Username|| |
| Line 106: | Line 96: |
| x-6-1 && family==COMMAND Command | ||x-4-6|| |
| Line 108: | 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|| = 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. 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 |
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.
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.