Insert link here.
I sniffed them,
credits to snow for his awesome sniffer.
I was bored and had nothing else to do.
Flame all you want.
P.S I'm Jionax, BleachFan in WoG and Kdev.(PM me for proof(in kdev and wog that is))
Insert link here.
I sniffed them,
credits to snow for his awesome sniffer.
I was bored and had nothing else to do.
Flame all you want.
P.S I'm Jionax, BleachFan in WoG and Kdev.(PM me for proof(in kdev and wog that is))
Sweeet saves me some time ty
Posted via Mobile Device
LMAO. Change your password. ^__^
Go ahead and take the account it's early/late birthday gift.
It has some nice items.
Last edited by ツ Ãlan™; 17-08-10 at 10:35 PM.
well it's not much of a use when you don't do it yourself, you don't know when exactly you get the unknowns now... just updating existing packets is possible.
Thanks ;) was about to do this myself
Here are some headers for v88:
To Server:
LOGIN_PASSWORD = 0x01
SERVERLIST_REREQUEST = 0x04
SERVERSTATUS_REQUEST = 0x06
SERVERLIST_REQUEST = 0x0B
PLAYER_LOGGEDIN = 0x14
PING = 0x19 // client sends ping now (?)
LOGIN_SCREEN = 0x24
VIEW_ALL_CHAR_REQUEST = 0x0D
To Client:
LOGIN_STATUS = 0x00
GET_USERNAME = 0x02
SERVER_STATUS = 0x03
SERVERLIST = 0x0A
CHARLIST = 0x0B
ENABLE_RECOMMENDED_SERVER = 0x1A
RECOMMENDED_SERVER = 0x1B
WARP_TO_MAP = 0x88
? = Questionable
Hello packet hasn't changed (iirc).
how to analysis those?![]()
loool this are the encrypted packets, gg
seems very useless, anyone can get those
Snow's sniffer has problems with decryption after it sniffs for a while unless you restart the crypto. There are better sniffers out there.
Anyone who could make use of this can sniff by themselves; that makes it easier as they know what ingame exactly they did and what they sniffed.
Especially v.88, only possible reason for a release is for an outdated version (such as Tespia v.89, which I coded a private server off of ^_^)
But yes, login packets did not change from 83->88/89, getHello has no reason to change it's entire structure whatsoever(other than the IV_PATCH_LOCATION which some of you guys can't seem to figure out, it's part of the structure) so I don't know why that needs to be talked about. Channelserver packets, almost all of them changed (87-88 was a big jump, many structure changes cause they copied from KMS again).
Last edited by RMZero213; 18-08-10 at 09:23 PM.
You got into Tespia? I wanted to be in Tespia, but I guess Nexon has a grudge against me!
I don't see anything regarding to an "IV_PATCH_LOCATION", or long enough to be a path location.PHP Code:Hex | Value | Desc.
----------------------------------
0E | 14 | message length
0058 | 88 | server version
0001 | 1 | unk
31 | 49 | unk
00000000 | 0, 0, 0, 0 | recv
00000000 | 0, 0, 0, 0 | send
08 | 8 | server state (test / regular)
----------------------------------
Depends if you have modified it or not. I can personally tell you there is a lot of pointless functions and function calls.
@LameJacob
Defining data structures isn't at all related to decryption.
However, decryption is a vital step because you need to do it in order to get the accurate data in the first place if the data were to be encrypted.
Yes, and I made a private server easily off of it.
PATCH, not PATH.
The 01 00 31 is a MAPLEASCIISTRING. It displays "1" (or "2", whatever)
This is part of the mapleVersion. Nexon releases "parts" of patches; so you may as well call the client 83.2 or 88.1. When there is no PATCH_LOCATION, it is just 00 00, which is STILL a STRING noting 0 length.
There you go, your unk problem is solved. Message length changes due to this string.
I have personally tested it myself and have seen some others confirm that it has a minor problem with decryption. It's not major but it's still a problem.
If you have modified it to not have that problem, congratulations and good for you, but that's not the sniffer I'm talking about.
Last edited by RMZero213; 19-08-10 at 03:46 AM.