Reasons Why Desync Happens (Thoroughly Explained /w Cited Commentary On Fixes & Focuses Info)
"I kind of suspected that -- hence my reluctance to trust encryption -- but I couldn't quite put my finger on how. Thanks for that. When Stephen Colbert was killed by HYDRA's Project Insight in 2014, the comedy world lost a hero. Since his life model decoy isn't up to the task, please do not mistake my performance as political discussion. I'm just doing what Steve would have wanted.
|
|
" Back in my days in the army, i get to learn radio transmission. One interesting stuff i learnt from it, is how to deal with radio communication from being falsely transmitted by enemy is having "Authentication procedure" and "Word encryption". This is much so alike to TCP and encryption in internet world. But the most interesting is how to prevent the enemy know your radio frequency at the 1st place. In comes "Frequencies Hopping". So what am i getting at? My point is, world-internet communications derives from military technologies and applications. If you need ideas, just google or search the wikipedia on current military communication method. Hope this would help. Perm. Retired from this unforgiving land of the Exiles.
Self-impost EXILED. |
|
" who are you sending your information to? the enemy, which i called man-in-the-middle, trying to intercept the information is not the problem we are discussing. you have mentioned two parties - you and the enemy. but why do you need to transmit information in the first place? there's the question of your allies. you secured the communication, encrypting the messages, so the so called "enemy" cannot get them. but you gave the key to decrypting it to your "allies". the question that plays the central role is - how do you know that your allies are not actually spies? forget conventional war and think cold war. a better analogy would be a shop. who is an honest costumer and who is a thief? you must let both in through your door and then monitor their actions. you must let both through the door because you don't even know that one of them is a thief (but you must suspect everybody or you will be robbed blind). you must give anybody, who wants to start communicating with you, the key to the decryption. but the fact that others cannot listen on your private conversations with each one, does not mean that you can let your guard down. as a side note, the radio analogy is also not that good because the internet is more like the post office rather than radio. it all works on addresses and return addresses. letters being routed all over the place, going through various checkpoints. one letter could be on a ship, the next one on a plane (and the later one could arrive before the first one). one big mess of huge mail houses all sorting and routing mail. IP is the mailman. TCP is actually a method to establish continuous exchange over mail. the path that can be chosen is not the correct path to choose. such is the nature of the Dao. Last edited by Dao#3393 on Jun 18, 2013, 9:57:24 AM
| |
" No I mean application layer. " The only ones that know the protocol are the POE server and client. It's not public. If you can't hack the servers, if you can't hack the client, you can't know the protocol. " Why can he find out how everything is done? He can't hack the source code from the binaries if you do things right. Also like I said if the hacker can hack everything in existance it's not even that big of a deal because of what I said earlier (he can't do much to "cheat" that can benefit him). The encryption and stuff talk is about how Scrottie said with my solution hackers would easily control the game and cheat and keep themselves alive whenever they want and stuff. What I'm arguing is that you can prevent that (with all the stuff I said), but the most important thing (that we are not discussing for some reason) is if that solution actually works (if it doesn't then it's kind of pointless to discuss security issues about it lol) ^^Well thats's cryptography and security discussion, kind of irrelevant to this. A public key encryption basically prevents that situation you mentioned from what I know. And if it doesn't? Well surely there is another one or there is another method to prevent specific situations and if there aren't well then I guess we are fucked until a genius mathematician comes up with another one, but that's not in the scope of this argument (finding solutions to desync). If banks, Paypal, etc can keep their stuff secure (password, account balance, etc) then so can GGG. If you worry about "ally spies" and stuff with POE then you have to care about other more important applications as well, which I'd say are much much more important than some single guy in the world being a super hacker and just giving himself 2 seconds more to live in a POE game |
|
" The client is just a bunch of byte instructions on your harddrive. Of course you can't recompile it to the original source but there are programs that make it readable enough. It does not take long at all for people with experience to find the code that parses packets and figure out how they are structured. |
|
" the client is publicly available. more on that below. " first and foremost, the client binaries. what are they? an executable format, and opcodes, which are, the binary form of instructions, which are 1 to 1 match with the assembly language of that architecture. because of that, they are easily translatable into assembly. the assembly alone will provide you with everything you need. but wait, there's also run time analysis of the program. you can analyse the executable during run time (not to mention the memory), find out which parts operate when. and recognizing calls to the operating system are easy as well (even without this analysis). basically all you need is the binary and run time analysis to understand how everything operates. second, the source code. irrelevant, but just for the sake of completeness. depending on how good you are, how well you know the language you are reversing (and naturally assembly and how the operating system operates), and if you can recognize the compiler used (a bonus not always required if you are good enough), you can pretty much reverse all the source code short of variable names, function names, basically everything but names. " assume the hacker has everything the minute you allow the client to be publicly downloaded. i was just commenting on your mentioning of encryption and protocol selection, both useless if you plan to use secrecy as a weapon. the only thing you cannot know is how the server operates. and then again, people in china wrote a diablo3 server so you can even reverse (or better put - emulate the behavior of) a server without having the binary. whatever other solution you suggested, i was not commenting on, thus it is irrelevant to my post. i will read that discussion in depth later to see if i can comment. " who are these hackers? are they just people from outside who want to disrupt your gameplay for fun and just resurrect random people? it is assumed in that discussion that the player is the hacker. and since the player has the client, he cares not about the encryption (has the key provided by the server) and not about the protocol (has it neatly reversed from the client). the only security a server has against a malicious client is how well the server handles it's packets and how much the server trusts that client. whatever other methods short of encryption and protocol that you suggested to prevent it, i will read and perhaps comment on, but in the quoted post i was talking about the encryption and protocol that you suggested will be secure. EDIT: re-read your posts. you haven't outlined any solution beyond very abstract and common sense things. which do not suggest how to solve desnyc, and do not suggest anything that perhaps isn't already implemented in game. you spoke of the encryption and the protocol, which is the part i commented on. you always assume that there are some unrelated hackers that are trying to disturb an innocent player, not that the player is the one who wants to hack to save the character from death (and other things). if you assume that one of the players wants to hack, then for example (commenting on one thing you said), the packets don't have to be in order because that client can, rather quickly, fake a packet with an earlier timestamp, and thus save himself from death, if the server is too trusting. moreover, if one of the players wants to hack, then the encryption is irrelevant, because that player has the key. not a single one of the encryption methods you mentioned is of any value. please clarify where in your solution you want to trust the client more than it is currently trusted (you can use the manifesto post on desync to find out, in general, where it is not currently trusted). and then i can determine if, from my point of view, it would be vulnerable, and then you can suggest a solution to that vulnerability. the path that can be chosen is not the correct path to choose. such is the nature of the Dao. Last edited by Dao#3393 on Jun 18, 2013, 4:22:30 PM
| |
|
Gonzaw, dao is right. He corrected something I said earlier; encryption unfortunately has no effect on the bots people choose to run. To be honest, I'm not sure what technique GGG is using that is frustrating hackers from using network interception and going pixel-based instead; the only thing dao did was correctly identify that encryption could not be it. It's also possible that the particular hacking community I was listening to is behind the times relative to some others.
When Stephen Colbert was killed by HYDRA's Project Insight in 2014, the comedy world lost a hero. Since his life model decoy isn't up to the task, please do not mistake my performance as political discussion. I'm just doing what Steve would have wanted.
|
|
|
They won't completely eliminate desync as they would have to admit they made mistakes in the coding and design of their netcode. Of course they can't have this, so instead they make small "fixes" that reduce the amount and/or severity of desyncs instead of combating the root cause of the problem.
IGN: ScionHasTheNicestAss (SC)
|
|
|
UDP wouldn't completely eliminate desync. Technically, except for the exact instant that the client gets fresh data from the server, it's in some minor form of desync; the question is whether the user perceives this lack of updated gamestate. The standard for "how long before it's desync" is based on both the ability of the game client to predict the current gamestate in the absence of recent server data (concealment), and on the perception of the viewer (detection).
What UDP would do is greatly reduce the duration between data receipts, thus greatly reducing the amount of desync. However, players who aren't easily fooled by concealment (who analyze network traffic) know that desync might go microscopic, but it's never fully eliminated. When Stephen Colbert was killed by HYDRA's Project Insight in 2014, the comedy world lost a hero. Since his life model decoy isn't up to the task, please do not mistake my performance as political discussion. I'm just doing what Steve would have wanted. Last edited by ScrotieMcB#2697 on Jun 18, 2013, 6:50:09 PM
|
|
" let me understand your terms. network based = what i called man in the middle. sniffing the packets and trying to manipulate them, not from the client, or even necessarily from the same computer. any network sniffing program, like the one you probably used to determine that PoE works on TCP, is an example of how such a thing works. pixel based = some program that learns to identify things on screen and use the client's controls that are available to the player through regular play, just automated is this what you meant ? if so, what i am talking about is something completely different. most network based sniffing hacks are obsolete because of encryption. of course anything can be useful in one situation or another. pixel based is just bots that are doing nothing special but making a player out of the computer, with quicker reaction times than normal humans, and automated procedures. what i am talking about, that would allow the more advanced things, is completely different. it involves reverse-engineering the client and manipulating it. as long as correct information is sent to the server, it would be none-the-wiser. maphack is one simple example of such a thing. you reverse-engineer the client to find out where the map is stored, then modify the client code (or binary) to reveal it all. if the server trusts the client with the entire map, this is possible, and the server would never know because nothing at all is sent to it to alert such a situation - all completely done on the client. sending packets with information and manipulated timestamps is of that nature as well. you need to use the existing encryption code to send valid data using the internal protocol of the game. in the alt-f4 example, you would add code to detect death and immediately generate such data to be sent. then you control the packet (either from within the client, modifying the complete client call to the operating system's socket functions to instead use raw sockets so you can construct your own packets all the time, or just in this particular instance route that packet through another active program on your computer - after preparing it in the client, encryption and all - and that program would construct a custom packet in that particular instance, but the receiving server would be none the wiser because the program would forge the packet to be as if sent from the client). this trivial example is easy to defend against - upon detection of alt+f4 accept no new input until connection is re-established (requiring in the game protocol to send some "new game" packet), and the client shouldn't be sending any. if new input was sent after alt+f4 was used (as would be the case with modifying the timestamps so the server thinks the alt+f4 was sent prior), then the server would know that the client is modified and compromised. same thing could be done even if the client communicates via UDP, so this trivial example is easy to work around. but it was just an illustration of how hacking the client is possible, using the alt+f4 example that was used previously in this discussion. (you could argue that a "new game" packet be forged right after it, and i could say that "new game" would have to, even in the case of UDP, use a TCP-style handshake, and no new commands in the unmodified client would be sent prior to the server acknowledging the "new game" packet. so still, the server would know that the client was compromised) depending on what the server entrusts to the client, vulnerabilities could be found that may or may not involve packet tampering. the path that can be chosen is not the correct path to choose. such is the nature of the Dao.
|
