Комментарии 21
Статья отличная, спасибо, но «что делать, чтобы собрать данные для графа» было в принципе ясно с самого начала, и сложность там не в отсутствии хороших идей, а в отсутствии реализаций этих хороших идей. Вот и тут видит око, а исходников нет.
Нужна эта функция на самом деле буквально паре человек, а автоматизация ее прямо в UEFITool'е потребует включения туда дизассемблера, поиска по сигнатурам и затем сотен часов отладки еще. Гораздо лучше, на мой взгляд, со стороны UT ограничится UEFIDump'ом и все дальнейшее делать скриптами для IDA/R2/Binja/чтотамувас, потому что оно все специально под подобные задачи заточено.
Нужна эта функция на самом деле буквально паре человек, а автоматизация ее прямо в UEFITool'е потребует включения туда дизассемблера, поиска по сигнатурам и затем сотен часов отладки еще. Гораздо лучше, на мой взгляд, со стороны UT ограничится UEFIDump'ом и все дальнейшее делать скриптами для IDA/R2/Binja/чтотамувас, потому что оно все специально под подобные задачи заточено.
Естестественно, это было понятно, что и как, но не у всех такой богатый опыт, как у Вас, Николай!
Кто-то ещё только начинает, пусть это будет просто Tutorial.
Да, основная задача — реверс. Решил начать не с него — небольшая интрига!
Я и сам начинал не с исходников типа «Teano...», а именно с реверса.
Кстати, всё не так уж и тривиально там сделать. И, например, даже готового скрипта на чем бы то ни было будет не достаточно. Очень существенная вещь при дизассемблировании/декомпиляции — «метаданные». Как они выглядят, как организованы — будет существенно зависеть от средства, которым пользуемся… Но это отдельная тема — есть планы, но время покажет…
Кто-то ещё только начинает, пусть это будет просто Tutorial.
Да, основная задача — реверс. Решил начать не с него — небольшая интрига!
Я и сам начинал не с исходников типа «Teano...», а именно с реверса.
Кстати, всё не так уж и тривиально там сделать. И, например, даже готового скрипта на чем бы то ни было будет не достаточно. Очень существенная вещь при дизассемблировании/декомпиляции — «метаданные». Как они выглядят, как организованы — будет существенно зависеть от средства, которым пользуемся… Но это отдельная тема — есть планы, но время покажет…
Если бы там было тривиально, уже были бы публичные готовые решения, а пока более менее готовое что-то есть только у Педро (EfiSwissKnife).
С другой стороны, даже не готовое, кривое и на коленке — сильно лучше, чем ничего., поэтому даже такие «сугубо теоретические» статьи я поддерживаю всеми руками. Если найдете возможность выложить что-то — отлично, если нет — другим будет проще подступиться к проблеме.
С другой стороны, даже не готовое, кривое и на коленке — сильно лучше, чем ничего., поэтому даже такие «сугубо теоретические» статьи я поддерживаю всеми руками. Если найдете возможность выложить что-то — отлично, если нет — другим будет проще подступиться к проблеме.
В настоящий момент мне проще «выдать» готовый результат (по запросу), чем решение. В данный момент это больше набор методик решения задачи. Кое-где надо напильничком! Хотя практически всё можно на автомате решать!
А публичных готовых решений и не будет! Вот в этом я точно уверен!
А законченных решений и не может быть вообще!
В принципе, для того, чтоб получить описанный результат, мне понадобилось немало времени. Да и работа не закончена!
Кстати, как написал в «Заключении», задача была не в получении графа зависимостей, он — бонус.
Да, для DXE объём побольше, а методически всё попроще.
"...Knife" смотрел мельком, но там вроде точность невысокая…
А публичных готовых решений и не будет! Вот в этом я точно уверен!
А законченных решений и не может быть вообще!
В принципе, для того, чтоб получить описанный результат, мне понадобилось немало времени. Да и работа не закончена!
Кстати, как написал в «Заключении», задача была не в получении графа зависимостей, он — бонус.
Да, для DXE объём побольше, а методически всё попроще.
"...Knife" смотрел мельком, но там вроде точность невысокая…
>> пожелание пользователей: построить «Dependency Graph» для исполняемых модулей
а зачем?
Дизассемблировав и поняв логику, перегнать ее в coreboot?
а зачем?
Дизассемблировав и поняв логику, перегнать ее в coreboot?
Сомнительно. Задачи разные бывают.
Флаг вам в руки, если сможете это выполнить. Правда с засильем ME/PSP теряется весь смысл. Я уже давно забил на попытки понять логику настройки памяти(новее DDR2) даже по исходникам.
>> с засильем ME/PSP теряется весь смысл
а выкусывать их из оригинальных БИОСов, не способ?
>>Флаг вам в руки, если сможете это выполнить.
это работа, чуть ли не на года, по каждому из чипсетов.
Делать это на авось, бесплатно, потешить самолюбие, интересно первые пару месяцев, не более.
>> попытки понять логику настройки памяти
Да, новее DDR2 это лес.
В это даже АМИ не ввязывается, просто подвязывая код от Интел/АМД.
а выкусывать их из оригинальных БИОСов, не способ?
>>Флаг вам в руки, если сможете это выполнить.
это работа, чуть ли не на года, по каждому из чипсетов.
Делать это на авось, бесплатно, потешить самолюбие, интересно первые пару месяцев, не более.
>> попытки понять логику настройки памяти
Да, новее DDR2 это лес.
В это даже АМИ не ввязывается, просто подвязывая код от Интел/АМД.
Ну с ME положим переключить в АНБ режим можно, а что делать с PSP, который вообще основным x86 ядрам ресет не снимет, пока всё не проверит, плюс не удостоверится, что прошивка подписана, режим «йа разработчег» там есть, но AMD во всех бумагах ставит полный запрет выпуска такой платы в продажу и вообще куда-то дальше самих разработчиков. Я три года назад уже пришел к выводу, что полный OpenSource PC x86 это фантастика, либо компьютер образца 2011-14 года максимум, остается ARM архитектура, но у неё проблемы с производительностью и универсальностью. Ещё можно на Talos 2 посмотреть, но опять проблема с софтом и ещё более редкой архитектурой.
Собственно вся трудоёмкость этого реверса и выливается в то, что никто этого не делает за редким исключением (KGPE-D16 может быть примером обратного, но я хз, что там рапторовцы делали на самом деле, может по полным даташытам переписали код)
Собственно вся трудоёмкость этого реверса и выливается в то, что никто этого не делает за редким исключением (KGPE-D16 может быть примером обратного, но я хз, что там рапторовцы делали на самом деле, может по полным даташытам переписали код)
НЛО прилетело и опубликовало эту надпись здесь
Извините, не понял идею, очень уж она сумбурно выражена. Ну меняйте изменённый модуль, есть для этого MMTool или UEFITool (в тех случаях, когда она работает — но в PEI томе у неё как раз проблемы). Кто мешает-то?
Вообще-то информация типа последнего списка наиболее полезна как раз разработчикам.
Она покажет, какие интерфейсы вообще не работают, где перекосы, возможный «мёртвый» код.
Дело в том, что увидеть по исходникам подобные вещи — весьма нетривиальное занятие.
Те, кто видел даже древние утекшие исходники Aptio IV, тот это должен понимать.
Я не останавливался на том, где может понадобиться подобного рода информация, но для аналитиков из команды разработчиков подобная информация была бы не заменима.
Даже с точки зрения информационной безопасности, подобные дыры — это дар, место, где можно размещать свои поделки, т.е. места «повышенного внимания».
Вообще-то я уже не в первый раз пишу, что описанные результаты — это всего-навсего бонус, дополнительная возможность, реверс позволяет получать дополнительную информацию, проводить доп. анализ.
На PEI-фазе, например, можно проанализировать, кто и какие HOB-ы создаёт и как их использует, а потом посмотреть это же и на DXE фазе.
И это так — самые простенькие идеи.
Другое дело, что я не описывал, как в реалити это можно делать, но там места надо раза в 2-4 больше, если только кратенько.
Результаты определённые есть, идей хватает, возможно и продолжение (развитие).
Статический анализ бинарного кода — штука весьма занятная.
Вообще-то информация типа последнего списка наиболее полезна как раз разработчикам.
Она покажет, какие интерфейсы вообще не работают, где перекосы, возможный «мёртвый» код.
Дело в том, что увидеть по исходникам подобные вещи — весьма нетривиальное занятие.
Те, кто видел даже древние утекшие исходники Aptio IV, тот это должен понимать.
Я не останавливался на том, где может понадобиться подобного рода информация, но для аналитиков из команды разработчиков подобная информация была бы не заменима.
Даже с точки зрения информационной безопасности, подобные дыры — это дар, место, где можно размещать свои поделки, т.е. места «повышенного внимания».
Вообще-то я уже не в первый раз пишу, что описанные результаты — это всего-навсего бонус, дополнительная возможность, реверс позволяет получать дополнительную информацию, проводить доп. анализ.
На PEI-фазе, например, можно проанализировать, кто и какие HOB-ы создаёт и как их использует, а потом посмотреть это же и на DXE фазе.
И это так — самые простенькие идеи.
Другое дело, что я не описывал, как в реалити это можно делать, но там места надо раза в 2-4 больше, если только кратенько.
Результаты определённые есть, идей хватает, возможно и продолжение (развитие).
Статический анализ бинарного кода — штука весьма занятная.
НЛО прилетело и опубликовало эту надпись здесь
Если вы про полезное применение UEFITool, то их масса полезных уже сейчас, но в билды встраивать именно эту утилиту я все равно не стал бы, даже если результат получился бы немного быстрее, чем у нынешней билд-системы в EDK2 (которая тормозит просто забей) — надежность низкая, плюс всякие вендорские фишки поддерживаются весьма слабо.
С последним предложением я бы очень сильно поспорил, потому что в теории теория от практики тоже не отличается, а на практике всю цепочку доверия большинства IBV и OEM уже не раз обходили, и еще не раз обойдут, потому что никто вообще не заморачивается проверкой того, что занятие то действительно бесполезное. А когда начали проверять, неожиданно оказалось, что вся «защита» обходится удалением драйвера BootGuardDxe, который раньше на бит в HOBе реагировал, при помощи упомянутого уже UEFITool'а, упс.
С последним предложением я бы очень сильно поспорил, потому что в теории теория от практики тоже не отличается, а на практике всю цепочку доверия большинства IBV и OEM уже не раз обходили, и еще не раз обойдут, потому что никто вообще не заморачивается проверкой того, что занятие то действительно бесполезное. А когда начали проверять, неожиданно оказалось, что вся «защита» обходится удалением драйвера BootGuardDxe, который раньше на бит в HOBе реагировал, при помощи упомянутого уже UEFITool'а, упс.
НЛО прилетело и опубликовало эту надпись здесь
Атакуют при этом чаще всего не идею, а реализацию.
Intel BootGuard сам по себе отработал штатно, и корень доверия он вполне себе обеспечил, т.к. в PEI-томе, накрытом им, ничего никто не менял. Зато драйвер BootGuardPei, написанный кстати именно AMI, а не OEMом, проверив хеши DXE-тома и обнаружив несовпадение из с эталоном (который тоже не даст исправить именно Intel BootGuard, потому что они в файле в PEI-томе лежат) вместо того, чтобы машину завесить или перезагрузить, поставил единицу в HOB и продолжил работу. Это потом уже BootGuardDxe должен был среагировать на эту единицу и выдать пользователю надпись «хеши поломались, все пропало», но вот незадача, его удалили уже, и потому реагировать на эту сиротливую единицу стало некому.
В итоге платформа замечательно работает с модифицированным DXE-томом, цепочка доверия нарушена, все счастливы, а Gigabyte виноват только в том, что не стал перепроверять реализацию цепочки доверия, предоставленную ему IBV.
Наверняка пофиксили, да. Если поняли, если согласовали фикс с AMI, если получили обновленный референс-код, если интегрировали его, если выпустили обновление, если запретили откат на него, если пользователь это обновление поставил. Несколько многовато если, на мой взгляд.
Intel BootGuard сам по себе отработал штатно, и корень доверия он вполне себе обеспечил, т.к. в PEI-томе, накрытом им, ничего никто не менял. Зато драйвер BootGuardPei, написанный кстати именно AMI, а не OEMом, проверив хеши DXE-тома и обнаружив несовпадение из с эталоном (который тоже не даст исправить именно Intel BootGuard, потому что они в файле в PEI-томе лежат) вместо того, чтобы машину завесить или перезагрузить, поставил единицу в HOB и продолжил работу. Это потом уже BootGuardDxe должен был среагировать на эту единицу и выдать пользователю надпись «хеши поломались, все пропало», но вот незадача, его удалили уже, и потому реагировать на эту сиротливую единицу стало некому.
В итоге платформа замечательно работает с модифицированным DXE-томом, цепочка доверия нарушена, все счастливы, а Gigabyte виноват только в том, что не стал перепроверять реализацию цепочки доверия, предоставленную ему IBV.
Наверняка пофиксили, да. Если поняли, если согласовали фикс с AMI, если получили обновленный референс-код, если интегрировали его, если выпустили обновление, если запретили откат на него, если пользователь это обновление поставил. Несколько многовато если, на мой взгляд.
Не надо лучше, не удаляйте все артефакты после успешной сборки, и повторная сборка много времени не займет.
Как разработчики спецификации не старались, все равно не получилось избавиться от всех горизонтальных и вертикальных связей, и потому такая «полевая хирургия» иногда работает хорошо, а иногда не работает никак.
Как разработчики спецификации не старались, все равно не получилось избавиться от всех горизонтальных и вертикальных связей, и потому такая «полевая хирургия» иногда работает хорошо, а иногда не работает никак.
НЛО прилетело и опубликовало эту надпись здесь
Очень много информации, нужной для 100% правильной пересборки, в образе либо нет, либо она там в крайне неудобном виде и ее придется доставать при помощи хитрого парсинга, дизассемблера и такой-то матери. Те же номера динамических PCD или AMI'шных SDL TOKENов брать неоткуда, и потому при крупных изменениях все равно придется половину пересобирать, а отличить крупные от некрупных труднее, чем не заморачиваться и собирать каждый раз заново.
На мой взгляд дискуссия уехала совсем в сторону. Ну пересборка тут совсем ни при чем.
Открою маленький секрет. Когда разбираюсь с прошивкой, то она вся в памяти и дизассемблирую и декомпилирую всё сразу (ну 32 и 64 отдельно, хотя тоже можно сразу), при этом вся память (все файлы под руками), и PCD базы и NVRAM и RAW и FREEFORM файлы.
Вот почему описываю уже результат некоторой аналитики (простейшей).
На самом деле подобной аналитики вариантов можно напридумывать.
Кому такие инструменты были бы полезны… Флаг в руки, думайте, мечтайте…
Это и фишка и проблемы, та же ИДА работает в этом случае через… (не скажу через что).
Но Ильфак вряд слушать будет, чего не хватает. Ну глюки он правит. Когда мне не лень, напрягаю его, с поддержкой у него не плохо налажено, особенно если не с ним лично взаимодействуешь!!!
Честно говоря, на последних прошивках, когда они всё в динамику толкают, даже имена файлов (нет UI-секций), с отдельным файлом разбираться — вряд ли просто.
Но полезный анализ никто не отменит.
Задачи надо правильно ставить.
Ну пытается же Интел что-то получить/доказать, используя символьную информацию.
Просто ещё один подход, кстати, как показывает практика, вполне реальный.
Не говоря уж о той проблеме, что иногда просто интересно, а соответствует ли бинари тому исходному коду, который тебе выдали?..
Открою маленький секрет. Когда разбираюсь с прошивкой, то она вся в памяти и дизассемблирую и декомпилирую всё сразу (ну 32 и 64 отдельно, хотя тоже можно сразу), при этом вся память (все файлы под руками), и PCD базы и NVRAM и RAW и FREEFORM файлы.
Вот почему описываю уже результат некоторой аналитики (простейшей).
На самом деле подобной аналитики вариантов можно напридумывать.
Кому такие инструменты были бы полезны… Флаг в руки, думайте, мечтайте…
Это и фишка и проблемы, та же ИДА работает в этом случае через… (не скажу через что).
Но Ильфак вряд слушать будет, чего не хватает. Ну глюки он правит. Когда мне не лень, напрягаю его, с поддержкой у него не плохо налажено, особенно если не с ним лично взаимодействуешь!!!
Честно говоря, на последних прошивках, когда они всё в динамику толкают, даже имена файлов (нет UI-секций), с отдельным файлом разбираться — вряд ли просто.
Но полезный анализ никто не отменит.
Задачи надо правильно ставить.
Ну пытается же Интел что-то получить/доказать, используя символьную информацию.
Просто ещё один подход, кстати, как показывает практика, вполне реальный.
Не говоря уж о той проблеме, что иногда просто интересно, а соответствует ли бинари тому исходному коду, который тебе выдали?..
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Статический анализ «BIOS/UEFI» или как получить Dependency Graph