Sep 062014

The Grim Dawn logoGame compatibility is generally becoming a major issue on Windows XP and XP x64, and I’m not even talking about Direct3D 10/11 here. Microsofts own software development kits and development environments (VisualStudio) come preconfigured in a pretty “Anti-XP” way these days, even if you intend to just build Direc3D 9 or OpenGL 4 applications with it.

There are examples where even Indie developers building Direct3D 9.0c games refuse to deal with the situation in any way other than “Please go install a new OS”, Planetary Annihilation being the prime example. Not so for Grim Dawn though, a project by a former Titan Quest developer which I [helped fund] on Kickstarter a while back. In their recent build numbered B20, an issue arose that seemed to be linked to XP exclusively. See this:

Grim Dawn B20 if_indextoname() Bug

Grim Dawn B20 if_indextoname() bug, in this case on a German 32-Bit Windows XP. Looks similar on XP x64 though. © by [Hevel].

More information can be seen in the corresponding Grim Dawn [forum thread], where I and others reported the issue, determining that it was on XP only in the process. That thread actually consists of two issues, just focus on the if_indextoname() one. This is also documented at [Microsofts MSDN library].

The function seems to be related to DNS name resolution and is a part of the Windows IP Helper API on Windows Vista and newer.  if_indextoname() does however not exist on any NT5.x system, which means Windows 2000, XP and 2oo3 Server which includes XP x64 and there is no fallback DLL. My assumption is, that this happened because of the newly added multiplayer netcode in the game.

Now the interesting part: After me and a few other XP users reported the issue starting on the 30th of August, it took the developers only 3 days to roll out a hotfix via Steam, and all was good again! I believe nowadays you can judge developers by how well they support niche systems, and in this case support was stellar. It may also have something to do with the Grim Dawn developers actively participating in their forums of course. That’s also great, as you can interact with them directly! No in-between publisher customer support center crap, but actually people who know their stuff, ’cause they’re the ones building it!

So I’d like to say a big “Thank you, and keep up the good work!” here!

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:


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!

Mar 112014

AnurA logoI don’t know about you, but I have been [ranting] about Razer and their shady new cloud-based driver model for input devices for long enough, on top of their what I would call shoddy manufacturing quality. Sure, some people called me a hater (basically), but recently my Razer Lachesis started showing signs of breaking. First, a jumpy sensor, then an erratically behaving mouse wheel. Ok, the sensor I fixed by disassembling and cleaning the mouse inside out, but the wheel is just broken beyond my capabilities, as it would sometimes cause a scroll in the wrong direction for whatever weird reason.

So now I wanted a new mouse, and since the market doesn’t offer anything that I would’ve considered “worth my coin”, I could just as well order almost anything. So I went for yet another gaming mouse, the Epic Gear AnurA, with Epic Gear actually being a subdivision of the Taiwanese hardware manufacturer [GeIL]. Strangely, they do not offer a driver download for the mouse. I assumed, since they’re saying that they support Windows XP, 7, 8 etc., that the driver would ship with the device. But there is no such thing. But more about that later. Let’s have a look at the mouse first:

The AnurA feels nice to the touch, and features a braided cable, which makes a reasonably good impression. Which it should, for about 60-70€. It does not have that Razer-style coating, but a form of softer plastic for the parts where you’d hold it. Also, the rest feels quite good, including the micro switches, so the haptic impression is solid. Looking at the bottom, you’ll see that this device features not one, but two sensors. An IR LED one, and a high resolution LASER one. You can switch between them with a hardware switch, and you may also choose to keep the default, which is the patented HDST mode, that combines both sensors together. For the math work to make the magic of combined sensors happen, there is an embedded 32-Bit ARM Cortex M3 processor installed.

Also, you should keep in mind, that this mouse is optimized for claw style grip. So if you use a palm grim on the device, you’d probably wanna go for a larger Logitech instead. But for a two finger claw grip (thumb and pinkie in my case) it works nicely. Palm grip might still work if your hands are small, but there are surely other mice, that feel better ergonomically if you want to lay your entire palm onto the mouse. At least, the AnurA can be used both with your left and right hand. The button configuration can be stored on the hardware flash memory using the control panel, so you do not need the software to switch to left handed mode later! Not bad.

According to Epic Gear, the dual sensor technology should handle all kinds of problems, like drift, jitter, jumpiness etc. If you know that your mousing surface only works with one of the two technologies, you can of course just switch to that tech exclusively using the switch.

But now, to the driver. Or more to its non-existence. Epic Gear does not provide a Windows driver. At all. There is a control software for basic configuration, like detailed dpi settings for all three sensor modes, but it can work with the standard HID mouse driver of Windows – also on Windows XP Pro x64 edition! I also tried to verify this using DriverView, and indeed, the AnurA does not require any kind of additional Windows driver! Awesome! See here, some screenshots of the driver test and the control panel, which also shows the AnurA being a gamers mouse:

The mouse operating driverless is probably also the reason why an input device product released in early 2014 can work properly on Windows XP Pro x64 Edition, including the control software, firmware flash etc. Also, given the onboard flash memory for settings/profile storage, you can run this well on any version of Windows that supports USB, Linux, MacOS X, BSD UNIX, Solaris, Haiku OS, any UNIX, whatever. The hardware keys can be used to change dpi, switch profiles or switch sensors. There is also a dpi-changing “sniper mode” function that greatly reduces dpi if you need to hold your rifle steady. Well, it is a gamers mouse after all.

Ooh, and yes, you can switch off the light. ;)

Overall, I am pretty satisfied for now. Hopefully, the build quality of the electronics is up to that of the casing and cabling. If so, this piece of hardware might live a long life attached to my main workstation despite is rather… martial looks, which don’t quite fit my style. But neither did the Razer Lachesis mouse, so whatever.

Apr 112012

SLIOh, and in other news: I started another live chat with nVidia yesterday, and talked to yet another rather well-informed support person named Karthik, who answered my primary question. Of course I asked, wether there actually would be any SLI support for the GeForce GTX 680 on Windows XP and Windows XP x64 as the recent beta driver not having it shocked me quite some. Mr. Karthik however insisted, that the 2-way SLI feature is still fully supported for NT 5.x and that even the current beta driver is actually not feature-complete yet.

That would mean, that I really only have to wait for the WHQL driver and that it won’t be necessary to give up my cards for GTX 580s. There is still a little bit of doubt here, so I’m keeping my options (and bartering threads) open for now.

Apr 102012

SLISo the neverending story continues..  and as it seems, it is spiralling towards a really bad ending. Yesterday, nVidia released a new beta driver for the GeForce GTX 680, version 301.24. As this is the first unified driver, it also supports older cards. However, as a new missing feature it states, that “GeForce GTX 680 SLI” will be missing for both XP and XP x64. Just that one feature that I need, god dammit. Since beta drivers are usually feature complete, this means that SLI won’t be making it into XP (x64) for the GTX 680. I’ll wait for the final WHQL driver, but it’s looking really grim. I have already prepared and started forum threads to set an exchange for two GTX 580s into motion.

This is really, really bad. It’s crap to see that card still supported, just with the most important part missing. If this isn’t in the WHQL, I’ll start a last support chat with nVidia for final clarification. I have a feeling I’m not gonna like what they’ll have to say. We’ll see soon enough I guess.

Mar 302012

Zotac GeForce GTX 680 boxesTo the left you can see two Zotac graphics card boxes. That’s two GeForce GTX 680 cards, so the latest and greatest, nVidias just released Kepler architecture in the form of GK104. So while GK104 is not the final high-end part (GK110 will be just that around late summer or autumn), it’s being sold as such at the moment, since it’s simply the most powerful single GPU to date. And a power-efficient one at that. I guess GK110 will be a monster if nVidia decides to go all-out with the design. While GK104 boasts a 6Ghz QDR 256-Bit memory interface with 2GB, GK110 will give us a supposed 6GHz 512-Bit interface with 4GB. And on top of that 2306 shader cores instead of GK104’s 1536. Well, I don’t believe the memory interface stories yet though. Sounds a bit too good to be true, as that’d be almost 400GB/s..  Well, whatever. Let’s get to the point here, now shall we?

Two GeForce GTX 680 and two GeForce GTX 480To the right you can see the two new GeForce GTX 680 cards on top, and the replaced GeForce GTX 480 cards on the bottom. One SLI supposed to replace another. If only it was that easy. At this moment, nVidia is not offering any driver for either Windows XP nor Windows XP x64 Edition, which I am using. No WHQL and no beta. The only drivers available are leaked alpha versions 300.65 (which detects “NVIDIA GK104” cards instead of “GeForce GTX 680” indicating that this is a development version) and 300.83. These have been leaked by nVidia manufacturing partners like MSI and Gigabyte over the web and others like Zotac on their installation media. Now while they work in prinicple, it seems that one very important feature is missing: SLI.

Since there is no SLI, and currently there seems to be only a single GPU mode, performance at the moment is slightly lower than before. Dammit. A few days ago I have chatted with nVidia support, and the support guys have confirmed, that Windows XP OSes are still officially supported, but the driver ain’t ready yet. So it’s the waiting game again. I have however still sent Zotac an eMail requesting another driver with SLI support, but I don’t think there is going to be any before the official WHQL driver launch for XP and XP x64. A damn shame. Waiting game all over again indeed…