[REQUEST]Packet Sniffing tutorial(ANALYZING)

Ok thx lesderd

Now i captured the packets for failed login to enzura server
By edxloader
look

Quote:

[S -> C][0FF1] 01 00 00 00 ................ 00 00 00 00 ................ [S -> C][A101] 01 ................ 02 ................ 14 00 ................ 53 69 6C 6B 72 6F 61 64 5F 53 72 65 76 6F 6C 75 Silkroad_Srevolu 74 69 6F 6E tion............ 00 ................ 01 ................ 01 00 ................ 06 00 ................ 45 6E 7A 75 72 61 Enzura.......... 01 00 ................ F4 01 ................ 01 ................ 00 ................ Failed login [S -> C][0FF3] 00 00 00 00 ................ 09 00 00 00

Is this is it ? Correct
but still dont know when server sends to client and when client sends to server

AFAIK, 0FF* packets are made by edxLoader and don't exist in the real sro.
If you only need LoginServer documentation, use this: [Only registered and activated users can see links. Click Here To Register...]

Quote:

Originally Posted by lesderid AFAIK, 0FF* packets are made by edxLoader and don't exist in the real sro. If you only need LoginServer documentation, use this: [Only registered and activated users can see links. Click Here To Register...]

Its really exist
look at A101
I put the packets of it in the quote and its in loginserver documination

also look
0FF1 is already exist

Quote:

GatewayInfo [2001] { [WORD] Length of GatewayServer Name [STRING] GatewayServer Name //GatewayServer [BOOL] Server Flag //0x00 is Client connection, 0x01 is Server connection }; HandShake [5000] { NoHandShake { [BYTE] 0x01 }

I think you cant really understand what analyzing & sniffing packets well

0xFFX packets are internal Silkroad packets specific to the client. What they do is take certain packets received and repost them internally so you can ignore them. They aren't from the loader though, just what Silkroad uses internally to communicate. They only show up because they are "parsed" like normal packets.

For packet analyzing before character selection, you need to use a proxy, like any of my edx33 tools. The auto-parser only shows packets from character selection on (server stats ends up getting parsed in some versions, but that's it). In addition, there are a few limitations to the auto parser when it comes to showing opcodes of the packets that are received in groups as well as opcode only packets

So in short, the auto parser shows you literally how the client parsed a packet. For exact packet ordering and correct opcodes, you have to use a proxy and get the data from there.

This (see pushedx's post) is why I said you should use my documentation for the LoginServer packets.

Thanks for explaining it pushedx, I didn't know the 'story' behind this.