Re: Socket Filter NKE
Re: Socket Filter NKE
- Subject: Re: Socket Filter NKE
- From: Josh Graessley <email@hidden>
- Date: Wed, 9 Dec 2009 11:11:30 -0800
Hi Jakub,
There's no reason it wouldn't work for incoming connections but it will be a little tricky. You'll want to create the listening socket that incoming connections will initially connect to.
When an application wants to accept incoming connections on a TCP socket, it must first call listen. I think your filter will have an opportunity to intercept the listen call (it's been a really long time since I was looking at that code). At the point of the listen, you'll need to figure out what address the socket is bound to (sock_getsockname). You could probably bind the socket to a new address and then tell your process to open a listening socket bound to the original address/port pair. If the port is zero, the socket your filtering did not specify a port, so your application can also bind do zero. After you've done this, you'll need to over ride the getsockname function for that socket to return whatever address/port your filtering applications listening socket is bound to.
This should result in your application having a listening socket bound to the address/port that the application you're intercepting thinks it is listening on. When a connection comes in, your process should open a second socket to the listening socket your process is intercepting (at the new address/port that you rebound to).
I'm not certain you can call bind a second time on a TCP socket, although if the socket hasn't been connected yet or listening hasn't started, I think that should work. If changing the bind isn't an option, you'll have to do some ugly stuff around intercepting the initial bind. That's going to be especially gross because at the point the bind occurs, you won't know if the application wants to use that socket for an inbound or outbound connection.
Hope this helps at least give you some ideas. Sorry to be so vague.
-josh
On Dec 9, 2009, at 7:09 AM, Jakub Bednar wrote:
> Hi Josh,
>
> thanks a lot for a fast response. I have run some tests with redirecting outgoing connections both on Leopard and Snow Leopard and it works just fine. I just wonder, can the NKE redirect also incoming connections?
>
> Jakub
>
> On Dec 3, 2009, at 7:20 PM, Josh Graessley wrote:
>
>>
>> The recommeded solution is to manipulate connections to connect to
>> your process instead of their intended destination. You may pass the
>> intended destination out of band to your processs and then relay the
>> data in user space between the socket connection from their process
>> and your socket connection to their intended destination.
>>
>> Sent from my iPhone
>>
>> On Dec 3, 2009, at 7:38, Jakub Bednar <email@hidden> wrote:
>>
>>> Hello list,
>>>
>>> I am writing a socket filter NKE that will intercept any TCP
>>> connections, pass its data to user-space processing using
>>> SYS_PROTO_CONTROL and then re-inject them back. I have read many
>>> posts in Apple mailing lists and the guides discussing NKE and
>>> Kernel Programming and up to now everything worked great.
>>>
>>> Today I have found a problem with one-way traffic ended with FIN
>>> sequence. In this case, the TCP reacts on the FIN and a
>>> sf_detach_func is called to my filter, while I still have some data
>>> swallowed and waiting for user-space to process it.
>>>
>>> I can't reinject the packets as I don't want to leave any data
>>> unprocessed.
>>> If I drop the packets, the client won't get them all, leading to
>>> errors.
>>>
>>> Can anyone please point me to any documentation discussing the
>>> socket filters in more detail? Can I msleep in sf_notify_func or
>>> sf_detach_func to let user-space process finish the scanning? Or can
>>> I somehow deny the socket detach and do it myself later?
>>>
>>> Thanks a lot for Your help,
>>>
>>> Jakub
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Darwin-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden