HGKeeper

# MySpaceIM

> **NOTE:** The MySpace IM network has been shut down.

## Introduction

This document is a reverse-engineered protocol specification for

[MySpaceIM](http://www.myspace.com/im). The first version of this document was

created for build 673, but as of 2007-06-02 it refers to build 697 or newer.

This page is a known to be incomplete. It was originally started started by

User:jeff, residing at http://developer.pidgin.im/wiki/MsimProtocolSpec . An

older HTML version of this document is available.

Some text in italics refers to

[msimprpl](http://developer.pidgin.im/MySpaceIM), the MySpaceIM protocol plugin

for libpurple.

Contributions to this document are welcome!

## Servers

*msim_login*

Connect to im.myspace.akadns.net, which will point you to one of several MSIM

servers (currently 204.16.33.139-195).

69 - 74 connection attempts are allowed (usually 69) until the server will

block you out for a period of time.

All connections are made using TCP. The default port is 1863, but the client

will try to connect using ports 6660,6661,6662,6665,6668,6669,0080 and 0443 in

succession if 1863 fails. If successful, the port will be stored (the Win32

client uses `HKCU\Software\MySpace\IM\LastConnectedPort` in the registry) and

tried first for future connections.

## User Identifications

Users are identified by several means:

* User ID (uid) - unique number; used extensively by protocol. User's web page

at http://myspace.com/user_ID.

* Email address - used to sign in, and locate buddies.

* Username/IM Name - "Your unique name that can't be changed", shown on buddy

lists, and for user's web page at http://myspace.com/username.

* Display Name - shown on your web page, can be changed and non-unique.

* First Name and Last Name - "private and used for search only".

## Message Structure

*MsimMessage*

Tokens are separated by backslashes, which alternate as name, value, name,

value, etc. For example, this message:

```

\k1\v1\k2\v2\xxx\yyy\final\

```

contains the following information:

Key | Value

--- | -----

k1 | v1

k2 | v2

xxx | yyy

The end of a message is marked with \final\. Note that this marker is not a

key/value pair.

Special characters are escaped with '/':

Character | Escaped As

--------- | ----------

/ | /1

\ | /2

*msim_escape*, *msim_unescape*

The following data types can be defined:

Type | Description

---- |------------

Integers | These are just stored as ASCII, decimal

Text | ASCII

Binary | Base64 encoded

Boolean | Presence of the key indicates 'true', absense 'false'

Dictionary | Multiple key=value's, separated by \x1c

What I call here *dictionaries* (also known as associative arrays, hashes) are

often present in a field named body. Keys inside a dictionary use CamelCase and

boolean values are represented as a string, True or False, instead of the

absence of presence of a key.

Escape codes in dictionaries:

Character | Escaped As

--------- | ----------

' or ` | '

# | #

" | "

Escape codes in '|' delimited lists:

Character | Escaped As

--------- | ----------

/ | /1

\ | /2

## Login Sequence

*msim_login*, *msim_process*, *msim_login_challenge*

Upon connection, server immediately sends a "login challenge" message to the client:

Key | Type | Description

--- | ---- | -----------

lc | integer | 1

nc | binary | 0x40-byte nonce

id | integer | 1

Client sends login challenge response:

Key | Type | Description

--- | ---- | -----------

login2 | integer | 196610

username | text | Email address to login using

response | binary | Challenge response, derived using algorithm described below

clientver | integer | 673, corresponds to 1.0.673.0 in "About" dialog (679, etc.)

reconn | integer | 0

status | integer | 100

id | integer | 1

Server replies with:

Key | Type | Description

--- | ---- | -----------

lc | integer | 2

sesskey | integer | Session key

proof | Same as userid? Sometimes differs.

userid | Numeric userid

profileid | Same as userid?

uniquenick | Username

id | integer | 1

The session key is sent by the client in almost every future message.

Errors:

Code | Message | Type

---- | ------- | ----

259 | The supplied email address is invalid. | Fatal

260 | The password provided is incorrect. | Fatal

Code 260 is no longer used if trying to login with an invalid email address,

circa client build 404. Instead, invalid email and invalid passwords both

return code 260. See

[MySpaceIM Info Disclosure: Silently Fixed](http://www.planb-security.net/2006/09/myspaceim-info-disclosure-silently.html)

### Challenge/Response Login Algorithm

*msim_login_challenge*

response is computed from:

* First 0x20 bytes of nc field -- nc1

* Last 0x20 bytes of nc field -- nc2

* User's password, in UTF-16 little endian (only the first 10 characters, in

lower case)

* User's ASCII email address

Compute SHA1(SHA1(password) + nc2). This will result in 0x14 bytes. Using the

first 0x10 bytes (128 bits) as an RC4 key, encrypt the following concenated

together:

* nc1

* User's ASCII email address

* Four zero bytes: 00 00 00 00

* 1 byte = number of network interfaces on this machine

* IPv4 address of interface used to connect to server in network order.

Example: \x7f \x00 \x00 \x01 (for 127.0.0.1)

* IPv4 addresses of host's network interfaces in network order. Example: \x0a

\x00 \x00 \x40 (for 10.0.0.64), \xc0 \xa8 \x58 \x01 (for 192.168.88.1), and

so on.

The network interface addresses are obtained using the Win32 GetIpAddrTable API call. They should be the actual interface IPs on the system, even if they are RFC1918 private addresses. The server most likely uses these addresses to determine if a connection can be directly initiated to the host, or if it must pass through some kind of NAT device.

High-level summary:

```

response = RC4encrypt(key=hash(hash(pw) + nc2), data=nc1+username+IP_list)

```

## Buddy Messages

*msim_send_bm*

Messages from client or server:

Key | Type | Description

--- | ---- | -----------

bm | integer | Message type.

sesskey | integer | Session key.

t | integer | Userid to send message to (outgoing messages only).

f | integer | Userid message came from (incoming messages only).

date | integer | For offline messages, timestamp of when message was sent, Unix time

cv | integer | Client version build number.

msg | text | Text of message.

Known message types for bm:

Value | Notes | msg

----- | ----- | ---

1 | Instant message | See markup below.

100 | Status message | List, see below.

121 | Action Message | Zap or typing notification.

122 | Media Message | Key/value pairs joined by ampersands, see below.

124 | Profile Message | Contains age, song, gender, display name, headline, etc.

126 | Status Mood Message | Contains Status mood information

Servers appear to pass all buddy messages between clients, even if the type

('bm' field) is unrecognized. The

[Miranda IM plugin](http://forums.miranda-im.org/showthread.php?p=122912) uses

bm code 200 to "send miranda + plugin version information as is done with many

other protocols".

### Instant Messages

*msim_incoming_im*, *msim_send_im*

Message text is formatted using "tags", similar to HTML, and (aside from the

escaped forward slashes) is valid XML. Tags and attribute names are single

letters to save space. Attributes are either quoted with ' or backquote. For

unknown reasons, the client uses ' but the server translates it to the

backquote.

Tags end as in HTML: `<tag>...</tag>` (appears in protocol dumps as `< /1tag>`,

because `/` is encoded as `/1`).

Example:

```

<f f='Times' h='16'><c v='black'><b v='white'>hello</1b></1c></1f></1p>

```

Known tags:

* `<p>` = paragraph

* `<a>` = anchor (link)

* h = href

* This tag is self-closed, for example: `<a h='http://google.com' />`

displays http://google.com. It doesn't seem to be possible to change the

text of the link.

* `<f>` = font tag

* f = font face (Arial, Arial Black, Comic Sans MS, Courier New, Tahoma,

Times, Verdana, or another)

* h = font height, in pixels. For displays set to 96 DPI:

* 4pt = 5 (sizes must be between 4 and 72 points)

* 5pt = 7

* 6pt = 8

* 7pt = 9

* 8pt = 11

* 9pt = 12

* 10pt = 13

* 11pt = 15

* 12pt = 16

* 13pt = 17

* 14pt = 19

* 15pt = 20

* 16pt = 21

* 17pt = 23

* 18pt = 24

* 72pt = 96

* Note: 1 pt = 1/72 inch, and 1 inch = 96 pixels (at 96 dpi), so height

= round((96/72.)*point_size).

* Note 2: At 120 DPI, 72pt is sent as h=120, and so on. Points are

always 1/72 ", so the real formula is height =

round((DPI/72.)*point_size). For more information on font sizes, see

this Planet SoC blog post: Week 7 Updates: Notifications and Font

Sizes

* s = bit field of text decoration; add/OR together:

* 1 = bold

* 2 = italic

* 4 = underline

* `<c>` = text color tag

* v = color (a name like "black", "white", or "rgb(253,0,0)",

"rgba(253,0,0,100)" (alpha), or "transparent")

* `<b>` = background color tag

* v = color

* `<i>` = image (emoticon/smiley)

* n - name: bigsmile growl mad scared tongue devil happy messed sidefrown

upset frazzled heart nerd sinister wink geek laugh oops smirk worried

googles mohawk pirate straight kiss

Known character entities:

Character | Entity

--------- | ------

" | "

& | &

' | '

< | <

> | >

### Incoming Status Message

*msim_status*

Examples:

* |s|0|ss|Offline

* |s|1|ss|:-)|ls||ip|0|p|0

Index | Type | Description

----- | ---- | -----------

0 | text | s

1 | integer | 0 for offline (or hidden), 1 for online, 2 for idle, 5 for away

2 | text | ss

3 | text | Headline

4 | text | ls

5 | text |

6 | integer | 0

7 | text | p

8 | integer | 0

### Action Message

*msim_incoming_action*, *msim_send_typing*

Zaps are, in order (0-9): zap whack torch smooch hug bslap goose hi-five punk'd

raspberry. Zaps are sent with this msg:

* !!!ZAP_SEND!!!=RTE_BTN_ZAPS_n, where n is a 0-based index into zap array.

For typing notifications:

* %typing%

* %stoptyping%

#### Group Messages

*Trac ticket*: http://developer.pidgin.im/ticket/4691

Group messages seen coming from http://myspace.com/78744676 (or

http://myspace.com/myspaceim), a chatroom added to the buddy list by default:

* GroupCount=25;

* Offline= (someone's user ID)

* MsimMarkup-formatted messages

* ContactType=2

These messages also had:

Field | Type | Description

----- | ---- | -----------

f | integer | Chatroom ID, for example 78744676

cv | integer | Client version, build 1000

gid | integer | Group ID? 23

aid | integer | User ID of person talking in that chatroom, if applicable

When a user talks in a chatroom, f is set to the user ID of a user representing

the chatroom, and aid is set to the user ID of the user talking. Not sure how

gid fits into this. You appear to get chatroom messages if the chatroom user is

on your buddy list, even if you haven't joined the chatroom. (Note: need to

figure out terminology here, I've been using chatroom but MySpaceIM uses the

term 'group').

### Media Messages

*not implemented*

bm of 121 is used to send media.

Seems to be sent when someone first messages you. Example transcript:

```plaintext

(05:31:51 PM) someone: cmdtype=1&reqid=856000425340460813&contenttype=1&

(05:32:01 PM) someone: Hello

(05:32:04 PM) me: hi there

(05:32:07 PM) someone: cmdtype=1&reqid=856000425340466400&contenttype=1&

(conversation continues)

```

Sending background picture:

```

cmdtype=3&reqid=15704865745410042&contenttype=1&

```

Picture (less than 600K) invitation request:

```

cmdtype=4&reqid=15704865745421128&contenttype=4&filename=Winter.jpg

```

If picture is not accepted, or offer canceled:

```

cmdtype=5&reqid=15704865745413631&contenttype=4&accept=no

```

cmdtype

Code | Description

---- | -----------

1 | ??? Sent initially

3 | Send background image

4 | Picture invitation request

5 | Accept/deny picture invitation request

### Profile Message

This message contains information on the buddy from their profile. Sometimes it

is empty, sometimes it contains the following dictionary-encoded keys:

Name | Type | Description

---- | ---- | -----------

Age | integer | Age in years

AvatarURL | string | URL of avatar

BandName | string |

SongName | string |

ContactType | integer | 2

DisplayName | string |

Gender | string | M or F

Headline | string |

ImageURL | string | URL of JPEG image on MySpace Content Distribution Network

IMName | string | Instant messaging name, blank if user doesn't have MySpaceIM

UserName | string |

RoomLastLogin | integer |

Location | string | city, state, country

ShowAvatar | boolean | True or False

Example:

```plain

\bm\124\f\78744676\msg\Age=27AvatarUrl=BandName=cold war kidsContactType=2DisplayName=MySpaceIMGender=FHeadline=ImageURL=http:/1/1a895.ac- images.myspacecdn.com/101111/149/186/11111986894_m.jpgIMName=MySpaceIM Chat RoomLastLogin=128287884600000000Location=SANTA MONICA, California, USShowAvatar=FalseSongName=Hang Me Up To DryTotalFriends=119814UserName=myspaceim\final\

```

## Set Status Messages

To change your own status:

Key | Type | Description

--- | ---- | -----------

status | integer | Status code.

sesskey | integer | Session key.

statstring | string | User-settable status message (for online or away).

locstring | string | Location string? Sometimes "userinfo;"

Status codes:

Code | Description

---- | -----------

0 | Hidden/offline

1 | Online

2 | Idle

5 | Away

Unknown codes (tested 3, 4, and 6) are recognized as offline by the official

client.

Same code as in incoming status messages.

## Keepalives

From server:

Key | Type | Description

--- | ---- | -----------

ka | boolean | Presence indicates this is a keepalive message.

Sent every 3 minutes to keep connection alive.

## Add Buddy

*msim_add_buddy*

Key | Type | Description

--- | ---- | -----------

addbuddy | boolean | Presence indicates to add buddy.

sesskey | integer | Session key.

newprofileid | integer | Userid to add.

reason | text | Empty

The client also sends a persist message to update the buddy list. Example

sequence (after looked up userid), adding uid 6221:

* \addbuddy\\sesskey\420159774\newprofileid\6221\reason\\final\ - add buddy

* \blocklist\\sesskey\420159774\idlist\b-|6221|a+|6221\final - update blocklist

* \persist\1\sesskey\420159774\cmd\514\dsn\0\uid\180301984\lid\9\rid\31\body\ContactID=6221.GroupName=IM Friends.Position=1000.Visibility=1.NameSelect=0\final\ - update contact info

Errors:

Code | Message | Type

---- | ------- | ----

1539 | The profile requested is already a buddy. | Non-fatal

## Delete Buddy

*msim_remove_buddy*

Key | Type | Description

--- | ---- | -----------

delbuddy | boolean | Presence indicates to delete buddy.

sesskey | integer | Session key.

delprofileid | integer | Userid of buddy to delete.

The client also sends a persist message and updates the block list when deleting a buddy. Example message sequence:

* \delbuddy\\sesskey\97309878\delprofileid\175349942\final\ - delete buddy with numeric ID 175349942

* \persist\1\sesskey\97309878\cmd\515\dsn\0\uid\3656574\lid\8\rid\18\body\ContactID=175349942\final\ - delete from on-server buddy list?

* \blocklist\\sesskey\97309878\idlist\a-|175349942|b-|175349942\final\ - update block list; remove user (-) from accept (a) and block (b) list?

## Block List

*msim_add_buddy updates the blocklist, not implemented: User-settable

blocklists.*

Key | Type | Description

--- | ---- | -----------

blocklist | boolean | Presence indicates to change block list.

sesskey | integer | Session key.

idlist | list | Encoded list of buddies to block/unblock, see below.

`idlist` is constructed from one of the following format strings:

* a-|%lu|b-|%lu

* a-|%lu|b+|%lu - block userid %lu

* b-|%lu|a+|%lu - unblock userid %lu

where %lu is the userid. Current guess is that a is for accept list, b is for

block list, - removes and + adds, but this has not been proven. Example idlist,

when "Who can contact me: Anyone" and "Who can see when I'm online: Anyone" is

set:

* w0|c0|a-|*|b-|*|b+|blockeduser1...

Removes all users from accept list and block list, then adds blockeduser1

(userid).

If "Who can contact me: Only people on my Contact List" and "Who can see when

I'm online: Anyone", then idlist is:

* w0|c1|a-|*|a+|buddy1|buddy2|...|buddyN|b-|*

where buddyN is the userid of each buddy on the contact list. |a-|*| removes

all users from the accept list, |a+|...| adds only buddies to accept list,

|b-|* removes all buddies from blocklist.

Opcodes:

* w# = Who can see when I'm online? 0=Anyone, 1=Only people on my contact list

* c# = Who can contact me? 0=Anyone, 1=Only people on my contact list

* a- = remove from accept list

* a+ = add to accept list

* b- = remove from block list

* b+ = add to block list

* \* = all userids

## Get Info

Key | Type | Description

--- | ---- | -----------

getinfo | boolean | Presence indicates that this is a get info request.

sesskey | integer | Session key.

uid | integer | Userid to look up.

Examples:

```

\getinfo\\sesskey\53348262\uid\6221\final\

```

\getinfo\\sesskey\70517308\uid\180301984\final\

```

Specifics of this message's purpose are unknown.

See also the 1,0,2 persist message (they're often sent together).

## Set Info

Key | Type | Description

--- | ---- | -----------

setinfo | boolean | Presence indicates that this is a get info request.

sesskey | integer | Session key.

info | dictionary | Packed dictionary of information to set.

'info' dictionary has same fields as setinfo. Examples:

```

\setinfo\\sesskey\70517308\info\Age=20AvatarUrl=BandName=ContactType=1DisplayName=MySpaceIM Protocol Plugin for PidginGender=MImageURL=http:/1/1a513.ac-images.myspacecdn.com/1images01/118/1m_0ad6cfe1ae4b676622e98c6d4cb3cef0.pngLastLogin=128290072800000000Location=California, USShowAvatar=FalseSongName=TotalFriends=4UserName=msimprpl\final\

```

## Web Challenge Request (webchlg)

Key | Type | Description

--- | ---- | -----------

webchlg | boolean | Presence indicates a web challenge request.

sesskey | integer | Session key.

n | integer | 0, unknown.

imfreedom/knowledgebase