Как отключить intel me

Выключаем Intel ME 11, используя недокументированный режим

В ходе исследования внутренней архитектуры Intel Management Engine (ME) 11-й версии был обнаружен механизм, отключающий эту технологию после инициализации оборудования и запуска основного процессора. О том, как мы нашли этот недокументированный режим, и о его связи с государственной программой построения доверительной платформы High Assurance Platform (HAP) мы расскажем в этой статье.

Авторы предупреждают, что использование данных знаний на практике может повлечь за собой повреждение вычислительной техники, и не несут за это никакой ответственности, а также не гарантируют работоспособность или неработоспособность чего-либо и не рекомендуют экспериментировать без наличия SPI-программатора.

Введение

Intel Management Engine — это закрытая технология, которая представляет собой интегрированный в микросхему Platform Controller Hub (PCH) микроконтроллер с набором встроенных периферийных устройств. Именно через PCH проходит почти все общение процессора с внешними устройствами, следовательно Intel ME имеет доступ практически ко всем данным на компьютере и возможность исполнения стороннего кода позволяет полностью скомпрометировать платформу. Такие безграничные возможности привлекают исследователей не первый год, но сейчас интерес к технологии Intel ME значительно вырос. Одной из причин этого является переход данной подсистемы на новую аппаратную (x86) и программную (доработанный MINIX в качестве операционной системы) архитектуру. Применение платформы x86 позволяет использовать всю мощь средств анализа бинарного кода, что ранее было затруднительно, так как до 11-й версии использовалось ядро с малораспространенной системой команд — ARC. К сожалению, анализ Intel ME 11-й версии был затруднен тем, что исполняемые модули упакованы кодом Хаффмана с неизвестными таблицами. Но нашей исследовательской группе (Дмитрий Скляров, Марк Ермолов, Максим Горячий) удалось их восстановить (утилиту для распаковки образов можно найти на нашей странице в GitHub).

После распаковки исполняемых модулей мы приступили к изучению программной и аппаратной «начинки» Intel ME. Наша команда занимается этим уже достаточно продолжительное время, и мы накопили большой объем материалов, которые было решено опубликовать. Это первая статья из цикла статей, посвященных внутреннему устройству и особенностям работы Intel ME, и в ней мы расскажем, как отключить основную функциональность подсистемы. Этот вопрос терзает специалистов, так как ее отключение позволило бы снизить риски утечки данных, например в случае обнаружения в этой технологии уязвимости нулевого дня.

Как выключить ME

Как выключить ME — этот вопрос часто задают некоторые владельцы компьютеров x86-архитектуры. Тема деактивации неоднократно поднималась, в том числе и исследователями нашей компании.

Актуальности этому вопросу добавляет недавно обнаруженная критическая (9,8 из 10) уязвимость в Intel Active Management Technology (AMT) — технологии, которая базируется на Intel ME.

Сразу огорчим читателя — полностью выключить ME на современных компьютерах невозможно. Это связано прежде всего с тем, что именно эта технология отвечает за инициализацию, управление энергопотреблением и запуск основного процессора. Сложности добавляет и тот факт, что часть кода «жестко прошита» внутри микросхемы PCH, которая выполняет функции южного моста на современных материнских платах. Основным средством энтузиастов, которые «борются» с данной технологией, является удаление всего «лишнего» из образа flash-памяти при сохранении работоспособности компьютера. Но сделать это не так просто, так как, если встроенный в PCH код не найдет во flash-памяти модули ME или определит, что они повреждены, система запущена не будет. Уже несколько лет в сети развивается проект me_cleaner, в рамках которого доступна специальная утилита, позволяющая удалить большую часть образа и оставить только жизненно необходимые для основной системы компоненты. Но даже если система запустилась, радоваться рано — приблизительно через 30 минут может произойти автоматическое отключение, так как при некоторых сбоях ME переходит в Recovery-режим, в котором не функционирует больше некоторого фиксированного времени. В итоге процесс очистки усложняется. Например, до 11-й версии удавалось уменьшить размер образа до 90 KБ, но в 11-й — уже только до 650 КБ.

Рисунок 1. Поддержка архитектур Skylake+ в me_cleaner

Секреты в QResource

Intel дает производителям материнских плат возможность задать небольшое количество параметров ME. Для этого компания предоставляет производителям оборудования специальный набор программного обеспечения, в который входят такие утилиты, как Flash Image Tool (FIT) для настройки параметров ME и Flash Programming Tool (FPT), реализующая поддержку программирования flash-памяти напрямую через встроенный SPI-контроллер. Данные программы недоступны конечному пользователю, но их без труда можно найти в интернете. Из этих утилит можно извлечь большое количество файлов формата XML (подробное Intel ME: The Way oftheStatic Analysis), изучение которых позволяет узнать много интересного: структуру прошивки ME и описание PCH strap — специальных конфигурационных битов для различных подсистем, интегрированных в микросхему PCH.

Рисунок 2. Упакованные XML-файлы

Нас заинтересовало одно из таких полей с именем «reserve_hap», так как напротив него имелся комментарий — High Assurance Platform (HAP) enable.

Рисунок 3. PCH strap для High Assurance Platform

Поиск в Google не был долгим. Буквально вторая ссылка говорит, что такое название носит программа по созданию доверительных платформ, связанная с Агентством национальной безопасности (АНБ) США. Презентацию с описанием программы можно найти тут. Нашей первой мыслью было поставить этот бит и посмотреть, что будет. Это может сделать любой желающий, если у него есть SPI-программатор или доступ в Flash Descriptor (на многих материнских платах некорректно выставлены права доступа к регионам flash-памяти).

Рисунок 4. Статус ME после активации HAP-бита

После загрузки платформы утилита meinfo сообщает странный статус — Alt Disable Mode. Беглые проверки показали, что ME не отвечает на команды и никак не реагирует на воздействия из операционной системы. Мы решили разобраться, как система переходит в этот режим и что он означает. К этому времени у нас уже была проанализирована основная часть модуля BUP, который отвечает за начальную инициализацию платформы и, исходя из вывода meinfo, устанавливает этот статус. Для понимания алгоритма работы BUP необходимо более подробно описать программное окружение Intel ME.

Программная часть Intel ME 11

Начиная с PCH 100-й серии компания Intel полностью переработала эту микросхему. Был осуществлен переход на новую архитектуру встроенных микроконтроллеров — с ARCompact компании ARC на x86. За основу был выбран 32-битный микроконтроллер Minute IA (MIA), который используется в микрокомпьютерах Intel Edison и SoC Quark. Он основан на дизайне весьма старого, скалярного микропроцессора Intel 486 с добавлением системы команд (ISA) от процессора Pentium. Однако для PCH компания выпускает данное ядро с применением 22-нм полупроводниковой технологии, получая высокую энергоэффективность микроконтроллера. Таких ядер в новом PCH три: Management Engine (ME), Integrated Sensors Hub (ISH) и Innovation Engine (IE). Последние два могут активироваться и деактивироваться в зависимости от модели PCH и целевой платформы, а ME-ядро работает всегда.

Рисунок 5. Три x86-процессора в PCH

Такие глобальные изменения потребовали изменения и программной составляющей ME. В частности, в качестве основы для операционной системы был выбран MINIX (ранее ThreadX RTOS). Теперь прошивка ME включает полноценную операционную систему со своими процессами, потоками, диспетчером памяти, драйвером аппаратных шин, файловой системой и многим другим. В ME интегрирован аппаратный криптопроцессор, поддерживающий алгоритмы SHA256, AES, RSA, HMAС. Доступ к оборудованию для пользовательских процессов производится посредством локальной таблицы дескрипторов (LDT). Через LDT организовано также и адресное пространство процесса — оно является всего лишь частью глобального адресного пространства ядра, границы которого заданы в локальном дескрипторе. Таким образом, ядру не нужно переключаться на память разных процессов (меняя каталоги страниц), как, например, в Microsoft Windows или Linux.

На этом закончим обзор программного окружения Intel ME и рассмотрим более подробно, как происходит загрузка операционной системы и модулей.

Стадии загрузки Intel ME

Запуск начинается с программы ROM, которая содержится во встроенной в PCH статической памяти. К сожалению, способ прочесть или перезаписать эту память широкой общественности не известен, но в интернете можно найти «предпродажные» версии прошивки ME с разделом ROMB (ROM BYPASS), который, по нашему предположению, дублирует функции ROМ. Таким образом, исследуя такие прошивки, можно восстановить основную функциональность программы первичной инициализации.

Изучение ROMB позволяет понять назначение ROM — выполнение начальной инициализации оборудования, например SPI-контроллера, проверка цифровой подписи заголовка раздела FTPR, загрузка модуля RBE, который расположен уже во flash-памяти. RBE, в свою очередь, проверяет контрольные суммы модулей KERNEL, SYSLIB, BUP и передает управление на точку входа в ядро.

Следует заметить, эти три сущности — ROM, RBE и KERNEL — выполняются на нулевом уровне привилегий (в ring-0) ядра MIA.

Рисунок 6. Проверка целостности SYSLIB, KERNEL и BUP в RBE

Первый процесс, который создается ядром, — это BUP, который уже выполняется в своем адресном пространстве, в ring-3. Других процессов ядро по своей инициативе не запускает, этим занимается сам BUP, а также отдельный модуль LOADMGR, к нему вернемся позже. Назначение BUP (platform BringUP) — это инициализация всего аппаратного окружения платформы (в том числе процессора), выполнение первичных функций управления энергопитанием (например, запуск системы по нажатию кнопки включения) и запуск все остальных процессов ME. Таким образом, можно с уверенностью говорить, что PCH в 100-й серии и выше просто физически не имеют возможности запуска без корректной прошивки ME. Во-первых, BUP инициализирует контроллер управления энергопитанием (power management controller, PMC) и ICC-контроллер. Во-вторых — запускает целую вереницу процессов; часть из них «жестко прошита» в коде (SYNCMAN, PM, VFS), а другая часть содержится в InitScript (аналог автозапуска), который хранится в заголовке тома FTPR и защищен цифровой подписью.

Рисунок 7. Запуск SYNCMAN и PM

Таким образом, BUP считывает InitScript и запускает все процессы, которые удовлетворяют типу запуска ME и являются IBL-процессами.

Рисунок 8. Обработка InitScript

Рисунок 9. Список модулей c флагом IBL

В случае если запуск процесса не удался, BUP не будет запускать систему или переведет ее в Recovery режим, в котором произойдет автоматическое отключение питания после нескольких десятков минут. Как можно видеть на иллюстрации, последним в списке IBL-процессов является LOADMGR. Именно он дает старт оставшимся процессам, но в отличие от BUP, если в процессе запуска модуля происходит ошибка, LOADMGR просто перейдет к следующему.

Таким образом, первый вариант ограничить функционирование Intel ME — удалить все модули, которые не имеют флаг IBL в InitScript, что позволит существенно уменьшить размер прошивки. Но первоначально мы хотели выяснить, что происходит с ME в режиме HAP. Для этого рассмотрим программную модель BUP подробнее.

Рисунок 10. Схема запуска модулей в ME

BringUP

Если присмотреться к алгоритму работы модуля BUP, можно сказать, что внутри него реализован классический конечный автомат. Выполнение функционально разделено на две составляющие: стадии инициализации (представляют собой тот самый конечный автомат) и выполнение сервисных запросов других процессов после инициализации системы. Число стадий инициализации разное, в зависимости от платформы и SKU (TXE, CSME, SPS, consumer, corporate), но основные, общие для всех версий, все же можно выделить.

Первая стадия

На начальной стадии происходит создание внутренней диагностической файловой системы sfs (SUSRAM FS — файловая система, расположенная в энергозависимой памяти), считывание конфигурации, и, самое главное, получение информации от PMC о том, что привело к данному старту — включение питания платформы, глобальный перезапуск всей платформы, перезапуск только ME или же пробуждение из состояния сна. Эта стадия называется boot flow determination. От нее зависят последующие стадии работы конечного автомата инициализации. Кроме того, поддерживаются несколько режимов работы: нормальный и набор сервисных режимов, при которых ME штатно не функционирует — HAP, HMRFPO, TEMP_DISABLE, RECOVERY, SAFE_MODE, FW_UPDATE и FD_OVERRIDE.

Вторая стадия

На следующей стадии происходят инициализация ICC-контроллера и загрузка ICC-профиля (отвечает за тактовые частоты основных потребителей), инициализация Boot Guard и начало циклического опроса подтверждения запуска процессора.

Третья стадия

BUP ожидает сообщение от PMC о том, что основной процессор запустился. После этого BUP запускает асинхронный цикл опроса PMC на предмет возникновения событий энергопитания (перезапуск или отключение платформы) и переходит к следующей стадии. Если такое событие произошло, BUP выполнит запрашиваемое действие в момент перехода между стадиями инициализации.

Четвертая стадия

На этой стадии происходит инициализация внутреннего оборудования. Также BUP запускает цикл опроса heci (специального устройства, предназначенного для получения команд от BIOS или операционной системы) на предмет получения DID (DRAM Init Done message) от BIOS. Именно это сообщение позволяет ME понять, что основной BIOS инициализировал оперативную память и зарезервировал для ME специальный регион, UMA, и после этого перейти к следующей стадии.

Пятая стадия

Как только DID получен, BUP, в зависимости от режима работы, который определяется по разным составляющим, либо запускает IBL-процессы из InitScript (при нормальном режиме работы), либо зависает в цикле, выйти из которого он может только при получении сообщения от PMC, например, в результате запроса на перезагрузку или выключение системы.

Именно на этой стадии мы и находим обработку HAP, причем в этом режиме BUP не выполняет InitScript, а зависает. Таким образом, остальная последовательность действий при нормальном режиме работы не имеет отношения к HAP и нами рассматриваться не будет. Главное, что хочется отметить: в режиме HAP BUP выполняет всю инициализацию платформы (ICC, Boot Guard), но не запускает основные процессы ME.

Рисунок 11. Определение режима HAP

Рисунок 12. Перевод ME в пятую стадию, что равноценно зависанию

Рисунок 13. Пятая стадия

Установка HAP-бита

Исходя из вышесказанного, второй вариант отключения состоит в установке HAP-бита и удалении или повреждении всех модулей, кроме тех, которые необходимы BUP для старта — RBE, KERNEL, SYSLIB, BUP. Сделать это можно просто убрав их из CPD-раздела FTPR и пересчитав контрольную сумму заголовка CPD (подробнее структура прошивки ME описана тут).

Остается еще один вопрос: как установить этот бит? Можно воспользоваться конфигурационными файлами FIT и определить, где он расположен в образе, но есть путь проще. Если открыть FIT, то в секции ME Kernel можно найти некий параметр Reserved. Именно этот бит и отвечает за включение режима HAP.

Рисунок 14. Бит активации режима HAP

HAP и Boot Guard

Нами также был найден код в BUP, который при активированном режиме HAP устанавливает дополнительный бит в политиках Boot Guard. К сожалению, выяснить, чем управляет этот бит, нам пока не удалось.

Рисунок 15. Установка дополнительного бита для Boot Guard

Поддержка ME 11 в me_cleaner

Пока эта статья готовилась к печати, разработчики обновили me_cleaner, в результате чего он стал так же удалять из образов все модули, кроме RBE, KERNEL, SYSLIB и BUP, но без установки HAP-бита, что вводит ME в режим «TemporaryDisable». Нам стало любопытно, что происходит при таком подходе.

Мы выяснили, что удаление разделов с файловой системой ME приводит к ошибке при чтении файла cfg_rules. Данный файл содержит ряд различных настроек системы. Среди них, как мы полагаем, есть флаг, который мы назвали «bup_not_temporary_disable». Если он не установлен, вся подсистема переводится в режим TemporaryDisable, а так как этот флаг – глобальная переменная, по умолчанию инициализированная нулем, то ошибка чтения расценивается как конфигурация, требующая отключения.

Отметим также, что мы проверили также прошивки от серверной и мобильной версии ME (SPS 4.x и TXE 3.x). В серверной версии этот флаг всегда устанавливается в 1, а в мобильно не анализируется. Из вышесказанного следует, что данный способ не сможет работать на серверных и мобильных версиях (Apollo Lake) ME.

Рисунок 16. Чтение файла cfg_rules

Вместо заключения

Таким образом, мы нашли недокументированный PCH strap, который позволяет перевести Intel ME в режим отключения на ранней стадии. Хотя физическое удаление модулей из образа с сохранением работоспособности неявно доказывает, что этот режим производит отключение ME, бинарный анализ не оставляет поводов для сомнений. C большой долей уверенности можно сказать, что выйти из этого режима Intel ME уже не в состоянии, так как в модулях RBE, KERNEL и SYSLIB не найдено кода, который позволяля бы это осуществлять. Также мы считаем, что ROM, интегрированный в PCH, практически не отличается от ROMB, в котором тоже не найдено ничего похожего. Таким образом, HAP позволит защититься от уязвимостей, присутствующих во всех модулях, кроме RBE, KERNEL, SYSLIB, ROM и BUP, но, к сожалению, от эксплуатации ошибок на более ранних этапах этот режим не предохранит.

Мы ознакомили представителей Intel с деталями исследования. Их ответ подтвердил нашу догадку о связи недокументированного режима с программой High Assurance Platform. С разрешения компании приведем отрывок из ответа:

Mark/Maxim,
In response to requests from customers with specialized requirements we sometimes explore the modification or disabling of certain features. In this case, the modifications were made at the request of equipment manufacturers in support of their customer’s evaluation of the US government’s “High Assurance Platform” program. These modifications underwent a limited validation cycle and are not an officially supported configuration.

Мы полагаем, что данный механизм — удовлетворение обычной просьбы любой правительственной службы, которая хочет уменьшить вероятность утечки по побочным каналам. Но остается главный вопрос: как HAP влияет на функционирование Boot Guard? Из-за закрытости этой технологии ответить на этот вопрос пока не представляется возможным, но мы надеемся, что в скором будущем нам это удастся.

Авторы: Горячий Максим, Ермолов Марк

• intel ME
• отключение intel me

• Блог компании Positive Technologies
• Информационная безопасность

Боремся с дистанционным контролем: как отключить Intel ME

Технология Intel ME (или AMT, Active Management Technology) является одним из самых загадочных и мощных элементов современных x86-платформ. Инструмент изначально создавался в качестве решения для удаленного администрирования. Однако он обладает столь мощной функциональностью и настолько неподконтролен пользователям Intel-based устройств, что многие из них хотели бы отключить эту технологию, что сделать не так-то просто.

На прошедшем 17 и 18 мая в Москве форуме Positive Hack Days VI исследователи Positive Technologies Максим Горячий и Марк Ермолов представили несколько техник отключения Intel ME, сопроводив доклад видеодемонстрацией процесса.

Что это, и зачем нужно отключать Подсистема Intel Management Engine (ME) представляет собой дополнительный «скрытый» процессор, который присутствует во всех устройствах на базе чипсетов Intel (не только в PC и ноутбуках, но и в серверах). Среда исполнения ME никогда не «спит» и работает даже при выключенном компьютере (при наличии дежурного напряжения), а также имеет доступ к оперативной памяти, сетевому интерфейсу, USB контроллеру и встроенному графическому адаптеру.

Боремся с дистанционным контролем: как отключить Intel ME

Технология Intel ME (или AMT, Active Management Technology) является одним из самых загадочных и мощных элементов современных x86-платформ. Инструмент изначально создавался в качестве решения для удаленного администрирования. Однако он обладает столь мощной функциональностью и настолько неподконтролен пользователям Intel-based устройств, что многие из них хотели бы отключить эту технологию, что сделать не так-то просто.

На прошедшем 17 и 18 мая в Москве форуме Positive Hack Days VI исследователи Positive Technologies Максим Горячий и Марк Ермолов представили несколько техник отключения Intel ME, сопроводив доклад видеодемонстрацией процесса.

Что это, и зачем нужно отключать

Подсистема Intel Management Engine (ME) представляет собой дополнительный «скрытый» процессор, который присутствует во всех устройствах на базе чипсетов Intel (не только в PC и ноутбуках, но и в серверах). Среда исполнения ME никогда не «спит» и работает даже при выключенном компьютере (при наличии дежурного напряжения), а также имеет доступ к оперативной памяти, сетевому интерфейсу, USB контроллеру и встроенному графическому адаптеру.

Несмотря на столь обширные возможности, существуют вопросы к уровню защищенности ME — ранее исследователи уже находили серьезные уязвимости и векторы атак. Кроме того, подсистема содержит потенциально опасные функции — удаленное управление, NFC, скрытый сервисный раздел (hidden service partition). Интерфейсы подсистемы ME недокументированы, а реализация закрыта.

Все эти причины приводят к тому, что многие рассматривают технологию ME в качестве «аппаратной закладки». Ситуацию усугубляет тот факт, что с одной стороны у пользователя устройства нет возможностей по отключению этой функциональности, а с другой производитель оборудования может допустить ошибки в конфигурации МЕ.

Хорошая новость заключается в том, что способы отключения ME все же существуют.

Техники отключения Intel ME

Исследователи компании Positive Technologies Максим Горячий и Марк Ермолов в ходе состоявшегося в Москве форума Positive Hack Days VI представили доклад, посвященный отключению Intel ME. Специалисты описали несколько техник отключения данной подсистемы:

1. Основанные на сбое инициализации ME;
2. Через механизм обновления микропрограммы ME;
3. Недокументированные команды
4. Недокументированный механизм, предназначенный для разработчиков аппаратуры — Manufacture Mode.

Большинство методов отключения используют встроенные механизмы ME, разработанные для вендоров устройств на платформе Intel. Все они подробно описаны в презентации, которая опубликована на GitHub. По ссылке представлено демонстрационное видео отключения ME (оно же ниже):

И тем не менее, возникает резонный вопрос: «Действительно ли ME перестает работать в полном объеме при использовании ее встроенных механизмов отключения?» В качестве доказательства факта отключения МЕ исследователи приводят следующий аргумент: ME работает в двух режимах использования памяти: только SRAM (встроенный в ME) и SRAM + UMA. UMA — это часть памяти хоста, которая используется как подкачиваемая память (swap). После инициализации DRAM-контроллера хостом ME всегда переключается в режим SRAM + UMA.

Таким образом, если ME действительно выключена, то при отключении на аппаратном уровне доступа МЕ к UMA-памяти в произвольный момент (посредствам канала VСm), в МЕ не будет происходить аппаратных сбоев, связанных с отсутствием данных и кода, которые были вытеснены в UMA память (такие аппаратные сбои приводят к аварийному отключению питания с основных аппаратных компонентов платформы). С другой стороны применение этих методов позволяет осуществить DoS-атаки на технологию AMT в случае ее применения для удаленного управления.

Видеозапись доклада опубликована на сайте PHDays — нужно найти в списке выступление под названием «How to Become the Sole Owner of Your PC».

• Intel ME
• аппаратные закладки
• информационная безопасность
• отключение Intel ME

• Блог компании Positive Technologies
• Информационная безопасность
• Системное программирование

О подсистеме Intel ME и ее отключении

Начиная с 2006 года на всех материнских платах компьютеров с процессорами Intel устанавливается микроконтроллер подсистемы ME (в современных компьютерах он интегрирован в чипсет).

Его назначение и функционал большинству пользователей непонятны.

Официально Intel® ME — это маленькая, мало потребляющая энергию компьютерная подсистема, которая выполняет различные задачи в спящем режиме, во время запуска компьютера и во время его работы.

Фрагмент вывода команды hwinfo, показывающий информацию о контроллере Intel 200 Series PCH CSME HECI, отвечающем за работу подсистемы Intel ME на компьютере с материнской платой Gigabyte Z370P D3:

31: PCI 16.0: 0780 Communication controller [Created at pci.386] Unique ID: WnlC.+ignOUsuRuB SysFS ID: /devices/pci0000:00/0000:00:16.0 SysFS BusID: 0000:00:16.0 Hardware Class: unknown Device Name: "Onboard - Other" Model: "Intel 200 Series PCH CSME HECI #1" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0xa2ba "200 Series PCH CSME HECI #1" SubVendor: pci 0x1458 "Gigabyte Technology Co., Ltd" SubDevice: pci 0x1c3a Driver: "mei_me" Driver Modules: "mei_me" Memory Range: 0xf7f2d000-0xf7f2dfff (rw,non-prefetchable) IRQ: 137 (39 events) Module Alias: "pci:v00008086d0000A2BAsv00001458sd00001C3Abc07sc80i00" Driver Info #0: Driver Status: mei_me is active Driver Activation Cmd: "modprobe mei_me" Config Status: cfg=new, avail=yes, need=no, active=unknown

Что такое и зачем нужна подсистема Intel ME?

Модуль Intel ME изначально назывался Intel Manageability Engine, затем — Intel Management Engine, а также Converged Security and Manageability Engine (CSME) или сокращенно Converged Security Engine (CSE).

В ноутбуках и embedded-компьютерах эта система называется Trusted Execution Engine (TXE), а на серверах — Server Platform Services (SpS).

Первая версия (ME 1.0) появилась в 2005 году, вторая (встроенная в северный мост) — в 2006-м. В 2007-м году были созданы ME 3.0 для desktop-ов и ME 4.0 — для мобильных устройств. Очередные релизы Intel ME затем стали регулярно обновляться, например:

• в 2009 году вышла версия AMT/ME 6.0 (превая PCH платформа), а также ME Gen 2 (для ARC600 CPU), добавлена поддержка KVM (на основе протокола VNC);
• в 2011-м — появилось обновление ME 7.1 DAL (Dynamic Application Loader) для IPT/OTP;
• в 2014 году вышел ME 10.0;
• в 2015 — ME 11.0.

Программная часть кода Intel ME прописана в BIOS материнской платы:

Intel ME имеет собственную маленькую память (SRAM), потребляет очень мало энергии. Подсистема способна читать данные на PC без ведома пользователя (шпионить за ним) и в некоторых случаях даже может дистанционно отключать компьютер. Фактически, Intel ME — это шпионский backdoor.

Intel ME firmware активна, даже если компьютер находится в дежурном режиме (состояние sleeping/hibernating).

Intel Management Engine может читать/писать данные RAM с помощью функционала DMA, а также используется для:

• менеджмента служб Low-power, out-of-band (OOB);
• управления службой Capability Licensing Service (CLS)
• реализации функционала Anti-Theft Protection и Protected Audio Video Path (PAVP);
• может осуществлять доступ и контроль функций AMT/vPro, TPM (Trusted Platform Module), QST (fan control), ICC (Integrated Clock Control), DAL (IPT/OTP), SWC (Silicon Workaround Capability).

В современных компьютерах для питания подсистемы Intel ME, используется отдельная линия. Таким образом, работа Intel® Management Engine не зависит от операционной системы компьютера, функционируя независимо от ядра.

Когда компьютер работает (состояние процессора S0/M0), подсистема Intel ME работает следующим образом:

Когда компьютер находится в дежурном режиме (состояние CPU S3/M1), подсистема Intel ME продолжает ограниченно работать:

Лишь когда, компьютер обесточен, подсистема Intel ME отдыхает (находится в состоянии S3/M-off):

Так как обычному пользователю функционал Intel ME не нужен, сторонники теории заговора предполагают, что эта подсистема создана и работает в интересах американского Агентства национальной безопасности. Правда это или нет, каждый может судить сам…

Как отключить Intel Manageability Engine?

Функционал современной Intel ME невозможно полностью отключить, так как в противном случае компьютер перестанет работать.

Зато можно отключить большинство ненужных пользователю функций это подсистемы, отредактировав BIOS, попутно увеличив быстродействие и надежность работы компьютера.

На компьютерах, использующих Intel ME 6.0 (модели, выпускавшиеся до 2008-2009 годов) включительно, ее можно полностью отключить.

Более современные версии Intel ME используются для инициализации оборудования и power-менеджмента, поэтому на них полностью отключить эту подсистему нельзя.

Функционал Intel ME компьютеров под управлением Linux можно максимально ограничить с помощью открытого программного обеспечения coreboot.

На любом компьютере можно прошить очищенную от Intel Meпрошивку, которую можно сделать с помощью утилиты me_cleaner.

me_cleaner – это программа написанная Nicola Corna на Python, которая может частично отключить функционал ME для компьютеров с процессорами Intel, начиная с архитектуры Nehalem и новее.

После модификации уменьшается реальный размер BIOS, что значительно сокращает время загрузки компьютера, а также улучшает стабильность его работы.

Для использования me_cleaner используется оригинальный файл BIOS (original_dump.bin), который модифицируется командой

python me_cleaner.py -S -O modified_image.bin original_dump.bin

Модифицированный файл (modified_image.bin) нужно записать на микросхему SPI-флеш BIOS вместо родного BIOS, либо штатной утилитой, либо с помощью программатора.

Для устранения возможных проблем перед прошивкой обязательно нужно сохранить в безопасное место ориганальную версию BIOS.

Отключение функционала Intel ME на примере материнской платы Gigabyte Z370P D3

На плате Gigabyte Z370P D3 можно модифицировать прошивку BIOS и без программатора, с помощью одной из утилит со страницы HowToReflashBIOS.

Автором использовалась оригинальная версия bios, скачанная с сайта производителя и утилита Q-Flash, встроенная в BIOS.

Для очищения BIOS от функционала Intel ME:

• скачиваем оригинальный BIOS с сайта производителя:

• распаковываем архив, копируем оригинал BIOS и и модифицируем его скриптом me_cleaner:

python me_cleaner.py -S -O Z370PD3_mod.bin Z370PD3.F15

• получаем вывод с сообщением об успехе (в конце: Checking the FTPR RSA signature… VALID

Done! Good luck!): Full image detected The ME/TXE region goes from 0x3000 to 0x200000 Found FPT header at 0x3010 Found 11 partition(s) Found FTPR header: FTPR partition spans from 0x1000 to 0xa8000 Found FTPR manifest at 0x1448 ME/TXE firmware version 11.8.81.3807 Public key match: Intel ME, firmware versions 11.x.x.x The HAP bit is NOT SET Reading partitions list. FTPR (0x00001000 - 0x0000a8000, 0x000a7000 total bytes): NOT removed FTUP (0x00110000 - 0x0001bc000, 0x000ac000 total bytes): removed DLMP ( no data here , 0x00000000 total bytes): nothing to remove PSVN (0x00000e00 - 0x000001000, 0x00000200 total bytes): removed IVBP (0x0010c000 - 0x000110000, 0x00004000 total bytes): removed MFS (0x000a8000 - 0x00010c000, 0x00064000 total bytes): removed NFTP (0x00110000 - 0x0001bc000, 0x000ac000 total bytes): removed ROMB ( no data here , 0x00000000 total bytes): nothing to remove FLOG (0x001bc000 - 0x0001bd000, 0x00001000 total bytes): removed UTOK (0x001bd000 - 0x0001bf000, 0x00002000 total bytes): removed ISHC ( no data here , 0x00000000 total bytes): nothing to remove Removing partition entries in FPT. Removing EFFS presence flag. Correcting checksum (0x54). Reading FTPR modules list. FTPR.man (uncompressed, 0x001448 - 0x002000): NOT removed, partition manif. rbe.met (uncompressed, 0x002000 - 0x002096): NOT removed, module metadata kernel.met (uncompressed, 0x002096 - 0x002124): NOT removed, module metadata syslib.met (uncompressed, 0x002124 - 0x002188): NOT removed, module metadata bup.met (uncompressed, 0x002188 - 0x00274a): NOT removed, module metadata pm.met (uncompressed, 0x00274a - 0x0027f8): NOT removed, module metadata vfs.met (uncompressed, 0x0027f8 - 0x003124): NOT removed, module metadata evtdisp.met (uncompressed, 0x003124 - 0x0032b2): NOT removed, module metadata loadmgr.met (uncompressed, 0x0032b2 - 0x0033da): NOT removed, module metadata busdrv.met (uncompressed, 0x0033da - 0x00375e): NOT removed, module metadata gpio.met (uncompressed, 0x00375e - 0x0038a8): NOT removed, module metadata prtc.met (uncompressed, 0x0038a8 - 0x003a58): NOT removed, module metadata policy.met (uncompressed, 0x003a58 - 0x003c18): NOT removed, module metadata crypto.met (uncompressed, 0x003c18 - 0x003da2): NOT removed, module metadata heci.met (uncompressed, 0x003da2 - 0x003f6e): NOT removed, module metadata storage.met (uncompressed, 0x003f6e - 0x00426a): NOT removed, module metadata pmdrv.met (uncompressed, 0x00426a - 0x00438e): NOT removed, module metadata maestro.met (uncompressed, 0x00438e - 0x004478): NOT removed, module metadata fpf.met (uncompressed, 0x004478 - 0x004590): NOT removed, module metadata hci.met (uncompressed, 0x004590 - 0x004692): NOT removed, module metadata fwupdate.met (uncompressed, 0x004692 - 0x00479a): NOT removed, module metadata ptt.met (uncompressed, 0x00479a - 0x0048a6): NOT removed, module metadata touch_fw.met (uncompressed, 0x0048a6 - 0x0049c0): NOT removed, module metadata rbe (Huffman , 0x0049c0 - 0x007240): NOT removed, essential kernel (Huffman , 0x007240 - 0x017280): NOT removed, essential syslib (Huffman , 0x017280 - 0x0285c0): NOT removed, essential bup (Huffman , 0x0285c0 - 0x053040): NOT removed, essential pm (LZMA/uncomp., 0x053040 - 0x055300): removed vfs (LZMA/uncomp., 0x055300 - 0x05d600): removed evtdisp (LZMA/uncomp., 0x05d600 - 0x05efc0): removed loadmgr (LZMA/uncomp., 0x05efc0 - 0x061e40): removed busdrv (LZMA/uncomp., 0x061e40 - 0x0636c0): removed gpio (LZMA/uncomp., 0x0636c0 - 0x0647c0): removed prtc (LZMA/uncomp., 0x0647c0 - 0x065340): removed policy (LZMA/uncomp., 0x065340 - 0x06a080): removed crypto (LZMA/uncomp., 0x06a080 - 0x077d40): removed heci (LZMA/uncomp., 0x077d40 - 0x07bc00): removed storage (LZMA/uncomp., 0x07bc00 - 0x080040): removed pmdrv (LZMA/uncomp., 0x080040 - 0x0811c0): removed maestro (LZMA/uncomp., 0x0811c0 - 0x082f40): removed fpf (LZMA/uncomp., 0x082f40 - 0x084900): removed hci (LZMA/uncomp., 0x084900 - 0x085180): removed fwupdate (LZMA/uncomp., 0x085180 - 0x089e80): removed ptt (LZMA/uncomp., 0x089e80 - 0x09f6c0): removed touch_fw (LZMA/uncomp., 0x09f6c0 - 0x0a8000): removed The ME minimum size should be 360448 bytes (0x58000 bytes) The ME region can be reduced up to: 00003000:0005afff me Setting the HAP bit in PCHSTRP0 to disable Intel ME. Checking the FTPR RSA signature. VALID Done! Good luck!

Каталог со скриптом me_cleaner.py и файлами bios:

Как видно из примера, me_cleaner удалил из BIOS материнской платы Gigabyte Z370P D3 восемнадцать (!) модулей: pm, vfs, evtdisp, loadmgr, busdrv, gpio, prtc, policy, crypto, heci, storage, pmdrv, maestro, fpf, hci, fwupdate, ptt и touch_fw.

• прошиваем модифицированный Bios (файл Z370PD3_mod.bin) любым удобным способом, например, штатной утилитой Q-Flash (для этого нужно сохранить файл BIOS на флешку);

При прошивке модифицированного BIOS на материнскую плату Gigabyte Z370P D3 утилита Q-Flash показывает разницу прошиваемого файла (версия Fast) с оригиналом (Intact):

• наслаждаемся работой компьютера без шпионского модуля Intel ME.

После прошивки модифицированого BIOS компьютер стал работать ощутимо быстрее, загрузка памяти также уменьшилась.

Hwinfo теперь не видит шпионского устройства PCI 16.0: 0780 Communication controller. Потребление процессора хоть и незначительно, но снизилось, что положительно сказалось на его температуре при майнинге.

P.S. В ubuntu 22.04 предустановлен python3, поэтому команда для модификации BIOS выглядит так:

python3 me_cleaner.py -S -O modified_image.bin original_dump.bin

Вам также может понравиться

Использование radeontop для получения информации о загруженности видеокарт AMD в Linux

25 марта, 2021

Как отменить или заменить транзакцию, зависшую в сети Ethereum

30 июня, 2020