Как не видел смысла в интерфейсах, так и не вижу. Там где нужна та или иная реализация в классе, она там и будет. Даже если несколько объектов, должны уметь делать что-то одно, это будет объявлено и без интерфейсов.
Столкнулся со специфичной проблемой безопасности при написании аддона для WoW.
ПО состоит из трёх уровней:
Сам аддон, Lua.
Клиент, Java.
Веб-сервис.
Аддон (1) создаёт и поддерживает лог на компьютере игрока. Лог содержит рекорды и игровую статистику. Клиент (2) читает созданный аддоном лог и посылает…
Zahanc:
Вариант с md5 хешем каждой записи или всего лога позволит остановить часть хомячков с той-же надежностью, что и "шифрование" xor-ом - оба способа одинаково обходятся заглянув в код Lua.
Обеспечить одинаковую работу рандома достаточно просто - там же на самом деле псевдорандом и seed видоизменяется после каждой операции заранее заданым способом - достаточно обеспечить одинаковость этой операции и рандом будет выдавать одинаковые значения хоть на джаве, хоть на брейнфаке. Другое дело что это так-же бесполезно, как и хеш данных - обходится идентично за счет доступа к Lua-имплементации в открытом виде.
обфускатор штука хорошая и задержит небольшое кол-во хомяков, но во-первых все обращения к WoW API придется оставить не обфусцированными, а во вторых обфускация имееет смысл только на больших объемах кода - иначе найти нужное место в коде не составит большого труда.
Я тоже думаю в этом направлении. Вот только не могу придумать как это сделать точно.
Я рассуждал, мол, каждая запись в лог сопровождается 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. Не могу проверить прямо сейчас.
Zahanc, есть простое решение, которое остановит часть хомяков - запилить свой алгоритм рассчета хеша на основе данных и писать этот хеш тоже в лог, тогда тупые изменения файла данных уже ничего не дадут т.к. надо будет пересчитывать хеш как-то, а клиент сможет на основе данных проверять валидность хеша
но это не спасет от возможности подсмотреть алгоритм генерации хеша и/или шифрования и воспользоваться этими знаниями в своих целях, вплоть до использования скопированного оттуда кода хеширования/шифрования для автоматической генерации данных в том формате в каком их ожидает клиент
и я даже не говорю о возможности декомпиляции клиента - это не уровень хомячков
PROGRAMMS
Комментарии проекта Программирование
Выбор редакции
Интерфейсы и с чем их едят
Ред. Эргалон
Аутентификация с нуля. Предотвратить подмену записей.
Вариант с md5 хешем каждой записи или всего лога позволит остановить часть хомячков с той-же надежностью, что и "шифрование" xor-ом - оба способа одинаково обходятся заглянув в код Lua.
+
Наверное буду "шифровать" XOR'ом или что-то вроде. Чтобы нужно было-бы по крайней мере понимать Lua, чтобы понять что происходит.
+
Lua таки можно компилировать в байткод: www.lua.org/manual/4.0/luac.html Проверял на luac53. Вот только WoW не загружает такие файлы (ожидаемо). Может ещё что раскопаю.
К тому же существуют obfuscator'ы. Не могу запустить ни один, правда.
+
Рабочий obfuscator: github.com/jkusner/LuaObfuscator Не уверен работает ли он с 30300 WoW API. Не могу проверить прямо сейчас.
Ред. prog