Аналог ptrace в win64

Необходимо выполнить участок кода под защитой. Код может быть любой и потенциальный шеллкод может юзать напрямую int xx\sysenter для вызова кернел функций.

Под никсами реализовал через ptrace - все работает. Теперь осталось сделать тоже самое под винды, нужно обязательно под win64, под win32 - опция.
Возможно такое на встроенном в винду уровне? Хотелось бы обойтись без написания доп. драйверов, перехвата SDT итп.

Устанавливать dr* через GetThreadContext\SetThreadContext как я понял не сработает, да и судя по сорсам линуха они там только для ptrace single step используются, а на вызов кернела там напрямую enter\exit ptrace хэндлер вызывается.
Для винды пока нашел дебаг утилиты которые .etl трефс файлы делают где трейсятся как раз вызовы кернела, вот только как с этим интерфейсом на нижнем уровне работать пока не нашел, и может ли оно ловить абсолютно все все вызовы пока не уверен. Ктонибудь знает как оно работает?

 

Бред. Что такое под защитой, ptrace, кернел и остальное ?

 

Кстати нет ни одного вашего поста в разделе про ядро, не раноли вам туда лезть, вначале наверное нужно с терминами определиться. Ато трейс файлов.. этож вам не линукс.)

 

semen
Сделать подобие эмулятора.
1. int3 после текущей инструкции
2. в SEH хэндлере - анализ следующей команды: если call/jmp - считаем адрес перехода и к шагу (1), если int/syscall/etc. - нужное тебе поведение (т.е. то что ты подразумеываешь защитой); во всех остальных случаях - выполняешь текущую инструкцию и снова к шагу (1).

 

Clerk
Под защитой, это значит код не может совершить ничего запрещенного, в общем случае код может вызвать кернел функции напрямую, минуя топ левел апи, поэтому хуки дллных функций итп недостаточно - надо или сам код небыл произвольным, например, виртуальная машина, а контролируем то что на ней исполняется (примером является пхп), или контролировать все вызовы кернела, что я и собираюсь делать (примером являются антивирусы).
С ядром у меня опыта действительно мало, ограничевается драйвером рамдиска и видео капчура. Трудных вопросов по ядру у меня пока не возникало, вот и нету пока постов в разделе с ядром. Может этот вопрос и перетечет в ядро, но очень хотелось бы обойтись без него, а даже если и с ним, то без прямого хука SDT, если это возможно, т.к. насколько я знаю начиная с висты она защищается и ее перехват крайне не рекомендуется.
Насчет трейс файлов: .etl трейсы это вполне виндовое понятие, работают с ними WinDDK\6001.18002\tools\tracing\ утилиты, а также xperf из "Microsoft Windows Performance Toolkit" (в вин7 можно еще сгенерить такой файл встроенными средствами Control Panel\All Control Panel Items\Performance Information and Tools\Advanced Tools->Generate a system health report, файл будет находиться в PerfLogs\System\Diagnostics\x_xxxxxxxx-xxxxxx\NtKernel.etl ).
Кстати я с ними разобрался и понял что это мне не подходит. Как видно в WinDDK\6001.18002\tools\tracing\amd64\system.tmf все входы и выходы сисколов он действительно протрейсит, но, во-первых выполняемый трассируемый поток не блокируется, во-вторых эвент буффера могут теряться, если переполнятся, до того как их заберет юзермод.
Насчет ptrace - это никсовый апи, который позваляет брякнуться на syscall, ну и стандартная трассировка тоже есть. Виндовый апи вобщем продвинутей, нету проблемы с аттачем к процессу как у ptrace, но вот конкретно этой фичи у него не нашел.
deLight
Можно проще и быстрее, использовать аппаратный пошаговый трассировщик через регистры dr*, но исполнение по инструкции это слишком долго, быстрее виртуальная машина. Вот я и удивляюсь, неужели все используют только виртуальные машины или ограниченный jit? А потом находится дыра в пхп и или яве и получаем взломанные сайты и программы.
У вм конечно есть плюс - большая кросплатформенность и незваисимость от версий ос, а syscall могут поменяться. Но в моем случае это не так важно, важна скорость.

 

область действия seh - поток в контексте которого произошло исключение

трассируемый код может использовать DRx(напримре некоторые или даже все, что тогда?)

при чем тут это вообще?

это тоже к чему?

 

ohne
Ну с сехом это верно подмечено, это в отдельно ватчер следит задебаг эвентами, и это его хендлер будет проверять при такой схеме, но схема рабочая.
Насчет того, что трассируемый код может использовать DRx - неверно. Для их изменения этому коду надо вызвать GetThreadContext\SetThreadContext, иначе из юзер мода с ними не поработать. А в конечном итоге эти вызовы приведут к вызову кернела, которые мы и заблокируем, так что защащенный код DRx у нас не изменит (даже юзая вызовы кернела, минуя топ левел GetThreadContext\SetThreadContext).
То что syscall могут поменяться это к недостатку такого метода защиты - вышел сервиспак к винде и код стал нерабочим.

 

какой еще "ватчер"? что то не понял. ты же код в буффере пытаешься проверить?
можно на русском эту схему объяснить? т к не понтяно.

глупости это

ну да не изменит и работать соответственно правильно не будет не будет - и все норм
можно таким макаром и апи запретить вызывать и сервисы - но только смысле какой? не ясно
эмулировать нужно DRx если уж будешь сам юзать

до сих пор не можешь номера сервисов динамически получать? эт плохо.

это защита? а в чем суть то? не понятно

 

ohne
Ватчер это тот кто следит за кодом. Схему где есть неточность про seh предложил не я, а deLight, могу только рассказать как сам ее понял, но в моем представлении она рабочая:
1. Создаем поцесс ватчера где крутится WaitForDebugEvent, а нитка и процесс с защащенным кодом дебагятся
2. Записываем int 3 на место каждой последующей инструкции. WaitForDebugEvent ловит эксепшн, восстанавливает затертую инструкцию и затирает следующую(е) с учетом ветвлений.
По сути софтварная эмуляция синглстепа, но зачем, когда есть хардварная - незнаю, не ко мне вопрос. Обсуждать дальше этот метол смысла нет, т.е. он не подходит.

Непонял зачем DRx эмулировать если собираюсь их юзать? Во-первых не собираюсь, т.к. брякнуться именно на сисколе с помощью них нельзя. Самому же защищенному коду такие низкоуровнивые системные вещи будут недоступны. Антивирусы же тоже на этом уровне видут проверку и ничего, смысл есть, что неясно? В никсах аналогом блока GetThreadContext\SetThreadContext является блок ptrace syscall. И все работает, и работает как надо, это не предмет обсуждения, вопрос как теперь сделать это на винде.

Определять номер syscall по имени из ntdll.dll я умею, но с тех пор как я последний раз имел с этим делом (была еще winxp x32) изменилось слишком много и это бы не спасло, вобщем, гарантировать наверняка тут ничего нельзя.

 

semen
Изменить DR регистры можно и без GetThreadContext\SetThreadContext.

 

Вобщем как я понял, ТС хочет реализовать чтото типа sandbox'a.
Вариантов не много: виртуализация, виртуальная машина, хуки системных ф-ций...

з.ы. верните редактирование )

 

Хм, как? Только что проверил - Privileged instruction.

+1000

Увы, виртуальная машина не подходит по причине скорости, проще ограничиться поддержкой никсов.
Ближайшая альтернатива - свой драйвер, она даже позволит улучшить скорость работы т.к. не надо будет переключаться на нитку что ведет проверку и обратно на исполняемую, удваивая кол-во контекст свитчей. Просто грузим в кернел профиль защиты и указываем кого защищать, и все, лишних переключений в юзер мод не будет (похожий механизм использует, например, SUSE AppArmor).

Однако падение производительности без своего драйвера судя по никс версии приемлимое (<1% при адекватном кернел рейте). Так что если можно обойтись без лишнего драйвера - лучше без него. Ведь, напрмер, кернел отладчик виндовый может шагнуть в кернел? Может можно как-то механизм виндового кернел отладчика заюзать?
Вот это и главное выяснить, хотябы есть решение в природе или нету, чтобы зря время не тратить, а сразу начать делать драйвер.

 

Ну вот и опять потребовалось редактирование
Первая квота предидущего поста должна быть тактая:

 

В seh-обработчике через изменение структуры context.

Шагнуть он может(int 3 => IDT => ядерный диспетчер исключений=> коллбек ядерного отладчика), а мы врятли

Я незнаю как в данной задаче при достаточно высоком уровне производительности обойтись без драйвера.

 

Т.е. windbg делает за замену на int 3, а прямой sysenter не засечет? Тогда этот метод тоже не подходит.
Про метод с seh спасибо, надо будет прикрыть и эту лавочку. Правда думаю эта лазейка для защищенного кода не критичка, пускай себе меняет dr*, всеравно все "плохое" он теоретически может сделать только через вызовы кернела. Главное сисколы правильно прикрыть, типа NtDebugSystemControl закрыть, ио контролы только известные пропускать, параметры валидировать итп. Или я ошибаюсь?

 

Как вариант можно не хачить ядро(во избежании проблем с patchguard'ом), а загрузив свой модуль защиты и указав защищаемое приложение, поставить DR брекпойнт на обработчик sysenter'а. Также нужно предусмотреть, чтобы отладочные регистры не сбросил кто-нибудь из пользовательского режима. Ну и в обработчике уже решать что можно вызывать, а что нет.

 

А вообще, не совсем понятно, что имеется ввиду под фразой "Код может быть любой и потенциальный шеллкод может юзать напрямую int xx\sysenter для вызова кернел функций.". Я очень смутно представляю себе, как вы будете контролировать тот факт, что шелкод может инжектнуться в другое приложение, не защищаемое вами, и вызвать все что он хочет. Конечно если ваша защита не будет сильно распространена, то такое поведение шелкода сложно представить, в противном случае, bypass solution может быть сделано очень просто. Лучшее в плане безопасности решение было бы исполнение внутри вирт. машины или динамическая рекомпиляция, но там будет проседать производительность.

 

О чём вообще тут пишите ?
Какой есчо сех, это юзермодный функционал всеголишь код который в одном из модулей находится. Реально имеет смысл для юзермода пограничный режим, это те 5 точек на которые возвращается поток при смене DPL c нуля на 3. Остальное не имеет значения. Будь то сех, вех и любой сторонний механизм. Это первое что должен знать кодер, который начал писать код под виндоз. Кто не понимает этого не может вообще писать код, ибо он не понимает что есть поток, как вообще можно чтолибо кодить не зная этого..
Во вторых следует понимать что есть режим ядра. Это не только ноль в кодовом селекторе. Это совокупность сегментных регистров и некоторых переменных. Драйвер - всеголишь модуль который содержит код, или ресурсы, или есчо что не имеет значения. Можно в гиперпространстве ядра код исполнять, да и вообще где угодно и драйвера/модуля тут вовсе не причём.
"Топ левел апи" - тут на этом форуме дельфи не в моде, для нас существоет два способа обратиться к ядру, это 0x2e прерывание и быстрый вызов сервиса. Причём тут апи.
WaitForDebugEvent() - об этом и речи быть не может, это функционал предоставляемый ядром, но предназначен он для приложений написанных на VB и тп. Нормальный код этим трассировать невозможно.
semen
Вот вы написали стока многа букоф, но смысла я не понял, что и от чего необходимо защищать ?

 

TSS

Вот тут поподробнее. Т.е. в кернел спейсе его никто не перетрет никогда? И почему не перехватывать сискол через msr тогда, зачем брикпоинт?
Вобщем хотелось бы вообще не хукать SDT, а применять более-менее стандартный метод. Ведь для реализации трейсов уже должны быть каллбэки на вход и выход сисколла, может оно и для юзера доступно.
Clerk
Я чтото тоже ничего не понимаю, с первой частью согласен. Сех тут притом, что он возможно (я еще не проверял и не уверен, сам первый раз слышу от TSS) в юзермод обработчике скрытно делает аналог SetThreadContext, через какой-либо другой сискол, не проверя все устанавливаемые поля, позволяя установить dr* не имея SeDebugPrivilege. Это и хотелось прикрыть, если оно таки имеет место быть, но вообще это неважно и к самой теме отношения не имеет.
Далее в чем собственно возражение тоже не понял. WaitForDebugEvent тут действителньо непричем, с его помощью брякнутся на сисколл нельзя, возможно этот вызов ведет в итоге к сисколу возможности которого выше и позволяют это сделать - тогда это мне и надо узнать.
Короче, вобщем, задача - брякнуться на сисколе. Если для этого необходимо, например, поставить кернел отладчик от мс или поменять глобал флаги включающие кернел отладку - это подойдет.

 

Всеголишь вызов NtContinue после обработки исключения для перезагрузки контекста текущего потока.