Glitch City Laboratories Archives

Glitch City Laboratories closed on 1 September 2020 (announcement). This is an archived copy of a thread from Glitch City Laboratories Forums.

You can join Glitch City Research Institute to ask questions or discuss current developments.

You may also download the archive of this forum in .tar.gz, .sql.gz, or .sqlite.gz formats.

Arbitrary Code Execution Discussion

Verifying console/emulator behavior with 8F - Page 2

Re: Verifying console/emulator behavior with 8F

Posted by: ISSOtm
Date: 2016-07-21 20:03:33
I edited my previous post, and I bump here for everyone to notice the bump.

I asserted that hte game will hang, although there is a chance my information is not correct. Anyone having a GBC/A could test ? Thanks.

Re: Verifying console/emulator behavior with 8F

Posted by: TheUnReturned
Date: 2016-07-22 00:32:43

I edited my previous post, and I bump here for everyone to notice the bump.

I asserted that hte game will hang, although there is a chance my information is not correct. Anyone having a GBC/A could test ? Thanks.
It might or might not hang… It's also decided by how well the CPU perform

Re: Verifying console/emulator behavior with 8F

Posted by: Aldrasio
Date: 2016-07-22 10:46:26


I edited my previous post, and I bump here for everyone to notice the bump.

I asserted that hte game will hang, although there is a chance my information is not correct. Anyone having a GBC/A could test ? Thanks.
It might or might not hang… It's also decided by how well the CPU perform


Why would that be a factor, though? It matters how it interprets an instruction, which is entirely on how the CPU handles command logic. Performance shouldn't matter.

Re: Verifying console/emulator behavior with 8F

Posted by: ISSOtm
Date: 2016-07-22 13:38:03
Assuming the CPU's components aren't rusted, the instruction always is interpreted the same way.

Re: Verifying console/emulator behavior with 8F

Posted by: Duo
Date: 2016-09-05 18:54:32
re: bgb 1.4.1

Please guys, update your BGB to the most current version 1.5.2. Version 1.4.1 is ancient (4 years+)

http://bgb.bircd.org

-Duo

Re: Verifying console/emulator behavior with 8F

Posted by: luckytyphlosion
Date: 2016-09-05 22:28:31
Inaccessible VRAM access is also relevant when encountering unstable missingno in Yellow version on a cleared save file. The game will hang for 6-7 minutes with a file that does not emulate inaccessible VRAM (such as 3DSVC), as the audio command pointers are corrupted to read from OAM ($fe00-fe9f). With accurate emulators/real hardware, inaccessible VRAM will cause the corrupted audio pointers to terminate quickly (from the $FF read during mode 2/3), however if VRAM is always open, the game continually process the audio much longer as there is no terminator.

Also, stop doesn't exist as an opcode in 3DSVC. Double Speed mode doesn't even require it, from my tests.

EDIT: okay didn't realize that inaccessible VRAM is emulated correctly on 3DSVC. However, it seems that inaccessible OAM isn't emulated correctly, as GB code never writes to OAM directly. (most, if not all code uses the OAM DMA)

Re: Verifying console/emulator behavior with 8F

Posted by: ISSOtm
Date: 2016-09-06 00:43:28
So we should also test OAM access outside of VBlank ?
And maybe test OAM corruption emulation.

Re: Verifying console/emulator behavior with 8F

Posted by: Stackout
Date: 2016-09-06 18:16:04
The new video by TheZZAZZGlitch inspired me to shove the 3DS VC binary into ida again.

I found the gb cpu interpreter function (let me guess: nintendo abandoned their attempt at a gba emu for 3DS, instead going the hardware route, because they never heard of a dynamic recompiler). The handler for the "stop" opcode just skips past the operand and ignores it, as is known.

I haven't checked fully the interesting stuff yet (custom opcode 0xfc handler!), that will come very soon.

edit: OK, so opcode 0xfc seems pretty useless. All its operands come from the loaded patchconfig, and if pc is not equal to the address of any patches (or if no patches are loaded!) then no operation occurs.

Re: Verifying console/emulator behavior with 8F

Posted by: Charmy
Date: 2016-09-07 14:05:42
Hmm i still don't understand this, i have no ASM or opcode knowledge so…
help.

But, GBC.emu Free seems to give weird results then it comes to walking out of bounds, it seems to show ether the "start" menu or the Pokémon Center text.
In some areas i can actually progress thru the text and the game completely ignores the RAM corruption going on.
It tries to heal around 100 Pokémon.
Then it changes the screen data to vomit.
Then Oak's lab music plays.
Then when the "We hope to see you again!" text finishes, the game crashes with some teal and the rival's theme.
If i choose Cancel, then the same teal rival thingy happens.

I think you should test that emulator as well.

Re: Verifying console/emulator behavior with 8F

Posted by: Stackout
Date: 2016-09-07 16:36:33
By the way, this stuff was already discovered, but for the record, here's a decompilation of the function used to read emulated GB's memory in the VC emu. (hex-rays + manual fixups)

int gb_read_memory(unsigned int address)
{
  #define UNDEFINED 0xff
  switch ( address >> 12 ) {
    case 0u:
    case 1u:
    case 2u:
    case 3u:
      return bank0_ptr[address];
    case 4u:
    case 5u:
    case 6u:
    case 7u:
      return currbank_ptr[address - 0x4000];
    case 8u:
    case 9u:
      if ( (*LCDSTAT_ptr & 3u) >= 3 )
        return UNDEFINED;
      return vram_ptr[address - 0x8000];
    case 0xAu:
    case 0xBu:
      if ( !fp_read_sram )
        return UNDEFINED;
      return fp_read_sram(address);
    case 0xCu:
      return wram_bank0_ptr[address - 0xc000];
    case 0xDu:
      return wram_currbank_ptr[address - 0xd000];
    case 0xEu:
      return wram_bank0_ptr[address - 0xe000];
    case 0xFu:
  if ( address >= 0xff80 )
    return hram_ptr[address - 0xff80];
  if ( address >= 0xff00 )
    return io_regs[address - 0xff00] & io_regs_maxvalues[address - 0xff00];
  if ( address >= 0xfea0 )
    return UNDEFINED;
  if ( address >= 0xfe00 )
    return oam_ptr[address - 0xfe00];
  return wram_currbank_ptr[address - 0xf000];
    default:
      return UNDEFINED;
  }
}

(this function is (relocated) at 0x165264, in the VC emulator version 2.058, which is the version used with at least the original release of the Gen1 VC. The GB CPU interpreter function is (relocated) at 0x1a3b28, and the NES/Famicom CPU interpreter function is directly afterwards at 0x1a8c18. I can provide a partially annotated .idb on request.)

Re: Verifying console/emulator behavior with 8F

Posted by: ISSOtm
Date: 2016-10-26 09:02:20
I know this topic has been locked, but there seems to be one oddity with VBA and money. It dates quite a bit, but since I'm writing more about GCRM, it came back to me.

If you have, let's say, 123456 money, the game stores this as $12, $34, $56. Using GCRM, we can turn this into $12, $6F, $56.

I expected this to work the same as 127556 (1 * 100000 + 2 * 10000 + 6 * 1000 + 15 * 100 + 5 * 10 + 6 * 1), and console (GBC or GBASP, can't remember which) verified this.
However, Krys3000 notified me that VBA acted as if he had 126956 money (as if it "corrected" the F to a 9).

By "the same as X", I mean that after doing an action with money the remaining  amount of monies was the same as if we had had X.


So, here is my point : unlock this topic, do some tests with the DAA instruction, and lock it again. I can't do that myself as of now, sorry.

[EDIT]
Seems like my post unlocked the topic. Oops.

Re: Verifying console/emulator behavior with 8F

Posted by: Torchickens
Date: 2017-03-08 18:15:58
I think I may have found a Game Boy Player inaccuracy, which is really surprising.

In English Pokémon Red there is a special glitch map 0xE7. After a couple of hours of testing I finally found a way to access it.

1) First get 202 Pokémon in the party (this is to place a C9 in memory at EC2B (CC2B) for map 0xE7's level-script pointer at EAF1). Without arbitrary code execution, this should be possible by activating Super Glitch while on the deposit option of a Pokémon Center's PC, depositing the Pokémon to get 255 Pokémon and then withdrawing a PC4SH to get 202 Pokémon (the ID of PC4SH).
2) Stand in the spot below, save and reset then put the party cursor to Pokémon 202 and close the menu.
3) Change D36E/D36F to 4112 and D35E to E7. You can do this with a TM31 x1 and X Attack x18 in the expanded items pack if you replace them with the Master Ball x199 and TM41 x79 respectively.

[img]https://i.imgur.com/gfAWjLa.png[/img]

4) You will warp to map 0xE7 and the game shouldn't freeze.

Note: The 202 Pokémon requirement may not be necessary on Game Boy/Virtual Console but it is on Game Boy Player.

This is where the emulation error comes in:

On a Game Boy Advance SP and Virtual Console, the map redirects you to another map (possibly Pallet Town) where Professor Oak may tell you not to go out and loop around the screen until you're forced to walk out of bounds.

[img]https://i.imgur.com/ZewDKkJ.png[/img][img]https://i.imgur.com/klzjmrH.png[/img]

But on the Game Boy Player the map doesn't redirect you and you get to explore it!

[img]https://i.imgur.com/xXGPRbe.png[/img]

Though it's easy to go out of bounds and freeze the game.

At first I wondered whether there were requirements for it not to work I was overlooking, but I tested the same save file doing the same steps on a Game Boy Player and then a Game Boy Advance SP in alternation. Every time on the Game Boy Advance SP it warped to Pallet Town. Every time on the Game Boy Player it let me explore the map.

Re: Verifying console/emulator behavior with 8F

Posted by: TheSixthItem
Date: 2017-06-22 01:33:26
GBA4IOS 2.1:
UnknownOpcodes: FAIL5
InvalidBanks: PASS
VRAMAccess: PASS
EchoRAM: PASS
InvalidStop: FAIL

Re: Verifying console/emulator behavior with 8F

Posted by: Stackout
Date: 2017-08-26 19:38:36
Has anybody tried running these tests on a Kong Feng GB Boy Colour (Chinese bootleg CGB clone)?