53,617
edits
Arbitrary code execution: Difference between revisions
m
→Methods: typos fixed: easily- → easily
Blueapple128 (talk | contribs) m (→Cause) |
m (→Methods: typos fixed: easily- → easily) |
||
| Line 16: | Line 16: | ||
After discovering a glitch that causes the program counter to jump to RAM, it is often the case that the initial location jumped to is hard for the player to control (such as sound bank data). Thus, it is common for most arbitrary code execution setups to first spell out only a small amount of code there, forming another jump instruction that will lead to a second location in memory that is easy for the player to modify. Examples of such locations can include [[party]] or [[PC]] data, [[Bag]] contents, [[Box]] names, and Pokémon [[nickname]]s. Once this has been done, the player may readily fill the second memory area with arbitrary code for the console to execute, and then perform the initial jump (by using the glitch item, glitch move, etc.), which will perform the second jump to the filled code and cause it to be run. | After discovering a glitch that causes the program counter to jump to RAM, it is often the case that the initial location jumped to is hard for the player to control (such as sound bank data). Thus, it is common for most arbitrary code execution setups to first spell out only a small amount of code there, forming another jump instruction that will lead to a second location in memory that is easy for the player to modify. Examples of such locations can include [[party]] or [[PC]] data, [[Bag]] contents, [[Box]] names, and Pokémon [[nickname]]s. Once this has been done, the player may readily fill the second memory area with arbitrary code for the console to execute, and then perform the initial jump (by using the glitch item, glitch move, etc.), which will perform the second jump to the filled code and cause it to be run. | ||
For more complex exploits, the above "two-stage" jump setup may not be enough as the game will eventually run out of space in the easily | For more complex exploits, the above "two-stage" jump setup may not be enough as the game will eventually run out of space in the easily modifiable second location (the Bag/Box/etc.) to continue spelling out code. It is possible to extend the setup to three stages by writing code in the second location whose effect is to write more code to a third location that contains more space but is hard for the player to modify directly<!-- such as what? couldn't find a direct example; does someone with more experience know what location is being written to in the linked video? -->. Once enough code has been written to the third location, the player may substitute the second location's code for code that jumps to the third location, then perform the glitch which will execute three jumps and run the desired code.<ref>https://www.youtube.com/watch?v=D3EvpRHL_vk</ref><!-- This multi-stage setup is specifically *NOT* TAS-exclusive; in fact it's the most viable substitute for jumping to controller input when the goal is to show off a demonstration unassisted rather than speed. --> | ||
Even more advanced setups may jump the program counter to controller input<ref>http://tasvideos.org/2187M.html</ref><!-- linking to the older and now obsolete run as it demonstrates this better -->, allowing a theoretically unlimited amount of code to be entered and run on the fly without having to store it all beforehand. Current demonstrations of this type of setup have so far been TAS-exclusive (as controller input is polled on and can change every frame, 60 times per second, as well as due to the very large amount of code that must be desired for such a setup to be worthwhile unassisted<!-- clarification: even if realtime is involved, if the desired exploit (e.g. programming Pong/Snake) is small enough, no one's going to spend the time to craft an unlimited input buffer when the storage space within the game's RAM is enough. A desired exploit has to be really huge to no longer fit inside all of the game's RAM and require jumping to controller input for more space. Code this large would take on the order of hours to input at realtime speed, which makes it unlikely. This sentence is NOT saying that programming the controller input loop itself is a large amount of code; it's saying that there's no point in programming such a realtime controller input loop in the first place unless the desired exploit (which is programmed in AFTER the input loop) is large enough to require it. -->); however as the setup code can be arbitrary, it is no doubt possible to program an input loop that is slow enough to be performed in real time. | Even more advanced setups may jump the program counter to controller input<ref>http://tasvideos.org/2187M.html</ref><!-- linking to the older and now obsolete run as it demonstrates this better -->, allowing a theoretically unlimited amount of code to be entered and run on the fly without having to store it all beforehand. Current demonstrations of this type of setup have so far been TAS-exclusive (as controller input is polled on and can change every frame, 60 times per second, as well as due to the very large amount of code that must be desired for such a setup to be worthwhile unassisted<!-- clarification: even if realtime is involved, if the desired exploit (e.g. programming Pong/Snake) is small enough, no one's going to spend the time to craft an unlimited input buffer when the storage space within the game's RAM is enough. A desired exploit has to be really huge to no longer fit inside all of the game's RAM and require jumping to controller input for more space. Code this large would take on the order of hours to input at realtime speed, which makes it unlikely. This sentence is NOT saying that programming the controller input loop itself is a large amount of code; it's saying that there's no point in programming such a realtime controller input loop in the first place unless the desired exploit (which is programmed in AFTER the input loop) is large enough to require it. -->); however as the setup code can be arbitrary, it is no doubt possible to program an input loop that is slow enough to be performed in real time. | ||