[TuT] TCP w AutoIT. Część 3 - Sygnalizacja programów I

[Phoenix_PL]

Witam, w trzeciej części tutoriala. Opiszę tutaj jak zrobić prostą sygnalizację programu - czyli przykładowo, wysyłane przez serwer polecenia będą wykonywane przez klienta i vice versa, na razie sama teoria.

 

Po pierwsze - musimy wymyślić w jakim formacie serwer wysyłać będzie wiadomości i jak klient będzie je interpretował. Klient nie może interpretować wiadomości systemowych, tak jak zwykłych - posłużę się tutaj przykładem chatu TCP. Jeśli serwer wysłałby po prostu, słowne polecenie "wyślij mi swoje IP" - klient potraktował by je wtedy jako normalną wiadomość i wyświetlił w oknie chatu. A nie o to nam chodzi. Dlatego polecenia systemowe powinny się elementarnie różnić od normalnych wiadomości, albo odwrotnie - to normalne wiadomości powinny się różnić od poleceń systemowych. Zaraz to wszystko wyjaśnię.

 

Przyjmijmy pierwszy przypadek - tekst jest traktowany jako wiadomość. Chcemy jednak żeby klient obsługiwał polecenia od serwera. Czym one mogą się różnić? Ano na przykład prefiksem. Przykładowo, zwykła wiadomość wygląda tak: teksttekstblabla, a polecenie systemowe #POLECENIE#poleceniepolecenieblabla. W tym wypadku #POLECENIE# to wiadomość systemowa - wystarczy że klient będzie sprawdzał każdą przychodzącą do niego wiadomość i jeśli wykryje że takowa ma prefiks to potraktuje ją jako polecenie systemowe.

 

Oczywiście klient też musiałby mieć analogicznie taki system - po to żeby odpowiadać serwerowi, jak i również wysyłać do niego polecenia systemowe.

 

Można zrobić też na odwrót. Wtedy poleceniepolecenieblabla byłoby typowym poleceniem systemowym, a #TEKST#teksttekstblabla zwyczajną wiadomością. I jest to lepsze rozwiązanie, jeśli chodzi o bezpieczeństwo programu.

 

Dajmy na to - ktoś sobie podejrzał jakie pakiety wychodzą od naszego klienta do serwera, i zauważył że w jednych są prefiksy #POLECENIE# a w drugich nie ma nic - te drugie to wysyłane przez niego wiadomości. W takim wypadku, nasz "haker" mógłby podejrzeć jakie polecenia systemowe wysyła klient i posługiwać się nimi bez ograniczeń - wystarczy, że wysłałby normalnie do serwera polecenie z prefiksem #POLECENIE#. Duża wada, oczywiście można szyfrować dane, zabezpieczać na różne sposoby, ale można też użyć innej metody i mieć pewność że program będzie bezpieczny.

 

Zamiast tego, można do normalnych wiadomości dodawać prefiksy. Wtedy nasz haker nie mógłby wysyłać z poziomu programu poleceń systemowych, bo wiadomości wysyłane przez niego miałyby wstawiane automatycznie prefiksy - a wiadomości systemowe wysyłane przez program bez udziału użytkownika ich by nie miały. W takim wypadku jedyną możliwością byłaby dekompilacja i zmiana kodu programu, czemu można zapobiec, i mamy dzięki takiemu rozwiązaniu większą pewność i brak wymogu nakładania paru kolejnych zabezpieczeń.

 

Oczywiście zdaję sobie sprawę że pakiety można edytować, bla bla bla, i tak można to złamać, ale nie każdy jest do tego zdolny. No i wystarczy już zwykłe szyfrowanie oraz zabezpieczenie programu przed dekompilacją, żeby praktycznie wyeliminować ryzyko złamania naszych zabezpieczeń.

 

Tak więc przyjmijmy że będziemy używać sygnalizacji, w której wiadomość będzie poprzedzana prefiksem. Dodamy jeszcze po drodze proste szyfrowanie naszych wiadomości, tak dla bezpieczeństwa.

 

Teraz - jak serwer i klient będą interpretować nasze polecenia?

Przyjmijmy że będziemy sami wpisywać polecenia systemowe. Nie mogą one wyglądać tak samo, jak wiadomości, ale też głupie by było wpisywanie #POLECENIE# przed każdym poleceniem - możemy na przykład użyć samego #, na przykład #wyjscie.

 

Wtedy wystarczy że program sprawdziłby czy pierwszym znakiem w wiadomości jest '#'. Ale jest tutaj też kolejny problem.

Jeśli program traktowałby każdą wiadomość z # na początku jako polecenie - wtedy wyklucza to wysyłanie normalnych wiadomości z # początku. I skąd program ma wiedzieć czy takie polecenie w ogóle istnieje?

Możemy posłużyć się do tego tablicą aliasów. Zwykła tablica w której byłyby zapisane wszystkie polecenia systemowe - program przeleciałby ją, szukając tego które my podaliśmy - jeśli by nie znalazł wysłanego przez nas polecenia, wtedy traktowałby je na przykład jako zwykłą wiadomość albo wyrzucałby błąd "Nie znaleziono polecenia". Jeśli by znalazł, wysłałby to polecenie do klienta. Pamiętajmy jakiego typu sygnalizacji używamy - polecenia systemowe bez prefików, wiadomości z prefiksem.

 

Okej, skoro tak, to co by się działo z poleceniem po jego dojściu do klienta? Musiało by zostać odpowiednio zinterpretowane przez niego. Funkcją na przykład. A funkcja wykonywałaby dane polecenie.

 

Ale, co w wypadku kiedy klient musiałby zwrócić serwerowi jakąś wartość? Na przykład swoje IP? Jak to wysłać tak, żeby serwer zrozumiał?

 

Przykładową możliwością jest na przykład wysyłanie polecenia, takiego jakie zostało wysłane przez serwer z znakiem specjalnym (przykładowo /) i wiadomością zwrotną po nim. Wtedy serwer wiedziałby od razu z jakiej funkcji jest zwracana ta wartość. Po dotarciu wiadomości do serwera, wystarczyłoby wtedy usunąć znak specjalny i rozdzielić nazwę polecenia od wartości - i gotowe. W serwerze musiałaby być też funkcja, która obsłuży takie zwrotne polecenia. Oraz sprawdzanie czy to polecenie jest zwrotne - czyli przykładowo:

 

Odebrałem wiadomość. Sprawdzam czy jest to polecenie (nie posiada prefiksu). Jeśli tak - sprawdzam czy jest to polecenie zwrotne (posiada znak specjalny rozdzielający polecenie i wartość zwrotną), jeśli nie - traktuję jak zwykłą wiadomość. Jeśli nie jest to polecenie zwrotne, kieruję je do funkcji interpretującej polecenia. Jeśli jest to polecenie zwrotne, kieruję je do funkcji interpretującej polecenia zwrotne.

 

Może się to wydawać skomplikowane, ale nikt nie powiedział że prosto nie będzie.

 

No dobrze, czyli przykładowy algorytm wysyłania polecenia wyglądałby tak:

[user wpisuje wiadomość: teksttekst]

Klient sprawdza czy jest to polecenie: Nie

Klient dodaje prefiks wiadomości

Klient wysyła wiadomość:

#WIADOMOSC#teksttekst

 

Serwer odbiera wiadomość

[Admin wpisuje polecenie: #wyslijmiswojeip]

Serwer sprawdza czy jest to polecenie: Tak

Serwer usuwa '#'

Serwer wysyła polecenie:

wyslijmiswojeip

 

Klient odbiera polecenie

Klient sprawdza czy jest to polecenie: Tak

Klient sprawdza czy jest to polecenie zwrotne: Nie

Klient interpretuje polecenie

Klient wysyła polecenie zwrotne:

wyslijmiswojeip/192.168.1.1

 

Serwer odbiera polecenie

Serwer sprawdza czy jest to polecenie: Tak

Serwer sprawdza czy jest to polecenie zwrotne: Tak

Serwer kieruje polecenie do funkcji interpretującej polecenia zwrotne.

 

Ot, cała filozofia. To, co będzie w funkcjach interpretujących, oraz resztą praktyki zajmę się w drugim rozdziale tej części tutoriala. Pytania oczywiście zadawaj, jeśli czegokolwiek nie zrozumiesz. Praktyka w tym wypadku jest pełnym odzwierciedleniem teorii, więc jeśli tego nie jesteś w stanie pojąć, to z praktyką też możesz mieć problem.

 

Wiem że mogą być lepsze algorytmy, pomysły, itp - to jest akurat mój, prosty pomysł na taką sygnalizację. Ciekawymi pomysłami i rozwiązaniami nie pogardzę. Praktyka w następnej części tuta, bo narazie nie mam weny twórczej, a po drodze może się okazać że czegoś nie wyjaśniłem wystarczająco dokładnie albo ktoś czegoś nie rozumie, co w porę zdążę poprawić.

[abbadonIT]

Poradnik tak samo świetny jak dwie części poprzednie

[Thaid]

Nie wiem czy to nie będzie odkop, ale znalazłem błąd, a mianowicie:

 

 

Klient sprawdza czy jest to polecenie zwrotne: Nie

 

Jest to bowiem polecenie zwrotne, jak później wynika z kolejnych kroków.

[Phoenix_PL]

@Thaid, nie jest to błąd. Dopiero klient wysyła polecenie zwrotne do polecenia "wyslijmiswojeip" wysłanego przez serwer, a dostaje od serwera polecenie (nie zwrotne, bo serwer je wysyła dzięki temu że admin wpisał takie polecenie)

[JestemPolakiem]

Wyślij linki do poprzednich tutoriali z tcp.

@down

Dzięki, byłem wczoraj na telefonie i nie mogłem wejść na profil użytkownika ; d

[Phoenix_PL]

@JestemPolakiem masz u mnie na profilu, rzucają się w oczy