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

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


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

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

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

В этой статье мы подробно разберем:

  1. Почему мобильный чип в десктопе ловит «Ошибку 43» и как служебная директива реестра NVIDIA снимает её без патчинга системных бинарников;

  2. Как устроен проприетарный инсталлятор NVIDIA NVI2, и как мы сами наступили на ошибку 0xe0e00059 в чистой Windows 11, разбираясь с ней через дизассемблер;

  3. Как вернуть классическую Win32 Панель управления NVIDIA (nvcplui.exe) без Microsoft Store и интернета;

  4. Как корректно пересобрать и подписать каталог безопасности .cat по стандарту RFC3161 DigiCert, чтобы установщик работал «из коробки» в один клик.

Весь код проекта, включая открытый скрипт сборки и базу оборудования, опубликован на 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.

В десктопной RTX 3070 аппаратный идентификатор устройства (Hardware ID):

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 рапортует об успехе... но через 3 секунды экран гаснет, драйвер аварийно перезапускается, а в Диспетчере устройств появляется желтый треугольник:

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

Почему это происходит?

Когда впервые сталкиваешься с этой проблемой, легко предположить, что в глубинах ядра nvlddmkm.sys зашита жесткая проверка оборудования, требующая реверса в IDA Pro и патчинга машинного кода.

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

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

[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 и др.) остаются на 100% оригинальными 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:

  1. Тестовый режим отключен (testsigning off):Современные античиты уровня ядра (EasyAntiCheat.sys, BEDaisy.sys) блокируют запуск игр, если Windows загружена с testsigning on, так как тестовый режим открывает лазейку для загрузки неподписанных руткитов в ring 0. Наш драйвер работает в стандартном защищенном режиме с активным DSE (Driver Signature Enforcement) и включенным Secure Boot.

  2. Файлы ядра не изменены ни на один байт:Античит проверяет целостность и цифровую подпись загруженного в память nvlddmkm.sys. Поскольку мы не патчили исполняемый код, встроенная официальная цифровая подпись Microsoft Windows Hardware Compatibility Publisher (WHQL) остаётся идеально валидной.

  3. Графические библиотеки оригинальны:Юзермодные библиотеки рендеринга (nvldumdx.dll, nvd3dumx.dll) сохраняют подписи NVIDIA, поэтому античит не находит никаких признаков модификации библиотек внутри игрового процесса.

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


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

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

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

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

  2. Уровень установщика устройств (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-сущность &quot; передаёт в системный вызов CreateProcessW буквально как символ кавычки!

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

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

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

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

А поскольку субпакет в манифесте имел зависимость перед установкой драйвера дисплея, движок NVI2, получив ненулевой exit code, прерывал всю последующую цепочку развертывания.

Решение

Мы исправили манифест: убрали литеральные кавычки &quot;, добавили ключ принудительной перезаписи -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-контейнер, мы можем распаковать его программно.

Наш пайплайн автоматизирует этот процесс:

  1. Из контейнера AppX извлекаются нативные исполняемые файлы (nvcplui.exe, nvcpluir.dll, nvImage.dll, NvGpuUtilization.exe) и копируются скомпилированным вспомогательным модулем install_helper.exe в системную папку:C:\Program Files\NVIDIA Corporation\Control Panel Client\

  2. В системном реестре прописывается директива разблокировки классического UI на 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-драйвером;

  3. Вспомогательный модуль 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. Чтобы сохранить фирменный интерфейс распаковщика:

  1. Скрипт считывает оригинальный PE-загрузчик SFX (первые 1,12 МБ официального файла);

  2. С помощью библиотеки pefile зануляет поля VirtualAddress и Size в IMAGE_DIRECTORY_ENTRY_SECURITY заголовка PE Optional Header. Это очищает PE-загрузчик от старой цифровой подписи NVIDIA, которая иначе приводила бы к ошибке повреждения сигнатуры при склейке с новым архивом;

  3. Сжимает модифицированное дерево файлов в поток LZMA2 (уровень сжатия 9) и соединяет загрузчик с полученным архивом;

  4. Подписывает готовый монолитный .exe через signtool с меткой времени RFC3161 DigiCert.

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


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

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

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