| Сейчас на форуме: -Sanchez- (+8 невидимых) |
 |
eXeL@B —› Основной форум —› Вопрос по SIDE |
| Посл.ответ | Сообщение |
|
|
Создано: 16 июня 2017 19:45 · Поправил: Lambda · Личное сообщение · #1 Привет! Вопрос к difexacaw. Допустим я перехватил вызов сискола фильтром. Могу ли я в фильтре скипнуть выполнение системого вызова и подменить возвращаемое значение? Драйвер работает только под XP?  |
|
|
Создано: 17 июня 2017 00:29 · Личное сообщение · #2 Lambda Конечно можно. Драйвер работал под XP и 7. До 10-ки думаю можно завести без изменений. Там была фича для скрытия указателя в ядре, так вот этот механизм выше 7 вроде бы крэшил по какой то причине, я не помню подробностей. ----- vx | Сообщение посчитали полезным: Lambda |
|
|
Создано: 17 июня 2017 00:57 · Поправил: VOLKOFF · Личное сообщение · #3 Старше 7-ки не будет работать как минимум из-за реализации теста через INT 2E Плюс в новых осях x86 использует сплайсинг системных вызовов из за отсутсвия KiFastSystemCall До 7-ки включительно должно быть все норм. |
|
|
Создано: 17 июня 2017 01:23 · Поправил: difexacaw · Личное сообщение · #4 VOLKOFF Почему int2e не работает ? w8, IDT: Code:
> Плюс в новых осях x86 использует сплайсинг системных вызовов из за отсутсвия KiFastSystemCall Зачем это ? Оно не по этой причине не будет работать, к примеру пул не исполняем и прочая защита. В данной поделке принцип был в том, что бы можно было обработать сервисы не в ядре, что бы не пилить и отлаживать дров, а передать управление в юм, где можно использовать обычную юзер обработку, отладить это всё юзер отладчиком, в случае ошибки не крэшнет ось. ----- vx |
|
|
Создано: 17 июня 2017 01:43 · Поправил: VOLKOFF · Личное сообщение · #5 difexacaw пишет: Почему int2e не работает ? Оно на х64 не через int2e работает, а через шлюз FS:0C0h и будет просто Access violation Ну и заводить неподписанные дрова под 8+ не комильфо. |
|
|
Создано: 17 июня 2017 01:49 · Личное сообщение · #6 VOLKOFF Оно 32-хбитное, причём тут x64. Что бы обрабатывать сервисы под wow не нужен драйвер. ----- vx |
|
|
Создано: 17 июня 2017 01:50 · Личное сообщение · #7 difexacaw пишет: Конечно можно. ОК. Исполнение программы в начале кода функции фильтра. По ID сискола в EAX я решил, что нужно подменить возвращаемое значение сискола. Каким образом я это могу сделать в своем фильтре? Фильтр вызывается перед перед вызовом перехваченного сискола? |
|
|
Создано: 17 июня 2017 01:56 · Личное сообщение · #8 Lambda > По ID сискола в EAX я решил Обычно строится таблица номер_сервиса/хэш_имени и обработка происходит через хэши, а не ID. > Фильтр вызывается перед перед вызовом перехваченного сискола? Нет, он вызывается при вызове сервиса. Ядро прерывает обработку и возвращает управление в юм на указанный адрес. При этом никакие ресурсы не захватываются, таким образом не нужно их освобождать(возвращать управление в км). Тоесть можно эмулировать сервис. ----- vx | Сообщение посчитали полезным: Lambda |
|
|
Создано: 17 июня 2017 02:12 · Поправил: Lambda · Личное сообщение · #9 В коде вашего примера перехватывается ZwYieldExecution. После исполнения сыскола в EAX получаем 0x40000024. Фильтр в примере выглядит так: Code:
Что мне нужно дописать перед этими инструкциями, что бы вызов ZwYieldExecution всегда возвращал 0xAABBCCDD? |
|
|
Создано: 17 июня 2017 02:14 · Личное сообщение · #10 Словил жесткое дежавю  6 лет назад lomeavae пишет: Это x86 код. Что вы его тестите на другой архитектуре. ntldr пишет: Вообще-то юзермодный x86 код отлично исполняется на Win64 если ему не мешают кривые руки. Ваш, по вашим словам мега-стабильный и супер-безглючный, код не работает. Вывод очевиден: ваш софт к андоку гвоздями прибит и не терпит ни малейших изменений архитектуры. Ладно бы если таких мест одно-два и их невозможно переписать нормально. Но насколько я понял, у вас всё такое. Через пару-тройку лет везде будет x64 и подоспеет винда под ARM, тогда все ваши знания и наработки можно сливать в унитаз и начинать заново. Я же перекомпилирую код, поправлю пару некрасивых мест, прогоню статический анализ и юнит-тесты, и продукт сложностью в тысячи человеко-часов портирован за пару дней работы. И вот уже 2к17, реально мало людей (даже на 7-ке) которые работают под х86, а "воз и ныне там"... Не пытаюсь принизить уровень ваших знаний, в целом за моторчики респект, но читал ту тему и улыбался 
|
|
|
Создано: 17 июня 2017 02:29 · Поправил: difexacaw · Личное сообщение · #11 Lambda mov eax,0xAABBCCDD VOLKOFF Эту тему подняли из за этой . Там x86 приложение и защита. Так как у автора не нашлось пригодного инструмента, он выполнил полный ручной разбор. Для этого не нужна 64 ось. Почему же вы ему ничего дельного не посоветовали, чем сервисы замониторить, да есчо если и запустить под wow - там возможные стандартные драйвера не станут  Обычно приложение для двух архитектур идёт, конечно же вы не ищите лёгких путей и возьмёте 64 и windbg. ----- vx |
|
|
Создано: 17 июня 2017 02:41 · Поправил: Lambda · Личное сообщение · #12 difexacaw Если изменить EAX, то выполнение не возвращается в ядро по INT 2E. Смотрите гифку. http://i.imgur.com/6B92h4X.gifv |
|
|
Создано: 17 июня 2017 03:04 · Поправил: difexacaw · Личное сообщение · #13 Lambda Вам нужно выполнить прямой возврат mov eax,N и ret 4 что бы снять со стека структуру, вроде так. BADC0DE это возврат в ядро для продолжения обработки сервиса. При этом нужно соответствующие флажки использовать, что бы небыло рекурсий. Добавлено спустя 9 минут На гифке ошибка - invalid sys service, так как ID > max. При таком вызове ID должен быть любым, но < max. ----- vx | Сообщение посчитали полезным: Lambda |
|
|
Создано: 17 июня 2017 03:17 · Поправил: Lambda · Личное сообщение · #14 difexacaw С прямым возвратом все работает. Спасибо. difexacaw пишет: BADC0DE это возврат в ядро для продолжения обработки сервиса. При этом нужно соответствующие флажки использовать, что бы небыло рекурсий. Рекурсия будет только если я захочу в своем фильтре вызвать сыскол без сброса флажка. Верно? |
|
|
Создано: 17 июня 2017 03:26 · Личное сообщение · #15 Lambda > С прямым возвратом все работает. В случае если нужно обработать начало сервиса, отдать управление в ядро и получить его снова при возврате из сервиса, то нужно загрузить в стуктуру адрес ловушки, адрес возврата сохранить в локальном хранилище(тлс) и отдать управление в ядро. Когда из сервиса произойдёт возврат на ловушку, нужно вернуть управление на сохранённый адрес. > вызвать сыскол без сброса флажка. Верно? Так точно. ----- vx | Сообщение посчитали полезным: Lambda |
|
|
Создано: 17 июня 2017 03:57 · Поправил: Lambda · Личное сообщение · #16 difexacaw пишет: то нужно загрузить в стуктуру адрес ловушки Для обработки начала сервиса мы записываем адрес фильтра(ловушки) по оффсету 0xFFC. Для установки фильтра, который получит управление после вызова сервиса, есть другой оффсет? --------------- Уже понял. Вы имели в виду структуру, адрес которой мы убирали в стеке с помощью "retn 4" при прямом возврате. Что это за структура? Какие там еще данные кроме первого DWORD-а, который указывает на адрес возврата после выполнения сервиса? |
|
|
Создано: 17 июня 2017 08:31 · Личное сообщение · #17 Lambda FSTATE, второе её поле это ссылка на аргументы сервиса. Механизм такой: sysenter -> фильтр(FSTATE) -> sysenter(BADC0DE, FSTATE) -> продолжение_обработки_сервиса -> вызов обработчика сервиса(FSTATE.Args) -> возврат из sysenter на FSTATE.Ip Таким образом можно обойти возврат из sysenter на Ki*Ret(), а только так можно в юм словить это событие. ----- vx | Сообщение посчитали полезным: Lambda |
|
eXeL@B —› Основной форум —› Вопрос по SIDE |
Для печати