Pull to refresh

Comments 22

UFO just landed and posted this here
Ну да, со времён появления видеокарт.
Помню ещё как скриншоты с фильмами через paint смотрели на winxp, повеселее чёрных прямоугольников
В iOS такая же петрушка с OpenGL. Причем, в каждой новой версии рекомендуют свой трюк для получения не черного экрана.
А смысл в стиме это юзать? Там все и так уже есть.
Аргументация? Не хотите вылавливать стимапи и поток видео наружу, ваше право. Но, в общем, если идти по пути ленивого, проще отлавливать трафик стимклиента при трансляциях.
Хотя вопрос был про скриншоты… F12(default), Screenshot, SteamOverlay, в документации почитайте, граждане минусаторы.
Не влепят. Так работает всё ПО для стримов. VAC отправляет неизвестные dll на анализ, только в случае подтверждения что это чит происходит бан.
Интересно. Можно DLL специально написать с ошибками, чтобы она казалась безобидной, но при получении некоторых кривых данных происходило какое-нибудь переполнение и затирание памяти, адрес которой косвенно определялся пакетом данных. На этом и строить чит.
UFO just landed and posted this here
Тот комментарий был приглашением к технической дискуссии на тему «как защищать программы, если необходимо обеспечить совместную работу со сторонними компонентами». Это общая тема, не только в рамках системы Valve.

Часто в комментариях встречаются неожиданные решения, поэтому здесь и интересно.
Проще внедриться в одну из системных библиотек, но активироваться только при выполнении в контексте конкретной игрушки. Маловероятно, что Valve анализируют массу постоянно обновляющихся системных библиотек, которые могут отличаться в зависимости от редакции ОС, локализации или желания левой пятки MS. Или ещё можно использовать виртуализацию и модифицировать непосредственно регистры во время выполнения. В таком случае никаких модификаций кода вообще происходить не будет.
Если это совсем системная библиотека, находящаяся в System32, то Windows File Protection не даст её запатчить. Если библиотеку модифицировать и положить в директорию с игрой, будет заметно, что системная DLL загрузилась не из System32.

Если речь о всяких MSVC Runtime, которые распространяют с приложением, то защита знает точные хеши этих DLL.

Виртуализация не работает без доступа к ядру, а это проблема с приходом обязательной подписи драйверов.
Windows File Protection не даст её запатчить
SfcDisable.
Виртуализация не работает без доступа к ядру
Бред собачий. Виртуализация происходит уровнем ниже, ей по барабану, какую ОС будут запускать в виртуальной машине.
Я подумал, виртуализация такая, как была виртуализация ресурсов для DOS-программ в Windows. Т.е. если программа делает обращение к ресурсу или вызывает какую-то ф-цию, невидимый для неё монитор перехватывает управление, пользуясь средствами отладки CPU.

В любом случае, на этих двух принципах нельзя построить продукт, который было бы не стыдно отдавать другим людям. «Вот мой скринграббер, но работает он только для игр в вирт. машине, или требует разрушить механизмы защиты OS».
Да, это скорее для тех самых скрытых от VAC читов и других весёлых модификаций, которые не должны быть обнаружены пользователем и/или специальным софтом.
Виртуалка для читов плохо подходит из-за снижения производительности, разве что к малодинамичным играм вроде HearthStone.

А SfcDisable требует перезагрузки и подавления системных предупреждений при каждом старте (если речь идёт об особом софте, который юзер не должен заметить).

То есть, варианты рабочие, но не могу согласиться с изначальным посылом «Проще внедриться в одну из системных библиотек».
Если игрушка сетевая, проще научиться снифать трафик конкретного процесса.
А можете подробнее описать, почему используется именно такой метод внедрения в процесс, а не SetWindowsHookEx с хуком WH_CBT?
Если честно — особо не раздумывал над методом, а в чем преимущество SetWindowsHookEx?
На вскидку, преимущество только в использовании стандартного документированного API для инжекта вместо закладки на то, что адрес kernel32.dll будет тот же самый.
Sign up to leave a comment.

Articles