Advertising (This ad goes away for registered users. You can Login or Register)

Everything you should know about exploits!

All the Help you need is here
TiPi
Retired Mod
Posts: 740
Joined: Tue Sep 28, 2010 5:32 am
Contact:

Everything you should know about exploits!

Post by TiPi » Thu Dec 29, 2011 6:02 pm

Hello guys.

About a year ago, while working on VSHBL with some1 and Nymphaea, I wrote a tutorial concering exploits.
With the news of the exploits on the PSV, I decided to translate it to English.

I hope you guys like it! :)
---------------------------------------------------------------------
What does this tutorial offer you?
-> You will be able to install and use “PSPlink”, a program to analyze whatever happens beyond the screen of your PlayStation device.
-> You will understand what exploits are and how they are triggered
-> You will know some MIPS, that's an assembly language
-> You will be able to determine what kind of crashes or glitches are exploitable

Don't expect that you will immediately find such exploits after reading this tutorial. You still need lots of luck and patience.

For Dutch people out there: I also wrote this tutorial in Dutch here.
Index
1. Introduction
-1.1. Getting started
-1.2. How to install PSPlink
-1.3. Some words explained
-1.4. Useful PSPlink commands
-1.5. Different exploits
--1.5.1. Usermode exploits
--1.5.2. Update mode exploits
--1.5.3. Kernel exploits
--1.5.4. Pre-IPL exploits
2. Exploit hunting
-2.1. Make it crash!
---2.1.1. VSH exploit
---2.1.2. A Theme crash
---2.1.3. A Game exploit
-2.2. The crash log
---2.2.1. Exception types(1)
---2.2.2. Do I have control over certain registers?
---2.2.3. Why does my device crash?
--2.3. What's going on?
---2.3.1. Disasm it!
---2.3.2. Well.. is it exploitable?
---2.3.3. Analyzing the whipEout theme crash
--2.4. Searching for registers, adapting them, and checking them.
--2.5. Testing your exploit
--2.6. Successful exploits
-3. Sources and links
--3.1. Thank you!
--3.2. Handy links
--3.3. Sources
1. Introduction
1.1. Getting started
To exploit a PSP device, you'll need the following things:
-A hex-editor. In this tutorial, I use XVI32
-A file to exploit
To exploit a PSP device, you'll need some kind of file to load that exploits vurnerable libraries. In this tutorial, I will be using a PSP theme, a .PTF file since they're easy to craft in a way they make the PSP system crash. However, I got to admit that those files are completely unexploitable since PTF is a read-only format. Your chances are higher using a TIFF image file or something like that.
-An USB cable
-A hacked PlayStation Portable device (Here's how)
-PSPlink
-Optional: TiPi Random Stuff Generator
-For savegame exploits: savegamedeemer
1.2. How to install PSPlink
-Download PSPlink
-Download the PSPlink drivers:
-These when you have a x86 system.
-These when you have a x64 system.
-Now install those drivers and unpack these files to a folder on your computer.
-Unpack the PSPlink folder to \PSP\GAME on your PSP PRO DUO stick
-Create a folder called “seplugins” in the root of your memory stick.
-Move the files “usbhostsfs.prx” and “psplink.prx” to that folder.
-Create two text files, one called GAME.txt and one called VSH.txt, within that folder, containing the following text:
ms0:\seplugins\psplink.prx 1
-Now activate those plugins in the Recovery Menu (Hold R while starting up your PSP)
-Run “usbhostsfs_pc.exe”. You should see the following information:
USBHostFS (c) TyRaNiD 2k6
Built Jan 21 2009 19:52:56 - $Revision: 2368 $
Don't panic when there went something wrong. On some 64-Bit systems, problems may occur due the fact that this program uses unsigned drivers. You'll have to sign them yourself then.
-Now start “pspsh.exe”, you should see the following text:
host0:/>
-On the “usbhostsfs_pc.exe” screen the following text appears:
Accepting async connection (0) from 127.0.0.1
Accepting async connection (2) from 127.0.0.1
Accepting async connection (3) from 127.0.0.1
-Now turn on your PSP. Make sure that the device is connected to your PC using the USB cable.

-On the “usbhostsfs_pc.exe” screen, the following text should pop-up:
Connected to device
and on “pspsh.exe”:
Loading all modules ... Ready
or
host0:/>
-Congratulations! Right now, your PSP is ready to transfer crash logs to your PC!
1.3. Some words explained
-VSH: The main menu of the PSP.
-flash0: The internal PSP storage disk where the system software is stored
-Savegame: The game progress data that is stored on your PSP.
-Word: 4 bytes
-Halfword: 2 bytes
1.4. Useful PSPlink commands:
-disasm {0x0XXXXXXX} Y
→ Gives you a list of the executed MIPS-instructions. All X characters represent a HEX-character, together they form the memory address of the wanted instruction. Y represents the amount of listed instructions you want to see listed.
Example:  disasm 0x09B5A400 30
-calc {0x0XXXXXXX}{+/-/...}{Y}
→ Using the calc function you can calculate with HEX addresses. You can use it to substract a
a number of instructions from an address to view the Y-amount instructions before that I instruction. Example: calc 0x09B5A400-50 will give you 0x09B5A3CE
Of course, you can also use the standard calculator for your OS. They should have a HEX mode. There are also various ways to calculate with HEX addresses available on the internet.
-savemem 0x08800000 20000000
→ Use this command to take a “memory dump”. -Literally a dump of the current memory on your PSP device. Note: you don't really need to change the arguments here (unless you want to dump kernel memory or if you don't want to dump the whole memory (24MiB)!
-bpset {0x0XXXXXXX}
→ Using this command, you can determine whether the code jumps to a certain address. If you injected some kind of jump somewhere, it's very handy to determine whether the system eventually jumped to that address. When such a breakpoint occurs, the system freezes.
-exresume
→ Use this to de-freeze the system again after a breakpoint. You can also use  bpset $epc 0
-memprot off
→ Use this when the crashing line isn't shown.
1.5. Different exploits
There are different exploits. Each allowing you to access certain parts of the system software, or giving you certain permissions. There's some sort of “ranking” of value and rarity. In this tutorial, I will be teaching you how to look after a “GAME”, “DEMO” or “VSH” exploit. I might write a tutorial on other exploits later on.

1.5.1. Usermode exploits
-An usermode exploit is an exploits that's loaded trough the execution of a certain function within the XMB or GAME. Most likely, they cover some buffer overflows.

Game/Demo exploits
-The only difference between those two is that DEMO exploits can be freely downloaded to a memory card. These exploits are triggered trough a coding mistake within a certain game. More information about this later on.
→ Possibilities of a GAME/DEMO exploits
-Triggering an “e-loader” to load unsigned homebrews without the need
of CFW or a kernel exploit
-It can be used to trigger certain kernel exploits
-Examples: Sukkiri Sudoku Demo exploit
Patapon 2 demo exploit
Everybody's Golf (Hot Shot's Golf)-Game exploit
MOHH exploit
GTA:LCS exploit

VSH exploits
-These exploits are triggered trough a file in the XMB, like a special crafted image or video file. These exploits have more imports than a game exploits, which means that they have more functions to use, such as flash0 read permissions. Therefore, it's easy to combine these with a kernel exploit.
→ Possibilities of a VSH exploit
-They are most likely combined with a kernel exploit.
-Example: ChickHEN (TIFF exploit)
VSHBL Exploit (unreleased yet)

1.5.2. Update-mode Exploits
-To be honest, we know less about these. Mainly because it's only a theoretical concept, we haven't found one yet. It would offer you more privileges than an usermode exploit, but that wouldn't offer you kernel access.

1.5.3. Kernel Exploits
A kernel exploits gives us access to the whole kernel, to the system files stored onto flash0. It involves a mistake in a kernel function of the system software, and they are often triggered by an usermode exploit

1.5.4. Pre-IPL exploits
The PRE-IPL is a complex thing, so let's just drop the technical details. A pre-IPL (Pre-Initial Program Loader) is some sort of program that executes before the actual system software. It checks whether your device is not hacked and if it is, it will result in an infinite loop, a brick. A team of developers managed to find a PRE-IPL exploit to put the system in service mode and to allow custom system software on the device. It was called “Pandora Battery”. Unfortunately, Sony fixed this exploit on the latest PSP devices. (From datecode 8C)
They can't fix it for the older PSP's, since this is a hardware exploit. Otherwise they'd have to adapt the motherboard.
2. Exploit hunting
2.1. Make it crash!
2.1.1. A VSH exploit
VSH exploits aren't the easiest to start with, but they have more value than a game or demo exploit.

Most VSH exploits start with a crash or a glitch. Not a random freeze or glitch, but a glitch that you intentionally caused. Since you want to “play around” with the memory, you'll have to be able to edit the crafted file that crashes your PlayStation portable. Therefore, we use a “hex-editor”.

Most of the VSH exploits were found in the “TIFF” image format. But also other types of files are interesting to exploit, like a MP4 movie or an MP3 song.

Normally, you should try to find those exploits within the libraries used on the device itself. But there's a chance you don't have enough knowledge yet to find exploits within those libraries. Therefore, we'll just make some changes within the file. Hope you're lucky today!

Once you got a crash, don't start to party yet. A crash is NOT an exploit. It's a crash. Some crashes are interesting though. That depends on the influence you've got on the memory and on the instructions executed before and after the crash.

Okay, let's get started. Grab a random PSP theme. We will be using the whipeEout pure theme. Just save it somewhere and copy it to /PSP/THEME on your memory card.

2.1.2. A theme crash
Now open that .PTF file in the HEX editor. You should get something like this:
Image

Okay.. let's try to generate a crash! Attention: the space before the blue marker is the header. You better stay away of it. Most likely, the file would get corrupted when you make any major changes to that spot.

Let's do something naughty. Let's change all NULL (00) bytes AFTER the cursor to 61 (a). Just to generate a crash. Of course, we should learn more about the file structure before we try to exploit this thing. But I don't have enough time to cover that (since there's a huge load of file structures out there)..
The character we inject doesn't really matter, but I use “a” because it's easy to recognize in a crash log later on. The file now looks like this:
Image

Anyways, let's save our crafted file and load it trough the XMB! (Make sure PSPlink is ready to capture a potential crash). The icon of the theme says “corrupted”, but hey, nothing resists of of trying to apply the theme, no?

If everything went alright, your PlayStation Device crashed. If not, just try to do something else with the file. Or learn more about file structures to achieve a decent crash.

Here's the crash log that should pop up:
Image

Alright. This is probably Chinese to you. Not a problem, in the chapter 2.1.3. you'll find some information that may help you out!

2.1.3. A game exploit
Game exploits have less value than a VSH exploit, but they're also pretty cool
to find. Using savegamedeemer you can decrypt
savedata and exploit it! Just activate the plugin the same way you activated PSPlink, play the game you want to exploit and save. Then open up /PSP/SAVEPLAIN and open SDDATA.BIN using your HEX-editor.

The most popular way to search for a savegame exploit is trough a visible variable such as a player name in the game. Say there are 10 characters
reserved for the storage of the name, and you inject 20 characters, your PSP
has a problem. It's like pouring 2 liters of water into a bucket that only can hold only one liter. There's an “overflow”. If the game has a bug, it can't handle that.

Now just load the game again and try to load your malicious savegame. There's a chance the game crashes. Congratulations, now continue to 2.2.!
2.2. The crash log
Before we start, some definitions:
BADVAddr -> Bad Virtual Address
Status -> Status Register
Cause -> Cause Register
EPC -> Exception Program Counter Register
Note that it could happen that a crash occurs twice, or that you trigger two crashes at once. Then your PSP will shut itself down immediately and are the crashes useless. There are some chances to prevent a certain crash from occurring though.

2.2.1. Exception types (1)
The first thing you'll see, is the type of crash. This line includes to determine whether the crash is useful or not. Pay attention now!
0-> External Interrupt (Useless!)
1-3-> Reserved (Probably an FPU exception, Useless!)
→ FPU-E: Math error, like a devision by zero.
4-> Address Error (Load or instruction fetch, may be useful)
5-> Address Error (Data store) (Might be useful)
6-> Bus Error (instruction fetch) (May be useful)
7-> Bus Error (data load or store) (Might be useful)
8-> Syscall instruction (Useless!)
9-> Breakpoint (In 99% of the cases useless, unless you can control $ra)
10-> Reserved instruction (Useless!)
11-> Coprocessor unusable(Useless!)
12-> Arithmetic overflow (Useless)
13-15->Not used
2.2.2. Do I have control over certain registers?
It's very important to have control over certain registers. That way, you can influence what happens with those instructions. If you're lucky, you can inject a jump to your code this way.. more on that later.

There are different sorts of “registers”, spaces to put certain data in, each having their own function. Here's a list of them:

$zr → Always 0x00, often used to set registers to zero
$at → Assembler reserved
$v0-v1 → Function return
$a0-a3 → Incoming arguments
$t0-t9 → Temporary registers. (So not that handy when it comes to exploiting..)
$s0-s7 → Saved temporary registers
$k0-k1 → Exception handling ← Kernel registers!
$gp → Global data pointer
$sp → Stack pointer
$ra → Return address, the system will jump (return) to this address when the instructions are completed. Obviously, control over this register is very handy to jump to your code!

Well.. how do you determine whether you have control then? Well, normal usermode memory addresses start with 0x08, 0x09, 0x48, 0x49 (these are uncached addresses), 0x0A, 0x0B, 0x00 ($zr..), DEADBEEF (register not used yet), 0xFF (There may be some influence here, but in most of the cases, this influence isn't really handy).
Image

Let's use this information to analyze our whipEout theme crash:
→ Influenced registers:
-$v0: this one is clearly influenced, since we injected a's (0x61)
-$a0: 0x6A0F51E0 not a normal address..
-The other registers as $v1,$a1 $a3, $t0, $t1, $s1, $s2, $s5 could be influenced as well, more on this later.
Do you have control over certain registers? Good, continue to 2.2.3!

2.2.3. Why does my device crash?
Before we start analyzing the crash, it's always interesting to know why your device crashed. The command that made the device crash, is most likely located at the “crashing line” (3).

I'd write a document with all the MIPS commands used on the PSP, but I'd rather not re- invent the wheel, so I refer to this topic.

Quick note: all jumps and branches have a “delay slot”, a function that is executed after the instruction itself. Some branches have a “l” on the end of their name, which stands for “likely”.
In this case, the delay slot instruction will only be executed when the situation meets a certain requirement.

In this case:
bnezl $a3, 0x09C1E998
This means (branch not equal to zero + likely), so it will check whether $a0 is not zero, what is the case in here. So it doesn't execute the delay slot, and crashes. What means that we have influenced $a3 somehow.
2.3. What's going on?
2.3.1. Disasm it!
To know what instructions are executed before and after the crash (in memory address order), we use the “disasm” command (see 1.4.), we'll also be using the EPC (see 2.2.)

To know whatever happens just after your crash, just use the following command:
disasm {epc} 30 ← amount of lines we want!

Just keep increasing that amount until you spot the command “jr $ra” , in certain circumstances, it could take a while until this instruction appears. This only occurs in huge functions, but it makes exploiting harder, since more instructions are being executed on the (influenced) registers.

Anyways, for our crash, we use the following command:
disasm 0x09C1E9C0 30

That generates the following output:

Code: Select all

0x09C1E9C0: 0x54E0FFF5 '...T' - bnezl $a3, 0x09C1E998
0x09C1E9C4: 0x8C830008 '....' - lw $v1, 8($a0)
0x09C1E9C8: 0x00001021 '!...' - move $v0, $zr
0x09C1E9CC: 0x50400004 '..@P' - beqzl $v0, 0x09C1E9E0
0x09C1E9D0: 0x00001821 '!...' - move $v1, $zr
0x09C1E9D4: 0x94C20006 '....' - lhu $v0, 6($a2)
0x09C1E9D8: 0x00001821 '!...' - move $v1, $zr
0x09C1E9DC: 0x00C2180B '....' - movn $v1, $a2, $v0
0x09C1E9E0: 0x03E00008 '....' - jr $ra
0x09C1E9E4: 0x00601021 '!.`.' - move $v0, $v1
0x09C1E9E8: 0x0A707A78 'xzp.' - j 0x09C1E9E0
0x09C1E9EC: 0x00001821 '!...' - move $v1, $zr
0x09C1E9F0: 0x27BDFFF0 '...'' - addiu $sp, $sp, -16
0x09C1E9F4: 0xAFBF0000 '....' - sw $ra, 0($sp)
0x09C1E9F8: 0x0E712498 '.$q.' - jal 0x09C49260
0x09C1E9FC: 0x00 '....' - nop
0x09C1EA00: 0x8FBF0000 '....' - lw $ra, 0($sp)
0x09C1EA04: 0x03E00008 '....' - jr $ra
0x09C1EA08: 0x27BD0010 '...'' - addiu $sp, $sp, 16
0x09C1EA0C: 0x3C032E47 'G..<' - lui $v1, 0x2E47
0x09C1EA10: 0x2CA50010 '...,' - sltiu $a1, $a1, 16
0x09C1EA14: 0x3463494D 'MIc4' - ori $v1, $v1, 0x494D
0x09C1EA18: 0x14A00005 '....' - bnez $a1, 0x09C1EA30
0x09C1EA1C: 0x00003021 '!0..' - move $a2, $zr
0x09C1EA20: 0x8C820000 '....' - lw $v0, 0($a0)
0x09C1EA24: 0x3C05312E '.1.<' - lui $a1, 0x312E
0x09C1EA28: 0x10430003 '..C.' - beq $v0, $v1, 0x09C1EA38
0x09C1EA2C: 0x34A53030 '00.4' - ori $a1, $a1, 0x3030
0x09C1EA30: 0x03E00008 '....' - jr $ra
0x09C1EA34: 0x00C01021 '!...' - move $v0, $a2

Sometimes, it could be handy to know what happens before your crash. Therefore, you can subtract the EPC by a number (f.e. 50) using the calc function. (See 1.4.)

For our crash, that makes:
calc 0x09C1E9C0-50

Output:
0x09C1E98E.

Let's disasm that:
disasm van 0x09C1E98E
Output:

Code: Select all

0x09C1E98C: 0x00004021 '!@..' - move $t0, $zr
0x09C1E990: 0x00604821 '!H`.' - move $t1, $v1
0x09C1E994: 0x8C830008 '....' - lw $v1, 8($a0)
0x09C1E998: 0x25080001 '...%' - addiu $t0, $t0, 1
0x09C1E99C: 0x00803021 '!0..' - move $a2, $a0
0x09C1E9A0: 0x24620020 ' .b$' - addiu $v0, $v1, 32
0x09C1E9A4: 0x30630003 '..c0' - andi $v1, $v1, 0x3
0x09C1E9A8: 0x0109382B '+8..' - sltu $a3, $t0, $t1
0x09C1E9AC: 0x1460000E '..`.' - bnez $v1, 0x09C1E9E8
0x09C1E9B0: 0x00822021 '! ..' - addu $a0, $a0, $v0
0x09C1E9B4: 0x8CC20000 '....' - lw $v0, 0($a2)
0x09C1E9B8: 0x50450007 '..EP' - beql $v0, $a1, 0x09C1E9D8
0x09C1E9BC: 0x94C20006 '....' - lhu $v0, 6($a2)
0x09C1E9C0: 0x54E0FFF5 '...T' - bnezl $a3, 0x09C1E998
0x09C1E9C4: 0x8C830008 '....' - lw $v1, 8($a0)
0x09C1E9C8: 0x00001021 '!...' - move $v0, $zr
0x09C1E9CC: 0x50400004 '..@P' - beqzl $v0, 0x09C1E9E0
0x09C1E9D0: 0x00001821 '!...' - move $v1, $zr
0x09C1E9D4: 0x94C20006 '....' - lhu $v0, 6($a2)
0x09C1E9D8: 0x00001821 '!...' - move $v1, $zr
0x09C1E9DC: 0x00C2180B '....' - movn $v1, $a2, $v0
0x09C1E9E0: 0x03E00008 '....' - jr $ra
0x09C1E9E4: 0x00601021 '!.`.' - move $v0, $v1
0x09C1E9E8: 0x0A707A78 'xzp.' - j 0x09C1E9E0
0x09C1E9EC: 0x00001821 '!...' - move $v1, $zr
0x09C1E9F0: 0x27BDFFF0 '...'' - addiu $sp, $sp, -16
0x09C1E9F4: 0xAFBF0000 '....' - sw $ra, 0($sp)
0x09C1E9F8: 0x0E712498 '.$q.' - jal 0x09C49260
0x09C1E9FC: 0x00 '....' - nop
0x09C1EA00: 0x8FBF0000 '....' - lw $ra, 0($sp)


2.3.2. Well.. is it exploitable?
There are various important factors to determine whether your crash is exploitable or not. These are the most logical ones:

-Using a jump
→ Example: jr/jalr $v1 (exploitable when we can control $v1)
-Using a sw (store word) command
→ Using this method, we could inject jumps.
Example: sw $v0, $v1 (could be exploitable when we're able to control both registers)

-Using a workaround
→ When you can influence a register that influences another register that jumps to another register ect.. your crash could be exploitable! Just try to get control/inject a jump somehow. Be creative!

→ To know whether your code did jump to that certain memory address, you could set a breakpoint. (See 1.4.)

2.3.3. Analyzing the whipEout theme crash

Code: Select all

0x09C1E98C: 0x00004021 '!@..' - move $t0, $zr
→ $t0 = $zr, → $t0 = 0x00

Code: Select all

0x09C1E990: 0x00604821 '!H`.' - move $t1, $v1
→ $t1 = $v1

Code: Select all

0x09C1E994: 0x8C830008 '....' - lw $v1, 8($a0)
→ Load the word stored into [$a0+8]+the following 3 bytes

Code: Select all

0x09C1E998: 0x25080001 '...%' - addiu $t0, $t0
→ $t0 = $t0 + 1 (now is $t0 0x001)

Code: Select all

0x09C1E99C: 0x00803021 '!0..' - move $a2, $a0
→ $a2 = $a0

Code: Select all

0x09C1E9A0: 0x24620020 ' .b$' - addiu $v0, $v1, 32
→ $v0 = $v1 +32

Code: Select all

0x09C1E9A4: 0x30630003 '..c0' - andi $v1, $v1, 0x3
→ $v1 = $v1 & 0x03

Code: Select all

0x09C1E9A8: 0x0109382B '+8..' - sltu $a3, $t0, $t1
→ Is $t0 less than $t1?

Code: Select all

0x09C1E9AC: 0x1460000E '..`.' - bnez $v1, 0x09C1E9E8
→ Jumps to that memory address when $v1 != 0

Code: Select all

0x09C1E9B0: 0x00822021 '! ..' - addu $a0, $a0, $v0	

→ $a0 = $a0 + $v0

Code: Select all

0x09C1E9B4: 0x8CC20000 '....' - lw $v0, 0($a2)
→ Load word from $a2 into $v0

Code: Select all

0x09C1E9B8: 0x50450007 '..EP' - beql $v0, $a1, 0x09C1E9D8
→ If $v1 = $a1, then jump to the instruction on 0x09C1E9D8

Code: Select all

0x09C1E9BC: 0x94C20006 '....' - lhu $v0, 6($a2)
→ Load halfword of [$a2+6] and the following byte

Code: Select all

0x09C1E9C0: 0x54E0FFF5 '...T' - bnezl $a3, 0x09C1E998
→ Go to the instruction when $a3 = 0
--CRASH LINE--

Code: Select all

0x09C1E9C4: 0x8C830008 '....' - lw $v1, 8($a0)
→ Load word from [$a0+8] and the following 3 bytes

Code: Select all

0x09C1E9C8: 0x00001021 '!...' - move $v0, $zr
→ $v0 = 0x00 (so we can't use any control over $v0)

Code: Select all

0x09C1E9CC: 0x50400004 '..@P' - beqzl $v0, 0x09C1E9E0
→ When $v0 = 0x09C1E9E0, then go to the instruction (?)

Code: Select all

0x09C1E9D0: 0x00001821 '!...' - move $v1, $zr
→ $v1 = 0x00

Code: Select all

0x09C1E9D4: 0x94C20006 '....' - lhu $v0, 6($a2)
→ Load a half word from [$a2+6] and the follwing byte

Code: Select all

0x09C1E9D8: 0x00001821 '!...' - move $v1, $zr
→ $v1 = 0x00

Code: Select all

0x09C1E9DC: 0x00C2180B '....' - movn $v1, $a2, $v0
→ “move not zero”, when $v0 is greater than 0, $v1 = $a2

Code: Select all

0x09C1E9E0: 0x03E00008 '....' - jr $ra
→ Go to the return address
More information here and here.
You probably already noticed, this crash is NOT exploitable. We can't influence a jump, nor inject a mini-jump or think of a fancy workaround.
2.4. Searching for registers, adapting them, and checking them
Most of the data is stored backwards. When you inject 0x12345678 into a file,
0x78563412 will be displayed in the crash log.
In this case, it's quite simple. $v0 equals 0x61616101. Let's search for that string in the file as 0x01616161 and replace it with 0x61616161, then try to cause the crash again. The result:
Image

Awww yeah! $v0 changed to 0x61616161, what means that we have full control over this register!

Now let's try to get control over $a0. That's more difficult, since we know that $a0 gets $v0+$a0 somewhere in the code. Let's illustrate that by changing the “aaaa” of $v0 to “!!!!”.
Et voila! ($a0 -> 0x6A0F5060 != $a0 -> 0x29CF5200)
If we revert all those instructions executed on $a0, we'll get the $a0 “start” address, which is probably a normal memory address. This means that $a0 is only influenced due the fact that we could influence $v0.

You may want to determine the exact place of where a register loads its data in the file. Therefore, you can use TiPi Random Stuff Generator which will generate random data to inject into the file. Now there are fewer possibilities (remember that data is stored backwards!), then just search for those possibilities, f.e. When $v0 = 0x29A9923C, search for 3C93A929 in the file and rename them to 0x11, 0x22, 0x33... to determine what possibilities is the spot you're looking for.
2.5. Testing your exploit
When you finally found an exploitable crash (congratulations!), you want to test it, of course. When you have determined how you can make the code jump to a certain address using the list of MIPS commands, you can determine the jump point. (Where is the code located? Where do you want to “jump”?)

The code itself can be a simple PoC (Proof on Concept), like a SceKernelExitGame() (this will return you to the XMB), or other things like a
“green screen flasher”. You just have to put the code somewhere into the file to load it into the memory of the system (so we can jump to it, later on). The address of SceKernelExitGame(), you'll have to determine yourself.

Once the code is hidden in your file, cause the crash and take a memdump (see 1.4.). Then open that file in a hex editor and search for your code in the memory dump. Now you take the HEX-offset (displayed in the HEX-editor)
and add 0x08800 to it. (Now we have the exact location of the code in the memory!)

Okay, just take that address and jump to it! If that fails, the address might have been influenced somehow. Make sure you didn't forget to determine whatever happens with the address using the list of MIPS commands! If that works, you can write a BIN loader to load a hello world PoC and you can port or write an eloader to launch!
2.6. Successful exploits
Eggsploit by Matiaz
Image

Patapon exploit by the HBL-team
Image

Hot Shots Golf Exploit
Image

This crash would be exploitable when..

Image
Image
(We can inject a jump!)
Image
Image
3. Sources and links
3.1. Thank you!
First of all I'd like to thank the following people:
-Some1
-Nymphaea
-m0skit0
-Wololo
-JJS
-You, for reading this tutorial (and leaving a comment (?))
3.2. Handy links
3.3. Sources
This was the end of the tutorial. Will try to update it from time to time. Reactions or feedback are always welcome.
This tutorial may include some small mistakes, feel free to correct them. Same goes for language mistakes.
If there are any further questions on this subject, feel free to ask them!
Advertising
Problems or questions? Feel free to contact me.
-My Blog-

Josh 443
Posts: 5
Joined: Wed Dec 28, 2011 1:01 am

Re: Everything you should know about exploits!

Post by Josh 443 » Fri Dec 30, 2011 6:52 pm

How would I be able to do this with a Linux (ubuntu-based) computer?
Advertising
Image

TiPi
Retired Mod
Posts: 740
Joined: Tue Sep 28, 2010 5:32 am
Contact:

Re: Everything you should know about exploits!

Post by TiPi » Fri Dec 30, 2011 9:24 pm

Josh 443 wrote:How would I be able to do this with a Linux (ubuntu-based) computer?
The only thing that differs is the installation of PSPlink. This link may help you.
Problems or questions? Feel free to contact me.
-My Blog-

User avatar
noname120
Developer
Posts: 777
Joined: Thu Oct 07, 2010 4:29 pm

Re: Everything you should know about exploits!

Post by noname120 » Wed Jan 11, 2012 10:03 pm

Quite interresting !
I hope we can find exploits in the psp emulator of PSV so can we take the control of the PSV ! (at least it's executed with user mode, hopeful these stupid guys make it uses Kmode :D )

Hope Sony won't delet the psp emulator if we do that (hope they won't do like otherOS)
Funny stuff
<yifanlu> I enjoy being loud and obnoxious
<yifanlu> rooting an android is like getting a hooker pregnant
<xerpi> I sometimes think I should leave all this stressing **** and be a farmer instead

wth
HBL Developer
Posts: 834
Joined: Wed Aug 31, 2011 4:44 pm
Contact:

Re: Everything you should know about exploits!

Post by wth » Sun Jan 15, 2012 8:14 am

awesome thx !
I just found a psn demo save exploit yay
I tested it using a jump to sceKernelExitGame, but it's kinda boring to retrieve a function true address so I tested it using the full game version instead, to be able to retrieve sceKernelExitGame's address easily xD

but on the demo, apart from the freeze due to my sceKernelExitGame's false address causing a breakpoint since I didn't bother figuring the real one yet, there's the exact same bug & apparently working the exact same way so it's really a ready-to-use save exploit (for vita :P)


Also, does anyone know how to encrypt a savegame deemer plain save back to original ? because since it's an exploit, savegame deemer is not really gonna be able to encrypt it back lol



Edit: sry, just followed TiPi's link : wololo's tutorial
It works perfectly :mrgreen:
My exploit behaves a little differently on the demo however finally, so I'll have to investigate the demo a little more to make it compatible too

ultimakillz
Retired Mod
Posts: 805
Joined: Mon Sep 27, 2010 6:55 pm

Re: Everything you should know about exploits!

Post by ultimakillz » Mon Jan 16, 2012 3:19 pm

wth wrote:but on the demo, apart from the freeze due to my sceKernelExitGame's false address causing a breakpoint since I didn't bother figuring the real one yet, there's the exact same bug & apparently working the exact same way so it's really a ready-to-use save exploit (for vita :P)
is that is true then it is great news. keep the name of the game a secret and don't tell anyone who isn't known in the scene. i also suggest you send a pm to wololo with this information as he's currently spearheading porting the hbl to the vita, and a working exploit in a demo would be a great advancement.

wth
HBL Developer
Posts: 834
Joined: Wed Aug 31, 2011 4:44 pm
Contact:

Re: Everything you should know about exploits!

Post by wth » Mon Jan 16, 2012 4:09 pm

ultimakillz wrote:is that is true then it is great news. keep the name of the game a secret and don't tell anyone who isn't known in the scene. i also suggest you send a pm to wololo with this information as he's currently spearheading porting the hbl to the vita, and a working exploit in a demo would be a great advancement.
ok yeah I can't say which game it uses yet to avoid wasting it, but as I added in my previous Edit, I'm still working on making this bug exploitable in the demo version actually (the same bug occurs on the demo but somehow doesn't behave exactly the same way)
anyway I could always post a POC video of it later if I got time

but I only made the psn buyable full version's POC exploit for now

Edit: pmed wololo, I'll tell him if he's interested

Edit2: Done, Hello World ready and running on 6.60 ofw (but don't have a psvita yet, so unable to test on vita for now and since I don't have the full game on psn I also can't try it on 6.60 ofw)
[ok I could try making my demo version compatible with the exploit to actually publish a video of the hello world, but that'd just be a waste of time, I'll just wait until I get a vita]

wth
HBL Developer
Posts: 834
Joined: Wed Aug 31, 2011 4:44 pm
Contact:

Re: Everything you should know about exploits!

Post by wth » Fri Feb 24, 2012 10:31 pm

Got my vita today, here's the PoC http://www.youtube.com/watch?v=l70oGahjHh4
bad quality, sry (only have my laptop's front camera today ^^')

asdfvita
Posts: 4
Joined: Thu Feb 23, 2012 3:04 am

Re: Everything you should know about exploits!

Post by asdfvita » Sat Feb 25, 2012 5:28 pm

Thank you so much wth. It is guys/gals like you who make it possible for non tech savvy people like me to use our machines to the fullest.
Thanks, I'm looking forward to the realease of a HBL for Vita. Keep up the great :D work.

User avatar
Salahkun
Posts: 62
Joined: Wed Feb 29, 2012 4:52 pm

Re: Everything you should know about exploits!

Post by Salahkun » Sun Mar 04, 2012 11:43 am

if im exploiting a game can it brick my psp go ?
ImageImage
The Mana World Player Since 2005

Post Reply

Return to “Tutorials”