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

Тема в разделе "WASM.NT.KERNEL", создана пользователем zoool, 7 июл 2009.

  1. SashaTalakin

    SashaTalakin New Member

    Публикаций:
    0
    Регистрация:
    15 дек 2008
    Сообщения:
    261
    я в реверсинге зелененький скажем. те кто в теме скажите насколько затруднит отладку/дизассмеблирование драйвера если он будет частично состоять из самодельных инструкций, которые будут этим же драйвером (или вторым драйвером) эмулироваться? Тобиж логику этих инструкций допустим можно восстановить, но ить с ними и дизассмеблерный листинг поедет по идее
     
  2. reversecode

    reversecode Guest

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

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

    SashaTalakin New Member

    Публикаций:
    0
    Регистрация:
    15 дек 2008
    Сообщения:
    261
    ну сломаешь логику и как дальше. все отладочные средства/дизассмеблеры заточены на нормальный ассемблер а не на самопридуманный вперемешку с нормальным. как будешь код анализировать. или сейчас это делается как-то просто?
     
  4. TSS

    TSS New Member

    Публикаций:
    0
    Регистрация:
    13 апр 2009
    Сообщения:
    494
    Ну процессорный модуль для иды придется писать, разобрав перед этим формат этих самодельных инструкций, тогда даже если интерпретатор сам написан на этом псевдокоде - можно будет легко разобраться.
     
  5. reversecode

    reversecode Guest

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

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

    SashaTalakin New Member

    Публикаций:
    0
    Регистрация:
    15 дек 2008
    Сообщения:
    261
    скрывать логику работы программы. чтобы не клонили
     
  7. reversecode

    reversecode Guest

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

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

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

    Medstrax Забанен

    Публикаций:
    0
    Регистрация:
    18 июл 2006
    Сообщения:
    673
    Пара копеек по теме. Дискуссия в контексте равноправного выполнения отлаживаемого и отлаживающего кода на мой взгляд малоактульна. Вчерашний день. Большинство существующих методик антиотладки и антиэмуляции при использовании 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 команду можно менять в памяти без изменения ее на проце. А отладчики и эмуляторы, естественно, сосут, т.к. эмуляторы про очередь вообще не знают, а отладчики... отладчики будут пытаться выполнить уже модифицированную инструкцию... )