Предотвратить впрыск winsock с обходом MS
Я где-то читал код, который обещает защитить приложения Winsock от редакторов пакетов.
Я запускаю игровой сервер, и это действительно хорошая новость для меня. Но возможно ли это на самом деле?
Как добавить DLL с использованием обходных путей в исполняемый файл моей игры, который защитит мои функции winsock от взлома?
Например, если они подключат редактор пакетов к моему приложению, они ничего не увидят при регистрации пакетов?
Или лучше скрыть процесс моего приложения от таких инструментов?
Спасибо. Пожалуйста, обсудите.
Код, который я нашел: http://pastebin.com/XtfSHxBL
Решение
Если бы вы добавили такой код в вашу игру, я бы просто НЕ УЗНАЛ ее;)
Преодолей это.
Клиент НЕ является безопасным, и никогда не может быть доверенным.
Кроме того, я мог бы просто переключаться между маршрутизаторами linux и захватывать пакеты там ..
Если вы не хотите, чтобы ваши данные winsock были захвачены, вам нужно зашифровать их с помощью хорошего ассиметричного алгоритма шифрования, такого как PGP, и до того, как данные будут отправлены в winsock.
Лучше было бы использовать isdebuggerpresent, чтобы закрыть программу, если это правда.
Но тогда вам нужно зашифровать исполняемый файл, потому что иначе я бы просто разобрал его с IDA и либо исправил isdebuggerpresent для NOP, либо 0xe9 с возвратом false через createremotethread во время выполнения, что случайно не было бы обнаружено при проверке контрольной суммы файла ,
Однако, таким образом, вы все равно будете уязвимы, если я перехватываю функцию WinAPI isdebuggerpresent и не выполняю ее. Это то, что может быть достигнуто с обходами MS также;)
Другие решения
Что-нибудь подобное будет тривиально обойти. Сосредоточьтесь на защите реального протокола, используйте шифрование, проверяйте все на стороне сервера.
Я бы написал это в комментарии, но, видимо, для этого нужна репутация.
Возможно, в некоторой степени. Однако ничто не остановит постоянного хакера.
Одна возможность, которую я помню (потому что я исследовал атаку на этот «безопасный» импорт функций), использовалась средой выполнения .NET для защиты от перехвата функций чтения / открытия реестра (по соображениям безопасности, связанным с CAS).
По сути, они решили жестко связать адреса функций, указав прямые адреса для нескольких вариантов окон (несколько пакетов обновления). Очевидно, что это то, что вы можете делать опытно, только если вы являетесь MS (вы исправляете advapi32, меняя адрес функций Reg *? Вы также отправляете исправление mscoree).
Это затрудняет перехват и перехват этих функций (по крайней мере, сложнее, чем просто использование IAT), но, как я уже сказал, я обнаружил, как это было сделано, исследуя атаку, так что …
С Detour вы все еще используете IAT, но вы можете проверить, если кто-то возился с ним, и «восстановить» (переписать) исходный адрес. Или, по крайней мере, проверить это. Это то, что делал Punkbuster, IIRC. Имейте в виду, это доказывает, что нет ничего лучше защищенного клиента (люди понимали, что делает PB -> они его обошли).