| User | Post |
Kaz
 
   
  
 
 
Since: 06-24-02
From: I'm not paranoid...
Rating: 10 (400 pts)
Since last post: 7499 days
Last activity: 7574 days
|
|
Somebody said (they play KRO) that they've implemented encrypted packets now. Several questions:
1) It's crackable right?
2) It's even more crackable if you look in the program isn't it?
3) How does it work exactly? I'm guessing that they don't use bytes and go to nibbles or binary and then maybe invert the code.
4) Anything else somebody should know... |
DaiSHi
Moderator
 
Since: 05-03-02
From: California
Rating: 10 (400 pts)
Since last post: 7351 days
Last activity: 7351 days
|
|
i'm no expert on ecryption, but if encrypted packets are sent to the client, then there has to be a decrypter in the client. it'll be only a matter of time before someone finds that decrypter, figures out how it works, and can make their own...
edit: another thought came to mind: if our client has to support the decryption, either we have to dl an entirely new client with the decrypter, or our client gets patched. obviously, that patch will have the decrypter in there, making it easier for crackers to get to work... even encrypting the patch may not be enough, just delays the process
--------------------
Loki: DaiSHi 49/38 future knight, H.O.L.Y.Merchant OC peekaboo
(edited by DaiSHi on 11-23-02 12:19 PM) |
lagwagon
 
Since: 08-12-02
From: Orange County, CA
Since last post: 7556 days
Last activity: 7556 days
|
|
packet encryption wouldn't be nessacary would it? Although I suppose it would help to directly add new packets to the emulated one that were from the real one.
IOW, If packets were encrypted new packets from gravities servers wouldn't have to be decrypted, then added to the emu server/client. Right?
--------------------
       -=[chaos]=-
Kneo  :: lvl 36/31 theif
Lagwagon ::Â lvl 21/20 archer
:: lagwagon was here :: |
MingShun
 
Since: 05-10-02
Rating: 10 (400 pts)
Since last post: 7399 days
Last activity: 7399 days
|
|
I can't think of any other encyption methods which do not require the client to decrypt. At least not the program itself. I'm sure that if RO is operating version specific, they can probably use Kereberos encryption protocol...no wait, that won't work. Sorry, I keep mistaking what Kereberos does.
Best bet is that if there is encryption, it's gonna be in a compiled program and include a lot of math and manipulation. How the encryption is implemented though will determine how difficult the program is to crack.
I mean, inverting all the bits...that's fast, but it's somewhat easy to figure out.
How about if you're using the nth place of Pi and multiplying it by the inverted bits + the range of numbers starting from n -> n + 8 place of e. Lol, as long as the program can figure out what the n's used were, this would be a legitimate method.
Seriously though, I think that if there RO uses encryption, it's gonna be something simple like add a number to the packet. I seriously doubt they would waste time implementing something more difficult unless the players keep complaining.
[edit] I forgot to add, encryption can be used to protect packets from outside interference. That means from third parties, like eavesdroppers. The question is, who is the eavesdropper? Someone looking for private information, or a program that makes decisions based on the information it's given (a bot comes to mind).
IOW, encryption tries to protect information until it reaches the endpoint.
[another edit] If this whole post sounds fake, well...I'm not really up to date with security methods...I just wrote what seemed logical.
--------------------
This is my signature, what else do you think it could be?
(edited by MingShun on 11-23-02 08:32 PM) |
Sasami
Goddess in Training
 
Since: 02-18-02
From: Back in texas! YAY! college sucked!
Rating: 10 (1030 pts)
Since last post: 7351 days
Last activity: 7351 days
|
|
| best way to do packet encryption is use variables that are constantly changing like session uptime, date, number of characters on the screen at a time for a person, etc, really throws people for a loop, even when trying to look inside the game code. Algorithms with set numbers are easy to find out no matter what because they are right inside the exe. But the encryption needs to be simple enough as to not take up too much processor, specifically for the server as it will be decoding and encoding a lot of packets. |
lagwagon
Since: 08-12-02
From: Orange County, CA
Since last post: 7556 days
Last activity: 7556 days
|
|
hmm... another possibliity, and I'm not saying this out of knoledge, but out of a guess, and I'm not sure if this is even ever used, but isn't it possible for the server to have a packet A, convert it to packet B, and the client converts packet B to packet C (while A does not C). Then the client takes a type C, converts it to D, and the server converts D to A? That would really throw somone off considering incoming packets would be different encryption that outgoing...
Just a thought.
--------------------
       -=[chaos]=-
Kneo  :: lvl 36/31 theif
Lagwagon ::Â lvl 21/20 archer
:: lagwagon was here :: |
MingShun
Since: 05-10-02
Rating: 10 (400 pts)
Since last post: 7399 days
Last activity: 7399 days
|
|
That's brilliant! When I think of encryption, I think of it like A-B-A. As long as the client understands type C, this would make an excellent encryption technique. From the looks of it, sending A out and receiving an A back could help with data integrity too. After all, A could boost the numbers, so if a bad D comes back, the data could be out of bounds. In other words, A has to make sense, you can't have a character go from 1,1 to 500,500 with a single step.
I'm sure there's gotta be a flaw somewhere, but I can't think of one at the moment.
--------------------
This is my signature, what else do you think it could be? |
Kaz
Since: 06-24-02
From: I'm not paranoid...
Rating: 10 (400 pts)
Since last post: 7499 days
Last activity: 7574 days
|
|
Hmm
A (original I assume?)
Goes to B for incoming packet sniffer...
Changes to C (but it's not original...)
Client changes C to what so it can understand it?
Client changes it to D for outgoing packet sniffer
Server changes it back to A for checksum.
I don't think packets go in a complete loop though. Just have an integrity check would double teh required bandwith. |
MingShun
Since: 05-10-02
Rating: 10 (400 pts)
Since last post: 7399 days
Last activity: 7399 days
|
|
Bandwidth? From the looks of it, only one packet is needed. You don't need extra packets for integrity...although it might help. Bandwidth usage seems normal then.
Are you sure you don't mean CPU and memory? That's where the conversions take place, at the endpoints.
I figured out a probable flaw. People can monitor the outgoing D packets and the incoming B packets. I think that if they can find the pattern in the D packets, then they could probably figure out the encryption that'll turn a D packet into a legal A packet. IOW, the concept seems similar to keygen technology.
Perhaps the B packets may help their quest too. It's the go-btwn of an A and a C. The D is the go-btwn of an A and a C too. Essentially, there has to be some relationship between the two. I'm saying that B and D have to be related in some way, or you can't make an A from a C and a C from an A. I'm trying to think if this isn't always true, but I'm not sure.
Now then, it comes to the strength of the encryption. Yeah, there can be a relationship btwn B and D, the question is, what is it? Encrypting a set of data 5 different ways is stronger than 1 way. It also takes a lot more CPU time.
Oh, C type encryption seems to be the unencrypted form that the client can read.
--------------------
This is my signature, what else do you think it could be? |
lagwagon
Since: 08-12-02
From: Orange County, CA
Since last post: 7556 days
Last activity: 7556 days
|
|
yeah, i can see that it probably would comsume a lot of cpu and other temporary/processing resources, but this isnt even happening anyway, so lets make it more advanced =)
if you threw in, like Sasami said, an always changing variable, you could use it like this:
packet A: some encryption with a changing variable, but heres the trick: the changing variable to be used would be decided by yet another changeing variable!
like date would be part of the encryption at one time, and as for the packets coming out of the client: at one time it might use the number of red pixels on the user's screen at that given time. at another time the server might be sending an encryption with the number of characters on the server, and the client might be sending the ro server's ping as the user sees it.
woah... that might give a person trying to figure out the packets a mental break down... lol.
--------------------
       -=[chaos]=-
Kneo  :: lvl 36/31 theif
Lagwagon ::Â lvl 21/20 archer
:: lagwagon was here :: |
MingShun
Since: 05-10-02
Rating: 10 (400 pts)
Since last post: 7399 days
Last activity: 7399 days
|
|
Lol, the challenge is getting the decoding key to the client without another party intercepting it 
Maybe have the key take an alternate route.
Let's see, advantages of the alternate route...
1. 3rd party cannot immediately decode an encrypted packet. Needs both parts, the encrypted packet, and the key.
2. Also, might not spot the key. I mean, while he's watching an ocean the key is currently traveling through a city hundreds of miles away. Can't spot the key, can't grab it.
Disadvantages:
1. There could be a delay between the encrypted packet and the decoding key. I mean, the time it takes to travel one route may be different from the time needed for another.
2. If the other party is sniffing the receiving party's connection...the alternate route method won't do any good. He'll still get the key. Unlike (2) of the advantages, the 3rd party is sniffing the endpoint, and not somewhere in the middle.
3. Bandwidth. We need to send 2 parts for one piece of information. Worst case, traffic load is 2 times heavier.
Lol, it might work though. I think this system would work if not used for a realtime system. Any other ideas?
--------------------
This is my signature, what else do you think it could be? |
Kaz
Since: 06-24-02
From: I'm not paranoid...
Rating: 10 (400 pts)
Since last post: 7499 days
Last activity: 7574 days
|
|
Erm... I meant the server would have to understand it. Since C is unencrypted, the server is working with encrypted data, which is sort of a oxymoron. It's not working off an A, it's working off encrypted information that would have had to have a C in the first place.
Or perhaps I'm rambling again.
Speculation:
I don't think they're implementing a very complex encryption. They said that there will be lag becuase of it, but I think they're just using that as a scape goat.
Think about it... I think this might be whats happening;
Gravity goes p2p in America for the cheap price of $5 a month since they can't overcharge and lose customers/publicity. Since they're not getting much profit, they decide to use the loki server for another service. Well, we get what we paid for... They'll add in 3 sub servers anyways becuase lag is still horrible and as some sort of compensation. Now then, they'll implement a small encryption, blame it on that, get rid of most hackers in the process. They get money, most people blame it on encryption, we play and are at least happy... and all is good... not the best, but decently good.
Btw, I plan on trying to crack this with my super 1337 n00b skillz. Simply, taking a packet that we know about, and comparing to a new packet... anybody know if the client sends "idle" packets? If you're all alone in a corner of prontera, will a packet be sent? |
lagwagon
Since: 08-12-02
From: Orange County, CA
Since last post: 7556 days
Last activity: 7556 days
|
|
Have no fear! Kaz's ub3r l337 n00b h4xing sk1llz are here!
lol g/l man
About the idle packets, this was posted in general discussion in the thread "No encryption? Gravity2BLying...":
Originally posted by Sasami
7E is a uptime packet sent by the client to make sure it is in sync with the server for the speed hack, it in no way stops bots though because the server does not sever the connection if it isnt recieved.
so are those 'sync' packets what you might consider idle packets? You send them when you're idle, but they serve a purpose...
--------------------
       -=[chaos]=-
Kneo  :: lvl 36/31 theif
Lagwagon ::Â lvl 21/20 archer
:: lagwagon was here :: |
Sasami
Goddess in Training
Since: 02-18-02
From: Back in texas! YAY! college sucked!
Rating: 10 (1030 pts)
Since last post: 7351 days
Last activity: 7351 days
|
|
| you send them all the time no matter what at certain intervals, whether you are idle or not. |
| 
