How To Crash The PSP

[qubitz]

Has anyone tried assembling a simple program and using it as data.psp? In our effort to port Linux to the PSP (sf.net/projects/psplinux), we've been looking for ways to get code running on the PSP and one of our experiments yeilded an interesting result. We assembled a simple code, such as this:

Code: Select all

main:
    j    main

We assembled this file with as and used it as data.psp in eboot.pbp, and when we tried to launch it, the PSP would shut off.

What's interesting is that when we run the output from as through ld then the PSP won't shut off, rather it reports that the game could not be loaded.

This seems to indicate that the PSP is trying to execute our file, even though it is not encrypted. I had hoped that someone here might have some ideas as to what is going on here.

[annerajb]

if you could guide us on how did you did that it will be great .

[pixel]

Or maybe it got "decrypted", which led to invalid instructions, shutting off the psp...

[ChaosKnight]

Interesting. I'm looking at the header of the PSP critically now. It may be possible to run an unencrypted file, so something like this would be helpful. Can anyone post some kind of assembly loop code in hex? Something like

label0: jmp label0

Would be good, just enough to get it to hang.

[pixel]

Awww, come on... be a bit serious. You guys have no idea about what you're doing, are you ?

We assembled this file with as and[...]What's interesting is that when we run the output from as through ld then[...]

First of all, get some lectures about ELF files goddammit! What's a relocatable ELF, what's a executable ELF, and most of all, what in the hell does as and ld do!


What you're doing is just throwing random bytes into the file, nothing more. Period. So you can't assume that the PSP ran the "j main" in any way! You can just assume that you got a specific file which specifically was decrypted in a certain way leading to a very random combination of bytes which incidentally shut off the PSP. This is indeed interesting. NOT because you managed to send specific instructions to the PSP, but because the FILE you created got some quirks into the PSP system. This is not due to the code dudes. This is just randomness.


My, my, my......


Ah, and, ChaosKnight, FYI, the "j" can't get right if going thru AS only. "jump" is absolute, and a .o is relative. So, the address is relocated when linking (thru LD that is), and meanwhile, the address is 0 inside the .o file produced by as.



Oookay, this MAY be a goddammit of a coincidence that "j 0" got the PSP to shut off. But I still say that this was pure random. Just try other tests:

nop
nop
nop
nop
j 0

move $a0, $a0
move $a0, $a0
move $a0, $a0
move $a0, $a0
j 0


If ALL of them lead to PSP to shut down, okay, then, try:

j 0x8000

If this ALSO lead to PSP to shut down, this then is pure random due to the ELF headers structure.

[qubitz]

I never claimed that it was executing my code. I know about ELF files, as and ld. Sorry I didn't get too technical in my post. I just figured that anyone who might be able to help me would know what I was talking. I'll make sure to sound more technical, to establish more credibility with you, mmkay pixel?

I knew that something strange was going on causing the PSP to shut off, and I knew that it wasn't executing the code. But I did know that the PSP was shutting off when the file wasn't linked, which meant to me that it was treating it differently. Sure, it could have been random garbage that came out when the PSP tried to decrypt it, but of all the tests I've done, all the code I tried, it always came out the same way when it wasn't linked. So I doubt that the changes from the linker caused it to decrypt differently and not crash.

I thought that this information was important enough to share. So if you don't want to scare people from sharing new information, maybe you would refrain from flaming them as soon as they do so.

[qubitz]

Also, it's not the j 0 that causes the crash. I've run other tests that did not contain that command that came up with the same results.

[ChaosKnight]

Pixel, are you sure it's an ELF? If they are using a loader (most OSes do) it's very likely doing a few things using the header first.

Seems like there are three offsets from what MelGibson/oopo have put together which I can only assume are .bss, .text, .data, in whatever order. So maybe ELF wrapped in something else?

Here's a brief based on what I saw MelGibson put together (he used long, i use int) of what the suspected header is:
char[4] = "~PSP"
int = 0x00080000 (version?)
short = 0x0101 (?)
char[28] = Text
short = 0x0102 (?)
int = File Size - 336
int = File Size
int x 3 = Offsets?
short x 2 = 0x40 (64)
int x 2 = 0x00000000
int = 1067008
int x 2 = 0
int = 1067008
int = 2553296
int x 8 = 0
int = 12
int x 12 = Encrypted Data? MD5 Checksum?
int = File Size - 336
int = 0x80 (128) Encryption?
int x 6 = 0x00000000

But you seem to know a lot pixel, maybe you can hack together some kind of test, that's what I'll be doing. Also I was asking for hex codes (as in hand-built assembly) but I'll do that myself after studying up on this processor and its instruction set and related subjects for hand-building assembled instructions.

[Neil Stevens]

Uh, what makes ELF binaries incompatible with a "loader?" How do you think ELF-formatted code gets into memory? Osmosis?

[ChaosKnight]

Neil - The ELF is likely wrapped in the PSP file and not a "plain-vanilla" ELF. The PSP file seems to have offsets to support ELF sections.

[pixel]

Okay, now, you sound more reasonable. Beause all in your first post lead to "it's running our code!". Look at ChaosKnight reply: he's actually thinking the code was run.


Now, for me, it's REALLY doubtful that the PSP run ELF files bare, or that would be a real, big, ugly, mistake from SONY.


SO, to get back on track: yes, you got a file that can get the psp to shut down. Okay, now, I suggest you take this file, and change some bytes in it, in order to get what EXACTLY is getting the PSP to shut down. Because I guess the normal elf headers won't really be useful, especially since you're having a .o file here.

[ChaosKnight]

Look at ChaosKnight reply: he's actually thinking the code was run.

Actually I was agreeing with you, Pixel. I do not thiink the code was run. I think that Sony embedded the ELF inside the PSP file, rendering a flat ELF useless until it's been "packaged" by Sony.

Aside from that I did some heavy header modification in a hex editor to try and make the PSP run some NOPs. I won't list all tha changes I made, but among them are re-assigning the suspected offsets to valid locations in a much smaller file (352 bytes), changing the suspected file lengths and offsets to be reasonable with the smaller file, and changing the suspected 128-bit encryption int to 0.

In two tests I ran, one with the suspected MD5 in place, and one having it zeroed out, they both returned the same error, which I have to admit is new to me.

Error: 80020148

No clue what this means, it could mean anything because of how much I changed. I'll continue with a slower change process and a more scientific log of what I'm attempting.

Oh well, I can't attach so I won't attach my PBPs, but if you'd like to look at what I did, just ask and I'll put it on my web server.

[qubitz]

Origionally I said:

This seems to indicate that the PSP is trying to execute our file, even though it is not encrypted.

I didn't think that it was actually running. It couldn't be running if it shut off.

Really what I was getting at is that there is the PSP is doing something with the ELF code, because it crashes with the code hasn't been linked.

[pixel]

I think it's just a coincidence: please try other tests.

[qubitz]

Well since I'm sure that its not the j 0 that does it, and I've assembled a variety of code samples and tried lots of things, and the only consistency that I have come up with is that when I don't link I get the crash, what other tests do you think I should try?

I'm looking for suggestions.

[pixel]

So, every time you don't link, you get the shut down, that's about it ?

[qubitz]

Yup.

[pixel]

Okay. There's only a small flag which differentiate a .o from a .elf file. You can try to tweak this flag to see what happens in the psp. Still, as "flag", I still think it's a coincidence that this byte just happen to do something special in the PSP.

If you look at any elf header (.o or linked .elf file), you should get the following magic:

Code: Select all

0x7F 'E' 'L' 'F'

Then, following, you have 3 bytes. First is "class", which should be 32 bits for both file types (0x01). Then it's "encoding", which should be little endian for both file types (again, 0x01). The third byte is the elf type, which follows this table:

Code: Select all

static char * elf_types[] = {
    "No file type",        // 0x00
    "Relocatable file",    // 0x01
    "Executable file",     // 0x02
    "Shared object file",  // 0x03
    "Core file",           // 0x04
};

So, it should be 0x01 for your .o file, and 0x02 for your .elf file. The rest of the header should be unreleavant.

Just try poking this byte.

[qubitz]

Thanks for that bit of info. I checked it out and the ELF type doesn't change. It was x01 after assembly, and remained x01 after linking. So it must be something else...

[qubitz]

Here's a sample. For some reason though, there are about FFF zero bytes in the linker output before the symbol table. I'm not sure why this would happen...

Anyways..here is the sample asm:

Code: Select all

.globl	main
main:
	j	main

Here's what the header of the .o

Code: Select all

7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 01 00 08 00 01 00 00 00 00 00 00 00 00 00 00 00 94 00 00 00 00 30 a2 10 34 00 00 00 00 00 28 00 0a 00 07 00 00 00 00 08 00 00 00 00 00 00 00 

After I link it here is the header:

Code: Select all

7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 02 00 08 00 01 00 00 00 18 00 90 08 34 00 00 00 98 10 00 00 00 30 a2 10 34 00 20 00 01 00 28 00 0a 00 07 00 01 00 00 00 18 10 00 00 18 00 90 08 18 00 90 08 28 00 00 00 28 00 00 00 07 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 

Any ideas what change could be causing the crash?

[pixel]

Okay. More details requested. What do you call "when I put it thru ld" ? because the second file is still a .o file.

[qubitz]

Code: Select all

ld -x elfmips.x -o freeze.elf freeze.o

I was just passing one object file through on the case I posted, but I've done it with multiple files as well.

[qubitz]

Ooops I meant to write -T and not -x.

[pixel]

Okay, sorry: I misread my code. The byte telling if an ELF file is a .o or a linked .elf is the 16th one. And, indeed, you can see that there's a 01 in the first file, and a 02 in the second one. My bad.

[qubitz]

Ah yes..I did notice that it changed from 01 to 02. So its linking correctly...

[lmx]

umm, lol. so you think it's running decrypted program code?

psp kernel bails as soon as it finds something awry with an encrypted elf. you are just getting executabe corrupt errors.

try again

[qubitz]

Not exactly. There's no way that these decryption errors only appear when a file has not been linked.

Think about it. A non-linked ELF: Crash the PSP. A Linked ELF: Loading error that doesn't crash the PSP.

The PSP is reading the ELF file regardless of encryption.

Try again.

[ChaosKnight]

Think about it. A non-linked ELF: Crash the PSP. A Linked ELF: Loading error that doesn't crash the PSP.

The PSP is reading the ELF file regardless of encryption.

It's reading a file. That file may be built in a way that causes the loader to have some sort of unhandled exception, which causes the reboot. I'd like to be as optimistic as the next guy, but in reality all we really know is that it's loading a file.

[pixel]

Test it: take a linked elf file, change that 02 into a 01, and run it. See what happens...

[qubitz]

I've never claimed that it's actually running the code, or that it even will. But I am claiming that the PSP does care that the file is not linked, which to me indicates that it's reading the ELF file.

However, I am doing more experiments and I will post back with my findings. I'd like it if anyone else tried to repeat my experiment and see what they get.