Что лучший способ состоит в том, чтобы остановить людей, взламывающих основанную на PHP highscore таблицу флеш-игры
NullPointerException s - исключения, возникающие при попытке использовать ссылку, которая указывает на отсутствие местоположения в памяти (null), как если бы она ссылалась на объект. Вызов метода по нулевой ссылке или попытка получить доступ к полю нулевой ссылки вызовет функцию NullPointerException. Они наиболее распространены, но другие способы перечислены на странице NullPointerException javadoc.
Вероятно, самый быстрый пример кода, который я мог бы придумать для иллюстрации NullPointerException, be:
public class Example {
public static void main(String[] args) {
Object obj = null;
obj.hashCode();
}
}
В первой строке внутри main я явно устанавливаю ссылку Object obj равной null. Это означает, что у меня есть ссылка, но она не указывает на какой-либо объект. После этого я пытаюсь обработать ссылку так, как если бы она указывала на объект, вызывая метод на нем. Это приводит к NullPointerException, потому что нет кода для выполнения в местоположении, на которое указывает ссылка.
(Это техничность, но я думаю, что она упоминает: ссылка, которая указывает на null, равна 't то же, что и указатель C, указывающий на недопустимую ячейку памяти. Нулевой указатель буквально не указывает на в любом месте , который отличается от указаний на местоположение, которое оказывается недопустимым.)
12 ответов
Это - классическая проблема с интернет-играми и конкурсами. Ваш код Flash работает с пользователями для решения счета к игре. Но пользователям не доверяют, и код Flash работает на компьютере пользователя. Вы - СОЛЬ. Нет ничего, что можно сделать, чтобы препятствовать тому, чтобы взломщик подделал рекорды:
-
Flash еще легче перепроектировать, чем Вы могли бы думать, что это, так как байт-коды хорошо документируются и описывают высокоуровневый язык (Actionscript)---при публикации флеш-игры Вы публикуете свой исходный код, знаете ли Вы это или нет.
-
Взломщики управляют памятью во время выполнения интерпретатора Flash, так, чтобы любой, кто знает, как использовать программируемый отладчик, мог изменить любую переменную (включая текущий счет) в любое время или изменить саму программу.
самое простое нападение на Вашу систему должно выполнить Трафик HTTP для игры через прокси, поймать высокий счет, сохраняют и воспроизводят его с более высоким счетом.
можно попытаться заблокироваться, это нападение путем привязки каждого высокого счета сохраняют к единственному экземпляру игры, например, путем отправки зашифрованного маркера клиенту при игровом запуске, который мог бы быть похожим:
hex-encoding( AES(secret-key-stored-only-on-server, timestamp, user-id, random-number))
(Вы могли также использовать сеансовые куки для того же эффекта).
игровой код отзывается эхом, этот маркер назад к серверу с высоким счетом сохраняют. Но взломщик может все еще просто запустить игру снова, получить маркер, и затем сразу вставить тот маркер в воспроизводимый высокий счет, сохраняют.
Поэтому затем Вы подаете не только маркерные или сеансовые куки, но также и сеансовый ключ высокого шифрования счета. Это будет ключом AES на 128 битов, самим зашифрованным с ключом hardcoded во флеш-игру:
hex-encoding( AES(key-hardcoded-in-flash-game, random-128-bit-key))
Теперь, прежде чем игра отправляет высокий счет, она дешифрует high-score-encrypting-session ключ, который она может сделать потому что Вы hardcoded high-score-encrypting-session-key-decrypting-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 с операциями "исключающее ИЛИ"
-
Заменяющие ключевые массивы байтов с функциями, которые вычисляют ключ
-
Рассеивающееся поддельное ключевое шифрование и высоко выигрывают регистрации всюду по двоичному файлу.
Это - все главным образом пустая трата времени. Это само собой разумеется, SSL не собирается помогать Вам также; SSL не может защитить Вас, когда одна из двух конечных точек SSL является злой.
Вот некоторые вещи, которые могут на самом деле уменьшить высокое мошенничество со счетом:
-
Требуют, чтобы вход в систему, чтобы играть в игру, иметь вход в систему произвели сеансовые куки и не позволяли несколько выдающихся игровых запусков на той же сессии или нескольких параллельных сессиях для того же пользователя.
-
рекорды Отклонения от игровых сессий, которые длятся меньше, чем самые короткие реальные игры, в которые когда-либо играют (для более сложного подхода, попытайтесь "изолировать" рекорды для игровых сессий, которые длятся меньше чем 2 стандартных отклонения ниже средней игровой продолжительности). Удостоверьтесь, что Вы отслеживаете игровую серверную сторону продолжительностей.
-
Отклонение или карантинные рекорды от логинов, которые только играли в игру несколько раз, так, чтобы взломщики произвели "документацию" разумно выглядящей игровой игры для каждого входа в систему, который они создают.
-
очки "Heartbeat" во время игровой игры, так, чтобы Ваш сервер видел рост счета за время жизни одной игровой игры. Отклоните рекорды, которые не следуют за разумными кривыми счета (например, спрыгивая от 0 до 999 999).
-
игра "Снимка" указывает во время игровой игры (например, сумма боеприпасов, положения на уровне, и т.д.), который можно позже согласовать против зарегистрированных временных очков. У Вас не должно даже быть способа обнаружить аномалии в этих данных для запуска с; просто необходимо собрать его, и затем можно возвратиться и проанализировать его, если вещи выглядят подозрительными.
-
Отключают учетную запись любого пользователя, который приводит одну к сбою из Ваших проверок безопасности (например, когда-либо отправляя зашифрованный высокий счет, который приводит проверку к сбою).
Помнят, хотя это Вы только удерживаете высокое мошенничество со счетом здесь. Существует ничто , можно сделать, чтобы предотвратить если. Если существуют деньги на строке в Вашей игре, кто-то собирается победить любую систему, которую Вы придумываете. Цель не к остановка это нападение; это должно сделать нападение более дорогим, чем просто получение действительно хорошего в игре и избиении его.
Не действительно возможно достигнуть того, что Вы хотите. Внутренности приложения Flash всегда частично доступны, особенно когда Вы знаете, как использовать вещи как CheatEngine, имея в виду, неважно, как безопасный Ваш веб-сайт и browser<-> связь сервера, все еще будет относительно простым преодолеть.
Я обычно включаю "фантомные данные" игровой сессии с highscore записью. Таким образом, если я делаю мчащуюся игру, я включаю данные воспроизведения. У Вас часто есть данные воспроизведения уже для функциональности воспроизведения или фантома, мчащегося функциональность (играющий против Вашей последней гонки или играющий против фантома чувака № 14 в списке лидеров).
Проверка это очень физический труд, но если цель состоит в том, чтобы проверить, законны ли лучшие 10 записей в конкурсе, это может быть полезным дополнением к арсеналу других мер безопасности уже, указали.
, Если цель состоит в том, чтобы сохранить список highscores онлайн недо конца времени ни с кем имеющим необходимость смотреть на них, это не принесет Вам очень.
Нет никакого способа сделать его абсолютно unhackable, поскольку легко декомпилировать SWFs, и квалифицированный хакер разработчика мог тогда проследить через Ваш код и разработать, как обойти любую зашифрованную систему, которую Вы могли бы использовать.
, Если Вы просто хотите остановить детей, обманывающих через использование простых инструментов как TamperData, хотя, тогда Вы могли генерировать ключ шифрования, который Вы передаете SWF при запуске. Тогда используйте что-то как http://code.google.com/p/as3crypto/ для шифрования высокого счета прежде, чем пасовать назад его к коду PHP. Тогда дешифруйте его в конце сервера прежде, чем сохранить его в базе данных.
Каждый раз, когда Ваша highscore система основана на том, что приложение Flash отправляет unencrpyted/unsigned highscore данные через сеть, которая может быть прервана и управляла/воспроизводила. Ответ следует из этого: зашифруйте (прилично!) или криптографически подписывают highscore данные. Это, по крайней мере, делает его тяжелее для людей для взламывания highscore системы, потому что они должны будут извлечь секретный ключ из файла SWF. Многие люди, вероятно, сдадутся тут же. С другой стороны, все это взятия отдельно человек, чтобы извлечь ключ и отправить его где-нибудь.
Действительные решения включают больше коммуникации между приложением Flash и highscore базой данных так, чтобы последний мог проверить, что данный счет несколько реалистичен. Это, вероятно, сложно в зависимости от того, какую игру Вы имеете.
Вы говорите о том, что называют "клиентской проблемой" доверия. Поскольку клиент (этими наличными, SWF, работающий в браузере), делает что-то, что они разработаны, чтобы сделать. Сохраните высокий счет.
проблема состоит в том, что Вы хотите удостовериться, что "сохраняют счет" запросы, прибывают из Вашего фильма флэш-памяти, и не некоторого произвольного Запроса HTTP. Возможное решение для этого состоит в том, чтобы закодировать маркер, сгенерированный сервером в SWF во время запроса (использующий flasm), который должен сопровождать запрос для сохранения высокого счета. Как только сервер сохраняет тот счет, маркер истекает и больше не может использоваться для запросов.
оборотная сторона этого - то, что пользователь только будет в состоянии отправить один высокий счет на загрузку фильма флэш-памяти - Вы имеете, должны вынудить их обновить/перезагрузить SWF, прежде чем они смогут играть снова для нового счета.
По моему опыту, к этому лучше всего приближаются как проблема социальной инженерии, а не проблема программирования. Вместо того, чтобы фокусироваться на лишении возможности обмануть, сфокусируйтесь на создании его скучный путем удаления стимулов обмануть. Например, если основной стимул является публично видимыми рекордами, просто ставя задержку, когда рекорды показывают, может значительно уменьшить обман путем удаления цикла позитивных откликов для мошенников.
Шифрование использования известного (частного) обратимого ключа было бы самым простым методом. Я не все на AS, таким образом, я не уверен что виды поставщиков шифрования существует.
, Но Вы могли включать переменные как игровая длина (зашифрованный, снова) и количество щелчка.
Все вещи как это могут быть перепроектированными, так полагайте, что добавление набора данных спама бросает людей от аромата.
Редактирование: могло бы стоить отказаться от некоторых сессий PHP также. Запустите сессию, когда они нажимают, запускают игру и (как в комментарии к этому сообщению говорится), регистрируют время. Когда они отправляют счет, можно проверить, что они на самом деле получили открытую игру, и они не отправляют счет слишком скоро или слишком большие.
могло бы стоить решить, что скаляр для наблюдения говорит, что максимальный счет на второй / минута игры.
Ни одна из этих вещей не uncircumventable, но она поможет иметь некоторую логику не в Flash, где люди видят его.
Мне нравится, какие tpqf, сказанные, а скорее, чем отключение учетной записи, когда обман обнаружен, реализуют ловушку поэтому каждый раз, когда они входят в систему, они видят свои взломанные очки и никогда не подозревают, что были отмечены как сообщение-розыгрыш. Google для "Сообщения-розыгрыша phpBB MOD" и Вы будете видеть оригинальный подход.
Простой способ сделать это должно было бы обеспечить криптографический хеш Вашего значения highscore наряду со счетом это сам. Например, когда регистрация результатов через HTTP ДОБИРАЕТСЯ: http://example.com/highscores.php?score=500&checksum=0a16df3dc0301a36a34f9065c3ff8095
При вычислении этой контрольной суммы, общий секрет должен использоваться; этот секрет никогда не должен передаваться по сети, но должен быть трудно кодирован и в бэкенде PHP и во флэш-памяти frontend. Контрольная сумма выше была создана путем предварительного ожидания строки" секрет " к счету" 500 " и выполнения его через md5sum.
, Хотя эта система будет препятствовать тому, чтобы пользователь отправил произвольные очки, она не предотвращает "атаку с повторением пакетов", где пользователь повторно отправляет ранее расчетный счет и комбинацию хеша. В примере выше, счет 500 всегда производил бы ту же строку хеша. Часть этого риска может быть снижена путем слияния большей информации (такой как имя пользователя, метка времени или IP-адрес) в строке, которая должна быть хеширована. Хотя это не предотвратит воспроизведение данных, оно обеспечит, чтобы ряд данных был только допустим для отдельного пользователя в единственное время.
Для предотвращения любой атаки с повторением пакетов от появления некоторый тип системы ответа проблемы должен будет быть создан, такие как следующее:
- флеш-игра ("клиент") работает, HTTP ДОБИРАЮТСЯ [1 118] http://example.com/highscores.php без параметров. Эта страница возвращает два значения: случайным образом сгенерированный соль значение и криптографический хеш того соленого значения, объединенного с общим секретом. Это соленое значение должно быть сохранено в локальной базе данных незаконченных запросов и должно связать метку времени с ним так, чтобы это могло "истечь" после, возможно, одна минута.
- флеш-игра комбинирует соленое значение с общим секретом и вычисляет хеш, чтобы проверить, что это соответствует тому, обеспеченному сервером. Этот шаг необходим для предотвращения подделки в соленые значения пользователями, поскольку это проверяет, что соленое значение было на самом деле сгенерировано сервером.
- флеш-игра комбинирует соленое значение с общим секретом, высоко выиграйте значение и любую другую релевантную информацию (псевдоним, IP, метка времени), и вычисляет хеш. Это тогда передает эту информацию обратно бэкенду PHP через HTTP, ДОБИРАЮТСЯ или POST, наряду с соленым значением, высоким счетом и другой информацией.
- сервер комбинирует информацию, полученную таким же образом как на клиенте, и вычисляет хеш, чтобы проверить, что это соответствует тому, обеспеченному клиентом. Это тогда также проверяет, что соленое значение все еще допустимо, как перечислено в незаконченном списке запросов. Если оба этих условия верны, это пишет высокий счет в высокую таблицу счета и возвращает сообщение "успеха" со знаком клиенту. Это также удаляет соленое значение из незаконченного списка запросов.
имейте в виду, что безопасность любого из вышеупомянутых методов поставилась под угрозу, если общий секрет когда-либо доступен для пользователя
Как альтернатива, части этого назад и вперед можно было избежать, вынудив клиент связаться с сервером по HTTPS и обеспечив, чтобы клиент был предварительно сконфигурирован для доверия только сертификатам, подписанным определенным центром сертификации, к которому у Вас один есть доступ.
Можно задавать неправильный вопрос. Вы кажетесь сфокусированными на людях методов, используют для игр их пути высокий список счета, но блокируются, определенные методы только идет до сих пор. У меня нет опыта с TamperData, таким образом, я не могу говорить с этим.
вопрос, который необходимо задавать: "Как я могу проверить, что отправленные очки допустимы и подлинны?" Особенный метод сделать, который зависим от игры. Для очень простых головоломок Вы могли бы отправить по счету наряду с определенным начальным состоянием и последовательностью перемещений, которые привели к конечному состоянию, и затем повторно выполнили игру на стороне сервера с помощью тех же перемещений. Подтвердите, что установленный счет совпадает с вычисленным счетом, и только примите счет, если они соответствуют.
Новый популярный аркадный мод заключается в том, что он посылает данные с флэш-памяти на php, обратно на флэш-память (или перезагружает ее), а затем обратно на php. Это позволяет вам делать все, что угодно, чтобы сравнить данные, а также обходить post data/decryption hacks и тому подобное. Один из способов сделать это - назначить 2 случайных значения из php на flash (которые вы не можете захватить или увидеть, даже если запущен флэш-граббер данных в реальном времени), используя математическую формулу, чтобы добавить оценку со случайными значениями, а затем проверить ее, используя ту же самую формулу, чтобы перевернуть ее, чтобы увидеть, совпадает ли оценка с ней, когда она, наконец, переходит на php в конце. Эти случайные значения никогда не видны, так же как и время проведения операции, и если оно длится больше пары секунд, то оно также отмечает это как обман, потому что предполагает, что вы остановили отправку, чтобы попытаться вычислить случайные значения или прогнать числа через какой-то шифр, чтобы вернуть возможные случайные значения для сравнения со значением оценки.
Это кажется довольно хорошим решением, если вы спросите меня, видел ли кто-нибудь проблемы с использованием этого метода? Или возможные способы обойти это?