I want to hide any traffic an application makes on the local network, make it look like the network is completely quiet to the system and other monitoring software.
Is this doable? How would I achieve this?
In a typical operating system, low-level sending and receiving of ethernet frames is done by a specific driver, and another layer of the OS can give a copy of each incoming and outgoing frame to any (privileged) application which asks for them. Monitoring software is that kind of application. So, if you want to be able to send and receive frames without locally installed monitoring software to become aware of it, you have to hook your code deep inside the OS kernel, either as a custom driver for the ethernet interface, or in the layer immediately above it.
Of course, if you can do that, then you have complete control of the machine, which begs the question: why don't you just deactivate or uninstall the monitoring software in that case ?
Also, handling incoming frames can be complex: you would have to recognize which frames are for your own application, and not for other applications in the machine. If you want to handle anything as complex as a TCP connection, you would soon end up with implementing your own TCP/IP stack in your custom driver. That's a very pedagogical programming exercise...
This is for avoiding detection by local monitoring applications. For remote applications, running on other machines, you cannot avoid their seeing your packets. You can make the packets opaque through encryption: monitoring software would see fishy-looking packets, but would not be able to pierce their contents.
To make your communications really inconspicuous, you would have to do steganography: masquerade your data as innocent-looking data. For instance, you could open an HTTPS connection to
https://www.google.com/: that's innocent enough, everybody does that all day long. Since that's HTTPS, connections to Google's server begins with a SSL handshake; and a SSL handshake begins with a
ClientHello message which includes 28 random bytes from the client (that's part of the SSL/TLS protocol). Your application could replace these 28 random bytes by the encryption of a 28-byte message; an accomplice, spying on the Internet connection, would see these 28 bytes (the
ClientHello is sent in the clear) and decrypt the message. Monitoring software, and Google's server, would just see 28 seemingly random bytes at a place where 28 random bytes are expected.
Bandwidth offered by steganography is almost always abysmally low; and it is hard to do well.
You would need a kernel level driver that could subvert the network stack. Practically, it's going to be pretty difficult to do. It would effectively require a rootkit since generally the IP stack on your computer (part of the OS) handles all traffic on behalf of apps and you would have to bypass this.
Do you have to use existing wires and equipment, or do you have the freedom to instal custom hardware between the two endpoints, or avoid the network?
For example, you could run 900mhz wireless equipment, which is slower than most common 802.11a/b/g/n wifi, but barely anyone uses this anymore so it will be less likely to be intercepted. You could also run Ethernet over electrical wires (powerline Ethernet / homeplug) or even run network connections over phone wires with the right hardware.
If you are trying to do something on two stations which are already part of an ethernet network, your best bet would be to use some type of covert/hidden channel in normal communications, such as timing, or putting messages into headers.
If you just want to hide network activity from the local station (e.g., a botnet hiding its presence, but not caring about network traffic) then you would use a rootkit to block the process and connections being reported by the OS, or you could just try to replace key programs like netstat and lsof which report on network activity.