Jaki jest najlepszy sposób, aby zatrzymać ludzi hacking tabeli najlepszych wyników PHP w grze Flash

Możesz zadawać złe pytanie. Wydaje ci się, że skupiasz się na metodach, których ludzie używają do gry na szczycie listy najlepszych wyników, ale blokowanie określonych metod idzie tylko tak daleko. Nie mam doświadczenia z TamperData, więc nie mogę z tym rozmawiać.

Pytanie, które powinieneś zadać, brzmi: "Jak mogę sprawdzić, czy przesłane wyniki są ważne i autentyczne?"Specyficzny sposób na to zależy od gry. Dla bardzo prostych gier logicznych, można wysłać wynik wraz z konkretnym stan początkowy i sekwencja ruchów, które doprowadziły do stanu końcowego, a następnie ponownie uruchomić grę po stronie serwera, używając tych samych ruchów. Potwierdź, że podany wynik jest taki sam jak obliczony wynik i zaakceptuj go tylko wtedy, gdy pasuje.

Łatwym sposobem na to byłoby dostarczenie kryptograficznego hasha wartości rankingu wraz z jego wynikiem. Na przykład podczas publikowania wyników przez HTTP GET: http://example.com/highscores.php?score=500&checksum=0a16df3dc0301a36a34f9065c3ff8095

Podczas obliczania tej sumy kontrolnej należy użyć współdzielonej tajemnicy; ta tajemnica nigdy nie powinna być przesyłana przez sieć, ale powinna być zakodowana zarówno w backendzie PHP, jak i w nakładce flash. Na powyższa suma kontrolna została utworzona przez dodanie ciągu " secret " do wyniku "500", i przepuszczam przez md5sum.

Chociaż ten system uniemożliwi użytkownikowi publikowanie arbitralnych wyników, nie zapobiega "atakowi powtórek", w którym użytkownik repostuje wcześniej obliczony wynik i kombinację skrótu. W powyższym przykładzie wynik 500 zawsze wytworzy ten sam łańcuch skrótu. Niektóre z tych zagrożeń można złagodzić, dodając więcej informacji (takich jak nazwa użytkownika, timestamp lub adres IP) w ciągu, który ma zostać zahaszowany. Chociaż nie uniemożliwi to powtórnego odtwarzania danych, zapewni, że zestaw danych będzie ważny tylko dla jednego użytkownika w tym samym czasie.

Aby zapobiec wystąpieniu jakichkolwiek ataków replay, konieczne będzie utworzenie pewnego rodzaju systemu odpowiedzi na wyzwania, takiego jak:

1. gra flash ("klient") wykonuje HTTP GET of http://example.com/highscores.php bez parametry. Ta strona zwraca dwie wartości: losowo wygenerowaną wartość salt oraz kryptograficzny hash tej wartości salt połączony ze wspólną tajemnicą. Ta wartość salt powinna być przechowywana w lokalnej bazie danych oczekujących zapytań i powinna mieć skojarzony z nią znacznik czasu, aby mogła "wygasnąć" po około jednej minucie.
2. gra flash łączy wartość salt ze wspólnym sekretem i oblicza hash, aby sprawdzić, czy pasuje do tego dostarczonego przez serwer. To krok jest niezbędny, aby zapobiec manipulowaniu wartościami salt przez użytkowników, ponieważ sprawdza, czy wartość salt została rzeczywiście wygenerowana przez serwer.
3. gra flash łączy wartość salt ze wspólną tajemnicą, wysoką wartością wyniku i innymi istotnymi informacjami (Nick, ip, znacznik czasu) i oblicza hash. Następnie wysyła te informacje z powrotem do zaplecza PHP za pośrednictwem HTTP GET lub POST, wraz z wartością salt, wysokim wynikiem i innymi informacjami.
4. serwer łączy w sobie informacje otrzymane w taki sam sposób, jak na kliencie, i oblicza hash, aby sprawdzić, czy pasuje do tego podanego przez Klienta. Następnie sprawdza również, czy wartość salt jest nadal ważna zgodnie z listą oczekujących zapytań. Jeśli oba te warunki są prawdziwe, zapisuje wysoki wynik do tabeli wyników i zwraca podpisaną wiadomość" sukces " do klienta. Usuwa również wartość salt z listy oczekujących zapytań.

Należy pamiętać, że bezpieczeństwo każda z powyższych technik jest zagrożona, jeśli udostępniony sekret jest kiedykolwiek Dostępny dla użytkownika

Jako alternatywę, niektórych z tych przypadków można uniknąć, zmuszając klienta do komunikacji z serwerem przez HTTPS i zapewniając, że klient jest wstępnie skonfigurowany tak, aby ufał tylko certyfikatom podpisanym przez konkretny urząd certyfikacji, do którego ty sam masz dostęp.

Podoba mi się to, co powiedział tpqf, ale zamiast wyłączać konto w przypadku wykrycia oszustwa, zaimplementuj honeypot, aby za każdym razem, gdy się logują, widzieli swoje zhakowane wyniki i nigdy nie podejrzewali, że zostali oznaczeni jako troll. Google dla "phpBB Mod Troll" i zobaczysz pomysłowe podejście.

W zaakceptowanej odpowiedzi tqbf wspomina, że można po prostu zrobić wyszukiwanie pamięci dla zmiennej wynik ("mój wynik jest 666 więc szukam liczby 666 w pamięci").

Jest na to sposób. Mam tu zajęcia: http://divillysausages.com/blog/safenumber_and_safeint

Zasadniczo masz obiekt, który przechowuje Twój wynik. W setterze mnoży wartość, którą podajesz losowo (+ i -), a w getterze dzielisz zapisaną wartość przez losową multiplikator, aby odzyskać oryginał. To proste, ale pomaga zatrzymać wyszukiwanie pamięci.

Zobacz też filmik od kilku facetów stojących za silnikiem przycisków, którzy opowiadają o różnych sposobach walki z hackingiem: http://zaa.tv/2010/12/the-art-of-hacking-flash-games / . byli inspiracją dla klasy.

Zrobiłem coś w rodzaju obejścia... Miałem dał gdzie wyniki incremented (zawsze masz + 1 wynik). Po pierwsze, zacząłem liczyć od losowej liczby (powiedzmy 14 ) i kiedy wyświetlam wyniki, po prostu pokazał wyniki var minus 14. Tak było, jeśli krakersy szukają np. 20, to nie znajdą (w pamięci będzie 34). Po drugie, ponieważ wiem, jaki powinien być następny punkt... Użyłem biblioteki Adobe crypto, aby utworzyć hash tego, co następny punkt powinien być. Kiedy mam aby zwiększyć wyniki, sprawdzam, czy hash inkrementowanych wyników jest równy hash jest powinien być. Jeśli cracker zmienił punkty w pamięci, hasze nie są równe. Wykonuję weryfikację po stronie serwera i kiedy dostałem różne punkty z gry i z PHP, wiem, że chodziło o oszustwo. Oto fragment mojego kodu (używam klasy Adobe Crypto libraty MD5 i random cryptography salt. callPhp () to Walidacja po stronie serwera)

private function addPoint(event:Event = null):void{
            trace("expectedHash: " + expectedHash + "  || new hash: " + MD5.hash( Number(SCORES + POINT).toString() + expectedHashSalt) );
            if(expectedHash == MD5.hash( Number(SCORES + POINT).toString() + expectedHashSalt)){
                SCORES +=POINT;
                callPhp();
                expectedHash = MD5.hash( Number(SCORES + POINT).toString() + expectedHashSalt);
            } else {
                //trace("cheat engine usage");
            }
        }

Używając tego technika + obfustykacja SWF, udało mi się zatrzymać krakersy. Ponadto, kiedy wysyłam wyniki na serwer, używam własnej małej funkcji szyfrowania / deszyfrowania. Coś takiego (kod po stronie serwera nie jest dołączony, ale możesz zobaczyć algorytm i zapisać go w PHP):

package  {

    import bassta.utils.Hash;

    public class ScoresEncoder {

        private static var ranChars:Array;
        private static var charsTable:Hash;

        public function ScoresEncoder() {

        }

        public static function init():void{

            ranChars = String("qwertyuiopasdfghjklzxcvbnm").split("")

            charsTable = new Hash({
                "0": "x",
                "1": "f",
                "2": "q",
                "3": "z",
                "4": "a",
                "5": "o",
                "6": "n",
                "7": "p",
                "8": "w",
                "9": "y"

            });

        }

        public static function encodeScore(_s:Number):String{

            var _fin:String = "";

            var scores:String = addLeadingZeros(_s);
            for(var i:uint = 0; i< scores.length; i++){
                //trace( scores.charAt(i) + " - > " + charsTable[ scores.charAt(i) ] );
                _fin += charsTable[ scores.charAt(i) ];
            }

            return _fin;

        }

        public static function decodeScore(_s:String):String{

            var _fin:String = "";

            var decoded:String = _s;

            for(var i:uint = 0; i< decoded.length; i++){
                //trace( decoded.charAt(i) + " - > "  + charsTable.getKey( decoded.charAt(i) ) );
                _fin += charsTable.getKey( decoded.charAt(i) );
            }

            return _fin;

        }

        public static function encodeScoreRand(_s:Number):String{
            var _fin:String = "";

            _fin += generateRandomChars(10) + encodeScore(_s) + generateRandomChars(3)

            return _fin;
        }

        public static function decodeScoreRand(_s:String):Number{

            var decodedString:String = _s;
            var decoded:Number;

            decodedString = decodedString.substring(10,13);         
            decodedString = decodeScore(decodedString);

            decoded = Number(decodedString);

            return decoded;
        }

        public static function generateRandomChars(_length:Number):String{

            var newRandChars:String = "";

            for(var i:uint = 0; i< _length; i++){
                newRandChars+= ranChars[ Math.ceil( Math.random()*ranChars.length-1 )];
            }

            return newRandChars;
        }

        private static function addLeadingZeros(_s:Number):String{

            var _fin:String;

            if(_s < 10 ){
                 _fin = "00" + _s.toString();
            }

            if(_s >= 10 && _s < 99 ) {
                 _fin = "0" + _s.toString();
            }

            if(_s >= 100 ) {
                _fin = _s.toString();
            }           

            return _fin;
        }


    }//end
}

Potem wysyłam zmienną wśród innych fałszywych VAR-ów i po prostu gubię się wśród drogi... To jest dużo pracy dla tylko małe gry flash, ale gdzie nagrody są zaangażowane niektórzy ludzie po prostu dostać chciwy. Jeśli potrzebujesz pomocy, napisz do mnie.

Szyfrowanie przy użyciu znanego (prywatnego) klucza odwracalnego byłoby najprostszą metodą. Nie jestem na bieżąco, więc nie jestem pewien, jakiego rodzaju dostawcy szyfrowania istnieją.

Ale możesz dołączyć zmienne takie jak długość gry (zaszyfrowana, ponownie) i liczba kliknięć.

Wszystkie takie rzeczy można poddać inżynierii odwrotnej, więc rozważ wrzucenie kilku śmieciowych danych, aby zmylić ludzi z tropu.

Edit: w niektórych sesjach PHP też może być warto. Start the sesja po kliknięciu start game i (jak mówi komentarz do tego posta) Zaloguj się czas. Kiedy prześlą wynik, możesz sprawdzić, czy rzeczywiście mają otwartą grę i nie przesyłają wyniku za wcześnie lub za dużo.

Może warto wypracować Skalar, aby zobaczyć, jaki jest maksymalny wynik na sekundę/minutę gry.

Żadna z tych rzeczy nie jest nieobrzezalna, ale przyda się trochę logiki nie we Flashu, gdzie ludzie mogą to zobaczyć.

Z mojego doświadczenia wynika, że najlepiej traktować to jako problem inżynierii społecznej, a nie jako problem programowania. Zamiast skupiać się na uniemożliwieniu oszukiwania, skup się na uczynieniu go nudnym, usuwając zachęty do oszukiwania. Na przykład, jeśli główną zachętą są publicznie widoczne wysokie wyniki, po prostu opóźnienie, gdy wyświetlane są wysokie wyniki, może znacznie zmniejszyć oszustwa, usuwając pętlę pozytywnego sprzężenia zwrotnego dla oszustów.

Nie można ufać żadnym danym, które zwraca klient. Walidacja musi być przeprowadzona po stronie serwera. Nie jestem programistą gier, ale zajmuję się tworzeniem oprogramowania biznesowego. W obu przypadkach pieniądze mogą być zaangażowane, a ludzie będą łamać techniki zaciemniania po stronie klienta.

Może wysyłać dane z powrotem do serwera okresowo i zrobić jakąś walidację. Nie skupiaj się na kodzie klienta, nawet jeśli tam mieszka twoja aplikacja.

Gdy Twój system wyników jest oparty na fakcie, że aplikacja Flash wysyła nieencyklopedyczne / niepodpisane dane wyników przez sieć, które mogą być przechwytywane i manipulowane / odtwarzane. Odpowiedź wynika z tego: encrypt (przyzwoicie!) lub kryptograficznie podpisać dane z rankingu. To przynajmniej utrudnia ludziom złamanie systemu najlepszych wyników, ponieważ będą musieli wyodrębnić tajny klucz z pliku SWF. Wiele osób pewnie się tam podda. Z drugiej strony, wszystkie potrzeba samotnej osoby, aby wydobyć klucz i umieścić go gdzieś.

Rzeczywiste rozwiązania wymagają większej komunikacji między aplikacją Flash a bazą danych wyników, aby ta ostatnia mogła sprawdzić, czy dany wynik jest w pewnym sensie realistyczny. Jest to prawdopodobnie skomplikowane w zależności od tego, jaki rodzaj gry masz.

Nie ma sposobu, aby uczynić go całkowicie niehakowanym, ponieważ łatwo jest dekompilować pliki SWF, a wykwalifikowany programista haker może następnie prześledzić Twój kod i dowiedzieć się, jak ominąć dowolny zaszyfrowany system, który możesz zastosować.

Jeśli chcesz po prostu powstrzymać dzieci przed oszukiwaniem za pomocą prostych narzędzi, takich jak TamperData, możesz wygenerować klucz szyfrowania, który PRZEKAZUJESZ do pliku SWF podczas uruchamiania. Następnie użyj czegoś w rodzaju http://code.google.com/p/as3crypto / aby zaszyfrować wysoką wynik przed przekazaniem go z powrotem do kodu PHP. Następnie odszyfruj go na końcu serwera przed zapisaniem go w bazie danych.

Mówisz o tym, co nazywa się "problemem zaufania klientów". Ponieważ klient (w tej gotówce SWF działający w przeglądarce) robi coś, do czego jest przeznaczony. Zapisz wysoki wynik.

Problem polega na tym, że chcesz się upewnić ,że żądania "zapisz wynik" pochodzą z filmu flash, a nie jakieś dowolne żądanie HTTP. Możliwe rozwiązanie tego problemu to zakodowanie tokenu wygenerowanego przez serwer do pliku SWF w momencie żądania (za pomocą flasm ), który musi dołącz do prośby, aby zapisać wysoki wynik. Gdy serwer zapisze ten wynik, token traci ważność i nie może być już używany do żądań.

Minusem tego jest to, że użytkownik będzie mógł przesłać tylko jeden wysoki wynik na załadowanie filmu flash - musisz zmusić go do odświeżenia / przeładowania pliku SWF, zanim będzie mógł ponownie odtworzyć nowy wynik.

Zazwyczaj dołączam "ghost data"sesji gry z wpisem rankingu. Więc jeśli robię grę wyścigową, dołączam dane powtórki. Często posiadasz już dane powtórki, aby uzyskać funkcję powtórki lub funkcję ghost racing (grając przeciwko ostatniemu wyścigowi lub grając przeciwko ghost of dude #14 w tabeli liderów).

Sprawdzanie ich jest bardzo ręczne, ale jeśli celem jest sprawdzenie, czy 10 najlepszych zgłoszeń w konkursie jest legalne, może to być przydatnym dodatkiem do arsenał środków bezpieczeństwa inni już wskazali.

Jeśli celem jest utrzymanie listy najlepszych wyników w Internecie do końca czasu, bez konieczności patrzenia na nie, to nie przyniesie Ci wiele.

Sposób, w jaki robi to nowy popularny arcade mod, polega na tym, że wysyła dane z Flasha do php, z powrotem do Flasha( lub przeładowuje go), a następnie z powrotem do php. Pozwala to zrobić wszystko, co chcesz porównać dane, a także ominąć hacki danych/deszyfrowania postów i tym podobne. Jednym ze sposobów jest przypisanie 2 randomizowanych wartości z php do Flasha (których nie można pobrać ani zobaczyć, nawet jeśli działa program realtime flash data grabber), używając wzoru matematycznego, aby dodać wynik z losowymi wartościami następnie sprawdzanie go za pomocą tej samej formuły, aby odwrócić go, aby sprawdzić, czy wynik pasuje do niego, gdy w końcu trafi do php na końcu. Te losowe wartości nigdy nie są widoczne, a także czasy transakcji zachodzące, a jeśli jest to więcej niż kilka sekund, oznacza to również oszustwo, ponieważ zakłada, że zatrzymałeś wysyłanie, aby spróbować dowiedzieć się losowych wartości lub uruchomić liczby za pomocą pewnego rodzaju szyfru, aby zwrócić możliwe losowe wartości w celu porównania z wynikiem wartość.

Wydaje mi się to całkiem dobrym rozwiązaniem, czy ktoś widzi jakieś problemy z używaniem tej metody? Czy możliwe sposoby obejścia tego?

Myślę, że najprostszym sposobem byłoby wywołanie funkcji takiej jak RegisterScore (score) za każdym razem, gdy gra zarejestruje wynik do dodania, a następnie zakoduje go, spakuje i wyśle do skryptu php jako ciąg znaków. Skrypt php wiedziałby, jak go poprawnie dekodować. Zatrzyma to wszelkie wywołania bezpośrednio do skryptu php, ponieważ próby wymuszenia wyniku spowodowałyby błąd dekompresji.

Jest to możliwe tylko dzięki przechowywaniu całej logiki gry po stronie serwera, która również przechowuje wynik wewnętrznie bez wiedzy użytkownika. Ze względów ekonomicznych i naukowych ludzkość nie może zastosować tej teorii do wszystkich typów gier, z wyjątkiem turowych. Np. utrzymanie fizyki po stronie serwera jest kosztowne obliczeniowo i trudne do uzyskania jako szybkość ręki. Nawet to możliwe, podczas gry w szachy każdy może dopasować rozgrywkę szachową AI do przeciwnika. Dlatego lepiej multiplayer gry powinny również zawierać kreatywność na żądanie.

To nie jest naprawdę możliwe, aby osiągnąć to, co chcesz. Wewnętrzne aplikacje Flash są zawsze częściowo dostępne, zwłaszcza gdy wiesz, jak korzystać z rzeczy takich jak CheatEngine , co oznacza, że bez względu na to, jak bezpieczna jest Twoja strona internetowa i komunikacja z serwerem przeglądarki, nadal będzie stosunkowo prosta do pokonania.

Dobrym pomysłem może być komunikacja z backendem poprzez AMFPHP . Powinno to zniechęcić przynajmniej leniwych do prób wypychania wyników za pomocą konsoli przeglądarki.