TDI FILTER driver – Page 4

This topic has 61 replies, 2 voices, and was last updated 17 years, 4 months ago by Dmitry_177.

Viewing 15 posts - 46 through 60 (of 62 total)

Author

Posts

July 15, 2007 at 4:24 pm #6321

Keymaster

return OldClientEventReceive(pBlockFromPagedLookasideList->EventContext,

ConnectionContext,

ReceiveFlags,

BytesIndicated,

BytesAvailable,

*BytesTaken,

Tsdu,

*IoRequestPacket);

Ого, я даже не посмотрел, звездочки убери в параметрах… Прежде чем писать драйвера, прости книжку по C что ли…

July 15, 2007 at 5:06 pm #6322

Dmitry_177

Participant

Да я пробовал без звездочек, не компилируется даже, ошибки пишутся.. И книгу по С читал… Сделал так:

ntStatus = OldClientEventReceive(pBlockFromPagedLookasideList->EventContext,

ConnectionContext,

ReceiveFlags,

BytesIndicated,

BytesAvailable,

(ULONG)BytesTaken,

Tsdu,

(PIRP)IoRequestPacket);

всеравно BSOD

July 15, 2007 at 9:27 pm #6323

Vadim Smirnov

Keymaster

Да я пробовал без звездочек, не компилируется даже, ошибки пишутся.. И книгу по С читал…

Кто бы сомневался если OLDCLIENTEVENTRECEIVE неправильно определен…

При таких ошибках драйвера писать по меньшей мере рановато… Это мягко говоря 🙂

July 15, 2007 at 10:35 pm #6324

Dmitry_177

Participant

Чем OLDCLIENTEVENTRECEIVE неправильно определен??? Я же посмотрел как ClienteReceive в DDK определено…

NTSTATUS

ClientEventReceive(

IN PVOID  TdiEventContext,

IN CONNECTION_CONTEXT  ConnectionContext,

IN ULONG  ReceiveFlags,

IN ULONG  BytesIndicated,

IN ULONG  BytesAvailable,

OUT ULONG  *BytesTaken,

IN PVOID  Tsdu,

OUT PIRP  *IoRequestPacket

);

Совершенно также… И со звездочками.. Подскажи пожалуйста если что не так…

July 16, 2007 at 10:08 am #6325

Vadim Smirnov

Keymaster

М-да, просто нет слов… У тебя:

typedef NTSTATUS (*OLDCLIENTEVENTRECEIVE)(IN PVOID,

IN CONNECTION_CONTEXT,

IN ULONG,

IN ULONG,

IN ULONG,

OUT ULONG,

IN PVOID,

OUT PIRP);

Должно быть:



typedef NTSTATUS (*OLDCLIENTEVENTRECEIVE)(IN PVOID,

IN CONNECTION_CONTEXT,

IN ULONG,

IN ULONG,

IN ULONG,

OUT ULONG*,

IN PVOID,

OUT PIRP*);

ULONG * – это тип указатель на ULONG, PIRP * – указатель на PIRP. ВСЕ ЧТО ДО ИМЕНИ ПАРАМЕТРА – ЭТО ТИП ПАРАМЕТРА.

July 16, 2007 at 3:59 pm #6326

Dmitry_177

Participant

Сделал так… Всеравно BSOD.. !analyze -v показывает вот что:

kd> !analyze -v

*******************************************************************************

*                                                                             *

*                        Bugcheck Analysis                                    *

*                                                                             *

*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

An attempt was made to access a pageable (or completely invalid) address at an

interrupt request level (IRQL) that is too high.  This is usually

caused by drivers using improper addresses.

If kernel debugger is available get stack backtrace.

Arguments:

Arg1: 00000e20, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000001, value 0 = read operation, 1 = write operation

Arg4: 8149f08d, address which referenced memory

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************

***                                                                   ***

***                                                                   ***

***    Your debugger is not using the correct symbols                 ***

***                                                                   ***

***    In order for this command to work properly, your symbol path   ***

***    must point to .pdb files that have full type information.      ***

***                                                                   ***

***    Certain .pdb files (such as the public OS symbols) do not      ***

***    contain the required information.  Contact the group that      ***

***    provided you with these symbols if you need this command to    ***

***    work.                                                          ***

***                                                                   ***

***    Type referenced: nt!_KPRCB                                     ***

***                                                                   ***

*************************************************************************

*************************************************************************

***                                                                   ***

***                                                                   ***

***    Your debugger is not using the correct symbols                 ***

***                                                                   ***

***    In order for this command to work properly, your symbol path   ***

***    must point to .pdb files that have full type information.      ***

***                                                                   ***

***    Certain .pdb files (such as the public OS symbols) do not      ***

***    contain the required information.  Contact the group that      ***

***    provided you with these symbols if you need this command to    ***

***    work.                                                          ***

***                                                                   ***

***    Type referenced: nt!KPRCB                                      ***

***                                                                   ***

*************************************************************************

*************************************************************************

***                                                                   ***

***                                                                   ***

***    Your debugger is not using the correct symbols                 ***

***                                                                   ***

***    In order for this command to work properly, your symbol path   ***

***    must point to .pdb files that have full type information.      ***

***                                                                   ***

***    Certain .pdb files (such as the public OS symbols) do not      ***

***    contain the required information.  Contact the group that      ***

***    provided you with these symbols if you need this command to    ***

***    work.                                                          ***

***                                                                   ***

***    Type referenced: nt!_KPRCB                                     ***

***                                                                   ***

*************************************************************************

*************************************************************************

***                                                                   ***

***                                                                   ***

***    Your debugger is not using the correct symbols                 ***

***                                                                   ***

***    In order for this command to work properly, your symbol path   ***

***    must point to .pdb files that have full type information.      ***

***                                                                   ***

***    Certain .pdb files (such as the public OS symbols) do not      ***

***    contain the required information.  Contact the group that      ***

***    provided you with these symbols if you need this command to    ***

***    work.                                                          ***

***                                                                   ***

***    Type referenced: nt!KPRCB                                      ***

***                                                                   ***

*************************************************************************

*************************************************************************

***                                                                   ***

***                                                                   ***

***    Your debugger is not using the correct symbols                 ***

***                                                                   ***

***    In order for this command to work properly, your symbol path   ***

***    must point to .pdb files that have full type information.      ***

***                                                                   ***

***    Certain .pdb files (such as the public OS symbols) do not      ***

***    contain the required information.  Contact the group that      ***

***    provided you with these symbols if you need this command to    ***

***    work.                                                          ***

***                                                                   ***

***    Type referenced: nt!_KPRCB                                     ***

***                                                                   ***

*************************************************************************

MODULE_NAME: yk51x86

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP:  42de4146

WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart

unable to get nt!MmSpecialPoolEnd

unable to get nt!MmPoolCodeStart

unable to get nt!MmPoolCodeEnd

00000e20

CURRENT_IRQL:  2

FAULTING_IP:

+ffffffff8149f08d

8149f08d 180b            sbb     byte ptr [ebx],cl

DEFAULT_BUCKET_ID:  WRONG_SYMBOLS

BUGCHECK_STR:  0xD1

LAST_CONTROL_TRANSFER:  from 8149f08d to 8053fa73

STACK_TEXT:

WARNING: Stack unwind information not available. Following frames may be wrong.

80548b54 8149f08d badb0d00 8226c458 f76e7992 nt!Kei386EoiHelper+0x27db

80548c18 aaca362d 8226c458 81446c48 00000e20 0x8149f08d

80548c7c aaca8e39 81446c48 00001850 80548d9c tcpip!ARPRcv+0x31ba

80548d04 aac9cef5 8207c460 2101a8c0 08ccb4d5 tcpip!ARPRcv+0x89c6

80548d64 aacbae4d 00000020 8207c460 aac9f076 tcpip!IPFreeBuff+0x634

80548e18 aac9b922 8207c460 81a02522 0000049b tcpip!tcpxsum+0x2d65

80548e58 aac9b84d 00000000 821be440 81a02500 tcpip!ARPRcvPacket+0x128

80548e94 f8138f45 82268008 00000000 f7658b40 tcpip!ARPRcvPacket+0x53

80548ee8 f765301d 00022350 820c2398 00000001 NDIS!FddiFilterDprIndicateReceive+0xd4d

80548efc f76531b4 821df710 820c2398 00000001 psched!RegisterPsComponent+0x6cef

80548f20 f76535f9 822631f0 00000000 821df710 psched!RegisterPsComponent+0x6e86

80548f38 f8138d40 822631e8 00000001 81a4a37c psched!RegisterPsComponent+0x72cb

80548f88 f770efe0 00022350 80548fa8 00000001 NDIS!FddiFilterDprIndicateReceive+0xb48

80548fd8 f7708c67 81a4a004 81a4a37c 82207130 yk51x86+0xdfe0

80549008 f770a1ea 60a4a004 8054902c f812ef09 yk51x86+0x7c67

80549014 f812ef09 81a4a004 80551d80 80551b20 yk51x86+0x91ea

8054902c 80540f7d 81a4a088 81a4a074 00000000 NDIS!NdisCompletePnPEvent+0x17b

80549050 80540ef6 00000000 0000000e 00000000 nt!KiDispatchInterrupt+0x35d

00000000 00000000 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2d6

STACK_COMMAND:  kb

FOLLOWUP_IP:

yk51x86+dfe0

f770efe0 8b83e4010000    mov     eax,dword ptr [ebx+1E4h]

SYMBOL_STACK_INDEX:  d

FOLLOWUP_NAME:  MachineOwner

IMAGE_NAME:  yk51x86.sys

SYMBOL_NAME:  yk51x86+dfe0

BUCKET_ID:  WRONG_SYMBOLS

Followup: MachineOwner

Причем здесь yk51x86.sys? Это не мой драйвер.. И всеравно падает при вызове оригинальной функции…

Перехваченная функция объявлена так:

NTSTATUS HookedClientEventReceive(IN PVOID  TdiEventContext,

IN CONNECTION_CONTEXT  ConnectionContext,

IN ULONG  ReceiveFlags,

IN ULONG  BytesIndicated,

IN ULONG  BytesAvailable,

OUT ULONG  *BytesTaken,

IN PVOID  Tsdu,

OUT PIRP  *IoRequestPacket)

{

...

return OldClientEventReceive(pBlockFromPagedLookasideList->EventContext,

ConnectionContext,

ReceiveFlags,

BytesIndicated,

BytesAvailable,

BytesTaken,

Tsdu,

IoRequestPacket);

}

но тут я думаю нормально все со звездочками…

Я как понимаю опять IRQL_NOT_LESS_OR_EQUAL.. Но у меня нестраничная память используется, как вы и говорили..

July 17, 2007 at 7:05 am #6327

Vadim Smirnov

Keymaster

Your debugger is not using the correct symbols

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

July 17, 2007 at 3:28 pm #6328

Dmitry_177

Participant

Вот, вроде получилось:

kd> !analyze -v

*******************************************************************************

*                                                                             *

*                        Bugcheck Analysis                                    *

*                                                                             *

*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

An attempt was made to access a pageable (or completely invalid) address at an

interrupt request level (IRQL) that is too high.  This is usually

caused by drivers using improper addresses.

If kernel debugger is available get stack backtrace.

Arguments:

Arg1: 7eec42a7, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000001, value 0 = read operation, 1 = write operation

Arg4: ffa68b9c, address which referenced memory

Debugging Details:

WRITE_ADDRESS:  7eec42a7

CURRENT_IRQL:  2

FAULTING_IP:

+ffffffffffa68b9c

ffa68b9c 888cbcff000000  mov     byte ptr [esp+edi*4+0FFh],cl

DEFAULT_BUCKET_ID:  INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR:  0xD1

PROCESS_NAME:  Idle

TRAP_FRAME:  805487d4 -- (.trap ffffffff805487d4)

ErrCode = 00000002

eax=ffa68b94 ebx=00000a20 ecx=80eef1b8 edx=ffa780a0 esi=80dd5e70 edi=ffa5ee58

eip=ffa68b9c esp=80548848 ebp=8054887c iopl=0         ov up ei pl nz ac pe cy

cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010a17

ffa68b9c 888cbcff000000  mov     byte ptr [esp+edi*4+0FFh],cl ss:0010:7eec42a7=??

Resetting default scope

LAST_CONTROL_TRANSFER:  from 804f79d7 to 80526fc8

STACK_TEXT:

80548388 804f79d7 00000003 805486e4 00000000 nt!RtlpBreakWithStatusInstruction

805483d4 804f85c4 00000003 7eec42a7 ffa68b9c nt!KiBugCheckDebugBreak+0x19

805487b4 8053fa73 0000000a 7eec42a7 00000002 nt!KeBugCheck2+0x574

805487b4 ffa68b9c 0000000a 7eec42a7 00000002 nt!KiTrap0E+0x233

WARNING: Frame IP not in any known module. Following frames may be wrong.

80548844 fb0e9c1f ffa68b94 80eef1b8 00000a20 0xffa68b9c

8054887c f92a362d ffa780a0 80eef1b8 00000a20 tdifilter_testdriver+0xc1f

805488e0 f92a8e39 80eef1b8 00001150 80548a00 tcpip!IndicateData+0x225

80548968 f929cef5 ffbb9bf0 2201a8c0 fec12ecf tcpip!TCPRcv+0x160d

805489c8 f92bae4d 00000020 ffbb9bf0 f929f076 tcpip!DeliverToUser+0x18e

80548a7c f929b922 ffbb9bf0 fa536822 00000134 tcpip!IPRcvPacket+0x670

80548abc f929b84d 00000000 ffb419b8 fa536800 tcpip!ARPRcvIndicationNew+0x149

80548af8 fa895c9f ffbba008 00000000 fa717b40 tcpip!ARPRcvPacket+0x68

80548b4c fa71201d 00b40c88 ffb81150 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x1c2

80548b60 fa7121b4 ffb567a0 ffb81150 00000001 psched!PsFlushReceiveQueue+0x15

80548b84 fa7125f9 ffb3b158 00000000 ffb567a0 psched!PsEnqueueReceivePacket+0xda

80548b9c fa895d40 ffb3b150 80f26008 80f26014 psched!ClReceiveComplete+0x13

80548bec fae05387 00b40c88 80548e0c 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x5a4

80549014 fa88bf09 80f26008 80551d80 80551b20 vmxnet+0x2387

8054902c 80540f7d 80f264bc 80f264a8 00000000 NDIS!ndisMDpcX+0x21

80549050 80540ef6 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46

80549054 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26

STACK_COMMAND:  kb

FOLLOWUP_IP:

tdifilter_testdriver+c1f

fb0e9c1f 8945f4          mov     dword ptr [ebp-0Ch],eax

SYMBOL_STACK_INDEX:  5

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: tdifilter_testdriver

IMAGE_NAME:  tdifilter_testdriver.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  469b8e19

SYMBOL_NAME:  tdifilter_testdriver+c1f

FAILURE_BUCKET_ID:  0xD1_W_tdifilter_testdriver+c1f

BUCKET_ID:  0xD1_W_tdifilter_testdriver+c1f

Followup: MachineOwner

July 17, 2007 at 8:33 pm #6329

Dmitry_177

Participant

Я сейчас еще раз попробовал, сейчас мне немного подругому анализ написался:

kd> !analyze -v

*******************************************************************************

*                                                                             *

*                        Bugcheck Analysis                                    *

*                                                                             *

*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

An attempt was made to access a pageable (or completely invalid) address at an

interrupt request level (IRQL) that is too high.  This is usually

caused by drivers using improper addresses.

If kernel debugger is available get stack backtrace.

Arguments:

Arg1: ff49a978, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000001, value 0 = read operation, 1 = write operation

Arg4: ffa4d4d7, address which referenced memory

Debugging Details:

WRITE_ADDRESS:  ff49a978 Nonpaged pool expansion

CURRENT_IRQL:  2

FAULTING_IP:

+ffffffffffa4d4d7

ffa4d4d7 001400          add     byte ptr [eax+eax],dl

DEFAULT_BUCKET_ID:  INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR:  0xD1

PROCESS_NAME:  Idle

TRAP_FRAME:  805487d4 -- (.trap ffffffff805487d4)

ErrCode = 00000002

eax=ffa4d4bc ebx=00000e20 ecx=ffb84008 edx=80da0200 esi=ffb9b8b8 edi=ffb8ef08

eip=ffa4d4d7 esp=80548848 ebp=8054887c iopl=0         nv up ei pl nz ac pe cy

cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010217

ffa4d4d7 001400          add     byte ptr [eax+eax],dl      ds:0023:ff49a978=??

Resetting default scope

LAST_CONTROL_TRANSFER:  from 804f79d7 to 80526fc8

STACK_TEXT:

80548388 804f79d7 00000003 805486e4 00000000 nt!RtlpBreakWithStatusInstruction

805483d4 804f85c4 00000003 ff49a978 ffa4d4d7 nt!KiBugCheckDebugBreak+0x19

805487b4 8053fa73 0000000a ff49a978 00000002 nt!KeBugCheck2+0x574

805487b4 ffa4d4d7 0000000a ff49a978 00000002 nt!KiTrap0E+0x233

WARNING: Frame IP not in any known module. Following frames may be wrong.

80548844 fb051c1f ffa4d4bc ffb84008 00000e20 0xffa4d4d7

8054887c f92a362d 80da0200 ffb84008 00000e20 tdifilter_testdriver!HookedClientEventReceive+0xaf [c:drvmain.c @ 160]

805488e0 f92a8e39 ffb84008 00001950 80548a00 tcpip!IndicateData+0x225

80548968 f929cef5 80dea670 2201a8c0 9bd03fa6 tcpip!TCPRcv+0x160d

805489c8 f92bae4d 00000020 80dea670 f929f076 tcpip!DeliverToUser+0x18e

80548a7c f929b922 80dea670 fa52d022 000001cc tcpip!IPRcvPacket+0x670

80548abc f929b84d 00000000 80f038f0 fa52d000 tcpip!ARPRcvIndicationNew+0x149

80548af8 fa895c9f ffb73008 00000000 fa717b40 tcpip!ARPRcvPacket+0x68

80548b4c fa71201d 00e61ed8 ffb961f0 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x1c2

80548b60 fa7121b4 ffb586a8 ffb961f0 00000001 psched!PsFlushReceiveQueue+0x15

80548b84 fa7125f9 80e017d8 00000000 ffb586a8 psched!PsEnqueueReceivePacket+0xda

80548b9c fa895d40 80e017d0 80df15d8 80df15e4 psched!ClReceiveComplete+0x13

80548bec fae05387 00e61ed8 80548e0c 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x5a4

80549014 fa88bf09 80df15d8 80551d80 80551b20 vmxnet+0x2387

8054902c 80540f7d 80df1a8c 80df1a78 00000000 NDIS!ndisMDpcX+0x21

80549050 80540ef6 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46

80549054 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26

STACK_COMMAND:  kb

FOLLOWUP_IP:

tdifilter_testdriver!HookedClientEventReceive+af [c:drvmain.c @ 160]

fb051c1f 8945f4          mov     dword ptr [ebp-0Ch],eax

FAULTING_SOURCE_CODE:

156: 								 BytesIndicated,

157: 								 BytesAvailable,

158: 								 BytesTaken,

159: 								 Tsdu,

>  160: 								 IoRequestPacket);

161:

162: 	DbgPrint("tdi_sniffer

***NEXT***

n");

163:

164: 	return ntStatus;

165: }

SYMBOL_STACK_INDEX:  5

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: tdifilter_testdriver

IMAGE_NAME:  tdifilter_testdriver.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  469d23da

SYMBOL_NAME:  tdifilter_testdriver!HookedClientEventReceive+af

FAILURE_BUCKET_ID:  0xD1_W_tdifilter_testdriver!HookedClientEventReceive+af

BUCKET_ID:  0xD1_W_tdifilter_testdriver!HookedClientEventReceive+af

Followup: MachineOwner

В прошлый раз небыло раздела FAULTING_SOURCE_CODE. Т.е. я как понимаю вся загвоздка в последнем параметре IoRequestPacket который передается в оригинальную функцию??? Интересно из-за чего..

July 20, 2007 at 11:02 am #6330

Dmitry_177

Participant

У меня получилось 😀 Я оказывается адрес неправильно оригинальной функции передавал.. 😆 Мне теперь намного понятней стало при работе в ring0 😀

Подскажи еще пожалуйста а вот TDI_EVENT_RECEIVE_DATAGRAM когда устанавливается? Что за датаграммы? Используются ли они при обычном лазании по сайтам, использования аськи, всяких других программ общения и всяких почтовых программ? Что-то не совсем понимаю что за датаграммы такие..

July 20, 2007 at 1:26 pm #6331

Vadim Smirnov

Keymaster

Что-то не совсем понимаю что за датаграммы такие..

UDP протокол

July 20, 2007 at 1:45 pm #6332

Dmitry_177

Participant

а если компьютер в сети, на работе например, а интернет у всех общий.. он может работать через прокси так и без него, вобщем кто как везде сделает.. вот при лазании по интернету через такую сеть, какой протокол используется UDP или TCP? на сколько я знаю UDP это внутрисетевой протокол, вот у меня и возник такой вопрос..

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

и еще, почитав про TDI_EVENT_CHAINED_RECEIVE и TDI_EVENT_RECEIVE_EXPEDITED что-то не очень пойму в каких случаях они устанавливаются.. подскажи пожалуйста, чтобы мне понятней было.. я как понимаю больше ничего ненадо перехватывать чтобы отслеживать входящий трафик?

July 20, 2007 at 6:13 pm #6333

Dmitry_177

Participant

перехватываю еще ClientEventChainedReceive сам перехват срабатывает, но данные почему-то из Tsdu немогу вытянуть.. Делаю так:

NTSTATUS HookedClientEventChainedReceive(IN PVOID				TdiEventContext,

IN CONNECTION_CONTEXT	ConnectionContext,

IN ULONG				ReceiveFlags,

IN ULONG				ReceiveLength,

IN ULONG				StartingOffset,

IN PMDL				Tsdu,

IN PVOID				TsduDescriptor)

{

UCHAR		*sduBuffer;

DbgPrint("tdi_sniffer:

***BEGIN TDI_EVENT_CHAINED_RECEIVE***

n");

sduBuffer = MmGetSystemAddressForMdlSafe (Tsdu, LowPagePriority);

DbgPrint(sduBuffer);

DbgPrint("tdi_sniffer:

***END TDI_EVENT_CHAINED_RECEIVE***

n");

return ((OLDCLIENTEVENTCHAINEDRECEIVE)((PCLIENTEVENTRECEIVECONTEXT)TdiEventContext)->EventHandler)(((PCLIENTEVENTRECEIVECONTEXT)TdiEventContext)->EventContext,

ConnectionContext,

ReceiveFlags,

ReceiveLength,

StartingOffset,

Tsdu,

TsduDescriptor);

}

т.к. в Tsdu содержится MDL адрес, вытягиваю данные функцией MmGetSystemAddressForMdlSafe.. и почему-то никакие принятые данные не отображаются..

July 23, 2007 at 2:57 pm #6334

Dmitry_177

Participant

SerpentFly, помоги пожалуйста.. в исходниках того файрвола нету перехвата именно данных из ClientEventChainedReceive…

July 28, 2007 at 3:22 pm #6335

Dmitry_177

Participant

SerpentFly, не поможешь? 🙁

Author

Posts

Viewing 15 posts - 46 through 60 (of 62 total)

← 1 2 3 4 5 →

You must be logged in to reply to this topic.