Pull to refresh

Comments 21

А почему вы не используете уже существующие решения (тот же GRUB)?
Потому что мне нужен очень легкий загрузчик
Можно в цифрах лёгкий vs тяжёлый?
Загрузчик, резидентный код которого не будет занимать более чем 1-2к в первом мегабайте памяти. Дабы исключить конфликты.
А каким образом проблема решена в уже существующих продуктах, например, VeraCrypt, TrueCrypt и т.д.?
Если бы они валились на этапе загрузки — давно поднялся бы вой на болотах.
Наконец — при таком обилии проблем как объяснить эффективность «Petya» — он бы просто валился у массы пользователей сразу после перезагрузки?
Как работоспособность VeraCrypt/TrueCrypt доказывает что проблем в BIOS/UEFI нет? Загрузчики могут быть не сравнимы по содержимому, и проводить такое сравнение некорректно.

Во-первых VeraCrypt/TrueCrypt не работают с USB. Во-вторых их загрузчик BIOS не покидает реального режима процессора. В моем случае приходиться переводить процессор в защищенный режим т.к. резидентная часть кода большая, и разместить её в первом мегабайте я не могу(иначе ничего работать не будет).

Что же касается проблем и их решений, я не был в восторге от того как некоторые моменты сделаны в VeraCrypt/TrueCrypt. Например, размещения резидентного кода, которое выполняется по фиксированному адресу. Что не правильно, т.к. вполне можно потереть чужую память что может располагается в тех пределах. Спасает его только то, что код маленького объема.

Относительно «Petya», вы знаете принцип его работы? Подмена MBR? Может быть подмена bootmgr? Может он работает с USB устройствами?
Исходно Вы сформулировали задачу, как создание продукта для шифрования, для которого разрабатывается загрузчик-расшифровщик.

Логично, что я упомянул уже существующие продукты, успешно выполняющие эту задачу.

Я никогда не слышал о проблемах с перезаписью памяти, о которой Вы упомянули. Равно как и в рамках описанной Вами задачи мне непонятны критические требования к подключению по USB.

Либо опишите задачу более подробно, либо Вы реализует чересчур сложную схему решения, искусственно находя для себя проблемы.

А вы бы и не услышали о проблеме с затиранием памяти.


По USB я работаю со смарт-картами на которых храниться ключ расшифрования.

Авторы Petya скорее всего взяли имеющийся bootmgr.efi, и заменили в нем пару инструкций на выполнение не ntldr, а исполняемого кода Misha.

А как же secure boot? Ntldr это далеко не uefi и запускается до бут менеджера.

https://blog.fortinet.com/2017/06/28/a-technical-analysis-of-the-petya-ransomworm

Там только анализ до килл-свитча, а информации, что именно делает Петя с бут-лоадером, нет.

Вариантов не много, MBR, бут сектор активного раздела или bootmgr который загружается бут сектором.

Либо писатели нашли еще более экзотический способ.
Иногда мне страшно, как много посетителей Хабра забанено в Гугле.
Санкции, видимо.
https://securelist.com/petya-the-two-in-one-trojan/74609/

Если больше деталей нужно — пишите, не стесняйтесь.

Спасибо. Получается, они заменяли код MBR, а на GPT-дисках прятали таблицу GPT и грузили бутлоадер с использованием "защитного" MBR-раздела. Ну, у них задача проще — они не выходили из real mode, с кодом длиной 8 КБ это несложно. Они не ломились на USB-хабы, разве что для ввода кода расшифровки нужна клавиатура, но потерю поддержки USB-клавиатуры после запуска UEFI и выхода обратно в реальный режим довольно легко обнаружить, т.е. наступить ни на одни из граблей, которые потребовали таких костылей для конкретных UEFI, не сумели. Да и если вирус не запустится на 5% машин, на которые попал, невелика потеря.

Сервис BIOS int 16h работает с клавиатурой, поэтому к USB вообще не надо обращаться.
EFI MacBook является особым исключением, и работать с ним тяжелее всего


А можете в двух словах рассказать?
Например их EFI не брезгует тем, чтобы использовать фиксированные адреса для своих нужд. Когда вы читая карту памяти, видите что память в этом участке свободна, и вы начинаете её использовать. Следовательно, результат рэндом.

А если зарепортить вот прямо мне в Л/С? Постараемся исправить.
Понятно, что никто не будет приводить MacEFI к полному соответсвию спецификации UEFI 2.3+, но такие откровенные баги мы все же стараемся чинить.

Статья давняя, конечно, но


После еще пары проблем с 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
Sign up to leave a comment.