Glossary: Difference between revisions

Line 19:

;{{Anchor|Breakpoint}}'''Breakpoint'''

:See [[~~#Breakpoint|~~breakpoint]].

:See [[breakpoint]].

;{{Anchor|Buffer overflow}}'''[[Buffer overflow]]'''

:To write more data into a buffer than its size allows. The data will end up being written into adjacent memory areas, causing memory corruption.

:To write more data into a buffer than its size allows. The data will end up being written into adjacent memory areas, causing [[#Memory corruption|memory corruption]].

;{{Anchor|Corruption}}'''Corruption'''

:See [[#Memory corruption|memory corruption]].

;{{Anchor|Count byte}}'''Count byte'''

Line 47:

Line 50:

;{{Anchor|Memory bank}}'''Memory bank'''

:In the GameBoy, a segment of the ROM or the SRAM, mapped to a consecutive segment of the 16-bit GameBoy address space. With the exception of ROM bank 0 (the "home bank"), the banks are "switchable", i.e. they share the same address space ($4000~$7FFF for switchable ROM banks, $A000~$BFFF for SRAM banks), and are "switched" into and out of the accessible memory space with special instructions (technically, an "impossible write" to the ROM). This is to solve the problem that the space needed for those areas in a large game can be much larger than the 64KB that the 16-bit address space allows.

;{{Anchor|Memory corruption}}'''Memory corruption'''

:Modification of a memory location by a piece of code that is never supposed to modify it, which may cause important data be overwritten in a potentially hard-to-discern pattern. This is usually caused by [[#Buffer overflow|buffer overflow]], but may also result from other forms of pointer manipulation; the [[ZZAZZ effect]] is an example.

:This phrase should not be used when different data intentionally share the same memory location (e.g. the player's name and the grass encounter table in the [[old man trick]]), or when the code writes to the intended memory location an invalid value due to a logic error (e.g. changing the [[#Item count|item count]] to 255 with [[item underflow]]).

;{{Anchor|Overflow}}'''Overflow'''

Line 68:

Line 75:

;{{Anchor|Stack corruption}}'''Stack corruption'''

:Memory corruption in the [[#Stack|stack]] area. This kind of corruption is usually highly disruptive to the execution flow because it may easily change return addresses on the stack, causing <code>ret</code> instructions to jump to unintended addresses. As a result, it is likely to crash the game, but when controlled it can also be used for many exploits, including [[arbitrary code execution]].

:[[#Memory corruption|Memory corruption]] in the [[#Stack|stack]] area. This kind of corruption is usually highly disruptive to the execution flow because it may easily change return addresses on the stack, causing <code>ret</code> instructions to jump to unintended addresses. As a result, it is likely to crash the game, but when controlled it can also be used for many exploits, including [[arbitrary code execution]].

;{{Anchor|Stack pointer}}'''Stack pointer'''

@@ Line 19: / Line 19: @@
 ;{{Anchor|Breakpoint}}'''Breakpoint'''
-:See [[#Breakpoint|breakpoint]].
+:See [[breakpoint]].
 ;{{Anchor|Buffer overflow}}'''[[Buffer overflow]]'''
-:To write more data into a buffer than its size allows. The data will end up being written into adjacent memory areas, causing memory corruption.
+:To write more data into a buffer than its size allows. The data will end up being written into adjacent memory areas, causing [[#Memory corruption|memory corruption]].
+;{{Anchor|Corruption}}'''Corruption'''
+:See [[#Memory corruption|memory corruption]].
 ;{{Anchor|Count byte}}'''Count byte'''
@@ Line 47: / Line 50: @@
 ;{{Anchor|Memory bank}}'''Memory bank'''
 :In the GameBoy, a segment of the ROM or the SRAM, mapped to a consecutive segment of the 16-bit GameBoy address space. With the exception of ROM bank 0 (the "home bank"), the banks are "switchable", i.e. they share the same address space ($4000~$7FFF for switchable ROM banks, $A000~$BFFF for SRAM banks), and are "switched" into and out of the accessible memory space with special instructions (technically, an "impossible write" to the ROM). This is to solve the problem that the space needed for those areas in a large game can be much larger than the 64KB that the 16-bit address space allows.
+;{{Anchor|Memory corruption}}'''Memory corruption'''
+:Modification of a memory location by a piece of code that is never supposed to modify it, which may cause important data be overwritten in a potentially hard-to-discern pattern. This is usually caused by [[#Buffer overflow|buffer overflow]], but may also result from other forms of pointer manipulation; the [[ZZAZZ effect]] is an example.
+:This phrase should not be used when different data intentionally share the same memory location (e.g. the player's name and the grass encounter table in the [[old man trick]]), or when the code writes to the intended memory location an invalid value due to a logic error (e.g. changing the [[#Item count|item count]] to 255 with [[item underflow]]).
 ;{{Anchor|Overflow}}'''Overflow'''
@@ Line 68: / Line 75: @@
 ;{{Anchor|Stack corruption}}'''Stack corruption'''
-:Memory corruption in the [[#Stack|stack]] area. This kind of corruption is usually highly disruptive to the execution flow because it may easily change return addresses on the stack, causing <code>ret</code> instructions to jump to unintended addresses. As a result, it is likely to crash the game, but when controlled it can also be used for many exploits, including [[arbitrary code execution]].
+:[[#Memory corruption|Memory corruption]] in the [[#Stack|stack]] area. This kind of corruption is usually highly disruptive to the execution flow because it may easily change return addresses on the stack, causing <code>ret</code> instructions to jump to unintended addresses. As a result, it is likely to crash the game, but when controlled it can also be used for many exploits, including [[arbitrary code execution]].
 ;{{Anchor|Stack pointer}}'''Stack pointer'''

Glossary: Difference between revisions

Navigation menu

Search