I'm building an application that needs to modify DHCPv6 packets dynamically before they hit the wire. I'm doing some heavily proprietary work with DHCPv6 vendor options, and I need the ability to examine and modify those options in-memory before they are transmitted.
I've built a proof-of-concept layered service provider on top of Winsock by modifying the Microsoft sample code. It intercepts outgoing HTTP packets, changes the referrer-agent to something funny, and sends the packet on its way. Verified in Wireshark, works great.
It was also straightforward to change my installer code so that my LSP gets chained in on top of UDP/IPv6 rather than TCP/IPv4, and now, with a debugger attached, I can see myself getting callbacks with stacks leading into the DHCP server. However, I can no longer see the buffers in memory.
WSPSend and WSPConnect don't get called, since we're on a connectionless protocol--that makes sense. I do get a consistent callback in WSPSendTo but the lpBuffers member, which in my HTTP prototype contained the buffer representing the outgoing packet, is NULL.
Am I going about this completely the wrong way, or is there another Winsock operation I need to override? I'd be happy to go in another direction if an LSP is the wrong way to go, but outside libraries are a very tough sell for this application--otherwise, I'd be looking at Winpcap.
EDIT: Wow, this was a long time ago. For those coming behind me, this ultimately worked fine. I'm embarrassed to say that the issue was that I was compiling with optimizations that prevented me from seeing the correct data in the debugger. When I stopped being lazy and dumped the bytes to a file, I saw that all was well.
LSP does can only intercept Winsock traffic, DHCP is at a lower layer, you need a different technology to do this, for example: NDIS, TDI (Will not work on Win8) or WFP (Will not work on XP)
Related
I have written a small program that returns a custom response to receiving SYN packets to some ports in Linux. This required me to make a minor edit to the Linux Kernel and recompile. I have tested this and i have the functionality i require in Linux.
I wish to have the same functionality in Windows XP/7. To achieve this i believe i would need to edit a driver/file/registry setting that controls tcpip functions. The goal would be to disable the default action of sending RST packets when a SYN is received on a closed port?
The research i have done so far has pointed me towards something like tcpip.sys or the tcpip settings in registry?
I am realistic that this may not be possible due to the drivers being unsigned if i modify them, but hopefully someone can put my mind at ease about the plausibility of this being possible?
I am struggling with my code in devkitpro trying to get this program to connect to the Internet. It says it connects, it gets an IP address.
However, how do I read from the Internet and verify that it is even writing my data to the socket? This is a very tough devkit due to the lack of or quality of the documentation. I need some help on this.
EDIT: I'll post the code when asked for it. It is long and needs cleaning up.
The socket code in devkitPPC/libogc closely mirrors the BSD sockets interface. The main differences are that functions are prefixed with net_ (net_socket, net_connect, net_send, etc), net_select() is not implemented, and in most cases the error codes are returned from the functions themselves, not with errno.
If you've created a socket and connected it to a remote server, you've probably figured this out already!
However, how do I read from the Internet and verify that it is even
writing my data to the socket?
The same way you would on on a PC! Open a connection with net_socket() and net_connect(), read and write data with net_send() and net_revc(), call net_close() when done.
Check return values from these functions to determine whether the operation succeeded or failed. Most functions return < 0 when an error has occurred. You will also have to initialize the Wii network hardware and obtain an IP address first.
This is a very tough devkit due to the lack of or quality of the
documentation.
Very true. Some system headers are documented using Doxygen, unfortunately network.h isn't. However, as the interface is similar to BSD sockets, most socket tutorials or examples can be applied.
I'll post the code when asked for it. It is long and needs cleaning
up.
Post some code and I'll do my best to offer more help.
My main goal is to create an advanced program for manipulating the packets that route within my network via the router. Let my program have total control over the router. Set the download/upload speeds to my inputs, apply the effect to certain devices within in my network. Block upload or download traffic. Set second delay for either the upload or download speed. Specify % of loss packets, and the list goes on.
The problem is that I don't know where to start. I know most languages at the very most basic level. I'd like to create this program in either C, C++ or C# but I don't know yet. What else do I need to know before creating this program? Winsock or something? Winpcap APIs?
This goal is my motivation to learn programming to the extreme, and I'm really looking forward to it.
Thanks in advance!
Hmmm I guess you would want to look at pcap(?):
pcap
Check out:
http://beej.us/guide/bgnet/html/multi/index.html
'Beej's Guide to Network Programming
Using Internet Sockets'
All you could possibly need to know about programming sockets for capture and manipulation.
If I were you I'd write it in C, I'm writing a similar project at the moment in C++ and it's hell but too late to stop and start again.
Hope that helps.
Bear in mind that you either need a router that you can re-program or you need to use your PC as a router to do this.
Either way you want to look into how IPTABLES are implemented.
I've never seen Desktop Windows used as a router only Windows Server, though it may still be possible. libpcap is for packet capture, but not interception as I understand it. Programs like Wireshark use it to monitor copies of packets, but not to modify them. If you want to attempt this, my impression has been that there is a lot more documentation and tools for doing something like this with NetFilter/IPTables on Linux. You can even install something like OpenWRT on a compatible router and get a small, cheap Linux router, though having Desktop Linux will probably help for development. The NetFilter QUEUE library can be used with some IPTables firewall rules to redirects specific (or all) packets to a regular user program. That program can then read the packet and modify it or even request it to be dropped.
http://www.netfilter.org/projects/libnetfilter_queue/
If you want to manipulate network traffic on a Windows machine (as you mentioned), you will need some extra software. This operating system wont give you the full control over itself, which is fine for some reasons.
I think what you want to do, should be done with either winpcap or win10pcap if you are using Win10. These packages contains a windows driver and the libpcap user space library.
More than once I picked myself wanting to have an easy way to edit packets on-the-fly in my LAN, so I thought it was time for me to make some "machinery" to do the job. I think WFP would do exactly what I needed.
Not only I wanted to filter and edit packets off the computer my program would be running, but I would also like to ARP poison a machine in my LAN and edit the packets routed through the other one (I don't know wheter I could do this using WFP; that's another part of my question. If anyone knows, please tell me).
The problem is I'm not being able to download Visual C++, and I need it to use the WFP (it's part of the Windows SDK, which is not fully available for MinGW; porting the headers myself is generally a headache). Also I simply would like to know how to do that in Linux.
Anyone?
(Complementary question at ServerFault.com: https://serverfault.com/questions/74915/best-way-to-live-edit-packets-from-another-computer)
The most common way to capture and store packets in linux is through libpcap. You can use standard sockets to send the packets or generic libraries (boost::asio).
You can accomplish the same using wireshark. I believe wireshark will allow replay and/or injection.
As far as arp poisoning, you will probably have to do that directly with arp packets yourself.
Here's my question.
Right now I have a Linux server application (written using C++ - gcc) that communicates with a Windows C++ client application (Visual Studio 9, Qt 4.5.)
What is the very easiest way to add SSL support to both sides in order to secure the communication, without completely gutting the existing protocol?
It's a VOIP application that uses a combination of UDP and TCP to initially set up the connection and do port tunneling stuff, and then uses UDP for the streaming data.
I've had lots of problems in the past with creating the security certificates from scratch that were necessary to get this stuff working.
Existing working example code would be ideal.
Thank you!
SSL is very complex, so you're going to want to use a library.
There are several options, such as Keyczar, Botan, cryptlib, etc. Each and every one of those libraries (or the libraries suggested by others, such as Boost.Asio or OpenSSL) will have sample code for this.
Answering your second question (how to integrate a library into existing code without causing too much pain): it's going to depend on your current code. If you already have simple functions that call the Winsock or socket methods to send/receive ints, strings, etc. then you just need to rewrite the guts of those functions. And, of course, change the code that sets up the socket to begin with.
On the other hand, if you're calling the Winsock/socket functions directly then you'll probably want to write functions that have similar semantics but send the data encrypted, and replace your Winsock calls with those functions.
However, you may want to consider switching to something like Google Protocol Buffers or Apache Thrift (a.k.a. Facebook Thrift). Google's Protocol Buffers documentation says, "Prior to protocol buffers, there was a format for requests and responses that used hand marshalling/unmarshalling of requests and responses, and that supported a number of versions of the protocol. This resulted in some very ugly code. ..."
You're currently in the hand marshalling/unmarshalling phase. It can work, and in fact a project I work on does use this method. But it is a lot nicer to leave that to a library; especially a library that has already given some thought to updating the software in the future.
If you go this route you'll set up your network connections with an SSL library, and then you'll push your Thrift/Protocol Buffer data over those connections. That's it. It does involve extensive refactoring, but you'll end up with less code to maintain. When we introduced Protocol Buffers into the codebase of that project I mentioned, we were able to get rid of about 300 lines of marshalling/demarshalling code.
I recommend to use GnuTLS on both the client and the server side, only for the TCP connection. Forget about the UDP data for now. The GnuTLS documentation has example code for writing both clients and servers. Please understand that at least the server side (typically the TCP responder) needs to have a certificate; the client side can work with anonymous identification (although there is even an example without server certificate, using only DH key exchange - which would allow man-in-the-middle attacks).
In general, it is likely that you will have to understand the principles of SSL, no matter what library you use. Library alternatives are OpenSSL (both Unix and Windows), and SChannel (only Windows).
Have you tried the SSL support in Boost.Asio or ACE? Both use OpenSSL under-the-hood, and provide similar abstractions for TCP, UDP and SSL. Sample code is available in both the Boost.Asio and ACE distributions.
One thing you may need to keep in mind is that SSL is record-oriented instead of the stream-oriented (both TCP and UDP). This may affect how you multiplex events since you must, for example, read the full SSL record before you can call a read operation complete.
To help handle this with no changes to the application yo may want to look at the stunnel project (http://www.stunnel.org/). I don't think that it will handle the UDP for you though.
The yaSSL and CyaSSL embedded SSL/TLS libraries have worked well for me in the past. Being targeted at embedded systems, they are optimized for both speed and size. yaSSL is written in C++ and CyaSSL is written in C. In comparison, CyaSSL can be up to 20 times smaller than OpenSSL.
Both support the most current industry standards (up to TLS 1.2), offer some cool features such as stream ciphers, and are dual licensed under the GPLv2 and a commercial license (if you need commercial support).
They have an SSL tutorial which touches on adding CyaSSL into your pre-existing code as well: http://www.yassl.com/yaSSL/Docs-cyassl-manual-11-ssl-tutorial.html
Product Page: http://yassl.com/yaSSL/Products.html
Regards,
Chris