How To Crash The PSP

ChaosKnight · Post by **ChaosKnight** » Tue Apr 19, 2005 11:00 pm

qubitz - Can you post the file that crashes the PSP? I think just being able to look at it would help me understand what's going on.

Thanks.

lmx · Post by **lmx** » Wed Apr 20, 2005 12:34 am

Guessing* unhandled errors in the elf are just handled by a brute force kernel kick in the teeth (reset), until the next kernel update when scei will add another error message.

And talking abouyt exploits publicly are probably the best way to get another kernel update out quicker ;) You have another couple of months till the next baby - and everyone will want to install it with the new gubbins (browser).

*reasonably sure.

ChaosKnight · Post by **ChaosKnight** » Wed Apr 20, 2005 2:30 am

lmx - I think it maybe trying to read the PSP header and getting 0 offsets and such for data which is throwing exceptions like no tommorow. (w00t, let's execute code at a null memory address.)

Also I would welcome an update. It will give more data to compare against and if they did patch holes like that to give errors it would tell us when the same condition happened twice instead of a reboot which only tells us that it rebooted.

qubitz · Post by **qubitz** » Wed Apr 20, 2005 2:56 am

We still don't have an answer for why it only crashes on files that have not been linked. Of everything that I have used as data.psp, which includes random garbage and lots of compiled/linked code, the only thing that causes a shutoff is an unlinked ELF file. I can't see how this means anything but reading the ELF file. I'm not saying it is executing it, but it must be trying to parse it as an ELF file. How else could all of this be explained?

ChaosKnight · Post by **ChaosKnight** » Wed Apr 20, 2005 3:21 am

qubitz - If you can post your unlinked elf somewhere then I can analyze it to the best of my knowledge (i'm sure others will do the same) and maybe someone can come up with an answer.

However you can't disregard the PSP header and believe that it is trying to execute the raw unlinked elf. That's naive, especially with all the current research on PSP headers. But I could be completely off-base. That's the fun part about hacking a new console. You learn stuff.

So to summarize, post your findings for us to tear apart. ;)

qubitz · Post by **qubitz** » Wed Apr 20, 2005 3:42 am

The assembly code: http://psplinux.sf.net/files/freeze/freeze.asm

The assembled code: http://psplinux.sf.net/files/freeze/freeze.o

The linked file: http://psplinux.sf.net/files/freeze/freeze.elf

ChaosKnight · Post by **ChaosKnight** » Wed Apr 20, 2005 6:58 am

Uhm... has this been compiled with some sort of offical SDK or CodeWarrior? Not sure, but I don't think that's allowed in this community.

pedroleite · Post by **pedroleite** » Wed Apr 20, 2005 7:16 am

qubitz wrote:The assembly code: http://psplinux.sf.net/files/freeze/freeze.asm

The assembled code: http://psplinux.sf.net/files/freeze/freeze.o

The linked file: http://psplinux.sf.net/files/freeze/freeze.elf

Actually doing a strings from those binaries produces a lot of information... You have linked it against several libraries with SCE*?
You have a link to a crt0-dummy ? Dummy as in not working?
You have a gcc build for PSP? (leaked code?)
You have a newlib ? (Work in progress?)

Actually anyone could just make a crosschain for MIPS R4000, right?

qubitz · Post by **qubitz** » Wed Apr 20, 2005 7:55 am

Actually a got a binary mixed in with one someone else had assembled/linked. I replaced with with one I have assembled on my own. It has nothing from Sony/Metrowerks, and still exibits the shut off.

Kamilion · Post by **Kamilion** » Wed Apr 20, 2005 8:01 am

Looks like someone forgot about the PSP's watchdog timer.
If it doesn't receive anything, it'll shut the PSP off, which is why when you crash a game, it hangs for a couple moments then shuts off.

Keep that in mind.

qubitz · Post by **qubitz** » Wed Apr 20, 2005 8:05 am

If that were the case, could that imply that it started to load the ELF code and then crashed, which led to the watchdog timer powering off?

PspPet · Post by **PspPet** » Wed Apr 20, 2005 8:23 am

> I replaced with with one I have assembled on my own. It has nothing from Sony/Metrowerks, and still exibits the shut off.

Hmm, still looks like it is compiled with GCC (GPL) + the PSP patches (code name "Allegrex")
I suspect that is the illegally obtained CodeWarrior compiler, but I wish to be proven wrong.

---
Not to be a GPL stickler, but it you do have *legal* access to that compiler you also have legal access to the source patches (under GPL).
Unless restricted by another NDA (eg: in buying the GPL compiler), you also have the legal right to distribute those GPL patches to the community in general.

If however you obtained that compiler illegally, you should not be posting code generated by that compiler in any way-shape-or-form. That only taints the efforts of those who do not want to be tainted by the illegal CodeWarrior leak. Also against the rules of this BBS as I understand them.

If reproducable under a publicly available open-source compiler, please post details, and GPL source patches if applicable
[you aren't legally required to post GPL patches to the compiler if not releasing the actual compiler, however it would be appreciated]

IMHO: with the CodeWarrior leak, anyone relying on it should not be posting anything they learn from it on this public forum -- since it may harming the goals of others.

lmx · Post by **lmx** » Wed Apr 20, 2005 10:29 pm

So you're trying to reverse engineer something that Sony expressly doesn't want to to reverse engineer by any means possible, still against Sonys wish to protect their intellectual property? I'de suggest running any form of homebrew program will have to circumvent Sonys copy protection / operating system which is in effect what you're going to have to achieve, and is of dubious legality. Using 'legal' means to effectively open a closed system is still I believe against the law in some countries.. I'm no lawyer, I wish I was, as I'de be in for $$$ working at Sony.

So boning on about using illegally obtained dev materialls all seems a bit irrelevent. World wasn't cracked in a day etc.. Sorry to post nothing about the ELF, but I think you'de be better off garnering more support for an official solution.

Post by **ooPo** » Wed Apr 20, 2005 11:24 pm

Translation: I don't have anything dev-related to say, but I think you should forget about the law and do whatever you want.

Just because they don't want it doesn't make it illegal... yet. But that doesn't mean they aren't waiting to nail people who *do* cross the line into illegal activity.

When dealing in grey areas, it pays to be careful.

ChaosKnight · Post by **ChaosKnight** » Thu Apr 21, 2005 12:20 am

I think it might actually be able to run ELF files. To test this I changed the header of the firmware PSP file (known working) from ~PSP to ~PSX and got an error, so it does validate header...

Interesting. I documented all of this and updated certian things on the PSP File Research Thread. I just used edit because it looks stupid to reply to yourself.

MelGibson · Post by **MelGibson** » Thu Apr 21, 2005 12:40 am

Nice test Chaos.... :D

What happens if you change the header from ~PSP to ~ELF ? or .ELF ( 7F 45 4C 46 ) like in a real ELF file ?

Would try it myself.... but no PSP, yet :(

ChaosKnight · Post by **ChaosKnight** » Thu Apr 21, 2005 1:29 am

Changed it on a PSP file and it gave me the invalid header error, however I then built a blank elf file (header only) which did the exact same thing as this freeze object file.

So maybe it does try to execute ELFs... not sure, but at least I was able to reproduce the same results with a differant file (and without the SCE libs).

This is the link: www.animezilla.net/psp/freeze/eboot.pbp

PspPet · Post by **PspPet** » Thu Apr 21, 2005 1:48 am

> So you're trying to reverse engineer something that Sony expressly doesn't want to to reverse engineer by any means possible...

IMHO: There are plenty of legal "fair use"s of reverse engineering. I've hacked a few systems myself, and have been threatened by Sony too. In all cases I'm proud to say that I've only used publicly available information.

Perhaps falling on deaf ears...
If the board mods decide that using stolen software is ok, that's up to them - it is their board.

----
My commentary:
Open Source means being "Open"

One important part about an open source effort is that other people can reproduce results and get the same output (show-your-work and share-your-work)

Not wanting to share-your-work to avoid a flood of newbie questions especially at this stage is a good reason.
Not wanting to share-your-work because the first part of the instructions would be "find the illegal bittorrent..." then I think we are going down a very dangerous slope.

My suggestion for this BBS is: don't post results that your fellow members can not (legally) reproduce themselves.

ModernRonin · Post by **ModernRonin** » Sun May 08, 2005 4:59 pm

Code: Select all

.globl	main
main&#58;
	j	main

You should probably put a NOOP after "j main". Read up on the MIPS architecture - due to the way the CPU instruction pipeline works, the next instruction right after a jump is always executed even though it isn't supposed to be. This is because the CPU is always executing instructions one step ahead of the actual program counter.

http://www.mrc.uidaho.edu/mrc/people/jf ... IPSir.html

Code: Select all

.globl	main
main&#58;	j	main
           noop

I don't think this will fix your freezing problem - I think it's more likely that the watchdog isn't getting petted which is causing a reset. But it's still worth trying.

What we really need is the code to pet the watchdog. If we can put that into a forever loop, we should be able to freeze the PSP without it resetting. Then we'll know we're making progress.

In the longer term, we should also think about trying to write some buffer overflow exploits:

http://www.phrack.org/phrack/56/p56-0x0f

The shell code given here won't work. At least, I can't think of any earthly reason why it should. It's specifically for overflowing an SGI Irix system, which runs a variant of Unix - nothing like what the PSP runs.

Grover · Post by **Grover** » Sun May 08, 2005 6:19 pm

Just my 2 cents: Id agree with PsPet. Cracking / Using something from CodeWarrior or Snsystems should be a big no-no. At the moment, it is fair to say, that there has been no real 'cracking' at all - simply an explot/hole that the original V1.0 PSP's have that allow people to execute ELF's.

By using actual developer based gear for this, taints the whole thing, and could easily bring the wrath of Sony, and basically make this board disappear in a poof of smoke. Remeber that ISP's are the ones that would be called on to remove the content or litigation will ensue.

Imho, if anything even vaguely from the developer system is posted / shown here.. then watch out.. because that could be bad for the board.. If (like PsPet says) mods are happy to go down this line, then beware the consequences - boards have disappeared for alot less.

th0mas · Post by **th0mas** » Mon May 09, 2005 6:15 am

ModernRonin wrote: http://www.phrack.org/phrack/56/p56-0x0f

The shell code given here won't work. At least, I can't think of any earthly reason why it should. It's specifically for overflowing an SGI Irix system, which runs a variant of Unix - nothing like what the PSP runs.

buffer overflows are definitely what might open up a v1.5, especially combined with what we'll learn from analyzing the workings of a v1.0. The shellcode linked will definitely not work since it's most likely going to attempt call the Irix equivalent of exec() and run a new shell (hence, "shellcode"). We want something more akin to initializing the system and loading a new ELF (or the exploit itself dumping the firmware, something along those lines).

ModernRonin · Post by **ModernRonin** » Mon May 09, 2005 1:58 pm

buffer overflows are definitely what might open up a v1.5, especially combined with what we'll learn from analyzing the workings of a v1.0. The shellcode linked will definitely not work since it's most likely going to attempt call the Irix equivalent of exec() and run a new shell (hence, "shellcode"). We want something more akin to initializing the system and loading a new ELF (or the exploit itself dumping the firmware, something along those lines).

We need two things:

1. We need to know how the PSP loads and runs a compiled ELF program. We need this to construct the buffer overflow code. I don't think we know this yet... but given what nem has posted here, I think we will find out sooner or later. It may just be jumping to an address in memory (like a library call), or maybe it'll be something using the MIPS syscall opcode. I would suggest that someone take a look inside a pirated dev kit and figure this out, but if I suggested that then the mods would delete my post, SO OF COURSE I WOULD NEVER SUGGEST THAT!

2. We need a program with a buffer to overflow. Optimally, this would be something in the PSP firmware already - the image viewer, the movie player, etc. Notice pdc's thread here. It looks like the PSP may have a buffer overflow problem when trying to load a PBP. If you design the .PNG icon inside a PBP just right, we may be able to do a buffer overflow and ka-ching!

There's a lot of work to do to make this a reality, though. Stack smashing attacks take a lot of trial and error to create. Once we have it though... it'll just be a matter of copying a single PBP file to your PSP's memory card and running it. Boom - p0wned!

In fact, if we do the buffer overflow right, we can make it so that the fact that the 1.5 firmware keeps everything encrypted won't matter. Because we wouldn't be asking the OS kernel to load (and decrypt) our program. We'd just smashing it straight into memory without the kernel even knowing about it. This is how the XBox Linux guys got Linux onto an XBox - they used a buffer overflow in the savegame load routines of MechAssault to overwrite memory with a specially made copy of the Linux boot loader and kernel.

But again, that's a long ways off. For the moment I'd just be happy with a bit of shellcode that loads and runs a small ELF file off the memory stick. That'd be plenty for homebrew dev. In theory it'd even be enough so that I can do what I ultimately want to do - put a decent web browser on my PSP.

Now if only I was smart enough to figure out either 1 or 2...

forums.ps2dev.org

How To Crash The PSP

String the binaries!

Branch delay slot, dude...

Re: Branch delay slot, dude...