Основная проблема в том, что выбора практически нет. Выбрасываем 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 от вышеупомянутых перла и питона никуда не делась.
Хочется спросить, где был бы сейчас Linux, будь он написан на ассемблере для x86 в свое время?
И где теперь написанная на ассемблере OS/360 от IBM, после работы над которой Брукс написал свою знаменитую книгу «Мифический человеко-месяц»?
Мой ответ на вопрос «как надо программировать на ассемблере» на данный момент звучит так: программируйте на С во всех случаях, кроме написания компилятора С для совершенно новой архитектуры.
Я безмерно уважаю разработчиков ColibriOS за их труд и статьи, но, по моему мнению, коммерческая разработка на ассемблере сейчас сродни коммерческой разработке на Whitespace, с тем же примерно уровнем сложности и соотношением затрат к результату.
И не только для пожилых. Мне всегда не нравились режимы работы в интерфейсах и увлечение контекстными кнопками, но пожилым я себя пока еще не могу назвать. То же самое и с тач-устройствами: совмещение устройств вывода с устройствами ввода, как когда-то выразился Леонид Каганов, это «как чай в унитазе заваривать». А потом все равно купил себе iPad.
Ждем тач-устройств с тактильной обратной связью, то, что предлагается на рынке сейчас — совершенно не замена теплым и ламповым аппаратным кнопкам.
Код у FTDI, к сожалению, получается много хуже чем устройства.
Не думаю, что наткнулся бы на этот баг, ибо об использовании их библиотек даже мысли в голову не приходили — прямая работа с D2XX или libftdi не намного сложнее, но все равно спасибо огромное.
Вышли тому, кто продемонстрирует на LCD, а то в консоли — это не спортивно.
Мой LCD сейчас на работе, а те, что доступны в «удаленной лаборатории» моего ПТУ, подключены к Stellaris Launchpad и Infineon XE167FM EasyKit, запуск Linux на которых — еще больший хардкор, а через мой драйвер дисплея это писать еще менее спортивно, чем в консоль.
Безопасность системы определяется безопасностью самой слабой ее части. Что толку в 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 от вышеупомянутых перла и питона никуда не делась.
И где теперь написанная на ассемблере OS/360 от IBM, после работы над которой Брукс написал свою знаменитую книгу «Мифический человеко-месяц»?
Мой ответ на вопрос «как надо программировать на ассемблере» на данный момент звучит так: программируйте на С во всех случаях, кроме написания компилятора С для совершенно новой архитектуры.
Я безмерно уважаю разработчиков ColibriOS за их труд и статьи, но, по моему мнению, коммерческая разработка на ассемблере сейчас сродни коммерческой разработке на Whitespace, с тем же примерно уровнем сложности и соотношением затрат к результату.
Ждем тач-устройств с тактильной обратной связью, то, что предлагается на рынке сейчас — совершенно не замена теплым и ламповым аппаратным кнопкам.
Не думаю, что наткнулся бы на этот баг, ибо об использовании их библиотек даже мысли в голову не приходили — прямая работа с D2XX или libftdi не намного сложнее, но все равно спасибо огромное.
Мой LCD сейчас на работе, а те, что доступны в «удаленной лаборатории» моего ПТУ, подключены к Stellaris Launchpad и Infineon XE167FM EasyKit, запуск Linux на которых — еще больший хардкор, а через мой драйвер дисплея это писать еще менее спортивно, чем в консоль.