Przekierowanie połączenia TCP

Witajcie :)
Chcę napisać pewnego rodzaju proxy, tylko dwuczęściowe,
żeby przekierować ruch z klienta gry przez mój program do serwera gry.

Chciałbym żeby gracz łączył się klientem z moim programem u niego na komputerze,
a dopiero ten przekierowywał do mojego programu na maszynie z serwerem,
a ten następnie dopiero do serwera gry.

Komputer gracza[Klient gry --> Mój program 1] ====> Komputer z serwerem gry[Mój program 2 --> Serwer gry]

Chciałbym to zrobić za pomocą indy 10. Najlepiej z jakąś autoryzacją, jak np. Socks5.
Jak dokładnie powinno takie połączenie wyglądać? Jak rozmieścić kontrolki server/client?
Jak ktoś ma jakieś ciekawe pomysły, rady albo materiały to czekam na informacje.
Pozdrawiam.

a jesteś w stanie w grze ustawić, żeby się łączyła z innym IP niż to, które założył autor?

Tak, oczywiście. W zasadnie to napisałem już podobny program..
Może nie tyle podobny, ale proxy jako "Mój program 1" na powyższym schemacie.
Niestety tylko na zwykłych Client/ServerSocket, a tam nie ma żadnej autoryzacji.
Program działa tylko po stronie klienta, więc wystarczy wziąć inny Launcher do gry,
zmienić ip i port i normalnie połączyć się do serwera bez mojego programu,
a dokładniej to antycheata, który wyłapuje i nie wysyła złych pakietów,
jak np na wyrzucanie graczy z serwera czy na kopiowanie ekwipunku.
Do tego posiada skanowanie nazw programów oraz dumpów.
Chciałbym żeby to się odbywało na dwa programy, ponieważ po stronie
serwera, o ile wymyślę coś z autoryzacją, można nie dopuszczać do połączenia.
Do tego program po stronie serwera może przekierowywać połączenie po localu,
a serwer gry można zablokować w firewallu na przychodzące z poza localhosta.
W takim przypadku beż mojego programu nikt by się nie połączył.
Idea dobra jest, umiejętności jako takie również,
ale pomysłów na realizację brakuje :(

Pamiętaj, że jest i tak niezałatana droga z klienta gry do klienta proxy i jeśli podepnę się w to miejsce dalej mam możliwość ingerencji w pakiety nawet jeśli zapewniłbyś bezpieczny kanał.

Zdaję sobie z tego sprawę, ale tutaj bardziej chodzi o zablokowanie cheatów,
przez właśnie skanowanie nazw i dumpów, bo bez nich mało kto rozkoduje i zakoduje
poprawnie pakiet do np. tego kopiowania.

Cytek10 napisał(a):

Zdaję sobie z tego sprawę, ale tutaj bardziej chodzi o zablokowanie cheatów,
przez właśnie skanowanie nazw i dumpów, bo bez nich mało kto rozkoduje i zakoduje
poprawnie pakiet do np. tego kopiowania.

Masz ci los, wziął się newbie za anticheat, będzie Sophail...

Jeżeli chcesz autoryzować, to najlepiej od razu po ustanowieniu połączenia które będzie potem stanowiło łącze gry wysłać z serwera losowy numer na który klient odpowie numerem który będzie przyporządkowany temu od serwera jakimś algorytmem. Potem możesz całą transmisję szyfrować. Ale i tak raczej nie będziesz w stanie przechwycić cheatów na poziomie socketu. Są różnego rodzaju aimboty, wallhacki itp. których twój anticzit nie wykryje.
Akurat tak się składa że jakiś czas temu pisałem własny anticheat. Tam zastosowałem architekturę klienta w którego wstrzykiwana jest dllka która kontroluje pracę gry i wysyła log na mój serwer a łączysz się normalnie (modyfikacje na poziomie packetów są wykrywane poprzez wykrywanie lokalnych/zfakowanych połączeń). I powiem ci, że wykrywanie czitów nie dając się samemu łatwo zhackować to temat nieprosty i wymagający dużej wiedzy, której tobie po poziomie pytań widać, że brakuje.
I jeszcze powiedz o jakie nazwy i dumpy ci chodzi. Nazwy procesów? Prześmieszne... Dumpy czego? Jak je będziesz analizować?

Dumpy cheatów, oraz ich nazwy(Caption formy). Nie ma ich dużo dostępnych.
Tak się składa, że nie grożą mi aimboty czy wallhacki, ponieważ jest
to gra mmorpg, w całości bazująca na pakietach, więc z poziomu
socketa można bardzo dużo zrobić.

a ja nie bardzo rozumiem te całe wywody - jesteś w stanie filtrować pakiety i odrzucać te złe po stronie klienta jako proxy a nie jesteś w stanie tego zrobić na serwerze, gdzie tak naprawdę gracz nie może niczego zrobić ani "podpiąć" się za proxy?
Dalej rozumiem, że ta gra to nie Twój projekt i nie masz dostępu do źródeł, bo jeśli masz źródła to całe to proxy to dla mnie głupota.

Tak, to nie jest moja gra, ale pliki serwerowe są ogólnie dostępne.
Po stronie serwera też bym zrobił takie proxy, tylko chciałem się
teraz przerzucić na coś lepszego niż standardowe sockety.
Chociaż nie koniecznie, jak bym wymyślił coś na autoryzację
przy socketach, wszak nie miałem z nimi większych problemów..

tylko chciałem się
teraz przerzucić na coś lepszego niż standardowe sockety.

Na co chciałeś się przerzucić lepszego niż sockety?!

Chociaż nie koniecznie, jak bym wymyślił coś na autoryzację
przy socketach, wszak nie miałem z nimi większych problemów..

Wystarczy czytać, no ale gdzie ja.

-321oho napisał(a)

Jeżeli chcesz autoryzować, to najlepiej od razu po ustanowieniu połączenia które będzie potem stanowiło łącze gry wysłać z serwera losowy numer na który klient odpowie numerem który będzie przyporządkowany temu od serwera jakimś algorytmem. Potem możesz całą transmisję szyfrować.

I po co ci autoryzacja skoro jesteś w stanie wykrywać czity server-side only. Moja przypuszczenia się potwierdzają: będzie sophail.

Wszystkich nie wykryje pakietami, ale zdecydowaną większość.
Na pozostałe potrzebuję program u klienta.
I nie chce autoryzować po ustanowieniu połączenia,
wszak mnie to nie satysfakcjonuje, wolałbym przed..

I nie chce autoryzować po ustanowieniu połączenia,
wszak mnie to nie satysfakcjonuje, wolałbym przed..

Facepalm. To wysyłaj gołębia pocztowego żeby się zautoryzować.

-321oho napisał(a):

I nie chce autoryzować po ustanowieniu połączenia,
wszak mnie to nie satysfakcjonuje, wolałbym przed..

Facepalm. To wysyłaj gołębia pocztowego żeby się zautoryzować.

Próbowałem, ale nigdy nie wracał.
A jakieś inne pomysły/porady?

Zrób tak jak jest to na schemacie, który przedstawiłeś. Z tym, że nie rób specjalnej aplikacji klienckiej do klienckiego PROXY tylko hook'uj funkcje WinSock'a, wyelminuje to pokonanie cię swoją własną bronią poprzez podpięcie się w sposób jaki opisałem w 1 poście. Dzięki szyfrowaniu komunikacji do serwera wymusisz stosowanie własnej aplikacji bo tylko Ty tak naprawdę będziesz wiedział jak komunikować się z serwerem PROXY.
Mając już swoją dajmy na to zainjectowaną dll'kę klienta PROXY możesz reagować na sygnatury cheat'ów. Całe zabezpieczenie jest na tyle silne na ile zdołasz zabezpieczyć zainjectowaną DLL'kę przed RE.
Kolejnym poziomem obrony mogła by być filtracja po stronie serwera PROXY przed serwerem gry wyłapująca znane bugi ingerujące w pakiety.

Zabezpieczenie podane przez @-123oho podejrzewam, że łatwo byłoby ominąć (z tak zdawkowego opisu) - podmieniając komunikację z serwerem i uciszając klienta trefnymi logami.

W grze KalOnline komunikacja była szyfrowana AES'em po 128 bitowych blokach z hasłem zmienianym co przychodzący pakiet. Pierwszy WelcomePacket zawierał 1 klucz. Możesz to osiągnąć przez komponenty ClientSocket i ServerSocket. Niestety komponenty te pozostawiają wiele do życzenia jeśli chodzi o wydajność i proponowałbym użycie czystego WinSock'a. Co do autoryzacji innej niż symetryczna to jest to dość trudne zagadnienie. Może podczas rejestracji mógłbyś wysyłać klientowi zestaw kluczy, z których mógłbyś później skorzystać, ale wprowadza to wiele zamieszania. A i tak kiedyś musisz ich użyć więc to tylko kwestia czasu aż zostaną przechwycone.

Podejście masz w zasadzie tylko jedno. Jeśli ktoś dowie się w jaki sposób odbywa się komunikacja zaczynasz od nowa.

Próbowałem, ale nigdy nie wracał.
A jakieś inne pomysły/porady?

Nie wracał dlatego że autoryzacja się nie powiodła.
Nie można się autoryzować nie inicjując komunikacji, wszystko o czym wspomina @szopenfx wynika właśnie z komunikacji.

Zabezpieczenie podane przez @-123oho podejrzewam, że łatwo byłoby ominąć (z tak zdawkowego opisu) - podmieniając komunikację z serwerem i uciszając klienta trefnymi logami.

Ale które moje zabezpieczenie? Chodzi o mój schemat anticheata mojego? Tam wszystko opierało się na trudności RE biblioteki anticheata (dużo antidebugów, własny packer etc.), logowaniu w dwa miejsca (serwer zdalny, dysk lokalny - szyfrowane) i kluczu który był emitowany przez serwer w trakcie gry. Dodatkowo z gry można było każdego klienta odpytać o różne parametry połączenia, więc raczej trudno byłoby zdławić podejrzenia podając fałszywe dane (anticheat logował dużo informacji o komputerze i środowisku). Łatwiej już było zmodyfikować bibliotekę anticheata, ale tutaj znów się kłaniają utrudnienia RE.
P.S. Teraz jestem -321oho.

Z tym, że nie rób specjalnej aplikacji klienckiej do klienckiego PROXY tylko hook'uj funkcje WinSock'a, wyelminuje to pokonanie cię swoją własną bronią poprzez podpięcie się w sposób jaki opisałem w 1 poście.

Bo akurat to dużo trudniej się podpiąć pod winsock już w twojej bibliotece anticheata... Można też złamać bibliotekę gry i hookować wywołania winsocka z kodu gry.

Dzięki szyfrowaniu komunikacji do serwera wymusisz stosowanie własnej aplikacji bo tylko Ty tak naprawdę będziesz wiedział jak komunikować się z serwerem PROXY.

I osoby które odtworzą algorytm komunikacyjny. Zupełnie podobnie do mojego rozwiązania:

-321oho napisał(a)

Jeżeli chcesz autoryzować, to najlepiej od razu po ustanowieniu połączenia które będzie potem stanowiło łącze gry wysłać z serwera losowy numer na który klient odpowie numerem który będzie przyporządkowany temu od serwera jakimś algorytmem. Potem możesz całą transmisję szyfrować.

Tylko problem leży w tym że pytacz nie rozumie po polsku i nie jest w stanie do niego dotrzeć, że komunikacja jest potrzebna, żeby być w stanie autoryzować klienta. Inaczej nie wiesz czy klient do ciebie wysyła śmieci czy coś zaszyfrowane i możesz tylko to usiłować odszyfrować.

W grze KalOnline komunikacja była szyfrowana AES'em po 128 bitowych blokach z hasłem zmienianym co przychodzący pakiet. Pierwszy WelcomePacket zawierał 1 klucz. Możesz to osiągnąć przez komponenty ClientSocket i ServerSocket. Niestety komponenty te pozostawiają wiele do życzenia jeśli chodzi o wydajność i proponowałbym użycie czystego WinSock'a. Co do autoryzacji innej niż symetryczna to jest to dość trudne zagadnienie. Może podczas rejestracji mógłbyś wysyłać klientowi zestaw kluczy, z których mógłbyś później skorzystać, ale wprowadza to wiele zamieszania. A i tak kiedyś musisz ich użyć więc to tylko kwestia czasu aż zostaną przechwycone.

Czyli dochodzi do typowej konkluzji: nie ma zabezpieczenia idealnego.

Wiadomo że nie ma zabezpieczeń nie do złamania.
A myślicie że standardowe sockety po stronie serwera
wytrzymają 120 klientów online?

a są jeszcze jakieś inne sockety? Uważasz, że np. INDY ma w środku coś innego niż "standardowy" socket?

Ja się tylko wtrące, że jeżeli wspomniano iż komponenty są nie wydajne, co w przypadku tymbardziej Indy może być możliwe to ja od siebie polecam Simple Tcp z: http://piechnat.pl/article/simpletcp.html - o ile urządza autora tylko TCP. Wprawdzie ja wykorzystywałem to tylko w większości swoich kodów do tworzenia klientów i to głownie do obsługi HTTP, ale serwer i komunikacje też nie problem zrobić. Trzeba by tylko wzbogacić to o szyfrowanie. Niemniej jednak moduł i komponent jest według mnie napisany prawidłowo i optymalnie, a jego ogromną zaletą jest to, że działa również i nadaje się pod czyste WinAPI, co osobiście mnie bardzo "urządzało". Zresztą z myślą o takim zastosowaniu pisał to autor komponentów. Jak coś to na stronie są pokazane proste przykłady wykorzystania klienta oraz serwera.

Dzięki olesio że i ty się udzieliłeś. Myślisz że to rozwiązanie
sprosta 120-150 połączeń ciągłego ruchu w obie strony?
I tak, tylko TCP mi potrzebne.

Myślę, że powinno dać radę. Ale zależy jak to później zaprogramujesz. Możesz według mnie wykorzystać gotowy przykład na stronie tego projektu, pokazujący jak zrobić prosty klient oraz serwer odsyłający wysłane zapytania i stworzyć ze 150 klientów lokalnie w pętli i zrobić aby co losowe kilka sekund czy częściej wysyłały jakiś testowy request identyfikujący ich po nazwie. Oczywiśćie tak jak pokazano z wykorzystaniem wątków. Dzięki temu będziesz wiedział jak to się wyrabia i wygląda. Oczywiście docelowo ważne będą pewnie również wielkości pakietów danych oraz posiadane łącza przez użytkowników programu. Tak mi się zdaje. A więcej pewnie doradzą Tobie tutaj pewnie bardziej doświadczeni w pisaniu aplikacji klient-serwer, ja pisałem na bazie tego modułu głownie proste klienty wykorzystujące HTTP, tak jak wspomniałem wcześniej.

Dzięki olesio że i ty się udzieliłeś. Myślisz że to rozwiązanie
sprosta 120-150 połączeń ciągłego ruchu w obie strony?
I tak, tylko TCP mi potrzebne.

A jeżeli mam server to ile mogę do niego klientów podłączyć? Zależy od servera. Dawno już takich 'genialnych' pytań nie widziałem. Bah, tutaj zależy jaki rozmiar i jak często pakiety są odbierane wysyłane. No ale przecież ilość otwartych socketów to podstawa (netstat -a to pewnie podstawowe spowolnienie komputera). No ale tak to jest jak newbie bierze się za coś o czym zielonego pojęcia nie ma. Sophail to to jest jeszcze w fazie projektowania.

a są jeszcze jakieś inne sockety? Uważasz, że np. INDY ma w środku coś innego niż "standardowy" socket?

No właśnie on tak uważa co już wcześniej zauważyłem. Brak podstawowego zrozumienia działania tego magicznego pudełka nazywanego internetem.

Tak właściwie to o czym rozmowa jest teraz? O tym że pytacz nie rozumie podstawowych zagadnień internetowych w stylu pakiet, socket itd.? Wydaje mi się że rozmowa jest bezsensowna bo pytacz nic nie wnosi do tematu, tylko wiecznie zadaje głupie pytania bo nie jest w stanie zrozumieć poprawnych odpowiedzi udzielonych przez nas.