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 - ISSOtm

Pages: [1] 2 3 ... 58
I'm doubtful to upload a save file as long as I haven't made sure that saving is at least 99% fail-proof. Currently hard-resetting wile the game is saving may permanently "uninstall" the exploit. (The save patching currently only takes place when SRAM has been re-locked, which seems to happen very late into the process)

I'll also be providing a patching program (probably Python) later on, when I get around to meta-program it from the RGBDS output \o/
I think this is enough to warrant a double-post, but... the new names worked perfectly, BGB keeps breaking due to accessing disabled SRAM (intended, lel), but it's working!

The GitHub repository is live!
Alright, I'll try with the new names, and when I get something working, I'll publish a repo :)
I actually re-did all your work on my own side, in order to have a RGBDS setup that patches in any save file. It's currently working! If you want, I can publish this to a GitHub repo and work from there.

I'm currently using the US Crystal 1.0 version built from pokecrystal (MD5: 9f2922b235a5eeb78d65594e82ef5dde), on which your exploit seemed to work out of the box.
Btw, US Crystal 1.1 (as built from pokecrystal, again) has a MD5 of 301899b8087289a6436b0a241fbbb474.

Checking if saving has occurred is actually trivial. Switch to SRA1, check if the player's name is still out exploit's name (checking for the first byte is enough, since the "Green's name" control char shouldn't be obtainable by the player). If that's the case, patch in the existing save, and call `Checksum`, and finally write it back. (This might be actually a bit dangerous if the code triggers while in the normal `Checksum` function, but there's a chance it doesn't occur)

As for the HRAM hook, here's how I do it:
Code: [Select]
OAMHook: ; Ends up at FF80
    call $C002
    ld [$ff00+c], a

DMALoader: ; Ends up at $C000
    ; Code here...

    ; Set up regs for DMA to go on smoothly
    ld c, $46 ; LOW(rDMA)
    ld a, $C4 ; HIGH(wVirtualOAM)

    db "GCL@"

    push bc
    push de
    push hl
    ; Hook OAM DMA
    ld hl, OAMHook
    ld bc, 4 << 8 | $80
    ld a, [hli]
    ld [$ff00+c], a
    inc c
    dec b
    jr nz, .copyOAMHook
    ; Copy loader to WRAM
    ld hl, DMALoader
    ld de, $C000 ; Stack space, of which a lot is usually available
    ld bc, DMALoaderEnd - DMALoader
    call CopyBytes
    ld de, NewPlayerName
    ld hl, wPlayerName
    call CopyName2
    pop hl
    pop de
    pop bc
(In my source, it's a bit different, due to requiring some artifacts to get RGBDS to output code with the proper, WRAM, addresses)

A side note regarding the use of C000+ as storage: this works fine, except with Withdraw Smash ACE. Should be OK, I guess.

Another side note as to how to restore the player's name: instead of copying a default name, we can probably fetch it from the save backup instead!
[EDIT] Sadly, the backup is overwritten before our name is evaluated, thus, we can't restore the name from the backup. My other idea is to instead store the player's name in another region of SRAM, and copy back from there. (Side note, I'm aiming at something like MrCheeze's virus, which can be applied to basically any save file, thus we could copy the player's name to an unused SRAM section before patching takes place)

And finally, another quirk: the game uses the Mom's name to store the player's during the Dude's catching tutorial. We'd have to patch that as well with the exploit's string.
To detect if the player saved, you can check if the "SAVE" option in the menu has been selected (I think this could be detected by checking the cursor tile). I'm interested in this as well, I could lend you a hand if you want.
However, which version of Crystal are you using? (MD5/SHA1 if possible, please)
I'd prefer to use the US versions if possible, due to the SYM file provided by the disassembly.
Coin Case is fairly obsolete, for starters. We tend to use box names instead, and Wrong Pocket TMs.
Using SRAM is a bad idea, for three reasons:
1. It's banked, so you have to ensure the correct bank is loaded
2. It has to be unlocked, then ideally re-locked
3. 3DS VC cannot execute from SRAM

Corrupting Pokémon data is also a rather bad idea, since it's prone to lots of corruptions.

If you need to write large payloads, you can instead use luckytyphlosion's Mail execution setup.
It's an emulation problem. The game has a different way of accessing the cartridge port, which triggers anti-piracy.
It'd be a fun coincidence, regarding the [ûrl=]Evolving Raichu[/url] glitch. I don't believe these to be correlated at all, though -- it's just a translation fucky wucky >w<
Generation I Glitch Discussion / Re: New Pokemon Yellow Softlock?
« on: April 29, 2018, 09:13:56 pm »
Here's what should happen:
  • The game sets the successful animation counters (4-1 = 3 sub-animations, 3 shakes)
  • If it's a Ghost battle, the game overrides it with a null animation (0 sub-anims, 0 shakes)
  • If the battle is the Old Man or Oak type, and event 02F is set (which is *not* the case during the normal Rattata catching demo), then the animation is overridden with the failure animation (play all 5 sub-anims, shake 3 times). Otherwise, the Pokémon is automatically considered captured, which, as explained below, skips any ball-shaking calculations and preserves the value set at step 1
  • Otherwise, if the player is fighting the Ghost Marowak, the animation is set to fail.
  • If the capture succeeds, the game does not perform extra calculations, and skips the following step, thereby preserving the capture value.
  • Finally, the game performs complexicated calculations, which determine the number of ball shakes. This basically amounts to either playing only 1 sub-anim, or playing all 5 sub-anims with different shake amounts
Finally, and using that parameter, the game plays the ball toss animation.

This ends up in the special handler, which first plays the corresponding toss sub-animation, then sub-anims from this sequence.

I haven't looked into the rest much more than finding the ball-shake function.
What text box did you change? And what do you mean? You can't jump to a textbox.
What function?
Overwriting isn't that simple - a NULL deref means the game is crashing either way, and removing the error handler isn't going to change anything.
You should use pokered instead. Change all the RST vectors to NOPs, except 0038, which you should repoint to the blank space after the interrupt vectors (0061~0068, not sure) and put the func there.

There is no RAM address 0038. 0038 is in ROM.
To be fair, any value with A as its lower nibble causes SRAM to open, which means writing a random value to 0000-1FFF has a 1/16 chance to open SRAM. If this happens, and is followed by a 0039 crash, SRAM will be trampled over then locked (since SP goes from CFXX to 0000, then wraps). If bank 0 is loaded, you'll be fine (it will corrupt HoF data, but it's not checksummed). If bank 1, 2 or 3 is loaded, this will most likely make the checksum verification fail when starting up again, thus save corrupted.

Again: saving, viewing a sprite and not saving anymore largely reduces your chances of crashing.

Another note: it is also possible to change the loaded SRAM bank, which wraps (thus 3/4 chance of loading a risky bank) by writing to $4000-5FFF.
That's why I assume chances to corrupt are pretty much random, but you can lower them by properly setting up.

Of note is that Gen II has more SRAM banks, which might not all be checksummed (plus there are some backup banks), potentially reducing the risk of corruption causing "save corrupted" messages, thougsome data would still be corrupted.
In Red, SRAM is often left unlocked, making these edits easier.
This is plain wrong. The game closes SRAM every time it finishes using it (sprite decompression, saving data, boxes, etc.)
Pages: [1] 2 3 ... 58