I love reading write ups like this. It's an extremely empowering feeling to realize that all these opaque software and cryptic errors are ultimately also written by fellow programmers. You CAN understand it, you CAN take matters into your own hands.
I remember once, a few years back, there was this website where I was supposed to submit something, only that the submission page couldn't load. My friend thought that that was the end of it, but I decided to try to poke around.
Back then I was quite unacquainted with http but I started with what I knew, downloading the page source, figuring out what was the link or call that was failing, then testing it with curl. I eventually managed to figure out that the problem was caused by a missing header in the http request so I installed some random browser extension that patched http requests and voila, it worked!
Still remember the amazing feeling when the page loaded. My friend thought I was a wizard
I remember applying for a visa on a country's government website and their Javascript was broken. I "hacked" the HTML just to finish the application. I think it was a Firefox compatibility issue.
At one point, I managing some servers for a project at a large company. There was an internal web app via which one could modify and change the update / patch schedule for servers.
Only it was behaving like I wasn't authorized to use it (despite being the registered owner of the servers), and I couldn't find any documentation on what groups it wanted me in.
Take a quick glance at the js, and it's doing AD lookups from my client, via an unofficial AD-REST endpoint everyone used, and then using the result.
So easy enough to just return what it's looking for and change my server's schedules as desired.
But hmm... I wonder if it works for the admin-looking group? Yup. Of course it does.
Ping it over to a friend who works in appsec, they poke it for awhile, and figure out (a) with admin permissions this tool can change the patch schedule of everything (e.g. AD domain controllers) & (b) the same pattern of client-checks was used on a lot of other tools that team built.
So I threw some poor team's roadmap into disarray, but a little curiosity on my part helped improve our security posture.
The solution might've been a bit shorter if he'd known to search for info about the WOW6432Node and found out about how registry redirection works, something I don't see him clearly call out in there despite wondering where that extra bit comes from:
Hi there, author here. It was more than due to a 32-bit game running on 64-bit Windows and compatability mode didn't work.
Ubisoft changed the reg key of the base game from it's retail key to "Uplay Install 87" and the expansion had no idea to look for that key at all. If you used the Ubisoft copy of both games, the expansion pack would never have found the base game.
Yeah I was thinking he could have just flipped the KEY_WOW64_64KEY or the KEY_WOW64_32KEY on where ever it opened the registry in the installer Or use compatibility mode?
I am still glad he got it working in the end.
Are there any articles from Microsoft folks on why they made the 32/64 compatibility choices they did?
I'm not going to say they're the worst, and they certainly work, but they're also pretty obtuse and "Why would you design a thing like that?"
From memory of the era, the 32/64 bit client transition seemed a bit rushed when Intel had long decreed no home users would need 64-bit, and then AMD promptly started selling the Athlon 64 to anyone who would buy one.
Ha! thought exactly the same. I haven't used Windows in 18 years but when he mentioned installshield and cab files I felt right at home. Still remember using the PowerToys to open cab files :)
I played a lot of Installshield games as a kid - I definitely recognised their sail-like logo, but was too young to ever poke around in the installer back then. I started poking around in hex maybe in 2008 and then it was just installed games.
I do remember trying to mod Populous the Beginning, which is quite a bit older
This. It's strangely upsetting. It makes me want to "raise the alarm", which I imagine is a leftover evolutionary psychological tidbit instilling the "duty to inform" others about things.
Gotta say, I would just pirate the game and play it with a vaguely clear conscience since I've already paid for it. Probably would block it in the firewall, though.
I think my approach may well be completely lawful in some jurisdictions, since it essentially amounts to ‘making the purchased software compatible with the user's device’.
For disc versions or botched official releases gamecopyworld still seems to be there. Back when games still came on discs, i downloaded the crack even before trying to install a freshly bought game.
Ofc, this is mostly a moot point now with GoG. If GoG manages to convince the publisher to let them sell the game without DRM.
Edit @stavros: You and anyone suffering from nostalgia should check GoG regularly :) I probably have most of my childhood games on there now.
There's even active HoMM3 PvP streamer community with several thousands live audience on Youtube and Twitch. There are also addons, and community, for Heroes 4 and 5, but two magnitudes smaller.
Wait what? Wow Heroes 3 is a childhood game of mine. I remember spending hours in the map editor just drawing maps and placing enemies and resources all around.
Glad to see it still alive and kicking! Who to watch?
https://www.youtube.com/user/TheKnownWorld - some informational videos (strategies and such) as well as challenges against computers. Great explanations on the why/how and you get to watch at your own pace. I enjoy these more than the streams. Unfortunately he has run out of challenge ideas I think hehe
I believe that’s not against trojans, but for the legal safety (the game can’t call home and tell its/yours ids). As of trojans, just use well-established, curated torrent forums instead of faceless rarbg/kat/pb alikes.
Still risky. Any piracy of mine stopped once I had enough disposable income (and Steam etc. came along) to more conveniently buy the game. Which is an interesting commentary on the supposed lost sale for every pirate copy: when I couldn't afford it, there was no potential sale actually lost. I certainly understand budget-driven piracy though.
Anyway, if you're running pirate copies of any variety, I'd recommend a sandbox of some sort. VMware Player is free, and in my experience faster than VirtualBox. It won't passthrough a dedicated GPU though so it would only be good for older games. you'd need Workstation Pro to get that. Or a Linux distro like Proxmox that runs a bare-metal hypervisor.
And that's why you install questionable software in a virtual machine that you absolutely monitor with every available tool under the moon first. See where it goes, what it exports and brings back, check for file modifications it does with a file monitoring or file difference tool. Also repeat this test 365 times, one for each day of the year - pretty sure automation comes to mind. And only then you can say with a 50% error margin that the thing you downloaded is safe :P
Actually the various torrent aggregators usually have a comment section and if you don't download 0-days it's already vouched safe/unsafe by the time you get to it.
>sigh. Sure, Linux tells you to “bake it yourself” but at least the Linux hands you the tools to do it and if you follow the instructions, the tools definitely do what you expect of them. I fear Windows just isn’t quite there.
Probably something most of people here can't relate to, but this is something I'm always grateful for all the "modern" language toolings, as someone that is not a dev and uses Windows.
I now can just download source code of various open source projects if in Go/Node/Python, and just run/compile it. They work fine most of times.
I never had the same confidence for any C++ projects, even when the author themselves also use Windows, which is unlikely. I almost never make them work/compile successfully. If the binary isn't provided I just feel doomed.
Thanks for the writeup. To be completely honest, i wish you (and other scammed players) would sue Ubisoft and claim huge sums (maybe to give away to FLOSS game devs?). These huge game corps are avidly exploiting their workers and charging tons of money for unfinished/buggy games in clear violation of all consumer/worker protection laws.
I mean, if the game doesn't work for you, that's conceivable. But that they sell a game that doesn't work for many people, and the problem is widely known and the editor refuses to do anything but still takes money for it... it makes me wanna throw up :)
Hi, author here. On one hand I wholly agree with you. Ubisoft has absolutely no right to go around selling products that don't work - it's abysmal. In my other "how to fix it" post, my first suggestion is to just buy it from GOG, with a link. Don't give Ubisoft your money (I'm pretty sure we won't from now on).
I could have also just pirated it. If I gave up, that's how we'd have done it.
That said, if we'd have done that, I wouldn't have had the fun ripping this piece of software to bits. :)
You mentioned checking the forums, but did you ever try contacting Ubisoft through their support page? If nothing else, I'm curious about what their response would be to an issue that's preventing you from playing your purchased game that is entirely a problem with the way the installer is written.
My partner spoke to some who did and from what I understand there was no resolution. We could maybe have pushed for a refund but I had a bit of time pressure of her leaving for a trip (and I wanted her to have this game for it).
I'm gonna drop their support a link to my writeup, see what happens!
Besides, I had a lot of fun playing with it. There were no doubt easier ways to do what I did but I enjoyed digging! :)
Since you've spelled it all out, I hope they actually take your fix and start shipping it. Not because I want them to benefit from unpaid labor, but because I want anyone else who buys the game to benefit from it without having to find your blog post.
This sort of reverse engineering stuff certainly is fun though. As long as the software isn't heavily obfuscated that is. Before WoW died because of the Blizzard harassment investigation, I tried to reverse engineer Battle.net and the game to create an alternate launcher so I didn't have to see the ads in Battle.net. But both were obfuscated and had anti-debugging features. While I'm sure it would have been possible to figure out, it was too much for me so I eventually abandoned that.
I love your write-up on your process. I've done a couple short explanations before of how patches I've released work, but your blog post is far more thorough and a great read.
I hope so too. I could only imagine that they didn't know why this happened and/or didn't have the budget to investigate the problem. They kind of don't have any excuses now. If they've still got the original sources, it should be a 5 minute fix (rounded up to a day with testing and whatever corporate processes they follow).
Nothing is uncrackable and it was that thought that kept me going with this. I can imagine that deliberately-obfuscated DRM like Battle.net would be a hell of a lot harder than this was though. Technically, it was all there for me to see from the start but I didn't know the way I should approach the problem. Finding that out was a big part of it.
Cheers, I'm glad you enjoyed it. More people have said they liked it than I ever thought would, I'm kinda surprised.
> Don't give Ubisoft your money (I'm pretty sure we won't from now on).
My personal strategy is to only give money after i'm satisfied with a product (at least in the computer world). I never bend to paywalls and will NEVER financially support non-free software because it enables that kind of user-abuse situation to begin with.
> That said, if we'd have done that, I wouldn't have had the fun ripping this piece of software to bits. :)
You can still pirate the game as a quick workaround while you dismantle the original release. Anyway thanks for this read i learnt much about windows debugging (as a non-Windows user).
All the other things such as practicality aside, this is an amazing post all around.
The content is interesting even to someone like me who doesn't really care for modding games or has no more than very bare experience with decompilers and dealing with hex editors.
Writing is a great balance between too dry and too verbose or "edgy". The material is super accessible, and it progresses at a very smooth and steady pace. What started with basic debugging ended up in digging through decompiled code and mapping characters for the fixed path manually to preserve the character count in the .inx file.
I swore I was going to only read the intro and read the rest in the morning, but ended up gulping up the whole thing in one go :(
As others have noted, Process Monitor (ProcMon for short). It’s a really excellent no-nonsense GUI tool. This is a good overview of how to use it: https://www.youtube.com/watch?v=pjKNx41Ubxw
The post mentions using the system monitor to track some events (including registry queries). There's apparently other ways for that (but which the author failed to compile, including the official Microsoft tool), and the monitor can only see 32 XOR 64 bits events, not both.
I've used Process Monitor in the past to track down a mysterious "cannot open file" error. It readily listed the file opening attempt the software made, among a ton of other events.
I wonder if the Windows program compatibility settings would have helped. One should be able to mark a program as needing the 32-bit runtime. Googling tells me that the Windows XP SP2 setting should force 32-bit mode.
One of the amazing things about doing stuff like this is the forum discussions, tutorials, irc logs, and mailing lists that detail every step and exploration and tool. Cracking a keygen, creating trainers, using hex editors, and so on down the game piracy, cheating, editing, and modding rabbit hole is incredibly rewarding and occasionally useful in the real world.
It's worth doing at least once for anyone, but I think it will get harder for people as more content ends up ephemeral, unsearchable, or locked inside walled gardens.
also, that might be dated, so additionally search around for 'Ghidra'. Iirc, hackers at the NSA convinced their bosses the US would be more secure if the gen pop had access to their tools. Cool stuff.
> It never ceases to amaze me how anyone can reason through decompiled code.
How so? I'm very much so a nascent programmer, but I've learned the most by decompiling other's code and seeing what works and what doesn't. When I see good apps, I guess I make the (sometimes specious) assumption that whoever wrote it likely also knows how to write pretty well.
I've also done a ton of troubleshooting at a past support position via decompiler since the Dev Team was sometimes...sparse with details :)
It's one of the things I do like about programming, it's just a big logic puzzle to break down. Sometimes the logic harder to follow, but there is a way to understand it. My biggest mental growths have been just seeing how other people accomplish goals I want to accomplish, and understanding what does and doesn't work well. Especially with major developers, it's really interesting to see how/why they do the things they do as their needs are way different than in-house app needs.
I think you mean "debugger", not "decompiler". To me (who has never done it) "decompiling" is looking through a bunch of hex dumps and code skeletons with all the names replaced by "function_3" and "var_1", because you don't have access to the source or the ability to run a debugger -- only the compiled binary. That's obviously much harder than being able to debug or read the source code with comments (which is already hard).
I don't have any C# projects to decompile so let me ask you, do you typically use this with projects that have source available so you are essentially attaching a debugger to their source, or are you looking at a bunch of generically named, comment-stripped decompiled functions like I described above?
The latter. The code was very straight forward in most cases and I just saw the raw logic. Sometimes I was able to get on good terms enough with a Dev to get them to explain their logic, but usually the code stood on its own.
But Generically named is not appropriate here, as at least with this job, we had really good devs, and they would get slapped pretty hard for non-intuitive naming. The Dev Leads were very careful about naming schemes and the end result was that it was pretty simple to understand what something was related to.
DotPeek also makes a lot of this work __very__ convenient with things like the stack trace explorer and its navigation tooling.
I have started reading this with the assumption "incorrect or absent registry key" and it paid off.
What a pain in the bosom were those registry keys. Can you imagine that for some time, The Registry was considered a Good Thing. GNOME tried to roll out its own before defecting to Mac ways.
What's the Mac way you're talking about? How is it different from Windows registry? I'm not so familiar with Windows, but the way i understood it was that the registry was just a very limited and inefficient file storage like we have on libre systems.
So, I have a meta question: how does one go doing writeups like this? I mean, I kinda tried once post-factum, but I feel details are already starting to get blurry at that point in my memory (esp. of all the failed paths, but also byte offsets, checked fields, Google searches, etc.), as well as the order of events. OTOH, I can hardly imagine doing even such detailed screenshots on every step while actually hacking, as I assume it would slow me down like crazy and most probably break my flow. So, what's the trick??
Hi, I'm the author. I write a lot of technical software docs for a living so I'm no stranger to writing, but this was my first attempt at such an informal writeup.
I started trying to fix it on a Friday evening and gave up after I couldn't get the "abort -> No Operation" thing. When I came back a couple of days later, I realised how I was going to proceed, but wanted to write it up. I made sure the thread I was pulling made sense (and thus I was confident I'd get to the end of this), stopped, and wrote the writeup to that point retrospectively. I also went back and recreated some of the screenshots.
From then on I played with the software for a bit until I "hit a breakthrough", stopped, and wrote the story and took some screenshots, then worked on the software until the next "breakthrough". I wanted this doc to record offsets and methodology so I made sure to include that wherever I could. I also used the document as a "rubber-duck debugging" aide, writing it for someone unfamiliar to the project.
I then polished/edited it (rushedly, without too much care) the day after and put it up. You can see my shift in methodology a few times where I mess up the past and present tense and with how some bits have considerably more detail than others.
As this is my first, I don't know if I'd do it the same way again. I've got a HW hacking project on the go and while I've taken loads of pictures, I think I'll probably be writing that up fully retrospectively.
Thanks a lot for the reply!! FWIW, I didn't notice the change of tenses or other stuff at all, found the whole piece very engaging and interesting! (Though admittedly skimmed some details that I didn't care enough about :P)
As for rubber-duck debugging, that's a benefit I didn't think of, thanks!
I wrote this style of blog all the time. When doing any kind of "discovery", I always just open notepad.exe and write some keywords, short notes, and reference URLs (most important) along the way, not specifically for blogging, but just need them for my own process.
Once done, and feel like I can write a blog about it, I would redo the whole thing (and take the screenshots) for the blog article.
Thanks for the reply!! So basically working notes, makes sense, and I vaguely thought about that too; although it would appear they somehow don't seem to work that well in my case for this purpose; I need to think about it. As to the "redo" step, that is something I didn't think of, but sounds like a really good idea, thank you!
For work i use a tool called Snagit to queue up screen captures then a pen and paper to scribble notes.
The two together along with my memory and the order of open tabs is enough to put together "good enough" documentation showing the discovery and fixing process.
I skimmed through the first 3/4 of this article screaming "Process Monitor!" until the author finally cracked that tool open. It's a wonderful utility that's bailed me out of jams like this in the past.
It wound up being a WOW6432Node issue. I felt the transition from 32-bit to 64-bit was handled a lot less cleanly by Windows designers than their previous transition from 16-bit to 32-bit. Hacks like Program Files (x86) were particularly offensive.
What has happened to all the scene crackers? It strikes me they would have this polished off in a matter of hours.
Because he was basically navigating all their techniques (decompilation, bypassing checks, file formats, locating key locations, patching binaries, etc).
Basically a game designed (and harcoded to some extent) for 32 bit windows doesn’t work on 64-bit Windows. This is an old problem that a lot of software faced during the switch in the 00s.
Installing it in a VM on XP would have probably achieved the same result.
Ubisoft changed the reg key of the base game from it's retail key to "Uplay Install 87" and the expansion had no idea to look for that key at all. If you used the Ubisoft copy of both games, the expansion pack would never have found the base game.
I don't actually think it's malice. I think it's just a matter of unforeseen consequences combined with an inability to take corporate responsibility for their own products.
The reg key they've changed in the base game does have some Ubisoft specific information so I expect they did that in order to allow the game to work well with their delivery service. They tested it and it worked.
They presumably just didn't think to test the expansion installer or perhaps even worse, weren't permitted the funding to explore all the potential knock on effects.
Since noone is fixing it, despite there being many service tickets about it, I can only think that the engineers don't know what the issue is.
I would suggest to use procmon.exe, all file and registry accesses could have been monitored without any disassembly and the problem could probably have be resolved much easier.
Sorry my bad it is the very last tool used, which does in fact lead to success, I guess documenting all this other stuff might help somebody somewhere, or at least persuade people to skip the superfluous efforts and just go right to procmon
I also think that if the author here used that in the first place they would have arrived at the registry problems much sooner. ProcMon is often the first thing I reach for when dealing with a 'missing files' kind of problem on Windows.
I was looking how to automate procmon on CI and found this (but info there might be bit outdated, had to reset my procmon registry to get it back to work) - https://gist.github.com/balaprasathr/ae424eec0e9e2860aa84a85... and whole article that goes deep into it - but can't find it now - I think I've stumbled on to it from the link above.
> I also think that if the author here used that in the first place they would have arrived at the registry problems much sooner.
You're absolutely correct. Doing this again, I'd probably get to start from the middle. I went the way I did because I was essentially starting it blind - technically capable but with no idea how one should do this. Discovering and reasoning my way through potential causes and tools helped it be a massive learning experience and I'm glad I did.
Also Rohitab Batra's API Monitor v2 - http://www.rohitab.com/ - very powerful - especially if you are hunting down who uses "getenv" (well not really getenv, but you get the picture)
And there is "strace" (not the one from cygwin/mingw, which mostly traces apps written for their runtime), but from DrMemory's - https://drmemory.org/page_drstrace.html
Then you have the realtively recent Detours released, and tons of other tooling TBH, just all over.
API Monitor is an amazing tool that I've used a few times in the past when procmon wasn't enough. But I wish the author would either return to working on it or open source it. As it is, many calls it can capture are opaque because it only captures the address that a parameter is pointing to instead of following the pointer to get the actual data.
I remember once, a few years back, there was this website where I was supposed to submit something, only that the submission page couldn't load. My friend thought that that was the end of it, but I decided to try to poke around.
Back then I was quite unacquainted with http but I started with what I knew, downloading the page source, figuring out what was the link or call that was failing, then testing it with curl. I eventually managed to figure out that the problem was caused by a missing header in the http request so I installed some random browser extension that patched http requests and voila, it worked!
Still remember the amazing feeling when the page loaded. My friend thought I was a wizard