Register for your free account! | Forgot your password?

Go Back   elitepvpers > Conquer Online 2 > CO2 PServer - Discussions / Questions
You last visited: Today at 10:31

  • Please register to post and access all features, it's quick, easy and FREE!


Client Crash After Packet `MsgAction` v5017

Reply
 
Old   #1
 
elite*gold: 0
Join Date: Jun 2014
Posts: 12
Received Thanks: 1
Exclamation Client Crash After Packet `MsgAction` v5017

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 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 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 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

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

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.



ShekoHex is offline  
Old 11/12/2018, 16:22   #2
 
elite*gold: 0
Join Date: Jun 2014
Posts: 12
Received Thanks: 1
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:


ShekoHex is offline  
Old 11/13/2018, 17:51   #3
 
elite*gold: 0
Join Date: Apr 2017
Posts: 91
Received Thanks: 53
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 "" for it in case you'd want to try it.
boDil is online now  
Old 11/13/2018, 19:19   #4
 
elite*gold: 0
Join Date: Jun 2014
Posts: 12
Received Thanks: 1
Quote:
Originally Posted by boDil View Post
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 View Post
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 "" 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.


ShekoHex is offline  
Old 11/14/2018, 11:41   #5
 
elite*gold: 0
Join Date: Dec 2012
Posts: 1,620
Received Thanks: 834
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.
Super Aids is offline  
Old 11/14/2018, 16:56   #6
 
elite*gold: 0
Join Date: Apr 2017
Posts: 91
Received Thanks: 53
Quote:
Originally Posted by Super Aids View Post
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.
boDil is online now  
Thanks
1 User
Old 11/14/2018, 17:08   #7
 
elite*gold: 0
Join Date: Jun 2014
Posts: 12
Received Thanks: 1
Quote:
Originally Posted by Super Aids View Post

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`.
  1. 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.
  2. 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
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 ?
ShekoHex is offline  
Old 11/15/2018, 10:02   #8
 
elite*gold: 0
Join Date: Dec 2012
Posts: 1,620
Received Thanks: 834
Quote:
Originally Posted by boDil View Post
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 *** size etc.
Super Aids is offline  
Old 11/15/2018, 22:45   #9
 
elite*gold: 0
Join Date: Jun 2014
Posts: 12
Received Thanks: 1
Quote:
Originally Posted by boDil View Post

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



Thank you all
ShekoHex is offline  
Thanks
1 User
Old 11/16/2018, 03:58   #10
 
elite*gold: 12
Join Date: Jul 2011
Posts: 7,048
Received Thanks: 3,383
Quote:
Originally Posted by ShekoHex View Post
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



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.
Spirited is offline  
Thanks
1 User
Old 11/16/2018, 16:45   #11
 
elite*gold: 0
Join Date: Apr 2017
Posts: 91
Received Thanks: 53
Quote:
Originally Posted by ShekoHex View Post
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



Thank you all
Awesome, good job!


boDil is online now  
Thanks
1 User
Reply

Tags
co5017, msgaction



« Conquer2 3D - Opinions? | Could someone tell me the name please? »

Similar Threads
after making update client crash after chose character
03/14/2013 - SRO PServer Ask the Experts - 4 Replies
Hello Epvp after making update client crash after chose character i update the media with english txts and Particles too put i delete the update for the Particles
Crash Crash Crash
07/27/2010 - SRO PServer Ask the Experts - 3 Replies
When i try to log in with bot, after i log in, instant CRASH. It is because of the traffic on ZSZC ? What should i do ?
Crash. Crash. Crash. Help?
10/30/2009 - Dekaron - 10 Replies
Okay EPVPr's, I have a question for you. Is anyone else having the 2moons/dekaron client crash on them as much as it is for me? I'll explain my full situation unlike alot of people on here(I'm sure most of you guy's know what i'm referring to :p) Situation: I start 2Moons, login. Usually on char select i'll open CE 5.5 from my "Up To Date" .CT file. Other times it will be "in map" depends on the situation as you all know. With as little as only one script activated(or even all) which most...
Where can I download the original Conquer v5017 client?
08/29/2009 - CO2 PServer - Discussions / Questions - 1 Replies
I need a site or anywhere to download the original plain v5017 client so I can edit it. Please help me.



All times are GMT +1. The time now is 10:31.


Powered by vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.

Support | Contact Us | FAQ | Advertising | Privacy Policy | Abuse
Copyright ©2018 elitepvpers All Rights Reserved.