Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - TheZZAZZGlitch

Pages: 1 2 [3] 4 5 ... 10
Generation III Glitch Discussion / Re: It would be interesting if...
« on: September 30, 2016, 04:39:08 pm »
Not exactly, since the anti-cheat mechanism is what allows the box corruption in the first place.
The only method to do this would be to disable all egg checks entirely. Patching the following memory addresses to the following values should do it (although I don't know how to convert this into a list of codes for any GBA cheating device):

Code: [Select]
806AAC2 -> 00
806AAC3 -> 20
806AA26 -> 00
806AA27 -> 20
806A960 -> 00
806A961 -> 21
806AACA -> 00
806AACB -> 21
806A866 -> 00
806A867 -> 21
806A920 -> 00
806A921 -> 21

Note: Only tested on Emerald US. This also disables normal eggs from working.
Programming/Scripting/Development/Web Design / Re: [C] pointer to array
« on: September 28, 2016, 07:47:42 am »
Code: [Select]
int a, b, c, d;

// An array of pointers
int *stuff[4] = {&a, &b, &c, &d};
// A pointer to an array of pointers
int *(*ptr_to_stuff)[4] = &stuff;
// An array of pointers to arrays
int *(*array_of_ptr_to_stuff[2])[4] = {&stuff, &stuff};

int main(){
    // Will print the exact same thing
    printf("%p\n", &a);
    printf("%p\n", stuff[0]);
    printf("%p\n", (*ptr_to_stuff)[0]);
    printf("%p\n", (*array_of_ptr_to_stuff[1])[0]);
Pokémon Discussion / Re: Trades between RBY and Pokémon Sun and Moon
« on: September 07, 2016, 03:25:23 pm »
I just have a feeling that all of the anti-cheating measures in Pokemon Bank are designed to prevent an average 1337 h4x0r from trying to put their shiny Arceus into GTS.
It wasn't designed to deal with the level of control that 8F gives us (does Nintendo even know about 8F arbitrary code execution?)
As it was said before, not long ago it was possible to get level 100+ Pokemon stored and transferred without any problems.

Glitch Pokemon probably won't be allowed (even if they were, they would just turn into equivalent Gen II Pokemon). But I assure you that invalid movesets will be a thing (Charizard with Crabhammer, here I come!) and invalid DV combinations will be a thing (15/15/15/15 Mewtwo lel).

Throughout the years Game Freak has shown us that they don't care about error checking at all.
If it turns out to be true, does anybody know how this or the data following D261 could be manipulated for making code to obtain Celebi?

Address $D261 is indeed in the middle of enemy trainer data. If this data is made harmless, the execution slides all the way to $D48E, which contains the player's name. This can be manipulated to jump anywhere we'd like. On the video, the player's name is set to "てガみ" - which is 0xC3, 0x05, 0xD0 - jp $d005. I assume that the author of the video put some code there to activate the event.
Video Games / Re: Aevilia - a RPG made from (nearly) scratch
« on: September 01, 2016, 06:09:51 pm »
I got it to run under Windows. Kind of.

It perpetually sends me back to the main menu after I try to select anything.
Nothing interesting shows in the log files, and I don't want to go through the pain of reading someone else's code.
I had this happen before, and this is just a bug in some of the older versions of VBA. When displaying textboxes on turbo mode, the tilemap will sometimes get corrupted. It does not seem to happen consistently - I once created a VBM movie file with the bug occuring, but after restarting the emulator and playing it back, the problem magically disappeared.

I don't really know the cause of this. By doing some analysis on the screenshot above we can discover some patterns:
- Everything gets changed: tile data, pallettes and tile attributes (some of the tiles are flipped)
- Almost every 4th tile is ID 0x40, X-flipped
- Tiles are arranged in columns: in the 3rd column, tile 0x40 is the most frequent; in the 4th column, tile 0x02 is the most frequent, and so on. Every column consistently has a most frequent tile.
- The textbox displays fine, so the code that triggers the bug happens before the textbox gets rendered

I searched the ROM for patterns with 4th, 8th and 12th byte set to 0x40, and while I did in fact find some matches, they don't look anything like the corruptions I was able to get.

Could you grab a memory dump after the bug happens and post it here? If this sounds like wizardry to you:
1. Go to Tools > Memory viewer
2. Click "Save..."
3. Type in: Address 0000, size FFFF
4. Give the file some clever name, save it and post it
The same method of arbitrary code execution through the link cable is possible in Gen II. This (similarly to the Gen I version) works by overflowing the trade partner Pokemon list and overwriting a return address on the stack.

There is also a writeup about the Gen I link cable exploit, so if you want to know exactly how this works, visit:
The process is pretty much the same for Gen II.
It's unclear whether this was supposed to be intended behavior or not. Here is a part of the move effect table:

dw PayDayEffect              ; PAY_DAY_EFFECT
dw $0000                     ; SWIFT_EFFECT
dw StatModifierDownEffect    ; ATTACK_DOWN_SIDE_EFFECT
dw StatModifierDownEffect    ; DEFENSE_DOWN_SIDE_EFFECT
dw StatModifierDownEffect    ; SPEED_DOWN_SIDE_EFFECT
dw StatModifierDownEffect    ; SPECIAL_DOWN_SIDE_EFFECT
dw StatModifierDownEffect    ; unused effect (0x48)
dw StatModifierDownEffect    ; unused effect (0x49)
dw StatModifierDownEffect    ; unused effect (0x4A)
dw StatModifierDownEffect    ; unused effect (0x4B)

dw ConfusionSideEffect       ; CONFUSION_SIDE_EFFECT
dw TwoToFiveAttacksEffect    ; TWINEEDLE_EFFECT
dw $0000                     ; unused effect

The pointers for those glitch effects do not come from any out of bounds data - the programmers who created this table explicitly added 8 effects responsible for lowering stats. The remaining two entries in the table ended up as placeholders. So there might have been plans for extra two stats in the game (Special Attack and Special Defense?). However, there are no corresponding unused entries for other stat-related effects (lowering by 2 stages, raising by 1 stage, raising by 2 stages).

The actual behavior of the effects looks glitchy because the stat names are taken from an out of bounds location. But in fact, aside from the glitchy message, the subroutines responsible for handling stat changes are properly adapted to work with stat indices from 0 to 7.
Interestingly enough, two bytes in RAM located right after the stat changes table are unused, as if there's actually space reserved for two additional stats.

As it stands, all of this could still be accidental. There's no conclusive proof that the two mysterious unused stats were actually intended to be used.
I have a SYM file for Red/Blue, since I use it in bgb to get symbols for debugging.
But it doesn't seem to be of much help when creating a one-file disasm, using it by itself wouldn't preserve comments and differences between data and code. But I still included it as an attachment, since it's useful to have.

Instead, I randomly decided to do something stupid:

Code: [Select]
# coding: utf8
result = b''; counter = 0
with open('out.asm', 'rb') as f:
    for i in f.readlines():
        if i[0:9] == b'INCLUDE "':
            with open(i[9:-3], 'rb') as g: result +=
            counter += 1
            result += i
with open('out.asm', 'wb') as f: f.write(result)
print("Eradicated includes: %i" % counter)
# run it multiple times to deal with nested includes

And the result looks surprisingly OK.
It still lacks comments with function addresses (this could be done with the SYM file mentioned earlier), and has all the constants and macros (the problem of constants can be fixed by prefixing/suffixing each pointer constant with its effective address; still no idea how to approach the macros, does rgbasm have an command line option to only preprocess macros without compiling?)
Definitely. A one-file disassembly is a lot easier to search through when you want to analyze a certain subroutine or check for certain behavior.
The current disasms of Pokemon games are formatted like "corporate quality code", which is good for ROM hacking, but not too good for reversing. A similar thing happened to the pokered disassembly. I circumvented the problem by getting an older version of the repository, where everything was still mostly in one file. But this old version has a lot of stuff undocumented, so later I need to search through the current version anyways.

An easy way to get a one-file disasm would be writing a quick script to expand all of the includes. Still, that wouldn't deal with macros and constants (looking through the code, minding my own business... f**k, what address is wWhichPokemon again? *scroll back to the top*)
Thank you for all of your responses! I updated the table with all the information you submitted.

I originally didn't know undefined opcodes actually hang the CPU, I expected something similar to the behavior of 6502, where invalid opcodes actually do something - sometimes useful, sometimes not.
Therefore, I will now consider the test to be passed if the game doesn't keep running after executing an invalid instruction, since that's the behavior on real hardware. I updated the test accordingly.

Already we see that some of the glitches will be version exclusive - most importantly, 3DS VC seems to have pretty inaccurate emulation (although most of this stuff is undefined behavior, so they have the right to format my SD card if I try to do this). Some random facts as of now:
- The "MISSINGNO. is trying to learn effect" is 4 times less likely to be seen on 3DS VC.
- Coin Case ACE will not work on Stadium 2's GB Tower.
- 3DS VC most likely ignores invalid opcodes, which means that some crashing glitch items could potentially be more useful there.

Also, superscript inside tables looks weird.
I don't know if there's a text guide of some sort, but this TAS pretty much shows one of the correct paths to achieve this:
The trick is to enter the Indigo Plateau map at a high enough Y coordinate to be above the badge guards, bypassing them completely.
I planned to do this for a long time. In Gen I, we have a lot of glitches that exploit certain obscure details of the GB hardware or rely on undefined behavior, yet it still isn't exactly clear what behavior is exhibited by certain emulators and the real console. Thankfully, we have an easy way to execute any code we want with 8F. It's a good opportunity to test if everything works exactly as we think it works. I welcome everyone with working 8F setups on VC/console/mobile emulators/other devices to run the following 8F scripts and see if we have 100% accuracy for our glitching purposes.

If my request gets some interest, this table will be filled with data regarding the most important systems.
Also let me know if someone thinks of another relevant test to add.

Last updated 2016-07-22


1 - the emulator breaks into a debugger every time an undefined opcode is encountered
2 - brings up the infamous message "unknown opcode xx at yyyy"
3 - the result is 127 instead of 124 - this behavior needs to be more thoroughly investigated
4 - the game hangs without any message
5 - unknown opcodes are ignored, most likely because of the emulator hooking them to communicate with the hardware
6 - (probably) always returns 0
7 - displays a message: "The saved data has been corrupted, so it is impossible to CONTINUE. Please reset the game and choose NEW GAME", the save is not corrupted though
8 - (probably) always returns 255 - so VRAM access is enabled not during the V-Blank period, but during the V-Blank interrupt, which changes things dramatically
9 - some other data seems to be stored in the echo RAM area
10 - some corrupted stops work, some not - this is to be expected with undefined behavior

The tests themselves:


Self-explanatory. This is intended to test whether the target system ignores invalid opcodes, or crashes/halts when they are executed. This behavior could potentially affect any glitches that execute data as code (invalid sound banks, invalid item/move effect pointers).

TM27         x201

Code: [Select]

If the game continues running after executing the script - FAIL
If the system brings up an error message or the game hangs or crashes - PASS


This checks how the system handles switching to non-existent ROM banks. This determines the behavior of glitches that cause invalid bank switches - most commonly invalid sound banks or invalid predefined commands.

Lemonade     x65
Repel        x32
X Speed      x79
Ultra Ball   x198
Fire Stone   x71
Moon Stone   x35
Water Stone  x201

Code: [Select]
ld a,41
ld e,20
ld b,e
ld c,a
ld (bc),a
add 20
ld b,a
ld a,(bc)
inc hl
ldi (hl),a

The third item's quantity changes to 124 - PASS.
Third item's quantity changes to something other than 124, like 255 or 0 - FAIL.
Remember to reset item 3's quantity if you want to repeat the test.


VRAM data can only be read or written during V-Blank, H-Blank, or when the LCD screen is turned off. Otherwise, the write operation will be ignored, and all read operations will return FF. This test checks this behavior. Emulation of VRAM inaccessibility is essential for correct behavior of a lot of popular glitches, including Cooltrainer, Super Glitch, Brock Through Walls and any other glitches that attempt to "search through the entire address space".

Lemonade     xAny
Repel        x144
X Speed      x175
PP Up        x35
Moon Stone   x34
TM01         xAny

Code: [Select]
ld a,??
ld e,90
ld b,e
xor a
ld c,a
inc hl
ld a,(bc)
ldi (hl),a

Run the script multiple times in a row and observe the quantity of the third item.
If it changes seemingly randomly between 255 and any other value - PASS
If it never becomes 255, even after trying multiple times - FAIL


Because of how GB's address line works, RAM addresses $C000~$DDFF are mirrored at $E000~$FDFF. This repeated section of memory is called the echo RAM. Because this feature was hardly used by anyone, several emulators don't support it. This test is intended to verify whether echo RAM is emulated correctly. Emulation of this feature changes the behavior of glitches that cause extensive memory corruption, like Pokemon beyond the sixth slot, or Dokokashira Door Glitch. Also, Coin Case arbitrary code execution won't work without echo RAM emulation.

Lemonade     xAny
Repel        x241
X Speed      x44
Fresh Water  x175
TM06         x88
PP Up        x10
Water Stone  x201

Code: [Select]
ld a,00
ld e,f1
ld b,e
inc l
inc a
xor a
adc a,58
ld c,a
ld a,(bc)
ldi (hl),a

Run the script and check the quantity of item 3.
If it changes to the code of the first letter in the player's name - PASS
If it doesn't change, or changes to a wrong value, like FF or 00 - FAIL


This is to test how the system reacts to invalid STOP opcodes. This behavior could affect some of the non-ACE Coin Case glitches, along with all glitches that execute data as code (invalid sound banks, invalid item/move effect pointers)

Full Restore x??
TM01         xAny

Code: [Select]
stop ??

Start with an arbitrary amount of Full Restores.
Run the 8F script. If the game crashes/halts whenever the script is executed - PASS
If not, try running the script with a different amount of Full Restores and repeat the process.
If after several tries the game is still running - FAIL.
Generation I Glitch Discussion / Re: Invalid sound banks examination
« on: July 20, 2016, 12:15:24 am »
Here, I believe it's just that developers that padded ROM banks with zeroes.

For both Yellow and Red, there is a final, large group of banks that all crash with rst 38h. For these, I believe that the developers filled unused ROM banks with FFs. Just like they did for the rst vectors. Boy, what a pack of dummies... even I fitted a FillMemory function in there, so... meh. Game Freak + 1st Gen = (crappy code)^n, with n steadily increasing over time.

Banks 40-7F aren't filled with anything, because they don't exist on the RBY carts. The carts are all 1MB, meaning they only have banks up to 3F. If the MBC's told to read from a bank that doesn't exist, it just pulls all 1's. This isn't unique to Pokemon, all Gameboy games with a ROM smaller than 2MB do this.

Hell, give this a shot on the original Japanese Red/Green carts with banks 20 and up. The same thing will happen, because they're 512kB carts.

The NOP sleds aren't surprising for the banks above 20 since they generally contain international (non-Japanese) script data and don't have code.

On several emulators I observed a different behavior; the bank number has its two most significant bits truncated, so switching to bank 0x41 actually loads bank 0x01. I have no idea how the real console should behave. Also, if the virtual console emulator and real console behave differently, we could get some exclusive behavior.

If someone has an 8F setup on real hardware/VC, we can try to find out with this item list.

Lemonade     x65
Repel        x32
X Speed      x79
Ultra Ball   x198
Fire Stone   x71
Moon Stone   x35
Water Stone  x201

Code: [Select]
ld a,41
ld e,20
ld b,e
ld c,a
ld (bc),a
add 20
ld b,a
ld a,(bc)
inc hl
ldi (hl),a

If after executing this code the second item's quantity changes to 124 - target console/emulator takes bank numbers modulo 0x40.
If the second item's quantity changes to 255 - target console/emulator grabs blank data from nonexistent banks.
Generation I Glitch Discussion / Re: Gameshark code
« on: July 18, 2016, 06:11:10 am »
I've played Gen I Pokemon games multiple times. I still have to do a glitchless playthrough.
Glitching is just a lot more fun that the game itself. In fact, I consider Gen I to be one of the worst games in the series, gameplaywise.
Pages: 1 2 [3] 4 5 ... 10