Даже дизассемблировать ничего не придется, достаточно записать единицу в нужный регистр EC.
Вообще говоря недорогие машины Dell (у меня Vostro 3360) оказались изнутри очень сильно так себе. Алюминиевый корпус алюминиевый только снаружи, внутри все крепится к пластику, в том числе и верхняя крышка (черех пару лет постоянных открываний-закрываний гайки вылетят из пластиковых стоек), чтобы сменить HDD на SSD пришлось разбирать корпус полностью, а крепежные винты оказались завинчены так туго, что один даже пришлось высверливать. Микросхема БИОСа расположена в 5 мм от края окна быстрого доступа к компонентам, а доступ к ней ограничен только специально добавленым пластиком (удаляем пластик паяльником и можно надевать клипсу программатора в случае сбоя прошивки, не разбирая весь ноутбук целиком). Батареи, занимающей 2/3 корпуса, едва хватает на 4 часа работы в Visual Studio, управление кулером сделано топорно и он излишне шумный (думаю написать свой драйвер, когда дойдут руки), на клавиатуре при быстрой печати ощутимо шатаются клавиши, причем часть дополнительных клавиш посылает скан-коды, а другая работает только через DMI, и сама клавиатура до сих пор имеет интерфейс PS\2. В качестве вишенок для торта — HDA-чип Cirrus Logic и динамики, слушать которые без слез невозможно, и кривой Phoenix SCT 2.3 с неработающим восстановлением после сбоя вместо нормального UEFI.
Я понимаю, что нельзя купить «почти ультрабук» за 500 евро и хотеть от него слишком многого, но это точно мой последний ноутбук Dell.
В таком случае наиболее удобный инструмент — SOIC-клипса, только лучше купить не китайскую за 10 центов, а нормальную, производства Pomona или 3M. Также не стоит забывать, что программатору, подключенному клипсой к припаянному к плате чипу, придется еще и половину платы запитывать, поэтому нужно либо выпаивать чип (это надежнее), либо организовавать дополнительное стабильное питание, чтобы во время чтения\записи не было ошибок. То, то микросхема поддерживает Dual или QuadSPI — ничего страшного, обыкновенный SPI она от этого поддерживать не перестает, а если ваш программатор умеет QuadSPI — просто будет прошиваться 30 секунд вместо 2 минут.
Идея адекватная, но встает вопрос «кто будет контролировать контролеров?». Ничего не мешает производителю оборудования запускать в этой TrustZone любые закладки АНБ программы, а если технология будет скомпрометирована — исправить что-то можно будет только заменой оборудования.
Практически на всех AMI, которые я встречал, регион BIOS либо не защищен вообще, либо защищен только установкой BIOS Lock, которую можно снять либо прошивкой через AFU в ключом /GAN, либо редактированием NVRAM. Цифровая подпись там хранится только в заголовке Aptio Capsule и в микросхему не попадает, а на некоторых платах (не будем показывать пальцем на Asrock) для обхода этой проверки можно просто удалить заголовок. В SMM там есть только обработчик установки бита BIOS Write Enabled, который ставит этот бит обратно, но и это можно отключить, сняв вышеупомянутый BIOS Lock редактирвоанием NVRAM.
Для Phoenix'ов имеются утекшие инженерные версии PFlash, которые прошивают что угодно даже на ноутбуках с последней версией платформы (SCT 2.3), где прошивка должна осуществляться описанным в вышеупомянутом докладе способом через оставление капсулы в памяти и софт-ресет, но по факту происходит обычным способом. Правда, на моем ноутбуке старая версия PFlash вызывает повреждение NVRAM, и после прошивки ноутбук перестает работать, но сам факт осуществления этой прошивки — на лицо.
Каких-то фундаментальных статей по безопасности UEFI я давно уже не видел, но скорее потому, что не слежу за темой, чем потому, что их нет. Вот тут можно посмотреть на практическую сторону «защиты» от прошивки модифицированных БИОСов, большая часть прозьб удовлетворяется вполне успешно.
Основная проблема в том, что выбора практически нет. Выбрасываем AMI — и для десктопа остаются только платы Intel. Выбрасываем Phoenix — из ноутбуков остаются только десяток моделей с Insyde H2O и машины Apple (на которых вообще никакой защиты нет и дамп замечательно снимается и пишется flashrom'ом). А после переезда ME в чипсет к безопасности всех систем на базе процессоров Intel люди, разбирающиеся в ней, не могут относиться без доли скептицизма. Сейчас еще AMD внедрит TrustZone, то про «безопасность» на системах x86 вообще можно забыть.
Я описываю состояние безопасности существующих систем, а не тех, которые через 3 года встанут в строй. А его иначе как «полумифическим» назвать язык не поворачивается. И исправлена эта ситуация для владельцев UEFI-совместимых плат на чипсетах Intel 5, 6 и частично 7 серий уже не будет никогда.
Безопасность системы определяется безопасностью самой слабой ее части. Что толку в SecureBoot, если AMI позволяет проишивать все, что угодно, несмотря на подписи, а на 95% современных десктопных плат UEFI основан на коде AMI? Да, это недоработка конкретного вендора, но кому становится легче от этого?
Прошу меня простить, но о безопасность технологии SecureBoot я не говорил ничего. Я говорил о безопасности текущих реализаций UEFI, которая оставляет желать много лучшего, и будет оставлена в таком состоянии еще долго. Включайте SecureBoot и будьте спокойны, если вас это устраивает, в на 2 моих ПК из 3 его просто нет и уже никогда не появится.
Если бы и написал — все равно ответил бы, что нет. ;)
Только вот это и не нужно, т.к. SecureBoot включен хорошо если на 2% имеющихся UEFI-систем, да и он не всегда помогает. При этом на одной половине UEFI-систем вообще нет никакой защиты, а на другой она снимаетсятривиально.
А дальше все просто, бери flashrom, дампай@меняй@прошивай.
Программатор спасет отца русской демократии.
На всякого рода презентациях производители UEFI любят рассказывать про то, как они защищают компоненты от модификации при помощи ЭЦП и поддерживают Chain-of-Trust, но по факту я не видел еще ни одного UEFI BIOS'а, в котором действительно бы проверялось что-то, кроме контрольных сумм, обычно все проверки выполняются на этапе прошивки. О способе прошивки модифицированного БИОСа можно еще здесь спросить, но я все равно рекомендую программатор — он в разы надежнее.
Готовой базы, насколько я знаю, нет, но найти дамп для какого-либо сравнительно популярного железа можно на форумах ремонтников (соответствующий раздел на notebook1.ru, например). Иногда дамп можно сделать из файла с обновлением, дописав в него необходимые данные, но эта возможность есть обычно только у обладателей десктопов.
Можно еще исправить не переход (его иногда бывает непросто найти), а просто добавить свое устройство в список.
Во второй части расскажу и про этот класс модов (whitelist removal) тоже.
Он, все же, больше про SLIC, чем про модификации.
Навскидку: Descriptor не разбирает, ошибки в структуре не видит и не исправляет, код закрытый, требует наличия .Net 3.
Я не оспариваю первенства AndyP (а еще раньше apple_rom с его BIOS Patcher'ом), но не стал бы писать не самую простую программу, если бы аналогичная умела все, что мне нужно.
Построю лабиринт, где смогу затеряться с тем, кто захочет меня найти. Кто это сказал и о чем?
При прочтении статьи сразу в голове всплыла (аудио)книга В. Пелевина «Шлем Ужаса». Заинтересовавшимся темой лабиринтов — рекомендую к прочтению или прослушиванию.
Особенно неприятно, что Lenovo использует Phoenix SCT в качестве прошивки, да еще и дополнительно вводит белые списки совместимого оборудования, которые невозможно обойти без вскрытия ноутбука и использования SPI-программатора.
У меня был Lenovo x121e AMD, и больше никаких их продуктов я не куплю.
ThinkPad'ы, которые делала IBM, были одними из лучших машин на рынке, а теперь от них осталось только название и TrackPoint на клавиатуре.
Если не убрать из требований «бесконечные» данные, то можно запустить что угодно, написав в 30 строк декодер образа этого «что-угодно» обыкновенным XOR с не очень длинным ключом (так обойдется ограничение на запись двочного кода в одну строку, ведь теперь в строке вовсе не код), а после расшифровки просто передать туда управление.
Если же рассматривать «функции BIOS» в широком смысле, т.е. с возможностью использования UEFI-сервисов, то можно буквально несколькими командами попросить диспетчер DXE загрузить драйвер, написанный на EBC (точно не исполняемый код процессора) и лежащий рядом с нашим кодом. Тоже если стараться и не проверять коды возврата, в 30 строк уложиться можно.
О Великий Рандом, мне рассказывают про UEFI SecureBoot в смартфоне. И про TPM. И про то, что железо выпускается одним единственным производителем. И про шифрование всего подряд ключами, которые невозможно достать или сменить. И про то, что вот это все — для моей же безопасности.
Прохладный сказ, бояре.
Да легко.
Возьмем «обычное» приложение на C++\Qt, использующее Qt только для GUI (ну и немного классов из Core, раз уж их все равно тянуть вместе с GUI). Собираем его с Qt 4.8.5 не статическим — получаем 150 Kb исполняемого файла, которому нужны QtCore4.dll (2.5 Mb) и QtGui4.dll (8.3 Mb) и C++ Runtime соответствующей версии.
Если собирать статически, то на выходе получаем исполняемый файл размером в 7,5 Mb, которому ничего не нужно. При этом для статической сборки Qt 4.8.5 тоже ничего, кроме компилятора, не нужно (если не собирать WebKit, Phonon и т.п.), и она вполне себе собирается без всяких патчей.
Теперь собираем то же самое приложение: те же 150 Kb исполняемого файла, Qt5Core.dll (3,9 Mb), Qt5Gui.dll (2,9 Mb), Qt5Widgets.dll (4,5 Mb) и тот же самый RT. Разница небольшая, но не в пользу Qt5.
Статически же собирать Qt5 — целое приключение. Кроме исходного кода, нужны еще Perl и Python (а если с опциями ошибиться, то и DirectX SDK). И то не факт, что вообще соберется. Каюсь, сборку 5.2 еще не тестировал, но уверен почему-то, что зависимость configure.exe от вышеупомянутых перла и питона никуда не делась.
Вообще говоря недорогие машины Dell (у меня Vostro 3360) оказались изнутри очень сильно так себе. Алюминиевый корпус алюминиевый только снаружи, внутри все крепится к пластику, в том числе и верхняя крышка (черех пару лет постоянных открываний-закрываний гайки вылетят из пластиковых стоек), чтобы сменить HDD на SSD пришлось разбирать корпус полностью, а крепежные винты оказались завинчены так туго, что один даже пришлось высверливать. Микросхема БИОСа расположена в 5 мм от края окна быстрого доступа к компонентам, а доступ к ней ограничен только специально добавленым пластиком (удаляем пластик паяльником и можно надевать клипсу программатора в случае сбоя прошивки, не разбирая весь ноутбук целиком). Батареи, занимающей 2/3 корпуса, едва хватает на 4 часа работы в Visual Studio, управление кулером сделано топорно и он излишне шумный (думаю написать свой драйвер, когда дойдут руки), на клавиатуре при быстрой печати ощутимо шатаются клавиши, причем часть дополнительных клавиш посылает скан-коды, а другая работает только через DMI, и сама клавиатура до сих пор имеет интерфейс PS\2. В качестве вишенок для торта — HDA-чип Cirrus Logic и динамики, слушать которые без слез невозможно, и кривой Phoenix SCT 2.3 с неработающим восстановлением после сбоя вместо нормального UEFI.
Я понимаю, что нельзя купить «почти ультрабук» за 500 евро и хотеть от него слишком многого, но это точно мой последний ноутбук Dell.
закладки АНБпрограммы, а если технология будет скомпрометирована — исправить что-то можно будет только заменой оборудования.Для Phoenix'ов имеются утекшие инженерные версии PFlash, которые прошивают что угодно даже на ноутбуках с последней версией платформы (SCT 2.3), где прошивка должна осуществляться описанным в вышеупомянутом докладе способом через оставление капсулы в памяти и софт-ресет, но по факту происходит обычным способом. Правда, на моем ноутбуке старая версия PFlash вызывает повреждение NVRAM, и после прошивки ноутбук перестает работать, но сам факт осуществления этой прошивки — на лицо.
Каких-то фундаментальных статей по безопасности UEFI я давно уже не видел, но скорее потому, что не слежу за темой, чем потому, что их нет. Вот тут можно посмотреть на практическую сторону «защиты» от прошивки модифицированных БИОСов, большая часть прозьб удовлетворяется вполне успешно.
Безопасность системы определяется безопасностью самой слабой ее части. Что толку в SecureBoot, если AMI позволяет проишивать все, что угодно, несмотря на подписи, а на 95% современных десктопных плат UEFI основан на коде AMI? Да, это недоработка конкретного вендора, но кому становится легче от этого?
Прошу меня простить, но о безопасность технологии SecureBoot я не говорил ничего. Я говорил о безопасности текущих реализаций UEFI, которая оставляет желать много лучшего, и будет оставлена в таком состоянии еще долго. Включайте SecureBoot и будьте спокойны, если вас это устраивает, в на 2 моих ПК из 3 его просто нет и уже никогда не появится.
Только вот это и не нужно, т.к. SecureBoot включен хорошо если на 2% имеющихся UEFI-систем, да и он не всегда помогает. При этом на одной половине UEFI-систем вообще нет никакой защиты, а на другой она снимается тривиально.
А дальше все просто, бери flashrom, дампай@меняй@прошивай.
На всякого рода презентациях производители UEFI любят рассказывать про то, как они защищают компоненты от модификации при помощи ЭЦП и поддерживают Chain-of-Trust, но по факту я не видел еще ни одного UEFI BIOS'а, в котором действительно бы проверялось что-то, кроме контрольных сумм, обычно все проверки выполняются на этапе прошивки. О способе прошивки модифицированного БИОСа можно еще здесь спросить, но я все равно рекомендую программатор — он в разы надежнее.
Во второй части расскажу и про этот класс модов (whitelist removal) тоже.
Навскидку: Descriptor не разбирает, ошибки в структуре не видит и не исправляет, код закрытый, требует наличия .Net 3.
Я не оспариваю первенства AndyP (а еще раньше apple_rom с его BIOS Patcher'ом), но не стал бы писать не самую простую программу, если бы аналогичная умела все, что мне нужно.
При прочтении статьи сразу в голове всплыла (аудио)книга В. Пелевина «Шлем Ужаса». Заинтересовавшимся темой лабиринтов — рекомендую к прочтению или прослушиванию.
У меня был Lenovo x121e AMD, и больше никаких их продуктов я не куплю.
ThinkPad'ы, которые делала IBM, были одними из лучших машин на рынке, а теперь от них осталось только название и TrackPoint на клавиатуре.
Если же рассматривать «функции BIOS» в широком смысле, т.е. с возможностью использования UEFI-сервисов, то можно буквально несколькими командами попросить диспетчер DXE загрузить драйвер, написанный на EBC (точно не исполняемый код процессора) и лежащий рядом с нашим кодом. Тоже если стараться и не проверять коды возврата, в 30 строк уложиться можно.
Прохладный сказ, бояре.
Возьмем «обычное» приложение на C++\Qt, использующее Qt только для GUI (ну и немного классов из Core, раз уж их все равно тянуть вместе с GUI). Собираем его с Qt 4.8.5 не статическим — получаем 150 Kb исполняемого файла, которому нужны QtCore4.dll (2.5 Mb) и QtGui4.dll (8.3 Mb) и C++ Runtime соответствующей версии.
Если собирать статически, то на выходе получаем исполняемый файл размером в 7,5 Mb, которому ничего не нужно. При этом для статической сборки Qt 4.8.5 тоже ничего, кроме компилятора, не нужно (если не собирать WebKit, Phonon и т.п.), и она вполне себе собирается без всяких патчей.
Теперь собираем то же самое приложение: те же 150 Kb исполняемого файла, Qt5Core.dll (3,9 Mb), Qt5Gui.dll (2,9 Mb), Qt5Widgets.dll (4,5 Mb) и тот же самый RT. Разница небольшая, но не в пользу Qt5.
Статически же собирать Qt5 — целое приключение. Кроме исходного кода, нужны еще Perl и Python (а если с опциями ошибиться, то и DirectX SDK). И то не факт, что вообще соберется. Каюсь, сборку 5.2 еще не тестировал, но уверен почему-то, что зависимость configure.exe от вышеупомянутых перла и питона никуда не делась.