Rewriting at Runtime. Ex: Pokemon

programming
1

I watched a few Games Done Quick videos from earlier this year and while some were pretty boring (just get from point a to point b while avoiding encounters as much as possible kind of thing), this one stuck out at me. And while the idea of doing this isn’t anything new to me, being able to watch someone doing it was pretty cool.

Taking advantage of some overflow exploits this guy is able to beat the gameboy game pokemon in around 20 minutes:

This reminded me of kirupa’s IIFE tutorial where at the end there’s mention of how your code is an open book. That’s much more the case now on the web what with the developers available in most desktop browsers (at least as far as client side code goes). But to see this happen within a closed game system using only the interface explicitly provided to the user, I thought, was interesting. From the video:

…and that’s where I can pretty much access memory addresses that are not supposed to, and I can use my ID inventory as a really simplistic hex editor to complete the game pretty much any way I choose.

If you didn’t watch it, he does this by editing the map pointer to put his character at the end-game location.

These are the things you have to think about when attempting to write secure software. It’s not easy. And you’d be surprised how far into software people go to beat the system.

1 Like
2

It’s an interesting topic.

Huh, Kirupa sure is a genius for coming up with the idea to put that note in there. He and I were talking about that tutorial and he brought up how code can be similarly-open in languages/frameworks like .NET, where you can reflect on the program’s bytecode easily.

The live performance aspect of it is certainly interesting. (I’m in robot mode so I’m going to continue to not come up with interesting words.) Who knew that eSports would glamorize hex editing?

But it’s not like people gathered their knowledge of the games internals purely by playing the game. Without reverse engineering tools like emulators, MHS and Cheat Engine, it would be a lot more difficult for anyone to stumble upon glitches that involve writing out long sequences of memory and/or manipulating pointers.

(screenshot from @sockfolder)

The people who generally find these things are sitting around playing the game watching hex-addressed values change. Luckily for them, other people have found or come up with names for those values, either because game developers left the symbol names in the shipping binary, or because they used classic GameShark-style reasoning (I have 73 arrows now, but had 45 earlier. Let’s look through memory snapshots to find the (likely) one address that happened to have that sequence of values.)

I’ve tried my hand at repeating some of the less-complicated glitches on my 3DS. So far, I’ve gotten out of the forest without ever getting a sword or beating the Deku tree, and I’ve gotten into the Deku tree and Jabu-Jabu’s belly as an adult.

But the things I’ve done are pretty simple in comparison to what others have done.

Indeed. There was a sort-of fun assignment in college that was your typical buffer exploit project: You’re given a binary (I think with symbols removed, so you couldn’t read the disassembly as easily), which asks for user input when it runs. You know that the text input code is using a vulnerable form of strcpy… or at least you should know that given that I assume that’s what the previous lecture in the class was talking about. Anyway, the goal is to use your input string to get the program to do something other than crash or print the “you suck” message. Generally the resultant input string looks something like:

Kͭ҉͎i̺̔ͬ̏ͮ̕r̨̹̾́u͊͜p̢̰͉̯͔̅ͨ́̂̃a̴̠̝̐͐̽̎͌̔͒ ͈̇C̱͉̗̈̉͗̽ͤ̒͜ͅh̶̘̜̒̂ͯͬ̒̃ͦì̌ͧ͗̋n̲̲͉̺͖͖ͬͥͦͨͪ̂n͗͘a̷̫̻͕͚ͥͭͪ̑ͥ̅ͮt͎̣̩̄͋̎͜h͚͕͐̐̎a͎͖̙̳̠̮ͯ͑̊ͨ͠m̱̑̌̇̓̚b̮͖̝̤̺̍i̵̠̹̦͕̗̬̻̓

… because you’re disregarding the original intent of the input field and writing binary via Unicode, or ASCII, or whatever.

Requoting because I had a different angle on this. You didn’t imply the opposite of this, but game developers generally aren’t (and certainly weren’t in the past) trying to write secure software. As long as some totally game-breaking glitch isn’t encountered by 9x.y% of players (where x and y depend on your quality standards), then I don’t think anyone’s going to spend time trying to fix it. You probably know that from your many roles at Adobe. Online games are a bit different, since if one person finds a glitch, they can either abuse it to get to the top of a leaderboard, and/or spread it around so that lots of people know it and ruin the (perceived) experience.

But yeah, I wouldn’t be happy writing encryption software or banking software or similar. There are people who enjoy that sort of stomping out of edge cases, and it’s nice that they exist.

Hey, sometimes it’s as easy as prepending a _ to someone’s URL folder name in an ActionScript contest… :smirk:

3

If anyone can do something like that without those tools, they need to be dissected and studied :blush:

Wow that’s cool! The closest I’ve done, which really isn’t the quite the same, is reverse engineer the Wii Mii data file saved to Wii remotes for my online Mii editor. And of course 3 days later the format was posted online by some other group that reversed engineered it. At least I got to check my work…

Whoa. That was pretty intense. I can’t even tell you how many hours I dumped into that one and still never beat it. This makes me want to cry.

This is true. And your point about the leaderboards is on target as well, and even sometimes they don’t get fixed. I saw a talk by a game maker who said you pretty much have to run the game on the server to have any kind of confidence in your leaderboard data because there’s so many ways people can, and will, try to hack it.

I also took some fuzzing training which really opened my eyes to what people are capable of given a piece of software. And its not just getting into it, but also about identifying patterns and crazy stuff like that - beyond what I can remember.

:innocent: