123
-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|419|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> On Topic -> Decryption woes...

Wed, 19 Oct 2011, 14:33
Afr0
I'm using an ARC4 implementation to en/decrypt my packets, but the last character of the packet I'm decrypting is never decrypted!! :@
Why?



Client:



Server:





The variable Test in HandleCharacterInfoRequest() always ends up with a value similar to: "2011.10.19 10:\0"

Edit: Jay, we need an MMO forum at Socoder!

-=-=-
Afr0 Games

Project Dollhouse on Github - Please fork!
Thu, 20 Oct 2011, 04:18
spinal
With only one member seemingly interested in MMO's, you might be talking to yourself a lot in that forum section. /offtopic

-=-=-
Check out my excellent homepage!
Sat, 22 Oct 2011, 10:17
Afr0
I think I finally found a way to handle this;

  • Client encrypts the first packet (which includes a randomly generated key) with a public key known to the server.
  • Server decrypts packet, and then en/decrypts further messages using the key.

    Instead of using a third-party implementation, I'm now using CryptoStream which is available natively in .NET.
    I realize that anyone can disassemble the client to get the public key used to encrypt the encryption-key, but they'd still have to intercept the first packet, and by then it'd be too late because the encryption-key is generated randomly for each session.

    -=-=-
    Afr0 Games

    Project Dollhouse on Github - Please fork!
  • Wed, 26 Oct 2011, 15:20
    Afr0
    Right, so after a lot of tweaking I finally got something working...

  • Client sends the user's password hashed with the username as a salt. Packet also contains encryption key (which is currently unencrypted, simply because I haven't been bothered to determine the best way to encrypt it yet);



  • Server checks the hash, and if it matches it just sends out a tiny confirmation-packet containing 0x00 (in addition to the PacketID).

  • Client sends a CharacterInfoRequest packet. This packet is encrypted, which it can be since the server now has the key;



  • Server decrypts packet using the same function as the client;



  • Server then reads the decrypted timestamp and fetches the number of characters and character IDs from the DB. If the number of characters is < 1, it just sends an empty, encrypted responsepacket (containing the number of characters, which is 0) (all communication is now encrypted, btw).
    If the number of characters is > 1, it gets the IDs for all the existing characters.
    Then it fetches the information for all the characters with the matching IDs, which includes a timestamp. If the client's timestamp is newer, then all the information about all the characters is sent to the client. If the client's timestamp is older, it means that the client's cache was outdated, so all the information is sent. Otherwise the timestamp matched, so nothing needs to be updated. The idea here is that all the information about all characters is sent at once, such that the timestamps for all characters will always be equal.

    -=-=-
    Afr0 Games

    Project Dollhouse on Github - Please fork!