Forum Replies Created
-
Posts
-
Is there any exported variable like “NtBuildNumber” which keeps the Version Number and CSD String.
NtBuildNumber is exported by kernel, CSD string with service pack not.
Но у меня этот код почему-то постоянно синий экран выдает… никак не могу понять почему.
А отладчик на что?
SerpentFly, помоги пожалуйста.. Все что я смог сделать я отобразил это в коде.. Я реально зашел в тупик.. Помоги пожалуйста..
ClientEventReceive это не единственный event handler, который нужно перехватить, есть еще ClientEventReceiveExpedited, ClientEventChainedReceive.
И подскажите пожалуйста как вытащить принятые пакеты и от куда их вообще нужно вытаскивать, из Tsdu?
Да, вообще повнимательней читай DDK, там все написано в комментариях к event handler’ам.
have set the mode of capturing as follows:
ADAPTER_MODE Mode;
Mode.dwFlags = MSTCP_FLAG_RECV_TUNNELis that correct??
This will allow you to pre-process all packets received by your system, if this is what you intended to do then this is correct.
If the WinPKFilter installed in a gateway can it capture the packets that send to another destination IP address not of the gateway itself (if can tell me how can I do this by providing me with some code samples) or it can only capture the packets that send with destination IP address of the gateway only.
Routed packets (destined to systems different from the Gateway) are also captured. Actually they are captured twice, when received on one network interface and when forwarded to another one.
I realized the net control its done by implementing a firewall-hook driver… the idea is to make a function filter that it is called when its revieved a package and discarded/accepted depends on the logic of the function filter. It uses ipfirewall.h wich was introduced in Win 2000 DDK … so this is a case of “functions added in Windows 2000 kernel and missed in NT4”, isnt it?
Firewall hook driver was added in Windows 2000 and you are right that you can’t use it under Windows NT. Actually there are two options to implement firewall in Windows NT:
1) NDIS IM driver
2) NDIS hooking driverNDIS IM is pain in Windows NT, this type of driver was improved only with Windows 2000 release. So I would recommend NDIS hooking one. Implementing such type of driver from the scratch is not easy task and you better find something ready, like WinpkFilter.
RTFM DDK
Windows XP and below:
BOOLEAN
PsGetVersion(
PULONG MajorVersion OPTIONAL,
PULONG MinorVersion OPTIONAL,
PULONG BuildNumber OPTIONAL,
PUNICODE_STRING CSDVersion OPTIONAL
);
Parameters
MajorVersion
Points to a caller-supplied variable that this routine sets to the major version of the operating system. This optional parameter can be NULL.
MinorVersion
Points to a caller-supplied variable that this routine sets to the minor version of the operating system. This optional parameter can be NULL.
BuildNumber
Points to a caller-supplied variable that this routine sets to the current build number of the operating system. This optional parameter can be NULL.
CSDVersion
Points to a caller-allocated buffer in which this routine returns the current service-pack version as a Unicode string only during system driver initialization. This optional parameter can be NULL.Windows XP and above
NTSTATUS
RtlGetVersion(
IN OUT PRTL_OSVERSIONINFOW lpVersionInformation
);
Parameters
lpVersionInformation
Pointer to either a RTL_OSVERSIONINFOW structure or a RTL_OSVERSIONINFOEXW structure that contains the version information about the currently running operating system. A caller specifies which input structure is used by setting the dwOSVersionInfoSize member of the structure to the size in bytes of the structure that is used.typedef struct _OSVERSIONINFOEXW {
ULONG dwOSVersionInfoSize;
ULONG dwMajorVersion;
ULONG dwMinorVersion;
ULONG dwBuildNumber;
ULONG dwPlatformId;
WCHAR szCSDVersion[ 128 ]; // Maintenance string for PSS usage
USHORT wServicePackMajor;
USHORT wServicePackMinor;
USHORT wSuiteMask;
UCHAR wProductType;
UCHAR wReserved;
} RTL_OSVERSIONINFOEXW;1. Should I use DDK NT for the migration? Is it impossible to use later DDKs? I have XP DDK that contains a libw2k, libwxp, libwnet… but no something like libwnt. I ask it because I would want to use Ntstrsafe.lib and it is *said that I can use it for NT, but there is no Ntstrsafe.lib in DDK NT.
You can use Windows XP DDK and build NT driver with Windows 2000 building environment. Just avoid using functions added in Windows 2000 kernel and missed in NT4 (most of WDM stuff). Also, don’t forget to link exsup.lib to your driver, otherwise you may get some problems with trying to load your driver on Windows NT (an example if it uses SEH).
2. When I try to compile the driver with NT DDK as we can expect I get a lot of errors… unknown symbol OBJ_KERNEL_HANDLE, unfinded ndis.h, etc. What strategies do you advice me to resolve it? should i rewrite some entire parts of the code or could I fix it with a few changes? when I comment the ndis.h include it has a great impact … i guess there is no way to use it in NT drivers… so much changed the net interface?
OBJ_KERNEL_HANDLE, was added in Windows 2000, so you better make a workaround for this (move the code which operates with handles into the context of the System thread). ndis.h presents in Windows NT DDK, so basically there should not be any real problem with it. Just be more careful with NDIS version definitions.
3 and last. Im debugging the xp version with WinDbg through a serial COM1 cable. Can you recommend me better way to do it? I mean, something with virtual machine would be enough for this job?
You can run test system under VMWare, it works just fine with WinDBG. Under Windows NT4 it may be also useful to try SoftIce (it is discontinued but for NT4 works quite well).
Я уже спрашивал, так правильно будет перехватывать?
Да
Ну и соответственно и контекст еще так же присвоить…
Да
А еще, подскажете пожалуйста как в драйвере хранить список
Можешь свой список сделать. Можешь использовать встроенные односвязные или двухсвязные. Смотри функции:
InitializeListHead, ExInterlockedInsertHeadList, ExInterlockedInsertTailList, ExInterlockedRemoveHeadList, ExInterlockedPopEntryList, ExInterlockedPushEntryList, InsertHeadList, InsertTailList, IsListEmpty, KeInitializeSpinLock, PopEntryList, PushEntryList, RemoveEntryList, RemoveHeadList, RemoveTailListЧто-то я не пойму.. а как тогда хранить для каждого address object свой оригинал callback функции? и потом еще в самой callback функции определять какой оригинал вызывать..
Честно говоря, если после моего предыдущего пояснения остались вопросы, то может тогда не стоит и браться за подобный проект? Лучше возьмите за основу что-нибудь готовое, иначе на написание первого стабильного драйвера потратите уйму времени Да и TDI в Vista уже depreciated, так что стоит ли напрягаться…
🙄Распишу что я имел ввиду. Для каждого address object аллокируем некую структуру, которую храним у себя например в списке. В этой структур помимо прочих полей, которые могут понадобится, мы сохраняем оригинальный адрес ClientEventReceive и оригинальный контекст, который должен быть в нее передан. В обработчике TDI_SET_EVENT_HANDLER с TDI_EVENT_RECEIVE подменяем оригинальную ClientEventReceive и контекст заменяем на адрес той структуры, которая у нас оборачивает address object. Соответсвенно, в новом обработчике ClientEventReceive имеем указатель на структуру с оригинальным обработчиком и контекстом. Теперь понятно? 8)
IrpSp->FileObject
Pointer to an open file object representing a local-node address. The transport uses the FsContext and, possibly, FsContext2 fields to access the state it maintains about this address.
Depending on the type of ClientEventXxx handler to be registered, this address might be or become associated with an established endpoint-to-endpoint connection made by this client.Хендлеры ставятся в контексте address object, то есть сохранять подменять нужно не для разных потоков, а для разных address object.
IrpSp->Parameters
Pointer to a TDI_REQUEST_KERNEL_SET_EVENT structure, defined as follows:
struct _TDI_REQUEST_KERNEL_SET_EVENT {
LONG EventType;
PVOID EventHandler;
PVOID EventContext;
} TDI_REQUEST_KERNEL_SET_EVENT, *PTDI_REQUEST_KERNEL_SET_EVENT;
The transport uses the members of this structure as follows:EventType
Specifies the type of ClientEventXxx handler to be registered (see Comments).
EventHandler
Specifies the entry point of the ClientEventXxx routine to be called when this type of event occurs. This member can be NULL if the client is deregistering a previously registered event handler.
EventContext
Specifies a pointer to be passed, uninterpreted by the transport, to the given ClientEventXxx routine whenever it is called. This member is NULL if EventHandler is NULL.Можно подменить EventContext на некую собственную структуру оборачивающую address object и содержащую указатель на оригинальный ClientEventReceive.
P.S. А вообще вместо изобретения велосипеда стоило заглянуть в Resources и сходить по ссылке http://sourceforge.net/projects/tdifw
Во-первых, до того как будет вызван оригинальный обработчик никаких данных в IRP TDI_RECEIVE нет и быть не может, так как IRP перехвачен на пути от приложения к сети, а не наоборот. Так можно только TDI_SEND поймать.
Ну а во вторых, большинство TDI клиентов используют не IRPs с TDI_RECEIVE, а устанавливают callbacks на события с использованием TDI_SET_EVENT_HANDLER (в случае с receive это ClientEventReceive). В DDK все написано.
Ну так а что сделано чтобы получать входящий траффик? Обычно входящие данные идут через callbacks, соответственно нужно перехватывать их установку.
ЗЫ К суппорту тема не имеет отношения, для подобных вопросов есть отдельная борда Windows Internals
ЗЗЫ Тему отредактировал, следите за кодировкой…
Еще небольшой вопросик, в поставке за 3500 $ входят исходники NDIS IM драйвера?
Да, конечно.
Собственно говоря, драйвера разделяют значительный обьем кода между собой. При разработске kernel mode решения это удобно, так как можно расширять этот общий код и при условии использования некотрых ограничений писать кроссплатформенный код.
Ну данная метода мне известна, просто подразумевается что софт будет работать и на 2К.
В принципе в Windows 2000 есть возможность получить такую же табличку как и в Windows XP+ с использованием некоторого количества недокументированных структур. Детали правда я уже не помню, но можно поискать/восстановить.
В догонку тогда еще вопрос. Как с помощью вашего драйвера отбросить ИСХОДЯЩЕЕ соединение например на какойто порт?
Пропарсить заголовки исходящего пакета и если окажется что это TCP SYN пакет на тот порт, что иы хотим заблокировать, то просто не возврашать пакет стеку.
