Всем привет, сейчас немного изучаю системные вызовы в Windows и появилось несколько вопросов
1) Индексы syscall отличаются в разных ос, однако не совсем понятно по способу вызова,
они разные на x32, x64 и wow64, но отличаются ли они в разных версиях винды и
можно ли где-нибудь скачать дллки от разных версий?
2) Какие есть способы перехвата системных вызовов из юзермода при условии,
что системный вызов заинлайнен и неизвестно где он производится?
Я слышала что вроде можно через NtQuerySystemInformation, но до конца не знаю.

-----
В облачке многоточия

| Сообщение посчитали полезным:

Boostyq пишет:
но отличаются ли они в разных версиях винды иможно ли где-нибудь скачать дллки от разных версий?

возьмите WinDbg и все станет ясно.

-----
Give me a HANDLE and I will move the Earth.

| Сообщение посчитали полезным:

plutos пишет:
как один из возможных вариантов, возьмите WinDbg, установите интересующие вас версии Windows на, скажем, VMware (для удобства), пропишите в environmental variables путь к Windows Symbol Server, чтоб символы подгружались автоматически для каждой версии и все станет ясно.
Спасибо за совет, но поставить такое кол-во осей не имею возможности
Windows XP SP1
Windows XP SP2
Windows Server 2003 SP0
Windows Server 2003 SP2
Windows Server 2003 R2
Windows Server 2003 R2 SP2
Windows Vista SP0
Windows Vista SP1
Windows Vista SP2
Windows Server 2008 SP0
Windows Server 2008 SP1
Windows Server 2008 SP2
Windows Server 2008 R2
Windows Server 2008 R2 SP1
Windows 7 SP0
Windows 7 SP1
Windows Server 2012 SP0
Windows Server 2012 R2
Windows 8.0
Windows 8.1
Windows 10 Build 1507
Windows 10 Build 1511
Windows 10 Build 1607
Windows 10 Build 1703
Windows 10 Build 1709
Windows 10 Build 1803
Это не считая разрядности, иначе в два раза больше
Инфу, что вы скинули я находила в гугле, xp x32 у меня есть на виртуалке, KiFastSystemCall тоже видела, у самой 7 x64, увидела как выглядит на wow64 и x64, однако не знаю как на других осях, поэтому и спрашивала дллки, потому что это дешевле, чем ставить все оси
Интелевский мануал тоже читаю вечерами, но пока до инструкций не дошла

-----
В облачке многоточия

| Сообщение посчитали полезным:

Boostyq пишет:
Спасибо за совет, но поставить такое кол-во осей не имею возможности

ну, тогда простите великодушно, я ж не знал о каком количестве идет речь.
Удачи!

-----
Give me a HANDLE and I will move the Earth.

| Сообщение посчитали полезным:

Как-то с этим разбирался, но уже все забыл, если честно.
DISCLAIMER: Я могу сильно ошибаться, всю инфу надо перепроверять.

Короче, int 0x2E поддерживается как способ системного вызова на многих 32-битных OS (тестировал до Windows 8 включительно).
На 64-битных надо иначе.
Итого, получается такой франкенштейн.


А номера системных вызовов можно парсить из ntdll.

| Сообщение посчитали полезным: Boostyq

Boostyq пишет:
поэтому и спрашивала дллки, потому что это дешевле, чем ставить все оси
Чтоб получить дллки, ставить оси необязательно, есть 7зип (для .esd) и экспанд (на всякий случай), чтоб нтдлл из дистрибутива достать.

-----
2 оттенка серого

| Сообщение посчитали полезным:

plutos пишет:
ну, тогда простите великодушно, я ж не знал о каком количестве идет речь.
Удачи!
На самом деле я не знаю сколько нужно, поэтому и спросила знает ли кто-нибудь меняется ли вызовы для других версий винды...

-----
В облачке многоточия

| Сообщение посчитали полезным:

Boostyq пишет:
Интелевский мануал тоже читаю вечерами, но пока до инструкций не дошла
То есть до 2 тома?

-----
2 оттенка серого

| Сообщение посчитали полезным:

f13nd пишет:
То есть до 2 тома?
Я скачала 2abcd, но там еще до начала инструкций куча информации, а я под x64 слабо знаю

-----
В облачке многоточия

| Сообщение посчитали полезным:

1. Отличаются. Гугл в помощь, таблицы соответствий для разных версий ОС имён функций и номеров есть.
2. Если грамотно сделано, нет.

| Сообщение посчитали полезным: Boostyq

Archer пишет:
1. Отличаются. Гугл в помощь, таблицы соответствий для разных версий ОС имён функций и номеров есть.
2. Если грамотно сделано, нет.
Таблицы я нашла https://j00ru.vexillium.org/syscalls/nt/32/ и https://j00ru.vexillium.org/syscalls/nt/64/, но в них не описано как именно происходит вызов

-----
В облачке многоточия

| Сообщение посчитали полезным:

Одинаково он происходит. Через int 2e/sysenter на нативной разрядности и так называемый heaven gate через FAR переход на WOW64.

| Сообщение посчитали полезным:

Да нафига эти таблицы нужны, если в рантайме все можно прочитать?
Я писал в свое время утиль, она до сих пор стабильно работает от XP до последних билдов 10-ки, все адреса сисколов налету читаются из текущей системы и вызываются в зависимости от ОС и ее разрядности. Принципиально в ядре в этом отношении мало что поменялось, упорство и гугл дадут вам хорошую основу матчасти в отличии от чужих готовых решений ;)

| Сообщение посчитали полезным: Boostyq

VOLKOFF пишет:
Да нафига эти таблицы нужны, если в рантайме все можно прочитать?
Я писал в свое время утиль, она до сих пор стабильно работает от XP до последних билдов 10-ки, все адреса сисколов налету читаются из текущей системы и вызываются в зависимости от ОС и ее разрядности. Принципиально в ядре в этом отношении мало что поменялось, упорство и гугл дадут вам хорошую основу матчасти в отличии от чужих готовых решений ;)
Согласна, что лучше парсить оригинальные вызовы, однако для того чтобы это правильно делать нужно как можно больше примеров оригинальных вызовов, например

Здесь нельзя точно утверждать, что там всегда будут эти регистры, при этом не хотелось бы тащить собой дизасм длин
Кстати парсить тоже не всегда сработает, вот например листала вызовы и обнаружилось, что все уже украдено до нас

В этом случае ничего кроме таблицы не остается

-----
В облачке многоточия

| Сообщение посчитали полезным:

Boostyq пишет: Кстати парсить тоже не всегда сработает, вот например листала вызовы и обнаружилось, что все уже украдено до нас

на диске же вызовы целые, в примере как раз плохой пример хука.

| Сообщение посчитали полезным:

Чтобы много не писать, - мы сейчас говорим об абстрактной потенциально где-то возможной ситуации которая с неопределенной вероятностью может случится, а может нет, или есть какой-то сабж?
Если да, покажите, скорее всего есть более простое решение вопроса.

| Сообщение посчитали полезным:

VOLKOFF пишет:
Чтобы много не писать, - мы сейчас говорим об абстрактной потенциально где-то возможной ситуации которая с неопределенной вероятностью может случится, а может нет, или есть какой-то сабж?
Если да, покажите, скорее всего есть более простое решение вопроса.

Сабж в том чтобы заинлайнить syscall, вообще без call или jmp, потому что оригинальные функции хукнуты прямо под корень не мной
Хотя call в коде судя по всему придется все равно делать для передачи параметров и уже после делать пост обработку

-----
В облачке многоточия

| Сообщение посчитали полезным:

shellstorm пишет:
в примере как раз плохой пример хука
А с чего такой вывод?

| Сообщение посчитали полезным:

SReg пишет:А с чего такой вывод?

Этот вариант годится только для легального софта, которому никто не будет целенаправленно противодействовать, антивирусы просто пометят как hack tools или riskware, а для темных дел он непригоден.
1. он очевиден, патч можно искать достаточно тупой сигнатурой.
2. его легко обойти, тупо загрузить из образа на диске или захардкодить сервисные таблицы.
3. его легко снять, для этого даже ненужен ядерный антируткит.

В остальном рабочий вариант, который можно использовать в легальном софте.

| Сообщение посчитали полезным:

Самый простой вариант на x32, просто передается в systenter (через прерывания вроде тоже можно, но так медленнее), и затем идет выравнивание стека
Дальше на x64, мне до сих пор непонятно почему там не происходит выравнивание стека, ясно что первые 4 аргумента передаются в регистрах, но даже если их больше вроде тоже не выравнивается
А самый сложный для wow64, не совсем ясно что происходит с регистрами и стеком при проходе через heaven's gate, остаются ли значения ecx например в rcx или нет
Кстати в 10 винде с определенного времени изменились стабы на x86 и wow64 (про x64 не знаю)

-----
В облачке многоточия

| Сообщение посчитали полезным:

Boostyq

> В этом случае ничего кроме таблицы не остается

> 02.ntdll.ZwOpenSection - E9 6380FEBF - jmp 38EA1C78

В дисковой копии по тому же смещению от начала файловой секции расположен оригинальный стаб, тем более у вас есть их именованный экспорт, никакой проблемы нет. Для не экспортируемых стабов(гуя) там да, таблицы по большей части, так как тени стабы редко экспортятся, а в общем там их даже из функции(её всю распарсив) трудно взять(не универсально, хардкод) - там может быть в пределах процедуры множество неэкспорт стабов.

Тоесть это надуманная проблема и задача не практическая. Видимо это общего типа задача - тоесть некоторая процедура пропатчена и нужно получить её изначальное тело/части его. В таком случае задача статически неразрешима(в общем), так как обращение к телу может отсутствовать в статик графе(cfg), к примеру это индексируемое ветвление. Можно лишь в динамике проследить окончание всей фильтрующей цепи, да и то каким то частным путём(зная к примеру примерный формат оригинальной процедуры - сигнатурой обнаружить или динамической сигнатурой - возврат на код за мостом в пропатченной процедуре: на сервисе вы получите нужный контекст). А так как цель патча - фильтрация некоторых данных, то оригинальная процедура вовсе может быть скипнута, тогда вообще ничего определить нельзя.

> заинлайнить syscall, вообще без call или jmp, потому что оригинальные функции хукнуты прямо под корень не мной

А какая разица какое тело у процедуры, которую вы будите патчить ?
Патч общим путём всегда выполняется, не имеет значение содержимое процедуры(только что бы влезло длинное ветвление). Ну начинается она с ветвления, что в этом такого.. переписал на новое, этим всем занимаются утили, которые вы собрались использовать для установки патча.

Во вторых ваш патч ставится поверх предыдущих и обрабатывать вы будите не шлюз(senter/sint/scall/etc) в стабе(как ядерный вызов, где нужно знать контекст для индексации апи), а стаб как экспортируемую апи, как и любую другую, msgbox() к примеру

-----
vx

| Сообщение посчитали полезным:

Мде, теперь немного понятнее как это работает в wow64, универсального ничего не написать, там под каждую функцию отдельный обработчик, печально
Кстати, прочитала что, хукнуть системные вызовы таки можно на x64, ничего не патча

-----
В облачке многоточия

| Сообщение посчитали полезным:

Boostyq

Каким образом ?

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
Каким образом ?
Точно не скажу, прочитала десятки статей и кучу постов на форумах, методы хука меня особо не интересовали, но краем глаза видела, что на x64 можно ставить обработчик через недокументированную функцию, вернее через недокументированные параметры

-----
В облачке многоточия

| Сообщение посчитали полезным:

difexacaw пишет:
Каким образом ?
Мужыки заволновались ))

Может в новых вендах наконец аналог ptrace реализовали?

| Сообщение посчитали полезным:

Boostyq пишет:
методы хука меня особо не интересовали
Boostyq пишет:
2) Какие есть способы перехвата системных вызовов из юзермода
с самого начала вот на таком уровне и было понимание мной задачи

kunix пишет:
Может в новых вендах наконец аналог ptrace реализовали?
Пока только россыпь аналогов strace

| Сообщение посчитали полезным:

Boostyq

Может ProcessInstrumentationCallback ?

--> Link <--

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

kunix

Есчо в первых версиях системы был реализован механизм WMI, там сервисы тоже мониторятся, но это слишком толстый механизм, не нэйтив.

Через трассировку эту задачу и нужно решать, но это совсем другая тема.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
не портабельно
difexacaw пишет:
когда он уже отработал
И слава богу
Оно, не смогла найти, почему то сайт, где видела больше не открывается

-----
В облачке многоточия

| Сообщение посчитали полезным:

Boostyq

--> Link <--

-----
vx

| Сообщение посчитали полезным: Boostyq

для личного использования - на своей машины, но в темных целях, shadow hook топ, ept гипервизор старый хлам не умеет детектировать, остальное набор костылей разной степени стабильности.

| Сообщение посчитали полезным: