-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathsave_exploit_one.txt
55 lines (54 loc) · 2.77 KB
/
save_exploit_one.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
<`-`> vifino: are you hear
<`-`> here
<`-`> aww
<`-`> Anyways, about to get a sucessful ROP under Pokemon Blue using a save file
<`-`> I've got a function thats writing into the stack
<`-`> All I have to do is control what gets written
<`-`> So, I know that I'm copying corrupt move data from DC77, which may be a WRAM address controlled by me
<`-`> DC77 is a pokemon box
* Pebbe is now known as Pebbe|Away
<`-`> Huh, it's not very user controlled
* Pebbe|Away is now known as Pebbe
<`-`> So it's in a memory copy loop...
<`-`> It's writing a value from D8FF to DC77, which gets written into stack later on
<`-`> If I can control D8FF, I have full code exec in Pokemon Red from a save file
* Pebbe is now known as Pebbe|Away
* Pebbe|Away is now known as Pebbe
<`-`> So, I found the root of the problem
<`-`> It calls GetName for an invalid name pointer (move 0xBF) and corrupts a major part of memory
<`-`> and that corruption cascades down into the stack
<`-`> So the entire memory corrupts itself with a repeating pattern
<`-`> Nice.
<`-`> #lua 0x14
<|0xDEADBEEF|> > 20
<`-`> #lua 0xD0E1-0xCD6D
<|0xDEADBEEF|> > 884
<`-`> So I have 844 bytes to work with, potentially
<`-`> And it copys ram until 0xE11A
<`-`> So, it starts uncontrollably copying bytes from 0xCD6C to 0xD0E1-0xE11A
<`-`> #lua 0xE11A-0xD0E1
<|0xDEADBEEF|> > 4153
<`-`> So it copies 4kb of ram onto itself
<`-`> Actually, no
<`-`> It stops copying at source 0xDFE7, dest 0xE360
<`-`> #lua 0xCD6C-0xDFE7
<|0xDEADBEEF|> > -4731
<`-`> wat
<`-`> oh
<`-`> Anyways, nearly 5kb of uncontrolled copy
<`-`> The uncontrolled copy only stops because a vsync happens mid copy, which calls a function that has 0x50 in it's address
<`-`> And then because of stack corruption, it returns to address 0x7A7A
<`-`> Which is in the middle of a function named HealEffect
<`-`> which is why a random message prints on the screen
<`-`> So it draws the battle interface on top of the stats screen, and claims that some heal failed
<`-`> Then it jumps to the middle of the trading menu, where it claims the trade was canceled
<`-`> Which is in the middle of the Cable Club's code
<`-`> So pretty much I can crash the game by copying invalidly terminated item data into memory
<`-`> Now, if I could get an uncontrolled copy from high to low in an area we can modify, I could have my fun
<`-`> But anyways, it's quite unfortunate that I didn't get to exploit the game
`-`> Oh... it's tile map data.
* KittyKattMeow has quit (Ping timeout: 186 seconds)
<`-`> So the exploit has different effects depending on what I do before triggering it
<`-`> Thats... nice...
The bytes located at 0xCE90 (or 0xCE22) get copied to 0xDFED, which is the stack pointer for the FormatMovesString function before it returns.
If 0xCE90 can be something located in SRAM, we could jump to our own code and execute.