I'm writing an network related application and I want to protect it from reverse engineering by shutting it down, if packet sniffer is detected. How can I detect if packet sniffer is running? I could check the running apps and check their names against pre-defined strings (wireshark, httpanalyzer, etc..), but that doesn't seem to be the best way to do it. Is there a way to determinate if application is sniffing packets? Thanks
There is fundamentally no way to do this in general. Most networks in use today are intended to send the packets across the network in a manner that permits (or even requires) all devices on the cable to see the packets.
You have to get over the concept that your work is so valuable that you need to protect it in this way (or by using copy protection, obfuscation, etc). Protect your application by producing a great application that everyone will want to actually pay for.
You know you can run the sniffer on the router using openwrt and there is no way you could detect that.Just encrypt the stream.
Related
I wonder if its possible to check if a WOL-request has been
received during the computer is already turned on. (pInvoke, c#?)
If the computer receives a magic paket and boots, Windows writes an corresponding event-log entry to the System-Log.
The way i'm looking for is not to listen to my UDP-Traffic by my own - if its possible i want to know how to receive a kind of system event (IRQ?) or something.. And thats all when receiving PC is already turned on.
I agree with Duston that WOL is a Layer 2 combined with hardware thing. On a normal working PC, there is little chance that the NIC hardware will pass this on to the drivers, as it is exactly the task of this hardware to only disturb your CPU if really needed.
You best chance to see a magic packet on a working PC would be : install and run sniffer (packet analyzer) software. That will force a supportive NIC into a special mode that transfers every packet to the CPU. If you can now see the magic packet in the output, next step would be to configure the sniffer to alert you in case it sees a magic packet. Done. All this will be quite CPU-intensive.
You could write software that performs all this, but that would essentially be rewriting the complete sniffer with fixed query instead of a configurable one.
We are looking to design a security application that does the following on laptops:
If the ethernet adapter is used (cable plugged in) disable/block all other network connections (wireless WIFI, mobile broadband (PPP), virtual VPN adapters etc)
When ethernet adapter is not being used again, all connections allowed.
Does anyone have any good suggestion on how to accomplish this?
We have looked in the WMI a lot but there are no good ways of doing this. Only disabling the network connection is not secure enough because most mobile broadband applications try to re-establish the connection. This should be an application that works on all laptop vendors without any user interaction (such as choosing interfaces etc..).
So any suggestions on how to accomplish this would be much appreciated.
The simplest method for doing this is by disabling the adapter. You say this won't work for you, but I suspect it will. You can detect if something tries to re-enable it and act appropriately.
If that isn't going to work for you, then the next easiest thing to do is to remove the device itself. I believe you will need to used some unmanaged calls to get this done. There is some sample code on codeproject.com that will point you in the right direction.
Keep in mind, if the user runs a check for devices, it will show up again. You can monitor for DBT_DEVICEARRIVAL to detect when this happens, and again act appropriately.
You might also try simply disabling the device. Usually though I have seen that when you disable a network connection, this is exactly what it does. It might depend on the card and OS. I haven't experimented with it.
I suggest you reconsider simply disabling the network interface rather than going to the device level. It is a much cleaner way of doing this, and you can always detect if the interface comes back up. Anything else you do is going to be a bit hackish.
The only other method I can think of would be to block traffic using the Windows Firewall API. Just keep in mind that not all network traffic is over IP.
Well, this might not be the optimal solution but... You could use the route command to disable the interfaces ability to reach any network. It will probably require a lot of tweaking and constant monitoring of the routing table, but would effectively prevent the interfaces ability to communicate with any other device.
There are different ways of doing this. As stated by others in this question it needs to be done on a lower level than what the WMI allows. There are some C++ examples around that addresses this issue. Check out the library NETCONLib by Microsoft.
I'm thinking like the methods games like Counter Sstrike, WoW etc uses. In CS you often have just like 50 ping, is there any way to send information to an online MySQL database at that speed?
Currently I'm using an online PHP script which my program requests, but this is really slow, because the program first has to send headers and post-information to it, and then retrieve the result as an ordinary webpage.
There really have to be any easier, faster way of doing this? I've heard about TCP/IP, is this what I should use here? Is it possible for it to connect to the database in a faster way than indirectly via the PHP script?
TCP/IP is made up of three protocols:
TCP
UDP
ICMP
ICMP is what you are using when you ping another computer on a network.
Games, like CounterStrike, don't care about what you previously did. So there's no requirement for completeness, to be able to reconstruct what you did (which is why competitors have to tape what they are doing). This is what UDP is used for - there's no guarantee that data is delivered or received. Which is why lag can be such a problem - you're already dead, you just didn't know it.
TCP guarantees that data is sent and received. Slower than UDP.
There are numerous things to be aware of to have a fast connection - less hops, etc.
Client-to-server for latency-critical stuff? Use non-blocking UDP.
For reliable stuff that can be a little slower, if you use TCP make sure you do so in a non-blocking fashion (select(), non-blocking send, etc.).
The big reason to use UDP is if you have time-sensitive data - if the position of a critter gets dropped, you're better off ignoring it and sending the next position packet rather than re-sending the last one.
And I don't think any high-performance game has each and every call resolve to a call to the database. It's more common to (if a database is even used) persist data occasionally, or at important events.
You're not going to implement Counterstrike or anything similar on top of http.
Most games like the ones you cite use UDP for this (one of the TCP/IP suite of protocols.) UDP is chosen over TCP for this application since it's lighter weight allowing for better performance and TCP's reliability features aren't necessary.
Keep in mind though, those games have standalone clients and servers usually written in C or C++. If your application is browser-based and you're trying to do this over HTTP then use a long-lived connection and strip back the headers as much as possible, including cookies. The Tornado framework may be of interest to you there. You may also want to look into HTML5 WebSockets however widespread support is still a fair way off.
If you are targeting a browser-based plugin like Flash, Java, SilverLight then you may be able to use UDP but I don't know enough about those platforms to confirm.
Edit:
Also worth mentioning: once your networking code and protocol is sufficiently optimized there are still things you can do to improve the experience for players with high pings.
I am working on an application that needs to control another device.
This control should be using Wi-Fi.
How can this be done in C#?
Important to know that the other device I want to make it.
I can afford the part of making and design but how to make it connect to PC using Wi-Fi?
I don't know about it.
I just need a key to start searching or some thing similar.
Connecting over Wi-Fi could be as easy as opening a socket on the server, and another on the client, and start streaming data. Of course this if both devices are compatible and has Wi-Fi receivers. Just think of them as two computers connected with a wire, or without a wire they will just behave the same.
The connection protocol will care about doing the magic of converting what you write on the socket, into RF signals received from the other device and converted back to bytes.
But if you are building your own antenna/receiver/protocol ... then things will be much more complicated.
If you have to ask then you're probably going to want a single board computer. Popular choices are:
gumstix
Zii EGG
nwg100 by Atmel
(XBee) --not too sure about these, I haven't used.
You can install a network stack and everything on them.
I'm to trying to develop a program to transfer files using TCP (in a local network) with C#, files should be transfer in encrypted way.
My knowledge about c# is average, and about socket programming just know the basics.
Currently have no idea how to begin.It will be great if you have any suggestion about how to begin, if there is any book, website or any other resources.
You could use WCF with netTcpBinding.
This would encrypt the file during transfer and reduce the development effort, since you do not need to program any low level sockets code.
Unless you want to use it as a learning experience for C#/.NET socket programming, there are a lot of free FTP apis that will do it for you without the pain of having to reinvent the wheel. Indy has been going for almost a decade and the others are fairly stable.
TCP sockets are pretty easy to use. While I don't know the API in c#, it will undoubtedly support a send() method, where you can pass in the bytes of your file, and on the other side it will let you register a callback function that will be called when bytes are received. The TCP protocol guarantees that the data passed in-between will not be corrupted or lost. You will need to encrypt and decrypt the data yourself however.
The easiest way to begin is to code up a 2-client chat program where you send the messages using TCP. If you want to understand more about the TCP protocol and the "network stack" (a set of underlying protocols) then you can start on wikipedia and carry on with a decent book on networks - it is actually a very big topic, but you don't really need to know unless you are making a serious app.
By the way, an easy linux hack is to use netcat (type man nc to get help).