OAM DMA hijacking: Difference between revisions
Jump to navigation
Jump to search
Content added Content deleted
(→Setup (additional arbitrary code execution): Repetition sorry) |
|||
Line 23: | Line 23: | ||
2. (Option 3 - Keeps OAM sprites but at the cost of potentially freezing the game if the HRAM addresses the player chose to change are overwritten again); Another option is to overwrite other HRAM address that don't often change beginning from a relative jump at FF89 (such as to the money coins amount at FF9F) to run additional code (and with a potential series of other relative jumps across HRAM) which can be ended with a ret, without having to ever leave HRAM as part of the routines the player writes. |
2. (Option 3 - Keeps OAM sprites but at the cost of potentially freezing the game if the HRAM addresses the player chose to change are overwritten again); Another option is to overwrite other HRAM address that don't often change beginning from a relative jump at FF89 (such as to the money coins amount at FF9F) to run additional code (and with a potential series of other relative jumps across HRAM) which can be ended with a ret, without having to ever leave HRAM as part of the routines the player writes. |
||
Here is an example for Red and Blue which keeps overworld sprites but disables moving the character, as documented by luckytyphlosion: |
|||
At FF86, write "jr FFF9". |
|||
At FFF9, write "dec a" |
|||
At FFFA, write "jr nz, FFF9" |
|||
At FFFC, write "jp [region]" |
|||
OAM DMA hijacking is useful as a form of 'real-time' arbitrary code execution, allowing the player to perform exploits such as walk through walls in Generation II or writing a [[0x50 sub-tile]] permanently to the beginning of the screen data for Generation I. |
OAM DMA hijacking is useful as a form of 'real-time' arbitrary code execution, allowing the player to perform exploits such as walk through walls in Generation II or writing a [[0x50 sub-tile]] permanently to the beginning of the screen data for Generation I. |