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 ... 10
General Discussion / Re: Yeniaul's Discord Server (and rules)
« on: February 27, 2017, 12:42:46 pm »
The invitation link is dead again.
How fast do these links expire?

Try this link, I just generated a nonexpiring one:

I still can't join. It keeps giving me the same message:
The instant invite is invalid or has expired
I'm using the web interface, not the app. I've never used Discord before, so I have no idea if this is an issue.
General Discussion / Re: Yeniaul's Discord Server (and rules)
« on: February 27, 2017, 11:35:50 am »
The invitation link is dead again.
How fast do these links expire?
General Discussion / Re: Yeniaul's Discord Server (and rules)
« on: February 26, 2017, 12:11:20 pm »
The instant invite is invalid or has expired

Wanted to finally join, but nope!
There are actually a lot of things that need to be tested here.
- Trying to transfer a box with more than 20 Pokemon
- Trying to transfer a box without an 0xFF terminator
- Transferring glitch Pokemon and/or hybrids
- Transferring Pokemon with levels over 100 and level 0
- How are invalid characters handled in nicknames and OT names?
- Transferring glitch moves and transferring a Cooltrainer Ditto
- Transferring invalid combinations of moves, like Exploding Bulbasaurs, Crabhammer Charizards and Surfing Pikachus
- Transferring Pokemon with underflowed PP
- Transferring Pokemon with multiple status conditions (frozen burn and so on)
It does nothing, it serves no purpose.
But it's there to make the item list easier to get. It's good practice to make item lists as clean as possible.

Let's say you want to use the instruction: ld (hl), a
When converted to an item list, it would become Glitch item 0x77, xAny.

However, glitch items are difficult to get. Also, it's not a good idea to have some random glitch items lying around in the inventory, since many of them can easily crash the game or have very long names. It's like walking around while carrying a loaded gun pressed against your head.

The solution is to add a useless instruction before the one we wanted.
ld d,d; ld (hl),a would translate to Elixer, x119.
No glitch items needed!
Are there any relatively accurate N64 emulators with debugging functionality?
I checked it, this is a buffer overflow caused by the glitch move's description. Code execution takes place by overwriting the IRQ handler (similar to what happens in Gen III with decamark summary screens)
This exact move is not exploitable, since the instruction pointer lands in unmapped memory. But there probably is an index that would work for ACE.

Edit: Never mind, it actually locks up the game in both mGBA and No$gba Debug, so I'm forced to think that this is just an emulation error
Generation I Glitch Discussion / Re: Pokedex Entries for Glitchmon- How?
« on: December 29, 2016, 05:13:31 am »
Every glitch Pokemon can be forced as an opponent by modifying RAM address $CFD8 while already in battle. This can be accomplished without hacking, either with Cooltrainer corruptions or with ACE. Once that's done, it's possible to catch the resulting Pokemon, which will display its Pokedex entry (provided that its Pokedex caught flag isn't already set).
There's also the Expanded Pokedex glitch that makes it possible to see Pokedex entries for several index 199+ glitch Pokemon.

But I'm pretty sure that people don't bother to go through all that trouble and just hack the game to take the images. It's not like the Pokedex entry will be different if obtained legitimately.
If you load the game on BGB, open the debugger and go to debug>access breakpoints you can set a breakpoint to A000-FDFF by entering A000-FDFF in the address box, ticking 'on write' and adding it. This way if there is any arbitrary code execution the emulator will open up the debugger at the place it's executing the code.

I think you meant 'on execute'.

Also, Viet Crystal has a lot of crashes caused by invalid text commands. All of them could potentially be exploitable, similar to the Coin Case glitch.
My theory about it was that somehow, interrupts weren't diasbled. This left me to wonder if it is possible for an interrupt to execute just after a DI instruction, and then for it to re-eanble interrupts when "reti" ? If that's the case, welp this glitch isn't 100% working.

I think this shouldn't be possible. Z80 doesn't have any instruction pipelining or fancy hyperthreading stuff, so every clock cycle should execute exactly one instruction before checking for interrupts. So an interrupt could only happen either directly before disabling (instruction pointer on DI), or directly afterwards, ending up in a queue (instruction pointer on instruction after DI).

But if I'm wrong, there should be nothing preventing us from fixing the problem with brute force:

Code: [Select]
; the more the better

Also, this doesn't seem to have been mentioned yet, but when testing on actual hardware, the game will do a hard reset about 50% of the time. I've had the best luck when pulling the cartridge straight out as quickly as possible and when inserting it by resting it on the cartridge slot and giving it a quick push with the bottom of my palm. If I remove it slowly or tilt it when pulling it out, it hard resets whenever it's pulled out much of the time. Similarly, if I insert it too slowly, it hard resets upon making contact with the cartridge reader much of the time. The issue is persistent across the DMG (latch removed), CGB, SGB, and MGB models. I haven't tested a Game Boy Light yet, since I don't have one, but I'd guess it also suffers the same fate.
Oh, really ? I got this problem with my first setup (the old which polled $0001, waited for it to become $FF, and then for it NOT to be $FF), which had a 12% success rate (out of ~40 times, I got like 5 successful attempts), where all my successes had me pull the cart straight.
I like to think it comes from the pins disconnecting in an incorrect manner, but I don't quite know what could be the culprit.
According to this, this is the pin layout :
Quote from: GbDevWiki
Pin   Name    Expl.
 1     VDD     Power Supply +5V DC
 2     PHI     System Clock
 3     /WR     Write
 4     /RD     Read
 5     /CS     Chip Select
 6-21  A0-A15  Address Lines
 22-29 D0-D7   Data Lines
 30    /RES    Reset signal
 31    VIN     External Sound Input
 32    GND     Ground
I don't even know what the "PHI", "CS" and "RES" pins may be used for.
I'm really clueless.

I would assume there is some cartridge line that is connected to the internal reset pin on the CPU. Unwanted noise from pulling the cartridge would put this pin in a low state, which would explain the sudden hard resets.

Doing the swap as quickly as possible should partially prevent this. Also, pulling the cart straight up and evenly on both sides makes sure all pins disconnect at roughly the same time.

As a few points of interest, there were two unintended effects that occurred when trying to do the glitch: One was a softlock and the other was a VRAM glitch that I haven't seen before on a Game Boy.

These glitches seem really interesting to me. They directly affected the SNES hardware and escaped the Gameboy CPU, forcing me to think that the SGB probed the inserted GB cartridge for some purpose, read garbage data when in the middle of the cart swap and caused some kind of overflow.
I guess some reversing needs to be done on the SGB ROM to see whether it periodically accesses cartridge data and under what conditions.
General Discussion / Re: The Member's Guide to Topiclessness
« on: December 14, 2016, 02:15:02 pm »
Quote from: TheZZAZZGlitch
But I guess the first version should be done until the end of this month.
That's a part of your message, I thought you promised me, but ok...

>'should' and 'I guess' in the same statement
>take the message as a promise
General Discussion / Re: The Member's Guide to Topiclessness
« on: December 14, 2016, 10:11:30 am »
It will be ready when it's ready :P
But I guess the first version should be done until the end of this month.

Never promised anything.

Actually it's working, but it's buggy and still partially untranslated.

Oh, and just in case you were wondering what's the Japanese equivalent of "qÁF qÁF qÁF qÁF": MIZEMIZEMIZEMIZEMIZEMIZE
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.
Pages: 1 [2] 3 4 ... 10