playing a bit of catch-up...

[bpoint]

I finally got ahold of my PSP today after a rather long wait, and am in love with it already. :) After playing a few of the games, I set out to find how well the homebrew scene has been progressing.

It's been ages since I reversed any kind of hardware (anyone remember Project Unreality? :) ), so I'm sure I am a bit rusty. But I'm ready and willing to help out any way I can... I'd love to get a polygon drawn so I can port my 3D engine to PSP. :D

Anyway, I read through most of the posts on this forum, and after a few more net searches, I've been able to come up with this:

- Getting the PSP to run any kind of external code only seems to be possible through 3 methods: a PBP file on a memory stick, hijacking the "Game Sharing" WLAN stream, or attempting a buffer exploit by creating an invalid MPEG video stream that overflows the 76800 byte encoded frame size.

- We don't have _any_ real image data from Sony, except from a leaked alpha/beta flash upgrade which hoses the PSP when flashed -- but it could be a fake. However, it does actually run something (displays images and scrollable text), so maybe it is real.

I'm guessing the PBP file is the best bet we have right now. I noticed that a few of you have started hacking it apart, checking for compression and/or encryption. But one thing that I didn't notice is that no one seemed to be scanning for code. We know the PSP is MIPS R4k based, so there should be lots of 4-byte opcodes that look like MIPS opcodes...

...of course, if I had the ROM flash upgrade, I could check. I guess finding it is my first step. :)

I think I've pretty much gotten caught up in the PSP scene. If there's anything important I seem to have missed, let me know! Of course, if I make any progress with anything, I'll be more than happy to post information or source to whatever tools I might make in the process.

Off to go hacking! :)

[Guest]

Hey great summary! Welcome to PSP dev hacking, always glad to have more people.

Yeah, you covered everything pretty well, except one thing: stuff's encrypted! What does a MIPS R4k opcode look like under AES anway ? :)

Sony gave us a bit more of a challenge on this one...but the more help the merrier! ;)

[Agntneo]

Yes I do remember Project Unreality.
I remember my dad saying that N64 emulation wouldn't be possible etc.
Look at it now:D

And yes, your 3 theories are somewhat possible.

There could be several exploitable areas on the psp within the memory card feature.

1. Some sort of buffer overflow using the MPEG-4 playback
2. Audio exploit of some kind. Kinda similar to the xbox's softmode's.
3. Save hack of some kind, as people use on the gamecube.

People should start snoopin' around more and be posting info as they get it.
I just ordered my psp from lik-sang yesterday so things will be interesting.

[pushpin]

I am a noob here but here's my question. I had heard that PS2 dev has just only started to get any real traction. If that is true (and correct me if that is wrong), then doesn't that mean even if code is able to be run on the PSP, that it could be eons before anything useful can be done with it?

How many of the licensed developers are writing directly to HW? It doesn't seem like the PSP is as easy to do that with as is the case with GBA and DS, but again, correct me if I'm wrong.

I am very anxious to dust off my copy of See MIPS Run, but I also don't want to get excited over nothing.

Maybe someone here will have some realistic and positive view on this that will cheer my spirits? :)

[Guest]

Maybe someone here will have some realistic and positive view on this that will cheer my spirits? :)

My feeling here is that most serious homebrew PS2Dev'ers have their plate too full with assorted personal PS2 related projects to worry all that much about when they might ever be able to do PSP dev. Not that they aren't interested mind you, but just that I don't think they are worried about keeping their minds occupied with interesting things to do, including occasional hacking at the PSP.

Does that help ?

[bpoint]

I am a noob here but here's my question. I had heard that PS2 dev has just only started to get any real traction. If that is true (and correct me if that is wrong), then doesn't that mean even if code is able to be run on the PSP, that it could be eons before anything useful can be done with it?

A quick search on pouet.net shows that the earliest PS2 demo was back in October 2001. That's only a year and a half after the release date in Japan, and most likely homebrew was doing simpler stuff before that.

If the PSP is similar to the PS2 at all, then my guess is that the developers could be writing code which accesses the hardware directly (building GIF packets, etc), but might be using a Sony-provided library to make that easier. I haven't seen the PSP devkit, so your guess is as good as mine. :)

Once we figure out how to get the PSP to run some code we've created, we then have to get ahold of some exisiting code that does stuff and disassemble it and see what the heck it does.

So yeah, it'll probably take a while... but you could always dust off that "See MIPS Run" book earlier than later, and help out. :D

[Oobles]

Assuming that you guys do manage to crack open the PSP for homebrew code then I think the lead time to have good tools available will be a lot less than for the PS2. It has taken a number of years for ps2sdk to mature and the various homebrew libraries to also appear. But there is now a very good selection of ps2 tools and libraries.

Given that the architecture of the PSP is similar and is also mips based, then I think you will see *a lot* of code re-use from the ps2 tools and libraries. I invisage an oopo-psp-toolscript, a pspsdk, and other psp* libraries. It will take time, but I doubt ti will take the time it has for ps2.

My 2c.. and I'll be joining in when PSPs arrive in Australia. Still no launch date either. :(

Oobles.

[Saotome]

...so there should be lots of 4-byte opcodes that look like MIPS opcodes...

...What does a MIPS R4k opcode look like under AES anway ? :)

i've just written a program to check that. i didnt doubt that its encrypted but hoped that some little chunks might be unencrypted.
so i hacked together this little program. here's the elf-file (of course it runs on PS2 ;) )
and some screenshots: pic0,pic1,pic2,pic3,pic4,pic5.

i've only checked the update-image file, maybe there are other psp files which could contain mips code, but i dont have a PSP yet so i cant try.


now its time to code something for the eyetoy driver... ;)

[ooPo]

Hey, that's kinda fun. Pictures make things neater than they would normally appear. :)

[M2]

... what do you actually want to do if you can gain access to the device?

You want to be able to simulate UMD games or movies? Or something else altogether?

I know you can easily simulate the UMD movie title experience by actually copying the data which would appear on the UMD image to a memory stick. However, the PSP will only recgonize the first .RCO file on the disk...

Additionally.. there are capabilities to create Flash-esque games using the language for the PSP... something to consider too. (downloadable games to a MS?)

[Guest]

... what do you actually want to do if you can gain access to the device?

As a regular forum monkey here, let me welcome you to PS2DEV (and PSPDEV). The site for homebrew embedded systems development for Sony game consoles! People want to write and run anything on these boxes, especially homebrew graphics demos and games. All done legally and cleanly of course (none of the *wink* *wink* dissembling about legalities seen at other sites... always trying to keep things clean here).

But of course, you did know that, right ? :)

[M2]

But of course, you did know that, right ? :)

... yea, I knew the general basics, but I was more interested in what type of access. I've been working on building some very basic scripted menuing systems, which could potential run as jpg viewer of sorts (think slideshow)... but, I'm using tools which most don't have access to.

I was just curious what other people were trying to do, specifically, not just the general idea of the forums :)

And, yea, I've been a mild lurker... and it's all clean here.

[Guest]

Well, people here are looking to create and use tools that everyone can use and have available. Tools that few can use are frowned upon, because they are typically illegal to have outside of license restrictions and NDA, which themselves typically limit application towards homebrew. Other folx here that are, or eventually became, licensed developers often found their ability to contribute more limited, walking a fine line.

[M2]

... cool. Nice to know.

I'm mostly held behind NDA, but, there is a recent grey area... ...and, I'm removed from the more technical aspects, but, I do enjoy reading and trying out stuff as an end user... and it might be useful for me to see what homebrew users are doing compared to licensees.

[Masterson]

... but, I'm using tools which most don't have access to.

what might these "tools" consist of?

[M2]

UMD image creation tools... from start to finish. Including documentation on how to script the PSML.

[blackdroid]

And in what way would those "tools" be of interest anyway, we still need a way to run code, porting gcc will be a minor detail. tools like ps2link etc aswel.

[mrbrown]

And in what way would those "tools" be of interest anyway, we still need a way to run code, porting gcc will be a minor detail. tools like ps2link etc aswel.

Er, it seems M2 is talking about a high-level scripting language used for UMD movies. He also implies that you could copy one of these scripts to the MS and run it via the browser. So basically he's saying there's a way to do high-level homebrew on the PSP.

M2 could you elaborate a bit on what PSML is and what a RCO file is? IIRC, Sony is supposed to be licensing (or opening) the UMD movie spec at some point - is this part of that?

[konfig]

I don't know what is the normal means to detect instruction code in a meaningless binary data file. But when I read the MIPS R4000 Microprocessor User's Manual, I had some idea(maybe naive).

The MIPS R4000 instructions are 32-bit long and all begin with a 6-bit opcode. The value of the 6-bit opcode segment can range from 0 to 63.
But as the manual says, not all these values can imply a valid MIPS R4000 instruction. Some values(19, 28~31, 51, 59) are not used, So if a 32-bit data which begins with one of these values is found in the data file, It must not be an R4000 instruction. And also, other data near this one is usually not instructions.

Some additional restricts also can be used to help detecting instruction code('When some instruciton uses COP0, the immediate value should not be zero' etc).

It still can't be confirmed Whether or not the firmware upgrade file has its R4000 instruction data encrypted(Even if it is encrypted, I hope the above can be useful), So I think a simple test can be performed. I'll write a program later to search the psp file to see If something interesting can be found.

From the hacking of pbp file, seems PSP upgrade file uses little-endian data format. And normally, the instruction in the data file should be 32-bit word aligned.

[konfig]

Test is over. Nothing useful as expected -_-

There are 92608 32-bit words that begin with these values in the UNKNOWN.PSP file. Their distribution in the file is highly uniform.


number of segment without these words ------ segment length

0 ------ 384byte
6 ------ 320
45 ------ 256
341 ------ 192
2082 ------ 128

The file length is 3,387,376 bytes


code:

#include <stdio.h>
#include <stdlib.h>

typedef unsigned char BYTE;

int list[] = {19, 28, 29, 30, 31, 51, 59};

int main(int argc, char* argv[])
{
int threshold;
int i, counti, countj;
FILE* image;
size_t iosign;
long offset, lastpos;
BYTE buffer[4];

threshold = atoi(argv[2]);

image = fopen(argv[1], "rb");
if (image == NULL)
{
printf("error opening the file\n");
return (0);
}


lastpos = 0;
counti = 0;
countj = 0;
while (!feof(image))
{
iosign = fread(buffer, 1, 4, image);
if (iosign == 4)
{
buffer[3] >>= 2;
for (i=0; i<7; i++)
{
if (buffer[3] == list) break;
}
if (i<7)
{
counti++;
offset = ftell(image);
if (offset - lastpos > threshold)
{
printf("%d(%X--%X)\n", offset-lastpos, lastpos, offset);
countj++;
}
lastpos = offset + 4;
}
}
else
{
offset = ftell(image);
if (!feof(image))
{
printf("error reading the file at : %X\n", offset);
fclose(image);
return (0);
}
}
}
fclose(image);
if (offset - lastpos > threshold)
{
printf("%d(%X--%X)\n", offset-lastpos, lastpos, offset);
countj++;
}
printf("noninstruction word(s) found : %d\n", counti);
printf("acceptable segment(s) found : %d\n", countj);
return (0);
}

[florinsasu]

You can stop searching for instructions. The content of the executable file (btw: its externsion is .prx, not .psp) is compressed. You will not find anything like mips instructions.
There is a header of 128 bytes that contains plain info, but the rest of the file are elf segments scrambled.

[Saotome]

konfig: my program works a little different; it checks the register fields of possible mips instruction words. some registers are used more often in "standard" misc code than others (for example v0,v1,a0-a3,t0,sp,...).
the program reads the file in 1024-word blocks and shows each block as one column in the graph.

but it seems all/most psp files are encrypted/scrambled, so it will be a "little" harder than that to find any mips code ;)

[konfig]

There should be 96 instructions in a 384 bytes block. But as the result shows, an invalid 'instruction' appears at least every 96 'instructions'.

The file length is 3,387,376 bytes. 3387376/4 = 846884.75. There are 7 invalid values(out of 64 possible values) for the opcode and there are 92608 invalid 'instructions' in total.

92608/846884.75 = 0.10935
7/64 = 0.109375

Almost same.


So my view is, the psp file looks more like a compressed data file than a encrypted one(at least has been compressed, maybe encrypted as well). The PSP value pack contains a 32MB memory stick. Guess that size of upgrade file and downloadable game data will all be limited to fit this 32MB ms. It's necessary to compress these files.


Finally, maybe upgrading itself is not performed by MIPS instruction code. To achieve the goal of upgrading, PSP can also use:

1) some high level script language(text form or binary form. as mrbrown said) to perform upgrade, MIPS code as data.
2) some 'SONY standard' data file(like the WIN32 standard 'HLP' file), also MIPS code as data.


Oh, maybe I think too much... Please forget it.

[konfig]

konfig: my program works a little different; it checks the register fields of possible mips instruction words. some registers are used more often in "standard" misc code than others (for example v0,v1,a0-a3,t0,sp,...).
the program reads the file in 1024-word blocks and shows each block as one column in the graph.

but it seems all/most psp files are encrypted/scrambled, so it will be a "little" harder than that to find any mips code ;)

Thanks. Now I see why your code detects possibility. It really is a better way to detect instruction code in most cases.

I know little about hacking, so I have to stop here waiting for good news.