Ну, в таком случае искать только уязвимые загрузчики, либо пывнить драйвера в прошивках. С первым и так всё понятно. Я думаю, можно что-то найти даже не в DBX.
Второе сложнее и более локальное, но можно тоже рассмотреть. Поставщика прошивок у нас 3:
AMI, Insyde и Phoenix. Можешь плюсануть сюда вендорские драйвера от Intel и AMD. Я бы на твоём месте ориентировался либо на драйвера вендоров процессоров, либо же на стандартные драйвера, что качуют от прошивок к прошивкам.
Задача же заключается в поиске слабостей реализации в DXE фазе, например, повреждение памяти в каких-нибудь пулах. В качестве примера могу назвать
парсинг битмапы, так как в парсере могут быть ошибки. Какой-нибудь OOB Write ты выбить сможешь.
Если в DXE ничего не нашлось, то можно опуститься при желании в SMM, так как он может
перезаписывать данные на SPI чипе. Если цель - запись, то ищи
Arbitrary SMRAM R/W примитивы (например, как в
UsbRt) и примитивы для запуска кода (мб они у тебя уже будут). В случае с SMM у тебя следующий алгоритм действий:
- Снять защиту на запись с чипа (у AMI для этого специальный SW SMI обработчик);
- Создать себе Arbitary SMRAM R/W примитивы и закинуть свой блоб данных (главное, чтоб в SMRAM помещалось);
- Триггернуть протокол на запись в SPI чип через примитив на запуск кода;
- Восстановить защиту на запись.
Но я бы порекомендовал всё же тыкаться в DXE. Плюсом, в SMM сейчас очень сложно что-либо пывнить (а затем у нас ещё SMM Isolation появился на Intel).
Есть альтернативный вариант с поиском слабостей реализации в бутменеджере/бутлоадере (уже виндовом). Там есть свой определённый список поверхностей для атаки. Явные идеи давать я не буду.
Но это всё сложно, я бы вернулся к первому или же отказался от идеи отлома в принципе.
Триггерит.
Если ты говоришь про запатченные CVE - соответственно, только с появлением патчей, и то, если можно публиковать.
