Комментарии 8
Спасибо за статью, отличная.
Лучшим вариантом было бы добавить в прошивку свой SMM модуль, который UEFI бы легально разместил в SMRAM, чтобы не беспокоиться, что нашим кодом будет перезаписано что-то важное.Вот тут можно сделать еще один шаг — если возможность внедрения собственного кода уже имеется, то можно предоставить собственный обработчик на незадействованный номер SMI, в котором будет не только необходимый шелл-код, но и патчер для всех остальных обработчиков, к которым несложно получить доступ (они связаны в глобальный список mSmiEntryList, и можно итерироваться по нему):
Я правильно вспоминаю, что можно сначала в Uefi Shell загрузить свой драйвер, а потом — загрузить ОС?
В данном случае из шелла уже не выйдет, потому что SMM Dispatching к тому моменту давно уже закончился, и новые SMM-драйверы оттуда уже не запустить, так что придется нужный драйвер все равно в прошивку добавлять. Раньше там был баг с тем, что ОРОМы могли запускаться раньше, чем SMM-фаза заканчивалась, но его исправили довольно давно, и сейчас на него надеяться мало смысла.
За статью спасибо.
На Skylake и свежее (где PT идет с временными метками на каждый TIP-пакет, плюс оверхед ниже чем на бродвеле) это нормальное поведение — сначала PSB-шапка, а уже потом идет TIP.PGE
Закиньте пожалуйста багу в репозиторий libipt
Зачем трогали IA32_RTIT_STATUS.PacketByteCn я не понял — у вас там какие-то неизвестные мне side-эффекты возникают?
В нормальном случае во время входа в SMI вы получите traceEn = False
Внутри включите TraceEn = true трасса продолжит генерироваться с текущего момента, а если пора шапку воткнуть — то железо дополнительно воткнет шапку.
PSB-шапка генерируется аппаратно на лету и не должна мешать генерации PT. Можете пояснить что именно у вас происходит?
Создатель winIPT к слову реверс-инжинирил ipt.sys и не гарантирует стабильную работу всего этого безобразия. perf 4.4+ в этом плане более практичен. Работает там все из коробки. Можно попробовать что-то типа perf record -e intel_pt\\
если PSB генерируется до PGE, то ptxed не может синхронизоваться по нему.
На Skylake и свежее (где PT идет с временными метками на каждый TIP-пакет, плюс оверхед ниже чем на бродвеле) это нормальное поведение — сначала PSB-шапка, а уже потом идет TIP.PGE
Закиньте пожалуйста багу в репозиторий libipt
Зачем трогали IA32_RTIT_STATUS.PacketByteCn я не понял — у вас там какие-то неизвестные мне side-эффекты возникают?
В нормальном случае во время входа в SMI вы получите traceEn = False
Внутри включите TraceEn = true трасса продолжит генерироваться с текущего момента, а если пора шапку воткнуть — то железо дополнительно воткнет шапку.
PSB-шапка генерируется аппаратно на лету и не должна мешать генерации PT. Можете пояснить что именно у вас происходит?
Создатель winIPT к слову реверс-инжинирил ipt.sys и не гарантирует стабильную работу всего этого безобразия. perf 4.4+ в этом плане более практичен. Работает там все из коробки. Можно попробовать что-то типа perf record -e intel_pt\\
от автора:
Нам необходимо сбросить этот счетчик, иначе во время обработки трассы Intel PT будет пропущен момент входа в SMM, и трасса Ассемблера начнется со случайного места, когда PSB будет сгенерирован естественным образом.
Суть такая — трасса писаться будет, но вот при включении (traceEn=1) PSB не сгенерится. И ptxed не увидит код до момента естественной генерации PSB. Трасса писалась в юзермоде, стопнулась и вдруг стартовала в SMM, при этом блока синхронизации нет и парсер тупо выкинет весь код от входа в SMM до ближайшего PSB, так как не может понять где он (по IP из tip.pge он не умеет синхронизироваться вроде как).
Сбивая счетчик мы форсируем его сгенерить блок как можно скорее и закинуть в трассу инфу для синхронизации.
Зачем трогали IA32_RTIT_STATUS.PacketByteCn я не понял — у вас там какие-то неизвестные мне side-эффекты возникают?
Нам необходимо сбросить этот счетчик, иначе во время обработки трассы Intel PT будет пропущен момент входа в SMM, и трасса Ассемблера начнется со случайного места, когда PSB будет сгенерирован естественным образом.
Суть такая — трасса писаться будет, но вот при включении (traceEn=1) PSB не сгенерится. И ptxed не увидит код до момента естественной генерации PSB. Трасса писалась в юзермоде, стопнулась и вдруг стартовала в SMM, при этом блока синхронизации нет и парсер тупо выкинет весь код от входа в SMM до ближайшего PSB, так как не может понять где он (по IP из tip.pge он не умеет синхронизироваться вроде как).
Сбивая счетчик мы форсируем его сгенерить блок как можно скорее и закинуть в трассу инфу для синхронизации.
Теперь понял. На такое поведение ptxed тоже можете багу отправить :)
Вообще, после включения TraceEn = 1 в трассу сгенерируется пакет TIP.PGE, у которого полезной нагрузкой пойдет IP-адрес с которого мы стартовали. Этого достаточно для дальнейшего binary декодинга, но похоже что ptxed считает иначе.
Вообще, после включения TraceEn = 1 в трассу сгенерируется пакет TIP.PGE, у которого полезной нагрузкой пойдет IP-адрес с которого мы стартовали. Этого достаточно для дальнейшего binary декодинга, но похоже что ptxed считает иначе.
А зачем нужна трасса SMM-кода? Он же не такой большой и вполне анализируется статически?
1. Альтернатива отладке. Код SMM довольно проблематично отлаживать на продакшн системах. Например, нашел уязвимость, но ожидаемого эффекта от эксплоита не происходит. При помощи трассы можно определить, в каком месте поток исполнения двинулся не в том направлении.
2. Покрытие кода. При написании умного фаззера для кода SMM необходимо знать покрытие кода, но существующие методы инструментации не способны работать в SMM.
2. Покрытие кода. При написании умного фаззера для кода SMM необходимо знать покрытие кода, но существующие методы инструментации не способны работать в SMM.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование Intel Processor Trace для трассировки кода System Management Mode