Heed help! NDIS driver or else

NTDEV
1

I look for better and not difficult way to resolve the simple task.

PC Env.
Windows XP 32bit
Local network 192.168.1.1/255.255.255.0
TCP Proxy service listen at local server 192.168.1.7:9099

Task.
Pass any tcp packet followed to X.X.X.X:8081 to local proxy 192.168.1.7:9099

What is the fast/rights/simple way to do that?

My idea to rewrite RemoteIP/RemotePort in outgoing packet header to new,
and rewrite same in incoming packet (from proxy) to origin Remote IP/Port.

As I know, NDIS IM driver can help me to did it.

Right?

Please left me to right way.

Thank you very much!
Dmitry

2

The translation is not quite that simple if you want to be able to translate
the ‘reverse’ flow traffic as well (which you must do if you actually want
TCP to connect).

The ‘source’ of the translated packet must appear to be an address other
than a local address so that TCPIP will ‘respond’ by sending a packet back
onto the network instead of via the loopback interface.

This means you might need to spoof additional packets like ARP to make it
appear as though the ‘spoofed’ address is present.

One way to handle this is to use the original destination IP address as the
source IP address of the translated packet.

In so far as I assume that your proxy processing will eventually want to
actually talk to the original host on the original port, you need to be
ready to exclude packets in the flow(s) established for that purpose -
usually by recognizing a bound source port # (at least).

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@mail.ru
Sent: Monday, August 30, 2010 4:38 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Heed help! NDIS driver or else

I look for better and not difficult way to resolve the simple task.

PC Env.
Windows XP 32bit
Local network 192.168.1.1/255.255.255.0
TCP Proxy service listen at local server 192.168.1.7:9099

Task.
Pass any tcp packet followed to X.X.X.X:8081 to local proxy 192.168.1.7:9099

What is the fast/rights/simple way to do that?

My idea to rewrite RemoteIP/RemotePort in outgoing packet header to new,
and rewrite same in incoming packet (from proxy) to origin Remote IP/Port.

As I know, NDIS IM driver can help me to did it.

Right?

Please left me to right way.

Thank you very much!
Dmitry

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

Thank you David!

Yes, I understand it.

I think, no need to change source.

Sample for a first packet to remote server

ORIG HEADER
SOURCE PORT: 7483
SOURCE ADDR: 192.168.1.1
DEST PORT: 8081
DEST ADDR: 83.2.1.2

REWRITED HEADER
SOURCE PORT: 7483
SOURCE ADDR: 192.168.1.1
DEST PORT: 9099
DEST ADDR: 192.168.1.7

So, packet out to network.

Response from server

ORIG HEADER
SOURCE PORT: 9099
SOURCE ADDR: 192.168.1.7
DEST PORT: 7483
DEST ADDR: 192.168.1.1

REWRITED HEADER
SOURCE PORT: 8081
SOURCE ADDR: 83.2.1.2
DEST PORT: 7483
DEST ADDR: 192.168.1.1

And handle new port where connection be established.

4

wrote in message news:xxxxx@ntdev…
> I look for better and not difficult way to resolve the simple task.

Amen.

> PC Env.
> Windows XP 32bit
> Local network 192.168.1.1/255.255.255.0
> TCP Proxy service listen at local server 192.168.1.7:9099
>
> Task.
> Pass any tcp packet followed to X.X.X.X:8081 to local proxy
> 192.168.1.7:9099
>
> What is the fast/rights/simple way to do that?

What if you just make the users to work via the proxy in a normal
conventional way, and block direct web access? No NDIS :slight_smile:
–pa

> My idea to rewrite RemoteIP/RemotePort in outgoing packet header to new,
> and rewrite same in incoming packet (from proxy) to origin Remote IP/Port.
>
> As I know, NDIS IM driver can help me to did it.
>
> Right?
>
> Please left me to right way.
>
> Thank you very much!
> Dmitry
>

5

I misunderstood your statement “local proxy” to mean local to the same host.
But now I see you simply mean local to the same network so your are correct,
no need to rewrite the SrcIp.

However, now you must implement ARP to resolve the MAC address of the
proxy.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@mail.ru
Sent: Monday, August 30, 2010 6:46 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Heed help! NDIS driver or else

Thank you David!

Yes, I understand it.

I think, no need to change source.

Sample for a first packet to remote server

ORIG HEADER
SOURCE PORT: 7483
SOURCE ADDR: 192.168.1.1
DEST PORT: 8081
DEST ADDR: 83.2.1.2

REWRITED HEADER
SOURCE PORT: 7483
SOURCE ADDR: 192.168.1.1
DEST PORT: 9099
DEST ADDR: 192.168.1.7

So, packet out to network.

Response from server

ORIG HEADER
SOURCE PORT: 9099
SOURCE ADDR: 192.168.1.7
DEST PORT: 7483
DEST ADDR: 192.168.1.1

REWRITED HEADER
SOURCE PORT: 8081
SOURCE ADDR: 83.2.1.2
DEST PORT: 7483
DEST ADDR: 192.168.1.1

And handle new port where connection be established.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

6

to Pavel
I just want to implement it and learn this process.
Thanks Pavel!

to David
David, you are right!
I don’t thought about this case, where all this on same host!

Cause NDIS below TCP/IP,
if I rewrite only destination TCP port in packet, it will pass to miniport driver and into nic card…
I imagine, this wouldn’t works…

So, as you’ve posted above, if I rewrite source to dest, does miniport/nic card will ‘reverse’ it packet back to stack?

Sample
Local proxy listen 127.0.0.1:9099

Application try to connect to not listen local port (127.0.0.1:8081) and we will rewrite it.

ORIG HEADER
SOURCE PORT: 7483
SOURCE ADDR: 127.0.0.1
DEST PORT: 8081
DEST ADDR: 127.0.0.1

REWRITED HEADER
SOURCE PORT: 7483
SOURCE ADDR: 127.0.0.1
DEST PORT: 9099
DEST ADDR: 127.0.0.1

So, packet pass below to miniport driver and to nic card.

What is happen in this case?
May be, tcp/ip driver not pass this packet to NDIS and proceed it itself, make port unreachable response…

David, sorry for my detail investigate, I just wont to understand how all its works.

PS: Why I need to pass packet thru NDIS but not direct to listen port, as sample, I can implement en/decryption in NDIS or similar service.

7

The miniport does not do any ‘reversing’ (loopback) based on IP address. In
fact, the miniport ignores pretty much all but the MAC header and will
always send the packet onto the wire with the destination MAC address
determining if any other station (or stations) will accept the packet for
receive.

If your IM driver is to perform as I noted, the IM driver itself must make a
copy of the original packet, perform the translation, and then ‘reverse’ (by
indicating a receive) the packet itself.

Please also understand that addresses on the ‘loopback’ interface are not in
general going to work (though, I cannot recall if in NT5 this is enforced by
the stack). The IM driver is filtering one or more interfaces. Those
interfaces have IP addresses and are attached to a network (either as a
point-to-point, point-to-multipoint, or multicast link). The one interface
an IM driver is *never* attached to (and thus can filter) is the loopback
interface. An NDIS IM filter driver can only filter traffic that passes
across interfaces on adapter devices with NDIS miniport drivers.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@mail.ru
Sent: Tuesday, August 31, 2010 3:57 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Heed help! NDIS driver or else

to Pavel
I just want to implement it and learn this process.
Thanks Pavel!

to David
David, you are right!
I don’t thought about this case, where all this on same host!

Cause NDIS below TCP/IP,
if I rewrite only destination TCP port in packet, it will pass to miniport
driver and into nic card…
I imagine, this wouldn’t works…

So, as you’ve posted above, if I rewrite source to dest, does miniport/nic
card will ‘reverse’ it packet back to stack?

Sample
Local proxy listen 127.0.0.1:9099

Application try to connect to not listen local port (127.0.0.1:8081) and we
will rewrite it.

ORIG HEADER
SOURCE PORT: 7483
SOURCE ADDR: 127.0.0.1
DEST PORT: 8081
DEST ADDR: 127.0.0.1

REWRITED HEADER
SOURCE PORT: 7483
SOURCE ADDR: 127.0.0.1
DEST PORT: 9099
DEST ADDR: 127.0.0.1

So, packet pass below to miniport driver and to nic card.

What is happen in this case?
May be, tcp/ip driver not pass this packet to NDIS and proceed it itself,
make port unreachable response…

David, sorry for my detail investigate, I just wont to understand how all
its works.

PS: Why I need to pass packet thru NDIS but not direct to listen port, as
sample, I can implement en/decryption in NDIS or similar service.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

8

> point-to-point, point-to-multipoint, or multicast link). The one interface

an IM driver is *never* attached to (and thus can filter) is the loopback
interface.

IIRC in Windows 127.0.0.1 is not an NDIS object at all, and implemented within tcpip.sys

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

9

Thank you Dave!!!

Thank you Maxim!!!

I study possibilities of NDIS, and now post new thread, its about tcpip.sys

http://www.osronline.com/cf.cfm?PageURL=showlists.CFM?list=NTDEV