Client Crash After Packet `MsgAction` v5017

11/09/2018 10:19 ShekoHex#1

Hello There, I've a little problem that's driving me to crazy. but first let me explain it.

TL;DR

Quote:

For about year, i was learning and working with [Only registered and activated users can see links. Click Here To Register...] which i'm very very happy working with it day by day, with that has been said, i came a cross of idea of what about creating a CO Server in it to sharpen my skills in rust and in networking in general, so i searched for a basic source as a reference to me, i found
@Spirited 's [Only registered and activated users can see links. Click Here To Register...]Source
which IMO is very good start and well documented. also i got ConquerWiki also helped me a lot

I started my project and implemented the basic stuff like Networking and encryption stuff, also the project structure is roughly looks like Comet
Auth & Game servers and also some shared libs like `Networking` and `Core`.

I'm relaying on Asynchronous I/O in Rust using [Only registered and activated users can see links. Click Here To Register...] which is very fast and easy.
so far so good i got the client to communicate with Auth server
and got the client also connected to the Game server

the problem is that once the client sends MsgAction Packet with ActionType = 74 (SendLocation), and the server responds with location
the Primary command (uint32) is the player map id and the subtypes
(uint16) player x and the other (uint16) is the player y
and i also sends the server timestamp @ offset 4

once the client got that packet it starts to send other action types which i didn't implement it yet, i just respond with the same packet.
then after some seconds the Client Crashes (closed unexpectedly ^1).

-----

Here is the interesting part, if i started the Spirited's servers (auth & game) logging in the game got the character opened, everything is OK.
Closing Spirited's server without closing the client, clicking ok on the disconnection msgbox and then starting my own auth and game servers
connecting to it from the same client, it opens well and i logged in successfully :pogchamp:

the problem occurs only in a freshly opened client, which makes me like WHAAAAT!! :notsureif: !

some point of view:
i think the client is caching something, maybe some keys or what ever.

Here is a Packet Dump from my servers

Auth Server

Code:

Starting Auth Server
Server running on 0.0.0.0:9958
Client -> Server (MsgAccount) Length: 52 (0x34) bytes
0000:   31 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00   1...............
0010:   1c fd 41 c9  a1 69 aa b6  0d a6 08 4d  f3 67 eb 73   ..A..i.....M.g.s
0020:   5a 65 75 73  00 00 00 00  00 00 00 00  00 00 00 00   Zeus............
MsgAccount { username: "1", password: "1", realm: "Zeus", rejection_code: 2 }
Server -> Client (MsgConnectEx) Length: 32 (0x20) bytes
0000:   41 42 0f 00  e5 44 47 46  31 39 32 2e  31 36 38 2e   AB...DGF192.168.
0010:   31 2e 33 00  00 00 00 00  b8 16 00 00                1.3.........
Client -> Server (MsgConnect) Length: 28 (0x1c) bytes
0000:   41 42 0f 00  0a 00 00 00  72 65 73 2e  64 61 74 00   AB......res.dat.
0010:   00 00 00 00  00 00 00 00                             ........

Game Server

Code:

Starting Game Server
Server running on 0.0.0.0:5816
Client -> Server (MsgConnect) Length: 28 (0x1c) bytes
0000:   41 42 0f 00  e5 44 47 46  7b 00 45 6e  00 00 00 00   AB...DGF{.En....
0010:   00 00 00 00  0a 00 00 00                             ........
MsgConnect { character_id: 1000001, authentication_code: 1179075813, build_version: 123, language: "En", file_contents: 10 }
Server -> Client (MsgTalk) Length: 52 (0x34) bytes
0000:   ff ff ff 00  34 08 00 00  00 00 00 00  00 00 00 00   ....4...........
0010:   00 00 00 00  04 06 53 59  53 54 45 4d  08 41 4c 4c   ......SYSTEM.ALL
0020:   55 53 45 52  53 00 09 41  4e 53 57 45  52 5f 4f 4b   USERS..ANSWER_OK
Server -> Client (MsgUserInfo) Length: 79 (0x4f) bytes
0000:   41 42 0f 00  fb 2a 00 00  17 02 e8 03  00 00 00 00   AB...*..........
0010:   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00   ................
0020:   00 00 00 00  00 00 00 00  00 00 04 00  06 00 0c 00   ................
0030:   00 00 00 00  3e 01 00 00  00 00 01 0a  00 00 01 02   ....>...........
0040:   05 53 68 61  64 79 04 4e  6f 6e 65                   .Shady.None
Client -> Server (MsgAction) Length: 24 (0x18) bytes
0000:   a0 2c 1d 04  41 42 0f 00  00 00 00 00  00 00 00 00   .,..AB..........
0010:   00 00 4a 00                                          ..J.
MsgAction { client_timestamp: 69020843, character_id: 1000001, param0: 1001, param1: 430, param2: 380, param3: 0, action_type: 74 }
Server -> Client (MsgAction) Length: 24 (0x18) bytes
0000:   ab 2c 1d 04  41 42 0f 00  e9 03 00 00  ae 01 7c 01   .,..AB........|.
0010:   00 00 4a 00                                          ..J.
Client -> Server (MsgAction) Length: 24 (0x18) bytes
0000:   02 2e 1d 04  41 42 0f 00  00 00 00 00  00 00 00 00   ....AB..........
0010:   00 00 72 00                                          ..r.
Missing Action Type Unknown(114)
MsgAction { client_timestamp: 69021186, character_id: 1000001, param0: 0, param1: 0, param2: 0, param3: 0, action_type: 114 }
Client -> Server (MsgAction) Length: 24 (0x18) bytes
0000:   02 2e 1d 04  41 42 0f 00  00 00 00 00  00 00 00 00   ....AB..........
0010:   00 00 4b 00                                          ..K.
Missing Action Type SetInventory
MsgAction { client_timestamp: 69021186, character_id: 1000001, param0: 0, param1: 0, param2: 0, param3: 0, action_type: 75 }
Server -> Client (MsgTalk) Length: 75 (0x4b) bytes
0000:   ff ff ff 00  d0 07 00 00  41 42 0f 00  00 00 00 00   ........AB......
0010:   00 00 00 00  04 06 53 59  53 54 45 4d  08 41 4c 4c   ......SYSTEM.ALL
0020:   55 53 45 52  53 00 20 4d  69 73 73 69  6e 67 20 41   USERS. Missing A
0030:   63 74 69 6f  6e 20 54 79  70 65 20 55  6e 6b 6e 6f   ction Type Unkno
0040:   77 6e 28 31  31 34 29                                wn(114)
Server -> Client (MsgAction) Length: 24 (0x18) bytes
0000:   02 2e 1d 04  41 42 0f 00  00 00 00 00  00 00 00 00   ....AB..........
0010:   00 00 72 00                                          ..r.
Server -> Client (MsgTalk) Length: 75 (0x4b) bytes
0000:   ff ff ff 00  d0 07 00 00  41 42 0f 00  00 00 00 00   ........AB......
0010:   00 00 00 00  04 06 53 59  53 54 45 4d  08 41 4c 4c   ......SYSTEM.ALL
0020:   55 53 45 52  53 00 20 4d  69 73 73 69  6e 67 20 41   USERS. Missing A
0030:   63 74 69 6f  6e 20 54 79  70 65 20 53  65 74 49 6e   ction Type SetIn
0040:   76 65 6e 74  6f 72 79                                ventory
Server -> Client (MsgAction) Length: 24 (0x18) bytes
0000:   02 2e 1d 04  41 42 0f 00  00 00 00 00  00 00 00 00   ....AB..........
0010:   00 00 4b 00                                          ..K.
Client -> Server (MsgAction) Length: 24 (0x18) bytes
0000:   60 2e 1d 04  41 42 0f 00  00 00 00 00  00 00 00 00   `...AB..........
0010:   00 00 4c 00                                          ..L.
Missing Action Type SetAssociates
MsgAction { client_timestamp: 69021280, character_id: 1000001, param0: 0, param1: 0, param2: 0, param3: 0, action_type: 76 }
Server -> Client (MsgTalk) Length: 76 (0x4c) bytes
0000:   ff ff ff 00  d0 07 00 00  41 42 0f 00  00 00 00 00   ........AB......
0010:   00 00 00 00  04 06 53 59  53 54 45 4d  08 41 4c 4c   ......SYSTEM.ALL
0020:   55 53 45 52  53 00 21 4d  69 73 73 69  6e 67 20 41   USERS.!Missing A
0030:   63 74 69 6f  6e 20 54 79  70 65 20 53  65 74 41 73   ction Type SetAs
0040:   73 6f 63 69  61 74 65 73                             sociates
Server -> Client (MsgAction) Length: 24 (0x18) bytes
0000:   60 2e 1d 04  41 42 0f 00  00 00 00 00  00 00 00 00   `...AB..........
0010:   00 00 4c 00                                          ..L.

I'm ready to provide any code that could help to reproduce this issue.
Thank you.

Quote:

^1: After attaching a debugger to the game client, i found that it got access memory violation error, then it aborts.

Quote:

Note about the packet dump: the dumped packet dose not include the header in it, the header is showed in the text above the dump,
and of course the full packet is sent to the client.

11/12/2018 16:22 ShekoHex#2

Here is a snapshot of my TQCipher

Code:

use crate::cipher::Cipher; // This is just a shared trait (interface)
use std::num::Wrapping; // Wrapping is used to allow overflow, since rust dose not allow this, but here it is safe
use std::{fmt, mem};

/// Integer constant used to generate the initialization vector.
const P: u32 = 0x13FA_0F9D;

/// Integer constant used to generate the initialization vector.
const Q: u32 = 0x6D5C_7962;

/// The key size in bytes.
const KEY_SIZE: usize = 0x200;

const K: usize = KEY_SIZE / 2;

/// TQ Digital Entertainment's in-house asymmetric counter-based XOR-cipher. Counters
/// are separated by encryption direction to create cipher streams. This implementation
/// implements both directions for encrypting and decrypting data on the server side.
///
/// This cipher algorithm does not provide effective security, and does not make use
/// of any NP-hard calculations for encryption or key generation. Key derivations are
/// susceptible to brute-force or static key attacks. Only implemented for
/// interoperability with the pre-existing game client. Do not use, otherwise.
#[derive(Clone)]
pub struct TQCipher {
    iv: [u8; KEY_SIZE],
    alt_key: [u8; KEY_SIZE],
    use_alt_key: bool,
    decrypt_counter: i64,
    encrypt_counter: i64,
}

impl TQCipher {
    /// Instantiates a new instance of TQCipher using pregenerated
    /// IVs for initializing the cipher's keystreams. Initialized on each server
    /// to start communication. The game server will also require that keys are
    /// regenerated using key derivations from the client's first packet. Increments
    /// counters without thread-safety for synchronous reads and writes.
    pub fn new() -> Self {
        let p: [u8; 4] = unsafe { mem::transmute(P.to_le()) }; // convert P to 4 bytes array
        let q: [u8; 4] = unsafe { mem::transmute(Q.to_le()) };
        let mut local_iv = [0x0u8; KEY_SIZE];
        let local_alt_key = [0x0u8; KEY_SIZE];
        let mut p0 = Wrapping(p[0]);
        let p1 = Wrapping(p[1]);
        let p2 = Wrapping(p[2]);
        let p3 = Wrapping(p[3]);
        let mut q0 = Wrapping(q[0]);
        let q1 = Wrapping(q[1]);
        let q2 = Wrapping(q[2]);
        let q3 = Wrapping(q[3]);
        for i in 0..K {
            local_iv[i] = p0.0;
            local_iv[i + K] = q0.0;
            p0 = (p1 + (p0 * p2)) * p0 + p3;
            q0 = (q1 - (q0 * q2)) * q0 + q3;
        }
        TQCipher {
            iv: local_iv,
            alt_key: local_alt_key,
            use_alt_key: false,
            decrypt_counter: 0,
            encrypt_counter: 0,
        }
    }
}


impl Cipher for TQCipher {
    /// Generates keys for the game server using the player's server access token
    /// as a key derivation variable. Invoked after the first packet is received on
    /// the game server.
    #[inline(always)]
    fn generate_keys(&mut self, a: &u32, b: &u32) {
        let a = Wrapping(*a); // auth_code (token)
        let b = Wrapping(*b); // character_id
        let tmp1 = ((a + b) ^ Wrapping(0x4321)) ^ a;
        let tmp2 = tmp1 * tmp1;
        let tmp_key1: [u8; 4] = unsafe { mem::transmute(tmp1.0.to_le()) };
        let tmp_key2: [u8; 4] = unsafe { mem::transmute(tmp2.0.to_le()) };
        for i in 0..K {
            self.alt_key[i] = self.iv[i] ^ tmp_key1[i % 4];
            self.alt_key[i + K] = self.iv[i + K] ^ tmp_key2[i % 4];
        }
        self.use_alt_key = true;
        self.encrypt_counter = 0; // reset the counter
    }

    /// Decrypts the specified slice by XORing the source slice with the cipher's
    /// keystream. The source and destination may be the same slice, but otherwise
    /// should not overlap.
    #[inline(always)]
    fn decrypt(&mut self, src: &[u8], dst: &mut [u8]) {
        assert_eq!(src.len(), dst.len());
        let key = if self.use_alt_key {
            self.alt_key
        } else {
            self.iv
        };
        for i in 0..src.len() {
            dst[i] = src[i] ^ 0xAB;
            dst[i] = dst[i] >> 4 | dst[i] << 4;
            dst[i] ^= key[(self.decrypt_counter & 0xFF) as usize];
            dst[i] ^= key[((self.decrypt_counter >> 8) + K as i64) as usize];
            self.decrypt_counter += 1;
        }
    }

    /// Encrypt the specified slice by XORing the source slice with the cipher's
    /// keystream. The source and destination may be the same slice, but otherwise
    /// should not overlap.
    #[inline(always)]
    fn encrypt(&mut self, src: &[u8], dst: &mut [u8]) {
        assert_eq!(src.len(), dst.len());
        for i in 0..src.len() {
            dst[i] = src[i] ^ 0xAB;
            dst[i] = dst[i] >> 4 | dst[i] << 4;
            dst[i] ^= self.iv[(self.encrypt_counter & 0xFF) as usize];
            dst[i] ^= self.iv[((self.encrypt_counter >> 8) + K as i64) as usize];
            self.encrypt_counter += 1;
        }
    }
}

the reference i used to implement this is here: [Only registered and activated users can see links. Click Here To Register...]

11/13/2018 17:51 boDil#3

Have you tried to attach a packet logger (I believe there's one here on epvp somewhere) to the client to see what the packets received by the client look like?

Your response packets look fine to me, so you're probably on the right track with looking at your cipher.

You could also disable packet encryption from the client entirely (and server, too, obviously) to see if it works without it. That would probably take quite some effort though, but I wrote a "[Only registered and activated users can see links. Click Here To Register...]" for it in case you'd want to try it.

11/13/2018 19:19 ShekoHex#4

Quote:

Originally Posted by boDil

Have you tried to attach a packet logger (I believe there's one here on epvp somewhere) to the client to see what the packets received by the client look like?

Your response packets look fine to me, so you're probably on the right track with looking at your cipher.

firstly, thank you for your reply and trying to help,
although, i'm trying to find out the problem at the encryption algo. scope, why the client works well when i'm tried to log-in first using another soruce/server and then with the same opened client using my own server ?
with that have been said, i will try to re implement the cipher from ground up again.
but first i will try to get some packet logger to see the packets first.

Quote:

Originally Posted by boDil

You could also disable packet encryption from the client entirely (and server, too, obviously) to see if it works without it. That would probably take quite some effort though, but I wrote a "[Only registered and activated users can see links. Click Here To Register...]" for it in case you'd want to try it.

although this approach is very nice, but i'm likely to keep it as a last chance to see if that was the encryption problem.

11/14/2018 11:41 Super Aids#5

I'm going to assume that you're reading the packets incorrectly.

There is usually a log file associated when the client crashes and it should tell you what went wrong.

Packets are read like this:

2 bytes (size)
2 bytes (type)
n bytes (packet)
8 bytes (suffix - The suffix is not always present. I think the auth server doesn't use it? - This also depends on version, can't remember what version they added it in.)

A usual cause for this is that you read a static sized buffer, but it's either incomplete or it has too many bytes.

If it's incomplete then you need to read more bytes from the socket to complete the buffer. You're not always guaranteed to receive all bytes at once when reading from a socket, this is very important when writing your socket handler because it must be able to receive multiple times in order to get all bytes needed for the buffer.

If the buffer has too much data ex. you have a buffer of 1024 bytes, but your packet was only 10 bytes then you need to retrieve the first 10 bytes because those will be the current packet to handle. Afterwards you're left with the beginning of a new packet and thus the first 2 bytes will give you the size you need for the next packet and thus you can fit the buffer accordingly.

You have to repeat either of those steps.

This is usually solved using a packet-splitter.

Also remember that when receiving from a socket you always get the amount of bytes read, so you can always calculate whether you have received all bytes or not.

I'm sure Tokio has something for their streams that tells you how many bytes were read, it at least exists when you use io::copy from the reader stream to the writing stream then you get an amount from its future callback.

11/14/2018 16:56 boDil#6

Quote:

Originally Posted by Super Aids

I'm going to assume that you're reading the packets incorrectly.

There is usually a log file associated when the client crashes and it should tell you what went wrong.

Packets are read like this:

2 bytes (size)
2 bytes (type)
n bytes (packet)
8 bytes (suffix - The suffix is not always present. I think the auth server doesn't use it? - This also depends on version, can't remember what version they added it in.)

A usual cause for this is that you read a static sized buffer, but it's either incomplete or it has too many bytes.

If it's incomplete then you need to read more bytes from the socket to complete the buffer. You're not always guaranteed to receive all bytes at once when reading from a socket, this is very important when writing your socket handler because it must be able to receive multiple times in order to get all bytes needed for the buffer.

If the buffer has too much data ex. you have a buffer of 1024 bytes, but your packet was only 10 bytes then you need to retrieve the first 10 bytes because those will be the current packet to handle. Afterwards you're left with the beginning of a new packet and thus the first 2 bytes will give you the size you need for the next packet and thus you can fit the buffer accordingly.

You have to repeat either of those steps.

This is usually solved using a packet-splitter.

Also remember that when receiving from a socket you always get the amount of bytes read, so you can always calculate whether you have received all bytes or not.

I'm sure Tokio has something for their streams that tells you how many bytes were read, it at least exists when you use io::copy from the reader stream to the writing stream then you get an amount from its future callback.

It's the client that crashes, not the server, and if you look at the packet dump he provided, it seems like the "initialization" phase of the client went fine (EnterMap, GetItems, GetFriends, etc.), so I don't think he's reading packets wrong; also, the packet dump shows no packet "fragments" or anything like that as far as I can tell.

I'm probably leaning towards the cipher implementation being faulty somehow, but I've never actually implemented it myself, so I can't really tell if anything is wrong with it.

11/14/2018 17:08 ShekoHex#7

Quote:

Originally Posted by Super Aids

Spoiler

I'm going to assume that you're reading the packets incorrectly.

There is usually a log file associated when the client crashes and it should tell you what went wrong.

Packets are read like this:

2 bytes (size)
2 bytes (type)
n bytes (packet)
8 bytes (suffix - The suffix is not always present. I think the auth server doesn't use it? - This also depends on version, can't remember what version they added it in.)

A usual cause for this is that you read a static sized buffer, but it's either incomplete or it has too many bytes.

If it's incomplete then you need to read more bytes from the socket to complete the buffer. You're not always guaranteed to receive all bytes at once when reading from a socket, this is very important when writing your socket handler because it must be able to receive multiple times in order to get all bytes needed for the buffer.

If the buffer has too much data ex. you have a buffer of 1024 bytes, but your packet was only 10 bytes then you need to retrieve the first 10 bytes because those will be the current packet to handle. Afterwards you're left with the beginning of a new packet and thus the first 2 bytes will give you the size you need for the next packet and thus you can fit the buffer accordingly.

You have to repeat either of those steps.

This is usually solved using a packet-splitter.

Also remember that when receiving from a socket you always get the amount of bytes read, so you can always calculate whether you have received all bytes or not.

I'm sure Tokio has something for their streams that tells you how many bytes were read, it at least exists when you use io::copy from the reader stream to the writing stream then you get an amount from its future callback.

thank you for your explanation.
For Socket Reading from Socket, i think there is no problem in it.
I created a very good packet splitting mechanism for that

so long story short, Since Everything here is Async, after reading some data from the socket, the data goes to a State Machine that has a `DecodeState` either is `Head` or `Data`, so here we have two methods `decode_head` and `decode_data`.

Decode Head:
the decode head returns a Result with Optional data of Tuple (u16, PacketType)
here is what is going on
first i check the size of the buffer of the socket reader, if it's less than 4 then i return immediately with `None`. the state machine then return to the current Reactor (executor) to tell it is not ready yet, the next time the reactor tries to `poll` our stream, it maybe filled with the minimum required length (4 bytes).
then if there is the (4 bytes) or greater than that, it's okay, i just using the cipher to decrypt the first 4 bytes into an 4 bytes slice, then read the first 2 bytes as `u16` (ushort) which will give me the length of the packet, and the next 2 bytes also as `u16` which gives me the packet type.
after that split and remove those 4 bytes from the stream, then return with (len - 4, packetType) to the state machine, which will update it's state and start to decode the data.
Decode Data:
in this case it's more simpler than above, first as always i will check for the current length of my socket reader buffer against the provided length from state machine, if there is enough data decrypt this data using the cipher and return these bytes to the packet structure mapper along with packet type.

For Packet Reading and Writing I created a Very efficient **I THINK** for Serialization and Deserialization packets.

i'm using [Only registered and activated users can see links. Click Here To Register...]
Serde is a framework for serializing and deserializing Rust data structures efficiently and generically.
Rust dose not have reflection or to be more precisely a run-time reflection
instead, everything would be done in compile time.
so i created my Serialization and Deserialization for Conquer Packets

Here is an Example how that will work.

after getting data and packet type from socket using the state machine
the server will match over the packet type and start to use a structure according to that packet type (packet id)

here is an example of the Auth Server `MsgAccount` structure

Code:

#[derive(Deserialize)]
pub struct MsgAccount {
    #[serde(deserialize_with = "deserialize_fixed_string_16")]
    pub username: String,
    #[serde(deserialize_with = "deserialize_password")]
    pub password: String,
    #[serde(deserialize_with = "deserialize_fixed_string_16")]
    pub realm: String,
    #[serde(skip)]
    pub rejection_code: u32,
}

the `#[derive(Deserialize)` is simple to tell the compiler to do the implantation of Deserialize trait for me for this simple structure.
the `deserialize_fixed_string_16` and `deserialize_password` is a custom methods created by me to deserialize the fixed strings in packets

here is an another example form Game Server `MsgTalk` packet.

Code:

#[derive(Debug, Default, Deserialize, Serialize)]
pub struct MsgTalk {
    color: u32,
    channel: u16,
    style: u16,
    character_id: u32,
    recipient_mesh: u32,
    sender_mesh: u32,
    list_count: u8,
    sender_name: String,
    recipient_name: String,
    suffix: Option<String>,
    message: String,
}

as i said the `#[derive(...)]` notation tells the compiler: please can you do that implantation for me ?

but how to get the data or write data from and to that structure ?
for that i created the 2 simple function `to_bytes(something that impl Serialize trait) -> Bytes`
and `from_bytes(Bytes) -> Structure`

Code:

impl TQMessage for MsgTalk {
    fn decode(&mut self, packet: Bytes) -> SerdeResult<()> {
        *self = from_bytes(&packet)?;
        Ok(())
    }

    fn encode(&mut self) -> SerdeResult<Option<(Bytes, PacketType)>> {
        Ok(Some((to_bytes(self)?.freeze(), PacketType::MsgTalk)))
    }
}

so after getting the data (buffer) from the socket and we know the packet structure from packet type i just call `from_bytes(buffer)` to structure the data back from that bytes
and so as in `to_bytes(structure)` to get bytes out from that structure append packet length and packet type to the first 4 bytes in that bytes and send that to the client.

so here there is no manual reading and writing to the socket, and instead of dealing with byte level, i'm playing with the structure itself.

by the way, i'm using channels to communicate internally.
here is a snippet where i'm trying to send a msg talk packet to the client.

Code:

 let mut msg_talk = MsgTalk::from_system(0, TalkChannel::Create, ANSWER_OK.to_string());


// the actor here is wrapper around the current active socket (client) connection, the send method
// is not the send to the socket. it's used to send (Queue) a msg to the client.
actor.send(&mut msg_talk)?;

so at the end sorry it that was too long, but i want to just explain as much as i can,

and another request, if someone could give me a link for a 5017 Packet logger to see what packet received by the client from the server ?

and the question remains the same:

Quote:

why the client works well when i'm tried to log-in first using another source/server and then with the same opened client using my own server ?

11/15/2018 10:02 Super Aids#8

Quote:

Originally Posted by boDil

It's the client that crashes, not the server, and if you look at the packet dump he provided, it seems like the "initialization" phase of the client went fine (EnterMap, GetItems, GetFriends, etc.), so I don't think he's reading packets wrong; also, the packet dump shows no packet "fragments" or anything like that as far as I can tell.

I'm probably leaning towards the cipher implementation being faulty somehow, but I've never actually implemented it myself, so I can't really tell if anything is wrong with it.

Yes, the client will crash if you send an invalid packet and that usually happens when you're receiving packets wrong, because then you end up sending some weird ass size etc.

11/15/2018 22:45 ShekoHex#9

Quote:

Originally Posted by boDil

I'm probably leaning towards the cipher implementation being faulty somehow, but I've never actually implemented it myself, so I can't really tell if anything is wrong with it.

OK after investigating sometime to look at the Crypto it self, i re-implemented it again from ground up, and i can say, you was right, it's the crypto problem.

and the server is now working :pogchamp:

[Only registered and activated users can see links. Click Here To Register...]

Thank you all :)

11/16/2018 03:58 Spirited#10

Quote:

Originally Posted by ShekoHex

OK after investigating sometime to look at the Crypto it self, i re-implemented it again from ground up, and i can say, you was right, it's the crypto problem.

and the server is now working :pogchamp:

[Only registered and activated users can see links. Click Here To Register...]

Thank you all :)

I had that before where I was looping through a slice wrong in the cipher and it caused it to eventually desynchronize from the client. Glad you found the issue, those low level server issues are difficult to debug sometimes.

11/16/2018 16:45 boDil#11

Quote:

Originally Posted by ShekoHex

OK after investigating sometime to look at the Crypto it self, i re-implemented it again from ground up, and i can say, you was right, it's the crypto problem.

and the server is now working :pogchamp:

[Only registered and activated users can see links. Click Here To Register...]

Thank you all :)

Awesome, good job!