StarCraft: Remastered – Emulating a buffer overflow for fun and profit [pdf]
0xeb.net
0xeb.net
So much history is lost because game companies don't archive their assets.
* http://au.ign.com/articles/2013/06/27/original-kingdom-heart...
* https://adventuregamers.com/forums/viewthread/7766
* I also thought that the original Okami assets were lost with the closure of Clover Studio but I can't find a source.
Without a central location where all the IP is stored, it becomes easy for older pieces to fall off the radar during company transitions, system upgrades, whatever. I suspect as people move away from large company wide SMB/NFS shares this is once again going to start being a common story. Particularly as people try to shrink their online storage footprint and move things to "archive" only. I've worked at places where I've had to repeating justify why i'm eating up a $LARGE_NUMBER GB for the last $SOME_NUMBER released versions of the product because the build process triggers a complete archive of the entire artifacts directories when a release build is specified.
Online storage be it, S3 buckets, or LTO backed NFS shares have real costs associated with them, and invariably IT comes along and starts asking why they have to upgrade their systems, or justify their OPEX numbers. Having a few TB of build artifacts that are rarely (if ever as the versions get older) referenced sits right up there with keeping previous employee's machine images, or home directories live.
The problem though is that putting things in an offline archive is just the first step in forgetting it exits. At that point your basically saying that in 10-15 years the only remaining copy of the data is going to be the git repo on some guys laptop sitting in his attic (the modern version of the floppies in shoeboxes).
1: https://kotaku.com/guy-finds-starcraft-source-code-and-retur...
EDIT: found the story, and i was wrong about the sleeve looks like it was a regular jewel case, but still.
The investigation into how this could happen is still ongoing, but the reason that's been reported so far is that someone just lost the keys.
If something like that can happen to government documents, just imagine what could happen to general company assets.
[1]: http://www.abc.net.au/news/2018-01-31/cabinet-files-reveal-i...
[1] https://ggtriple.wordpress.com/2014/12/10/no-expansions-in-m...
That's why the plans for "Baldur's Gate HD" were downgraded to "Baldur's Gate Enhanced Edition" :'(
* http://www.eurogamer.net/articles/2012-12-17-enhancing-baldu...
I was into random-memory-access maps back when (I believe) they were first discovered; we didn't use EUD, but simple resource triggers - e.g. "For player $absurdNumber[0], increase Vespene Gas to $someWeirdValue". It probably wasn't as flexible as the bug described in the presentation, but still allowed for some fun - like runtime terrain changes, or runtime weapon changes (like gun -> nuke). AFAIR that loophole was closed within few weeks of showing up, with patch 1.13e.
Unrelated:
> StarCraft Remastered collects game telemetry (including map information, etc.)
Yes. Of course it does.
Fuck the Internet era.
--
[0] - AFAIR only legitimately usable players in StarCraft were 1-8, player 12 was for "Neutral" critters & stuff; anything above 256 was beyond what the game has reserved space for, and so if you asked for the data of such high-number players, you were accessing unrelated game memory.
> Yes. Of course it does.
> Fuck the Internet era.
Well, to be honest, everything played on Battle.net is visible to Blizzard already and especially now that they support hosting games even when not reachable directly from the internet, there's even more data available (AFAIK map files were only transferred P2P in the old times, and the Battle.net servers didn't care about those at all).
Yes, they did fix it. They made it so you could no longer write using EUDs, but you could still read from what I remember (it's been quite a while, I remember experimenting using EUDs).
> AFAIR only legitimately usable players in StarCraft were 1-8, player 12 was for "Neutral" critters & stuff; anything above 256 was beyond what the game has reserved space for, and so if you asked for the data of such high-number players, you were accessing unrelated game memory.
Yup, though you could set a colors players using a non-default map editor. Doing so would cause odd coloring of units. AFAIR after player 12, the colors weren't explicitly colored. So you got mostly black, or whatever coloring was in the users memory at the time.
The most tragic part is, most users won't even know. There are probably a few EUD maps out there that don't run on SC:R and everyone probably just thinks Blizzard is breaking things unnecessarily.
But more than that, I would love to hear perspective from those who exploited this bug. At the very least, it must be amusing to see some of these things still working even though they really ought not. I mean, a buffer overflow read/write primitive reading and writing from and to data structures that no longer exist? That's really something.
After enough years, a bug stops being a bug and starts being part of the personality of a piece of software or hardware. I like that they cared. And I'm sure, for sake of the some-17k maps making use of it, users will too. I don't play StarCraft, but I'll say this has my interest piqued almost enough to consider buying this and checking it out. At $15, it isn't too hard of a sell, especially knowing the care put into it.
I'd say this qualifies as an Ascended Bug / Ascended Glitch: http://tvtropes.org/pmwiki/pmwiki.php/Main/AscendedGlitch
Much like the EUD bug, this was used by mapmakers, but was patched by Blizzard after it was exploited to run arbitrary code. A workaround for one of the more common use cases (hash tables) was later re-added, but the maps that made use of this bug were permanently broken.
“Don’t reverse engineer our apps. Also, here is why we didn’t patch things, because they would break tremendous value delivered to our platform by people who reverse engineered our apps.”
Y’all remember when Blizzard sued those OSS devs for reimplementing their server protocol in bnetd?
It is incredible the extent to which the game got hacked to make this possible.
Extended Unit Death. A buffer overflow exploit that massively increased the power of the map editor's "scripting language" (called "triggers" in the map editor). It was called Extended Unit Death because the trigger used was intended for the map maker to specify some sort of action upon a player having a certain number of units die. By overflowing the unit field in this trigger you could read from any memory address and by doing the same to another set of triggers that manipulated the death count you could write to any memory address. It was patched out in 1.13 for obvious reasons, however, you can re-enable EUD functionality with custom launchers to play maps that take advantage of the exploits.