My apologies in advance if my question seems a little unprofessional... I am not much of a developer after all.
As part of my university project I need to develop a program that will listen on the network and tell whether the traffic is encrypted or not? What's important is only to know if the traffic coming to a network end is encrypted and it's not really important to know the type and the algorithm of the encryption.
I really have no clue where to begin. I'd appreciate it if anyone could give me some clues on what to look for.
Thanks in advance...
Although the answer of GregS is of course correct, the best way to distinquish encrypted text is to look at the protocol used by the application. For instance, if browsers encrypt anything, it's probably done by using SSL. Remote terminals use SSH.
Although the cipher text is mostly looking as random bytes, you can probably distinquish the encryption protocols. If this is enough depends on your use case. As a first step, many protocols use a specific server port by default; this can be used as a heuristic so you can check the most common protocols for that port first.
Related
First, I need to know this in kernel space, so please take this into consideration.
No, I cannot use the IP address of the other device and ARP it(too long to explain why here) but I simply cannot use ARP, ARP won't work for the project I am working on.
Is there a function/utility I can use to know the MAC address of the other end in a connection attached to a given net_device I already have regardless of the IPs?
Thanks in advance, and if my question is not clear or makes no sense, leave a comment and I'll make sure to edit the question to explain/fill in the gaps
The standard protocol for "I need to speak to my neighbor" kind of problems is LLDP. At the moment, this is usually implemented via OpenLLDP (user-space) on Linux systems. However, there appears to be some kernel-space patches on the way that might help you:
Supposing you have the possibility to enable LLDP on the other end, you should be able to use it to discover that device.
There is an interesting problem at hand. I have a role-playing MMOG running through a client application (not a browser) which sends the actions of my player to a server which keeps all the players in sync by sending packets back.
Now, the game uses a top layer protocol over TCP/IP to send the data. However, wireshark does not know what protocol is being used and shows everything beyond the TCP header as a dump.
Further, this dump does not have any plain text strings. Although the game has a chat feature, the chat string being sent is not seen in this dump as plain text anywhere.
My task is to reverse engineer the protocol a little to find some very basic stuff about the data contained in the packets.
Does anybody know why is the chat string not visible as plain text and whether it is likely that a standard top level protocol is being used?
Also, are there any tools which can help to get the data from the dump?
If it's encrypted you do have a chance (in fact, you have a 100% chance if you handle it right): the key must reside somewhere on your computer. Just pop open your favorite debugger, watch for a bit (err, a hundred bytes or so I'd hope) of data to come in from a socket, set a watchpoint on that data, and look at the stack traces of things that access it. If you're really lucky, you might even see it get decrypted in place. If not, you'll probably pick up on the fact that they're using a standard encryption algorithm (they'd be fools not to from a theoretical security standpoint) either by looking at stack traces (if you're lucky) or by using one of the IV / S-box profilers out there (avoid the academic ones, most of them don't work without a lot of trouble). Many encryption algorithms use blocks of "standard data" that can be detected (these are the IVs / S-boxes), these are what you look for in the absence of other information. Whatever you find, google it, and try to override their encryption library to dump the data that's being encrypted/decrypted. From these dumps, it should be relatively easy to see what's going on.
REing an encrypted session can be a lot of fun, but it requires skill with your debugger and lots of reading. It can be frustrating but you won't be sorry if you spend the time to learn how to do it :)
Best guess: encryption, or compression.
Even telnet supports compression over the wire, even though the whole protocol is entirely text based (well, very nearly).
You could try running the data stream through some common compression utilities, but I doubt that'd do much for you, since in all likelihood they don't transmit compression headers, there's simply some predefined values enforced.
If it's infact encryption, then you're pretty much screwed (without much, much more effort that I'm not even going to start to get into).
It's most likely either compressed or encrypted.
If it's encrypted you won't have a chance.
If it's compressed you'll have to somehow figure out which parts of the data are compressed, where the compressed parts start and what the compression algorithm is. If your lucky there will be standard headers that you can identify, although they are probably stripped out to save space.
None of this is simple. Reverse engineering is hard. There aren't any standard tools to help you, you'll just have to investigate and try things until you figure it out. My advice would be to ask the developers for a protocol spec and see if they are willing to help support what you are trying to do.
I am designing an application protocol, and i am wondering if i still need include checksum in the protocol since tcp/ip already has checksum.
what's your opinion?
The BitTorrent protocol has a heavy amount of additional error correction and detection layered on top of TCP, so clearly the protocol designers saw the need for it.
The TCP checksum is quite weak, so you probably want an application level one if you are at all worried about reliability.
In particular the TCP checksum is not a secure hash, and there is no signature, so if you're worried about malicious changes then you need to add the security yourself.
To add to the other answers, you should probably look into Message Authentication Codes. MACs are a more robust way to detect errors than a simple TCP checksum.
If you want something robust, take a look at [HMAC][2]. HMAC provides both error detection and authentication (via shared keys).
If you want something quick and dirty, why not use sha1 hashes?
im looking for a way to detect, and capture data being sent TO and FROM a specific program, ive attempted to use something like wireshark but it all seems to be a bunch of nonsense to me, so i was wondering if anybody could help me get the data, translate it into text, to allow for editing, and then to resend the new edited information on its way.
Look for Capture TCP stream feature/menu item in Wireshark.
Edit: It's actually Follow TCP Stream.
Wireshark is definitely the way to go. It'll capture the data going to a specific port (which you can probably correlate to a the program fairly easily). I hope this isn't happening over SSL though (wireshark isn't going to help you much if it is).
But if you have to reverse engineer the server's communication protocol, capturing the network packets is the least of your problems. Reverse engineering is difficult and can be fairly error prone as it's often based on guess work. My suggestion is to do this as a last resort: if the server is intended to communicate with the outside world, there's probably some protocol documentation floating around somewhere that will be much more reliable than a wireshark trace.
I have just started writing socket programs. Came to know that single UDP packet has source port destination port and some MAC address representing router..etc. I wonder why anybody cannot create custom packets with a fake information in and send it over internet. I would like to know how safe are our PCs. What should be done to secure it ?
There are a couple of different aspects to the answer.
One is that the web relies on TCP, not UDP. Which means that it is connection-oriented. Your package will be rejected, unless it appears to be part of an existing connection (which means, among other things, that it has to have the right source IP and port as well. And it has to have the right sequence number to fit into the receive window). This can still be faked without too much trouble, of course. But it does require you to know a bit about the packets being sent on the original connection.
Another part is that whenever we need to be sure that the sender of a packet is who they claim to be, we use encryption. :)
Most packets don't really need this. It's not a huge deal if someone sends a request to Google which appears to come from my IP. But when making credit card transactions, it becomes a bit more important.
Most of the TCP/IP stack "leaks trust", as I once put it -- and there isn't much that you, as a software developer (assuming you're looking for a programming solution, otherwise, stackoverflow's the wrong forum, go to serverfault or superuser;-) can do about it -- beyond choosing and carefully implemented protocols that are reasonable in terms of security expectation.
HTTPS (with strong checks of certificates, etc) is one reasonably strong approach; for stronger security, look into SSH and VPN-based approaches. Of course, nobody should assume privacy or strong authentication is in place unless they've taken specific steps towards it (if they HAVE taken such steps, they may be still subject to successful attacks, which is why using existing, more or less "proven" solutions such as HTTPS, SSH, VPNs, is advisable;-).
Yes, anyone can create packets with whatever data they want and send them out over the internet. Especially with UDP, you can pretend to be anyone you want (unless your ISP does egress filtering). Source addresses for UDP cannot be trusted. Source addresses for TCP can to an extent (you know the data has to be coming from the IP address in question, or someone along the route).
Welcome to the internet :)
Edit: just to clarify egress filtering is something the sending ISP would have to do. As a reciever, there's not really anything you can do to verify the address on a UDP packet without communicating back to the sender. The only reason you can at least partially trust an incoming TCP connection is that TCP requires certain control data flow back to the sender (and hence needs a valid IP address/port to set the connection up and maintain it).
Well, many many people create invalid packets and send them over Internet; for instance, read Ping of death.
A [completly] secure computer is a computer turned off. To make your running PC more secure from this thread kind, you should rely on firewall softwares/hardwares, which can detect that malformed packets.
Custom packets with fake information can easily be created. Therefore you have to make sure you're not vulnerable to them.