Столкнулся со специфичной проблемой безопасности при написании аддона для WoW.
ПО состоит из трёх уровней:
  1. Сам аддон, Lua.
  2. Клиент, Java.
  3. Веб-сервис.
Аддон (1) создаёт и поддерживает лог на компьютере игрока. Лог содержит рекорды и игровую статистику. Клиент (2) читает созданный аддоном лог и посылает…
Вопрос
7 2.3K
22
все обращения к WoW API придется оставить не обфусцированными
Я как-то упустил этот момент. Благодарю за наводку.
обфускация имееет смысл только на больших объемах кода
Попробую декларировать десяток другой чуши в исходнике.
Закрою вопрос когда закончу с реализацией; пару недель. Спасибо за помощь.
24
Zahanc:
Вариант с md5 хешем каждой записи или всего лога позволит остановить часть хомячков с той-же надежностью, что и "шифрование" xor-ом - оба способа одинаково обходятся заглянув в код Lua.
Обеспечить одинаковую работу рандома достаточно просто - там же на самом деле псевдорандом и seed видоизменяется после каждой операции заранее заданым способом - достаточно обеспечить одинаковость этой операции и рандом будет выдавать одинаковые значения хоть на джаве, хоть на брейнфаке. Другое дело что это так-же бесполезно, как и хеш данных - обходится идентично за счет доступа к Lua-имплементации в открытом виде.
обфускатор штука хорошая и задержит небольшое кол-во хомяков, но во-первых все обращения к WoW API придется оставить не обфусцированными, а во вторых обфускация имееет смысл только на больших объемах кода - иначе найти нужное место в коде не составит большого труда.
22
Я тоже думаю в этом направлении. Вот только не могу придумать как это сделать точно.
Я рассуждал, мол, каждая запись в лог сопровождается 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. Не могу проверить прямо сейчас.
24
Zahanc, есть простое решение, которое остановит часть хомяков - запилить свой алгоритм рассчета хеша на основе данных и писать этот хеш тоже в лог, тогда тупые изменения файла данных уже ничего не дадут т.к. надо будет пересчитывать хеш как-то, а клиент сможет на основе данных проверять валидность хеша
но это не спасет от возможности подсмотреть алгоритм генерации хеша и/или шифрования и воспользоваться этими знаниями в своих целях, вплоть до использования скопированного оттуда кода хеширования/шифрования для автоматической генерации данных в том формате в каком их ожидает клиент
и я даже не говорю о возможности декомпиляции клиента - это не уровень хомячков
22
Вся идея состоит в том, чтобы собирать данные с компьютеров игроков и аггрегировать их на сервере. И я не могу посылать запросы в Веб напрямую из игры (Lua), поэтому нужен отдельный клиент (2).
Аддон (1), который Lua, лишь слушает события в игре и пишет лог. Клиент (2) который читает лог написан на Java, следовательно компилируется.
prog,
Если аддон Lua модифицирован, скажем токен заменён, я ожидаю клиент Java заметить и отвергнуть лог.
Кстати да, я ведь могу клиентом (Java) проверять hash файла Lua. Таким образом можем исходить из того, что Lua не изменяем.
24
А разве Lua-аддоны нынче уже можно компилировать или они по прежнему в текстовом виде? Если второе - любая система шифрования бесполезна т.к. отредактировать код аддона не сложнее, чем подменить содержимое лога, а значит данные будут скомпрометированы еще до шифрования.
Не работает как надо, не выводит ничего на доску и игра заканчивается после первого хода. Пробовала всё из play перекинуть в main, но тогда выводятся только нолики. Уже даже не знаю как мне быть
""
#include <iostream>
#include <Windows.h>
using namespace std;
char board[9] = {'-','-', '-', '-', '-', '-', '-',…
Вопрос
10 5.6K
15
Doc, именно так и было. Мне лично удобнее сразу по ходу дебага записывать результаты и смотреть, проходит ли работа по задуманному мною сценарию. То есть по ходу работы программы я еще и сам просчитываю ее на листке, чтобы убедиться, что все в коде происходит верно. Если же нет, я помечаю для себя проблемное место, обдумываю как пофиксить, фикшу, снова дебажу и так до тех пор, пока моя программа не будет работать верно.
29
По-моему он все же имел в виду работу с дебаггером, а ручку с листочком только как вспомогательное.
28
Meddin, разжигать огонь можно изи с помощью трения палки об палку
вот только всё же лучше использовать зажигалку или спички
вариант листочек с ручкой в основном используют студенты в лабах когда надо сдать и забыть ибо лень учиться как делать по нормальному
или если в языке нету нормальных средств отлова ошибок для записи их в лог (например jass)
у большинства прогеров по умолчанию в дебаг версии включена запись лога
да и в релизной тоже