Jak mogę zapobiec fałszywym raportom wyników do globalnych tabel najlepszych wyników?

Gry przeglądarkowe i mobilne zazwyczaj mają globalne tabele najlepszych wyników. Tabele często zawierają również wyniki w liczbie 2 147 483 647 osób - w których ludzie zorientowali się, jakie wywołanie usługi internetowej zgłosiło wyniki i wykorzystali je do zarejestrowania fikcyjnego wyniku.

W przypadku prostych gier logicznych możemy się przed tym bronić, dołączając zapis każdego ruchu wykonanego przez gracza (i wszystkich losowych nasion użytych do wygenerowania poziomu) z wezwaniem do raportowania wyników. Całą grę można następnie odtworzyć i zweryfikować na serwerze.

Jednak szybko staje się to niemożliwe dla czegoś większego niż Pac-man.

Jak inaczej można zapobiec tego rodzaju oszustwom?

Wewnętrzny system, którego użyliśmy dla Moblox (później zastąpiony przez OpenFeint) działał w następujący sposób:

• Wyślij wiadomość JSON przez zwykły HTTP (nie HTTPS). Dołącz skrót MD5 wszystkich pól plus magiczny ciąg.
• Na serwerze sprawdź integralność wiadomości za pomocą tej samej operacji.

Aby złamać system, musisz znaleźć ten magiczny ciąg. Jest to możliwe przy inżynierii odwrotnej, ale bolesne.

OpenFeint, ScoreLoop i CocosLive używają tej samej sztuczki, ale z HTTPS. Bardzo łatwe do wdrożenia.

Chociaż masz rację, że nie zawsze jest możliwe wysyłanie całych powtórek na serwer w przypadku złożonych gier, podobny system może być używany, gdy serwer okresowo (i losowo) pyta klienta o pewną część swojego stanu, podczas gdy gra jest uruchomiona.

Na przykład w FPS co minutę możesz zapytać „Ile zabijasz?”, „Gdzie są wszyscy wrogowie?” Itd. Jeśli klient nie wróci z rozsądną odpowiedzią na wyzwanie w w rozsądnym czasie oszukują.

Oczywiście działa to tylko wtedy, gdy gra jest online podczas całej sesji gry. Ponieważ celem tutaj jest możliwość przesłania do internetowej tabeli liderów, myślę, że to rozsądne - nie wyrzucaj gracza z gry, jeśli odpowiedzą źle, po prostu nie pozwól mu na liście wyników.

Zachęcam jednak do ponownego rozważenia przesłania powtórek. Wszystko, czego naprawdę potrzebujesz, to początkowe losowe źródło i znacznik czasu. Powinno to być naprawdę najwyżej kilkaset KB. Wiele gier zręcznościowych już to robi, aby zapisać powtórki do celów przeglądu gracza; sprawdzenie poprawności serwera może nie być trywialne, ale zapobiega wszelkim oszustwom, z wyjątkiem botowania.

Możesz ograniczyć najbardziej rażące nadużycia, monitorując najwyższe wyniki w tabeli najlepszych wyników. W zależności od gry możesz mieć „doskonały wynik”, powyżej którego każdy wynik musi być fałszywy. Jeśli nie, możesz obliczyć najniższy „wynik niemożliwy”; czy gracz może strzelić 10 strzałów na sekundę, gra trwa 1 minutę, a każdy zabity wróg jest wart 100 punktów? Zatem każdy wynik powyżej 60 000 musi być fałszywy.

Możesz także pomóc w złagodzeniu problemu, przesyłając niektóre metadane; nie pełna historia gry, jak opisujesz, ale tylko składniki, które składają się na wynik. Powiedz: zdobądź 60000, 500 zabitych wrogów i złapany jeden bonusowy przedmiot. Następnie możesz wykonać proste kontrole. Jest to „bezpieczeństwo przez zaciemnienie” i dlatego nie jest wcale bezpieczne, ale pomaga wyeliminować najbardziej naiwnych z atakujących.

Ostatecznie możesz wykluczyć niemożliwie wysokie wyniki, ponieważ reszta jest (z definicji) mało prawdopodobna, a zatem może być legalnym (i niesamowitym) graczem.

W przeciwnym razie musisz polegać na technikach zaciemniania (takich jak szyfrowanie i wysyłanie innych statystyk poza zwykłym wynikiem).

Możesz także okresowo wysyłać wyniki w trakcie gry, co zwiększyłoby poziom skomplikowania oszustwa - tzn. Serwer może zdecydować, czy gra się wystarczająco długo, aby zagwarantować określony wynik, a także zapewnić wystarczającą liczbę raportów pośrednich zostały odebrane podczas gry (po prostu nie rób tego w 100%, bo pociąg jadący do tunelu w drodze do domu spowoduje, że wyrzucę telefon przez okno).

Ostatecznie jednak ktoś znajdzie sposób, aby go złamać, więc nie zabijaj się, próbując go powstrzymać.

Dodałem szybką / brudną tabelę najlepszych wyników do mojego projektu jakiś czas temu i nie będąc w ogóle zaznajomionym z bezpieczeństwem internetowym itp. Okazało się, że jest to wada. Zaskakujące jest to, że z prawie 1 200 000 zarejestrowanych wyników, miałem tylko 5 lub 6 razy serię rażąco niepoprawnych wyników, które osiągnęły szczyt tabeli. Większość wyników wyglądała nawet bardziej na usterkę w grze niż na prawdziwe „hakowanie”.

Myślę więc, że ważną kwestią jest: upewnij się, że system punktacji twojej gry jest szczelny , lub przynajmniej wykonaj kilka naprawdę dobrych testów wykonalności; teraz ta gra, o której mówię, była postem Ludum Dare 48 godzin, więc nie była to najbardziej stabilna rzecz w okolicy ... ale ogólnie myślę, że bardziej prawdopodobne jest, że przypadkowy gracz odkryje / wykorzysta usterkę w grze niż gdy ktoś bezpośrednio „zhakuje” tabelę wyników.

To powiedziawszy, pracuję teraz nad przepisaniem tego projektu i idę na całość z zaciemnianiem. Nie będę wchodził w zbyt wiele szczegółów, ale w zasadzie wszystkie wyniki przesyłają kluczową wartość opartą na zbiorze losowych wartości i wartości mieszania i magicznego ciągu znaków, a następnie każdy wynik, który przejdzie ten test i jest wystarczająco wysoki, aby rzeczywista wartość „ Tabela liderów Top X ”musi przejść kolejną rundę sprawdzania poprawności (tym razem z wygasającą wartością klucza wygenerowaną po stronie serwera i dokładniejszymi kontrolami wykonalności).

Radziłbym również użyć jakiegoś narzędzia do śledzenia pakietów, aby sprawdzić, jakie rzeczy są widoczne (pierwotnie robiłem znacznie prostszą weryfikację, co oznaczało, że ktoś mógł użyć narzędzia do śledzenia pakietów, aby znaleźć i zduplikować żądanie HTTP przesłanego wyniku, bez wiedzy magiczny ciąg znaków lub cokolwiek innego (oznaczało to, że najpierw potrzebowałeś wiarygodnego wyniku, ale możesz wysłać duplikaty tego wyniku, ile chcesz ...)). Użyłem Wireshark do przetestowania tego.

Huh, okazało się to trochę długie, ale mam nadzieję, że to pomaga ...

Nie jestem ekspertem w tej dziedzinie, ale gdybym był tobą, postaram się zaszyfrować partyturę kluczem osadzonym w twoim kodzie. Ci ludzie będą musieli zastosować inżynierię wsteczną w kodzie zamiast zwykłego tekstu używanego w usługach internetowych.

Speedruns rejestrują w zasadzie każde naciśnięcie klawisza i rejestrują grę CAŁĄ. Tak, możesz nagrać całą grę, nie jest to niewykonalne. Każdy inny sposób na zrobienie tego jest możliwy do złamania za pomocą inżynierii odwrotnej (nie mogę tego wystarczająco podkreślić: nie dodajesz bezpieczeństwa, dodajesz niejasności).

Mimo to, nawet jeśli zrobisz to w ten sposób, mogą faktycznie przesłać speedrun. Nie możesz nic zrobić, aby temu zapobiec.

W tym momencie pojawia się pytanie, czy wysoki wynik to po prostu gracz, który znalazł exploita (na przykład, jeśli niektóre rzeczy w grze dają karę punktową, a błąd powoduje „zawijanie” wyniku ujemnego aby stać się bardzo pozytywnym ... lub po prostu graczem, który znajdzie pewne warunki gry, takie jak bezpieczne miejsce na planszy, w którym może po prostu siedzieć i nie martwić się o przegraną w nieskończoność).

Aby odróżnić hack od exploita gry, dobrym pomysłem byłoby przesłanie przynajmniej niektórych danych gry. Pomoże ci to naprawić exploity.

W przypadku niektórych gier (szczególnie turowych) możesz grać w tę grę przez serwer, gdzie cała logika gry istnieje po stronie serwera, a klient jest tylko interfejsem. To nie tylko utrudnia hakowanie wyników, ale umożliwia także trywialne rejestrowanie wszystkich działań gracza na serwerze, a tym samym odtwarzanie dowolnej gry w dowolnym momencie. Zdaję sobie sprawę, że dla czegoś takiego jak strzelanina akcji może to być niepraktyczne.

Utwórz wszystkie losowości z jednego materiału źródłowego i zapisz dane wejściowe dla każdej ramki. Ilekroć masz najwyższy wynik (powiedzmy 50 najlepszych), wyślij seed i pełne dane wejściowe do serwera. Zagraj w grę na serwerze i zaktualizuj tabelę wyników, jeśli uzyskasz wysoki wynik.

Jeśli uważasz to za niewykonalne w przypadku bardziej wyrafinowanych gier ze względu na rozmiar żądania, spójrz na ten przykład.

Załóżmy, że gra ma 8 przycisków wejściowych (1 pad i 4 przyciski) i działa z prędkością 60 klatek na sekundę. Godzinę wejściową do gry można przesyłać z 3,6 KB bez kompresji. Sesja prawdopodobnie potrwa mniej niż godzinę, a kompresja powinna ją znacznie zmniejszyć, ponieważ wkład człowieka jest bardzo redundantny.

Wyzwaniem jest uczynienie gry deterministyczną, odtwarzalną z zarejestrowanych danych wejściowych i wykonywalną na serwerze.

Nigdy wcześniej tego nie wdrażałem, ale ...

Wysyłaj wyniki stopniowo ze znacznikami czasu. To daje dziennik, aby zobaczyć, jak często poprawia się wynik, a także sposób na śledzenie „pędu” wyniku.

Następnie ustalisz kamienie milowe / kryteria swoich wyników.

Na przykład: Wynik większy niż 20 000 nie może dotrzeć w ciągu pierwszych 20 sekund gry. Wynik większy niż 250 000 nie może dotrzeć bez wpisu większego niż 200 000.

Nie jest to dokładnie to samo, co wysyłanie stanu gry, ale blisko niego.

Dodatkowa korzyść: Pomyśl o wszystkich przydatnych statystykach gry, które możesz z tego uzyskać. Ktoś prawdopodobnie zapłaciłby za to dobre pieniądze.