2,614
edits
Arbitrary code execution: Difference between revisions
m
→Cause
Blueapple128 (talk | contribs) m (→Methods) |
Blueapple128 (talk | contribs) m (→Cause) |
||
| Line 3: | Line 3: | ||
==Cause== | ==Cause== | ||
Data storage on any machine in general consists of two fundamental types, ROM ({{wp|read-only memory}}) and RAM ({{wp|random-access memory}}). In the context of a game console, ROM consists of the game code which cannot be modified (short of physically tampering with the cartridge), while RAM consists of any data that may change on a continuous basis, including the contents of the save file (SRAM), the contents of the screen display (VRAM), and other variables (such as whether or not the player is currently in a battle, or the current sound(s) that are playing, or any other values that need to be temporarily stored such as in the middle of a formula calculation or routine<!-- registers -->). (Notably, all data stored in the latter two are cleared whenever power to the machine is cut.) | Data storage on any machine in general consists of two fundamental types, ROM ({{wp|read-only memory}}) and RAM ({{wp|random-access memory}}). In the context of a game console, ROM consists of the game code which cannot be modified (short of physically tampering with the cartridge), while RAM consists of any data that may change on a continuous basis, including the contents of the save file (SRAM), the contents of the screen/video display (VRAM), and other variables (such as whether or not the player is currently in a battle, or the current sound(s) that are playing, or any other values that need to be temporarily stored such as in the middle of a formula calculation or routine<!-- registers -->). (Notably, all data stored in the latter two are cleared whenever power to the machine is cut.) | ||
One such temporary variable that exists in virtually any machine of any kind is the processor's {{wp|program counter}}, which points to the memory location where the next line of code is to be read and executed. Under standard conditions, the program counter simply increments by 1 each time a line of code is read, such that individual lines of code are read sequentially; however there are many cases where a line of code will instruct the program counter itself to jump forward or back (such as when certain lines of code must only be executed under certain conditions and are to be skipped otherwise, or when the game needs to wait for a certain condition to be true before progressing, and must continuously check that condition until it is true). Commands that cause the program counter to do this are known as ''jump instructions''<!-- or "branch instructions", but I'm 70% sure that GB assembly instead calls them "jump if zero" and "jump if not zero"; regardless, not quite relevant to the article -->. Naturally, as all game code exists in ROM, all proper jump instructions must point to a location in ROM. The program counter's behavior is simply to blindly read in and execute code at whatever memory location it is pointing to (and then increment itself by 1); thus faulty jump instructions may cause the program counter to start reading in garbage values from an unexpected place and attempt to interpret them as code, resulting in behavior unintended by the developers. | One such temporary variable that exists in virtually any machine of any kind is the processor's {{wp|program counter}}, which points to the memory location where the next line of code is to be read and executed. Under standard conditions, the program counter simply increments by 1 each time a line of code is read, such that individual lines of code are read sequentially; however there are many cases where a line of code will instruct the program counter itself to jump forward or back (such as when certain lines of code must only be executed under certain conditions and are to be skipped otherwise, or when the game needs to wait for a certain condition to be true before progressing, and must continuously check that condition until it is true). Commands that cause the program counter to do this are known as ''jump instructions''<!-- or "branch instructions", but I'm 70% sure that GB assembly instead calls them "jump if zero" and "jump if not zero"; regardless, not quite relevant to the article -->. Naturally, as all game code exists in ROM, all proper jump instructions must point to a location in ROM. The program counter's behavior is simply to blindly read in and execute code at whatever memory location it is pointing to (and then increment itself by 1); thus faulty jump instructions may cause the program counter to start reading in garbage values from an unexpected place and attempt to interpret them as code, resulting in behavior unintended by the developers. | ||