Генерация IOCTL

Привет всем!

Кто нить подкинет линк на чтиво, в котором описывается техника генерации ioctl запросов? Это когда в ioctl-мониторе видишь, что коды запросов всегда разные при общении с дровиной(на всякий случай пояснил(может криво)).

Или линк на код)

 

Fail,

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

 

Indy_, не, не, вы не поняли. Или я не понял

Смотрите. Есть приложуха, у нее есть дровина. Юзермодная часть общается с дровиной посредством DeviceIoControl или NtDeviceIoControlFile, так? Эти функи посылают ioctl запросы в дров, в котором функция диспетчеризации их разбирает. Обычно это константы: case: xxx; case: eee; case:yyy; Т.е. в юзермод-части есть ioctl-константы, которые разбираются в дрове.

А есть дровины, у которых ioctl коды не константные, а генерируемые. Вопрос в этом. Так было устроено в gmer x86 когда то например.

Это эффективно насколько позволяет автоматика) Т.е. имеет право на жизнь, но таки да, диспетчеризацию и не только реверсить нада

 

Fail,

Не понимаю вашу задачу, какая конечная цель ?

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

 

Indy_,

задача затруднить анализ дрова посредством черного ящика, т.е. что бы невозможно было сопоставить "код ioctl - действие дрова".

М? Поподробнее мона?..

 

Fail,

Так работают AV драйвера, нужно знать ключ, иначе запрос отклоняется.

Что значит затруднить анализ" ?

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

 

Indy_,

А как это работает? Юзермод приложение посылает константу-ioctl в дров, если "пароль" верный - дров "запоминает" приложуху и работает с ней? Т.е. если перехватить "начало разговора" приложухи с дровом, где шлется пароль - вся защита слетает? Или я не понимаю?

 

Fail,

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

 

Indy_,

как ключ отправляется в дров? как происходит авторизация?

 

Fail,

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

 

Indy_,

Интересно. Спасибо.

 

Fail,

Именно эта фильтрация(по PID) и мешает провести атаку на ав драйвера.

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

 

Так эт я понимаю..) Яж как раз интересовался про черный ящик, про защиту от фаззинга как раз..

 

Fail, ioctl коды не константные, а генерируемые
Скажем, юзермодное приложение выполняет циклический сдвиг на один бит влево. Соответственно в диспатчере драйвера константы вовсе не константы, а переменные, которые тоже сдвигаются на один бит влево при выполнении запроса.

 

Можно если не код, то хотяб псевдокод? Я что то туго себе это представляю(

 

Fail,
кернел мод

Code (C):

1.  
2. DWORD SomeIoctl = 0xABCD;
3.  
4. OnDeviceIoControl(DWORD Ioctl)
5. {
6.     if (Ioctl == SomeIoctl)
7.     {
8.         ....
9.  
10.         SomeIoctl = ROL(SomeIoctl);
11.     }
12. }
13.  

юзермод

Code (C):

1.  
2. DWORD SomeIoctl = 0xABCD;
3.  
4. DeviceIoControl(SomeIoctl);
5. ROL(SomeIoctl);
6.  

 

unc1e, хм, интересно Спасибо)

Да, алгос весьма предсказуем, притом что при каджой новой инирации инициализации коды будут всегда совпадать... Это раз... И при обрушении юзерспейс-модуля, повторная его инициализация приведет к неработоспособности всей конструкции... это два. Но способ все равно интересный, спасибо за наколку