Forum Replies Created
-
Posts
-
You was answered by e-mail. 🙂
1. There are any documents or information with potential restrictions or conflicts with any other commercial software?
Regretfully we can’t guarantee that you won’t ever meet compatibility problems when using WinpkFilter because any driver based on the similar technology (NDIS hooking) but implemented on the different or incorrect way may cause a conflict. That’s why the latest release of WinpkFilter in addition to NDIS hooking based driver also includes the driver based on NDIS intermediate driver technology (it should not cause any compatibility issues but it has some other disadvantages, like installation an example). So for those users who need some specific compatibility you can create a special build with NDIS IM based driver.
Luckily, so far we are aware about the only irresolvable conflict of WinpkFilter with Sygate firewall, but since it was recently bought by Symantec and discontinued then it is not a real problem anymore.
2. My license covers solutions to any potential conflicts found with some other software?
Some conflicts are resolvable, and we always trying to keep WinpkFilter up-to-date and compatible with any other commercial software. However, sometimes the compatibility problem can’t be resolved (like it was with Sygate, it patched TCPIP.SYS image and the only way to achieve the compatibility with it was implementing similar ugly hooking).
3. Once I get the Source license, Is there any restriction to source code modify? E.g.: Only drivers, not Winpkfilter API, etc.
The only restriction applied to Source Code license is that you can’t distribute/resell the WinpkFilter driver’s source code. You are free to modify drivers on the way you want and distribute your solutions in binary form.
Sorry, 4th question is not answered here because we have not permissions from our clients to use their names for online ad.
Custom build is usually created in 48 hours (needs some time for building and testing the resulting solution).
– не знаю можешь ли ты написать TDImon, но на вскидку, через TDI_SET_EVENT_HANDLER можно зарегистрировать клиентские callback и этот метод применим к способу Attach, а не patch.
Оба метода и patch и attach очень близки по реализации. И обработка event handler в них проводится аналогично.
Could you please specify the exact version of the NeT Firewall you are using. There were some problems relative to MMC console initialization and shutdown, but we hope we had fixed them.
However, there is also a chance that NeT Firewall driver was not succesfully installed on your system. Did you have NeT Firewall working at all? Is it just a startup/shutdown problem or you could not managed the firewall to work at all?
NeT Firewall should be able to see and filter packets on all locally installed Ethernet, WiFi, dial-up network adapters including the virtual ones.
Вообще говоря, краткие инструкции по сборке заказчик должен был получить вместе с исходниками. Привожу их ниже:
1) For building Windows NT/2000/XP/2003 32 bit drivers you have to use Windows DDK (DDK must be XP or higher but building environment must be 2000, some NDIS structures depends from the environment). Sources file and dbuild.bat (automatic script for building drivers) are provided with the source code.
2) For building Windows 9x/ME you need MS Visual C++ 6.0 and Compuware VToolsD (in the meantime it is available as a part of SoftIce Driver Suite and Driver Studio). It is recommended to use VToolsD (makes building and maintaining driver much easier), however VxD project with a little effort can be configured to build with Windows 9x/ME DDK (it will make building driver process a bit more complex and you will have to use at least one ASM file with VxD skeleton). VxD projects explicitly includes two files from DDK assuming that DDK (you need 9x/ME DDK or cumulative DDK which includes 9x/ME DDK as its part) is installed into the H:NTDDK, if you set up DDK to the different folder you will see failed to include message when trying to build. To fix this change the path to DDK in the vxdhooks.h.
3) For building x64 version of WinpkFilter drivers you need one of the latest Windows DDK (which supports building x64 drivers). Sources file and dbuild.bat (automatic script for building drivers) are provided with the source code. For the automatic installation of NDIS IM driver from the installation program you can use slightly modified (the original version copies only single INF file but IM driver requires copying two INF files) snetcfg sample from XP DDK. It works just fine in combination with the special script (signdrv.bat) which disables driver signing warnings (works with Windows x64, Windows XP SP2, Windows Server 2003; earlier Windows versions regretfully have bugs in signing policy implementation and script does not work properly for them).
4) NT kernel-mode driver and VxD driver share some portion of source code located in Kernelcommon folder; these are actual filtering/functional routines.
Thats right, VLAN is implemented inside NIC NDIS miniport driver, the only way to handle VLAN tags for this type of cards is NIC driver modification, since they are not visible (striped) above it.
Can I install virtual adapter programmatically?
In general yes, but I should note that this is not easy if you intend to support different Windows.I’m also not sure if it is possible on NT 4.0 at all.
Can I install 2,3…5 adapters in one system and set different MAC addresses for each adapter programmatically?
You can create more than one network device within single virtual network adapter driver. So the amswer is yes, but requires additional work.
Virtual adapter supports frame length > 1514 bytes for 802.1p/q standards?
VirtNet emulates 802.3 device, however you can create driver to emulate any kind of network device.
Sorry, I don’t know why I had replied in Russian.
You can differ WAN connections by the pair of MAC’s used (source and destination are unique for each WAN link). When the new dial-up connection is created you get a call to you ProtocolStatus handler with wan line up event and you can parse and extract the data passed to this call. However, this won’t alllow you to get the exact connection name, you’ll need a user-mode mode agent for this.
Отличать WAN соединения можно по парам MAC адресов. При создании соединения можно пропарсить данные переданные в ProtocolStatus при wan line up event, однако имени соединения оттуда не вытащить, нужно делпть агента в user-mode.
1. Что использовать для присоединения к целевому устройству:
IoAttachDevice
IoAttachDeviceToDeviceStackЕсли писать аналог TDIMon, то надо патчить таблицу мажоров TCPIP.SYS. Но это конечно если именно аналог, а так можно и через AttachDevice.
2. Я делаю фильтр, надо ли вызывать
TdiRegisterProvider
TdiRegisterDeviceObject
Думаю нет, но что скажут спецы?Нет, не надо
3. Для TDI IOCTL сделаю в фильтре аналогичные и после своей обработки (для начала ни какой) передам пакеты дальше, а что делать с TDI Client Callbacks например
ClientEventConnect
ну, скажем прототипы есть, их можно объявить и у себя, но где взять адреса оригинальных функций и как их вызвать?Перехватывать регистрацию event’ов и менять указатели на свои…
4. Еще есть TDI Library Functions and Macros
TdiBuildInternalDeviceControlIrp
TdiPnPPowerRequest и т.п.
их там тьма, что их тоже надо эмулировать?
например, для пакетов я могу объявить их часть, а “не известные” просто передавать дальше, а как также поступить с функциямиФ-ции то есть, но не понимаю зачем они тебе…
Why speed showed after install equals to 10 MBit/s? This is real limit? Really can this adapter handle mutch more speeds?
No, this is not a real limit of course. There is no actual limit for virtual adapter except system perfomance. It’s just a value reported by miniport for the corresponding OID request.
Well, this topic was already discussed before (http://www.ntkernel.com/forum/viewtopic.php?t=52&highlight=sectionobject) but in Russian. There is a more reliable way to get full image name for the process, but it requires knowledge of some undocumented structures. Here is short translation of the main approach:
1. Obtain EPROCESS pointer through IoGetCurrentProcess().
2. For NT 4.0 and 5.0 take section handle from EPROCESS(SectionHandle) and using ObReferenceObjectByHandle() we obtain SectionObject; for NT 5.1 we can take SectionObject from EPROCESS directly.
3. From SectionObject we obtain SegmentObject.
4. From SegmentObject we obtain ControlArea.
5. From ControlArea we obtain FilePointer (this is FileObject pointer).
6. Using ObQueryNameString() we obtain full process name
All operations should be performed on PASSIVE_LEVEL and in the context of the process we obtain full path for.It is safe, you pass the larger buffer to the driver but it ignores the additional bytes in the trail.
The helper libraries seem like they would support a proof of concept effort. Can anyone confirm this? Also, the PassThru sample app looked like the best place to get an idea of starting.
Yes, you can take passthru sample as base for this kind of solution. It transparently filters all incoming and outgoing packets for the specified network interface and has capability to modify them. In general I think you can implement relatively flexible solution on this way.
However, I would solve the concrete problem on a bit easier way. Let’s assume you using NT/2000/XP/2003 type of operating system. It’s not a great problem to create a driver which intercepts NT native API calls. Since creating a process on NT system requires calling a subset of native API (NtCreateFile, NtCreateSection, NtCreateProcess) you can hook one or all of them (there are several ways), check the file/process which is going to start and block/permit the operation basing on user reaction, registry setting, driver loaded settings or etc… On this way you can create a flexible solution for monitoring processes start up on your system. I would even surmise that you could find a ready solution for this approach in the Internet.
Can you share an example (C/C++) for that case, suppose the new size (changed) always less than or equals MAX_ETHER_FRAME.
Sorry, at the moment we don’t have sample which modifies TCP data length in the packet. Implementing this kind of modification is a bit more complex that just changing few bytes in the packet without changing its length. I would recommend reading some good overview of TCP protocol before trying to implement this. In two words you have to track/alter sequence and acknowledgement fields in the packets. An example, you change “sex sex” in the incoming packet with «foo”, after this modification TCP data length of the packet is reduced for 4 bytes, so you should also modify sequence number in the TCP header by reducing it to 4. This SINGLE modification affects the whole TCP connection and you should also do the following:
1) For all other incoming packets associated with this connection you should also reduce the sequence for these 4 bytes.
2) For the outgoing packets associated with this connection you have to increment an acknowledgement number for those 4 bytes.If you do more modifications then you should recalculate sequence/acknowledgement numbers shift.
