Антиотладка и антитрейсинг в ядре...

я в реверсинге зелененький скажем. те кто в теме скажите насколько затруднит отладку/дизассмеблирование драйвера если он будет частично состоять из самодельных инструкций, которые будут этим же драйвером (или вторым драйвером) эмулироваться? Тобиж логику этих инструкций допустим можно восстановить, но ить с ними и дизассмеблерный листинг поедет по идее

 

ну ламаеться логика первого драйвера которы емулирует инструкции для другого
и потом ломаеться другой

посто невижу надобности в таких сложностях

 

ну сломаешь логику и как дальше. все отладочные средства/дизассмеблеры заточены на нормальный ассемблер а не на самопридуманный вперемешку с нормальным. как будешь код анализировать. или сейчас это делается как-то просто?

 

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

 

вопрос токо - зачем такие сложности и что можно скрывать?
кроме вирусов и прочего спай софта в этом нет надобности

зы
я про драйвера имел ввиду

 

скрывать логику работы программы. чтобы не клонили

 

недавно на геймдев ру обсуждали
резюме:
>вся логика уже давным давно придумана еще до появления первых компьютеров

на самом деле если скрыть что то в драйвере это может сильно сказаться на производительности

ну даже если дойдут до того что вмпротект или подобное доведут до ядра
то таким же образом как и софта снимаються все эти емуляции так же из драйверов будут

 

Пара копеек по теме. Дискуссия в контексте равноправного выполнения отлаживаемого и отлаживающего кода на мой взгляд малоактульна. Вчерашний день. Большинство существующих методик антиотладки и антиэмуляции при использовании VT-x идут лесом. Надо признать - грамотная реализация VMX root кода практически не оставляет шансов
на противодействие реверсингу. Тем не менее, раз народ интересуется, вкратце озвучу несколько техник для борьбы c инструментами, не поддерживающими VT-x.
1) Кэшировние. Memory write + INVD дает неплохие результаты. Отладчики и эмуляторы отдыхают. Замечу только, что кэш штука очень нежная, поэтому юзайте with care. Не забывайте про MTRR, разные комбинации MTRR + CR0.CD + CR0.NW дают очень неожиданные результаты, причем implementation specific.
2) Perfomance monitoring. Тут широчайшее поле для фантазии. Поясню. К примеру - Core, событие SEGMENT_REG_LOADS. Очевидно, что при выполнении под эмулятором или отладчиком счетчик будет отличаться от реального (эмулятор вообще не считает, а под отладчиком насчитается больше). Проблема только в том, чтобы выбрать event,
поддающийся прогнозированию.
3) Вообще вкуснятина. Многие ошибочно полагают, что трюк времен 486-х с записью по адресу команды уже попавшей на конвейер (да простит меня leo за неточность терминологии неактуален со времен первых пеньков. Полная буйня я вам скажу. Все то же самое, только с небольшими модификациями, - уже попавшую в prefetch queue команду можно менять в памяти без изменения ее на проце. А отладчики и эмуляторы, естественно, сосут, т.к. эмуляторы про очередь вообще не знают, а отладчики... отладчики будут пытаться выполнить уже модифицированную инструкцию... )