Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


DvDmanDT

Member Since 10 Dec 2004
Offline Last Active Yesterday, 06:09 AM

#5211524 Reliable UDP messages

Posted by DvDmanDT on 18 February 2015 - 02:17 PM

I'm mostly familiar with Lidgren which is pretty much the one true networking library for .NET. It uses multiple "channels" where some channels are unreliable, others are ordered but may have packets dropped, others are reliable and ordered.

 

It will only resend those that are reliable. The unreliable option allows packets to be received out of order with some packets dropped etc. You can mix and match channels as you see fit for your various data types.




#5210883 how to know most hack possiblities and find best way to handle them

Posted by DvDmanDT on 15 February 2015 - 02:46 PM

 

thank you for answering to me. i have read the code before but need information how it works. as i saw the code, there is no code for encrypting. is the encryption process automatic? does it work like rsa?  what does X509Certificate do? is this for being sure that data is from valid client and... ? ill be gratefull for more information about what you know about ssl.

 

 

 

Yes, the actual data encryption is automatic. It uses RSA and (probably) AES internally.

 

SSL does two things. The most obvious thing is that it encrypts data, but it also has mechanisms to verify peers. For example, when you connect to your bank, you want to make sure not only that the communications are encrypted, but you also want to be sure that it really is your bank that you are talking to. Such verification can be performed using an asymmetric encryption algorithm (such as RSA) and a certificate chain. The whole process is a bit to complex for me to write here, but the point is that some authority who everyone trusts can issue a non-fakeable (in theory at least) certificate to someone which can then be verified by others. The certificate contains the public encryption key to be used when communicating with that entity. The most common format of these certificates is X.509.

 

You can create a self-signed certificate with your own keys. This is typically used for testing or when you only need encryption.

 

The reason for using a trusted certificate system is that it prevents man-in-the-middle attacks where a your client unknowingly connects to a hacker who decrypts the data, reads it, re-encrypts it and passes it on to you. That can also happen with a self-signed certificate unless it's shipped with the client.

 

Correctly doing encryption is hard. smile.png You should probably read up on it on wikipedia or similar.

 

EDIT:

Certificates are most commonly used to verify servers, but they can also be used to verify clients. That could be used for white-listing for example. I'm not sure I've ever seen anything that actually uses client certificates however.




#5210857 how to know most hack possiblities and find best way to handle them

Posted by DvDmanDT on 15 February 2015 - 10:24 AM

RSA is super slow and is typically only used for handshaking and symmetric key exchange, then a symmetric algorithm such as AES is used. This is what SSL does. SSL is used by tons of things, secure web, secure FTP, SSH, current mail protocols, and so on. 
 
If you use a TCP connection and can keep it open, the SSL overhead will probably be fine. It's mostly the handshake that's the problem. Unless you are like an MMO, but then you'll probably need reverse proxies and load balancing anyway. SSL is probably going to be the fastest encryption solution you can find. Doing it yourself will either be less secure or slower.
 
Check out the System.Net.Security.SslStream.




#5210776 how to know most hack possiblities and find best way to handle them

Posted by DvDmanDT on 14 February 2015 - 09:22 PM

Encrypting traffic can make it more difficult to sniff/intercept the communication and stealing other peoples account data and it can potentially also prevent varous forms of cheating such as knowing stuff only the server and that particular client should know. It does not prevent a hacker from sending anything he wants from his own computer, but it can prevent him from impersonating another client.

 

So yeah, encryption is awesome and can bring alot of benefits, especially for the non-hacking players, but it does not mean you can trust whatever is received just because it was received over an encrypted channel.




#5210158 What's the point of obfuscating managed code?

Posted by DvDmanDT on 11 February 2015 - 05:36 PM

The problem is that, with the internet, everyone is a "skilled team". I don't have to hack anything, I just need to know how to find someone who did the work already and packaged it into a handly little installer I can double-click.

"Modding" (and cheating) cannot be stopped. Period. The user's machine is always hostile, always running code you cannot trust, even if you wrote it. The best you can do is verify on the server side to prevent cheating, and have a GM team who can verify cheating behavior and apply appropriate bans. (Or better yet - release server executables so people can run and manage their own servers)

I can think of a few ways to easily reverse obfuscation - someone wrote a program that transforms A -> B, I can write one that goes the other way (especially if the transformation is non-lossy). Symbols that "look alike" don't bother a computer after all smile.png

And if you're a single-player game? Psh. Let the user go nuts. They'll love you for it. And if you release the editor next time you'll have one of the longest sales tails in gaming without spending a cent. (Of course, your game has to be good - but we're operating on that assumption already)

 

Obfuscation is probably always lossy. Some tools generate IL that cannot be represented by C#/VB.NET. It can greatly delay cheating/hacking/modding/whatever, especially if you keep releasing new stuff.

It increases the effort while reducing the amount of people capable. If you released the source code, I could probably create some form of cheat in an hour or two. If you only release the non-obfuscated binaries, it would probably take me 1.5-2 times longer. If you were to release only obfuscated binaries, it would take me maybe 10-20 times longer with a huge chance that I simply won't bother. And yes, it can actually make a difference.

Most of us aren't triple A developers with millions of players and tons of attention, and chances are we won't attract the attention of "the very best".

Also, modding can create some serious problems for developers. It can create tons of support issues (yes, even when it's their own fault and you tell them so). When you update your game, chances are mods break and that you'll get the blame, or that people stick with the old and outdated version with all its bugs and issues. It can also create competition with your own game, making it more difficult to release DLCs/expansions or sequels.




#5210040 What's the point of obfuscating managed code?

Posted by DvDmanDT on 11 February 2015 - 09:04 AM

There are different obfuscation solutions. The one by preemptive (Dotfuscator) renames everything into a, A, b, .. and uses overloading heavily to make code harder to read. The one by RedGate (the Reflector guys) seems to rename everything into weird symbols that are hard to tell apart. They also shift the logic a bit. While I've only used Dotfuscator (not voluntarity!) I can tell you that you can easily reverse the process if you get a stack trace or whatever.

As to effectiveness. Non-obfuscated IL is pretty much the same thing as shipping the full source code with stripped comments. Obfuscation makes it a LOT harder to read and understand. It also has the effect that every build can become vastly different, potentially forcing crackers/whatever to redo their full work every build. If you disassemble a regular C++ .exe from two different builds, chances are you can easily detect the changes as well as reapply the same hacks to the new build.

Not everyone wants their game to be modded. There can be multiple reasons for this, but multiplayer cheating is one of them. While obfuscation will not prevent the more skilled teams from hacking/reverse engineering your product, it may prevent or at least delay the script kiddies from doing so. There are much better ways to make a game moddable, such as by providing an api with hooks etc.

Also, sometimes there are legal requirements to obfuscate your product due to included libraries or whatever. The worst part about obfuscation is that it completely messes with anything dealing with serialization and reflection.


#5204529 how to know most hack possiblities and find best way to handle them

Posted by DvDmanDT on 15 January 2015 - 12:38 PM

But it's the C-code that has the issue, not the PHP-code. You cannot _create_ these kinds of issues with PHP, but can certainly be affected by them. (With that said, PHP in particular is, in my own humble opinion, not really something you should ever use if you have an option. After following the development mailing list for years, I can honestly say it's the worst project I have ever seen from just about every perspective.)

 

If a common/basic library has an issue, then it typically affect you no matter what language you use to access it. Interpretation and/or code generation bugs can also affect just about anything you can think of, so there's no way out of that either. I think you should choose a platform with a good track record and a sane and security-aware design as opposed to something with a horrible track record and no security awareness what-so-ever. You won't be "safe", but you'll be better off.

 

I think we can all agree that "forget about even trying to write safe code, someone else has probably made a misstake anyway" is a very poor philosophy.




#5204473 how to know most hack possiblities and find best way to handle them

Posted by DvDmanDT on 15 January 2015 - 07:48 AM

It is impossible to cause a classic buffer overflow directly in an interpreted language because array accesses are bounds checked. The following in C would probably crash the program:
 
char n[10];
n[-MAXINT] = 83;
 
In a scripting language the illegal offset would be filtered out, usually just causing a warning and being discarded.

 
Or, in a more sane non-PHP language/platform, you might end up with a catchable and easy to handle exception or at least a reliable crash/shutdown.
 

A buffer overflow is when you have a buffer on your stack (like char mytext[256]; in C) and then you read input into it or copy into it without making sure the size copied is less than the buffer size.

 

Which it typically done by passing a pointer to (the first element in) that buffer to your input or copy function. You are (usually) not passing an array or a buffer, you are passing a pointer. It's up to the programmers to check boundaries and whatever in every single place in every single function where you are using pointers/buffers like this. At some point, someone inevitably misses one such check at one such code location and bam, you have a potentially exploitable bug. In some cases, you have checks but just accidentally write <= instead of < and bam, bug/hole/crash/whatever. The worst part is that compilers and even advanced static analysis tools have near zero chance of catching these mistakes.

 

In (insert just about anything other than C/C++ here) you'll work with language supported arrays/buffers/ranges with defined boundaries where the compiler/platform/tool chain have a chance of verifying what you are doing and at the very least detect errors at runtime. Some languages are designed in such a way that you cannot even write code that attempts to move outside of the bounds. Due to design decisions of C, even if the compiler can detect that you are writing outside of the bounds, it can't really do anything about it cause it can't be sure it wasn't your intention to do so. From a performance perspective, this can often be a good thing, but from a security/safety/stability perspective, it's a nightmare.

 

You complete solution will be a stack with hardware, os/drivers, a potential application platform (ie JRE/.NET) and your own application on top. Hardware and OS issues are more or less beyond your control, you'll have to react and fix when issues arise, and then rely on firewalls, antimalware, redundancy etc to reduce the effects of issues.

 

The platform is somewhat optional. Not using one means writing your full application from scratch, typically using C/C++, with giant probabilities of issues as well as potentially low productivity. An advantage is that the issues are less likely to be found than issues in a platform, especially if it's a non-distributed server-side only application. Using an application platform typically means introducing a layer that is beyond your control where you need to react and fix issues as they appear (ie by software updates), but it also means that your own application will have less issues since the platforms and associated languages prevents most of them. It's my strong belief that using a sane platform will enhance your overall security.

 

There is no such thing as being completely secure, but you can affect/improve security by making decisions about your platforms etc. It's not the only thing you should be doing, but it's one thing you should be doing.




#5204184 how to know most hack possiblities and find best way to handle them

Posted by DvDmanDT on 14 January 2015 - 06:52 AM

Well, I partially agree on the platform thing. It's a bit of a chicken and egg issue.

 

Even if your code is 100% correct and flawless, you may still suffer from hardware issues. Does that mean you shouldn't care at all about writing safe/secure software and just fix issues when they are seen?




#5204076 how to know most hack possiblities and find best way to handle them

Posted by DvDmanDT on 13 January 2015 - 05:52 PM

I think you misunderstood the bug. The bug is in the Java implementation. The bug allows a malicious user to inject "legitimate" data into an application written in Java, and by doing so, start executing arbitrary machine instructions, thus being able to "own" the machine.
Your software is written in Java, so your software doesn't have pointer/buffer problems -- but Java itself does, so the interface you expose to the world DOES have those problems.


No, you misunderstood me. smile.png Java is a complex piece of software written in C/C++, where it is ridiculously easy to make these kinds of mistakes. Had the software (the platform itself) been written in something less error-prone (I don't know, Ada maybe?) then perhaps it wouldn't have been possible to make said mistake. I'd argue that C and C++ are horrible languages for security/stability critical software such as platforms, it's just that they are (sadly) pretty much the only realistic choices.

It's always possible (highly likely) that the next lower level will have exploitable issues, even down in the hardware, but that's no excuse to not do everything in your power to make sure that your own code does the intended and doesn't introduce additional bugs/holes. Some languages and platforms are designed for power, others for performance, some for easy development and others for security/stability. I'd argue that choosing a platform that was designed with security/stability in mind is your best bet, even if there are no guarantees.

The "depends on your view" part was about looking at the software itself or the complete solution. I think both are very important view points. From my view, if I use Java and Java has a bug, it's not a bug in my software but a problem that affects my solution.

Fun trivia: In the embedded industry, there are lots of different safety certifications, some of which require that you can prove that every single instruction in your software has been executed with the desired result. That's at the bottom of the certification ladder. You still have to account for potential hardware issues and/or timing issues. The higher levels will barely allow you to have conditionals.


#5203924 How unreliable is UDP?

Posted by DvDmanDT on 13 January 2015 - 08:24 AM

Maybe the reason is that without the restricted address space of IPv4, there is no credible excuse for handing out dynamic addresses which change every few days (which is of course done on purpose so it's much harder for you to run a public server "for free" from home).

 

Over here almost all consumers have dynamic IPv4 addresses, but they almost never change, at least not as long as you keep renewing it and/or use your connection. I think it's partially for tracking reasons. Then again, our ISPs openly allow private servers and some of them even give out free dynamically updated domain names to their customers..




#5203917 how to know most hack possiblities and find best way to handle them

Posted by DvDmanDT on 13 January 2015 - 08:03 AM

I suppose it depends in your view.

 

My view is that if you have no pointers, you cannot accidentally dereference them or point them straight to hell. It means you cannot introduce that kind of bugs. The Java error you linked is a typical C/C++ problem which couldn't have happend in code written in say C#/Java (well, there are always exceptions ofcourse).

 

Platforms like .NET are designed in such a way that many problems cannot happen in the first place, while many others can be caught and handled in safe and secure ways. I wouldn't be the slightest surprised if we saw a production quality derivate of Singularity (OS by Microsoft written in C#) for servers sometime soon for this very reason. It has so much better potential to be secure.

 

Writing safe and secure code indeed doesn't save you from problems in your platforms/OS/hardware though, you still need updates, firewalls, anti malware systems and whatnot, I completely agree on that part, but you should still do what you can on your end, in your code.




#5203876 how to know most hack possiblities and find best way to handle them

Posted by DvDmanDT on 13 January 2015 - 04:40 AM

Another thing to keep in mind is what technology you use, including what language you are creating your game in. For example, higher-level languages are typically free from buffer overflow/underflow issues which are some of the most common and effective ways to "hack" software, either to steal information, bring down servers or in the worst case execute code remotely.

 

In other other hand, high level languages (such as PHP) often make it easy to execute code as strings and/or include additional code which can be very dangerous (though such languages are commonly executed in sandboxed environments reducing the effectiveness somewhat). High-level languages also commonly perform automatic/implicit type casting among it's variables, and/or making it impossible to enforce specific types, making it easier to make misstakes like the SQL injection samples above.




#5203276 How unreliable is UDP?

Posted by DvDmanDT on 10 January 2015 - 08:46 AM

Even ping can vary by a factor 50 in some cases. There are just so many variables. For example, there may be a VPN between two peers, either directly or at some point in between them. Such a VPN could decide to "improve" stability by making sure all packets are transmitted through that tunnel. This means that packets could get resent even though it's over UDP. In extreme cases, you may have multiple routes to your target and the routing system in between tries to load balance or whatever. In that case, one route might take seconds while the other milliseconds.




#5203269 How unreliable is UDP?

Posted by DvDmanDT on 10 January 2015 - 08:22 AM

I had two computers connected through a crossed TP cable (ie not even a switch or router in between) and did some tests. The only other traffic was Windows stuff. When sending small packets with at least one ms sleep in between, 100% of all packets were received and in order. As soon as I dropped that sleep, however, I saw something like 15-20% packet losses (not received at all) and 10-15% of packets received were out of order. Bursts (multiple packets in between sleep calls) resulted in less dropped packets, but there were still a large amount of packets received out of order.

 

Reintroducing the sleep between each packet but also introducing other traffic showed that it was _really_ easy to disrupt the communication and get losses. Heavy load on the computers also had some effect.






PARTNERS