Glitch City Laboratories Archives

EDIT :

I made AR codes for the Perfect Initiators (both of them), as well as a Cloning Glitch Pokemon 0x288A for easier use.
There's also .dmp and .vbm file to get them in previous page.

Perfect Initiators :
-SEASOR Box 1 Slot 1 :
A2C5C596 17DA2752
F45EB5FD 537687FB
19DF4333 C4F74712
A152E8EA 8D4760CA
B13788DF 3B9B3A06
C779EE6C 581A95B9
21B17AD5 DA302C1D
9D1EF466 2A6BBE89
C8B2C039 BBAF6F10
C6EBC6F3 449F849A
3E96C2CF 7A857392
E961EBF3 AB0BCF93
0C9256C3 62ECB067
CEDF2D7F 2B16ACD8
A0C9067E 5DF79155
B54DF298 D5F5CBE8
938599D1 405D3286
BC4CC3E8 1780C0E0
EBB11B21 D831516F
0E1022AE 1D878554


-Marked SEASOR Box 1 Slot 1 :
A2C5C596 17DA2752
F45EB5FD 537687FB
19DF4333 C4F74712
A152E8EA 8D4760CA
B13788DF 3B9B3A06
C779EE6C 581A95B9
FD888EEC 3BF29F9D
7ECAB9C9 836C5CE0
C8B2C039 BBAF6F10
C6EBC6F3 449F849A
3E96C2CF 7A857392
E961EBF3 AB0BCF93
70733463 A2300296
551E03CE 8008DF22
A0C9067E 5DF79155
B54DF298 D5F5CBE8
938599D1 405D3286
BC4CC3E8 1780C0E0
EBB11B21 D831516F
0E1022AE 1D878554


0X288A Cloning Pokemon Box 1 Slot 1 :
F3FF8938 F2F0E0C9
E2702D51 7857D4A2
AB71E557 19AF41CC
0FE199FA B823C7D7
0ACA1C25 59581547
10E8FBDF 66A39775
C82FFF38 70FF74BC
653F342F CD0F6A08
1F84851D BEC5B4D6
2F151FF1 1728714F
61398186 8C5F9FC5
FD9E9546 E55D0B32
A406783C 0C3177A7
5DF1F989 3FACA9DD
89CEE4A4 EB64C63B
5EB054E7 1231876C
51F13B68 9594314D
6D1A2A74 D3E004EC
1CDFF57E A9407B53
4DAC86DE 3AFEB045

This may be a bit old, but do you remember the thing you were mentioning here ? (the one that corrupted PC Pokémon)

I have now found that doing this can also corrupt the Pokemon in the PC, turning them into Bad EGGs with seemingly completely random glitch markings and glitch item. Other data regarding what the Pokemon was originally might have also been corrupted, but since I use actual hardware and not an emulator, I couldn't do much with them.

As I am not sure which action you were referring to (going over a Glitch Pokémon in PC, healing your party,…)

Hi, I'm new here. I've been lurking for a while though, and I'm not if this has been covered, but here goes.

Last night, I managed to successfully pull off the "hatch any Pokemon" glitch on Emerald and hatched a Jirachi. I did the Day Care thing to get rid of its glitch moves, etc., and then I started trying to get rid of the Bad Eggs in my boxes. At first, I tried to use the cloning glitch, but did it wrong and failed to get rid of them (I did get 5 Master Balls off the non-glitch clones, though :)). And while I was pulling the Master Balls off of them in "Move Items" mode, I happened into one of the corrupted boxes full of Bad Eggs and saw that several were holding glitch items, represented by the white "?". There were also two invisible Pokemon, one of which appeared to be holding a Choice Band, based on the sprite.

So my question is, what do these glitch items do, and are they safe to pick up? I'm hesitant to try bagging them since I play on cartridge and don't want my save corrupted. Also, has anyone ever experienced getting a valid item off an invisible Pokemon, so that there's a chance that's a real Choice Band?

Thank you.

I'm just going to leave a note for others that these require Anti-DMA (B2809E31 3CEF5320, 1C7B3231 B494738C).

Metarkrai, can you teach us the steps to convert a .PKM file into an Action Replay code for box 1 slot 1 (otherwise a code compatible for the Xploder Advance SP) please, as I bought one recently and would like to use it for fast cartridge glitching. Thanks!

This may be a bit old, but do you remember the thing you were mentioning here ? (the one that corrupted PC Pokémon)

I achieved that by picking up Decamark 0x1460 with the orange cursor and moving between boxes in the PC.
[..]

Anyway, if possible, would anyone be able to use an emulator to see the corrupted Pokemon and the glitch items they hold? I'm interested to see what the hex. values of the glitch items are, since some of them either have the "CLOSE BAG" sprite or have no sprite at all.

Since the name is hundreds of characters long, a buffer overflow occurs and many aspects of your game will be overwritten with corrupt data, notably your name, Party, Bag, Money, Trainer Card, gender, overworld sprite, battle sprite, Options, Badges and even your play time.

However, codes that call the "overworld script" subroutine and that use this subroutine to execute certain scripts (call credits, give a Pokémon, set some flags, warp,…) do not work well :
When the code is executed, the game only stores the adress at which the scripts must be executed, and executes them once the battle ends.
But when the battle ends, DMA is called again and the RAM data that contains the scripts is moved.
Thus, the game has a good chance to try to execute an invalid script and crash because of that, and a low chance to execute the code well.

This is quite annoying since most of the interesting codes use this "overworld script" subroutine (with it, you can trigger multiple things at once with a short code).

The only solution I found so far would be to put many "MasterBall 0x0001" right before the code, as bytes 0x00 and 0x01 are script values that don't do anything.
This would increase the chances of getting the code to work (but not to 100% because of the initial DMA translation), and it would also make things less easy to manipulate (this stack would need to be removed to duplicate new glitch items in order to create new codes, so you would also to duplicate a stack of Master Balls to create many tiny stacks and put them in front.

It is unfortunately not possible to manipulate the DMA when the battle ends. I do not know if DMA could be desactivated though (this would be a good solution)

The RAM data right before PC Items consists of some unknown/trash data, so it cannot be changed to be helpful.

If the overworld scripts could be used directly during the battle, the issue would also be solved. But I don't know if such a thing is possible (I never saw the game trigger a script like credits during a battle)


So as of now, the state of Arbitrary Code Execution with Pomeg Glitch is still not completed.

I have a pretty small question… where even is the player data located at? At around what address? I know that it changes, but I don't know where to look for it, I wanted to test some invalid genders.

*some reversing later*

Seems the function at 0x8076C2C (labeled as prev_quest_set_mode_3_and_stuff in the Emerald .idb) is what does the DMA stuff.

It basically does the following:

- saves off into the stack, the int32s at 0x30022CC and 0x30022D0
- zeroes 0x30022CC and 0x30022D0
- zeroes 0x203CF5C
- copies the three DMA-translated blocks of memory away: 0xF2C bytes from the DMA-translated block pointed to by 0x3005D90 into 0x2000000, 0x3D88 bytes from the DMA-translated block pointed to by 0x3005D8C into 0x2000F2C (directly after the first block), 0x83D0 bytes from the DMA-translated block pointed to by 0x3005D94 into 0x2004CB4; a total of 0xD084 bytes.
- calls the function at 0x8076BDC, which takes a int16 "seed value" derived from adding together the int8s at 0x200000A through 0x200000D (this is actually the trainer ID and secret ID – this additional entropy is only used in Emerald, FRLG just uses RNG output for this), and adds it with some RNG output, then uses this value to set the new DMA base addresses (and then calls a couple of other functions to derive some variable pointers using the new base addresses).
- copies the data from 0x2000000/0x2000F2C/0x2004CB4 to the new base addresses
- calls a function at 0x8000B1C that basically sets the entire block of memory at 0x2000000-0x201C000 as allocatable by the internal memory management library, therefore allowing the block to be clobbered by some other gamecode
- restores the saved values of 0x30022CC and 0x30022D0
- gets an int32 from the RNG and uses this as a new XOR key: a function is called that takes a bunch of (DMA-translated) addresses, decrypts them with the saved XOR key at offset 0xAC into the DMA-translated block pointed to by 0x3005D90 (which got copied to 0x20000AC earlier) and re-encrypts them with the new XOR key
- sets the new XOR key, overwriting the saved XOR key in the DMA-translated block.

In theory, you'd be able to use this information to set up the script pointer at the place it got copied to.
In practise, other parts of the game uses this block of memory as scratch space, and it's useless to change it as the DMA-changing function will just change it right back.

I guess instead of an overworld script VM nop slide you could just copy the overworld script VM bytecode to some place in 0x200D084-0x201C000 in the payload? At least some of this block of RAM doesn't get touched at all in the overworld or in battle, it seems.

I guess instead of an overworld script VM nop slide you could just copy the overworld script VM bytecode to some place in 0x200D084-0x201C000 in the payload?

I guess instead of an overworld script VM nop slide you could just copy the overworld script VM bytecode to some place in 0x200D084-0x201C000 in the payload?

If I understood well, you would like to copy a part of the code in that area in order to make it easily executable.
How long would be a code that does such a thing ? (copy n bytes from 0xaaaaaaaa to 0xbbbbbbbb).

I checked on emulator, and data at these adresses unfortunately doesn't stay when saving/resetting.
Thus, another area unaffected by DMA and not frequently used (or used for event things) would be needed first to make things work. (Unless both the copy of the bytes and the call to the overworld script subroutine can be done with a single code execution)

If a code to copy bytes from an adess to another isn't that long to write, then it could be used to create a Pokémon whose data contains the copied string of bytes.
Then, by placing such a Pokémon in a party slot, their data wouldn't move during all the procedure (because party pokémon data isn't affected by DMA).
This would need some refinement in order to see how to store the code in the Pokémon's data (or to see which in-game traded Pokémon could have its data modified to store code), but it would solve the issue on E/Fr/Lg.

Your code would just copy your script bytecode to some other location, then set up the overworld script to use that location. Saving and resetting doesn't matter, the only thing that matters is if it gets clobbered between the time you get code exec, and when the script executes back at the overworld. Which it doesn't seem to be if you put it at 0x200D084 as far as I can tell.

A quick memcpy would even be game-agnostic, as you could use the GBA BIOS call to do that (you could find the ASLR base address for your game, get the location of your payload from that into r0, put 0x200D084 into r1, put 0x100 in r2 to always copy 0x200 bytes (this should be enough, yes?), and svc 0xb (CpuSet)).

So, something like this… (please note: untested.)

; fasmarm syntax
thumb ; we don't want an ARM-mode payload
; code starts below

; not shown: payload prologue.
ldr r0,[saveblock1_base] |
ldrh r1,[pc_offset]            | replaced (if possible) with the use of pcitem_adress
ldr r0,[r0]                        |
adds r0,r0,r1
ldr r1,[bytecode_base]
movs r2,#0x100 (0xF0 is enough)
svc #0xb ; CpuSet
; now call script_run with r0=bytecode_base
; not sure if the bios call clobbers any registers.

bytecode_base: dw 0x0200D084 ; you might want to increase this value if something gets screwed by this; however anything from 0x200D084-0x201C000 should be OK.
pcitem_adress : dw  0x(Adress of Pc Item #1) (considering a certain game and a certain DMA translation)

Code (at $E0F14D0):
  ; Setup to execute a subroutine
  mov r0, r15
  add r0, #0x9
  mov r14, r0
  ; Pointer to the script engine subroutine
  ldr r1, =RunScriptOffset
  ; The script engine subroutine takes the pointer to a script in R0
  ldr r0, =bytecode_base (adress where the previous 0x100 words were copied)
  ; Do some magic
  bx r1
  pop {r4-r7, r15}
  ; This nop is necessary because 4 byte alignment for ldr
  nop
RunScriptOffset:
  ; Pointer to the script engine subroutine
  dcd 0x08098EF9