TDI hooking - требуется помощь

Недавно я попробовал реализовать обход TDI-фаеров путем

перехвата обработчика IRP.



В стеке TDI, как известно, девайсы расположены примерно так:

-> dev1 -> dev2 -> ... -> \Device\Tcp

(стрелкой показано направление вниз стека IRP)

Девайсы devN приаттачены к \Device\Tcp через IoAttachDevice.

Один из них - это и есть фаер.



Можно найти самый последний из них (т.е. самый высокий в иерархии IRP)

Код (Text):

1.  
2. // devAtt - последний из приаттаченных девайсов в стеке
3. // devTcp - /Device/Tcp
4.     if(devAtt==0 && devTcp==0)
5.     {
6.         usTcp.Buffer = (PWSTR)&device_tcp_buff;
7.        
8.         RtlInitUnicodeString(&usTcp, L"\\Device\\Tcp");
9.         ns=IoGetDeviceObjectPointer(&usTcp,
10.             FILE_READ_ATTRIBUTES,
11.             &fTcp, &devTcp);
12.         if(!ns)
13.         {
14.             devTcp = fTcp->DeviceObject;
15.             t.Trace(TraceAlways, "Tcp device addr=%08x\n",
16.                 devTcp);
17.             PDEVICE_OBJECT dev;
18.             for(dev=devTcp;
19.                     MmIsAddressValid(dev->AttachedDevice);
20.                     dev=dev->AttachedDevice)
21.                 KdPrint(("&device = %08x\n", dev));
22.             devAtt=IoGetAttachedDeviceReference(fTcp->DeviceObject);
23.             t.Trace(TraceAlways, "Attached device addr=%08x\n", devAtt);
24.             HookTdi(devTcp, devAtt, &hooks, &hooknum);
25.         }
26.         else
27.             t << "Failed to get device\n";
28.     }
29.  

Затем установить его обработчик IRP_MJ_INTERNAL_DEVICE_CONTROL на

свой, который выглядит следующим образом:

Код (Text):

1.  
2. // перехватчик для IRP_MJ_INTERNAL_DEVICE_CONTROL
3. NTSTATUS NTAPI TdiDispatchProc(PDEVICE_OBJECT pDeviceObject,
4.         PIRP pIrp)
5. {
6.     if(procID==pid) // если ID текущего процесса равен ID нужного нам процесса
7.     {
8.         // вызываем напрямую /Device/Tcp
9.         t << "Our process, calling tcpip.sys...\n";
10.         IoSkipCurrentIrpStackLocation(pIrp);
11.         ns=IoCallDriver(devTcp, pIrp);
12.         callTcp = TRUE;
13.     }
14.     else
15.     {
16.         dispProc = GetDispatchProc(hooks, hooknum, pDeviceObject); // иначе достаем старый обработчик и вызываем его
17.         KdPrint(("dispProc=%08x\n", dispProc));
18.         if(dispProc)
19.             ns = dispProc(pDeviceObject, pIrp);
20.     }
21. }
22.  

То есть я кидаю IRP в обход цепочки приаттаченных девайсов прямо на \Device\Tcp.



Испытания на показали следующее:

- если фаер не установлен: все работает так же, как и без перехвата

- если установлен Tiny Personal Firewall (бесплатная версия) - файрволл НЕ ВИДИТ исходящие соединения и

привязанные порты. по сути, цель достигнута.

- Outpost Firewall - файрволл не видит привязанные порты, не видит исходящие тоже, НО исходящие

соединения установить не удается (по всей видимости не приходит SYN+ACK ответ)



подскажите плз в чем может быть дело.

У меня есть предположения, но хотелось бы услышать ваши.

Тема очень интересная и перспективная, давайте ее обсудим ж)

 

Дык, где-то ж обсуждали на форуме, правда касательно, но там есть ответ на твой вопрос

 

В том, что фаерволлы еще и на NDIS сидят, а TDI фильтр ведет список IP и портов с которыми связаны разрешенные соединения, позже на NDIS уровне по этим данным производиться фильтрация всех входящих пакетов.

Причем у разных фаерволлов этот механизм реализован по разному, обойти оутпост на уровне NDIS будет ой как тяжело...

Тема это конечно интересная и перспективная, но готовых решений никто забесплатно не даст (да и за деньги сомневаюсь что продадут).

 

Ms Rem

а сплайсинг в нужные NdisXXX не спасет разве?

 

Спасает, но не от оутпоста.

 

Ms Rem OutPost ещё захватыват и IPFilter.

Saint German Вот интересный вопрос, а не пробовал ему "по рукам" (по IPFilter) ударить Например выгрузить. Я конечно не знаю (не разбирался) в каком модуле он сидит, но попробовать следует...

 

Да этот фильтр мне до ноги, так как он выше NDIS стоит, в tcp/ip стеке, а стек я свой загружаю.

И это ему тоже пофиг, оутпост без этого фильтра прекрасно обходиться, на фильтрацию NDIS это никак не влияет.

 

SteelRat

Ну дык найди этот колбек и удали,

(IOCTL_PF_SET_EXTENSION_POINTER), только это спасет только от стандартного фаервола, он появляется с wxp. К тому же агнитум удаляет данные из пакетов.

Только Ms Rem правду сказал - этот способ фильтрации, нужен ему как собаке пятая нога

 

Знаешь, тут сорсину одну откомпилировал, которая цепляет ДЛЛ свою в процессы для перехватов, у меня Аутпост свалился после запуска

 

А я почти организовал перехват NDIS в обход фаера. Проблема только в том, что например Outpost что-то сильно резко восстанавливает перехват и ставит его поверх моего... Есть идеи насчет "перехвата перехвата Outpost'а"? Я вот думаю, а что если поставить на страницу, в которой находятся NDIS_POROTOCOL_BLOCK и NDIS_OPEN_BLOCK атрибут "только чтение"

 

Атрибут "только чтение" в ядре ничего не значит если установить бит WP

Версия: может быть Outpost запускает таймер периодически восстанавливающий хуки?

Тогда можно запустить свой таймер срабатывающий чаще оутпостовского

 

> Атрибут "только чтение" в ядре ничего не значит если установить бит WP

пардон, сбросить конечно же ))

 

>А я почти организовал перехват NDIS в обход фаера.

Техвопрос: нужен ли для этого перехват NdisIMRegisterLayeredMiniport ?