) by mzvince (5.7 mon) (print)   ?   Sun Apr 28 2002 at 23:05:14

If you run a packet sniffer on WPNP (WinMX Peer Network Protocol) packets, it will soon become apparent that these packets are not transmitted in cleartext. For instance, search terms cannot directly be found in the packet stream.

The reason for this is that the packets are encoded using a simple XOR based algorithm. It cannot really be called encryption, since there is no key except packet length.

The encoding algorithm in question first xors the first byte with the last, then repeatedly xors a byte with its preceding byte, moving from the next-to-first byte to the last one, one byte at a time. This is done five times. The procedure varies slightly the first time, where the first byte is not XORed with the last byte, but rather with the packet[1] length.

In C:

void encode(char * what, unsigned int length) {

        int counter, x;

        for (counter = 4; counter >= 0; counter--) {

                if (counter != 4) what[0] ^= what[length-1];
                else              what[0] ^= (char)(length);

                for (x = 1; x < (int)length; x++) what[x] ^= what[x-1];
        }
}

and (for the sake of completeness)

void decode(char * what, unsigned int length) {

        int counter, x;

        for (counter = 0; counter < 5; counter++) {

                for (x = length-1; x > 0; x--) what[x] ^= what[x-1];

                if (counter != 4) what[0] ^= what[length-1];
                else              what[0] ^= (char)length;
        }
}


[1] or packet data length for some WPNP packets. See WPNP: Packet Types for more information about that.


thing) by mzvince (5.7 mon) (print)   ?   Sun Apr 28 2002 at 23:34:03

In WPNP there are basically two packet types above TCP/IP. The second packet type can have numerous "subtypes" indicating of what use that packet is, but that will be mentioned later.

The first packet type is that which a host cache will send. It is encoded, and simply contains a hostname in quad IP ASCII format followed by a colon and a port (e.g "127.0.0.1:3300"). It is not zero-terminated, and its length is given by TCP.

Connect to frontcode.com at port 7730 and wait for incoming data to get an example of this packet type.

The second packet type has got the following format:

 2 bytes: data length ("N"), little-endian
 ---- everything past this point is encoded ----
 2 bytes: packet subtype, little-endian
 N bytes: data

To decode the packet, one must start the decoding routine (which can be derived from the encoder at WPNP: Packet Encoding) at position 2 (skipping the first two bytes) and with length N+2 (N for data plus two for the packet subtype).

Most data is in clear text, separated by spaces.

The following subtypes has been found as of this time:

 2: Sent by a peer that logs in to another, and contains
 user name, password, client ("WinMX"), and some numbers
that have not yet been deciphered, separated by spaces. The
format is username, space, password, space, 0, space,
"WinMX" (with quotes), space, 8)

 3: Sent by the peer that listens to connections, as a 
response to packet subtype 2. Contains "nothing@nowhere.bla" 
as data (a fake e-mail address?).

 65494: Search request response. Contains file names and 
IDs of users that have the files.

Note that a peer may send multiple packets of the second type in a single TCP/IP packet. In this case, the length of the data returned by the recv function (in C) is going to be greater than N+4, and a new packet starts at that point.


To log in to a WinMX peer, first connect to one (get its IP by connecting to a host cache), then send 0x31 as the sole byte of a TCP packet, followed by "CLIE" (4 bytes) in another packet. After this, start transmitting and watching for type 2 packets, subtype 2(login) first.


