By forming a party consisting of only dead characters, you can confuse the game into modifying your party's status in useful ways, such as changing weak armor into strong weapons and getting access to endgame towns through the Return spell.

Cause of the glitch

Each time you take a step, the game checks the square each character just stepped onto and applies damage if it's a swamp or barrier square. The game is smart enough not to try and damage characters who are dead, but it assumes there's always at least one living character in the party -- which the game normally ensures by preventing you from removing your last living character at Luisa's Place, but if that character is numb, the game lets you leave that character behind anyway, giving you a party of only dead characters. You can also end up with a party of 1 dead character (the hero) by going to the fortuneteller in Assaram with the hero dead and all other living characters numb, typically accomplished by using the Dream Ruby on the other characters (hence the name of the glitch).

Once you do get an all-dead party, the damage check gets confused and tries to check a whopping 256 characters for damage. Depending on what data happens to be in memory, some of those "characters" will take "damage" by subtracting 2 from the memory location that would have the current HP of that character. If the right "character" triggers damage, the memory location will be where the party's items are stored, causing an item to change to the item 2 steps before it in the item list, or where the Return destination list is stored, giving access to towns you haven't yet visited.

Technical details

When moving to a new tile, $D389 does a far call to $B16A in bank 14. This routine has two purposes: auto-cure any numb characters (1/16 chance per character per step) and check each non-dead character for field damage. The routine first initializes variables for the damage check by calling $B1BD, then performs the check itself at $B1EE.

The main purpose of $B1BD is to count the number of living characters in the party. This count is stored to $66, and a list of party indices of the living characters is stored starting at $68. Zero is stored in $67 to initialize the counter for $B1EE.

$B1EE performs the field damage check as follows:

1. Load the current counter value ($67) into register Y.
2. Load the index of the tile under party member Y from $93+Y.
3. If the map type ($9A) is zero (the overworld) and the tile index is $07, apply swamp damage and go to step 6. (This is effectively dead code since the tile type for overworld tile index $07 is $05, so swamp damage would be applied anyway.)
4. Load the tile type for the tile index from $6DE0 (indexed by the low 5 bits of the tile byte; the high 3 bits are the layer number in towns and dungeons).
5. If the tile type is $05, apply swamp damage; if the tile type is $06, apply barrier damage.
6. Increment the counter.
7. If the counter is not equal to the number of live party members ($66), repeat from step 1. Note that the counter is not checked against the limit until the end of the loop, and it is tested for equality, so if there are no living party members, the loop will iterate 256 times before the counter overflows from 255 to 0 and the stop condition becomes true.

Damage is applied by loading a byte from the array at $68 (indexed by the current counter value) and calling the damage routine, which subtracts the damage from the character's current HP (HP is stored as 4 16-bit values at $071C).

In order for the bug to occur, at least one tile type on the map must be $05 (swamp) or $06 (barrier). This is true, for example, in the second floor of Luisa's Place (map $44, tile type index $01). Using that map as an example, any zero-page byte whose low 5 bits are 00001 will cause 2 to be subtracted from an even address in the range $071C...$081A (due to NES memory mapping, $0800...$081A are mapped to zero-page addresses $00...$1A). For a byte at zero-page address A which triggers damage, the party index will be loaded from zero-page address A minus $2B (the difference between $93 and $68); if the value of the byte at that address is B, 2 (swamp) or 15 (barrier) will be subtracted from the byte at address $071C + ((B & 127) ¤ 2).

Potentially useful addresses to modify are:

• $0746, $074C: High byte of experience for characters 1 and 3, which can be underflowed to level the character up to 99 in the next battle. Requires a party index byte of $15 or $18, respectively, and requires the next character's experience to not be a multiple of 256.
• $0752, $0758: 3rd byte of Return list for characters 1 and 3 (if zero, swamp damage will change it to $FE, allowing access to endgame towns -- note that the borrow clears the Aliahan bit for the next character). Requires a party index byte of $1B or $1E, respectively.
• $077C...$079A: Party inventory. The 1st, 3rd, 5th, and 7th items in each character's inventory can be changed; underflowing will also change the following item (as long as that item is not ID 0, an unequipped Cypress Stick). Requires a party index byte of $30...$3F.
• $079C...$07BA: Party spells. The 3rd page of battle spells can be underflowed if the field spell byte is nonzero (as is the case for a level-1 Pilgrim, for example). Requires a party index byte of $41...$4F (odd values).
• $07BE: High byte of party gold. Gold will not be capped at 99999 when buying items (though the number displayed in the gold window is capped at 99999). On underflow, this marks the first slot in the stored character list (normally occupied by the hero) as empty; creating a new character at Luisa's Place 2F would then overwrite the hero's data in the save file. Requires a party index byte of $51.
• $07C2: Stored-character index (in the adventurer list) for the 2nd party member. This could be underflowed to a large value, though I haven't investigated whether this would produce any useful effects. Underflowing would also decrement the index of the third party slot, which could potentially allow having two copies of the same character in the party. Requires a party index byte of $53, and requires the hero to not be in the third party slot. In all cases, the party index byte is shifted left to address the HP value, so the high bit of the byte can be either 0 or 1.

Note that some bytes which seem like they might be useful to underflow (maximum HP, for example) can't be underflowed because the next byte is zero; the damage routine treats the two bytes as a 16-bit integer, and will not attempt to reduce it below zero.

Also note that if you underflow the third spell page for a Pilgrim, Heal will be removed from the field spell list. If you also subtract 2 from the first spell page, the character will (if at level 1 or 2) learn Heal at the next level-up.

The following addresses can trigger damage on Luisa 2F: - The random number seed ($1C and $1D) will trigger damage if it has the proper value. - $2F will be $01 in towns, which triggers damage if $01 is a swamp tile (as on Luisa's Place 2F) - The lead character position ($30 and $31) can trigger damage; for example, on Luisa 2F, tile index $01 is a swamp tile, so X or Y coordinate 1 (the top or left edge of the map) will trigger damage. - $83 appears to be used as a temporary in message processing, and it can take on values which trigger damage. - The map number ($8B) and map type ($9A) could potentially trigger damage. Maps with type $01 are: $00 (Aliahan), $06, $07, $0A (Portoga), $0D (undefined map), $12, $50 (Isis), $96 (Isis oasis). - $9D receives the low 2 bits of a random value every 64 frames on the overworld if no party members are standing on a town. There are no swamp or barrier overworld tiles in the $00-$03 range, but since the value does not change while in a town, it could be set on the overworld and then used in a town to trigger damage. - $A4 is a counter which increments with each random number returned; it could be manipulated to trigger damage. - The music data pointers at $D6...$DD could trigger damage. - The sound timers at $E2...$E9 and envelope offsets at $F7, $F9, $FB, and $FD could trigger damage, though timing would be tight.

Additional values which can trigger damage on Luisa 2F: - Consistent: $34, $45, $71, $73, $8D, $99, $B5, $C8, $CF, $DD. - Inconsistent (conditions not yet known): $0A, $0E, $12, $75, $77, $79, $7B.

Additional values which can trigger damage on the overworld: - The byte at $01 is consistently $07, which triggers damage. The associated character index byte is at $D6, the low byte of the first music channel data pointer. - $6C is consistently $E7 (low byte of the end of the overworld entrance list at 6/$B387) at entry to $B1EE, which would trigger damage, but it's cleared by other code if any preceding byte (such as $01) triggers damage.

The bug is also present in the initial release of the Japanese version of the game (Dragon Quest III), though it was reportedly fixed in a later rerelease. Since DQ3 limits names to four letters (kana) long, all data at $077C and later in DW3 is shifted 16 bytes toward $0700; for example, inventory data is located at $076C rather than $077C.

Stick Slime glitch

The Stick Slime is a dummy item which can be obtained via the Dream Ruby glitch by glitching an empty inventory slot. The game has 125 different items, but the format of the inventory data allows for 128 different item types, so setting an inventory slot to one of those 3 unused types causes the game to read parts of the program code as item data.

When you try to use an item, the game checks a table that tells it whether the item can actually be used and what to do when you use it. For the Stick Slime, the game reads part of the program code that makes it think the item can be used, but the data that says what to do with it points into the middle of nowhere, so the results are random: sometimes you can get several item messages at once, sometimes the game will crash or do other strange things, sometimes nothing will happen.

Technical details

$AE12 in bank 0 is called when using an item on the field. This routine first looks up the item's data in the table at $922B; bit 7 of the value indicates whether the item can be used at all. If so, or if (as applies here) the item number is at least $77, the routine then looks up a jump pointer for the item effect subroutine, which is stored in a 3-byte-per- entry table (the first byte appears to be a flag byte) at $B0C5, which only has entries for field-usable items. The Stick Slime is item $7D; as $7D is the first invalid item number, the effect routine pointer is read from the first 3 bytes after the end of the $B0C5 table, which gives the pointer $2948.

$2948 is within the PPU register region, pointing to (a mirror of) PPUCTRL. The CPU attempts to read an opcode from this address and gets open bus, which will be $29 (the high byte of the address read for the indirect jump). $29 is AND #imm, so the CPU reads an operand byte from $2949 (PPUMASK); this is also write-only, so the CPU gets $29 from open bus again.

The next instruction is found at $294A; this is PPUSTAT, which will return $00 (BRK) at the time this particular code is executed. Dragon Warrior III implements BRK as a sort of far call instruction, with two operand bytes which indirectly select the function to be called (via table lookup). The first byte will be at $294B (OAMADDR), which is write-only so the CPU gets $29 from open bus (the high byte of the indirect address used for the load). The second byte, however, will be at $294C, or OAMDATA; since this code will execute while the PPU is rendering the screen, the byte loaded will be depend on the precise timing of the read. The BRK handler uses table lookup rather than directly taking the address from the operand bytes, so this won't necessarily lead to a crash, but the particular behavior is effectively random.

Incidentally, the subroutine pointer for item $7E (Black Raven) is $D385 ($85 $D3 = sta $D3), which is also used for item $7F (Sword Horned) since that item's flag byte doesn't have bit 7 set and the table offset consequently isn't incremented for that item. This address happens to lie right before the normal call to the field damage subroutine, which is what got all this started in the first place. Coincidence or insanely clever inside joke? You decide.

The names of the invalid items come from overrunning the name tables; for example, "Stick" is the second line of the name of the first item (Cypress Stick), and "Slime" is the first line of the name of the first enemy (Slime). The garbage character at the end of "Slime" is a code used in enemy names to indicate how the name is pluralized.

Is arbitrary code execution possible?

I really, really want to say "yes", just because it would be so much fun. But unfortunately, it doesn't seem to be possible, at least not reliably.

The most likely exploitable path would be to read a value of $xF from OAMDATA with $4 <= x <= $E; this causes the BRK handler to select bank $1x at $8000, treat $8000 as a table of addresses, and jump to the address at the entry in that table selected by the first BRK operand byte -- here $29, so the jump target is read from $8052. Potentially exploitable values for the second operand byte include (note that on entry, A is the party index of the character who has the Stick Slime, X is $16, and Y is $29 from open bus):

• $5F => $691D; this is the second byte of the 10th character's spell list in the third save file.
• $6F => $68A8; this is the fifth inventory slot of the 7th character in the third save file.
• $AF => $0F00; this mirrors to $0700 and is the beginning of the active party data.
• $BF => $C915; this jumps into the middle of another subroutine with PLA instructions following, so stack manipulation might be possible. However, the possibilities for finding one of these bytes in OAM are limited. Sprites in DW3 are positioned with an offset (0,4) from multiple-of-8 coordinates, so byte 0 of a sprite entry will always be $x3 or $xB and byte 3 will always be $x0 or $x8. Bits $1C of byte 2 are always zero, so that leaves finding a sprite that uses one of the values above in its tile set and triggering the OAMDATA read at the exact instant (one of 2 cycles) the PPU is copying that byte to the secondary OAM during sprite evaluation.

If the Stick Slime could be used in battle, data past the end of the battle effect routine list ($BE3A, 53 entries) gives some interesting pointers, like $0558 (found at offset $72; this is the battle command data list, so you could write e.g. $20 $65 $65 by using Clothes, Medical Herb, Medical Herb with the first 3 characters, use the Stick Slime with the 4th character, and jump into the second save file's inventory data). Unfortunately, the item flags for battle are located right before the field flags, so the overflow items overlap with the first three items in the field list, which are weapons and thus not field-usable. Even if they were, the corresponding effect byte past the end of 4/$B270 is $00, which is handled properly by the code (it would be treated like the Blaze spell). This applies to the other invalid items as well.

On the Japanese version (Dragon Quest III), the Stick Slime routine pointer is $8100, in the middle of a separate routine, and the Black Raven pointer is $6600, in the second save file's spell list. The latter is promising, but unfortunately, when the game tries to write any of the glitched item names to the text window, it crashes due to overflowing a temporary buffer for copying the name. (DQ3 uses a different method to store names, with a length byte following the name of the item. The name copy loop has a similar bug to the Dream Ruby glitch in that a length of zero results in copying 256 bytes. The buffer is located at $0634, so copying 256 bytes will overwrite all the state information stored at the end of the $06xx page, such as the current $8000 bank index which is stored at $06D5.)