Protocols/MSNP/MSNP8/Challenges

From NINA Wiki
Jump to navigation Jump to search
MSNP Protocol
Version 8
General
OverviewGlossary
Payload CommandsNames
Bitwise AND
Connecting
AuthenticationPresence
ChallengesGetting Details
Setting DetailsMessages
Miscellaneous
Example Session
Messaging
AuthenticationMiscellaneous
MessagesExample Session
Overview
IntroductionTermsClients
Reference
Error ListCommandsRelying Party SuiteSpotlife
Services
XMPPHTTP GatewayTabsActivities
Documentation
Development ToolsMSNP Grid
PolygamyURLs used by MSN
Documents
Protocol Versions
Version 21
Version 18
Version 16
Version 15
Version 14
Version 13
Version 12
Version 11
Version 9
Version 8
Version 2
MSNC
IntroductionP2PObject DescriptorDisplay PicturesFile Transfer
Scenarios
Microsoft Messenger for Mac
MSNP on WebTV (MSNTV)


Server Pings (Challenges)

Pings from the server are sent with the CHL command. They are often referred to as challenges, because that is a good possibility as to what the three letter code stands for.

Challenges are sent by the NS from time to time, the first one shortly after the initial status has been set with CHG. There's no regular period to the time between CHLs. They include two parameters - the first is always "0", the second is the "challenge string". This has always been a 20-digit number, but a client shouldn't rely on that. A challenge might look something like this:

<<< CHL 0 15570131571988941333\r\n

When you receive a challenge, you must send a QRY command to the server within about 50 seconds or you'll be disconnected. QRY is a payload command with a TrID and two parameters: a client identification string and the number of bytes in the payload. As with all payload commands, the length is be followed by a newline, then the payload, which is not followed by a newline. In MSNP8 the payload of the QRY command is the "MD5 digest" of the challenge string and a client identification code. MD5 digests are always 32 bytes in length.

If you sent an invalid client code or incorrect digest, the server will send error 540 and close the connection. If you get the payload wrong, the results will be hard to predict and not good. Otherwise, the server will send a QRY response with the same TrID and no parameters.

Client identification information

Different Microsoft clients use different ID codes and ID strings. Here is a list of the strings and their corresponding strings:

Client ID string Client ID code
msmsgs@msnmsgr.com Q1P7W2E4J9R8U3S5
PROD0038W!61ZTF9 VT6PX?UQTM4WM%YR
PROD0058#7IL2{QD QHDCY@7R1TB6W?5B
PROD0061VRRZH@4F JXQ6J@TUOGYV@N0M
PROD00504RLUG%WL I2EBK%PYNLZL5_J4
PROD0076ENE8*@AW CEQJ8}OE0!WTSWII

It doesn't matter which ID string you use, but you must use the corresponding ID code - for example, you can't use msmsgs@msnmsgr.com with VT6PX?UQTM4WM%YR.

MD5 digests

MD5 is a message digest algorithm. Taking the MD5 digest of a string gives you a 32 byte "fingerprint" of it. If possible, you should try to find a library or an external program that creates MD5 fingerprints, but it's is officially described in RFC 1321, so you can try to implement it yourself if you're feeling brave. Make sure that your library can produce lower-case hexadecimal digests (there should be an option for this)

When the server gives you a challenge string, add your client code onto the end of it. For example, if the server gives you abcdefg and your code is 1234567, the input to the MD5 function should be abcdefg1234567. The hexadecimal digest for abcdefg1234567 is d1713d0f1d2e8fae230328d8fd59de01. I suggest you check your implementation using this example.

Example

Here is an example server ping and reply. You should check that your MD5 implementation against this example to make sure that you're encoding correctly. The most common mistake is to add a newline to the end of the challenge string before or after encoding it.

<<< CHL 0 15570131571988941333\r\n
>>> QRY 1049 msmsgs@msnmsgr.com 32\r\n
    8f2f5a91b72102cd28355e9fc9000d6e (no newline)
<<< QRY 1049\r\n

In this case, you would take the hexadecimal digest of 15570131571988941333Q1P7W2E4J9R8U3S5 which happens to be 8f2f5a91b72102cd28355e9fc9000d6e, and of course is 32 bytes long.