|
Size: 5602
Comment:
|
Size: 5778
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| * login bez replay | * login bez replay (./) |
| Line 8: | Line 8: |
| * address parsing * username parsing |
* address parsing (./) * username parsing (./) * username parsing from ewterm? (./) |
| Line 11: | Line 12: |
| * skutecny login success parse a reakce * synteticky header do tela zpravy * uprava xotd, aby umel prijmout odpodev na call na jinem LCI |
* 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 |
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)