|
Size: 3304
Comment:
|
Size: 5450
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = Semestralni prace = == Analyza protokolu ustredny Siemens EWSD == |
= TODO = |
| 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). | * command completion * logout * login bez replay * napsat kecy * reconnect * address parsing * username parsing * logout primitivum do IProto a emulace ENDSESSION * skutecny login success parse a reakce |
| Line 6: | Line 13: |
| 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. | ---- = 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. |
| Line 22: | Line 37: |
| 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 49: | Line 55: |
| Line 52: | Line 57: |
| 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 67: |
| 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 66: | Line 80: |
| x-2 offset/delka/vyznam 3 2 unknown1 5 2 job number 7 ? unknown2 |
|
| Line 72: | Line 81: |
| x-3-1 Exchange name x-3-2 APS version x-3-3 Patch version x-3-5 Username |
||x-2||unknown|| |
| Line 77: | Line 83: |
| x-4-1 && dir==4 && pltype==0 Terminal name | ||offset||delka||vyznam|| ||3||2||unknown1|| ||5||2||job number|| ||7||?||unknown2|| |
| Line 79: | Line 88: |
| 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 83: | Line 93: |
| x-4-3-2-2 Username | ||x-4-1||dir==4||pltype==0||Terminal name|| |
| Line 85: | Line 95: |
| 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 90: | Line 99: |
| x-4-4 Terminal name x-4-5 Username |
||x-4-3-2-2||Username|| |
| Line 93: | Line 101: |
| x-4-6 3 1 Year 4 1 Month 5 1 Day |
||x-4-3-2-3|| |
| Line 98: | Line 103: |
| x-4-7 3 1 Hour 4 1 Minute 5 1 Second |
||3||6||Date (string)|| ||9||6||Time (string)|| ||15||?||unknown|| |
| Line 103: | Line 107: |
| x-5-2 && family==COMMAND && dir==2 && pltype==0 Command error | ||x-4-4||Terminal name|| ||x-4-5||Username|| |
| Line 105: | Line 110: |
| x-6-1 && family==COMMAND Command | ||x-4-6|| |
| Line 107: | Line 112: |
| 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
- logout
- login bez replay
- napsat kecy
- reconnect
- address parsing
- username parsing
- logout primitivum do IProto a emulace ENDSESSION
- skutecny login success parse a reakce
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)