TASVideos

Tool-assisted game movies
When human skills are just not enough

Submission #7022: CasualPokePlayer's GBC Fushigi no Dungeon: Fuurai no Shiren GB: Tsukikage Mura no Kaibutsu "game end glitch" in 00:14.82

Console: Game Boy Color
Game name: Fushigi no Dungeon: Fuurai no Shiren GB: Tsukikage Mura no Kaibutsu
Game version: JPN
ROM filename: Fushigi no Dungeon - Fuurai no Shiren GB (J) [S].gb
Branch: game end glitch
Emulator: Bizhawk 2.6
Movie length: 00:14.82
FrameCount: 902
Re-record count: 1631
Author's real name: Wesley B.
Author's nickname: CasualPokePlayer
Submitter: CasualPokePlayer
Submitted at: 2021-02-03 07:07:09
Text last edited at: 2021-02-20 07:14:31
Text last edited by: CasualPokePlayer
Download: Download (1424 bytes)
Status: new
Submission instructions
Discuss this submission (also rating / voting)
List all submissions by this submitter
List pages on this site that refer to this submission
View submission text history
Back to the submission list
Author's comments and explanations:

(Link to video)

About the Game

Fushigi no Dungeon: Fuurai no Shiren GB: Tsukikage Mura no Kaibutsu, translated as Mystery Dungeon: Shiren the Wanderer: The Monsters of Moonlight Village, is a roguelike game developed by Aquamarine and published by Chunsoft, apparently released back in 11/22/1996. The game follows Shiren the Wanderer, and his talking weasel Koppa. The game has also gotten some ports/re-releases on Windows and Android. And there really isn't anything I can say past that, the game was only released in Japan, and there's really not much info about this game. The RTA leaderboards don't even have any runs on the Gameboy version. Luckily, this game is buggy so it won't matter for me.

Game objectives

Emulator used: Bizhawk 2.6

  • CGB in GBA mode is enabled for console verification.

Categories

  • Aims for fastest completion of the game
  • Executes arbitrary code
  • Corrupts save data
  • Some luck manipulation

Comments

The run is fairly short, so there isn't too much to comment on. The key exploit used is simply the L/R|U/D glitch. Essentially, the game doesn't handle L/R and U/D inputs correctly; often they will freeze the game, but sometimes they will cause ACE. This movie specifically uses the combination L/R/D to cause ACE at EDF0 (echo RAM for CDF0). I use my player name to store most of the payload, however, I simply don't have any bytes that can cause any jumps. That's where luck manipulation comes into play. The game stores 4 bytes for RNG at D601-D604. The game uses rTIMA (somewhat similar to rDIV, but much more restrictive for manipulation) for seeding the RNG, and uses a fairly complicated LFSR to cycle through RNG.

Stage by stage comments

Save file creation

I need to create a save file to really do anything, which can be quickly done. It also needs to be the 3rd save file, the 1st one won't work. I hard reset once the main save file is actually made (although before the backup is made; this causes the game to create the backup save after the hard reset is done, which changes RNG). As a note, the game doesn't seem to have any soft reset, and going back through the main menu without resetting is much slower, and will simply not work for my purposes anyways (due to the game splashing FFs in a huge chunk of RAM I need to slide past). As a note, this reset is why I need to use the 3rd save file, as the game will load the 3rd save file's data by default, and will only load the other save files if they actually go into the game (which I don't want to do).

RNG Manip/Name/ACE

This is where the main improvement from the previous comes in. After the reset, I manipulate for a fairly specific RNG combination. From my RNG log of all possible initial seeds:

  Tima0: 01 | Tima1: C8 | Tima2: E9 | RNG: 02 D5 87 C9
The main prize in this particular seed is $02 right before a $D5 -> $C9 combination. I then proceed to rename myself, which will write the following code into memory:

  ld de,$7C1C ; credits location
  ld a,e ; a = $1C
Afterwards, I need to flash the rename screen again. This will clear out a troublesome buffer of my name, leaving in some $88 bytes. I then just have to wait for a counter to tick down to $00. This ends up changing it to $01 (and stays that way), and also places a $28 byte two bytes away. This results in the following opcode.

  ld bc,$2800
bc is now $2800, which is perfect since this is around the general area where I need to write to trigger a bankswitch. I can press L/R/D now, which now executes the payload.

Now remember that RNG seed? This is at the end of a payload, which ends up being the following in assembly:

  ld (bc),a ; bankswitch to bank 1C
  push de ; (sp) = $7C1C
  add a
  ret ;  pc = 1C:7C1C, credits are located here
No inputs are needed for the cutscene, so input is ended once ACE is executed.

Similar submissions (by title and categories where applicable):