Even though this technically isn't a speedrun, I think it would be incredibly cool to watch. Basically the idea I'm having works like this:
1) Find a bug in a game that "randomly" corrupts memory in the game.
2) Program (in assembly) a mod to a game, say one that makes Mega Man shoot Mario fireballs.
3) Luck manipulate the bug to insert the modifications in the game.
This technique could also be used just to overwrite random memory addresses to whatever you want, say a counter that says what levels are unlocked, you could skip levels.
The general idea is you need to be able to exploit a variable that is an address the game loads to and another variable that is written there. It could be tough to find an exploit of this kind, but I'd say they've even been found already.
Besides making a sweet speedrun and or impressive video, people could implement these techniques on the actual system to hugely impress friends. Is this at all feasible, or am I crazy?
The latter, unless I'm incredibly mistaken.
I'm not saying it's impossible, but writing functional code completely by chance is about as likely as a human being eating a bag of Lays and crapping out Chuck Norris.
I mean, it's not a "technique". It's a hole in the programming that you don't really have that much control over. You might want to read up on the Sketch glitch from FF3. It's some pretty interesting stuff, and IIRC, is exactly what you're talking about.
Dragon Warrior 3 is especially vulnerable to memory corruption bugs, look in the Dragon Warrior 3 thread for the "Dream Ruby Bug". It's a memory corruption bug targeted at the area around your stats. The only operation done is 16 bit subtraction by 2 to aligned memory addresses, but that is enough to unlock Return to the endgame areas!
What's especially weird about this bug is that it is a function of the ENTIRE first 256 bytes of RAM! Yep, the volatile zeropage. The behavior of the bug is mostly unpredictable.
The thing is, all the runnable program is stored on the cartridge. The ROM image is called Read Only Memory for a reason. You can't write code to it, nor can you change any branch/jump target to anything useful. Your best hope is a stack overflow to trample a subroutine's return address, but that would be one serious bug to set off. There's no variable size data reading.
I'm skeptical that any game that survived even FF6 level quality assurance would be in any danger. Then again, see the Sketch Bug.
Super Metroid has a few glitches on par with that (most well-known is the space/time beam). But to actually program something to make a significant mod... that's not really feasible unless a bug lets you rewrite RAM however you please, as easily as a hex-editor. And even then it might still be real difficult to call the code when and how you want it (with free reign with a hex-editor, though, I know it'd be a piece of cake in Super Metroid)
If someone found such a bug or something that works as a hex-editor and a viable method of accessing RAM as code, I wouldn't mind programming the 'mod' for them. :P
::edit:: On the topic of ROM and RAM, there is no way to rewrite existing codes in ROM. Using RAM as program space is a bit unorthodox (I don't know if the NES can do it at all), but IIRC FF6 does actually do so a few times, and pointers to code are often stored in RAM. In a LoROM game it'd be easy to hijack such pointers to a bit of unused RAM in 7E:0000 - 7E:1FFF, and if necessary, JML from there to a larger chunk of unused RAM.
Finding a good unused chunk of RAM may likely be the hardest thing to do, actually.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
::edit:: On the topic of ROM and RAM, there is no way to rewrite existing codes in ROM. Using RAM as program space is a bit unorthodox (I don't know if the NES can do it at all), but IIRC FF6 does actually do so a few times, and pointers to code are often stored in RAM. In a LoROM game it'd be easy to hijack such pointers to a bit of unused RAM in 7E:0000 - 7E:1FFF, and if necessary, JML from there to a larger chunk of unused RAM.
Finding a good unused chunk of RAM may likely be the hardest thing to do, actually.
I don't know about other systems, but I've seen many games on the GBA that run code in RAM. I actually got the idea for this technique by looking at a codebreaker code for GBA. I couldn't figure out how it was modifying the code, turns out it was modifying a routine that was run in RAM.
After thinking about it for awhile, this idea seems less doable than I thought before, but still not impossible.
Kejardon, mind directing me to some info about the Super Metroid and FF6 glitches you mentioned?
The glitch in Super Metroid I referred to dumps a graphic image into RAM where it DOESN'T belong. It overwrites a ton of variables that drastically change the current status of the game. Triggering the glitch different ways will change the RAM differently - I haven't looked into it enough to figure out how.
There is no known way to call said RAM as code though, and it'd be basically impossible to program how you'd want to anyways.
I wasn't referring to a glitch in Final Fantasy 6, I was saying that it loads code into RAM and then executes it. I don't know how often it does it, but I do remember seeing it happen during the intro scene where Terra, Biggs, and Wedge are marching to Narshe.
I don't know of any way to edit the code before it's run though.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
::edit:: On the topic of ROM and RAM, there is no way to rewrite existing codes in ROM. Using RAM as program space is a bit unorthodox (I don't know if the NES can do it at all)
Look no farther than "The Legend of Zelda". This game copies lots of code into Battery-backed RAM and executes it!
What other NES games also run code from ram?
M.C. Kids
Battletoads
There's probably a huge long list of them. Because the vblank period is so short, you can write more data to video memory by constructing code and sending it to the screen that way.
I'm not saying it's impossible, but writing functional code completely by chance is about as likely as a human being eating a bag of Lays and crapping out Chuck Norris.
I don't think the idea was "find a bug which corrupts memory in different ways and see if by chance it produces runnable code". I think the idea was "find a bug which corrupts memory in *predictable* ways and then abuse this on order to write machine code (byte values of some routine you have written and compiled beforehand) which produces some runnable routine". In other words, if the compiled machine code you want starts with the sequence 120, 56, 38, 251, find a bug in the program which corrupts the memory in a way that you can create that sequence. This could in theory be achieved, for example, by a selection and ordering of inventory items, etc.
Of course, as has been pointed out, most consoles don't run code from RAM, so this is just not possible.
Of course, as has been pointed out, most consoles don't run code from RAM, so this is just not possible.
Only if you can corrupt the stack, you can make it run code from RAM -- but only new program code also created via memory corruption; it cannot change existing program code.
I don't think the idea was "find a bug which corrupts memory in different ways and see if by chance it produces runnable code". I think the idea was "find a bug which corrupts memory in *predictable* ways and then abuse this on order to write machine code (byte values of some routine you have written and compiled beforehand) which produces some runnable routine".
Exactly what I was wanting to do. Also the GBA and several games dwedit mentioned run code in RAM so overwriting those could possible lead to what I am looking for. Can anyone recommend a good resource for glitches/bugs in games?
Yes, as Bisqwit pointed out, it's not enough to be able to write something to RAM and that the console supports running code from RAM, you must somehow be able to modify the existing game code. The very minimum you need is to add some jump to your new code somewhere in the existing game code. (I assume that in most console games all jumps are hard-coded into the machine code, ie. they do not contain jump addresses read from a variable or such, which could be abused.)
And of course even if you find a memory-corrupting bug in some game, the chances that it's such a bug that you can abuse it to write any values you want to the desired memory address are rather small. :)
I assume that in most console games all jumps are hard-coded into the machine code, ie. they do not contain jump addresses read from a variable or such, which could be abused.
This wouldn't be accurate at all. Many, MANY jumps are actually done according to data in RAM. Overflow an index table, or rewrite a particular pointer in RAM, and walla, you have a subroutine call to RAM.
Actually overflowing the table or rewriting the pointer would be a tricky feat though.
Breaking the stack in a useful way actually sounds a bit harder than that. It's pretty common to break the stack in a non-useful way though. :P
Warp wrote:
And of course even if you find a memory-corrupting bug in some game, the chances that it's such a bug that you can abuse it to write any values you want to the desired memory address are rather small. :)
Rather small is an understatement.
Saying that 'Rather small is an understatement' is an implied understatement.
This is the sort of thing comparable with throwing a penny 20 feet and manage to get it to land and stop perfectly on a itty bitty pedastal. On the penny's side. With only about 10 tries.
The most likely way I can think of this being accomplished is with something like a demo recorder that records button presses every frame and writes that to RAM, and then some bug to manage to call that RAM as code.
I do not know of any such demo recorder. Nor do I know of any bug that allows you to call any particular spot of RAM you want as code.
I kinda doubt anybody's going to take me up on my offer anytime soon. :/ It'd be simply awesome if it ever did happen though.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
There are some NES games (like Battle City and Tetris) where you can change level map, thus modifying some areas of RAM. But it's still unclear how to call this new code.
I wish with Final Fantasy 6 US 1.0 that you could use Sketch to change the byte of memory that specifies whether you're in the World of Ruin. That would be a massive speed improvement =)
Joined: 11/17/2005
Posts: 278
Location: Massachusetts, USA
DeHackEd wrote:
I'm skeptical that any game that survived even FF6 level quality assurance would be in any danger.
The running joke is that there was none. :) But really any game that large with that many quirky special cases is doomed to be buggy anyway. Realistically, who is going to get Gogo and then the Gem Box in the same sitting? Or play through the game to the floating continent and lose without saving? I can't blame them for not testing Relm enough, who is very rarely ever in your party anyway. The reason for the joke is because Vanish+Doom, mblock ?= block, and walking through moving npcs are all kind of dumb mistakes.
Myria wrote:
I wish with Final Fantasy 6 US 1.0 that you could use Sketch to change the byte of memory that specifies whether you're in the World of Ruin.
Those memory addresses are too low and out of reach. The SG works just like the Super Metroid bug: the game loads a bitmap from a non-bitmap part of the cartridge, runs a decompression routine on this random data (uh-oh), and then paints it to the screen (oh crap). In FF6 we can't manipulate either the values or the corrupted area because we can't change the cartridge data or the code. The funny thing about the SG is that nukes a large portion of RAM, but it's mostly useless areas that get hit. The game copies a bunch of data structures and each battle takes place in a new copied instance of your game state. Those copies and some graphics are what get hit. The only reason you get to keep your corrupted inventory is because the game does an explicit copy of your in-battle inventory over your original one. (White lie: the contents of the overworld map and some camera variables may also be hit, but never in a useful way. Even if Relm could build land bridges it wouldn't be useful because you get her late, both times.)
But on the topic of finding a bug that allows for pinpoint, manipulatable, corruption with the ability to execute the payload, how about larger complicated games with scripting systems? The scripting system might be vulnerable. The example given at the start of the thread was making Mega Man shoot Mario-style fireballs. Thanks to the equip anything bug in FF6j it is possible to alter the attack animations intentionally to produce a result that is new to the game. If the goal is to make the game look like it has been modded, then mission accomplished. Unless you've got a bet for a specific mod or something.
