Как работает драйвер NVIDIA для карт-франкенштейнов: обход NVI2, WDDM 3.2 и запуск без тестового режима

2 часа назад Прокомментировать Просмотры: 0

На китайских маркетплейсах, включая AliExpress, уже несколько лет существует необычная категория видеокарт — видеокарты-франкенштейны. Это платы для настольных компьютеров с интерфейсом PCIe, на которые на производстве устанавливают мобильные графические процессоры в корпусе BGA. Среди них встречаются GeForce RTX 3060 Mobile, RTX 3070 Mobile, RTX 2080 Super Mobile и даже профессиональные RTX A3000.

Подобные решения привлекают выгодным сочетанием цены и производительности, однако у них есть существенный недостаток: NVIDIA официально не выпускает драйверы для мобильных GPU, установленных в настольный разъём PCIe.

Если загрузить актуальный драйвер Game Ready с сайта NVIDIA, программа установки сообщит о несовместимости оборудования. А попытка вручную добавить идентификатор устройства в INF-файл приведёт к появлению в Диспетчере устройств хорошо известной «Ошибки 43» (Code 43).

Долгое время основным решением для сообщества оставался FrankenDriver — проект энтузиаста под ником arutar. Его автор проделал большую работу: на протяжении нескольких лет он поддерживал такие платы и выпускал модифицированные сборки драйверов. При этом проект изначально распространялся в виде закрытых бинарных файлов, без общедоступного исходного кода и скриптов сборки, а новые релизы автор перевёл на модель поддержки через Boosty.

Мы решили разобраться: как изнутри устроена модификация современного драйвера NVIDIA? Можно ли автоматизировать сборку на чистом Python, не отключать Secure Boot, сохранить полную совместимость с античитами и при этом предоставить сообществу полностью открытый инструмент?

В статье подробно рассмотрим:

Почему мобильный GPU в настольном компьютере выдаёт «Ошибку 43» и как служебная директива реестра NVIDIA устраняет её без изменения системных бинарных файлов;
Как работает проприетарный установщик NVIDIA NVI2 и как мы столкнулись с ошибкой 0xe0e00059 на чистой Windows 11, исследуя её с помощью дизассемблера;
Как восстановить классическую Win32-панель управления NVIDIA (nvcplui.exe) без Microsoft Store и подключения к интернету;
Как пересобрать и подписать каталог безопасности .cat с меткой времени DigiCert по стандарту RFC3161, чтобы установщик запускался в один клик.

Все исходники проекта, включая открытый скрипт сборки и базу оборудования, доступны на GitHub: OpenFrankenDriver.

1. Как появились видеокарты-франкенштейны и в чём их особенность?

История таких плат началась во время майнинг-бума, когда настольные видеокарты были в остром дефиците. Мобильные графические процессоры GA106 и GA104 изначально не имели аппаратного ограничителя хешрейта LHR (Lite Hash Rate), поэтому китайские производители стали устанавливать мобильные BGA-чипы непосредственно на платы PCIe x16 для настольных ПК. После завершения криптовалютного ажиотажа и смены поколений фабрики продолжили использовать складские запасы чипов для выпуска доступных видеокарт начального игрового уровня.

       [ Десктопная плата PCIe x16 ]
       ┌───────────────────────────────┐
       │   VRM      [ GA104 Mobile ]   │  <-- Ноутбучный BGA-чип без IHS
       │  Питание    (RTX 3070m)       │
       │  ──────    [ GDDR6 VRAM ]     │  <-- 8 ГБ у 3070m (или 6/12 ГБ у 3060m)
       └───────────────────────────────┘

Металлической теплораспределительной крышки (IHS) у такого кристалла нет, поэтому система охлаждения соприкасается непосредственно с кремнием. Однако основная сложность обнаруживается на уровне шины PCIe.

Аппаратный идентификатор (Hardware ID) настольной RTX 3070 выглядит так:

PCI\VEN_10DE&DEV_2484

А идентификатор мобильной RTX 3070 Laptop GPU — так:

PCI\VEN_10DE&DEV_249D&SUBSYS_000010DE

В официальном пакете для настольных ПК чип с ID DEV_249D отсутствует в перечне устройств файла nv_dispi.inf. В мобильном же пакете он привязан к Subsystem ID конкретных производителей ноутбуков, таких как ASUS, Dell и Lenovo. Китайские платы для настольных компьютеров используют универсальный или пустой Subsystem ID (000010DE либо 00000000), поэтому ни один из официальных установщиков не распознаёт видеокарту и выводит сообщение: «Этот графический драйвер не обнаружил совместимого графического оборудования».

2. Природа «Ошибки 43»: зачем обходиться без изменения файлов драйвера

Первое, что приходит в голову энтузиасту, — открыть nv_dispi.inf в текстовом редакторе, найти строку для похожей настольной видеокарты, скопировать её и заменить идентификатор на DEV_249D.

Если после этого установить драйвер в тестовом режиме (testsigning on), Windows сначала сообщит об успехе. Но спустя несколько секунд экран погаснет, драйвер аварийно перезапустится, а в Диспетчере устройств появится жёлтый предупреждающий значок:

«Это устройство было остановлено, поскольку оно сообщило о возникновении неполадок. (Код 43)»

В чём причина?

Столкнувшись с проблемой впервые, можно предположить, что внутри модуля ядра nvlddmkm.sys действует жёсткая проверка оборудования и для её обхода придётся исследовать файл в IDA Pro и изменять машинный код.

Однако архитектура драйверов NVIDIA предлагает более практичный подход. Мобильные GPU рассчитаны на работу в ноутбуках — с соответствующими контроллерами питания, таблицами ACPI и особенностями платформы, включая Optimus и Dynamic Boost. Когда диспетчер ресурсов ядра (Resource Manager, модуль nvlddmkm.sys) запускает мобильный SKU на обычной настольной материнской плате без ожидаемого окружения, проверка топологии завершается неудачей и драйвер сообщает об ошибке инициализации устройства.

В NVIDIA предусмотрели штатный механизм переопределения этой логики для стендовых испытаний. Он активируется служебной директивой реестра:

[nv_miscBase_addreg__01]
HKR,, RM1457588, %REG_DWORD%, 0x00000001

На что указывает HKR? В синтаксисе INF-файлов директива HKR (Relative Root) в секциях AddReg драйвера устройства соответствует ключу реестра конкретного экземпляра оборудования:

HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\<Index>

При запуске устройства процедура инициализации nvlddmkm.sys считывает параметры из этого ключа. Префикс RM обозначает подсистему Resource Manager, а число 1457588 является внутренним идентификатором задачи (Change Request) в системе разработки NVIDIA. Значение RM1457588 = 1 предписывает диспетчеру ресурсов пропустить проверку мобильного профиля платформы.

В nv_dispi.inf предусмотрено несколько секций параметров оборудования для разных микроархитектур: nv_miscBase_addreg__01, 05, 09, 10, 16. Чтобы обеспечить работу Turing (RTX 2060M, 2080 Super Mobile), Ampere (RTX 3060M, 3070M) и Ada Lovelace, скрипт добавляет директиву RM1457588 = 1 в каждую из этих секций.

Одновременно из установочного пакета исключается NVPCF (NVIDIA Platform Controllers and Framework, nvpcf.inf) — ноутбучный фреймворк для контроля температуры и динамического распределения питания между CPU и GPU. На настольной плате без контроллера батареи он не работает и лишь создаёт неопознанные «фантомные» устройства в Диспетчере устройств.

Как это влияет на античиты и зачем нужен субпакет «Enable EAC support»

Главный инженерный вывод состоит в том, что системные бинарные файлы драйвера (nvlddmkm.sys, nvldumdx.dll и другие) полностью сохраняют оригинальное состояние WHQL-файлов NVIDIA.

В модификациях FrankenDriver исторически присутствовал субпакет с названием Enable EAC support. Изучение его манифеста EACSupport.nvi показывает, что внутри находится лишь простой вызов команды:

FOR /D %a in (${{SubPackageDirectory}}\..\*Display.Driver*) do xcopy ${{SubPackageDirectory}}\nv_disp.cat %a /Y

Этот скрипт всего лишь копировал каталог безопасности nv_disp.cat в папки драйвера.

Но почему сетевые игры с античитами уровня ядра — Easy Anti-Cheat (EAC), BattlEye, VAC и другими — работают с таким драйвером без проблем?

Объяснение совместимости опирается на несколько особенностей архитектуры Windows:

Тестовый режим отключён (testsigning off): современные античиты уровня ядра, например EasyAntiCheat.sys и BEDaisy.sys, блокируют запуск игр при загрузке Windows с testsigning on, поскольку этот режим позволяет загружать неподписанные руткиты в ring 0. Наш драйвер работает в обычном защищённом режиме с активным DSE (Driver Signature Enforcement) и включённым Secure Boot.
Файлы ядра не изменены: античит проверяет целостность и цифровую подпись загруженного в память nvlddmkm.sys. Исполняемый код не изменялся, поэтому встроенная официальная подпись Microsoft Windows Hardware Compatibility Publisher (WHQL) сохраняет действительность.
Графические библиотеки остаются оригинальными: библиотеки рендеринга пользовательского режима (nvldumdx.dll, nvd3dumx.dll) сохраняют подписи NVIDIA, и античит не обнаруживает признаков их изменения внутри игрового процесса.

Адаптация оборудования выполняется исключительно через декларативные параметры реестра в INF-файле и не затрагивает защищённый машинный код.

3. Каталог безопасности nv_disp.cat и установка без тестового режима

Системный разработчик под Windows, услышав о модифицированном драйвере без тестового режима, закономерно спросит:
«В 64-битной Windows действует механизм Driver Signature Enforcement (KMCS). Как системе удаётся загрузить изменённый драйвер в ядро без bcdedit /set testsigning on?»

Ответ связан с разделением двух независимых уровней проверки подписи в Windows:

Уровень ядра (Kernel-Mode Code Signing / CI.dll): ядро проверяет цифровую подпись самого исполняемого файла (nvlddmkm.sys), загружаемого в память через NtLoadDriver. Поскольку в nvlddmkm.sys мы не изменили ни одного байта, его встроенная официальная подпись Microsoft WHQL остаётся действительной. Windows загружает файл даже при включённом Secure Boot.
Уровень установщика устройств (SetupAPI / PnP): при развёртывании пакета установщик Windows проверяет целостность INF-файла по каталогу безопасности nv_disp.cat. После изменения nv_dispi.inf его хеш SHA256 уже не совпадает со значением в оригинальном каталоге NVIDIA.

Чтобы SetupAPI принял пакет, необходимо пересобрать каталог безопасности с учётом изменённого nv_dispi.inf и подписать его доверенным сертификатом.

Каталог должен включать криптографические хеши не только INF-файла, но и всех 270+ файлов графического пакета Display.Driver. Скрипт сборки обходит дерево каталогов и формирует файл описания nv_disp.cdf (Catalog Definition File):

[CatalogHeader]
Name=nv_disp.cat
ResultDir=.

[CatalogFiles]
<HASH>nv_dispi.inf=nv_dispi.inf
<HASH>nvlddmkm.sys=nvlddmkm.sys
<HASH>nvd3dumx.dll=nvd3dumx.dll
... (все файлы пакета Display.Driver)

Затем утилита makecat.exe из Windows SDK компилирует бинарный файл .cat:

makecat -v nv_disp.cdf

После этого каталог подписывается сертификатом проекта с обязательной меткой времени RFC3161, полученной через доверенный сервер DigiCert:

signtool sign /f FrankenDriver.pfx /p "password" /fd sha256 /tr http://timestamp.digicert.com /td sha256 nv_disp.cat

Когда открытый ключ сертификата добавлен в системные хранилища локального компьютера (Root — доверенные корневые центры сертификации и TrustedPublisher — доверенные издатели), подсистема PnP SetupAPI признаёт каталог доверенным и устанавливает видеокарту без предупреждающих диалогов. При этом тестовый режим (testsigning) не нужен, а Secure Boot остаётся включённым.

4. Подводные камни NVI2 в Windows 11 (26H2 / 24H2): расследуем ошибку 0xe0e00059

Чтобы избавить пользователя от необходимости открывать certmgr.msc и вручную импортировать сертификат перед установкой, в структуру установщика NVIDIA можно добавить собственный субпакет (SubPackage).

Установщик NVIDIA работает на закрытом движке NVI2 (NVIDIA Installer Core v2). Последовательность установки задаётся деревом XML-манифестов (setup.cfg, Display.Driver.nvi, FrankenDriver.nvi).

Движок NVI2 проверяет цифровые подписи XML-манифестов. Чтобы разрешить добавление собственных субпакетов и изменённого INF, скрипт сборки отключает проверку манифестов в библиотеке пользовательского режима NVI2.dll: заменяет условный переход jz после проверки подписи на jmp и модифицирует функцию-валидатор. Важно: NVI2.dll — временная графическая оболочка мастера установки, которая распаковывается в %TEMP%. После завершения установки она удаляется и к драйверам ядра отношения не имеет.

Мы подготовили субпакет FrankenDriverCert, который перед установкой графического драйвера должен был в фоновом режиме запустить системную утилиту certutil.exe и добавить сертификат в локальные хранилища Root, CA и TrustedPublisher.

В Windows 10 всё прошло успешно. Однако на чистой Windows 11, включая 26H2 и 24H2, установщик через несколько секунд завершился, показав малоинформативный тёмный экран:

«Не удалось установить программное обеспечение NVIDIA»Компонент: Графический драйвер — Не установлено

       ┌────────────────────────────────────────────────────────┐
       │   Программа установки NVIDIA                           │
       │                                                        │
       │   ✖ Не удалось установить программное обеспечение     │
       │                                                        │
       │   Компонент                               Состояние    │
       │   ───────────────────────────────────────────────────  │
       │   Графический драйвер                     Не установлено│
       │   Панель управления NVIDIA (Классическая)  Не установлено│
       └────────────────────────────────────────────────────────┘

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

Шаг 1: изучение журналов

В журнале телеметрии установщика %TEMP%\NvTelemetry.log обнаружилась краткая запись:

{"name":"FrankenDriverCert","version":"2022","installResult":4,"errorCode":"0xe0e00059"}

Что означает 0xe0e00059? В документации Win32 такого значения нет: это внутренний код состояния NVI2.

Шаг 2: исследование NVI2.dll в дизассемблере

Открыв NVI2.dll в декомпиляторе и найдя шестнадцатеричный код 0xE0E00059, мы попадаем в модуль выполнения этапов установки NVAppPhase.cpp:

// Реконструированный псевдокод из NVI2.dll:
HRESULT NVAppPhase::ExecuteCustomExe(PhaseContext* ctx) {
    PROCESS_INFORMATION pi = {0};
    STARTUPINFOW si = { sizeof(si) };
    
    // Формирование командной строки из <arg> тегов манифеста
    std::wstring cmdLine = this->BuildCommandLine(ctx);

    if (!CreateProcessW(NULL, &cmdLine[0], NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi)) {
        DWORD err = GetLastError();
        LogWarning(L"CreateProcess failed: 0x%08X", err);
        return 0xe0e00058; // NV_PHASE_LAUNCH_FAILED
    }

    WaitForSingleObject(pi.hProcess, INFINITE);
    DWORD exitCode = 0;
    GetExitCodeProcess(pi.hProcess, &exitCode);
    CloseHandle(pi.hProcess);
    CloseHandle(pi.hThread);

    if (exitCode != 0) {
        LogError(L"Phase command returned non-zero exit code: 0x%08X", exitCode);
        return 0xe0e00059; // NV_PHASE_EXECUTION_FAILED
    }
    return S_OK;
}

Смысл кода 0xe0e00059 оказался простым: запущенный дочерний процесс завершился с ненулевым кодом возврата (exit code).

Шаг 3: поиск причины

Рассмотрим исходный XML-манифест FrankenDriver.nvi, созданный для запуска certutil:

<exe ... exeName="certutil.exe">
    <arg value="-addstore"/>
    <arg value="Root"/>
    <arg value="&quot;${{SubPackageDirectory}}\FrankenDriver.cer&quot;"/>
</exe>

Выяснилось, что при формировании командной строки парсер аргументов NVI2 передаёт экранированную XML-сущность " в системный вызов CreateProcessW как буквальный символ кавычки.

В результате certutil.exe получала командную строку следующего вида:

certutil -addstore Root "\"C:\Users\...\FrankenDriver.cer\""

В Windows 10 парсер путей Win32 принимал вложенные кавычки, но в более строгом окружении Windows 11 утилита certutil завершалась с критической ошибкой:

0x8007007b (ERROR_INVALID_NAME / «Синтаксическая ошибка в имени файла, имени папки или метке тома»)

Поскольку манифест задавал этот субпакет как зависимость для установки графического драйвера, NVI2 после получения ненулевого кода возврата прерывал всю дальнейшую цепочку развёртывания.

Решение

Мы исправили манифест: удалили буквальные кавычки ", добавили ключ принудительной перезаписи -f, указали атрибут onError="ignore" и настроили мягкий режим развёртывания в setup.cfg:

<exe phase="InstallFrankenDriverCertRoot" onError="ignore" name="${{SystemDirectory}}\certutil.exe" when="install">
    <arg value="-addstore"/>
    <arg value="-f"/>
    <arg value="Root"/>
    <arg value="${{SubPackageDirectory}}\FrankenDriver.cer"/>
    <success value="0"/>
</exe>

После исправления на чистой Windows 11 сертификат импортируется в фоновом режиме за доли секунды, а затем штатно устанавливается графический драйвер.

5. Возвращаем классическую панель Win32 без Microsoft Store

Одна из наиболее досадных особенностей современных драйверов NVIDIA DCH — отсутствие классической панели управления в комплекте.

В соответствии со стандартом Microsoft DCH (Declarative, Componentized, Hardware Support Apps) производители должны распространять пользовательские утилиты настройки как отдельные UWP-приложения через Microsoft Store. Однако на практике возникают сложности:

Многие пользователи работают с Windows 10/11 LTSC или оптимизированными сборками, в которых Microsoft Store отсутствует;
На тестовых и изолированных стендах без интернета приложение из Store недоступно;
Для видеокарт-франкенштейнов UWP-панель из Store нередко не может инициализировать устройство из-за нестандартного Subsystem ID.

Мы решили вернуть привычную быструю панель управления nvcplui.exe непосредственно в состав установщика.

       ┌────────────────────────────────────────────────────────┐
       │   Панель управления NVIDIA                             │
       │   Файл  Правка  Вид  Справка                           │
       │  ┌─────────────────────────┬────────────────────────┐  │
       │  │ Выбор задачи...         │ Регулировка настроек   │  │
       │  │ ├─ Параметры 3D         │ изображения с просмот- │  │
       │  │ │  ├─ Управление 3D     │ ром                    │  │
       │  │ ├─ Дисплей              │                        │  │
       │  │ │  ├─ Изменение разреш. │ [ Настройки 3D ]       │  │
       │  │ └─ Видео                │                        │  │
       │  └─────────────────────────┴────────────────────────┘  │
       │   Версия драйвера: 621.14 WHQL                         │
       └────────────────────────────────────────────────────────┘

Любопытно, что NVIDIA по-прежнему включает нативные исполняемые файлы панели в официальный дистрибутив: они находятся внутри архива Display.Driver\NVCPL\*.appx. Поскольку .appx — обычный ZIP-контейнер, его можно распаковать программно.

Наш процесс сборки автоматизирует следующие действия:

Из контейнера AppX извлекаются нативные файлы (nvcplui.exe, nvcpluir.dll, nvImage.dll, NvGpuUtilization.exe), после чего скомпилированный вспомогательный модуль install_helper.exe копирует их в системную папку: C:\Program Files\NVIDIA Corporation\Control Panel Client\
В системный реестр добавляется директива, разрешающая классический интерфейс с DCH-драйвером:
```
[HKLM\SYSTEM\CurrentControlSet\Services\nvlddmkm\Parameters\Global\NVTweak]
"EnableNvcplUIOnDCH"=dword:00000001

[HKLM\SOFTWARE\NVIDIA Corporation\Global\NVTweak]
"EnableNvcplUIOnDCH"=dword:00000001
```
Флаг EnableNvcplUIOnDCH = 1 сообщает библиотекам NVIDIA CPL, что классический интерфейс Win32 можно запускать совместно с современным DCH-драйвером;
Модуль install_helper.exe с помощью интерфейсов Windows Shell (IShellLinkW, IPersistFile) создаёт ярлыки в меню «Пуск» и на общем рабочем столе (CSIDL_COMMON_DESKTOPDIRECTORY), корректно привязывая значок nvcplui.exe,0.

Панель запускается мгновенно, работает автономно без подключения к сети и позволяет управлять G-Sync, профилями 3D-графики, фильтрацией текстур и пользовательскими разрешениями.

6. Секция 26200 (WDDM 3.2) и поддержка 71 аппаратной конфигурации

В актуальных версиях Windows 11, начиная с 24H2 и включая 26H2, Microsoft обновила модель видеодрайверов до WDDM 3.2. Для разграничения логики разных поколений ОС в nv_dispi.inf используются секции с номерами сборок:

[NVIDIA_Devices.NTamd64.10.0...17134] — секция для Windows 10, начиная с Redstone 4 / 1803, и ранних выпусков Windows 11;
[NVIDIA_Devices.NTamd64.10.0...26200] — секция для Windows 11 24H2, 26H2 и последующих выпусков (сборки 26100, 26200+).

Механизм PnP SetupAPI работает следующим образом: обнаружив в INF-файле секцию с номером сборки, наиболее точно соответствующим текущей версии Windows (в данном случае 26200), система ищет Hardware ID только внутри этой секции. Если добавить видеокарту лишь в старую секцию ...17134, установщик на чистой Windows 11 24H2 или 26H2 сообщит, что совместимое оборудование не обнаружено.

Мы собрали сведения об известных видеокартах-франкенштейнах в декларативную базу data/devices.json. Сейчас она включает 71 конфигурацию, распределённую между обеими секциями:

RTX 3070 Mobile (DEV_249D со всеми вариантами Subsystem: 000010DE, 00000000 и пустыми масками);
RTX 3060 Mobile (DEV_2520, DEV_2560);
RTX 3060M 12GB (GA106 VRAM-mod) — платы, на которых китайские фабрики заменили память на 12 ГБ Samsung; используется нестандартный идентификатор PCI\VEN_10DE&DEV_2521&SUBSYS_000010DE;
RTX A3000 Mobile (DEV_24B8) — мобильные ускорители профессионального класса;
Серия RTX 20 Mobile (Turing): RTX 2080 Super Mobile (DEV_1E93), RTX 2060 Mobile (DEV_1F11 / DEV_1F15) и другие модели;
Первые представители RTX 40 Mobile: мобильные чипы Ada Lovelace на настольных платах (RTX 4060 Laptop GPU DEV_2820 / DEV_2860).

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

7. Автоматизация: открытый сборщик на Python

Чтобы снизить влияние человеческого фактора и не повторять одни и те же операции вручную при каждом ежемесячном обновлении драйверов NVIDIA, мы создали автоматический скрипт сборки: scripts/build.py.

Процесс сборки устроен следующим образом:

[ Официальный драйвер NVIDIA .exe ]
                │
                ▼
   1. Распаковка архива payload
                │
                ▼
   2. Парсинг data/devices.json и модификация nv_dispi.inf
      (внедрение 71 модели в секции 17134 и 26200 + фикс RM1457588)
                │
                ▼
   3. Генерация nv_disp.cdf и сборка каталога makecat
      (хеширование всех 270+ файлов Display.Driver)
                │
                ▼
   4. Подпись nv_disp.cat через signtool (SHA256 + RFC3161 DigiCert)
                │
                ▼
   5. Интеграция классической панели управления nvcplui.exe
                │
                ▼
   6. Настройка манифеста NVI2 (тихий импорт сертификата)
                │
                ▼
   7. Упаковка в монолитный установщик (SFX)

Для сборки достаточно установить Python и выполнить команду:

python scripts/build.py --nvidia-exe "621.14-desktop-win10-win11-64bit-international-dch-whql.exe"

Работа скрипта занимает 2–3 минуты. Отдельного внимания заслуживает создание итогового монолитного .exe: официальный установщик NVIDIA представляет собой модифицированный 7-Zip SFX. Чтобы сохранить фирменный интерфейс распаковки, скрипт:

Считывает оригинальный PE-загрузчик SFX — первые 1,12 МБ официального файла;
С помощью библиотеки pefile обнуляет поля VirtualAddress и Size в IMAGE_DIRECTORY_ENTRY_SECURITY заголовка PE Optional Header. Это удаляет из PE-загрузчика старую цифровую подпись NVIDIA, которая иначе вызвала бы ошибку повреждённой подписи после объединения с новым архивом;
Сжимает изменённое дерево файлов в поток LZMA2 с уровнем сжатия 9 и объединяет загрузчик с полученным архивом;
Подписывает готовый монолитный .exe с помощью signtool, добавляя метку времени RFC3161 DigiCert.

В результате получается единый исполняемый файл, который внешне и по поведению не отличается от официального установщика NVIDIA.

Исходный код и готовые сборки

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

Репозиторий проекта на GitHub: lnp/OpenFrankenDriver
Готовый протестированный установщик 621.14: Релиз v621.14.1
Перечень всех 71 поддерживаемых видеокарт: docs/SUPPORTED_DEVICES.md
Руководство по самостоятельной сборке: docs/HOW_TO_BUILD.md

Если у вас без дела лежит такая видеокарта или вам интересно устройство экосистемы графических драйверов современной Windows, загляните в репозиторий, попробуйте проект и поделитесь результатами!

Источник