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!

CC BY-NC-SA 4.0 Keeping Windows XP Pro x64 patched until 2015-07-14! For real! by The GAT at XIN.at is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

  13 Responses to “Keeping Windows XP Pro x64 patched until 2015-07-14! For real!”

  1. Would there be a way to just mimick some way the registry entry so the patch would not see the WinNT part in the registry? I tried to change it with no luck (online impossible, offline makes then the system shout something very bad). Would be good to make a small program that would pretend there is something that is typical for server SKU. Or am I completely wrong?

    • Hi (w),

      The proper string for server SKUs would be ServerNT instead of WinNT. You could try to change it and see what happens.

      However, I am not entirely sure if the registry key is all the installer checks. What I believe to be a CheckForPreRequisites() function in update.exe might actually check for more than that. In the Windows version API there are more functions like IsWindowsXPSP3OrGreater() or also IsWindowsServer(), which return boolean values. There are multiple other tricks to do that, some of which you can see [here] at MSDN. Fact is, I do not know which exact methods update.exe really uses to fully determine the exact SKU/version. I’m also too lazy to fire up the disassembler again (which is also not quite legal on top of things).

      If they are doing file version checks or Windows API calls – depending on what those calls actually do – then you’d need wrapper stub DLLs to redirect the calls temporarily or dummy files to show to update.exe, also temporarily. None of this is would be very clean (not that this here solution is either).

      Luckily, up to this day, KB2926765 is still the only update known to require this hack for XP x64.

      If you choose to give the registry key change a shot, please let me know how it goes!

      • Sorry for later reply…
        Registry change of this specific key is not possible. If you change it online, system says something about license violation and change it back immediately. If you change it offline, system starts up to BSOD (STOP 0x9A – SYSTEM_LICENSE_VIOLATION).

        To install an update that checks the registry, it is necessary to change a SystemPrefix value (located nearby the ProductType), particularly the third bit from right from 0 to 1. Then the system boots up with Windows Server 2003 logo, says some error about checking license and refuses to login the user. To be able to install the patch, it is needed to hack the system using image-debug way to 5-shift “sethc.exe” so the cmd.exe runs instead (in context of the account SYSTEM). Then you can run the patch manually from command line and install the update. After installation you have to change it all (offline of course) back to normal WinXP style and boot the OS. You find that the patch is correctly installed. But the process is quite difficult and not user friendly. (I did not describe the process in detail intentionally).

        If it would be possible to mimick the registry entry just for the patch, it would solve everything fast and easy. AFAIK there is no such program, so those hacks are necessary.

        • Hello again (w),

          So you replaced the login shell explorer.exe with cmd.exe or did you spawn cmd.exe before that, on the WinLogon screen? In any case, that’s some nasty stuff.

          So yeah, if one wants to do this by oneself, altering update.exe still seems to be the best option. But even now, so many months later, KB2926765 is luckily still the only update requiring it. Originally, I had anticipated this to become the standard, but fortunately that never happened.

          Edit: I just looked up the sethc.exe hack, no idea how I missed this. So you did indeed spawn cmd.exe outside of WinLogon. That’s a cute little trick!

          • Yea, the trick is quite easy:

            [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe]
            "Debugger"="C:\\windows\\system32\\cmd.exe"

            Then you can press shift 5 times at logon (or lock) screen and cmd window appears.

            • Abusing the operating systems’ accessibility functions for such purposes, how ethically questionable that is! ;)

              Oh well, it’s only two more months towards what even the most hardcore users would likely call “The end” of XP x64. Hard to admit it publicly, but kinda makes me sad, real sad…

  2. I like your information …keep working at it .
    I have a server and three work stations in my office . I did switch to Windows 7 and Windows 8 .
    I have had problems one after another since the upgrade from Server 2003 and 64bit xp pro . I have been using 64bit XP PRO for years with little or no problems at all . I have gone back to Server 2003 and 64bit XP PRO .
    The best of luck to all decide to follow the new software trends , I will not .

    • Hi Larry,

      You may wanna check out the [XP x64 post-mortem updates] page. You can find all updates for XP x64 there, backported from Server 2003 x64, including Microsoft severity ratings and informational links for each update. I will keep going with this until Server 2003 itself goes under, which will be in July 2015. Up to that date, I will continue to provide XP x64 updates to keep all NT 5.2 machines safe until the Grim Reaper comes to get ’em all. ;) We still have more than half a year to go with full support (official or not, who cares?)!

      Just keep in mind that in case you choose to use those updates, always go from oldest to newest, this is the safest way to do it. Also, should you choose not to trust my files (which is perfectly understandable from a security standpoint, as I might not be trustworthy in your opinion), you can always use my lists to download the original updates from Microsoft themselves to have a “trustworthy” source right there! :) Just look for the KB numbers and search for “Server 2003 x64”, you’ll get the right updates for XP x64 that way, if you don’t wanna trust my files! :)

  3. Wow, that 5eraph guy keeps up the good work. Would you still like WSUS update notifications from me?

    • Now that I’m running two Server 2003 VMs for update notifications and two XP x64 VMs for testing before deployment, it shouldn’t be necessary for the core system. If you do also roll out updates for additional Microsoft software like Office or Visual Studio or anything else not server-related however, that could still be helpful as I may not be monitoring these things.

      On my [update publication page] I wrote that I wouldn’t include such updates, but it can’t hurt either. If you choose to provide KB-numbers of any additional updates not related to the Server 2003 core system (including .Net), it’d be appreciated!

      I do not have additional Office licenses to install all Office versions plus all Visual Studio versions etc. just to check them for updates on Server 2003. But if you can cover that part, I’ll include them where possible.

      In any case I’ll keep hacking, testing and deploying on my own now, and at least my update list is a bit more fancy than 5eraphs, if nothing else. ;)

  4. Nochmals Danke für die Hilfe ^^ :D

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">

(required)

(required)