Jaki jest najlepszy sposób, aby powstrzymać ludzi przed hackowaniem opartej na PHP tabeli najlepszych wyników gry Flash

Mówię o grze akcji bez górnego limitu punktów i bez możliwości zweryfikowania wyniku na serwerze poprzez odtwarzanie ruchów itp.

To, czego naprawdę potrzebuję, to najsilniejsze szyfrowanie możliwe we Flash / PHP i sposób, aby ludzie nie dzwonili na stronę PHP inaczej niż przez mój plik Flash. W przeszłości próbowałem kilku prostych metod wywoływania pojedynczej partytury i wypełniania sekwencji sum kontrolnych / fibonacci itp., A także zaciemniania SWF za pomocą Amayeta SWF Encrypt, ale ostatecznie wszystkie zostały zhakowane.

Dzięki odpowiedziom StackOverflow znalazłem teraz więcej informacji od Adobe - http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps_12.html i https://github.com/mikechambers/as3corelib - co myślę można użyć do szyfrowania. Nie jestem jednak pewien, czy to doprowadzi mnie dookoła CheatEngine.

Muszę znać najlepsze rozwiązania zarówno dla AS2, jak i AS3, jeśli są one różne.

Głównymi problemami wydają się być takie elementy, jak nagłówki TamperData i LiveHTTP, ale rozumiem, że istnieją również bardziej zaawansowane narzędzia hakerskie - takie jak CheatEngine (dzięki Mark Webster)

Jest to klasyczny problem z grami i konkursami internetowymi. Twój kod Flash współpracuje z użytkownikami w celu ustalenia wyniku dla gry. Ale użytkownicy nie są zaufani, a kod Flash działa na komputerze użytkownika. Jesteś SOL. Nic nie możesz zrobić, aby uniemożliwić atakującemu osiągnięcie wysokich wyników:

• Flash jest jeszcze łatwiejszy do inżynierii wstecznej, niż ci się wydaje, ponieważ kody bajtowe są dobrze udokumentowane i opisują język wysokiego poziomu (ActionScript) --- kiedy publikujesz grę Flash, publikujesz swój kod źródłowy, niezależnie od tego, czy wiem to czy nie.

• Atakujący kontrolują pamięć wykonawczą interpretera Flash, dzięki czemu każdy, kto umie korzystać z programowalnego debuggera, może w dowolnej chwili zmienić dowolną zmienną (w tym bieżącą ocenę) lub sam program.

Najprostszym możliwym atakiem na Twój system jest uruchomienie ruchu HTTP do gry przez serwer proxy, przechwycenie zapisu o wysokim wyniku i odtworzenie go z wyższym wynikiem.

Możesz spróbować zablokować ten atak, wiążąc każdą zapisaną rekord z jednym wynikiem gry, na przykład wysyłając zaszyfrowany token do klienta podczas uruchamiania gry, który może wyglądać następująco:

hex-encoding( AES(secret-key-stored-only-on-server, timestamp, user-id, random-number))

(Możesz również użyć ciasteczka sesyjnego w tym samym celu).

Kod gry powtarza ten token z powrotem na serwer z zapisanym wynikiem. Ale atakujący nadal może po prostu ponownie uruchomić grę, zdobyć token, a następnie natychmiast wkleić ten token do odtworzonego rzutu wolnego.

Następnie podajesz nie tylko token lub sesyjny plik cookie, ale także klucz sesji szyfrujący najlepsze wyniki. Będzie to 128-bitowy klucz AES, który jest zaszyfrowany kluczem zapisanym na stałe w grze Flash:

hex-encoding( AES(key-hardcoded-in-flash-game, random-128-bit-key))

Teraz, zanim gra opublikuje najwyższy wynik, odszyfrowuje klucz sesji szyfrowania najlepszych wyników, co może zrobić, ponieważ zapisałeś klucz szyfrujący klucza sesji-szyfrowania w pliku binarnym Flash. Zaszyfrujesz najwyższy wynik za pomocą tego odszyfrowanego klucza wraz z skrótem SHA1 o wysokim wyniku:

hex-encoding( AES(random-128-bit-key-from-above, high-score, SHA1(high-score)))

Kod PHP na serwerze sprawdza token, aby upewnić się, że żądanie pochodzi z prawidłowej instancji gry, a następnie odszyfrowuje zaszyfrowany najlepszy wynik, sprawdzając, czy najlepszy wynik odpowiada SHA1 najwyższego wyniku (jeśli pominiesz ten krok , deszyfrowanie spowoduje po prostu losowe, prawdopodobnie bardzo wysokie, wysokie wyniki).

Więc teraz atakujący dekompiluje kod Flash i szybko znajduje kod AES, który wystaje jak obolały kciuk, chociaż nawet jeśli nie, zostałby wyśledzony w ciągu 15 minut za pomocą wyszukiwania pamięci i znacznika („Wiem mój wynik dla tej gry to 666, więc znajdźmy 666 w pamięci, a następnie złapmy każdą operację, która dotknie tej wartości --- och, spójrz, kod szyfrujący wysoki wynik! ”). Dzięki kluczowi sesji atakujący nie musi nawet uruchamiać kodu Flash; chwyta token uruchomienia gry i klucz sesji i może odesłać dowolny wynik.

Jesteś teraz w punkcie, w którym większość programistów po prostu się poddaje - daj lub weź kilka miesięcy na bałagan z atakującymi przez:

• Mieszanie kluczy AES z operacjami XOR

• Zastępowanie tablic bajtów klucza funkcjami obliczającymi klucz

• Rozpraszanie fałszywych szyfrów kluczy i wpisów o wysokich wynikach w całym pliku binarnym.

To wszystko głównie strata czasu. Oczywiste jest, że SSL też ci nie pomoże; SSL nie może cię chronić, gdy jeden z dwóch punktów końcowych SSL jest zły.

Oto kilka rzeczy, które mogą faktycznie ograniczyć oszustwa o wysokim wyniku:

• Wymagaj logowania, aby zagrać w grę, poproś o wygenerowanie pliku cookie sesji i nie zezwalaj na wiele zaległych uruchomień gry w tej samej sesji lub na wiele równoczesnych sesji dla tego samego użytkownika.

• Odrzuć wysokie wyniki z sesji gier, które trwają krócej niż najkrótsze prawdziwe gry, w jakie kiedykolwiek grałeś (dla bardziej wyrafinowanego podejścia, spróbuj „poddać kwarantannie” wysokie wyniki dla sesji gier, które trwają mniej niż 2 standardowe odchylenia poniżej średniego czasu gry). Upewnij się, że śledzisz czas trwania gry na serwerze.

• Odrzuć lub poddaj kwarantannie wysokie wyniki z logowań, w które grałeś tylko raz lub dwa razy, aby atakujący musieli stworzyć „papierową ścieżkę” rozsądnie wyglądającej rozgrywki dla każdego loginu, który utworzą.

• „Heartbeat” zdobywa punkty podczas gry, dzięki czemu Twój serwer widzi wzrost wyniku w ciągu jednej gry. Odrzuć wysokie wyniki, które nie są zgodne z rozsądnymi krzywymi wyników (na przykład, skacząc z 0 do 999999).

• Stan „Migawki” podczas gry (na przykład ilość amunicji, pozycja na poziomie itp.), Którą można później uzgodnić z zapisanymi wynikami tymczasowymi. Na początek nie musisz nawet wykrywać anomalii w tych danych; po prostu musisz go zebrać, a następnie możesz wrócić i przeanalizować, czy wszystko wygląda podejrzanie.

• Wyłącz konto każdego użytkownika, który nie przejdzie jednego z twoich kontroli bezpieczeństwa (na przykład poprzez przesłanie zaszyfrowanego wysokiego wyniku, który nie przejdzie weryfikacji).

Pamiętaj jednak, że powstrzymujesz się jedynie od oszustw związanych z wysokim wynikiem. Tam nic nie można zrobić, aby zapobiec jeśli. Jeśli w twojej grze są pieniądze, ktoś pokona każdy system, który wymyślisz. Celem nie jest powstrzymanie tego ataku; ma sprawić, że atak będzie droższy niż tylko bycie naprawdę dobrym w grze i pokonanie go.

Być może zadajesz złe pytanie. Wygląda na to, że koncentrujesz się na metodach, które ludzie wykorzystują, aby wspiąć się na listę najlepszych wyników, ale blokowanie określonych metod idzie tak daleko. Nie mam doświadczenia z TamperData, więc nie mogę z tym rozmawiać.

Pytanie, które powinieneś zadać, brzmi: „Jak mogę zweryfikować, czy przesłane wyniki są prawidłowe i autentyczne?” Konkretny sposób na to zależy od gry. W przypadku bardzo prostych gier logicznych możesz przesłać wynik wraz z określonym stanem początkowym i sekwencją 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 wynik obliczony i zaakceptuj wynik tylko wtedy, gdy się zgadza.

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

Przy obliczaniu tej sumy kontrolnej należy użyć wspólnego klucza tajnego; ten sekret nigdy nie powinien być przesyłany przez sieć, ale powinien być zakodowany na stałe zarówno w backendzie PHP, jak i we flashu. Powyższa suma kontrolna została utworzona przez dodanie ciągu „ sekret ” do wyniku „ 500 ” i przepuszczenie go przez md5sum.

Chociaż ten system uniemożliwi użytkownikowi publikowanie dowolnych wyników, nie zapobiega on „ponownemu atakowi”, w którym użytkownik ponownie publikuje wcześniej obliczoną kombinację wyniku i skrótu. W powyższym przykładzie wynik 500 zawsze dawałby ten sam ciąg skrótu. Niektóre z tych zagrożeń można ograniczyć, wprowadzając więcej informacji (takich jak nazwa użytkownika, znacznik czasu lub adres IP) do ciągu, który ma być zszywany. Chociaż nie zapobiegnie to ponownemu odtwarzaniu danych, zapewni, że zestaw danych jest ważny tylko dla jednego użytkownika jednocześnie.

Aby uniknąć jakichkolwiek atakom przez powtórzenie z występujących, jakiś rodzaj systemu challenge-response będą musiały zostać utworzone, takie jak:

1. Gra flash („klient”) wykonuje HTTP GET http://example.com/highscores.php bez parametrów. Ta strona zwraca dwie wartości: losowo wygenerowaną wartość soli oraz kryptograficzny skrót tej wartości soli w połączeniu ze wspólnym sekretem. Ta wartość soli powinna być przechowywana w lokalnej bazie danych oczekujących zapytań i powinna być z nią powiązana sygnatura czasowa, aby mogła „wygasnąć” po około jednej minucie.
2. Gra flash łączy wartość soli z udostępnionym kluczem tajnym i oblicza wartość skrótu, aby sprawdzić, czy odpowiada ona wartości podanej przez serwer. Ten krok jest konieczny, aby zapobiec manipulowaniu wartościami soli przez użytkowników, ponieważ weryfikuje, czy wartość soli została faktycznie wygenerowana przez serwer.
3. Gra flash łączy wartość soli ze wspólnym sekretem, wartością najwyższego wyniku i wszelkimi innymi istotnymi informacjami (pseudonim, ip, znacznik czasu) i oblicza wartość skrótu. Następnie wysyła te informacje z powrotem do zaplecza PHP za pośrednictwem HTTP GET lub POST, wraz z wartością soli, wysokim wynikiem i innymi informacjami.
4. Serwer łączy informacje otrzymane w taki sam sposób jak na kliencie i oblicza wartość skrótu, aby sprawdzić, czy jest ona zgodna z informacją podaną przez klienta. Następnie sprawdza również, czy wartość soli jest nadal aktualna, jak podano na liście oczekujących zapytań. Jeśli oba te warunki są spełnione, zapisuje najwyższy wynik w tabeli najlepszych wyników i zwraca klientowi podpisany komunikat „sukces”. Usuwa również wartość soli z listy oczekujących zapytań.

Należy pamiętać, że bezpieczeństwo dowolnej z powyższych technik jest zagrożone, jeśli wspólny sekret jest zawsze dostępny dla użytkownika

Alternatywnie, można tego uniknąć, zmuszając klienta do komunikowania się z serwerem za pośrednictwem protokołu HTTPS i zapewniając, że klient jest wstępnie skonfigurowany tak, aby ufał tylko certyfikatom podpisanym przez określony urząd certyfikacji, do którego ty sam masz dostęp .

Podoba mi się to, co powiedział tpqf, ale zamiast dezaktywować konto po wykryciu oszustwa, zaimplementuj honeypot, aby za każdym razem, gdy się logowali, widzieli swoje zhakowane wyniki i nigdy nie podejrzewali, że zostali oznaczeni jako troll. Google dla „phpBB MOD Troll”, a zobaczysz genialne podejście.

W zaakceptowanej odpowiedzi tqbf wspomina, że ​​możesz po prostu wyszukać w pamięci zmienną wyniku („Mój wynik to 666, więc szukam liczby 666 w pamięci”).

Jest na to sposób. Mam tutaj klasę: http://divillysausages.com/blog/safenumber_and_safeint

Zasadniczo masz obiekt do zapisania swojego wyniku. W setercie mnoży przekazywaną wartość przez liczbę losową (+ i -), aw gette dzielisz zapisaną wartość przez losowy multiplikator, aby odzyskać oryginał. To proste, ale pomaga zatrzymać wyszukiwanie pamięci.

Zobacz także wideo od niektórych facetów stojących za silnikiem PushButton, którzy mówią o różnych sposobach walki z hackowaniem: http://zaa.tv/2010/12/the-art-of-hacking-flash- gry / . Były inspiracją dla klasy.

Dokonałem pewnego obejścia ... Miałem dawanie, w którym wyniki rosły (zawsze dostajesz +1 punkt). Najpierw zacząłem liczyć od losowej liczby (powiedzmy 14), a kiedy wyświetlałem wyniki, po prostu pokazałem wyniki var minus 14. Było tak, że jeśli crackerzy szukają na przykład 20, nie znajdą tego (to będzie 34 w pamięci). Po drugie, ponieważ wiem, jaki powinien być następny punkt ... Użyłem biblioteki kryptograficznej Adobe, aby utworzyć skrót tego, co powinien być następny punkt. Kiedy muszę zwiększać wyniki, sprawdzam, czy skrót przyrostowych wyników jest równy skrótowi powinien być. Jeśli cracker zmienił punkty w pamięci, skróty nie są równe. Przeprowadzam weryfikację po stronie serwera, a kiedy otrzymałem inne punkty od gry i od PHP, wiem, że w grę wchodziły oszukiwanie. Oto fragment mojego kodu (używam klasy Adobe Crypto libraty MD5 i losowej soli kryptograficznej. CallPhp () to walidacja po stronie mojego 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");
            }
        }

Dzięki tej technice + zaciemnieniu SWF udało mi się zatrzymać krakersy. Ponadto, gdy przesyłam partytury po stronie serwera, 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 napisać 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
}

Następnie wysyłam zmienną między innymi fałszywymi zmiennymi i po prostu gubi się po drodze ... To jest dużo pracy dla małej gry flash, ale tam, gdzie są nagrody, niektórzy ludzie po prostu chciwie. Jeśli potrzebujesz pomocy, napisz mi wiadomość.

Pozdrawiam, Ico

Szyfrowanie przy użyciu znanego (prywatnego) odwracalnego klucza byłoby najprostszą metodą. Nie jestem zainteresowany AS, więc nie jestem pewien, jakiego rodzaju dostawców szyfrowania są.

Możesz jednak dołączyć zmienne takie jak długość gry (ponownie zaszyfrowane) i liczbę kliknięć.

Wszystkie takie rzeczy można poddać inżynierii wstecznej, więc zastanów się nad wprowadzeniem niepotrzebnych danych, aby odrzucić ludzi od zapachu.

Edycja: W niektórych sesjach PHP warto też się wyrzucać. Rozpocznij sesję, gdy klikną przycisk Rozpocznij grę i (jak mówi komentarz do tego postu) zaloguj czas. Kiedy podadzą wynik, możesz sprawdzić, czy rzeczywiście mają otwartą grę i nie przedstawiają wyniku zbyt wcześnie lub zbyt dużego.

Warto opracować skalar, aby zobaczyć, jaki jest maksymalny wynik na sekundę / minutę gry.

Żadna z tych rzeczy nie jest nie do obejścia, ale pomoże mieć logikę nie we Flashu, gdzie ludzie to widzą.

Z mojego doświadczenia wynika, że ​​najlepiej jest to traktować raczej jako problem inżynierii społecznej niż problem programowania. Zamiast skupiać się na uniemożliwieniu oszukiwania, skup się na nudności poprzez usunięcie zachęt do oszukiwania. Na przykład, jeśli główną zachętą są publicznie widoczne wysokie wyniki, po prostu opóźnienie wyświetlania wysokich wyników może znacznie ograniczyć oszustwo poprzez usunięcie pętli pozytywnego sprzężenia zwrotnego dla oszustów.

Nie możesz ufać żadnym danym, które zwraca klient. Sprawdzanie poprawności należy przeprowadzić po stronie serwera. Nie jestem twórcą gier, ale tworzę oprogramowanie biznesowe. W obu przypadkach można zaangażować pieniądze, a ludzie złamią techniki zaciemniania po stronie klienta.

Może okresowo wysyłaj dane z powrotem do serwera i dokonaj weryfikacji. Nie skupiaj się na kodzie klienta, nawet jeśli tam mieszka Twoja aplikacja.

Ilekroć twój system najlepszych wyników opiera się na fakcie, że aplikacja Flash wysyła przez sieć nieszyfrowane / niepodpisane dane najlepszych wyników, które mogą być przechwytywane i przetwarzane / odtwarzane. Odpowiedź wynika z tego: szyfruj (przyzwoicie!) Lub kryptograficznie podpisuj dane z najlepszych wyników. To przynajmniej utrudnia ludziom złamanie twojego systemu najlepszych wyników, ponieważ będą musieli wyodrębnić tajny klucz z pliku SWF. Wiele osób prawdopodobnie się podda. Z drugiej strony wystarczy jedna osoba, aby wyciągnąć klucz i opublikować go gdzieś.

Prawdziwe rozwiązania wymagają większej komunikacji między aplikacją Flash a bazą danych najlepszych wyników, aby ta ostatnia mogła zweryfikować, czy dany wynik jest nieco realistyczny. Jest to prawdopodobnie skomplikowane w zależności od rodzaju posiadanej gry.

Nie ma sposobu, aby uczynić go całkowicie niehackowalnym, ponieważ łatwo jest dekompilować pliki SWF, a wykwalifikowany 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 oszustwem za pomocą prostych narzędzi, takich jak TamperData, możesz wygenerować klucz szyfrujący, który przekazujesz do SWF podczas uruchamiania. Następnie użyj czegoś takiego jak http://code.google.com/p/as3crypto/, aby zaszyfrować najlepszy 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 problemie zwanym „zaufaniem klienta”. Ponieważ klient (w tej gotówce plik SWF działający w przeglądarce) robi coś, do czego został zaprojektowany. Zapisz najlepszy wynik.

Problem polega na tym, że chcesz się upewnić, że żądania „zapisz wynik” pochodzą z twojego filmu flash, a nie jakieś dowolne żądanie HTTP. Możliwym rozwiązaniem tego jest zakodowanie tokena wygenerowanego przez serwer w pliku SWF w momencie żądania (przy użyciu flasm ), który musi towarzyszyć żądaniu, aby zapisać wysoki wynik. Gdy serwer zapisze wynik, token wygasł i nie można go już używać do żądań.

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

Zazwyczaj dołączam „dane o duchach” sesji gry do wpisu o najlepszych wynikach. Więc jeśli tworzę grę wyścigową, dołączam dane powtórki. Często masz już dane powtórkowe dla funkcji powtórki lub funkcji wyścigów z duchami (gra przeciwko ostatniej rasie lub gra przeciwko duchowi kolesia # 14 na tablicy wyników).

Sprawdzanie, czy jest to praca bardzo ręczna, ale jeśli celem jest sprawdzenie, czy 10 najlepszych zgłoszeń do konkursu jest legalnych, może to być przydatny dodatek do arsenału środków bezpieczeństwa, które inni już wskazali.

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

Sposób, w jaki robi to nowy popularny mod zręcznościowy, polega na tym, że wysyła dane z flasha do php, z powrotem na flash (lub przeładowuje), a następnie z powrotem do php. Pozwala to zrobić wszystko, co chcesz porównać dane, a także ominąć włamania do danych / deszyfrowania i tym podobne. Jednym ze sposobów, aby to zrobić, jest przypisanie do pamięci flash 2 losowych wartości z php (których nie można złapać ani zobaczyć, nawet jeśli uruchamiany jest program do pobierania danych flash w czasie rzeczywistym), za pomocą wzoru matematycznego, aby dodać wynik z losowymi wartościami, a następnie sprawdzić go za pomocą ten sam wzór, aby odwrócić go, aby zobaczyć, 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 razy transakcja ma miejsce, a jeśli „

To pytanie wydaje się całkiem dobrym rozwiązaniem, jeśli ktoś mnie zapyta, czy ktoś widzi jakieś problemy z używaniem tej metody? Lub możliwe sposoby obejścia tego?

Myślę, że najprostszym sposobem byłoby wywoływanie funkcji takiej jak RegisterScore (score) za każdym razem, gdy gra rejestruje wynik, który ma zostać dodany, a następnie koduje go, pakuje i wysyła do skryptu php jako ciąg znaków. Skrypt php wiedziałby, jak poprawnie go zdekodować. Spowodowałoby to zatrzymanie wszelkich wywołań bezpośrednio do skryptu php, ponieważ wszelkie próby wymuszenia wyniku spowodowałyby błąd dekompresyjny.

Jest to możliwe tylko poprzez zachowanie logiki całej 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 tur. Na przykład trzymanie fizyki po stronie serwera jest kosztowne obliczeniowo i trudno jest uzyskać szybkość reakcji. Nawet możliwe, podczas gry w szachy każdy może dopasować rozgrywkę szachową AI do przeciwnika. Dlatego lepsze gry wieloosobowe powinny również zawierać kreatywność na żądanie.

Naprawdę nie jest możliwe osiągnięcie tego, co chcesz. Elementy wewnętrzne aplikacji Flash są zawsze częściowo dostępne, zwłaszcza gdy wiesz, jak korzystać z takich funkcji , jak CheatEngine , co oznacza, bez względu na to, jak bezpieczna jest komunikacja między Twoją witryną a przeglądarką <-> serwera, nadal będzie stosunkowo łatwo ją pokonać.

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