Forum Replies Created
-
Posts
-
Вообще говоря, краткие инструкции по сборке заказчик должен был получить вместе с исходниками. Привожу их ниже:
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.
Yes, you are right; there are problems with using the ndisapi.dll binary included within the WinplFilter package. The problem was caused by moving the NDISAPI project from one building environment to another so the routines exported through the DEF file were not exported anymore (this binary also is not possible to use with Delphi). We appreciate you report, WinpkFilter packages with fixed ndisapi.dll binary will be available for download in the next few days.
Fixed binary also available for download from the following link http://www.ntkernel.com/downloads/ndisapi.zip
Since WinpkFilter 3.0 we provide the complete source code for the ndisapi.dll in the freely available packages because of different building environments you may have to use. So, you can modify/port/rebuild the ndisapi.dll or even integrate it into your application.
Some others functions doesnt respect the functions declarations presented in the Help.
Could you please provide the details?
Well, DomainSuffixTool.exe is not relative to NeT Firewall. I guess that you already uninstalled NeT Firewall, and DomainSuffixTool.exe belongs to some other software you had tried and also uninstalled but not completely. I’d advise to check autorun and registry keys associated with application auto start up in order to detect the exact reason.
Blocked packets in the log were blocked by TCP stateful inspection module (these packets could be retransmitted/duplicated packets or corrupted during transmission, these could be also malicious packets but I don’t think this is the case).
You can disable TCP statefull inspection in the firewall options, but I would not recommend it.
