Аутентификация с нуля. Предотвратить подмену записей.

Столкнулся со специфичной проблемой безопасности при написании аддона для WoW.
ПО состоит из трёх уровней:
  1. Сам аддон, Lua.
  2. Клиент, Java.
  3. Веб-сервис.
Аддон (1) создаёт и поддерживает лог на компьютере игрока. Лог содержит рекорды и игровую статистику. Клиент (2) читает созданный аддоном лог и посылает команды веб-сервису (3).
Проблема в том, что лог это лишь открытый текстовый файл. Сколько нибудь грамотный игрок легко может подменить записи.
Вопрос: как предотвратить подмену записей?
Мои рассуждения следуют.
  • Я знаю, что использую WoW API аддонов не по назначению. Аддоны предназначены для расширения клиента и никак не для Web. И всё-таки?
  • Я знаю, что одно из правил гласит, что если злоумышленник получил секретные файлы, даже если они зашифрованы, то информация уже скомпрометирована. Я не пытаюсь сделать совершенно безопасную систему. Достаточно лишь чтобы среднестатистический игрок, ничего не знающий о компьютерах, не мог "скормить" веб-сервису любую информацию.
  • Говоря о решении. Я могу вообразить что нужен какой-то токен. Вроде как заставить аддон и клиент генерировать случайные хэши используя одно и тоже семя (seed), и чтобы клиент сопоставлял генерированные хэши когда читает лог. Проблема здесь главным образом в разнице в реализации алгоритмов: аддон написан на Lua, клиент на Java. RNG выдаст разные числа даже с идентичным семенем.



Views: 1 618

Doc #1 - 4 years ago 0
Голосов: +0 / -0
Держать данные на сервере.
prog #2 - 4 years ago 0
Голосов: +0 / -0
А разве Lua-аддоны нынче уже можно компилировать или они по прежнему в текстовом виде? Если второе - любая система шифрования бесполезна т.к. отредактировать код аддона не сложнее, чем подменить содержимое лога, а значит данные будут скомпрометированы еще до шифрования.
Zahanc #3 - 4 years ago (изм. ) 0
Голосов: +0 / -0
Doc,
Вся идея состоит в том, чтобы собирать данные с компьютеров игроков и аггрегировать их на сервере. И я не могу посылать запросы в Веб напрямую из игры (Lua), поэтому нужен отдельный клиент (2).
Аддон (1), который Lua, лишь слушает события в игре и пишет лог. Клиент (2) который читает лог написан на Java, следовательно компилируется.
prog,
Если аддон Lua модифицирован, скажем токен заменён, я ожидаю клиент Java заметить и отвергнуть лог.
Кстати да, я ведь могу клиентом (Java) проверять hash файла Lua. Таким образом можем исходить из того, что Lua не изменяем.
prog #4 - 4 years ago (изм. ) 0
Голосов: +0 / -0
Zahanc, есть простое решение, которое остановит часть хомяков - запилить свой алгоритм рассчета хеша на основе данных и писать этот хеш тоже в лог, тогда тупые изменения файла данных уже ничего не дадут т.к. надо будет пересчитывать хеш как-то, а клиент сможет на основе данных проверять валидность хеша
но это не спасет от возможности подсмотреть алгоритм генерации хеша и/или шифрования и воспользоваться этими знаниями в своих целях, вплоть до использования скопированного оттуда кода хеширования/шифрования для автоматической генерации данных в том формате в каком их ожидает клиент
и я даже не говорю о возможности декомпиляции клиента - это не уровень хомячков
Zahanc #5 - 4 years ago 0
Голосов: +0 / -0
Я тоже думаю в этом направлении. Вот только не могу придумать как это сделать точно.
Я рассуждал, мол, каждая запись в лог сопровождается md5 хэшем: токен+данные записи. Клиент пересчитывает хэш во время чтения и сопоставляет. Вот только токен можно подсмотреть в исходниках Lua, так что это не работает.
Между прочим понял что неизменяемость файла Lua не играет роли. Враг может скопировать Lua, модифицировать копию и таким образом воспроизвести любую логику.
Когда думал писать свой алгоритм, то упираюсь в разницу в имплементации. Можно ли как-то гарантировать что RNG будет вести себя одинаково в Java и Lua?
+
Наверное буду "шифровать" XOR'ом или что-то вроде. Чтобы нужно было-бы по крайней мере понимать Lua, чтобы понять что происходит.
+
Lua таки можно компилировать в байткод: www.lua.org/manual/4.0/luac.html Проверял на luac53. Вот только WoW не загружает такие файлы (ожидаемо). Может ещё что раскопаю.
К тому же существуют obfuscator'ы. Не могу запустить ни один, правда.
+
Рабочий obfuscator: github.com/jkusner/LuaObfuscator Не уверен работает ли он с 30300 WoW API. Не могу проверить прямо сейчас.
prog #6 - 4 years ago 0
Голосов: +0 / -0
Zahanc:
Вариант с md5 хешем каждой записи или всего лога позволит остановить часть хомячков с той-же надежностью, что и "шифрование" xor-ом - оба способа одинаково обходятся заглянув в код Lua.
Обеспечить одинаковую работу рандома достаточно просто - там же на самом деле псевдорандом и seed видоизменяется после каждой операции заранее заданым способом - достаточно обеспечить одинаковость этой операции и рандом будет выдавать одинаковые значения хоть на джаве, хоть на брейнфаке. Другое дело что это так-же бесполезно, как и хеш данных - обходится идентично за счет доступа к Lua-имплементации в открытом виде.
обфускатор штука хорошая и задержит небольшое кол-во хомяков, но во-первых все обращения к WoW API придется оставить не обфусцированными, а во вторых обфускация имееет смысл только на больших объемах кода - иначе найти нужное место в коде не составит большого труда.
Zahanc #7 - 4 years ago 0
Голосов: +0 / -0
все обращения к WoW API придется оставить не обфусцированными
Я как-то упустил этот момент. Благодарю за наводку.
обфускация имееет смысл только на больших объемах кода
Попробую декларировать десяток другой чуши в исходнике.
Закрою вопрос когда закончу с реализацией; пару недель. Спасибо за помощь.