Защита от хакеров

[johannes]

Доброго времени суток всем!
Какие есть варианты защитить многопользовательскую flash-игру от перехвата запросов?
Проблема в следующем: игра работает на SmartFoxServer'е. Появились проблемы с тем, что некто научился перехватывать и подделывать запросы клиента к серверу, тем самым ломая весь ход игры.
Предполагаю, что пользуются они какими-то программами типа Charles или Tamper Data...
Есть ли какие-то методы противодействия этому?

[iflamberg]

Единственный способ - не верить данным игрока. Дублировать все проверки дейсвий клиента на сервере.

[johannes]

краем уха слышал что есть какие-то надстройки для флеша...

не верить данным клиента невозможно, по специфике игры. Количество данных, определяемых клиентом сведены к возможному минимуму

[udaaff]

В идеале вся жизненно важная логика должна лежать на сервере.

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

Не обязательно запрос подделывать, можно и переменные в памяти менять, и байткод вашей игры, вообще изменить при желании в памяти.

Вопрос нужно ставить не только о том как защитить сам код, но и том как верифицировать его на сервере, проверить на валидность.

Могу предложить следующий вариант:
1) Максимально защитить код свиф-файла. Допустим, при помощи программы secureSWF
2) В запросе передавать хэш данных, которые участвуют в вычислении значения, которое вы передаете. Т.е. если, допустим, вы передаете n = a * b - z, то можно вместе с n передавать хэш(n + "_" + a + "_" + b + "_" + z + "какой-то ключ") и значения a, b и z. (secureSWF может шифровать строки (в данном случае ключ) и фиг разбери как она это делает =) ) И далее на сервере уже проверять этот хэш.

Таким образом читеру придется подменить как минимум четыре значения.

От изменения пи-кода это не спасет, но все же обфусцированный код тяжеловато будет разобрать.
Как ни крути, можно лишь усложнить задачу, сделать взлом программы не выгодным (по времени), но 100% защиты никак не добьешься, т.к. код выполняется на клиенте и клиент может сделать с ним все что угодно. А если тут будет какая-то выгода замешана, то нужно забыть о логике на клиенте раз и навсегда.

[iflamberg]

хм... интересно что покажет разработаный _etc getDefinitionNames, если его использовать на загруженную флешку по которой прошлись secureSWF. Интересно, интересно...

[etc]

Покажет, что и должен был показать, имена классов.