napster messages ================ by drscholl@users.sourceforge.net August 6, 2000 0. Foreward This is meant to be an open specification. If you find errors or know of additional functionality not described hereafter, please send me email. It benefits the entire community to have a complete and accurate protocol specification. Not only does it allow for clients to be developed for any platform, but also decreases the strain on the server having to parse out bad client messages. Disclaimer: the following information was gathered by analyzing the protocol between the linux nap client and may not resemble the official Windows client protocol. 1. Client-Server protocol Napster uses TCP for client to server communication. Typically the servers run on ports 8888 and 7777. Note that this is different from the `metaserver' (or redirector) which runs on port 8875. each message to/from the server is in the form of where and are 2 bytes each. specifies the length in bytes of the portion of the message. Be aware that and appear to be in little-endian format (least significant byte goes first). For example, in the C language you would encode the number 1 as const unsigned char num[2] = { 0x01, 0x00 }; and 256 would be encoded as const unsigned char num[2] = { 0x00, 0x01 }; [The above is for illustrative purposes only, there are much quicker ways to actually encode a number. -ed] Note that in many cases, strings are passed as double-quoted entries. For example, filenames and client id strings are always sent as "random band - generic cowboy song.mp3" or "nap v0.8" Where required, double quotes are used in the description of the messages below. Some additional information about use of quotes inside of quotes: > The answer is, no, it doesn't do escaping of quotes. If you try searching > for the phrase 'a "quoted" string' on the windows client, you get no songs > found, and "invalid search request" printed in yellow in your console > window. (don't know what code that is, sorry.) > > and no wonder-- a little birdie told me that the client sends this: > > FILENAME CONTAINS "a "quoted" string" MAX_RESULTS 100 [contributed by Ben Byer . -ed] Note that unlike the IRC protocol, each line does NOT end in \r\n. The field specifies exactly how much data you should read. 2. Message Types The following section describes the format of the section for each specific message type. Each field is denoted with <>. The fields in a message are separated by a single space character (ASCII 32). Where appropriate, examples of the section for each message are given. can be one of the following (converted to big-endian): 0 error message [SERVER] Format: 2 login [CLIENT] Format: "" [ ] is the port the client is listening on for data transfer. if this value is 0, it means that the client is behind a firewall and can only push files outward. it is expected that requests for downloads be made using the 500 message (see below) is a string containing the client version info is an integer indicating the client's bandwidth 0 unknown 1 14.4 kbps 2 28.8 kpbs 3 33.6 kbps 4 56.7 kbps 5 64K ISDN 6 128K ISDN 7 Cable 8 DSL 9 T1 10 T3 or greater build number for the windows client [optional] Example: foo badpass 6699 "nap v0.8" 3 3 login ack [SERVER] Format: the server sends this message to the client after a succesful login (2). If the nick is registered, the address given at registration time is returned. If the nick is not registered, a dummy value is returned. 4 version check [CLIENT] Format: Server sends [5] if an update is needed. All other responses are ignored. = string, version 2.0b5a sends "2.0" 5 "auto-upgrade" [SERVER] Format: Napster is out of date, get a new version. Or also known as gaping security hole. = string, the new version number. = string, hostname of upgrade (http) server = string, filename Connections are always made to port 80. The HTTP Request: GET HTTP/1.0 Connection: Keep-Alive Host: Expected HTTP Response. Content-Length: Content-Type: Upgrade file is save as "upgrade.exe". And executed as: upgrade.exe UPGRADE "" As far as I can tell no confirmation is requested by Napster when it receives this message. And immediately start to "auto-upgrade". To keep users informed that Napster is doing something potentially very harmful to their computer it displays a message saying it's "auto-upgrading". I think this pretty bad, since all someone has to do is hack a napster server et voila a zillion clients at your disposal. As far as I known this only affects the Win32 2.0b5a Napster client. Other clients/versions I don't know. [This section was contributed by Thomas van der Heijden -ed] 6 new user login [CLIENT] Format: "" This message is used when logging in for the first time to register a new nickname. The client normally checks for an unused nick using the "check nickname" (7) message and upon receipt of a "nickname not registered" (8) from the server will proceceed to log in with this command. note: this message is similar to the 0x02 message, with the addition of on the end Example: foo foo 6699 "nap v0.8" 3 email@here.com 7 nick check [CLIENT] Format: Queries the server to see if is already registered. This message is typically used prior to logging in for the first time to check for a valid nickname. Response to this message is one of 8, 9 or 10 8 nickname not registered [SERVER] Format: (empty) The server sends this message in response to the "nick check" (7) message to indicate that the specified nickname is not already registered and is ok to use. 9 nickname already registered [SERVER] Format: (empty) The server sends this message when the nickname the client has requested has already been registered by another user 10 invalid nickname [SERVER] Format: (empty) This server sends this message in response to the "check nickname" (7) messages when the specified nickname is invalid, usually due to bad characters such as spaces or other non-printable characters. The Napster, Inc. servers only accept (upper- and lower-case) nicks comprised of the following: abcdefghijklmnopqrstuvwxyz1234567890_[]{}-@^!$ 11 ??? [CLIENT] Format: [returns "parameters are unparsable" -ed] 12 ??? [SERVER] Format: (empty) this message is returned in response to message 11 from the client 13 echo??? [SERVER] Format: : [args] Prior to issuing a login (2) command, the server will echo back the received numeric and any arguments of any commands it receives. 14 login options [CLIENT] NAME:%s ADDRESS:%s CITY:%s STATE:%s PHONE:%s AGE:%s INCOME:%s EDUCATION:%s Example: NAME: kev ADDRESS: CITY: ephrata STATE: pa PHONE: AGE: 60 or older INCOME: $100,000 or more EDUCATION: Graduate Degree 100 (0x64) client notification of shared file [CLIENT] Format: ""