| ZoRoNa's profileZoRoNaX' blogBlog |  Tools  Help |
|
|
12/19/2006 Windows PE 2.0 + .NET Framework 2.0After 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 ContentThe 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)
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 10/8/2006 Windows Vista boot screen customizationUntil 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).
Text customization instructions
Changing the text in the boot screen is also possible. XML editing experience is required and assumed below.
10/5/2006 Object Store typesRecently, 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.
If you list it per Messenger version, you get the following list.
MSN Messenger 6.0
MSN Messenger 6.1
Nothing new has been added in this version.
MSN Messenger 6.2
MSN Messenger 7.0
MSN Messenger 7.5
Windows Live Messenger 8.0
Windows Live Messenger 8.1
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:
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 MSNP15With 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 AuthenticationWhen 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.
LocationsAnother 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. 6/25/2006 CapabilitiesMost 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.
i On version 8.0, this flag appears to be inactive. ii Not new in version 8.0, but unmentioned elsewhere. 4/18/2006 Windows Live Messenger 8.0 build 0683.00_BranchesWell, 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: 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).
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 3/27/2006 Windows Sidebar ported to XPAs Rafael and I did before with the Sidebar from Windows Vista build 5219, we now released two patches again for the Windows Sidebar! This time it's for the ones from build 5308.60 (February CTP unstaged) and build 5342. These patches allow you to run the Windows Sidebar on Windows XP/2003 using our emulation library.
Just download our small package, extract its contents to the same directory containing Sidebar and the 'Gadgets' directory, and launch patch.bat.
 Release Notes
Microsoft Windows Vista Sidebar 6.0.5342.02 Patch ///////////////////////////////////////////////// Changelog ///////// Revision 0 (library 1.3.0.0) - Initial release Usage ///// 1. Extract archive contents into directory containing Sidebar.exe (not included). (NOTE: Original executable CRC32 is E10EB198) 2. Execute patch.bat and follow on-screen instructions. Notes ///// FOLDERID_UserProfiles has not been implemented. Gadgets using this known folder will fail. Credit ////// Rafael http://www.anti-tgtsoft.com ZoRoNaX http://blog.uxevolutions.com/zoronax/ Frequently asked questions
Q. The Slideshow gadget settings pane seems to be broken! How do I fix it? A. ZoRoNaX noticed and fixed this. Replace the code in settings.html with this code. Q. Can Vista.Emulation.dll be shared by different Sidebar executables? A. Probably but it's an unsupported configuration. Q. The Launcher gadget causes an error and crashes Sidebar. A. Unfortunately, the emulation library does not currently support SHCreateItemFromIDList(). Keep monitoring this thread for updates. Q. Where do I put the Gadgets/Gadgets folder? A. If you were a legitimate Vista beta tester, you would have copied the Windows Sidebar folder in its entirety, which contains a Gadgets folder in the directory containing the executable. Inside this folder, there are .Gadget folders containing the gadget information. Old parts are not compatible. Q. I ran the patch and now I get an error (not a valid Win32 application). WTFO? A. You likely failed to read the version number on the patch, topic, readme, etc. and tried to patch an incorrect or altered version. Try again. Q. I added a bad gadget and now I can't start Sidebar. How do I fix this? A. Delete the C:\Documents and Settings\<user name>\Local Settings\Application Data\Microsoft\Windows Sidebar folder. Q. Why are things white, miscoloured, etc.? A. The Sidebar team decided to switch from using their own internal layout engine to relying on Internet Explorer's rendering. Because Internet Explorer 6.x fails to render the PNG alpha channels correctly, gadgets using such PNGs are affected. You can alter the gadget's HTML/JS to render such PNGs using DirectX alpha transformation (or upgrade to Internet Explorer 7 beta). Q. I receive "The ordinal 60 could not be located in the dynamic link library ATL.DLL"! How do I fix this? A. Your ATL.dll is old or very new. We'll try to find a more general ordinal for the next patch but for now, just copy ATL.dll from an XP machine into the same folder as Sidebar.exe. Q. How do I get Sidebar gadgets working on non-English locale systems? A1. Each gadget has an IETF language tag-named folder. In this case, all of them are en-US. You may want to rename these to the proper tag for your system (or easier, see A2). You can guess or execute this small executable (.net 2.0). Source code here. A2. Move everything out of the IETF tag-named folder into the root of the gadget's folder (and optionally delete en-US) - ZoRoNaX 3/22/2005 GCFAs with MSN Messenger 7.0 build 0732, it looks like we have a new protocol command in action. After the client sends the SYN command to the server, it sends the command GCF to the server with a request for a certain Xml file. The server at its turn sends back the Xml sheet. As for now, it's only being used with the Shield.xml file. That file affects a range of clients, which probably need to block a certain feature of the application in the future. Currently it looks like this: 3/3/2005 Offline IMOkay, so it seems we are going to get an update in MSN Messenger 7 with Offline IM. The options which were disabled by default are now enabled by default. Though it seems that offline IM isn't working yet, we are going to get closer to it. It is from now on also possible to add a contact to your list by providing his or her mobile phone number. To do this you need to send this to the server: ADC 14 FL N=tel:+311234567 F=Test The country code which you can choose from the list is in this case 31 and 1234567 is the number of the phone I entered. The F= parameter is optional and shows the display name. I also noticed that the SYN command might have been changed on MSNP11. If you send the two date/time stamps to the server which you might have received before and they match, you aren't getting the full list anymore. If it doesn't match with the one the server has, you are getting the full list again. It also seems that the offline banner is now working again in MSN Messenger 7.0.0604 and you are able to add a mobile number to a contact. See screenshot. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
