Great News!!
Great News!!
For the people who dont know, Firmware V. 2.0 has been exploited!
Someone even managed to compile a "hello world" program and run it on V.2.0! This is great for the homebrew community and i hope that every one contributes. I just thought i should let you guys know so we can start CODING!!! because i sure have, kudos to all.
Check out the full story at: http://www.psp-hacks.com/
Someone even managed to compile a "hello world" program and run it on V.2.0! This is great for the homebrew community and i hope that every one contributes. I just thought i should let you guys know so we can start CODING!!! because i sure have, kudos to all.
Check out the full story at: http://www.psp-hacks.com/
-
- Posts: 41
- Joined: Sat Jul 02, 2005 10:12 am
-
- Posts: 197
- Joined: Fri Jul 01, 2005 2:50 am
At the moment, making a game using this exploit isn't very viable for two reasons:
A. Source file has to be 64Kb in binary format.
B. It runs in the memory dedicated to background placement, so the drawing space has the PSP icons drawn over it.
Really, the place to go from here is to work out how to get the exploit to run an unsigned EBOOT with full RAM access.
A. Source file has to be 64Kb in binary format.
B. It runs in the memory dedicated to background placement, so the drawing space has the PSP icons drawn over it.
Really, the place to go from here is to work out how to get the exploit to run an unsigned EBOOT with full RAM access.
What I find ironic is that after all the hoo-hah early on about the 'jpeg exploit' never going to work, that in the end this is what shoehorned unsigned code into 2.0.
Yes, I realise that it is a different kind of jpeg exploit (bufer overflow), but it's still pretty humorous.
As for geting it into kernel mode, I wonder if a variant of the %sign exploit could be used. I'm not sure if the user level code can read other portions of memory, but if it can (I'm guessing it might, as (IIRC) games run in user mode and can read/write to saves) then you might be able to escalate though code layers by hopping from one exploit to another, possibly going in a circle by re-writing the 64k sector until you have the required authorisation to run an unsigned program directly.
::EDIT: Though it's highly likely that I'm just talking out of my rear end.
Yes, I realise that it is a different kind of jpeg exploit (bufer overflow), but it's still pretty humorous.
As for geting it into kernel mode, I wonder if a variant of the %sign exploit could be used. I'm not sure if the user level code can read other portions of memory, but if it can (I'm guessing it might, as (IIRC) games run in user mode and can read/write to saves) then you might be able to escalate though code layers by hopping from one exploit to another, possibly going in a circle by re-writing the 64k sector until you have the required authorisation to run an unsigned program directly.
::EDIT: Though it's highly likely that I'm just talking out of my rear end.
It works. Like described in the readme, first you have to copy the frame_buffer.png in ms0:/psp/photo, then display it and set it as background image, then copy the overflow.tif to ms0:/psp/photo and the h.bin to ms0:/h.bin and go again to the photo menu. The h.bin is executed when it tries to preview the overflow.tif.
I've tried this code for h.bin, which inverts the vram content:
If you don't want to compile it yourself, you can create the h.bin with this line (write all in one line) :
Edited: I forgot to mention that my test code is relocatable. Would be nice to find an exploit, which works with one file, only.
I've tried this code for h.bin, which inverts the vram content:
Code: Select all
start:
li $a0, 0x04000000
li $v1, 0x100000
loop:
lbu $v0, 0($a0)
xori $v0, 0xff
sb $v0, 0($a0)
addiu $a0, 1
subu $v1, 1
bnez $v1, loop
nop
beq $0, $v1, start
nop
Code: Select all
echo -e "begin-base64 644 h.bin\nAAQEPBAAAzwAAIKQ/wBCOAAAgqABAIQk//9jJPr/YBQAAAAA9v8DEAAAAAA=\n====" | uudecode
I believe thats not possible with this overflow.Shine wrote:...Would be nice to find an exploit, which works with one file, only.
When the data with the code gets loaded from the tiff file it is copied to the overflow buffer (with memcpy or sth), so it's still in data-cache. Thats why you can't run it directly, so the code in the background image (in vram) is "called" first, and that code flushes the cache and calls the code from the tiff-file.
EDIT: sorry double post. could have edited the other one :(
infj
It would be better to figure out how to recycle the NIDs from vshmain and other modules that are already loaded. There is *no* simple path into kernel mode from user mode on any PSP, including 1.0 and 1.5.digihoe wrote:This is in no way a final 2.0 hack, there is alot that has to be sorted out. First on the list is getting from usermode into kernelmode...
All a loader needs to do is disable interrupts (to prevent thread switching), collect a bunch of NIDs, wipe the VSH from memory, and do all of the ELF loading, relocatation, and NID resolving itself.
On that note, 1.0/1.5 homebrew needs to stop relying on kernel mode too much. I think we kind of knew there would come a time where it wasn't available. It is futile to attempt to break into kernel mode from vsh or user mode. The plus side of this exploit is that you are in vsh mode, so you have a few more priveledges than if you were in user mode. You still might not be able to load plaintext PRXs using sceKernelLoadModule().
But we'll see...
> It is futile to attempt to break into kernel mode from vsh or user mode.
Relying on kernel mode is a necessary evil. But if a hole can be found, it will be much much easier that simply living with user/vsh mode limitations. It would make the 2.0 homebrew possibilities much more like the existing 1.0/1.50 homebrew.
Also many system services can not be run purely in user mode (at least with our current Homebrew setup). eg: loading additional PRX files like the WiFi system support [the rules may be different under vsh mode 2.0]. Time will tell...
Relying on kernel mode is a necessary evil. But if a hole can be found, it will be much much easier that simply living with user/vsh mode limitations. It would make the 2.0 homebrew possibilities much more like the existing 1.0/1.50 homebrew.
Also many system services can not be run purely in user mode (at least with our current Homebrew setup). eg: loading additional PRX files like the WiFi system support [the rules may be different under vsh mode 2.0]. Time will tell...
It is possible, someone released on the toc2rta site a tif, which works without any other files. You can paste your code to 0x1c0 and it will be executed, when the image is viewed.Saotome wrote:I believe thats not possible with this overflow.
I've added my code to it. Save this as overflow.uuencode:
Code: Select all
begin-base64 700 overflow.tif.gz
H4sICMAeN0MAA292ZXJmbG93LnRpZgDtzTEKwkAQheFZN0oshCiKoJYpxBNY
pAh2uUXAC6S0FPEAHsGjWHoIz2Fh4TpZV0mrnfJ/MLOPZXa2KBZylt/XEzFW
jKZYyzRyS3OVi2z1wob7ujoht7T6JnrPDxozo5Ct1jjMnLQmpu1zpW0a8kbb
rPF23tgvfnfs90sZBl7ns30ov9y7PkRRlojNRHYHJ6ulnkcj+9S5dXpz5bAe
uTqbfPEFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4Uw/tb5HncEIAAA==
====
yea actually it was jonny2002 on this forum:Shine wrote:It is possible, someone released on the toc2rta site a tif, which works without any other files.
http://forums.qj.net/showthread.php?p=174102#post174070
I was working with him together on this (I'm sousuke on that forum), i finaly gave up and thought it isn't possible, but he managed to finish it anyway :).
here's our hello world (single tiff-file, doesn't need the ugly background anymore ;))
http://rapidshare.de/files/5535707/psp01.tif.html
mirror (direct link)
infj