Скриншотим игры — the hard way

[@odiszapc]

ms-rem жив!

[@mouse887]

Ну да, со времён появления видеокарт.

[@Denai]

Помню ещё как скриншоты с фильмами через paint смотрели на winxp, повеселее чёрных прямоугольников

[@PapaBubaDiop]

В iOS такая же петрушка с OpenGL. Причем, в каждой новой версии рекомендуют свой трюк для получения не черного экрана.

[@romanshuvalov]

VAC-бан за такие вещи не влепят?

[@Wedmer]

А смысл в стиме это юзать? Там все и так уже есть.

[@Wedmer]

Аргументация? Не хотите вылавливать стимапи и поток видео наружу, ваше право. Но, в общем, если идти по пути ленивого, проще отлавливать трафик стимклиента при трансляциях.
Хотя вопрос был про скриншоты… F12(default), Screenshot, SteamOverlay, в документации почитайте, граждане минусаторы.

[@bak]

Не влепят. Так работает всё ПО для стримов. VAC отправляет неизвестные dll на анализ, только в случае подтверждения что это чит происходит бан.

[@qw1]

Интересно. Можно DLL специально написать с ошибками, чтобы она казалась безобидной, но при получении некоторых кривых данных происходило какое-нибудь переполнение и затирание памяти, адрес которой косвенно определялся пакетом данных. На этом и строить чит.

[@qw1]

Тот комментарий был приглашением к технической дискуссии на тему «как защищать программы, если необходимо обеспечить совместную работу со сторонними компонентами». Это общая тема, не только в рамках системы Valve.

Часто в комментариях встречаются неожиданные решения, поэтому здесь и интересно.

[@Sadler]

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

[@qw1]

Если это совсем системная библиотека, находящаяся в System32, то Windows File Protection не даст её запатчить. Если библиотеку модифицировать и положить в директорию с игрой, будет заметно, что системная DLL загрузилась не из System32.

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

Виртуализация не работает без доступа к ядру, а это проблема с приходом обязательной подписи драйверов.

[@Sadler]

Windows File Protection не даст её запатчить

SfcDisable.

Виртуализация не работает без доступа к ядру

Бред собачий. Виртуализация происходит уровнем ниже, ей по барабану, какую ОС будут запускать в виртуальной машине.

[@qw1]

Я подумал, виртуализация такая, как была виртуализация ресурсов для DOS-программ в Windows. Т.е. если программа делает обращение к ресурсу или вызывает какую-то ф-цию, невидимый для неё монитор перехватывает управление, пользуясь средствами отладки CPU.

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

[@Sadler]

Да, это скорее для тех самых скрытых от VAC читов и других весёлых модификаций, которые не должны быть обнаружены пользователем и/или специальным софтом.

[@qw1]

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

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

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

[@Wedmer]

Если игрушка сетевая, проще научиться снифать трафик конкретного процесса.

[@zodiac]

А можете подробнее описать, почему используется именно такой метод внедрения в процесс, а не SetWindowsHookEx с хуком WH_CBT?

[@bak]

Если честно — особо не раздумывал над методом, а в чем преимущество SetWindowsHookEx?

[@boov]

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