Guest User


a guest
Jan 31st, 2016
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 16.68 KB | None | 0 0
  1. Dragon Warrior III Dream Ruby glitch (aka numbness glitch, item glitch)
  2. =======================================================================
  4. By forming a party consisting of only dead characters, you can confuse
  5. the game into modifying your party's status in useful ways, such as
  6. changing weak armor into strong weapons and getting access to endgame
  7. towns through the Return spell.
  10. Cause of the glitch
  11. -------------------
  12. Each time you take a step, the game checks the square each character
  13. just stepped onto and applies damage if it's a swamp or barrier square.
  14. The game is smart enough not to try and damage characters who are dead,
  15. but it assumes there's always at least one living character in the party
  16. -- which the game normally ensures by preventing you from removing your
  17. last living character at Luisa's Place, but if that character is numb,
  18. the game lets you leave that character behind anyway, giving you a party
  19. of only dead characters. You can also end up with a party of 1 dead
  20. character (the hero) by going to the fortuneteller in Assaram with the
  21. hero dead and all other living characters numb, typically accomplished
  22. by using the Dream Ruby on the other characters (hence the name of the
  23. glitch).
  25. Once you do get an all-dead party, the damage check gets confused and
  26. tries to check a whopping 256 characters for damage. Depending on what
  27. data happens to be in memory, some of those "characters" will take
  28. "damage" by subtracting 2 from the memory location that would have the
  29. current HP of that character. If the right "character" triggers damage,
  30. the memory location will be where the party's items are stored, causing
  31. an item to change to the item 2 steps before it in the item list, or
  32. where the Return destination list is stored, giving access to towns you
  33. haven't yet visited.
  36. Technical details
  37. -----------------
  38. When moving to a new tile, $D389 does a far call to $B16A in bank 14.
  39. This routine has two purposes: auto-cure any numb characters (1/16
  40. chance per character per step) and check each non-dead character for
  41. field damage. The routine first initializes variables for the damage
  42. check by calling $B1BD, then performs the check itself at $B1EE.
  44. The main purpose of $B1BD is to count the number of living characters in
  45. the party. This count is stored to $66, and a list of party indices of
  46. the living characters is stored starting at $68. Zero is stored in $67
  47. to initialize the counter for $B1EE.
  49. $B1EE performs the field damage check as follows:
  50. 1) Load the current counter value ($67) into register Y.
  51. 2) Load the index of the tile under party member Y from $93+Y.
  52. 3) If the map type ($9A) is zero (the overworld) and the tile index
  53. is $07, apply swamp damage and go to step 6. (This is effectively
  54. dead code since the tile type for overworld tile index $07 is $05,
  55. so swamp damage would be applied anyway.)
  56. 4) Load the tile type for the tile index from $6DE0 (indexed by the
  57. low 5 bits of the tile byte; the high 3 bits are the layer number
  58. in towns and dungeons).
  59. 5) If the tile type is $05, apply swamp damage; if the tile type is
  60. $06, apply barrier damage.
  61. 6) Increment the counter.
  62. 7) If the counter is not equal to the number of live party members
  63. ($66), repeat from step 1.
  64. Note that the counter is not checked against the limit until the end of
  65. the loop, and it is tested for equality, so if there are no living party
  66. members, the loop will iterate 256 times before the counter overflows
  67. from 255 to 0 and the stop condition becomes true.
  69. Damage is applied by loading a byte from the array at $68 (indexed by
  70. the current counter value) and calling the damage routine, which
  71. subtracts the damage from the character's current HP (HP is stored as 4
  72. 16-bit values at $071C).
  74. In order for the bug to occur, at least one tile type on the map must be
  75. $05 (swamp) or $06 (barrier). This is true, for example, in the second
  76. floor of Luisa's Place (map $44, tile type index $01). Using that map
  77. as an example, any zero-page byte whose low 5 bits are 00001 will cause
  78. 2 to be subtracted from an even address in the range $071C...$081A (due
  79. to NES memory mapping, $0800...$081A are mapped to zero-page addresses
  80. $00...$1A). For a byte at zero-page address A which triggers damage,
  81. the party index will be loaded from zero-page address A minus $2B (the
  82. difference between $93 and $68); if the value of the byte at that
  83. address is B, 2 (swamp) or 15 (barrier) will be subtracted from the byte
  84. at address $071C + ((B & 127) * 2).
  86. Potentially useful addresses to modify are:
  87. - $0746, $074C: High byte of experience for characters 1 and 3, which
  88. can be underflowed to level the character up to 99 in the next
  89. battle. Requires a party index byte of $15 or $18, respectively,
  90. and requires the next character's experience to not be a multiple
  91. of 256.
  92. - $0752, $0758: 3rd byte of Return list for characters 1 and 3 (if
  93. zero, swamp damage will change it to $FE, allowing access to
  94. endgame towns -- note that the borrow clears the Aliahan bit for
  95. the next character). Requires a party index byte of $1B or $1E,
  96. respectively.
  97. - $077C...$079A: Party inventory. The 1st, 3rd, 5th, and 7th items
  98. in each character's inventory can be changed; underflowing will
  99. also change the following item (as long as that item is not ID 0,
  100. an unequipped Cypress Stick). Requires a party index byte of
  101. $30...$3F.
  102. - $079C...$07BA: Party spells. The 3rd page of battle spells can be
  103. underflowed if the field spell byte is nonzero (as is the case for
  104. a level-1 Pilgrim, for example). Requires a party index byte of
  105. $41...$4F (odd values).
  106. - $07BE: High byte of party gold. Gold will not be capped at 99999
  107. when buying items (though the number displayed in the gold window
  108. is capped at 99999). On underflow, this marks the first slot in
  109. the stored character list (normally occupied by the hero) as empty;
  110. creating a new character at Luisa's Place 2F would then overwrite
  111. the hero's data in the save file. Requires a party index byte of
  112. $51.
  113. - $07C2: Stored-character index (in the adventurer list) for the 2nd
  114. party member. This could be underflowed to a large value, though I
  115. haven't investigated whether this would produce any useful effects.
  116. Underflowing would also decrement the index of the third party
  117. slot, which could potentially allow having two copies of the same
  118. character in the party. Requires a party index byte of $53, and
  119. requires the hero to not be in the third party slot.
  120. In all cases, the party index byte is shifted left to address the HP
  121. value, so the high bit of the byte can be either 0 or 1.
  123. Note that some bytes which seem like they might be useful to underflow
  124. (maximum HP, for example) can't be underflowed because the next byte is
  125. zero; the damage routine treats the two bytes as a 16-bit integer, and
  126. will not attempt to reduce it below zero.
  128. Also note that if you underflow the third spell page for a Pilgrim, Heal
  129. will be removed from the field spell list. If you also subtract 2 from
  130. the first spell page, the character will (if at level 1 or 2) learn Heal
  131. at the next level-up.
  133. The following addresses can trigger damage on Luisa 2F:
  134. - The random number seed ($1C and $1D) will trigger damage if it has
  135. the proper value.
  136. - $2F will be $01 in towns, which triggers damage if $01 is a swamp
  137. tile (as on Luisa's Place 2F)
  138. - The lead character position ($30 and $31) can trigger damage; for
  139. example, on Luisa 2F, tile index $01 is a swamp tile, so X or Y
  140. coordinate 1 (the top or left edge of the map) will trigger
  141. damage.
  142. - $83 appears to be used as a temporary in message processing, and
  143. it can take on values which trigger damage.
  144. - The map number ($8B) and map type ($9A) could potentially trigger
  145. damage. Maps with type $01 are: $00 (Aliahan), $06, $07, $0A
  146. (Portoga), $0D (undefined map), $12, $50 (Isis), $96 (Isis oasis).
  147. - $9D receives the low 2 bits of a random value every 64 frames on
  148. the overworld if no party members are standing on a town. There
  149. are no swamp or barrier overworld tiles in the $00-$03 range, but
  150. since the value does not change while in a town, it could be set
  151. on the overworld and then used in a town to trigger damage.
  152. - $A4 is a counter which increments with each random number
  153. returned; it could be manipulated to trigger damage.
  154. - The music data pointers at $D6...$DD could trigger damage.
  155. - The sound timers at $E2...$E9 and envelope offsets at $F7, $F9,
  156. $FB, and $FD could trigger damage, though timing would be tight.
  158. Additional values which can trigger damage on Luisa 2F:
  159. - Consistent: $34, $45, $71, $73, $8D, $99, $B5, $C8, $CF, $DD.
  160. - Inconsistent (conditions not yet known): $0A, $0E, $12, $75, $77,
  161. $79, $7B.
  163. Additional values which can trigger damage on the overworld:
  164. - The byte at $01 is consistently $07, which triggers damage.
  165. The associated character index byte is at $D6, the low byte of the
  166. first music channel data pointer.
  167. - $6C is consistently $E7 (low byte of the end of the overworld
  168. entrance list at 6/$B387) at entry to $B1EE, which would trigger
  169. damage, but it's cleared by other code if any preceding byte (such
  170. as $01) triggers damage.
  172. The bug is also present in the initial release of the Japanese version
  173. of the game (Dragon Quest III), though it was reportedly fixed in a
  174. later rerelease. Since DQ3 limits names to four letters (kana) long,
  175. all data at $077C and later in DW3 is shifted 16 bytes toward $0700; for
  176. example, inventory data is located at $076C rather than $077C.
  179. Stick Slime glitch
  180. ==================
  182. The Stick Slime is a dummy item which can be obtained via the Dream Ruby
  183. glitch by glitching an empty inventory slot. The game has 125 different
  184. items, but the format of the inventory data allows for 128 different
  185. item types, so setting an inventory slot to one of those 3 unused types
  186. causes the game to read parts of the program code as item data.
  188. When you try to use an item, the game checks a table that tells it
  189. whether the item can actually be used and what to do when you use it.
  190. For the Stick Slime, the game reads part of the program code that makes
  191. it think the item can be used, but the data that says what to do with it
  192. points into the middle of nowhere, so the results are random: sometimes
  193. you can get several item messages at once, sometimes the game will
  194. crash or do other strange things, sometimes nothing will happen.
  197. Technical details
  198. -----------------
  199. $AE12 in bank 0 is called when using an item on the field. This routine
  200. first looks up the item's data in the table at $922B; bit 7 of the value
  201. indicates whether the item can be used at all. If so, or if (as applies
  202. here) the item number is at least $77, the routine then looks up a jump
  203. pointer for the item effect subroutine, which is stored in a 3-byte-per-
  204. entry table (the first byte appears to be a flag byte) at $B0C5, which
  205. only has entries for field-usable items. The Stick Slime is item $7D;
  206. as $7D is the first invalid item number, the effect routine pointer is
  207. read from the first 3 bytes after the end of the $B0C5 table, which gives
  208. the pointer $2948.
  210. $2948 is within the PPU register region, pointing to (a mirror of)
  211. PPUCTRL. The CPU attempts to read an opcode from this address and gets
  212. open bus, which will be $29 (the high byte of the address read for the
  213. indirect jump). $29 is AND #imm, so the CPU reads an operand byte from
  214. $2949 (PPUMASK); this is also write-only, so the CPU gets $29 from open
  215. bus again.
  217. The next instruction is found at $294A; this is PPUSTAT, which will
  218. return $00 (BRK) at the time this particular code is executed. Dragon
  219. Warrior III implements BRK as a sort of far call instruction, with two
  220. operand bytes which indirectly select the function to be called (via
  221. table lookup). The first byte will be at $294B (OAMADDR), which is
  222. write-only so the CPU gets $29 from open bus (the high byte of the
  223. indirect address used for the load). The second byte, however, will be
  224. at $294C, or OAMDATA; since this code will execute while the PPU is
  225. rendering the screen, the byte loaded will be depend on the precise
  226. timing of the read. The BRK handler uses table lookup rather than
  227. directly taking the address from the operand bytes, so this won't
  228. necessarily lead to a crash, but the particular behavior is effectively
  229. random.
  231. Incidentally, the subroutine pointer for item $7E (Black Raven) is $D385
  232. ($85 $D3 = sta $D3), which is also used for item $7F (Sword Horned)
  233. since that item's flag byte doesn't have bit 7 set and the table offset
  234. consequently isn't incremented for that item. This address happens to
  235. lie right before the normal call to the field damage subroutine, which
  236. is what got all this started in the first place. Coincidence or
  237. insanely clever inside joke? You decide.
  239. The names of the invalid items come from overrunning the name tables;
  240. for example, "Stick" is the second line of the name of the first item
  241. (Cypress Stick), and "Slime" is the first line of the name of the first
  242. enemy (Slime). The garbage character at the end of "Slime" is a code
  243. used in enemy names to indicate how the name is pluralized.
  246. Is arbitrary code execution possible?
  247. -------------------------------------
  248. I really, really want to say "yes", just because it would be so much
  249. fun. But unfortunately, it doesn't seem to be possible, at least not
  250. reliably.
  252. The most likely exploitable path would be to read a value of $xF from
  253. OAMDATA with $4 <= x <= $E; this causes the BRK handler to select bank
  254. $1x at $8000, treat $8000 as a table of addresses, and jump to the
  255. address at the entry in that table selected by the first BRK operand
  256. byte -- here $29, so the jump target is read from $8052. Potentially
  257. exploitable values for the second operand byte include (note that on
  258. entry, A is the party index of the character who has the Stick Slime, X
  259. is $16, and Y is $29 from open bus):
  260. - $5F => $691D; this is the second byte of the 10th character's spell
  261. list in the third save file.
  262. - $6F => $68A8; this is the fifth inventory slot of the 7th character
  263. in the third save file.
  264. - $AF => $0F00; this mirrors to $0700 and is the beginning of the
  265. active party data.
  266. - $BF => $C915; this jumps into the middle of another subroutine with
  267. PLA instructions following, so stack manipulation might be
  268. possible.
  269. However, the possibilities for finding one of these bytes in OAM are
  270. limited. Sprites in DW3 are positioned with an offset (0,4) from
  271. multiple-of-8 coordinates, so byte 0 of a sprite entry will always be
  272. $x3 or $xB and byte 3 will always be $x0 or $x8. Bits $1C of byte 2
  273. are always zero, so that leaves finding a sprite that uses one of the
  274. values above in its tile set and triggering the OAMDATA read at the
  275. exact instant (one of 2 cycles) the PPU is copying that byte to the
  276. secondary OAM during sprite evaluation.
  278. If the Stick Slime could be used in battle, data past the end of the
  279. battle effect routine list ($BE3A, 53 entries) gives some interesting
  280. pointers, like $0558 (found at offset $72; this is the battle command
  281. data list, so you could write e.g. $20 $65 $65 by using Clothes,
  282. Medical Herb, Medical Herb with the first 3 characters, use the Stick
  283. Slime with the 4th character, and jump into the second save file's
  284. inventory data). Unfortunately, the item flags for battle are located
  285. right before the field flags, so the overflow items overlap with the
  286. first three items in the field list, which are weapons and thus not
  287. field-usable. Even if they were, the corresponding effect byte past the
  288. end of 4/$B270 is $00, which is handled properly by the code (it would
  289. be treated like the Blaze spell). This applies to the other invalid
  290. items as well.
  292. On the Japanese version (Dragon Quest III), the Stick Slime routine
  293. pointer is $8100, in the middle of a separate routine, and the Black
  294. Raven pointer is $6600, in the second save file's spell list. The
  295. latter is promising, but unfortunately, when the game tries to write any
  296. of the glitched item names to the text window, it crashes due to
  297. overflowing a temporary buffer for copying the name. (DQ3 uses a
  298. different method to store names, with a length byte following the name
  299. of the item. The name copy loop has a similar bug to the Dream Ruby
  300. glitch in that a length of zero results in copying 256 bytes. The
  301. buffer is located at $0634, so copying 256 bytes will overwrite all the
  302. state information stored at the end of the $06xx page, such as the
  303. current $8000 bank index which is stored at $06D5.)
Add Comment
Please, Sign In to add comment