First cut at PSP buffer overflow loader code.

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Post Reply
ModernRonin
Posts: 10
Joined: Sat May 07, 2005 5:19 pm
Location: Colorado
Contact:

First cut at PSP buffer overflow loader code.

Post by ModernRonin »

We need three things to run code on the 1.5 PSPs via buffer overflows:

1) We need to find a buffer overflow, and
2) figure out how to exploit it.

I think the best candidate so far is this thread.
(I think. Anyone else know of anything that looks like an obvious buffer overrun?)

Some resources on buffer overflows:

http://www.phrack.org/show.php?p=49&a=14 - Stack smashing/buffer over runs in general
http://www.phrack.org/phrack/56/p56-0x0f - MIPS shellcode construction

3) We need MIPS assembly code that will load something and run it.

I cannot supply #1 or #2. It will take a lot more intelligence, experience and time than I presently have. (The fact that I don't currently own a PSP doesn't help things either.)

But I've been looking for ways to construct #3, and I think I can do it. nem's post in this thread
contains the memory addresses of two functions that can allow us to load code: sceIoOpen and sceIoRead. These are both C style functions, and more importantly, both of them take four arguments or less. Which means that they can be called using only the normal MIPS call registers, no pushing stuff onto the stack. (Though that isn't too hard, I guess.)

I'm not sure if these are firmware routines or not. If they're not, they might not be in the same location in memory every time, which would shoot this all to hell. Also, these routines may need to be called via the MIPS syscall instruction instead of via jump. I hope nem can tell me if I'm doing the calling wrong.

So anyway, here is my first attempt at a program loader in MIPS assembly. NOTE: I have not tried to assemble this yet. If someone wants to try that and tell me the results, fine. I expect this still needs some tweaking. After it assembles, then I'll have to go back through it with a hex editor and make sure there are no zero bytes. This code must be made to avoid having any byte in it be equal to 0. And code with a 0 byte in it will generally not work as buffer overflow code, since the buffer overflowing will stop at a zero byte. (See Phrack article(s).)

The code is pretty simple. It just (tries to) load up the raw MIPS machine code from the file "PSP_GAME/HOMEBREW/HOMEBREW.MIPS" on the memory stick. It loads it into memory, and then transfers control to it. The code is intentionally crafted to avoid having any byte in it be equal to 0. And code with a 0 byte in it will generally not work as buffer overflow code, since the buffer overflowing will stop at a zero byte. This is why I'm using weird instructions like "addiu" instead of the usual "li". That turns into an "ori", which contains a zero byte.

This code alone is not enough. We also need some way to smash the stack on PSP 1.5, which is how we will insert and run this code. Once we can do that, we should have enough leverage to load an ELF file from the memory stick. Baby steps...

Code: Select all

main:     addiu $a0, $zero, filen		; 1st arg to open() - filename.
          slti $a1, $zero, -0xFFFF	; 2nd rg to open() - operation = 1 = reading.
          jal 0x109f50bc			; Call sceIoOpen().

          ; If we were smart, here we'd check $v0 (the return value from open()) to make
          ; sure it's not -1, which would indicate failure.
          ; But we're just going to assume that the open() worked and run with it.

          andi $a0, $v0, 0xFFFF	; First arg to read() - copy fd from $v0 to $a0.
          addiu $a1, $zero, 0x09FFF001 ; Second arg to read(), where to store read data.
          addiu $a2, $zero, 0xFFE ; Third arg to read(), how much to load. 4094 bytes.
          jal 0x6a638d83		; Call sceIoRead()

          ; Again, if we were smart, we'd check to see if $v0 contained the proper value.
          ; In this case, it should be 0x0EEE, which is the number of bytes read.
          ; But again, we're just gonna hope it all worked...

          j 0x09FFF001		; Jump to loaded code.

filen: .ascii "ms0:/PSP_GAME/HOMEBREW/HOMEBREW.MIPS"
nem says that Sony reserved 0x08800000 to 0x09ffffff as user memory. I wanted to load into the top of user memory to avoid as much as possible overwriting anything already loaded. Though, who knows what's really up there. Might be stack space for early parts of the program for all I know. The number of bytes loaded, 4094 or 0xFFE, was chosen because it was a 16 bit value that contained no zero bytes, and also did not cause the jump-to address (obtained by subtracting it from 0x9FFFFF) to contain any zero bytes. I could have used something larger I suppose. 0xFEFE would be the maximum value that results in no zero bytes in the jump-to address. But I thought that ~4kbytes was enough to make a second stage loader. If you really want this overflow code to be able to load files bigger than that, you can make the mods to the code yourself. They're simple.

The code is available as loader.s at the URL in my sig.

Tomorrow I'll try and assemble this and run it through the SPIM MIPS emulator. Right now, bedtime...
pdc
Posts: 107
Joined: Wed Mar 09, 2005 9:49 am
Location: Rainy Yorkshire, England
Contact:

Re: First cut at PSP buffer overflow loader code.

Post by pdc »

ModernRonin wrote: Anyone else know of anything that looks like an obvious buffer overrun?
I have a PMF file which I assume causes a buffer overrun or similar.

*This idea presumes the PMF/Media playback subsystem is a constant background process.

When the PMF video is played, playback stops suddenly.
Now the media playback subsystem is out of action and the PSP is unable to play any mp3/jpg/mp4/pmf files.

I can post the video if you are interested. Could be of interest also as games also use PMF files for their videos.

I will read/undestand your post fully when I am not trired and preparing for a job interview ;)
PSPimp
Posts: 13
Joined: Tue Apr 12, 2005 11:05 pm

Re: First cut at PSP buffer overflow loader code.

Post by PSPimp »

ModernRonin wrote: Tomorrow I'll try and assemble this and run it through the SPIM MIPS emulator. Right now, bedtime...
and tomorrow you might as well get a MIPS programming handbook and learn about delay slots and such funky stuff like not using hashes as jump addresses ...
blackdroid
Posts: 564
Joined: Sat Jan 17, 2004 10:22 am
Location: Sweden
Contact:

Post by blackdroid »

"We need mips assembly code that will load something and run it"

like wtf ? im itching for moving this topic to off-topic. buffer overflow exploits useful for running code ? well hello, duh thats like the abc, why the need to reiterate.

Go code instead of spending yet more time on speculation and blowing wind.

There are already elf loaders out there that you can use if you deem the one in psp unuseful.

All of that could have as easily been written in C, there is no special magic by writing straight MIPS, unless you do know what you are doing and need to outsmart the compiler.
Kung VU
KiWi
Posts: 13
Joined: Thu Mar 10, 2005 8:21 am

Re: First cut at PSP buffer overflow loader code.

Post by KiWi »

PSPimp wrote:
ModernRonin wrote: and tomorrow you might as well get a MIPS programming handbook and learn about delay slots and such funky stuff like not using hashes as jump addresses ...
Lol - 100 points for PSPimp :)
Regards,

KiWi

Germany's largest Console Community : www.gamefreax-forum.de
kry.sys
Posts: 82
Joined: Wed Mar 16, 2005 1:31 pm

Post by kry.sys »

you can have the greatest code in the world.. but where the hell are you going to point it.. in most cases.. getting a overflow to run your code requires more experience about the system than most software developers posess.. (myself included)..

Ive got some great code.. but.. where in the EF do I put it?

(pointer hex joke har har)
ModernRonin
Posts: 10
Joined: Sat May 07, 2005 5:19 pm
Location: Colorado
Contact:

Post by ModernRonin »

PSPimp wrote:and tomorrow you might as well get a MIPS programming handbook and learn about delay slots and such funky stuff like not using hashes as jump addresses ...
Yeah, I deserved that. Especially since I scolded someone for not putting a branch delay slot instruction in their code a couple days ago.

As for calling the functions, I specifically said that I didn't know if this was the right way, and asked for nem to give me a clue. Feel free to bash on me for admitting my ignorance up front but trying to do something useful anyway - I don't mind. It's sure more than I've seen you do...

Here's some better code (I'm not saying it works yet - nor have I had a chance to make sure it's free of null bytes):

Code: Select all

main:	addiu $a0, $zero, filen		; 1st arg to open() - filename.
        slti $a1, $zero, -0xFFFF	; 2nd rg to open() - operation = 1 = reading.
        jal 0x109f50bc			; Call sceIoOpen().
        andi $zero, $a0, 0xFFFF         ; Branch delay slot noop.

        ; If we were smart, here we'd check $v0 (the return value from open()) to make
        ; sure it's not -1, which would indicate failure.
        ; But we're just going to assume that the open() worked and run with it.

        andi $a0, $v0, 0xFFFF	; First arg to read() - copy fd from $v0 to $a0.
        addiu $a1, $zero, 0x09FFF001 ; Second arg to read(), where to store read data.
        addiu $a2, $zero, 0xFFE ; Third arg to read(), how much to load. 4094 bytes.
        jal 0x6a638d83		; Call sceIoRead()
        andi $zero, $a0, 0xFFFF ; Branch delay slot noop.

       ; Again, if we were smart, we'd check to see if $v0 contained the proper value.
        ; In this case, it should be 0x0EEE, which is the number of bytes read.
        ; But again, we're just gonna hope it all worked...

        j 0x09FFF001		; Jump to loaded code.
        andi $zero, $a0, 0xFFFF ; Branch delay slot noop.

filen: .ascii "ms0:/PSP_GAME/HOMEBREW/HOMEBREW.MIPS"
blackdroid wrote: like wtf ? im itching for moving this topic to off-topic. buffer overflow exploits useful for running code ? well hello, duh thats like the abc, why the need to reiterate.
Maybe not everyone knows. This is rather technical stuff, and not everyone here has a master's degree in computer science. Also, actually exploiting a buffer overflow is not easy. We need a place to share knowledge on how to do it. And I can use this thread to recruit people to help me do tests. The more of us we have running code that may work, the better a chance that we'll actually find something that works.

In any event, I once again say that what I'm doing here may be ABC, it's still a hell of a lot more than I'm seeing you do.
blackdroid wrote:There are already elf loaders out there that you can use if you deem the one in psp unuseful.
Since it won't seem to load unencrypted code, I do deem it very much unuseful for homebrewers like me. I wouldn't have tried to reinvent the wheel if I thought there was a better way. But maybe you can tell me a better way since you know so much?

As a matter of fact, since you're so much smarter than me, why don't you post some buffer overflow code to load ELF files off the memory stick? It's easy, isn't it? You could do it in an hour, couldn't you?

While you're at it, why don't you assemble one of those other ELF loaders and then tell me if there are any null bytes in it?

Or did you forget, in all your infinite 37337 hax0r 0mG0mG skillZzZZz, that there can't be null bytes in buffer overflow exploit code?
blackdroid wrote:All of that could have as easily been written in C, there is no special magic by writing straight MIPS, unless you do know what you are doing and need to outsmart the compiler.
Why don't you go compile some C code, and then tell me if there are any null bytes in it.

Or does it eat up all your time and energy just to rip on the people who are actually trying to get homebrew stuff working on 1.5?

Fuckin' haters...
ModernRonin
Posts: 10
Joined: Sat May 07, 2005 5:19 pm
Location: Colorado
Contact:

Post by ModernRonin »

kry.sis wrote:you can have the greatest code in the world.. but where the hell are you going to point it.. in most cases.. getting a overflow to run your code requires more experience about the system than most software developers posess.. (myself included).
And me too. I said that in my post. Right there after 1 and 2, I said, "I don't know how to do this." (Well, I exaggerate a bit. I think I might be able to figure it out eventually. I'll keep trying, at least.)
kry.sis wrote:Ive got some great code.. but.. where in the EF do I put it? (pointer hex joke har har)
The easy answer to that is "in one of pdc's PMF files that makes the PSP crash." The better question is "where in the PMF file, and how." And that's what I don't know. But I'll keep looking for the answer. I need to make several PMF files with different variations of the loader code in them until I can get one to work. It'll take a huge amount of trial and error. But it's the only way I see to do this.

Other people are working on their stuff, and that's great - they're probably smarter than me and will probably get it working sooner. That's fine with me. I just do this because I personally want to put a web browser on my PSP and I don't want to wait for Sony to make one. Cuz A) it'll probably be expensive and B) it'll probably suck and only allow you to visit certain Sony-approved sites.
th0mas
Posts: 43
Joined: Sun Apr 24, 2005 1:59 am
Location: Canada
Contact:

Post by th0mas »

ModernRonin wrote: Here's some better code (I'm not saying it works yet - nor have I had a chance to make sure it's free of null bytes):

...
While you're at it, why don't you assemble one of those other ELF loaders and then tell me if there are any null bytes in it?

...
Or did you forget, in all your infinite 37337 hax0r 0mG0mG skillZzZZz, that there can't be null bytes in buffer overflow exploit code?

...
Why don't you go compile some C code, and then tell me if there are any null bytes in it.

excuse me if I'm wrong, but.. null bytes only matter if we attempt to overflow a string buffer, because the strcpy will stop at the null byte. Most other forms of data allow for null bytes since they're moved around using memcpy (and somewhere else, oft in the header, is an int corresponding to "size of payload").

Most of the (albeit completely unproven to be real) buffer overflows people have "discovered" in the games have been in chunks of data, not strings. So null bytes really have no effect on the success of the buffer overflow.
kry.sys
Posts: 82
Joined: Wed Mar 16, 2005 1:31 pm

Post by kry.sys »

ModernRonin wrote:
kry.sis wrote:you can have the greatest code in the world.. but where the hell are you going to point it.. in most cases.. getting a overflow to run your code requires more experience about the system than most software developers posess.. (myself included).
And me too. I said that in my post. Right there after 1 and 2, I said, "I don't know how to do this." (Well, I exaggerate a bit. I think I might be able to figure it out eventually. I'll keep trying, at least.)
kry.sis wrote:Ive got some great code.. but.. where in the EF do I put it? (pointer hex joke har har)
The easy answer to that is "in one of pdc's PMF files that makes the PSP crash." The better question is "where in the PMF file, and how." And that's what I don't know. But I'll keep looking for the answer. I need to make several PMF files with different variations of the loader code in them until I can get one to work. It'll take a huge amount of trial and error. But it's the only way I see to do this.

Other people are working on their stuff, and that's great - they're probably smarter than me and will probably get it working sooner. That's fine with me. I just do this because I personally want to put a web browser on my PSP and I don't want to wait for Sony to make one. Cuz A) it'll probably be expensive and B) it'll probably suck and only allow you to visit certain Sony-approved sites.
ahh.. by where i mean where in the psp's memory do you start putting code once you overrun your initial memory allocation.. it called a pointer.. different os'es have difrent specifications.. and untill i know where certain things sit in memory i cant put my own code in memory or run any other code. I think nem has a memory map but im not sure if thats released... some things are static.. others arent.

i mean this in the nicest possible way.

get an old version of redhat. get some old overflow sploits from milw0rm and read some overflow tutorials for linux... when you overflow your first (old) system and actually understand whats involved it may shed some light onto the complexity of finding this info out without sony's or sony dev's help... if it makes you feel any better, a lot of overflows are found out of pure luck.. then you use simple code on a target to find where to put /run info in memry and have at it. keep in mind these other systems are well documented, unlike the psp.
blackdroid
Posts: 564
Joined: Sat Jan 17, 2004 10:22 am
Location: Sweden
Contact:

Post by blackdroid »

ModernRonin wrote: While you're at it, why don't you assemble one of those other ELF loaders and then tell me if there are any null bytes in it?

Or did you forget, in all your infinite 37337 hax0r 0mG0mG skillZzZZz, that there can't be null bytes in buffer overflow exploit code?
blackdroid wrote:All of that could have as easily been written in C, there is no special magic by writing straight MIPS, unless you do know what you are doing and need to outsmart the compiler.
Why don't you go compile some C code, and then tell me if there are any null bytes in it.

Or does it eat up all your time and energy just to rip on the people who are actually trying to get homebrew stuff working on 1.5?

Fuckin' haters...
There alot of ways to do code injection apart from string.h functions, and im quite sure sony has gone away from using unchecked length strings.

And yes infact it does take a great deal to moderate the forums, cause there are way too many talkers and less doers, you may or may not think I do anything, that doesnt bother me the least. but please keep the board clear from smokescreens, people who wants to indulge in buffer overflow exploits should do so by reading up on whats in the rom, or by trial and error ( some seem to enjoy that sport ), and when they find something interesting they can opt to share that.

Now hate is a strong word, if I was to resort to that feeling I guess this thread would not live on.
Kung VU
kry.sys
Posts: 82
Joined: Wed Mar 16, 2005 1:31 pm

Post by kry.sys »

blackdroid wrote:and im quite sure sony has gone away from using unchecked length strings.
I agree,

i have yet to see anything that looks like a null terminated string without bounds... but then.. i didnt really look THAT hard.

in any case... I hope to GOD that people do not rely on overflows to run code in the future. The physical hardware has the capability to run anything you tell it. the AES crypoto is somehting like a function.. like say... a video card. its software controlled like a video card. if i need shtuff cryped.. i send it to the onboard chip. find a way around that (again :P). if theres an overflow.. then you rely on it, its just gonna get patched and then we are stuck where we are now. if it doesnt get patched then yay... but hope to god people dont put nasty code out there for you. once you make a system easy to code for (using overflows at that) then you all you have is an unpatched windows 95 box with no firewall in the palm of your hands.

/end of security rant
isthar
Posts: 4
Joined: Thu Sep 15, 2005 2:14 am

Post by isthar »

Is a thread like this worth reviving in light of information now available, such as http://www.psphacks.net/forums/viewtopic.php?t=5750 ?
mrbrown
Site Admin
Posts: 1537
Joined: Sat Jan 17, 2004 11:24 am

Post by mrbrown »

No, because we no longer discuss exploits and buffer overflows on this site.

See http://forums.ps2dev.org/viewtopic.php?t=2837.
isthar
Posts: 4
Joined: Thu Sep 15, 2005 2:14 am

Post by isthar »

wow really? what a pity. im a programmer myself, hacker at heart; exploring system innards is a hobby for all of us, and finding faults is but one of the things we love to do. I went and read the info there -- pity finding vulnerabiliies in the psp's code was thrown out.

Does this mean, in a sense, that psp developers here are only targetting 1.0 and 1.50 users? If sony has newer firmwares that remove the ability to load unsigned code (thus showing their intent to not have unsigned code run), wouldn't that imply everyone here is doing something against sony's will, perhaps against their lawyers as well?

IOW, every bit of psp dev't IS illegal because to run it, it must run on a platform that the owner has put laws in effect for you not to run anything BUT their code?
PspPet
Posts: 210
Joined: Wed Mar 30, 2005 2:13 am
Contact:

Post by PspPet »

> exploring system innards is a hobby for all of us, and finding faults is but one of the things we love to do
Go ahead, look for an exploit. If you want to talk about possible buffer overflows, check the psphacks.net forums (not here). IMHO: about 95% is childish newbie or blatantly fraudulent claims, so look for the <5% useful content.

If and when you have something that works, expect it to appear here. If necessary, the PSPSDK can support it too [like kexploit]. That applies to all the (currently bogus and fraudulent) claims on "downgraders".
To repeat: it is interesting here only *AFTER* something real and reproducable is released.
Please, no speculation or exploit strategies or faked demo videos here.
----
> Does this mean, in a sense, that psp developers here are only targetting 1.0 and 1.50 users?
Yes, those are the only "homebrew capable PSPs". That may change in the future. In the mean time you can do a lot with 1.0/1.50

> wouldn't that imply everyone here is doing something against sony's will
True, against their desires. Gaming console makers generally don't want to open up to homebrew. In the PSP case, they have frequent firmware updates to close the holes (unlike the NDS)

> IOW, every bit of psp dev't IS illegal because...
Not true.
See the legal rules for reverse engineering and exceptions in such laws like the "DMCA".
Sony may not like homebrew happening and do what they can to close the holes. BUT as long as homebrew developers don't pirate content (ie. share copyrighted material), reverse engineer for unfair uses, publish confidential information or break copy protection -- you are generally safe and legal.
The PSPSDK and PSPTOOLCHAIN and most all-open-source homebrew apps fall in that legal category ("loader"-like apps that work in conjunction with pirated content are not)
Post Reply