Denuvo Software SolutionsСамое важное: вопреки устоявшемуся мнению, DENUVO НЕ является новой разработанной современной супер-современной защитой! На самом деле, за логотипом DENUVO скрывается обычный Российский VMProtect, с незначительными различиями (эдакий форк). Мифическая "крутость этой защиты" заключалась в отсутствии хорошего отладчика для отладки x64 (64 разрядных исполняемых PE файлов): всеми обожаемый OllyDbg работает только на x86 (32-разрядных) платформах, а версия x64 до сих пор не выпущена. Единственным более менее подходящим отладчиком остаётся x64dbg, но на момент появления DENUVO, он представлял страшно забагованный, слабый и плохо-оптимизированный продукт. Однако сам денуво и дал огромный толчок в развитии отладчика x64dbg! Теперь чуть более подробно:
- DENUVO = VMProtectЭто превосходно видно, если сравнить виртуальные машины обоих продуктов. От Lords of Fallen до Just Cause™ 3 - VMProtect 2.0 (2.x). Определено по наличию зашифрованной dispatch-table. Начиная с Just Cause™ 3 разработчики денуво поняли свой эпичный прокол и выкинули dispatch-table из виртуальной машины, переместив delta-смещения в ленту p-code, соответственно тем самым мы имеем перед собой уже современный VMProtect 3.x. Кроме копирования виртуальной машины, DENUVO полностью копирует у VMProtect обфускацию кода. Также сюда стоит добавить тот факт, что известная утилита ProtectionID определяла на первых порах DENUVO, как VMProtect 2.x, что как-бы намекает. Знаковое событие также произошло с Assassin's Creed Syndicate - он использует ... VMProtect! А почему не DENUVO?! Очевидно, в Ubisoft кое что знали и решили не переплачивать за нашумевший бренд. Правда, от "взлома за пару минут" это не спасло.
- Кто разработал DENUVO?Denuvo Software Solutions GmbH. г. Зальцбург, Австрия (НЕ путать с Австралией). Официально, это Рейнгард Блаукович (Reinhard Blaukovitsch) и Роберт Фендандез (Robert Hernandez). Первый, это не кто иной, как бывший разработчик SecuROM (Sony DADC Austria AG - тоже Австрия). Однако официальная информация вызывает большие сомнения - скорее всего, к разработке DENUVO привлечены лица из конторы VMProtect Software. Слишком уж разный стиль программирования между SecuROM и DENUVO. К тому же, удивляет факт: в виртуальной машине последних версий SecuROM 8 (8.03.012) разработчики сами же отказались от dispatch-table, а в первых версиях DENUVO она, внезапно, всплывает снова! Ещё раз наступили на свои же грабли?!
- DENUVO - DRM?В прямом смысле DENUVO не является DRM. Не может он проверять диски и производить онлайн-активацию, как это было в SecuROM. Да и не к чему - всё равно и проверка дисков, и онлайн-активация, что у SecuROM, что у StarForce успешно разобраны и взломаны. DENUVO (VMProtect) просто защищают файл от модификации. Причем DENUVO больше ориентирован на использование со Steam/Origin.
- DENUVO (VMProtect) реально взломать?Как и любую другую защиту - ДА! Конечно! Вопрос во времени и затраченных усилиях. Сейчас всё вертится вокруг эмуляции Steam/Origin, которые защищаются DENUVO. Эмулировать их просто + махинации с CPUID для DENUVO. Но, скорее всего, тенденция будет смещаться на унвиртуализацию самой виртуальной машины. Да, это конечно не секуромовская виртуальная машина, где была эталонная "изи катка" - но тем не менее, VMProtect'у не первый год и, уверен, задача эта решаема.
- DENUVO (VMProtect) крайне пагубно влияет на производительность и оптимизацию игрПодумаете сами - если даже без DENUVO(VMProtect) многие современные игры требуют мощные процессоры и быструю память, то с наличием защиты всё ещё хуже! Вся проблема как раз в виртуальной машине - виртуализация кода через её примитивы сама по себе выполняется слишком уж медленно. И пусть у Вас будет самый мощный i7 - даже он физически не справится быстро с перевариванием виртуальной машины, ибо это новый уровень абстракции и не помогут тут огромный кэш и тактовая частота процессора. Если, к примеру, одна ассемблерная инструкция занимает один такт процессора, то её исполнение под виртуальной машиной кол-во тактов вырастает на несколько миллионов(!!!). Здесь счет идёт уже на секунды, а не на такты! Ситуацию усугубляет сама платформа x64:
- Длина ассемблерных инструкций увеличивается почти в два раза (в сравнении с x86).
- Виртуальной машине нужно в два раза более времени, чтобы сохранить и обработать регистры процессора (от RAX до R15)
- Примитивы виртуальной машины плодятся сотнями
- Ленты p-code (байт-код) теперь занимают больше места, чем ассемблерный код самой игры!!!
В итоге, файлы защищенные DENUVO (VMProtect) "весят" уже более сотни мегабайт. Однако, если откинуть многочисленные примитивы виртуальной машины и километровые ленты байт-кода, то в остатке мы получим не более 15-30 Мб кода игрушки.
- "Скинул кряк к DENUVO, однако игра висит пару секунд в процессах и не запускается" (Steam)Действительно, DENUVO (VMProtect) хранит гробовое молчание об ошибках - и узнать в чём дело можно только ковырнув отладчиком. Разработчики кряков не удосужились проинформировать общественность, что для Steam в DENUVO идёт ещё небольшая проверка существования ветки HKEY_CURRENT_USER\Software\Valve. Соответственно есть два способа решить эту мелкую неприятность: Просто установить себе Steam или создать в реестре указанную ветку:
Код
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Valve]
[HKEY_CURRENT_USER\Software\Valve\Steam]
"Language"="russian"
"SteamInstaller"="SteamSetup.exe"
"SteamExe"="c:/program files (x86)/steam/steam.exe"
"SteamPath"="c:/program files (x86)/steam"
"SuppressAutoRun"=dword:00000000
"Restart"=dword:00000000
"BigPictureInForeground"=dword:00000000
[HKEY_CURRENT_USER\Software\Valve\Steam\ActiveProcess]
"SteamClientDll"="C:\Program Files (x86)\Steam\steamclient.dll"
"SteamClientDll64"="C:\Program Files (x86)\Steam\steamclient64.dll"
"Universe"="Public"
"pid"=dword:00000000
Такое впечатление, что разработчики насмотрелись на один классный DOS'вский вирус под названием "OneHalf".
Куча дисков со старфорсом, ни один лазер в процессе игр не сдох. Даже во времена старфорса таких баек не было, сейчас-то зачем их придумывать.
Пока не понял что да как...
