Який найкращий спосіб зупинити людей, які хакують таблицю рейтингів Flash-гри на основі PHP

Я говорю про екшн-гру без верхнього ліміту балів і ніякого способу перевірити рахунок на сервері, відтворюючи ходи тощо.

Що мені дійсно потрібно - це найсильніше шифрування, яке можливо в Flash / PHP, і спосіб запобігти людям, які дзвонять на сторінку PHP, окрім мого файлу Flash. У минулому я спробував декілька простих методів для здійснення декількох дзвінків на один рахунок та заповнення послідовності контрольної суми / позицій тощо, а також обмацував SWF за допомогою шифрування Amayeta SWF, але в кінцевому підсумку всі вони були зламані.

Завдяки відповідям StackOverflow тепер я знайшов додаткову інформацію від Adobe - http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps_12.html та https://github.com/mikechambers/as3corelib - що, на мою думку, я вважаю може використовувати для шифрування. Не впевнений, що це оберне мене навколо CheatEngine, хоча.

Мені потрібно знати найкращі рішення як для AS2, так і для AS3, якщо вони різні.

Основними проблемами здаються такі речі, як заголовки TamperData та LiveHTTP, але я розумію, що є і більш просунуті інструменти для злому - як CheatEngine (дякую Марку Вебстеру)

Це класична проблема Інтернет-ігор та конкурсів. Ваш Flash-код працює з користувачами, щоб визначити бал за гру. Але користувачам не довіряють, і Flash-код працює на комп'ютері користувача. Ти СОЛ. Ви нічого не можете зробити, щоб зловмисник не підробив високі бали:

• Flash інженеру навіть легше, ніж ви могли б подумати, оскільки байт-коди добре задокументовані та описують мову високого рівня (Actioncript) --- коли ви публікуєте гру Flash, ви публікуєте свій вихідний код, будь-ласка знаєте це чи ні.

• Зловмисники контролюють пам'ять виконання інтерпретатора Flash, так що кожен, хто знає, як використовувати програмований відладчик, може змінити будь-яку змінну (включаючи поточну оцінку) в будь-який час або змінити саму програму.

Найпростіша можлива атака проти вашої системи - це запустити HTTP-трафік для гри через проксі-сервер, зафіксувати збереження високого балу та повторити його з більш високим балом.

Ви можете спробувати заблокувати цю атаку, прив'язавши кожен високий бал збереження до одного екземпляра гри, наприклад, надіславши зашифрований маркер клієнту при запуску гри, який може виглядати так:

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

(Ви можете також використати сесійне cookie з таким же ефектом).

Код гри повторює цей маркер назад на сервер із збереженням високих балів. Але зловмисник все ще може просто запустити гру знову, отримати маркер, а потім негайно вставити цей маркер у повторно збережений рейтинг.

Тож далі ви подаєте не лише файли cookie-маркера або сеансу, а й ключ сеансу, що шифрує високий бал. Це буде 128-бітний ключ AES, сам зашифрований ключем, жорстко закодований у гру Flash:

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

Тепер, перш ніж гра опублікує високий бал, вона розшифровує ключ-сеанс шифрування з високим балом, який він може зробити, тому що ви жорстко закодували ключ-шифрування-сеанс-ключ-дешифрування ключа у бінарний Flash. Ви шифруєте високий бал цим розшифрованим ключем разом із хешем SHA1 високого балу:

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

PHP-код на сервері перевіряє маркер, щоб переконатися, що запит надійшов від дійсного ігрового екземпляра, а потім розшифровує зашифрований високий бал, перевіряючи, чи відповідає високий бал SHA1 високого балу (якщо пропустити цей крок , дешифрування буде просто давати випадкові, ймовірно, дуже високі, високі бали).

Тож тепер зловмисник декомпілює ваш Flash-код і швидко знаходить код AES, який стирчить як біль у великому пальці, хоча навіть якщо б не він, його було відстежено за 15 хвилин за допомогою пошуку пам’яті та відстежувача («Я знаю мій бал за цю гру становить 666, тому давайте знайдемо 666 в пам’яті, тоді вловимо будь-яку операцію, яка торкається цього значення --- о, дивись, код шифрування високого балу! »). За допомогою клавіші сеансу зловмиснику навіть не потрібно запускати Flash-код; вона захоплює маркер запуску гри та ключ сесії та може надіслати назад довільну високу оцінку.

Ви зараз на стадії, коли більшість розробників просто відмовляються --- віддайте або зробіть пару місяців возитися з нападниками:

• Розшифровка клавіш AES за допомогою операцій XOR

• Заміна байтових масивів ключів функціями, які обчислюють ключ

• Розсіювання підроблених шифрів ключів та високий показник опублікування у бінарних файлах.

Це все здебільшого марна трата часу. Само собою зрозуміло, що і SSL не допоможе вам; SSL не може захистити вас, коли одна з двох кінцевих точок SSL є злою.

Ось деякі речі, які можуть фактично зменшити шахрайство з високими показниками:

• Потрібно ввійти в гру, щоб у програмі було створено печиво сеансу, а також забороняти кілька запущених ігор на одному сеансі або кілька одночасних сеансів для одного користувача.

• Відхиліть високі бали від ігрових сеансів, які тривають менше, ніж найкоротші реальні ігри, що коли-небудь грали (для більш досконалого підходу спробуйте "карантинувати" високі бали для ігрових сесій, які тривають менше ніж 2 стандартних відхилення нижче середньої тривалості гри). Переконайтеся, що ви відстежуєте тривалість гри на сервері.

• Відхиліть або карантинуйте високі бали від вхідних даних, які грали в гру лише один раз або два рази, так що зловмисники повинні створити «паперовий слід» грамотного вигляду для кожної гри, яку вони створюють.

• "Серцебиття" забиває під час гри, так що ваш сервер бачить зростання результатів протягом життя однієї гри. Відхиліть високі бали, які не відповідають розумним кривим оцінок (наприклад, стрибки з 0 до 999999).

• Стан гри «Знімок» під час гри (наприклад, кількість боєприпасів, положення у рівні тощо), яке ви згодом зможете погодити із записаними проміжними оцінками. Вам навіть не потрібно мати спосіб виявити аномалії в цих даних для початку; вам просто потрібно зібрати його, і тоді ви можете повернутися назад і проаналізувати, чи все виглядає рибним.

• Вимкніть обліковий запис будь-якого користувача, який не здійснив один із ваших перевірок безпеки (наприклад, коли-небудь надсилаючи зашифрований високий бал, який не може перевірити)

Пам’ятайте, що ви тут лише стримуєте шахрайство з високими показниками Там немає нічого ви можете зробити , щоб запобігти , якщо. Якщо у вашій грі є гроші, хтось збирається перемогти будь-яку систему, яку ви придумали. Мета - не зупинити цю атаку; це зробити атаку дорожчою, ніж просто стати дійсно хорошим у грі та обіграти її.

Ви можете задати неправильне запитання. Ви, здається, зосереджені на методах, якими користуються люди, щоб пройти шлях до списку найвищих балів, але блокування конкретних методів заходить лише поки що. Я не маю досвіду роботи з TamperData, тому не можу з цим говорити.

Питання, яке вам слід задати, таке: "Як я можу підтвердити, що подані бали дійсні та справжні?" Конкретний спосіб зробити це залежно від гри. У дуже простих іграх-головоломках ви можете надсилати рахунок разом із певним початковим станом та послідовністю рухів, що призвели до кінця, а потім повторно запускати гру на стороні сервера, використовуючи ті самі рухи. Підтвердьте, що зазначений бал збігається з обчисленою оцінкою, і приймайте рахунок лише у тому випадку, якщо вони відповідають.

Найпростішим способом зробити це було б надати криптографічний хеш вашої рейтингової вартості разом із оцінкою, яку він робив самостійно. Наприклад, публікуючи результати через HTTP GET: http://example.com/highscores.php?score=500&checksum=0a16df3dc0301a36a34f9065c3ff8095

При обчисленні цієї контрольної суми слід використовувати загальну таємницю; ця таємниця ніколи не повинна передаватися по мережі, але повинна бути жорстко закодована як в PHP, так і в інтерфейс флеш-пам'яті. Контрольна сума вище була створена заздалегідь попередньо додавши рядок " секрет " до оцінки " 500 " та запустивши його через md5sum.

Хоча ця система заважає користувачеві розміщувати довільні бали, це не заважає "атаці повторного відтворення", коли користувач репостує попередньо обчислену комбінацію балів та хеш-сигналів. У наведеному вище прикладі оцінка 500 буде завжди створювати однакові хеш-рядки. Деякий із цього ризику можна зменшити, включивши додаткову інформацію (наприклад, ім’я користувача, часову марку чи IP-адресу) у рядок, який слід хешировать. Незважаючи на те, що це не завадить повторити дані, це гарантуватиме, що набір даних дійсний лише для одного користувача одночасно.

Щоб запобігти виникненню будь-яких атак на повтор, потрібно буде створити певний тип системи відповіді на виклик, наприклад:

1. Флеш-гра ("клієнт") виконує HTTP GET http://example.com/highscores.php без параметрів. Ця сторінка повертає два значення: випадкову величину солі та криптографічний хеш цього значення солі у поєднанні із загальним секретом. Це значення солі має бути збережене у локальній базі даних запитів, що очікують, і має мати пов’язану з нею часову позначку, щоб вона могла "закінчитися" через, можливо, одну хвилину.
2. Флеш-гра поєднує значення солі з загальним секретом і обчислює хеш, щоб переконатися, що воно відповідає тому, яке надає сервер. Цей крок необхідний для запобігання фальсифікації значень солі користувачами, оскільки він підтверджує, що значення солі насправді генерується сервером.
3. Флеш-гра поєднує значення солі із загальним секретом, високим значенням балів та будь-якою іншою відповідною інформацією (псевдонім, ip, часова марка) та обчислює хеш. Потім він надсилає цю інформацію назад в PHP бекенд через HTTP GET або POST, а також значення солі, високий бал та іншу інформацію.
4. Сервер поєднує отриману інформацію так само, як і про клієнта, і обчислює хеш, щоб переконатися, що він відповідає тій, що надається клієнтом. Потім він також перевіряє, що значення солі все ще є дійсним, як зазначено у списку запитів, що очікують. Якщо обидві ці умови є істинними, він записує рейтинг у таблицю з високим балом та повертає клієнту підписане повідомлення про успіх. Це також видаляє значення солі зі списку запитів, що очікують.

Будь ласка, майте на увазі, що безпека будь-якої з перерахованих вище методик порушена, якщо спільна таємниця коли-небудь доступна користувачеві

Як альтернативу, деякі з цих зворотних ситуацій можна уникнути, змусивши клієнта спілкуватися з сервером через HTTPS та гарантуючи, що клієнт попередньо налаштований на довіру лише до сертифікатів, підписаних певним органом сертифікації, до якого ви один маєте доступ .

Мені подобається те, що сказав tpqf, але замість того, щоб вимкнути обліковий запис при виявленні обману, впроваджуйте медовий горщик, щоб кожен раз, коли вони входили в систему, вони бачили свої зламані бали і ніколи не підозрювали, що вони позначені як тролі. Google для "phpBB MOD Troll", і ви побачите геніальний підхід.

У прийнятій відповіді tqbf зазначає, що ви можете просто здійснити пошук в пам'яті для змінної балів ("Моя оцінка 666, тому я шукаю число 666 в пам'яті").

Існує шлях до цього. У мене тут клас: http://divillysausages.com/blog/safenumber_and_safeint

В основному у вас є об'єкт для зберігання ваших балів. У сеттері він помножує значення, яке ви передаєте йому, на випадкове число (+ і -), а в геттері ви ділите збережене значення на випадковий множник, щоб отримати оригінал назад. Це просто, але допомагає зупинити пошук пам'яті.

Також перегляньте відео деяких хлопців, що стоять за механізмом PushButton, які розповідають про деякі різні способи боротьби з взломом: http://zaa.tv/2010/12/the-art-of-hacking-flash- ігри / . Вони були натхненником класу.

Я щось вирішував ... Я мав оцінку, куди збільшувались оцінки (ви завжди отримуєте +1 бал). По-перше, я почав рахувати від випадкового числа (скажімо, 14), і коли я показував бали, просто показав бали var мінус 14. Це було так, якщо сухарі шукають, наприклад, 20, вони не знайдуть його (це буде 34 в пам’яті). По-друге, оскільки я знаю, якою має бути наступна точка ... Я використав криптобібліотеку Adobe, щоб створити хеш того, що має бути наступна точка. Коли мені доведеться збільшити бали, я перевіряю, чи має бути хеш збільшених балів рівним хешу. Якщо зломщик змінив точки в пам'яті, хеші не рівні. Я проводжу деяку перевірку на стороні сервера, і коли я отримував різні бали від гри та від PHP, я знаю, що було пов'язано з обманом. Ось фрагмент мого коду (я використовую клас Adobe Crypto libraty MD5 та сіль випадкової криптографії. CallPhp () - це моя перевірка на сервері)

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");
            }
        }

Використовуючи цю техніку + SWF обтурація, я зміг зупинити сухарі. Крім того, коли я надсилаю оцінки на сервер, я використовую свою маленьку функцію шифрування / дешифрування. Щось подібне (код стороні сервера не включений, але ви можете побачити алгоритм і записати його в 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
}

Потім я надсилаю змінну серед інших фейків, і вона просто втрачається серед дороги ... Це дуже багато роботи лише для невеликих флеш-ігор, але там, де призи задіяні, деякі люди просто жадібні. Якщо вам потрібна допомога, напишіть мені прем'єр-міністр.

Ура, Іко

Шифрування за допомогою відомого (приватного) оборотного ключа було б найпростішим методом. У мене не все на AS, тому я не впевнений, які існують типи постачальників шифрування.

Але ви можете включити такі змінні, як тривалість гри (знову зашифровані) та кількість кліків.

Все, як це, може бути реверсивно розроблене, тому подумайте про те, щоб викинути купу небажаної інформації, щоб відкинути людей від запаху.

Редагувати: Можливо, варто застосувати ще й на деяких сесіях PHP. Почніть сеанс після натискання кнопки «Пуск» та (як йдеться у коментарі до цього допису), записуйте час. Коли вони подають рахунок, ви можете перевірити, чи справді у них відкрита гра, і вони не надто швидко чи занадто великі.

Можливо, варто розробити скаляр, щоб побачити, який максимальний бал - це секунда / хвилина гри.

Жодне з цих речей не є необрізним, але це допоможе мати певну логіку не у спалаху, де люди можуть його бачити.

На мій досвід, це найкраще підходить як проблема соціальної інженерії, а не проблема програмування. Замість того, щоб концентруватися на тому, щоб зробити неможливим обман, зосередьтесь на тому, щоб зробити це нудно, знявши стимули до обману. Наприклад, якщо основним стимулом є загальнодоступні високі бали, просто встановлення затримки, коли відображаються високі бали, може істотно зменшити обман, видаливши позитивний цикл зворотного зв'язку для шахраїв.

Ви не можете довіряти жодним даним, які клієнт повертає. Перевірку потрібно виконати на стороні сервера. Я не розробник ігор, але я роблю програмне забезпечення для бізнесу. В обох випадках гроші можуть бути залучені, і люди будуть порушувати методи клієнта з придушенням.

Можливо, періодично надсилайте дані на сервер і проводите певну перевірку. Не фокусуйтесь на коді клієнта, навіть якщо саме там проживає ваш додаток.

Щоразу, коли ваша система рейтингу базується на тому, що програма Flash надсилає через мережу незашифровані / непідписані дані рейтингу, які можна перехоплювати та маніпулювати / відтворювати. Відповідь випливає з цього: зашифруйте (пристойно!) Або криптографічно підпишіть дані високого рейтингу. Принаймні, це ускладнює людям зламати вашу систему рекордів, оскільки їм потрібно буде витягнути секретний ключ з вашого файлу SWF. Багато людей, мабуть, здадуть саме там. З іншого боку, все, що потрібно, - це людина, яка окремо витягне ключ і покладе його десь.

Реальні рішення передбачають більшу комунікацію між додатком Flash та базою даних рейтингів, щоб останній міг переконатися, що даний бал є дещо реалістичним. Це, мабуть, складне залежно від того, яку гру ви маєте.

Немає можливості зробити це повністю незручним, оскільки легко декомпілювати SWF, і кваліфікований хакер розробника може потім простежити ваш код і розробити, як обійти будь-яку зашифровану систему, яку ви можете використовувати.

Якщо ви просто хочете зупинити обман дітей за допомогою таких простих інструментів, як TamperData, тоді ви можете створити ключ шифрування, який ви передасте SWF при запуску. Потім використовуйте щось на зразок http://code.google.com/p/as3crypto/, щоб зашифрувати високий бал, перш ніж передати його назад до коду PHP. Потім розшифруйте його на кінці сервера, перш ніж зберігати його в базі даних.

Ви говорите про те, що називається проблемою "довіра клієнта". Тому що клієнт (цією готівкою є SWF, який працює в браузері) робить щось, що він призначений робити. Збережіть високий бал.

Проблема полягає в тому, що ви хочете переконатися, що запити "зберегти бал" надходять із вашого флеш-фільму, а не з будь-якого довільного запиту HTTP. Можливим рішенням для цього є кодування маркера, що генерується сервером, в SWF під час запиту (використовуючи флеш ), який повинен супроводжувати запит, щоб зберегти високий бал. Після того, як сервер зберігає цей бал, маркер закінчується, і його більше не можна використовувати для запитів.

Мінус цього полягає в тому, що користувач зможе подати лише один високий бал за завантаження флеш-фільму - вам доведеться змусити їх оновити / перезавантажити SWF, перш ніж вони зможуть знову зіграти для нового рахунку.

Я зазвичай включаю "дані привидів" ігрового сеансу із записом рейтингу. Тож якщо я роблю гоночну гру, я включаю дані повтору. У вас часто є дані про повторення вже для функцій перегляду або функцій гоночних привидів (граючи проти останньої гонки або граючи проти привидів чувака №14 на лідері лідерів).

Перевірка цих робіт є дуже ручною працею, але якщо мета - перевірити, чи законні 10 кращих конкурсних робіт, це може бути корисним доповненням до арсеналу заходів безпеки, які інші вже вказували.

Якщо мета полягає в тому, щоб список рейтингів в Інтернеті до кінця часу не було, щоб ніхто їх не дивився, це не принесе вам багато чого.

Новий популярний мод для аркад - це те, що він надсилає дані з флеш-файлів у php, назад у флеш (або перезавантаження), а потім назад у php. Це дозволяє вам робити все, що ви хочете порівняти, а також обійти хакерські дані / дешифрування тощо. Один із способів цього зробити - це присвоїти 2 спалахізовані значення з php у спалах (які ви не можете схопити чи побачити навіть при запуску в реальному режимі захоплення даних у режимі реального часу), використовуючи математичну формулу, щоб додати бал до випадкових значень, а потім перевірити його за допомогою ту ж формулу, щоб її перевернути, щоб побачити, чи відповідає оцінка, коли вона нарешті переходить до php наприкінці. Ці випадкові величини ніколи не видно, а також вони також раз здійснюють транзакцію, і якщо вона "

Це здається досить гарним рішенням, якщо ви запитаєте мене, чи хтось бачить проблеми з використанням цього методу? Або можливі шляхи навколо нього?

Я думаю, що найпростішим способом було б здійснювати дзвінки до такої функції, як RegisterScore (оцінка) кожного разу, коли гра реєструє доданий рахунок, а потім кодує його, упаковує та відправляє у php-скрипт як рядок. PHP-скрипт знає, як правильно його розшифрувати. Це зупинить будь-які виклики прямо до скрипту php, оскільки будь-які спроби примусити результат призведе до помилки декомпресії.

Це можливо лише за умови збереження всієї логіки гри на стороні сервера, яка також зберігає рахунок внутрішньо без відома користувача. З економічних та наукових причин людство не може застосовувати цю теорію до всіх типів гри, крім покрокових. Наприклад, наприклад, тримати фізику на стороні сервера обчислювально дорого і важко отримати швидкість реагування на швидкість руху. Навіть можливо, під час гри в шахи кожен може зіставити AI шаховий геймплей з супротивником. Тому кращі багатокористувацькі ігри також повинні містити творчість на вимогу.

Неможливо реально досягти того, чого ти хочеш. Внутрішня програма додатка Flash завжди частково доступна, особливо коли ви знаєте, як користуватися такими речами, як CheatEngine , тобто незалежно від того, наскільки безпечними є зв’язок вашого веб-сайту та браузера <-> сервера, це все одно буде подолати порівняно просто.

Можливо, буде гарною ідеєю спілкуватися з бекендом через AMFPHP . Це повинно відмовити принаймні ледачих намагатися просунути результати через консоль браузера.