I need to write an application that will proxify some other application (redirect all network traffic to other proxy server). Just like FreeCap, ProxyCap, etc. Can anyone here points me to API I should be using? Preferably the API that will work under 2k, XP, Vista and W7.
There are couple of APIs that you may use for this task.
One is LSP (Layered Service Providers) which is a Winsock2 API for writing Service Provider DLLs that can intercept all Winsock calls, like connect() or WSAConnect(). Read more on this here: www.komodia.com
Another is "detours" which is Microsoft's library for intercepting any API call. More on this here: research.microsoft.com/en-us/projects/detours/
Another is so-called IAT (Import Address Table) patching. Don't have a link for this.
Another approach is to write a DLL, name it "wsock32.dll", implement all Winsock2 calls that your target app uses, and simply place it to the folder with the target app. When the app will start, it will use the local "wsock32.dll" instead of the system one.
In general, you want to use some of these APIs to intercept the Winsock's connect() or WSAConnect() calls, do the connection thru the proxy in your code, and return your connected socked to the caller.
You probably want to read about DLL injection as well.
Can't you use some routing rules for that?
If not, write some simple server application in the technology You're in. I'm sure you'll find many examples in the network.
Related
I get to know that we can use List to make different rooms/lobby over server. I am new to server side development. I am bit confuse now. Like i need to make list(rooms) at server side. So which module I'll use to make server side code ? should i code using node js module of deepstream . Currently i have just connected to deepstream server and also connected rethinkdb and redis cache connector. So do i need to write a separate node module to do server side coding using node deepstream.io-client-js ? or do i need to implement a server over deepstream.io module?
it would be a great help if anyone can tell
When using deepstream, the notion of 'server-side coding' is less clear than in traditional http-based applications. Usually the client will communicate directly with the deepstream server, and often application logic can be defined directly in the client. Security is then provided by configuring Valve permissions and authentication in the deepstream config.
For cases where application logic cannot be handled securely on the client, we recommend setting up Data Providers. Here, one or more 'provider' servers will run a deepstream client and provide access to a resource through deepstream's RPCs (remote procedure calls) or using the Active Provider pattern.
I'm writing a server that needs to serve many clients. The traffic is NOT http (but rather some proprietary protocol on top of TCP). I'm not very familiar with commercial web servers such as IIS and Apache. Can anyone tell me if it's possible to write some sort of "extension" to run on top of one of these platforms so that I don't have to write the logic for the sockets? Or perhaps there is another way (not IIS or Apache) of doing it which is better?
My server is generally going to behave as a web service (gets request, queries db, sends response) however there is one scenario in which it stays connected to the client socket and sends updates at a given interval on that socket.
It seems reasonable for it to be a way to do this in a way that I'd only have to write my logic without the general logic of a server. Any ideas?
Thanks!
Good question, and its also good too look to leverage an existing web server - you get scalability and stability, effectively for free.
I've never done this myself, but it should be totally possible in IIS (i recommend v7+ for this, makes it easier).
You can set up a new web site through the administration tool, and assign it a port to listen on - this bit is pretty straight forward. You should set its Binding Type to net.tcp (this is a dropdown in the dialog to add a new website, you can't miss it).
You can then use either modules or handlers to implement the rest of your custom functionality. This article Developing IIS 7.0 Modules and Handlers with the .NET Framework is a good intro to the subject. Most of the doco out there about writing custom handlers and modules is focussed on the HTTP protocol, but there are some snippets floating around for TCP and/or net.tcp (because IIS and Apache are web servers, and web is synonymous with http). Another resource that may be useful is this: Configure Request-Processing for a Web Server (IIS 7)
Alternatively, you may consider changing your approach and do it as a net.tcp WCF service, with this you get the benefits of using IIS, the flexibility of choosing the protocol (can be statically configured, doesn't need to be compiled in), and you don't have to write handlers or modules.
Ok so what I want to do is create a background agent that monitors http traffic to/from a certain application and performs actions when there are requests and responses to a certain website. Is there a good way to do this in Cocoa? I'd like to avoid using really low level sniffing and/or requiring root access to do this (admin access is ok).
If the application your trying to monitor supports proxy servers you could write one and use that in your app. That probably is the easiest solution.
If that doesn’t work you could use something like mach_inject and mach_override to overwrite some socket system calls (socket and write probably are enough) in the program you’re going to monitor. That’s some kind of dark art though, so you’re probably better off using a packet sniffer like tcpdump and control that using a pipe.
Admin privileges (which are almost the same as root) are required for all of this, except the proxy solution.
Here's tcpdump and it's library libpcap:
http://www.tcpdump.org/tcpdump_man.html
and
http://www.tcpdump.org/pcap3_man.html
There's a tutorial here:
http://www.tcpdump.org/pcap.htm
Like Sven said you'll need admin privileges to do anything spectacular.
this is B2B scenario, one client (at least for now).
Server environment:
WCF service, IIS6, .NET v3.5
Client environment:
dev shop is .NET 2.0/VS2005. Will be calling my WCF service.
Question: should i
(a) open WSDL gen for the client(not desirable for security reasons)
(b) send a WSDL file(s) to the client
(c) pre-compile Proxy into dll (on my side) and send it to the client
(d) ???
?
Any suggestions on what would be the best practice for this scenario, any pros/cons?
Thanks in advance,
Igor
Why is a publicly available WSDL not desirable for security reasons?
I may be willing to admit that publishing an API (which is basically what you are doing with WSDL) makes you a bit more vulnerable than if you didn't, but it would be wrong to assume that hiding the WSDL constitutes any kind of security. This is ironically called security by obscurity, and it will be broken by any determined attacker.
The web service should be secure in itself. WCF offers many security features, but that is perpendicular to your question.
I'd prefer publishing the WSDL. If you don't want to do that, or if there is a policy in place that says that you can't do that, then send the WSDL to the client team so they can use it as they wish.
Precompiling the proxy will only enforce your coding conventions on the client team, and they may not appreciate that - for example, I often prefer my proxies to be generated with the /i switch that makes the generated classes internal. I also like to be able to specify the .NET namespaces so that they fit the rest of my code. That would not be possible if I got a precompiled assembly (I would be able to use it anyway, but it would just annoy me).
If you don't want to actually publish the WSDL and make it available online for calling clients, then I would prefer the "send me the WSDL and XSD" approach.
That way, you still give the client calling you the ability and flexibility of creating the proxy the way they see fit.
I would only consider using a pre-compiled proxy in an assembly if the calling party was unable or unwilling to create the proxy themselves, and only if they asked me to supply that code in assembly form.
Marc
In order of preference I would be inclined to:
Have the service expose the WSDL (with security enabled)
Send a WSDL file to the service consumer
I was going to list option 3 as sending a proxy DLL but on second thought I wouldn't even list it as an option. It seems to me that shipping your client a proxy DLL opens up a big can of worms that I would not want to deal with.
The main problem is that you end up having to support executable code that is deployed at the client site. The proxy code could be generated by svcutil but if there is some sort of problem invoking the service I can just see the client calling you for support and telling you that your proxy is not working. Now, their claim is probably not correct but it's hard for you to prove it since you don't know what they are doing on their side. e.g.
Maybe they didn't install the proxy DLL?
Maybe there is some permission problem?
Maybe they don't know what they are doing (yeah, I know that never happens. :) ).
Maybe a .NET upgrade on their side affected your proxy?
You might even run into some versioning headaches when sending them new proxies.
If your customer is not that savvy instead of trying to help them by creating proxy DLL perhaps putting some time and effort into assisting them in getting the correct configuration and usage of your service would be a better approach?
In my office building we have laptops on multiple floors all running a WCF Service. When WCF services communicate with each other, will a message for an out-of-range device automatically reach it by multi-hopping? Does WCF/the WLAN device driver handle this? Or do I have to detect if a device is not contactable/out-of-range and implement hopping in my own service?
As long as you have a connection from your WCF client to the service - yes, all avenues will be used. You shouldn't have to concern yourself with things like what network path your messages take - the network just has to be present and stable for the duration of a call ;-)
There's nothing in WCF to deal with this, really - this should be handled way lower in the network stack, by the driver or the OS.
Short answer
With WCF can do either or both of these:
Rely on an underlying protocol like IP to handle roaming
Use custom channel code that handles retries, roaming, etc the way you want it
No special mechanism for enhancing roaming is provided in the WCF classes Microsoft provides, but the framework itself is easily capable of supporting this seamlessly if you write or find a channel implementation to do this.
Full answer
WCF is not an on-the-wire protocol. It is a framework that allows you to communicate using a wide variety of protocols and network stacks. This allows you to use the same client and server code whether you are using HTTPS, raw TCP, named pipes, or any other protocol.
WCF ships with many channels in the box, and you can add your own. For example if you want to communicate over BlueTooth or IRDA, just create a new channel that talks these protocols and you can use your WCF services over it. These channels can also be found online or purchased from vendors.
Most networking today is done using the IP protocol, and if you are using WCF to communicate between desktop machines you will probably be using some protocol(s) on top of IP, for example TCP or HTTP. In this case, IP's normal routing rules will be used, so if the two machines can exchane IP packets you can communicate using WCF.
So if your WiFi access points allow seamless roaming you will be able to tap into that functionality using WCF.
If your WiFi routing doesn't have seamless roaming, you will have to do some extra work if you want to maintain a connection during roaming. Specifically you will need to create a channel that will respond to a closed connetion by re-resolving the server nane and retrying the request. Of course you will have to use DNS or another protocol so the server can update its registration as its IP address changes.
WCF is flexible enough to allow you to create such a channel and use it without your application code ever realizing it. But nothing like this comes in the box: You would have to build it, or download or purchase it.
it has nothing to do with WCF....
if there is a connection between the computers, on the IP, then the message will get through...