Comments 21
Если бы они валились на этапе загрузки — давно поднялся бы вой на болотах.
Наконец — при таком обилии проблем как объяснить эффективность «Petya» — он бы просто валился у массы пользователей сразу после перезагрузки?
Во-первых VeraCrypt/TrueCrypt не работают с USB. Во-вторых их загрузчик BIOS не покидает реального режима процессора. В моем случае приходиться переводить процессор в защищенный режим т.к. резидентная часть кода большая, и разместить её в первом мегабайте я не могу(иначе ничего работать не будет).
Что же касается проблем и их решений, я не был в восторге от того как некоторые моменты сделаны в VeraCrypt/TrueCrypt. Например, размещения резидентного кода, которое выполняется по фиксированному адресу. Что не правильно, т.к. вполне можно потереть чужую память что может располагается в тех пределах. Спасает его только то, что код маленького объема.
Относительно «Petya», вы знаете принцип его работы? Подмена MBR? Может быть подмена bootmgr? Может он работает с USB устройствами?
Логично, что я упомянул уже существующие продукты, успешно выполняющие эту задачу.
Я никогда не слышал о проблемах с перезаписью памяти, о которой Вы упомянули. Равно как и в рамках описанной Вами задачи мне непонятны критические требования к подключению по USB.
Либо опишите задачу более подробно, либо Вы реализует чересчур сложную схему решения, искусственно находя для себя проблемы.
Авторы Petya скорее всего взяли имеющийся bootmgr.efi, и заменили в нем пару инструкций на выполнение не ntldr, а исполняемого кода Misha.
А как же secure boot? Ntldr это далеко не uefi и запускается до бут менеджера.
Там только анализ до килл-свитча, а информации, что именно делает Петя с бут-лоадером, нет.
Либо писатели нашли еще более экзотический способ.
Санкции, видимо.
https://securelist.com/petya-the-two-in-one-trojan/74609/
Если больше деталей нужно — пишите, не стесняйтесь.
Спасибо. Получается, они заменяли код MBR, а на GPT-дисках прятали таблицу GPT и грузили бутлоадер с использованием "защитного" MBR-раздела. Ну, у них задача проще — они не выходили из real mode, с кодом длиной 8 КБ это несложно. Они не ломились на USB-хабы, разве что для ввода кода расшифровки нужна клавиатура, но потерю поддержки USB-клавиатуры после запуска UEFI и выхода обратно в реальный режим довольно легко обнаружить, т.е. наступить ни на одни из граблей, которые потребовали таких костылей для конкретных UEFI, не сумели. Да и если вирус не запустится на 5% машин, на которые попал, невелика потеря.
И что это доказывает?
EFI MacBook является особым исключением, и работать с ним тяжелее всего
А можете в двух словах рассказать?
Статья давняя, конечно, но
После еще пары проблем с USB в UEFI я пришел к тому, чтобы в загрузчик поместить свои драйвера хост контроллеров. Для этого приходится останавливать те драйвера, что работают в самом UEFI, и загружать свои. Добавлять так называемые “костыли” мне никогда не импонировало. К тому же, такой код со временем станет тяжело развивать из-за нагроможденности.
Как я тут понял, HP в своих версиях драйверов/PEIмодулей не стесняется ни разу использовать фичу #define true false.
Это и упоиянутая замена USB Direction (которая, в общем-то не совсем абсолютно бессмысленна — чуть упрощается ассемблерный код разбора. На пару-тройку инструкций))
Еще из веселых примеров у них — творческое видение реализации PEI_USB_HOST_CONTROLLER_PPI интерфейса: добавили самым первым членом структуры свой, посконный. При установке приравнивают его 3.
А при вызове из других Peim проверяют — если это значение не 3, то… скорость USB ставим Low, тадааам. Ну и, естественно, вообще получается эдакая "защита" интерфейса: в UEFI первый член струтктуры тот, что у HP второй.
Т.е. вызываются не те функции, что предполагаются.
hp_PEI_USB_HOST_CONTROLLER_PPI struc ; (sizeof=0x1C, align=0x4, copyof_112)
wtf_eq_3 dd ?
ControlTransfer dd ?
BulkTransfer dd ?
GetRootHubPortNumber dd ?
GetRootHubPortStatus dd ?
SetRootHubPortFeature dd ?
ClearRootHubPortFeature dd ?
hp_PEI_USB_HOST_CONTROLLER_PPI ends
Немного о багах в BIOS/UEFI ноутбуков Lenovo/Fujitsu/Toshiba/HP/Dell