Недавно наткнулся на эту удивительную возможность последних процов(Intel - VT-x или VanderPool, AMD - Pacifica). Написал небольшой гипервизор, все работает, входит в режим VMX-root operation и выходит. Возникла идея - написать мощный Ring0 отладчик, работающий на одной машине, как когда-то SoftIce. А то WinDBG всем хорош, но некоторые вещи нельзя отлаживать на виртуалке(ту же виртуализацию), а два компа иногда не получается организовать. Отладчик будет представлять собой VMM, который саму винду сделает виртуальной машиной и получит к ней полный доступ. Насколько это возможно, и вообще, реально ли?
кажется это называется руткит? Один из вариантов - Blue Pill от госпожи Рутковской. http://bluepillproject.org/ ЗЫ: сам с руткитами не работаю, ничего более сказать не могу.
Нет, некоторые руткиты просто используют эту технику, я же хочу написать отладчик, который будет держать всю систему в кулаке. VMM может перехватывать любые прерывания(до того, как они будут обработаны через IDT), всякие системные инструкции (типа операций с CR регистрами). Вывод на экран - прямой доступ к видеопамяти.
Предполагается, что гипервизор и будет отладчиком. Просто меня интересует, какие камни могут встретится, например, вывод на экран - собственный драйвер, как у SoftIce? Ведь SoftIce многие вещи делал сам, не полагаясь на винду, так как при отладке Винда-то висит, находится в "замороженном" состоянии.
Идея боян, только нормальной реализации по-моему еще нет) Не совсем, все-таки некоторые вещи можно юзать из обычного отладчика. А из такого гипервизорного отладчика помоему уже низя.. Само собой. Любая аппаратура - собственный драйвер. Иначе что ты там отлаживать собрался?
Идея уже обсуждалась. Баян и гуано. Во первых контроль ты будешь иметь не над всеми системными событиями. Во вторых представь, что интел вдруг что то изменит в этом механизме. И что писал то зря. Софтверные эмуляторы рулят!!
Почему не над всеми? Я могу контролировать любое исключение, любое прерывание, чтение-запись MSR, CR, LDTR, TR, GDTR, DR и пр. регистров, привелегированные инструкции, воод-вывод (IN-OUT, используя I/O bitmaps) и прочее. Полный контроль! Так надо использовать только документированные возможности, например не писать в структуру VMCS напрямую, а использовать VMREAD и VMWRITE. Предположим что написать - не проблема. Но будет ли он работать, как SoftIce, когда винда заморожена и ни один стандартный драйвер не работает? То есть вообще - какая должна быть архитектура, чтобы все работало на одной машине?
angren > Возникла идея - написать мощный Ring0 отладчик, > работающий на одной машине, как когда-то SoftIce. ... > Насколько это возможно, и вообще, реально ли? теоретически все просто. практически - нужно очень много кодить. уж лучше написать расширение для существующих отладчиков, позволяющее заюзать аппаратную виртуализацию, только не совсем понятно чем виртуализация может помочь. > я же хочу написать отладчик, который будет держать всю систему в кулаке. так и обычный отладчик может держать ее в кулаке. без виртуализации. > VMM может перехватывать любые прерывания > (до того, как они будут обработаны через IDT), а зачем? для каких интересно это таких узкоспецифичных целей нам нужно перехватывать прерывания до IDT? > всякие системные инструкции (типа операций с CR регистрами). а это еще зачем? насколько часто возникает такая необходимость? > Вывод на экран - прямой доступ к видеопамяти. не есть гуд. тот же айс юзает виндовый драйвер для вывода. > Просто меня интересует, какие камни могут встретится, > например, вывод на экран - собственный драйвер, как у SoftIce? использовать виндовый драйвер > Ведь SoftIce многие вещи делал сам, не полагаясь на винду, например? > так как при отладке Винда-то висит, > находится в "замороженном" состоянии. в результате чего мы имеем грабли при отладке многопоточных приложений ;-( > Почему не над всеми? Я могу контролировать любое исключение, > любое прерывание, чтение-запись MSR, CR, LDTR, TR, GDTR, > DR и пр. регистров, привелегированные инструкции, воод-вывод > (IN-OUT, используя I/O bitmaps) и прочее. Полный контроль! и на хрена? а вот вывести список процессов слабо? брякнуться на API функу или wm_msg? чтобы это сделать необходимо разбирать системные структуры, что очень муторно и системно-зависимо. виртуализация ничем тут не поможет. а отладчик, который не позволяет брякаться на API - кому он такой нужен? > Но будет ли он работать, как SoftIce, когда винда заморожена > и ни один стандартный драйвер не работает? То есть вообще > какая должна быть архитектура, чтобы все работало на одной машине? нет, не будет. в винде наблюдается тенденция переноса больших кусков кода из драйверов на прикладной уровень и потому вызывать видео-драйвера из гипервизора уже не получится, а если и получится, то с кучей ограничений. прямая запись в виде-память так же не всегда возможна и к тому же требует учета особенностей конкретных видюх. k3internal > Во вторых представь, что интел вдруг что то изменит в этом механизме. > И что писал то зря. Софтверные эмуляторы рулят!! не так уж и сложно вынести код, общающийся с гипервизором, в отдельный модуль. и этот модуль будет лишь крошечной частью отладчика, который должен уметь много чего. достаточно попробовать реализовать хотя бы одну раскрутку стека. достаточно взглянуть на ольгу и прикинуть сколько времени надо, чтобы реализовать ее функционал. а про эмуляторы очень даже правильно! присоединяюсь. эмуляция позволяет реализовать полный стел-отладчик, к тому же эмулятор может перехватывать все, что угодно. например, может детектить самомодифицирующийся код и автоматически брякаться на него просто по факту передачи управления на модифицированную ячейку памяти. или вот, скажем, брякаться на любую последовательность команд, описанную регулярными выражениями.
перехватывает именно всё ?? и память на ура ? А можно меня носом тыкнуть в интеловскую спецификацию где это написано? может я чево то пропустил.
k3internal > перехватывает именно всё ?? и память на ура ? эмулятор - да. (эмулятор /* программный */ != аппаратная виртуализация) > А можно меня носом тыкнуть в интеловскую спецификацию > где это написано? может я чево то пропустил. какая спецификация? вот как раз по спецификациям отследить такое очень сложно, хотя и возможно через те же атрибуты страниц например, но эмулятор, реализованный тобой, может делать вообще все, что угодно. в частности, для детекта самомодифицирующегося кода достаточно прицепить к каждой ячейке виртуального адресного пространства специальный атрибут, указывающий была ли она модифицирована или нет и проверять этот атрибут перед исполнением всякой команды.
