|
Size: 3364
Comment:
|
Size: 5768
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 - 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 6: | Line 19: |
| 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 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 39: | Line 51: |
| ||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||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|| |
| Line 50: | Line 136: |
| 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. |
= Implementace dissectoru pro Ethereal = |
| Line 53: | Line 138: |
| Rekurentni bloky se objevuji pro sekvence ID bloku (x oznacuje, ze na ID nezalezi): 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 |
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. |
| Line 64: | Line 140: |
| Dalsi bloky se jiz neparsuji rekurentne a maji nasledujici vyznam: x-2 offset/delka/vyznam 3 2 unknown1 5 2 job number 7 ? unknown2 |
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. |
| Line 71: | Line 142: |
| x-3-1 Exchange name x-3-2 APS version x-3-3 Patch version x-3-5 Username |
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. |
| Line 76: | Line 144: |
| x-4-1 && dir==4 && pltype==0 Terminal name | == Soubory == |
| Line 78: | Line 146: |
| 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 |
* 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)