e.e
Divine Intellect
- Joined
- Sep 16, 2016
- Messages
- 476
- Solutions
- 1
- Reaction score
- 227
Hello.
I'm trying to connect to a cip server 7.7 using OTC.
Connecting with cip client works.
I set OTSERV_RSA in modules/gamecore/const.lua to cip client 7.7's public RSA key which is
I then get to char list, but upon trying to log in with a character OTC hangs and I see this error in console
Someone then told me in a different post that since I got to character list that the problem I'm having is happening while connecting to the game server.
I only confirmed this yesterday when I did some network traffic analysis comparing successful login with cip client vs failed login with OTC client.
Here's a summary of what I noticed:
Connecting to the login server:
References
1)
cip client connection #1 (first data packet to login server)
cip client connection #2 (first data packet to login server)
OTC connection #1 (first data packet to login server)
OTC connection #2 (first data packet to login server)
2)
cip client connection #1 (first data packet to game server):
cip client connection #2 (first data packet to game server):
OTC connection #1 (first data packet to game server):
OTC connection #2 (first data packet to game server):
Interested in ideas, suggestions or solutions!
I'm trying to connect to a cip server 7.7 using OTC.
Connecting with cip client works.
I set OTSERV_RSA in modules/gamecore/const.lua to cip client 7.7's public RSA key which is
Code:
1429962396241639952007017738289889555079540334546615321747051608293473758277603888296721338620
4600674145392845853859217990626450972452084065728686565926568763097919597040472189120184779200
2125535401292779123937207447574596692788513647179235335529307251350570728407373705564708871762
033017096809910315212883967
Code:
ERROR: invalid decrypted network message
C++ stack traceback:
[C++]: Protocol::xteaDecrypt
./otclient(Protocol::xteaDecrypt(stdext::shared_object_ptr<InputMessage> const&)+0x234) [0x7ced52]
./otclient(Protocol::internalRecvData(unsigned char*, unsigned short)+0x240) [0x7cf0ba]
./otclient(std::_Function_handler<void (unsigned char*, unsigned short), std::_Bind<std::_Mem_fn<void (Protocol::*)(unsigned char*, unsigned short)> (stdext::shared_object_ptr<Protocol>, std::_Placeholder<1>, std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&, unsigned char*, unsigned short)+0x47) [0x7d045b]
./otclient(Connection::onRecv(boost::system::error_code const&, unsigned long)+0x6a) [0x7c25d0]
./otclient(boost::asio::detail::read_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, std::_Bind<std::_Mem_fn<void (Connection::*)(boost::system::error_code const&, unsigned long)> (stdext::shared_object_ptr<Connection>, std::_Placeholder<1>, std::_Placeholder<2>)> >::operator()(boost::system::error_code const&, unsigned long, int)+0x2fb) [0x7cb827]
./otclient(boost::asio::detail::reactive_socket_recv_op<boost::asio::mutable_buffers_1, boost::asio::detail::read_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, std::_Bind<std::_Mem_fn<void (Connection::*)(boost::system::error_code const&, unsigned long)> (stdext::shared_object_ptr<Connection>, std::_Placeholder<1>, std::_Placeholder<2>)> > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long)+0x101) [0x7cb949]
./otclient(boost::asio::detail::task_io_service::poll(boost::system::error_code&)+0x320) [0x7c5dbe]
./otclient(Connection::poll()+0x50) [0x7bfd48]
ERROR: failed to decrypt message
C++ stack traceback:
[C++]: Protocol::internalRecvData
./otclient(Protocol::internalRecvData(unsigned char*, unsigned short)+0x283) [0x7cf0fd]
./otclient(std::_Function_handler<void (unsigned char*, unsigned short), std::_Bind<std::_Mem_fn<void (Protocol::*)(unsigned char*, unsigned short)> (stdext::shared_object_ptr<Protocol>, std::_Placeholder<1>, std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&, unsigned char*, unsigned short)+0x47) [0x7d045b]
./otclient(Connection::onRecv(boost::system::error_code const&, unsigned long)+0x6a) [0x7c25d0]
./otclient(boost::asio::detail::read_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, std::_Bind<std::_Mem_fn<void (Connection::*)(boost::system::error_code const&, unsigned long)> (stdext::shared_object_ptr<Connection>, std::_Placeholder<1>, std::_Placeholder<2>)> >::operator()(boost::system::error_code const&, unsigned long, int)+0x2fb) [0x7cb827]
./otclient(boost::asio::detail::reactive_socket_recv_op<boost::asio::mutable_buffers_1, boost::asio::detail::read_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, std::_Bind<std::_Mem_fn<void (Connection::*)(boost::system::error_code const&, unsigned long)> (stdext::shared_object_ptr<Connection>, std::_Placeholder<1>, std::_Placeholder<2>)> > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long)+0x101) [0x7cb949]
./otclient(boost::asio::detail::task_io_service::poll(boost::system::error_code&)+0x320) [0x7c5dbe]
./otclient(Connection::poll()+0x50) [0x7bfd48]
./otclient(Application::poll()+0x9) [0x72a79d]
I only confirmed this yesterday when I did some network traffic analysis comparing successful login with cip client vs failed login with OTC client.
Here's a summary of what I noticed:
Connecting to the login server:
- Although the data patterns are a bit different between cip client vs OTC client (see reference 1), the data size of the packets sent back and forth are the same between the clients, and the number of packets and TCP flags are the same.
- It seems that both clients authenticates successfully as there's nothing too unexpected and the clients proceeds to connecting to the game server with same-sized data packets sent after handshake.
- The data patterns differs like before between the clients (see reference 2).
- Additionally the first data packet sent differs by 4 bytes between the two clients (cip 131 vs OTC 135) (see reference 2).
- The server responds with a data packet of size 1276 bytes to the cip client which successfully logs in, while it responds with a data packet of size 42 bytes to OTC.
- In OTC's case OTC then tries to send a 10 byte size packet that always starts with the hex data 0800 and then sends a FIN ACK which the server responds to with a ACK and then a RST ACK once I exit OTC.
In cip client's case after the server sends a 1276 bytes sized data packet the server sends another 934 bytes and then it looks like the client is connected as the server and client are sending small, variable-sized data packets back and forth. - One more strange anomaly I noticed is that the game server's 1276 byte packet sent to the cip client does not have a PUSH flag, just ACK. This can't be the cause of the problem with OTC connecting thus far though since it hasn't even gotten to the point of receiving any 1276 byte packet (or any other packets with any data and no PUSH flag for that matter).
References
1)
cip client connection #1 (first data packet to login server)
Code:
91000102000203335a9d43be529843d8c8504428df9dd16b89c20f579509c0a70a5c4a201bf851728cccaa476018d41984c0db22a36fce45f1bfd4c5588b66c0417da93b83b9a4ea0196dc66134640334ab2b0e5521be91518ac5aec2d02cf83c4d18f7e5777d7159479881feeffbef0ab87ba933774d58b65d94a60f65f48cb2594f28f117bc693e5a6af1674a8e8306105d3
cip client connection #2 (first data packet to login server)
Code:
91000102000203335a9d43be529843d8c85044c73394542460e57cdd6fbe34781e236f7b8748899753c5c4a23daac31377658d65fa33759de34dc42900a80f4adfb6307167a3c8bff4c5d2e0082d9131c64be8685fceeb7fd5d3da3d15763074e28c3602473b55b17b10a33414316ada07104b7eb5c00251157c08f27fd1b5861a90eb5b7ffe0e548b7f601f6649c6ab7c8001
OTC connection #1 (first data packet to login server)
Code:
9100010b000203335a9d43be529843e7ddc5563e7ad03363a21f5059f68d6f251af89781704a9baefb7ccfe40e578d97d2eeeef0961edbb54841c7dd00b987f27fbd81e57ec65eda55a8174a27fc4cbd297351327ff4953eeeedb7a5c0b6e7e5ce4eae9bc095ad30c8d537d9299fe2a58c202f08dacf650958eccba2024cabba6e3d94397c35523fbfe98f3a0bd458e0b1a547
OTC connection #2 (first data packet to login server)
Code:
9100010b000203335a9d43be529843e7ddc55659ee3e0ada2e84d77a420f0735dfc4c81b1bd3127dbc64579b5fc0250665b76916e47f0a6c57468a5a1ad78d2ea6021ceaf86e5829243ae93426af44f011035a9dc0e1438962d360e2ccb5949cf5b709b7c385353c762163e7c5d92074f511b57faf5a7517ece267d40f18005ca5402ce433004459cf73e9eb6932c5eba453f3
2)
cip client connection #1 (first data packet to game server):
Code:
81000a90837ced216f8fbdbf6ecea4075698c4457b0711ba60d49b92d30be5e8470c2efe1ad4d3cec945c18ca1360f02b2b471f3c879612fbe93e46b6002d34992751cec39305c6d7379a02481152a1fc9907e9541f33ab05eb1d55d76e78c5f8e94525461e814a6cc7f593581c5c1e6823250e449ade38ff419d3b7c98507039ba673
Code:
81000a648564e588bf5a50d13b17662cf7911c1252ae4888bde0a8f45dbdd3ec2879b194bbeab593fd8ff6eee2624a18d0120a1b9ff99cb095d3abb5bf4fa602e2cebd171b60392d680bfe0e1d65aaf8123c8afe1e339467f74a9c5692139c625162b8fd3468b0a83b1b637cd7ebfd52279db9e0a55ccd8d9ee38f1e855d1c9507cfc6
Code:
85000a0b00020342285b3113d3e3aa5b09c438dd1743a529f86d32aed6137890f059eb9ffc5f04655a9e7adec2588c5dc1344f0348314a84fb936451f8eeb21cad86ebfa7144a462d810cf146bbc486a8a7358880012a476cd239a253ffa2fca0320f34624f576274256a9eb79d8e9a9ce0c0ca2cb2cb09945f73d9ef21b7fbe94f2ee66ab688b
Code:
85000a0b0002032a1da88ec4de9cb4f2f2af50d7958cdceba1e0b3ec3bee55a4c993563f1119b72f514efb2be4dcdf38d29698e901aaee9e3d9dcc7af81604af29c378ca2323750560fa619485e8a20f485dd6fef8ae2ba57fa41305172a2ba0f21e6d7617ed648a6fd87129f98e57046adf94505665737c9223ec96129f61e6992e259fabb335
Interested in ideas, suggestions or solutions!
Last edited: