|
Size: 3454
Comment:
|
Size: 5768
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 59: | Line 78: |
| ||x-4|| | ||x-4||?||?|| |
| Line 64: | Line 83: |
| ||x-6|| ||x-8|| |
||x-6||?||?|| ||x-8||?||?|| |
| Line 100: | Line 119: |
| ||3||1||Year|| ||4||1||Month|| ||5||1||Day|| |
||3||1||Year|| ||4||1||Month|| ||5||1||Day|| |
| Line 106: | Line 125: |
| ||3||1||Hour|| ||4||1||Minute|| ||5||1||Second|| |
||3||1||Hour|| ||4||1||Minute|| ||5||1||Second|| |
| Line 115: | Line 134: |
= 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)