Autor Wątek: Ochrona gry przed Cheat Engine  (Przeczytany 5781 razy)

Offline Mr.Protek

  • Użytkownik
    • Pogromcy Potworów

# Luty 13, 2010, 15:53:38
Przypuśćmy że gra oferuję możliwość wspólnej gry przez sieć, wydaje mnie się że gra z oszustami nigdy nie jest miła :D

Po lanie to akurat mały problem, zawsze można przejść się pokój/piętro i walnąć łopatą po głowie. :P
Tyle że można grać też przez neta, nie tylko po lanie :) Latanie z łopatą do kogoś nie jest wskazane ;D Hehe, przypomniało mnie się jak mój kolega rozwoził pizze i raz kazali mu jechać w nocy w taką "niebezpieczną" część miasta, zobaczył jakiś gości pod blokiem to wyszedł z teleskopówą, i tak poszedł z tą pizza i z tym do klienta ;D Otworzylibyście drzwi takiemu uzbrojonemu pizza-menowi? ;D Aż strach nie dać napiwku :D

Cytuj
No właśnie pomyślałem o czymś podobnym

No to weź jeszcze pod uwagę C, bo w przeciwnym razie po prostu gracz zamrozi cały blok związany z np. atrybutami i dupa. Przynajmniej ja tak robiłem zawsze grając w SNESowe gierki :D
Wezmę to też pod uwagę :)

Wiadomo że wszystkiego nie da się zabezpieczyć, chodzi mi o coś co pomoże na najprostsze sztuczki i co będzie proste w implementacji :)
« Ostatnia zmiana: Luty 13, 2010, 15:55:17 wysłana przez Mr.Protek »

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Dab

  • Redaktor
    • blog

# Luty 13, 2010, 15:56:34
Kurczę, firefox zjadł mi połowę posta.

Pisałem jeszcze że możesz robić testy tego typu:
int kasa0 = gracz->kasa;
gracz->ZabierzKase(przedmiot->cena);
if (gracz->kasa + przedmiot->cena != kasa0) wtf();

przy czym jest to sporo zachodu i trzeba pilnować kompilator żeby tego nie "zoptymalizował". :) Ale przy okazji masz "ónit"-testy za friko ;)


Offline Byamarro

  • Użytkownik
    • PSGM

# Luty 13, 2010, 15:59:40
Jeśli dane gracza są zapisywane na jego kompie to masz już przechlapane i raczej tego nie zabezpieczysz. Jeśli nie znajdzie się jakiś kozak który chodzi po grach i je łamie. To gracze się zaczną wymieniać plikami jak save'ami...

Offline Dab

  • Redaktor
    • blog

# Luty 13, 2010, 16:03:12
Bez przesady, keep it real, ile % graczy małej niszowej gry może być uberprohakerami? Ilu % będzie się chciało grzebać?

Cytuj
raz kazali mu jechać w nocy w taką "niebezpieczną" część miasta, zobaczył jakiś gości pod blokiem to wyszedł z teleskopówą, i tak poszedł z tą pizza i z tym do klienta
Dwie hawajskie i przestań pan hakować golda, do jasnej ciasnej! :D

Offline Byamarro

  • Użytkownik
    • PSGM

# Luty 13, 2010, 16:06:10
Cytuj
Bez przesady, keep it real, ile % graczy małej niszowej gry może być uberprohakerami? Ilu % będzie się chciało grzebać?
Pozostaje jeszcze druga opcja.
A skoro gra ma mało graczy to po co jej zabezpieczenia?

Offline DoS

  • Użytkownik
    • Projekt ORC

# Luty 13, 2010, 16:06:53
Bez przesady, keep it real, ile % graczy małej niszowej gry może być uberprohakerami? Ilu % będzie się chciało grzebać?
Jeden farming, hunted,  czy jak to się będzie w Twojej grze nazywać, + niewyżyte dziecko neo = niepohamowana żądza zemsty

Offline Dab

  • Redaktor
    • blog

# Luty 13, 2010, 16:10:12
Jeden farming, hunted,  czy jak to się będzie w Twojej grze nazywać, + niewyżyte dziecko neo = niepohamowana żądza zemsty
Ale nawet przy najprostszych zabezpieczeniach takie dziecko neo opętane żądzą farmingu sobie nie poradzi. Do tego potrzeba minimum inteligencji. :)

Offline Byamarro

  • Użytkownik
    • PSGM

# Luty 13, 2010, 16:11:43
Musi być jakiś prekursor. Dzieci neo choć nie wiem z jak wielką żądzą zemsty, pewnie nie dadzą rady zhackować gry patrząc na hacki do innych gier... A już na pewno przez CE.
« Ostatnia zmiana: Luty 13, 2010, 16:14:35 wysłana przez Byamarro »

Offline BrutalComputer

  • Użytkownik

# Luty 13, 2010, 17:17:11
Jeżeli chodzi o grę lokalną, to nic na to nie poradzisz. Zawsze powstawały, powstają i będą powstawać hacki.
Jeżeli chodzi o grę w sieci, to dobry protokół nie pozwoli na modyfikowanie stanu gry. Jedyną możliwością są wtedy programy typu maphack lub aimbot ( lub coś podobnego - żadnych "dodaje ci 1000 złota" itp. ).
Załóżmy grę typu StarCraft - gracz dodaje sobie 1000 minerałów i gra się desynchronizuje i każdy gracz gra w swoją grę.
Załóżmy grę typu QuakeLive - gracz dodaje sobie 200 hp i dziwi się, czemu mimo 200 hp co chwila ginie. Autorytatywny serwer ma gdzieś, co myśli klient o swoim HP. W dodatku można nie przesyłać przez sieć pozycji niewidocznych graczy, co jest dodatkowym zabezpieczeniem.
Teraz anty-przykład:
Załóżmy grę typu Sauerbraten - gracz dodaje sobie 10000dmg do maszynówki i 10000ammo. Oczywiście, ze względu na nieautorytatywny serwer inni gracze po 2min banują tego "czitera". Ale dzięki temu w tą grę można grać płynnie z lagiem 500ms ;-P

Podsumowując: dobry protokół sieciowy to podstawa.

Offline Byamarro

  • Użytkownik
    • PSGM

# Luty 13, 2010, 20:24:01
Jak już zabezpieczysz przed CE. To dużym wyzwaniem będzie WPE. Które operuje na pakietach. A z tym już ciężej.

Offline Troll

  • Użytkownik
    • Oficjalna strona gry Gizarma

# Luty 13, 2010, 20:41:20
Jak już zabezpieczysz przed CE. To dużym wyzwaniem będzie WPE. Które operuje na pakietach. A z tym już ciężej.

Dobry protokół sieciowy będzie na to odporny. Wystarczy, że komunikaty klienta do serwera będą typu "gracz A atakuje gracza B", a nie "gracz B ginie".

Offline Byamarro

  • Użytkownik
    • PSGM

# Luty 13, 2010, 21:02:06
A jeśli wyśle zaspamuje serwer pakietami o treści "gracz A atakuje gracza B"?

Offline Rolek

  • Użytkownik

# Luty 13, 2010, 21:09:40
A jeśli wyśle zaspamuje serwer pakietami o treści "gracz A atakuje gracza B"?
To gracz A dostanie bana za speedhacka.

Offline Byamarro

  • Użytkownik
    • PSGM

# Luty 13, 2010, 21:15:18
Skąd wiesz że Mr. Protek takowe coś stworzył :)?

Offline Troll

  • Użytkownik
    • Oficjalna strona gry Gizarma

# Luty 13, 2010, 21:25:24
A jeśli wyśle zaspamuje serwer pakietami o treści "gracz A atakuje gracza B"?

Inteligentnie napisany serwer sobie z tym poradzi. Wszystko zależy zresztą od zasad gry. Jeśli grą byłby np. sieciowy FPS i gracz A miał by shotguna (szybkostrzelnośc np. 1 strzał/s) i serwer dostał by od klienta 1000 komunikatów/s o ataku na gracza B, to powinien zrealizowac tylko jeden strzał na sekunde niezależnie od komunikatów klienta. I tak właśnie było by to widziane przez pozostałych graczy

Dobrze napisany serwer nie ufa klientowi i sprawdza, czy wysłane dane są poprawne.