ZoRoNaX' blog

ZoRoNa's profileZoRoNaX' blogBlog

Tools

Help

Blog

12/19/2006

Windows PE 2.0 + .NET Framework 2.0

After playing around with Windows Vista, I decided to look into Windows PE 2.0 (it's based on Windows Vista). Having worked with it for a couple of days, I can say that Windows PE 2.0 is so much better than Windows PE 1.*. As a result I was able to fully integrate the Microsoft .NET Framework v2.0.50727, with the size of the image being increased by only 24MB! (uncompressed the Microsoft .NET Framework 2.0 takes about 70 MB) That just totally rocks!

On the included screenshot you can see that it is able to run an application with Windows Forms and Reflection without any problems at all.

11/4/2006

Restore Live Messenger Custom Content

The Windows Live Messenger team recently gave out a new build of Windows Live Messenger 8.1, which included a couple of fixes to the new Object Store. As Windows Live Messenger 8.1 BETA testers might have noticed, if you upgrade from version 8.1.006x to 8.1.0106 you will lose some custom content (like display pictures, custom emoticons, winks, etc.) which has been installed while using version 8.1.006x. The Messenger team does not and will not support custom content migration from version 8.1.006x to 8.1.0106, so Windows Live Messenger 8.1 BETA testers are pretty screwed on that.

Because I experienced that problem, I created a tool which migrates the custom content installed in version 8.1.006x to the proper format of version 8.1.0106. This tool does not delete any of the data already present, it only adds the missing items. To be able to restore the missing data, you need to provide the tool the Passport address and the Unique Passport ID of the account to process. The Unique Passport ID is a string of 16 characters long, including the leading zeros. You can find your Unique Passport ID on the Windows Live Account Settings page, which you can find at https://account.live.com/SettingsPage.aspx.

This tool DOES NOT migrate custom content that was added in Windows Live Messenger 8.0 and is not visible in Windows Live Messenger 8.1!

Special thanks

Rafael (testing and mirror 01)

Stephen (testing)

Inky (mirror 02)

Download: Mirror 01 // Mirror 02

Release Notes

Windows Live Messenger 8.1.0106 BETA Custom Content Migration Tool
//////////////////////////////////////////////////////////////////

This tool migrates custom content that was added in Windows Live 
Messenger version 8.1.006x and is not visible in build 8.1.0106.


Changelog
/////////

Revision 0 (version 1.0.0.0)
- Initial release


Usage
/////

1. Extract archive contents into a directory.

   (NOTE: Original executable CRC32 is 7662F520)

2. Execute objmig.exe in a command-prompt window and provide the 
   Passport address and Unique Passport ID.

Notes
/////

This tool DOES NOT migrate custom content that was added in 
Windows Live Messenger 8.0 and is not visible in Windows Live 
Messenger 8.1!!

The Unique Passport ID is a string of 16 characters long, 
including the leading zeros. You can find your Unique Passport ID 
on the Windows Live Account Settings page, which you can find at 
https://account.live.com/SettingsPage.aspx.

You can view help text by executing objmig.exe without arguments.


Credit
//////

ZoRoNaX
http://zoronax.spaces.live.com/

10/8/2006

Windows Vista boot screen customization

Until Windows Vista, one had to change the resources of ntoskrnl.exe to modify the boot screen. Modifying the ntoskrnl.exe executable is, of course, is very sensitive to human error which could render your Windows installation useless. With Windows Vista, the Windows loading process has been overhauled. For example, boot-time graphics were relocated, new native-mode boot-time applications added (winload.exe, winresume.exe) and all critical kernel components have received a digital signature. Because of the digital signatures, tampering with the kernel is no longer possible. Has the customization of the boot graphics come to an end? NO!

Multilingual User Interface files

With Windows Vista, Microsoft provides new functionalities in the Multilingual User Interface (MUI) area. This new functionality allows developers to separate localized resources (e.g. text strings) from language independent resources (e.g. bitmaps, icons, cursors). Typically, the separate .mui file contains the localized resources and the application executable contains the language independent resources. Just as with any .dll or .exe, a .mui file is just a normal Win32 portable executable (PE) stripped of executable code. On Windows Vista, the Win32 resource API functions have been modified to load resources from the .mui files automatically. Because the loading of resources happens independently of the application, it doesn't matter if the resource is located in the application executable or in a .mui file. The resource loading process can be seen as the following: First, the resources located in the applications executable are loaded into the memory. Afterwards, the system decides which .mui file to use (based on the language) and loads the resources from the .mui file on top of the previously loaded resources, replacing any resources that already exists! If a resource exists in a .mui file it will be loaded from the .mui file, but if a resource doesn't exist in a .mui file, the system loads it from the application executable resources if it exists there. But what does this MUI stuff has to do with boot screen customization? Everything!

Boot screen customization

Because .mui files don't have a digital signature, its resources can be modified without problems. So if one wants to replace a resource in a digitally signed executable, one can add the resource to the .mui file (or replace it in the .mui file if the resource exists there). That's exactly what we'll do to customize the Windows Vista boot screen, so grab your favorite Win32 resource editing tool and let's start! If you don't know which tool you need for this, you can download the excellent Resource Builder or the alternative Resource Hacker.

Customization instructions

First you have to create a working directory, let's say X:\bootscreen\, which is going to contain the modified winload.exe.mui file. Furthermore, I will assume that you have installed Windows Vista on your V: drive (of course you have to substitute these paths in this article with your own paths).

Open V:\Windows\System32\Boot\winload.exe with your favorite Win32 resource editing tool, navigate to resource 1 in the RCData resource section and save its contents to X:\bootscreen\winload.wim (there is only one RCData resource).

The extracted Windows Image (WIM) file contains the boot screen bitmaps. You can modify the winload.wim contents by using ImageX.

NOTE: ImageX currently is only distributed with "Microsoft Solution Accelerator for Business Desktop Deployment (BDD) 2007 (Beta) for Microsoft Windows Vista". Because BDD 2007 is still in beta, you can only get ImageX if you are a member of the beta program.
Mount the WIM image by creating a mount directory in the working directory (for example X:\bootscreen\mount\). Mount the WIM image with write access by executing:

imagex /mountrw X:\bootscreen\winload.wim 1 X:\bootscreen\mount

If ImageX successfully mounted the image, you will see two bitmap files in the X:\bootscreen\mount\ directory: osload800x600.bmp and osload1024x768.bmp . These two files are required and are used for the boot screen at 800x600 and 1024x786 resolutions respectively. You can replace these files with your own, as long as they are of bitmap type and have the above defined name and size.
After editing the bitmaps, commit the changes to the WIM file by executing:

imagex /unmount X:\bootscreen\mount /commit
Now X:\bootscreen\winload.wim contains your custom images, copy V:\Windows\System32\Boot\en-US\winload.exe.mui to X:\bootscreen\winload.exe.mui and open it with your favorite Win32 resource editing tool.
Create a new resource of the type RCDATA with name 1 and language 1033 (1033 stands for English-US) and import X:\bootscreen\winload.wim as the resource’s data. Save the file and exit your Win32 resource editing tool.

If you have a non English-US version of Windows Vista, your language code may be different. You can find a list of language codes here.
Copy X:\bootscreen\winload.exe.mui back to V:\Windows\System32\Boot\en-US\winload.exe.mui and you're done!

Text customization instructions

Changing the text in the boot screen is also possible. XML editing experience is required and assumed below.

Open X:\bootscreen\winload.exe.mui with your favorite Win32 resource editing tool and navigate to resource OSLOADER.XSL in the 23 resource section and save its contents to X:\bootscreen\osloader.xsl.
To change the Starting Windows Vista text, navigate to the osload-status template and change the text of the value attribute in the update element.
To change the position of the Starting Windows Vista text, navigate to the osload-graphics template and change the value of the height and width attributes of the textarea element in front of the textarea with a name attribute of status.

10/5/2006

Object Store types

Recently, Inky presented me a list of Object Store types (Object Store is the functionality that stores your messenger content [display pictures, emoticons, etc] on your computer) and asked me if I could fill in the blanks. Because I worked the last couple months on a tool that can enumerate all the installed content (the import and export functionality is currently on the to-do list) I was able the complete most of the list. After a small research, I was able to complete the whole list.

Value	Name	Comments
1	Avatar	Unknown, but already present since the beginning (MSN Messenger 6.0).
2	Custom Emoticons
3	User Tile	Static display pictures.
4	Shared File	Unknown, but already present since the beginning (MSN Messenger 6.0).
5	Backgrounds	Static backgrounds.
6	History
7	Deluxe Display Pictures	Dynamic display pictures.
8	Winks3	Winks.
9	Map File	A map file contains a list of items in the store.
10	Dynamic Backgrounds	Dynamic backgrounds.
11	Voice Clip
12	Plug-In State	Saved state of Add-ins.
13	Roaming Objects	For example, your roaming display picture.
14	Location	Information about your locations (City, Country, etc).

If you list it per Messenger version, you get the following list.

MSN Messenger 6.0

Avatar
Custom Emoticons
User Tile
Shared File
Backgrounds

MSN Messenger 6.1

Nothing new has been added in this version.

MSN Messenger 6.2

History

MSN Messenger 7.0

Deluxe Display Pictures
Winks3
Map File

MSN Messenger 7.5

Dynamic Backgrounds
Voice Clip

Windows Live Messenger 8.0

Plug-In State

Windows Live Messenger 8.1

Roaming Objects
Location

Unified User Notification (UUN)

Unified User Notification (UUN) was introduced together with Unified Buddy Notification (UBN) in MSNP13, to give clients the ability to exchange data with another without setting up a Switchboard session first. Although MSNP13 isn't the latest version of the protocol, the real purpose of the commands has come to the light with the introduction of Windows Live Messenger 8.1. If you send a UUN command to a buddy via your Notification Server, his or her client will receive it as a UBN command from the Notification Server.

When sending a UUN command to the server, 4 parameters are needed: a transaction identifier, the receiving buddy's e-mail address, the type of the data being send and the payload length. The type parameter can have the following values:

1 - Data for the Shared Folders sharing engine (in particular for the Synchronization Negotiation Manager).
2 - Not yet observed, so still unknown.
3 - MSNSLP data for starting a P2P session (in particular for starting a direct connection).

The differences between UUN and UBN are that the UBN command doesn't have a TrId parameter and that the parameter containing the e-mail address is the e-mail address of the sender.

Sending UUN - Abstract

Client: UUN <TrId> <receivers e-mail address> <type> <payload length>\r\n<payload data>

Server: UUN <TrId> OK\r\n

Sending UUN - Example

Client: UUN 10 buddy_b@live.com 1 78\r\n<SNM opcode="SNM" csid="{054F3A1E-229C-453a-8AAA-5530DEC402BB}" priority="0"/>

Server: UUN 10 OK\r\n

Receiving UBN - Abstract

Server: UBN <senders e-mail address> <type> <payload length>\r\n<payload data>

Receiving UBN - Example

Server: UBN buddy_a@live.com 1 78\r\n<SNM opcode="SNM" csid="{054F3A1E-229C-453a-8AAA-5530DEC402BB}" priority="0"/>

9/8/2006

MSNP15

With the release of Windows Live Messenger 8.1 BETA build 0064 today, the MSNP15 protocol has been enabled. This protocol introduces a new authentication scheme called RPS "Relying Party Suite". Where TWN "Tweener" authentication is used on protocol versions 14 and below, RPS authentication will be used on protocol versions 15 and above. Furthermore, users are now able to show their location in Messenger.

RPS Authentication

When a user wants to authenticate, not much values have to change. The sequence looks a lot like the Tweener authentication except that it uses SSO as name of the authentication system. Note that only the ticket is sent to the server, because the system is only used for authentication and thus the profile is obsolete.

Abstract

Client: USR <TrId> SSO I <email>\r\n

Server: USR <TrId> SSO S <policy> <base64 encoded nonce>\r\n

Client: USR <TrId> SSO S <ticket> <base64 something>\r\n

Server: USR <TrId> OK <email> <verified> 0\r\n

Example

Client: USR 10 SSO I buddy@live.com\r\n

Server: USR 10 SSO S MBI 0Xb2iqDOU4LeVUCUCWAQt6aYYz+xmobpwEDV9IshEaWUDUyyZ3KG961MHI3mKPYW\r\n

Client: USR 11 SSO S t=... HAAAAAEAAAADZgAABIAAAA...\r\n

Server: USR 11 OK buddy@live.com 1 0\r\n

If you look at the above sequence, you'll see that the response command after the initial command has an extra parameter to hold a nonce and that the policy has MBI as value. The value of the policy field should be used to authenticate against the Passport STS service (just like you had to do with the Tweener authentication: ?id=...&tw=...&ct=..&..). The nonce is, together with a couple of more values responsible for the the new base64 encoded parameter which is sent back with the ticket. I'm sure we'll find out later how to do that exactly.

Because of the new authentication system, we have to add a new token request to the SOAP authentication request. I assume that you are familiar with the SOAP authentication request, so I'll only explain some of the values.

Example

<wst:RequestSecurityToken Id="RST1">

<wst:RequestType>http://schemas.xmlsoap.org/ws/2004/04/security/trust/Issue</wst:RequestType>

<wsp:AppliesTo>

<wsa:EndpointReference>

<wsa:Address>messengerclear.live.com</wsa:Address>

</wsa:EndpointReference>

</wsp:AppliesTo>

<wsse:PolicyReference URI="MBI" />

</wst:RequestSecurityToken>

The value of the Id attribute in the RequestSecurityToken element may vary from RST1..RST<N> (where N is a number higher or equal to 1). The value of the URI attribute in the PolicyReference element has to be taken directly from the policy field in the received USR command. Furthermore, you have to specify the service target messengerclear.live.com for the moment. However, this may change in the future.

The response to the above request looks like the following response.

Example

<wst:RequestSecurityTokenResponse>

<wst:TokenType>urn:passport:compact</wst:TokenType>

<wsp:AppliesTo xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">

<wsa:EndpointReference>

<wsa:Address>messengerclear.live.com</wsa:Address>

</wsa:EndpointReference>

</wsp:AppliesTo>

<wst:LifeTime>

<wsu:Created>2006-09-08T12:24:14Z</wsu:Created>

<wsu:Expires>2006-09-08T20:24:14Z</wsu:Expires>

</wst:LifeTime>

<wst:RequestedSecurityToken>

<wsse:BinarySecurityToken Id="Compact1">t=...</wsse:BinarySecurityToken>

</wst:RequestedSecurityToken>

<wst:RequestedTokenReference>

<wsse:KeyIdentifier ValueType="urn:passport:compact" />

<wsse:Reference URI="#Compact1" />

</wst:RequestedTokenReference>

<wst:RequestedProofToken>

<wst:BinarySecret>...a base64 encoded value...</wst:BinarySecret>

</wst:RequestedProofToken>

</wst:RequestSecurityTokenResponse>

I won't go into detail, but the value of the BinarySecurityToken with Id="Compact1", should be used as value in the final USR command sent to the server.

Locations

Another new item is that persons are now able to set their geographical location in their PSM, which has been done by adding the element LOC to the Data element of the XML in the UUX payload. Now your UUX command could look like this:

Abstract

UUX <TrId> <Size>\r\n

<Data>...<LOC>\0Location\01\0<String formatting>\0<Value 1>\0<msnobj Creator="buddy@live.com" Type="14" SHA1D="..." Size="..." Location="0" Friendly="..."/>\01\0</LOC>...</Data>

Example

UUX 12 ...\r\n

<Data>...<LOC>\0Location\01\0Somewhere\0Somewhere\0<msnobj Creator="buddy@hotmail.com" Type="14" SHA1D="+k0sN0ojrTqOlpbDezJUFG/0Yz0=" Size="218" Location="0" Friendly="UwBvAG0AZQB3AGgAZQByAGUAAAA="/>\01\0</LOC>...</Data>

The format of the value in the LOC element looks a lot like the value for the current song playing aka Music. The <String formatting> field should have the Location name as value, just like the <Value 1> field. Followed by a MSNObject with Type=14 (Location) and with the Location name as friendly name, which is in turn base64 encoded.

6/28/2006

'Gebruik nieuwe Live Messenger is niet veilig'

-Dutch only.

In reactie op 'Gebruik nieuwe Live Messenger is niet veilig' op http://www.telegraaf.nl/i-mail/45479431/_Gebruik_nieuwe_Live_Messenger_is_niet_veilig_.html:

Dit artikel door de heer Hagens en de heer Vroon, geeft mijn inziens een onterechte kijk op de zaak en geeft ook aan dat er geen goede journalistiek is bedreven, dit zal ik hieronder toelichten.

De nieuwe functie waarover wordt gesproken (“Shared Folders” of in het Nederlands “Gedeelde mappen”) biedt twee gebruikers de mogelijkheid om bestanden met elkaar te synchroniseren. Zet gebruiker A een bestand in de gedeelde map bestemd voor gebruiker B, dan zal gebruiker B deze ontvangen als hij zich aanmeldt. Dit verschilt in feite niet van het vesturen van één bestand van gebruiker A naar gebruiker B zoals dit gebeurde in de voorgaande versies. De manier waarop het wel verschilt, is de overdracht van het bestand tussen twee gebruikers. In beide gevallen gaat begint het als volgt:
1. Een directe verbinding tussen de twee gebruikers als ten minste één van de gebruikers de mogelijkheid heeft om te reageren op een inkomende verbinding (dit ligt op netwerk niveau en staat los van elk programma m.u.v. de eventuele firewall)
2. Als punt 1 niet mogelijk is wordt het bestand verzonden via dezelfde verbinding waarmee ook de tekstberichten verzonden worden. De data gaat in dat geval van gebruiker A naar de servers van MSN gaat en van daar naar gebruiker B.

Als er eenmaal een verbinding is, dan is het verschil pas goed duidelijk. Via “Shared Folders” wordt het bestand beveiligd verzonden door het toepassen van een Public Key encryptie, wat betekend dat wat gebruiker A beveiligd met de publieke sleutel van gebruiker B alleen gelezen kan worden door gebruiker B (zie ook http://en.wikipedia.org/wiki/Public_key_encryption). Dit in tegenstelling tot het versturen van een los bestand zoals dit in de vorige versies zit waar helemaal geen encryptie of andere beveiliging wordt toegepast op de gegevens.
Ook is het zo dat als er geen virusscanner door de nieuwe Messenger wordt gevonden deze de optie bied om een gratis virusscanner te downloaden die automatisch deze bestanden scant. Daaruit kan geconcludeerd worden de gegevens die op deze wijze zijn verstuurd beter zijn beveiligd en schoner zijn dan in voorgaande versies.

Deel twee van het artikel gaat verder over het stelen van iemands identiteit (ook wel identity theft in het Engels). Identity theft is simpelweg niets anders dan het raden van een gebruikersnaam en/of wachtwoord van een gebruiker voor welk product/dienst/site dan ook. De manier waarop de dief hieraan is gekomen, door pure gok of door weten van deze gegevens is hiervoor niet van belang.
Het artikel probeert de indruk te wekken dat identity theft komt door slechte beveiliging in de Messenger dienst. Echter is dit niet simpelweg toe te schrijven aan een product of dienst. Elke vorm van aanmelding (m.u.v. biometrische) op het Internet is hieraan onderhevig. Dus ook uw privé of werk e-mail account!

Zoals in het artikel is vermeld, is het beveiligen van een computer met een firewall en virusscanner is inderdaad geen overbodige luxe. Maar dan moet de gebruiker zelf er ook wel actief aan werken door ervoor te zorgen dat de beveiligingssoftware up-to-date blijft. De gevaren waarvoor deze software in heet leven is geroepen wordt niet drastisch vergroot door het gebruik van Live Messenger, zoals al beschreven (het gevaar is groter als u KaZaA gebruikt). Tevens is het zo dat de argumenten die door de heer Vroon worden opgelepeld niet alleen gelden voor Live Messenger maar voor ieder product van elk willekeurig bedrijf dat de mogelijkheid bied om bestanden te sturen over het Internet. Ook is het zo dan een gebruiker zich bewust dient te zijn van de gevaren die het Internet met zich mee kan brengen, maar dit is voor een gedeelte van het publiek nog niet het geval.

Concluderend over het gehele artikel, met de onderbouwingen en stellingen, vind ik dat hier een slecht staaltje journalistiek is bedreven. Allereerst is er slechts één partij (beveiligingsexperts of mensen die zich zo noemen) die aan bod komt in het artikel, maar niet de andere partij. Ook is er geen (gedegen) onderzoek verricht naar de technische veranderingen in Live Messenger ten opzichte van vorige versies (MSN Messenger v7.5 en lager). Tot slot wordt er niet beschreven dat de genoemde kwade praktijken bij alle programma’s die bestanden of berichten(!) versturen over het Internet kan optreden.

-Een ICT’er met verstand van de beveiligingen en de technische werking van Live Messenger.

5:39 PM | Add a comment | Read comments (1) | Permalink | Blog it

6/25/2006

Capabilities

Most MSNP documents make reference to a “ClientID” field. This bitmask is officially called “Capabilities”. The bitmask allows a client to broadcast, to others, its capabilities (e.g. GIF Ink support). New Windows Live Messenger 8 bitmask values are in bold below.

Value	Name	Description
0x000001	Mobile Online	The client is running on a mobile device.
0x000004	Renders GIF	The client is able to handle Ink in GIF format.
0x000008	Renders ISF	The client is able to handle Ink in ISF format.
0x000010	Webcam Detected	The client has a webcam and allows others to see it.
0x000020	Supports Chunking	The client allows a large message to be received in chunks.
0x000040	Is Mobile Enabled	This is used when the client is running on a MSN Mobile device. This is equivalent to the MOB setting in the BPR list.
0x000080	MSN Direct deviceⁱ	This is used when the client is running on a MSN Direct device. This is equivalent to the WWE setting in the BPR list.
0x000200	WebIM Client	The client is a web-based Messenger client.
0x000800	Connected via TGW	The client is an internal Microsoft client and/or Microsoft Office Live client.
0x001000	Has Space	The user owns a space on MSN Spaces.
0x002000	MCE User	The client is running on Windows XP Media Center Edition.
0x004000	Supports DirectIM	The client supports DirectIM.
0x008000	Supports Winks	The client supports Winks.
0x010000	Supports Shared Search	The client supports shared searching between users.
0x020000	Is Botⁱⁱ	Set by the server if the account has been provisioned by MSN as being a Bot account (and thus have its limitations removed).
0x040000	Supports VoiceIM	The client supports Voice Clips.
0x080000	Supports SChannel	The client allows others to set up a secure channel (via which to send secure messages).
0x100000	Supports SIP Invite	The client supports unknown SIP-based communications.
0x400000	Supports SDrive	The client supports Shared Folders.

Value	Client Version
0x10000000	MSN Messenger 6.0
0x20000000	MSN Messenger 6.1
0x30000000	MSN Messenger 6.2
0x40000000	MSN Messenger 7.0
0x50000000	MSN Messenger 7.5
0x60000000	Windows Live Messenger 8.0
NOTE: If any of the client version values are set, the “P2P Aware” capability (internal) is set. This indicates the client is able to talk via the MSNC protocol.

ⁱ On version 8.0, this flag appears to be inactive.
ⁱⁱ Not new in version 8.0, but unmentioned elsewhere.

4/18/2006

Windows Live Messenger 8.0 build 0683.00_Branches

Well, the build seems to have leaked. Most of you probably saw the screenshots of it and read its feature list. One of the interesting features is Add-ins. These add-ins allow you to write a small application which can interact with the Messenger Client.

However, this feature is disabled by default and can only be enabled with a registry tweak. Because that certain registry key is only being read during the startup of Messenger, you have to restart Messenger in order to enable support for Add-ins.

To install a certain add-in into Messenger, go to Tools, Options and select the option Add-ins. Then hit the Add to Messenger... button, select the DLL file and enable the "Automatically turn on..." checkbox. If you now change your state to away, the plugin is loaded.

Download: Registry tweak
Download: Sample secretary plugin (DLL)

Download: Sample secretary plugin (Code)

-ZoRoNaX

3/31/2006

Update: Windows Sidebar ported to XP (build 5342)

Yesterday, we shipped Revision 1 for the emulation code for Windows Sidebar build 5342. It contains an interim fix which resolves the crash on functions which call the SHCreateItemFromIDList function (ie. Launcher gadget).

Download build 5342 (revision 01): Mirror 01 // Mirror 02

Release Notes

Changelog
/////////

Revision 1 (library 1.3.1.0)
- Changed SHCreateItemFromIDList to resolve
  Lancher gadget crashing (interim fix)


Revision 0 (library 1.3.0.0)
- Initial release

View more entries

ZoRoNaX

Categories

Archives

Blog

Windows PE 2.0 + .NET Framework 2.0

Restore Live Messenger Custom Content

Windows Vista boot screen customization

Object Store types

Unified User Notification (UUN)

MSNP15

RPS Authentication

Locations

'Gebruik nieuwe Live Messenger is niet veilig'

Capabilities

Windows Live Messenger 8.0 build 0683.00_Branches

Update: Windows Sidebar ported to XP (build 5342)