Jul 152015
 

XP x64 is dead logo[1] Update 2: It’s not looking good. At all. I (and some other users) have been playing around with Windows Storage Server 2003 systems (see the first update below), and while the OEMs are supposed to uphold support for the system, it seems they just don’t care. Two distributions have been inspected, one from Dell and one from Hewlett Packard. The latter actually does feature an updating software, that will however ignore all newer Microsoft security fixes. It just doesn’t do anything useful at all it seems.

For now, I am not even sure whether Microsoft truly ships any updates to the OEMs for rollout to customers, or whether they’ve just abandoned WSS03 completely, making their lifecycle statements regarding the operating system an empty promise, as no OEM could patch the OS itself like Microsoft can. It looks like we’re not getting anywhere with this. If you are a Windows Storage Server 2003 operator and you know more about this, or if you actually do have access to WSS03 Windows updates from after 2015-07-14, please do let me know in the comments! Thank you.

Update: While I’m not completely sure about it, it might be the case that we can disregard the text below this paragraph. A user that goes by the name of [tagg] pointed me towards a comment in the RyanVM forums, where 5eraph is releasing his XP x64 update packs. It seems that a special version of Windows Server 2003 called the “Windows Storage Server 2003” is actually supported until [October of 2016], which could mean that XP x64 could get yet another extension to its lifetime. I’m currently inspecting the operating system and methods to extract full update installers out of it to see whether it can truly be done. If yes, there might be life in the old dog yet!


The dark ages have finally arrived – for XP x64 users, that is. Yesterday, Microsofts extended support for Windows Server 2003 has ended, and with it also my [unofficial XP x64 update] project. There won’t be any more updates for Windows XP Professional x64 Edition SP2 and its on-board components from this day on. And while the regular 32-bit version with its older NT 5.1 kernel will live on until 2019 due to the [POSReady2009 hack], XP x64 will not, as there is no 64-bit embedded POSReady version of XP naturally, given that point-of-service systems like ticketing machines or airport terminals don’t need 64-bit address spaces.

So, as said on the update page, if you’re going to keep using XP x64, you’re doing so at your own risk. And you should really be knowing what you’re doing too, or you may not only put yourself at risk, but also other users on the web, should your machine become compromised. But given that XP x64 users I’ve encountered recently are also often freaks and avid Linux/UNIX users as well, I think the danger is much lower than with 32-bit XP.

Well that’s it. From the Microsoft side of things, this is pretty much where XP x64 ends.

It’s a bit sad that there is no free kernel API extension to make newer software run on the old system, like there is for Win9x with [KernelEx]. Software built with modern Microsoft development environments (Visual Studio 2013+) and in certain cases older ones will likely work on XP less and less from now on. People will no longer care so much for linking against the old platform SDKs and compiling for the v110_xp platform target.

Several free software projects (like FileZilla to name just one of many) have already ceased to support NT5.x even before the end of Server 2003. It’s even worse for commercial applications of course. Then there are others which still care to keep the platform supported, like the x265/HEVC encoder or closed software like AnyDVD HD.

But one thing’s for sure.

From this day on, it’ll only get darker and colder for those who decide to stay on this ship!

[1] Original image is © 2015 Windows 8 Wallpapers

May 242014
 

XP Hex hackingJust when things went crazy enough with my backporting of Server 2003 updates to Windows XP Pro x64 Edition, here comes the next “bomb”! User [MasterOf486er] on the [Voodooalert forums]German flag posted a link to the well known German website Winfuture, which focuses primarily on all things Windows. And they describe a way of hacking up Windows XP 32-Bit to act like a Windows Embedded POSReady 2009 system, [see here]German flag! Those so-called “POS” or “Point of Service” systems are typically airport terminals, train/subway ticket vending machines or ATMs and other systems running in Kiosk modes.

And Windows XP based POSReady 2009 systems are supported until [2019-04-09]!

The hack is rather simple, all you need to do to make your 32-Bit Windows XP act as an Embedded POSReady 2009 machine is to add the following to your systems registry:

Windows Registry Editor Version 5.00 

 [HKEY_LOCAL_MACHINE\SYSTEM\WPA\PosReady]
 "Installed"=dword:00000001

I have prepared a .reg file for your enjoyment, that you can just download and double click as Administrator after unpacking:

After entering the data to your registry, re-check Windows Updates, and you should be getting the goods! As always, you’ll have to do this at your own risk, no guarantees for anything from my side. But for now it seems to be working for people on XP 32-Bit!

Please note, that you might be violating Microsofts Windows XP EULA by applying this hack, so you’ve been warned!

Edit: We now have an official statement by a Microsoft spokesperson regarding the POSReady hack. As always, take with a grain of salt. [Source];

“We recently became aware of a hack that purportedly aims to provide security updates to Windows XP customers. The security updates that could be installed are intended for Windows Embedded and Windows Server 2003 customers and do not fully protect Windows XP customers. Windows XP customers also run a significant risk of functionality issues with their machines if they install these updates, as they are not tested against Windows XP. The best way for Windows XP customers to protect their systems is to upgrade to a more modern operating system, like Windows 7 or Windows 8.1.”

They do have a point there though. While we got an IE8 and .Net update, even the lightweight shell library update, there is no guarantee that every hole will be plugged, as POSReady 2009 systems are reduced feature set XPs after all. Also, the updates are naturally untested on regular XP machines, so there is risk. Still, I consider running XP in “POSReady 2009” mode being a better option still, when compared to just run it in “08th of April, 2014” state.

May 152014
 

Important Edit: I have decided to host updates for Windows XP Professional x64 Edition starting now. The updates will be hacked where necessary to work smoothly on XP x64, unmodified updates will also be re-hosted! You can find them all in a page pinned to the weblog on the top right, [here is the link]!

XP Hex hackingOk, so we all know that besides those “Malicious Software Removal” updates and that fancy [Internet Explorer hotfix], XP is and will stay dead in the water, when it comes to Microsofts support for patches, right? That might be true for Windows XP 32-Bit, but what if I told you that there is a real way to keep XP x64 alive and secure all the way until July 2015? Since the newer XP x64 shares a large code base with Windows Server 2003 (which keeps being supported until 2015-07-14), the logical thing would’ve been to just try out those updates where applicable. It ain’t all so easy though…

Install error

Trying to install the update for [KB2926765] succeeds on Server 2003, but fails on XP x64!

This update actually replaces the 32-Bit and 64-Bit versions of shlwapi.dll, which exists on both operating systems in the same version. So what’s going on? We can find the solution by unpacking the update file WindowsServer2003-KB2926765-x64-ENU.exe with 7zip or WinRAR. Inside you’ll find an update/ folder and in it, the file update_SP2QFE.inf.

When opened, the culprit can be found at the very end of the file:

[Prereq.XPAMDInstallBlock.Section]
    PresentOp=CheckReg,HKLM,"SYSTEM\CurrentControlSet\Control\ProductOptions",ProductType,0x00000000
    NotEqualOp=CheckReg,HKLM,"SYSTEM\CurrentControlSet\Control\ProductOptions",ProductType,0x00000000,!=,"WinNT"
    Display_String="%WrongProductMessage%"

When you open the registry editor and check those keys, you’ll find that “WinNT” string. And that means, that the prerequisites of the installer update.exe in the same folder are not met. And that’s the updater launched for the actual installation. So then, just edit the INF and install? Yeah, that’s what I thought. Forget about it right away! Each update comes with a catalog file – KB2926765.CAT in this case – which amongst other files holds cryptographic signatures of the INF files included. Change one of those INF files and it’s this one for you:

INF modification doesn't work

INF modification doesn’t work!

So then I found [this guy right here], who seems to be some serious Windows hacker. Like SERIOUS serious. I thought that hacking update.exe would be the next step, so I fired up the IDA disassembler and tried my luck together with my trusted old XVI32 hex editor to try and duplicate this guys hack to cancel out the INF file verification code:

So the assembly patch would generate hexadecimal binary opcodes (the instructions mov eax, 1 and retn 4 were added), which I then tried to enter into the file at the proper offset with a hex editor. Now I am no software reverse engineer and my x86 assembly is rusty, x86_64 non-existant. In the end, this failed miserably. The x86_64 code differs greatly from the x86_32 one shown at the blog post linked to above, so I was unable to port the solution over. It’s definitely possible, but it’s also a bit over my head.

And then I found a guy called 5eraph, who [assembles updates for Windows XP Pro x64 Edition] on RyanVMs forums, and his collection is still being maintained. In more recent times he had decided to include updates that were blocked on XP x64, especially since the end of Windows XP support. According to him, some of the updates showed clear signs of having been targetted at XP x64 just as well (you can find the signs if looking through all the INFs), if it wasn’t for the added crap in the update_SP2QFE.inf file and its siblings found in other Windows updates.

But he found a way. And again, the way was to patch update.exe. [See here]! Now I don’t know how this hack was developed, but basically you just need to edit a few strings with a hex editor. Here is the table with offsets as well as old values and new values in hexadecimal:

00016A90: 50 44 
00016A91: 72 75 
00016A92: 65 6D 
00016A93: 52 6D 
00016A94: 65 79 
00016A95: 71 53 
00016A96: 75 65 
00016A97: 69 63 
00016A98: 73 74 
00016A9A: 74 6F 
00016A9B: 65 6E 
00016AA0: 50 44 
00016AA2: 72 75 
00016AA4: 65 6D 
00016AA6: 52 6D 
00016AA8: 65 79 
00016AAA: 71 53 
00016AAC: 75 65 
00016AAE: 69 63 
00016AB0: 73 74 
00016AB4: 74 6F 
00016AB6: 65 6E

And what’s it look like when viewed in a hex editor? Let’s check it out in XVI32, stock version and modified version, the fields from the list have been marked in red to make it more clear. Just jump to offset 0x00016A90 and start editing:

So all you need to do is to change the data to some bogus crap, that exists nowhere else. You need to be very careful though, touch one wrong byte and the file will be damaged and will crash or behave erratically when launched. If everything has been done right, just launch the new, modified update.exe and something like this should greet you:

And just to verify that it actually did what it should, a quick version compare of the patched file shlwapi.dll in %WINDIR%\system32\ before installation and after installation & reboot is enough:

So, as I had hoped, it is indeed possible to refactor Server 2003 x64 updates for XP x64, even now where Microsoft is actively trying to block out the operating system from its updates. Now, not all updates will require this, as [reported by Sjaak Trekhaak] and confirmed by me. But those which do can be fixed!

Unless Microsoft finds some new way to harass what few XP x64 users remain, this is the way to go. It would be necessary to filter the updates though, as real Windows Server 2003 systems do feature components that XP x64 does not have, like an Active Directory LDAP server for instance. So a user would need to check this out on his own, or just rely on 5eraphs update pack of course. While I do prefer do pull this off myself, using 5eraphs stuff is much easier of course, no hex editing on your own, so you might wanna go with that instead.

And I do have bad news too after all. I can’t prove it, but due to the code base itself, it is highly likely that none of this works with Windows XP Pro x86 / 32-Bit…

In any case, Windows XP Professional x64 Edition lives on! The final battle ain’t over yet!

Thanks and greets fly out to 5eraph for his great XP x64 support, to RyanVM for hosting that cool forum and to [Remko Weijnen] for his elite hacking skills!