Forum Replies Created
-
Posts
-
Отличать 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.
Since Sygate firewall discontinued by Symantec it won’t cause compatibility problems anymore.
http://www.geek.com/news/geeknews/2005Nov/gee20051130033532.htm
pIpHeader = (iphdr_ptr)(pPacketBuffer->m_IBuffer + ETHER_HEADER_LENGTH);
pTcpHeader = (tcphdr_ptr)(((PUCHAR)pIpHeader) + sizeof(DWORD)*pIpHeader->ip_hl);pIPHeader = (iphdr*)PacketBuffer.m_IBuffer+14;
Typecasting has a higher priority than operator + above. You have to change it to:
pIPHeader = (iphdr*)PacketBuffer.m_IBuffer[14];
or
pIPHeader = (iphdr*)(PacketBuffer.m_IBuffer+14);
Can I limit bandwidth using winpkfltr for each ip/source combination?
Yes
If so, Please give me some directions on how to do this?
The basic idea is pretty simple. One possible realization is the following. Create a queue and put all packets into. Also create a periodic timer and each time when timer fires calculate time passed since last timer. Then claculate the amount of data you can allow to pass for the given time and process as many packets from the queue as it fits into clculated amount of data.
