Czesc.

Mam taka zagwozdke teoretyczna. Zalozmy, ze chce napisac aplikacje,
ktora bedzie robila COS. Dla uproszczenia wywodu zalozmy, ze bedzie to
jakas minigra. Calosc "gry" musi odbywac sie na maszynie lokalnej,
wlacznie z liczeniem "punktow".

W dowolnym momencie aplikacja ma miec mozliwosc aktualizacji ogolnej
ilosci punktow zdobytych przez danego "gracza" (uzytkownika) przez
wyslanie informacji o nowych punktach do serwera. Najlepiej przez
wywolanie zdalnego skryptu PHP, ktory by te baze aktualizowal.

No i teraz pytanie - jak zabezpieczyc sie przed nieuczciwymi graczami,
ktorzy chcieliby sobie podmienic wysylana do serwera liczbe punktow?

Zakladam, ze gracze nie beda dekompilowali aplikacji, bo jesli beda, to
chyba nic nie pomoze :) Ale moga miec chyba dosyc latwy podglad tego, co
aplikacja odbiera i wysyla (WireShark i wszystko jasne). Wiec nie moze
to byc po prostu proste
GET http://mojserwer/skrypt.php?uzytkownik=XYZ&dodaj_pun
kty=1234

Czy przychodzi Wam do glowy jakiekolwiek sensowne rozwiazanie?

Myslalem o tym, ze w momencie uruchomienia aplikacja moglaby sie laczyc
z serwerem i odbierac jakis unikatowy ID, ktory pozniej by przetwarzala
(zakladamy brak dekompilacji) np. algorytmem kodujacym wynik, gdzie
kluczem kodowania bylby ten ID... ale to chyba troche za bardzo zamotane.

Oczywiscie przesylanie punktow przez polaczenie z baza (osobne konto dla
dodawania punktow, aby baza byla bezpieczna) jest tak samo narazone na
ingerencje, wiec pozwole sobie pozostac chwilowo przy opcji PHP, chyba
ze macie argumenty :)

Podpowiem, ze na razie mecze C# pod Windowsem i poczatkowo to bedzie
platforma wyjsciowa.


Pozdrawiam.
--
[= WRonX =] [= W...@-...NET =] [= http://WRonX.NET =]
[= GCS/CC d->++ s+:- a- C++++$ U P>++ L+ !E W+++$ N++(+++) =]
[= !o-- K-? w++$ !O !M- !V-- PS+ PE !Y !PGP !t !5 X++ R++ =]
[= tv+ b+++ DI++ D+ G+ e+++ h--->---- r+++ y? =]

do góry

WRonX pisze:
> Czesc.

Cześć.

<ciach>

> Czy przychodzi Wam do glowy jakiekolwiek sensowne rozwiazanie?

<ciach>

Szyfrowanie.

Adam Kłobukowski

do góry

On 11 Lut, 14:44, WRonX <w...@-...wronx.net> wrote:
[..]
> No i teraz pytanie - jak zabezpieczyc sie przed nieuczciwymi graczami,
> ktorzy chcieliby sobie podmienic wysylana do serwera liczbe punktow?
>
> Zakladam, ze gracze nie beda dekompilowali aplikacji, bo jesli beda, to
> chyba nic nie pomoze :) Ale moga miec chyba dosyc latwy podglad tego, co
> aplikacja odbiera i wysyla (WireShark i wszystko jasne). Wiec nie moze
> to byc po prostu proste
>    GEThttp://mojserwer/skrypt.php?uzytkownik=XYZ&dodaj
_punkty=1234
>
> Czy przychodzi Wam do glowy jakiekolwiek sensowne rozwiazanie?
>

Propozycja:

Serwer ma dobry generator liczb losowych, źródło entropii i tak dalej.
Generuje co jakiś czas (niezbyt długi!) nową parę kluczy (prywatny i
publiczny) do jakiegoś algorytmu asymetrycznego szyfrowania. Każdy
klient ma swój klucz, który odgrywa rolę ID. Serwer ogłasza klucz
publiczny. Klienci muszą mieć aktualny czas (zsynchronizowany mniej
więcej z serwerem). Każdy klient bierze swoją wiadomość, dokleja do
niej czas oraz swoje ID i szyfruje całość za pomocą publicznego klucza
serwera. Wysyła wiadomość zaszyfrowaną. Serwer deszyfruje wiadomość za
pomocą swojego prywatnego klucza i sprawdza czas. Jeśli czas bardzo
odbiega od aktualnego - uznaje to za formę ataku i ignoruje wiadomość.
Jeżeli czas jest OK, ale ID klienta się nie zgadza - to również jest
atak. Jeśli serwer odbiera za dużo ataków - zaczyna ignorować
wszystko. W żaden sposób nie odpowiada na żadną wiadomość, która nie
przeszła weryfikacji.

Inny wariant - klient generuje tylko "odcisk" wiadomości z czasem i z
ID. Do każdej wiadomości dołącza taki zaszyfrowany "odcisk". Wtedy
każdy może wiadomość przeczytać, ale nikt nie może jej sfałszować (to
jest tylko autentykacja).

Pozdrowienia,
Paweł Biernacki

do góry

On 2010-02-11, WRonX <w...@-...wronx.net> wrote:
> Mam taka zagwozdke teoretyczna. Zalozmy, ze chce napisac aplikacje,
> ktora bedzie robila COS. Dla uproszczenia wywodu zalozmy, ze bedzie to
> jakas minigra. Calosc "gry" musi odbywac sie na maszynie lokalnej,
> wlacznie z liczeniem "punktow".
>
> W dowolnym momencie aplikacja ma miec mozliwosc aktualizacji ogolnej
> ilosci punktow zdobytych przez danego "gracza" (uzytkownika) przez
> wyslanie informacji o nowych punktach do serwera. Najlepiej przez
> wywolanie zdalnego skryptu PHP, ktory by te baze aktualizowal.
>
> No i teraz pytanie - jak zabezpieczyc sie przed nieuczciwymi graczami,
> ktorzy chcieliby sobie podmienic wysylana do serwera liczbe punktow?

Przeprowadźmy eksperyment myślowy.
Załóżmy, że kod źródłowy gry jest otwarty i każdy z graczy go ma.
Automatycznie każdy z graczy zna (może poznać) protokół komunikacji
z serwerem. Skoro zna ten protokół, to może napisać własny program do
komunikacji, który zgłasza wyniki wzięte z sufitu. Jeśli ten program
zachowuje się zgodnie z protokołem, serwer nie jest w stanie odróżnić go
od twojej aplikacji-gry.

Widać co się da dalej zrobić z architekturą "słowo honoru, ja nie
oszukuję"?

--
Secunia non olet.
Stanislaw Klekot

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "WRonX"
>Mam taka zagwozdke teoretyczna. Zalozmy, ze chce napisac aplikacje,
>ktora bedzie robila COS. Dla uproszczenia wywodu zalozmy, ze bedzie to
>jakas minigra. Calosc "gry" musi odbywac sie na maszynie lokalnej,
>wlacznie z liczeniem "punktow".
>
>W dowolnym momencie aplikacja ma miec mozliwosc aktualizacji ogolnej
>ilosci punktow zdobytych przez danego "gracza" (uzytkownika) przez
>wyslanie informacji o nowych punktach do serwera. Najlepiej przez
>wywolanie zdalnego skryptu PHP, ktory by te baze aktualizowal.
>
>No i teraz pytanie - jak zabezpieczyc sie przed nieuczciwymi graczami,
>ktorzy chcieliby sobie podmienic wysylana do serwera liczbe punktow?

Zauważ, że masz dużo więcej rzeczy do zabezpieczenia się przed. (grrr,
jakaś angielska składnia mi wyszła).
Na przykład gmeranie w pamięci procesu po stronie klienta.

--
Kruk@ -\ |
}-> epsilon.eu.org |
http:// -/ |
|

do góry

> Mam taka zagwozdke teoretyczna. Zalozmy, ze chce napisac aplikacje,
> ktora bedzie robila COS. Dla uproszczenia wywodu zalozmy, ze bedzie to
> jakas minigra. Calosc "gry" musi odbywac sie na maszynie lokalnej,
> wlacznie z liczeniem "punktow".
>
> W dowolnym momencie aplikacja ma miec mozliwosc aktualizacji ogolnej
> ilosci punktow zdobytych przez danego "gracza" (uzytkownika) przez
> wyslanie informacji o nowych punktach do serwera. Najlepiej przez
> wywolanie zdalnego skryptu PHP, ktory by te baze aktualizowal.
>
> No i teraz pytanie - jak zabezpieczyc sie przed nieuczciwymi graczami,
> ktorzy chcieliby sobie podmienic wysylana do serwera liczbe punktow?

nie wysyłać samych punktów, ale także "log" - zapis działań/event'ów
powodujących ich przyrost wraz ze znacznikami czasowymi

statystycznie wyłapiesz zbyt duże/nieprawdopodobne fizycznie
zagęszczenie zdarzeń nawet przy inteligentnej próbie oszustwa

do góry

"lolo" rozwiązał/a/o:
>> Mam taka zagwozdke teoretyczna. Zalozmy, ze chce napisac aplikacje,
>> ktora bedzie robila COS. Dla uproszczenia wywodu zalozmy, ze bedzie to
>> jakas minigra. Calosc "gry" musi odbywac sie na maszynie lokalnej,
>> wlacznie z liczeniem "punktow".
>>
>> W dowolnym momencie aplikacja ma miec mozliwosc aktualizacji ogolnej
>> ilosci punktow zdobytych przez danego "gracza" (uzytkownika) przez
>> wyslanie informacji o nowych punktach do serwera. Najlepiej przez
>> wywolanie zdalnego skryptu PHP, ktory by te baze aktualizowal.
>>
>> No i teraz pytanie - jak zabezpieczyc sie przed nieuczciwymi graczami,
>> ktorzy chcieliby sobie podmienic wysylana do serwera liczbe punktow?
>
> nie wysyłać samych punktów, ale także "log" - zapis działań/event'ów
> powodujących ich przyrost wraz ze znacznikami czasowymi
>
> statystycznie wyłapiesz zbyt duże/nieprawdopodobne fizycznie
> zagęszczenie zdarzeń nawet przy inteligentnej próbie oszustwa
wtedy oszust po prostu wykorzysta maksima pozwalane przez serwer,
których użytkownich nie będzie w stanie osiągnąć, ponieważ osiągniecia
użytkownika podpadają pod znormalizowaną przestrzeń zdarzeń, a osiągnię-
cia oszusta- pod liniową rozpraszaną przestrzeń zdarzeń, a oprogramowa-
nie z samej definicji nie może znać wszystkich dozwolonych losowych
przestrzeni zdarzeń, ponieważ losowość w informatyce jest nieskończonoś-
cią.
--
/ qo |) :@=N%_g=v=a=g_eD_e=c()=d=8! =%!gN@8'Re. w8in/ad
\ _x/ , ;h-%-a'hA'H4,X0'Xo~xo~xO,R`-%EXp01ITed: *-7/+eh
/ | ng `-%__%--'__%--'__%--~__%--^%B`/$qV3r[o; &GooMee
L_._o_O_*_^_"_'_`_ -> http://thereis.notlong.com <- `L"EnOF"

do góry

"WRonX" rozwiązał/a/o:
> Mam taka zagwozdke teoretyczna. Zalozmy, ze chce napisac aplikacje,
> ktora bedzie robila COS. Dla uproszczenia wywodu zalozmy, ze bedzie to
> jakas minigra. Calosc "gry" musi odbywac sie na maszynie lokalnej,
> wlacznie z liczeniem "punktow".
>
> W dowolnym momencie aplikacja ma miec mozliwosc aktualizacji ogolnej
> ilosci punktow zdobytych przez danego "gracza" (uzytkownika) przez
> wyslanie informacji o nowych punktach do serwera. Najlepiej przez
> wywolanie zdalnego skryptu PHP, ktory by te baze aktualizowal.
>
> No i teraz pytanie - jak zabezpieczyc sie przed nieuczciwymi graczami,
> ktorzy chcieliby sobie podmienic wysylana do serwera liczbe punktow?
>
> Zakladam, ze gracze nie beda dekompilowali aplikacji, bo jesli beda, to
> chyba nic nie pomoze :) Ale moga miec chyba dosyc latwy podglad tego, co
> aplikacja odbiera i wysyla (WireShark i wszystko jasne). Wiec nie moze
> to byc po prostu proste
> GET http://mojserwer/skrypt.php?uzytkownik=XYZ&dodaj_pun
kty=1234
>
> Czy przychodzi Wam do glowy jakiekolwiek sensowne rozwiazanie?
>
> Myslalem o tym, ze w momencie uruchomienia aplikacja moglaby sie laczyc
> z serwerem i odbierac jakis unikatowy ID, ktory pozniej by przetwarzala
> (zakladamy brak dekompilacji) np. algorytmem kodujacym wynik, gdzie
> kluczem kodowania bylby ten ID... ale to chyba troche za bardzo
> zamotane.
>
> Oczywiscie przesylanie punktow przez polaczenie z baza (osobne konto dla
> dodawania punktow, aby baza byla bezpieczna) jest tak samo narazone na
> ingerencje, wiec pozwole sobie pozostac chwilowo przy opcji PHP, chyba
> ze macie argumenty :)
kierunek próby zabezpieczenia zależy od przyjętej strategii postępowa-
nia:
?czy ma być tylko zabezpieczenie prawdziwości danych bez ich ukrywania
?czy ma być tylko ukrywanie danych z ufaniem ich prawdziwości.
a które z powyższych zależy również od postępowania w przypadku wykrycia
oszustwa; na pewno znajdzie się ktoś kto wykorzysta wszystkie dostępne
możliwości oszukania serwera, jeśli będzie tego potrzebować.
--
qo |) CPL<=dataDPL CPL==/>=codeDPL:conform'/nc';max=CPL! AV0ID bHp
_x/ , CPL<=TSS,gateDPL CPL>=/==dest_DPL:/(jmp&nc') ,RPL!- #GP -o0o
| ng __ -- __ -- __ -- __ -- __ -- __ -- __ -- __ -x86-, EV3RY o0o
,__ -- __ -- Current/Requested/DescriptorPrivilegeLevel C/R/DPL , d4y m:#=

do góry

WRonX pisze:
> Czesc.
>
> Mam taka zagwozdke teoretyczna. Zalozmy, ze chce napisac aplikacje,
> ktora bedzie robila COS. Dla uproszczenia wywodu zalozmy, ze bedzie to
> jakas minigra. Calosc "gry" musi odbywac sie na maszynie lokalnej,
> wlacznie z liczeniem "punktow".
>
> W dowolnym momencie aplikacja ma miec mozliwosc aktualizacji ogolnej
> ilosci punktow zdobytych przez danego "gracza" (uzytkownika) przez
> wyslanie informacji o nowych punktach do serwera. Najlepiej przez
> wywolanie zdalnego skryptu PHP, ktory by te baze aktualizowal.
>
[...]
>
> Czy przychodzi Wam do glowy jakiekolwiek sensowne rozwiazanie?
>
Przesyłanie informacji o przebiegu rozgrywki a na podstawie tego serwer
będzie liczył punkty. Tylko:
a) nie zawsze się da
b) jak ktoś będzie uparty to napisze bota

--
Pozdrawiam
Michoo

do góry

>>
>> statystycznie wyłapiesz zbyt duże/nieprawdopodobne fizycznie
>> zagęszczenie zdarzeń nawet przy inteligentnej próbie oszustwa
> wtedy oszust po prostu wykorzysta maksima pozwalane przez serwer,
> których użytkownich nie będzie w stanie osiągnąć, ponieważ osiągniecia
> użytkownika podpadają pod znormalizowaną przestrzeń zdarzeń, a osiągnię-
> cia oszusta- pod liniową rozpraszaną przestrzeń zdarzeń, a oprogramowa-
> nie z samej definicji nie może znać wszystkich dozwolonych losowych
> przestrzeni zdarzeń, ponieważ losowość w informatyce jest nieskończonoś-
> cią.

maksima musiałby znać lub wytestować np. kosztem tworzenia kolejnych
kont/ich autoryzacji/banowania itd.

kto mówi o super automatyce? dane mogą podlegać weryfikacji
niekoniecznie w momencie aktualizacji - można je cyklicznie obrabiać
statystycznie, wyłapywać anomalie, sprawdzać, uszczegóławiać kryteria
odrzuceń nie ujawniając metodologii kontroli (przez wstawienie w sztywny
automat) - google nie mówi dlaczego nisko indeksuje/banuje ani nie
podaje pozycji zaraz po dodaniu adresu

do góry