Connecting To The WPN

The connecting method WinMX clients use is called a "peer cache". This is a method of passing a quantity of node addresses to clients requesting them after this has occurred the peer cache disconnects the client and takes no further part in that clients operations.

This info guide will cover the secondary client connection method to the WPN, a primary guide is in the works but for now we will look over the more common type of connection method, using publicly available source code.
For the purposes of this overview we shall assume the WinMX client is using peer cache ports 7950-7952 to connect on an old Frontcode peer cache IP (

Visual display of the interaction between peer cache and secondary client

Lets look at the initial connection.
The secondary client initiates a connection to the peer cache using the cache IP and port mentioned above.

The peer cache accepts a connection from the requesting secondary client and replies with a "8" (hex38)

The client, having received the required response(38) now proceeds to sends an encryption key plus a client ID to the peer cache, generated by using the following formula.

(IN)  Crypt Key ID
    pBlock   : (OUT) Key Block ( 16 bytes )

    BYTE KeyBlock[16];
    CreateCryptKeyID(WPN KEY ID, KeyBlock);

Here is a list of WPN client ID,s used on the network.

Please Note : using an incorrect ID Key for secondary may result in the wrong segment of the code table being used and the resulting decryption will likely be unintelligible traffic.

The peer cache replies to this with its own encryption key to the client (16 bytes also ), these swapped keys are "seeds" for generating new up and down keys that will change each time you send or receive something, this is a popular method of "chaining" the clients together so non WPN clients will not be able to either connect or make sense of WPN Traffic.

The peer cache server now sends down a list of valid primaries IP,s from the cache in blocks of 10, using its encryption key generated using client ID 54. The client will have to start using the swapped encryption keys to make sense of the encrypted node list of course, a nice security feature.

A code flow diagram using client side code

Here is the actual code represented above in source code form and is taken from RoboMX 1.50 from the MxControl Project, which you can obtain from here.

BOOL CWPNPClient::GetParentNode(PARENTNODEINFO *pNodeInfo)

if(!pNodeInfo) return FALSE;

char buffer[512] = {'\0'};
BYTE *pNodeBuffer = (BYTE *)buffer + sizeof(buffer) / 2;
int i = 0, j = 0, nFree = 0;
TCHAR szHostName[256] = {'\0'};
WORD wHostIndex = 0;
WORD wPortIndex = 0;

m_bKeepLogin; wPortIndex--){

m_bKeepLogin ; wHostIndex++){

wsprintf(szHostName, FRONTCODEHOSTNAME, wHostIndex);

if(!m_mPeerCacheSock.Connect(szHostName, wPortIndex, 5)){

// We failed to connect. use alternate port

if(m_mPeerCacheSock.Recv(buffer, 1, 5) != 1)continue;
if(buffer[0] != 0x38)continue;

if(m_mPeerCacheSock.Recv(buffer, 16, 5) != 16)continue;
if(GetCryptKeyID((BYTE *)buffer) != 0x54)continue;

// Get free nodes
if(m_mPeerCacheSock.Recv(buffer, 132, 5) != 132)continue;


// Decrypt Node Information
DecryptFrontCode((BYTE *)buffer, pNodeBuffer);
memcpy(pNodeInfo, pNodeBuffer, 120);

// Sort by Free Secondary Num
for(j = 0 ; j < 9 ; j++){

nFree = j;

for(i = j + 1 ; i < 10 ; i++){

if(pNodeInfo[i].bFreeSec > pNodeInfo[nFree].bFreeSec ||
(pNodeInfo[i].bFreeSec == pNodeInfo[nFree].bFreeSec &&
 pNodeInfo[i].bFreePri < pNodeInfo[nFree].bFreePri)){

nFree = i;

pnFreeNode = pNodeInfo[j];
pNodeInfo[j] = pNodeInfo[nFree];
pNodeInfo[nFree] = pnFreeNode;

// Retry if No Free Parent Node


return TRUE;

return FALSE;

I hope the information shown here has made sense of some of the operations necessary when connecting to the WPN, my apologies for any errors or omissions, please let me know if you find any.

Please join with me in thanking both Nushi@2SN and Bender@MxControl for the use of the code shown, my eternal thanks to you both.

©2005-2017 All rights reserved. Page last updated Thu Jan 14 2016