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
General Discussion / Re: The Member's Guide to Topiclessness
« on: December 14, 2016, 07:21:41 am »
There actually was a glitch that allowed access to the True Pacifist ending at LV 10.
It was later patched by adding an additional check to see if the player has EXP 0 and LV 1. So the true ending can no longer be accessed with LV greater than 1, even by editing the save file (which probably shouldn't count as killing)
Never mind, it still actually works
So you could get the true ending if there was some glitch to raise LV beyond 1 without killing anything, and that should probably be the correct behavior (I didn't kill anything after all!)
Through some random Google searches I discovered this video. It showcases that the CPU still runs after swapping the cartridge, provided that the instruction pointer isn't in ROM. There's also a comment from a person who claims they were able to do this successfully by executing code from RAM.
So indeed, "bringing" ACE to other games should be possible.
I'd imagine something like this would work:

Copy the code to RAM and jump there (this step is unnecessary if we're using an 8F script, since ACE causes the code to run from RAM anyways)
Disable all interrupts (interrupt handlers are in ROM)
Give the user a chance to swap the cartridge. We could have a mechanism that reacts on button presses and so on, but the simplest, most compact way to do it would be having a very long loop that delays the execution, giving the user a few seconds to do the swapping
Now we're executing code in the context of the newly inserted cartridge. We can do whatever we want at this point, then jump to $0100 to run the game!

There are some problems with this. Most importantly, because the cart isn't actually running when we're executing our code, we can't really influence the game's state.
We can't just modify RAM, since the game will most likely initialize variables with its own values after starting. There are some ways we could avoid this:

Just edit the SRAM. We can wreak some havoc with that too. My first Gen III HoF warp exploit only used SRAM writes to do its job, for the same reason as we have here (both the game and its state are completely trashed long before the code is executed)
Exploit some game-specific quirks in RAM initialization. Gen I Pokemon games like to completely zero out WRAM during initialization, but a lot of games didn't bother to do that (like Magi-Nation). There is a chance that some code in the game uses this uninitialized data. For example, the NES classic Super Mario Bros has a Continue option that will happily read from unitialized data, which makes this glitch possible.
Don't make the game run its RAM initialization. For Pokemon games, jumping in the middle of the Init subroutine just after the RAM initialization code should do the trick. Or even better, don't let the game decide how it should be initialized. Do the initialization exactly how you want it, set up all RAM values you want, set up registers and resume the game in its running state (for Pokemon this would be in the overworld loop) - in other words, implement savestates in real hardware.
If the game does at least a part of its initialization with interrupts enabled, and prepares its RAM before it initializes DMA, we can try another trick: before launching the game, set a custom DMA handler that sets some RAM address to a given value and enable interrupts. There's a good chance that the DMA handler will be called before it gets overwritten by init code, but after the RAM initialization code is executed, giving us a persistent RAM change.

Once we're able to do any of these things, chances are we have already won. Many games don't expect invalid values in their internal variables, so most likely we can trigger a different ACE bug in a more convenient place and do all of the wonderful things.

In other words, by having a special Pokemon cartridge we could potentially ACE any game we want (or at least dump/write save files to it). But I still need confirmation whether or not this will happen on all consoles (GB, GBC, SGB). The 'completely legit random video I found on the internetz' suggests that it works at least for GBC.
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.
Pages: 1 2 [3] 4 5 ... 10