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

Pages: [1] 2 3 ... 62

Current box contents are saved to SRAM, then the box number in WRAM is changed and the new box loaded from SRAM.

Interestingly I don't think the box number in SRAM ever gets touched by simply changing boxes.
General Discussion / Re: Cool ASCII of my favorite word!
« on: January 13, 2018, 04:07:47 pm »
with a proper monospace font used, it reads "ENIGMA".
I'm unsure what you're requesting. I have Flipnote Studio 3D on my 3DS if that helps..?
the 4-step thing reminds me of the (international) dokokashira door glitch - doesn't it have a similar cause?
Pokémon Discussion / Re: Crystal: Unused party sanitisation function
« on: October 03, 2017, 08:32:55 pm »
Pretty sure it is debug code now.

I searched for other places where the string validity check function is called.

It's called in three places. One of those seems to be unused, and all incorporate parts of the checks detailed in the OP.

The unused occurrence and first used occurrence are in Battle Tower code, sanitising Battle Tower Pokémon after they are read. (The unused occurrence seems to have just been dummied out, as it is directly after the used code ends.)

This code sanitises Pokémon nicknames, replaces any OT name with bad characters with "CHRIS" (only one terminator this time), makes sure all nicknames and the OT name are terminated, and sanitises invalid moves in the same way as detailed in the OP (except here, move $00 is never considered invalid).

The unused half of this function replaces invalid Pokémon species ($FD being considered invalid) with Smeargle ($EB). Instead of a simple greater-than-or-equal check, it checks for equality against each invalid species value in turn. Pokémon levels are also checked, but the maximum level instead of being hardcoded is taken from SRAM at 5:B2FB.

The last occurrence is inside mobile-related code. Every single string (nickname, OT, mail, mail author) is checked for invalid bytes and termination (where the terminator is $4E for some reason) within the correct length, by bankswitched calls. If one of these checks fails, the offending string is replaced with a default string by a bankswitched call.

Here's a list of default strings used:
OT name, mail author: "クりス" Chris followed by two terminators
Pokémon nickname: "?????" unterminated(!!!)
Mail text: "こんにちは" "Konnichiwa" Hello followed by one terminator

The default strings are terminated by $50 as usual.

After checking the strings, an "item" at $C60E is checked, if it's $FF it gets replaced by $00. Finally, the exact same level checks as in the OP are performed.
Pokémon Discussion / Crystal: Unused party sanitisation function
« on: October 03, 2017, 10:37:50 am »
I was looking in pokecrystal for something unrelated and this caught my eye.

As the filename would have you expect, it's in EN Crystal at $13A47 (4:7A47). (It's in JP Crystal at $13BB3 (4:7BB3)). That's near the end of the bank, located after some Bug-Catching Contest-related stuff, and before a function that uses a lookup table to find square roots. It appears to not be in G/S (and given that it calls a function in a bank related to mobile code, that's not unexpected).

It is completely unreferenced and unused in at least JP and EN Crystal.

Here's what it does:

  • If the number of Pokémon in the party is over 6, set it to 6
  • The party species bytes are checked. If a byte is an invalid species ($00, $FC, $FE, $FF), change that species byte and the first species byte of that Pokémon structure to Smeargle ($EB).
  • For all Pokémon in the party:
    • If the second species byte in the Pokémon structure is invalid ($FD (Egg) is also considered invalid here), change it to Smeargle.
    • If the Pokémon's level is below 2, set it to 2; if it is over 100, set it to 100. Recalculate the Pokémon's stats, no matter whether or not the level was modified.
    • If the Pokémon's nickname is unterminated after 6 bytes, terminate it by setting the 6th byte to $50; if the nickname has any invalid characters (defined here as anything that is not $00, $05 - $13, $19 - $1C, $26 - $34, $3A - $3E, $40 - $48, $60 - $FF; a function in a bank related to mobile functionality is called to do this), set it to the Pokémon species name (if the Pokémon is an Egg, then set it to "タマゴ" ("Tamago"/Egg) followed by 50 50 50 instead)
    • If the Pokémon's Original Trainer name is unterminated after 6 bytes, terminate it by setting the 6th byte to $50; if it has any invalid characters, set it to the player's name
    • If the Pokémon has an invalid move in slot 1 ($00, $FC, $FD, $FE, $FF), replace it with Pound. If there is an invalid move in slot 2, 3, or 4, delete all moves starting from that slot(!!!).

Note that this code is only half localised in non-JP - it assumes nicknames and OT names are 6 bytes long, the list of characters considered valid assumes a Japanese game, and if an Egg's nickname contains invalid characters, it gets set to "タマゴ"; however, when removing a Pokémon's nickname, or changing its OT name, it copies the correct number of bytes for the localisation.

Given that this calls a function in a mobile-related bank, this function may have been intended to have been used to force the legitimacy of party Pokémon when using mobile-related features. Of course, it may have just been debug code.
Might as well just sticky this now.
According to the disassembly, it can not (the Time Capsule exploit only bypasses the species check).
Here are the patches:

Interestingly there are patch files for Crystal included, meaning that a Crystal VC release may still happen (or perhaps they abandoned it after realising they'd need to do something about the GB Mobile Adaptor in the Japanese version).

As with R/B, the patch files include comments with some IDA output and some actual src:

Code: [Select]
;  call ir_main
; ld d,a ; IR_STAT
; xor a

;   _IRcomm_end   0x2a1b9
; ld hl,ir_read_buf                |       21 50 c7 
; ld de,ir_read_buf_stk            |       11 00 c8
; ld bc,15                         |
; call block_move                  |
;                                   |

;3e 3f 21 92 51 cf cd df 65 00   
; ------->
; BCALL G_BANK0b,set_send_data2
; call read_buf_clr

Interesting that the "official" bankswitched call macro takes a bank as well as function address. I guess the official GB/C compiler and linker are inferior to rgbds and doesn't have an inbuilt feature to get the bank number that a symbol is in.
Wiki Discussion / Re: The big hex list
« on: September 18, 2017, 07:45:05 pm »
I just took a look.

It seems if you're willing to replicate the initial battle initialisation code, put the trainer class index in the a register then jump to the middle of InitBattleCommon, you can set up a trainer battle with any trainer class.

To be more clear, your payload would be doing everything up to the bankswitched call to InitBattleVariables, setting the a register then jumping to ld [wTrainerClass],a.
BTW, roamer struct is:

byte species; byte level; byte map_group; byte map_number; byte HP; word DVs;


When moving roamers, the code checks if map_group is $FF, this means the roamer is no longer available to catch; the roamer-encounter code only checks if you're on the same map as it (so it seems that you can indeed encounter a roaming ????? (00)) - this basically means that if you've caught at least one roamer, glitch map FF FF has at least one roaming ????? (00) in it:

And, even more hilariously, there's a function that sanity checks a wild Pokémon's species, returning with carry on if it's invalid (00, > FC); unfortunately, Game Freak forgot a ld a,b before calling it (alternatively, they wrote ld b,[hl] instead of ld a,[hl]), so what is checked isn't the wild Pokémon's species, but its level!

Not that this matters; the sanity check is done on the in-ROM wild Pokémon data before the battle starts, and besides, the only call to this function is done with code dealing with wild Pokémon data, which is completely skipped in the case of a roamer anyway.

Torchickens: did you try Flying away to reset the location value to something random? Just moving routes wouldn't work because the game won't find the location in the roamer-moving data (it does this before anything else), whereas Flying just checks if map_group if $FF or not.
I finally took a look at the "bad dump", turns out it's not really a "bad dump", someone modified the ROM.

Entry point jumps to 0:00e0, which is just nops in the good dump, but this space was used to add the following code:

ld a,0
ld [$6000],a
ld a,$30
ld [$6000],a
jp $0150

This code makes no sense, the header says it uses MBC1, where $6000 is a 1-bit wide register that flips between two different banking modes. Maybe this is for flashcart compatibility?

In addition, a ld a,1 got patched to ld a,0 at 00:024C, and again at 01:488E.

Finally, the header checksum got patched.
Going into the Pokemon Center breaks the WTW.

The Pokémon Center is only entered on poison whiteout, and when the Safari Zone step counter is still active.

EDIT: wait a minute, Gen I quirkiness strikes again, doesn't it? Whiting out puts you outside of the Pokémon Center, doesn't it?

In that case going into the Trade Center and whiting out in there would have to be done while the Safari Zone's step counter is running.
I didn't think about that, maybe the ROM I used was indeed a bad dump (causing the errors on an emulator) and my physical cartridge (being official) was a good dump hence didn't have the glitch on GBA SP and my physical SNES/Super Game Boy.

This is the MD5 checksum of the ROM I used on emulator.

DAT-o-MATIC says this is a trusted dump, but with the information now maybe that was a false positive.

Actually, it seems as if that ROM is a bad dump.
DAT-o-MATIC says that two dumps were made in 2014 and both have MD5 hash of 3029C962C483DF174FC6F5C9202326E3.
Pages: [1] 2 3 ... 62