[Help] IPV4 byte structure before and after encryption

IPV4 byte structure before and after encryption

Can someone help me understand what is actually happening to the bytes in the packet buffers I get when I begin listening for Realm traffic?

When I started on this project I fully expected to be receiving packets with encrypted bytes that looked like gibberish unicode characters, but that is not the case. The bytes are coming as nice integers that do not look to be encrypted to the naked eye.

What I have:

All of the packets on port 2050
packets seperated by incoming/outgoing
The bytearrays for each of the packets

How do you handle decrypting the byte array?
Byte by byte or all bits.tostring then back to bytes?

Bytes. You decrypt bytes as bytes, you get bytes.
Especially when you deal with packets (== not mean for "reading")

Its up to you to know how to read data from those decrypted bytes (and it depends on the packet type

)
Rotmg packets are like this
* length
* type (short)
* data

Try do decrypt an hello packet and write decrypted bytes to a file, you'll see

The structure is
int32 length, byte id, encrypted bytes[length].

Originally Posted by JustAnoobROTMG

Bytes. You decrypt bytes as bytes, you get bytes.
Especially when you deal with packets (== not mean for "reading")

Its up to you to know how to read data from those decrypted bytes (and it depends on the packet type

)
Rotmg packets are like this
* length
* type (short)
* data

Try do decrypt an hello packet and write decrypted bytes to a file, you'll see

Originally Posted by krazyshank

The structure is
int32 length, byte id, encrypted bytes[length].

Thanks you two for your help! I was analyzing the packets using an IPv4 diagram rather than a TCP diagram. I decided to writhe the packets out to .txt files as you suggested to figure out what was going on.

First Outgoing Packet:

Code:

Length: 66
64	F	29	A	84	B1	$$	$$	$$	$$	$$	$$	8	0	45	0
0	34	42	99	40	0	80	6	92	9A	C0	A8	1	40	36	DB
2C	CD	CC	6B	8	2	88	3D	3F	88	0	0	0	0	80	2
20	0	8E	1A	0	0	2	4	4	EC	1	3	3	2	1	1
4	2

Verifying my output against wireshark for the same packet, it appears that:

Header:
red = Destination -> 6 bytes
blue = Source -> 6 bytes
pink = Address type (IPv4) -> 4 bytes
orange = Packet Length (66 bytes) -> 2 bytes
cyan = packet ID -> 2 bytes

Data:
black = remaining 46 bytes

One more Question.
How is 0x4299 converted to a short?
17046 does not correspond to any packet id.

Can i see your code ?
Because even if i have an error on data length, packet type is good (10 aka hello in the current build).
And error on data length...Damnit, Endian again.

When we talk about ROTMG "packets", we are only refering to the interesting part of the network packets (transported data).
We are not dealing at all with Ethernet/TCP headers.

Just use Tcplistener (to listen on local 2050 port) , and TcpClient.GetStream() .

Then use BinaryReader to read interesting data (len, type, etc...) from the stream

yeah, its definitly an endian problem.

Code:

        private void pumpProcess(object state)
        {
            uint len = 0;
            int type = 0;

            try
            {
                while ( true )
                {
                    sendAllPackets();

                    len = endianConvert(_recvFrom.ReadUInt32());
                    type = _recvFrom.ReadByte();

                    byte[] buf = ( len - 5 > 0 ) ? _recvFrom.ReadBytes((int) len - 5 ) : new byte[ 0 ];
                    byte[] decr = Cipher.rc4( buf );

                      addPacket(
                        notifyReceived( PacketParser.Wrap( type, decr ) ), 
                        decr 
                    );
                }
            } catch( IOException)
            {
                Console.WriteLine("Type : {0} , Length : {1}", type, len);
            }

            _recvFrom.Dispose();
            _replyTo.Dispose();
        }

 private uint endianConvert(uint value)
        {
            return BitConverter.IsLittleEndian ? BitConverter.ToUInt32( BitConverter.GetBytes( value ).Reverse().ToArray(), 0 ) : value;
        }

Dont forget to reverse bytes again when sending the packet

So I think what I am understanding is that:
1. There are three data layers Ethernet:IPv4:TCP
2. I can scrap the Ethernet layer once the packets are filtered in/out
3. First 4 bytes of the IPv4 layer define the length and packet id. 2 bytes (short) for each? Something may need to be reversed here.
4. Everything after those 4 bytes needs to be decrypted using the RC4 hex strings

HelpIPV4 byte structure before and after encryption

Post a Reply

Similar Threads

Tags for this Thread