| View previous topic :: View next topic |
| Author |
Message |
sparda
Joined: 25 Sep 2005 Posts: 1 Location: LALA Land
|
Posted: Sun Sep 25, 2005 2:20 pm Post subject: 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/ |
|
| Back to top |
|
 |
cooleyandy
Joined: 02 Jul 2005 Posts: 41
|
Posted: Sun Sep 25, 2005 5:33 pm Post subject: |
|
|
| I am curious about certain things though. Have anyone tried out the hello world program yet? From what the author wrote, he mentioned of certain c features not working. Does anyone know what it is that doesn't work with the loader? Such as...can we get keys so we can at least make a game. |
|
| Back to top |
|
 |
AnonymousTipster
Joined: 01 Jul 2005 Posts: 197
|
Posted: Sun Sep 25, 2005 5:50 pm Post subject: |
|
|
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. |
|
| Back to top |
|
 |
am
Joined: 25 Sep 2005 Posts: 1
|
Posted: Sun Sep 25, 2005 6:23 pm Post subject: |
|
|
| The real problem is figuring out how to get into kernel mode. |
|
| Back to top |
|
 |
EdZ
Joined: 24 Apr 2005 Posts: 28
|
Posted: Sun Sep 25, 2005 7:35 pm Post subject: |
|
|
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. |
|
| Back to top |
|
 |
digihoe
Joined: 14 May 2005 Posts: 108
|
Posted: Sun Sep 25, 2005 8:41 pm Post subject: |
|
|
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...
Hope some of the brains on this board can help with this...
Best regards! |
|
| Back to top |
|
 |
Shine
Joined: 03 Dec 2004 Posts: 728 Location: Germany
|
Posted: Sun Sep 25, 2005 11:06 pm Post subject: |
|
|
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:
| Code: |
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
|
If you don't want to compile it yourself, you can create the h.bin with this line (write all in one line) :
| Code: |
echo -e "begin-base64 644 h.bin\nAAQEPBAAAzwAAIKQ/wBCOAAAgqABAIQk//9jJPr/YBQAAAAA9v8DEAAAAAA=\n====" | uudecode
|
Edited: I forgot to mention that my test code is relocatable. Would be nice to find an exploit, which works with one file, only. |
|
| Back to top |
|
 |
Saotome

Joined: 03 Apr 2004 Posts: 182
|
Posted: Mon Sep 26, 2005 1:08 am Post subject: |
|
|
here's my 4k demo tiff-file ;)
psp01.tif
(hello world with user memory (0x08800000) hex-viewer). _________________ infj |
|
| Back to top |
|
 |
Saotome

Joined: 03 Apr 2004 Posts: 182
|
Posted: Mon Sep 26, 2005 1:35 am Post subject: |
|
|
| Shine wrote: | | ...Would be nice to find an exploit, which works with one file, only. |
I believe thats not possible with this overflow.
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 |
|
| Back to top |
|
 |
stefan
Joined: 14 Nov 2004 Posts: 10
|
Posted: Mon Sep 26, 2005 2:09 am Post subject: |
|
|
| 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...
|
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.
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... |
|
| Back to top |
|
 |
PspPet
Joined: 30 Mar 2005 Posts: 210
|
Posted: Mon Sep 26, 2005 5:45 am Post subject: |
|
|
> 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... |
|
| Back to top |
|
 |
Shine
Joined: 03 Dec 2004 Posts: 728 Location: Germany
|
Posted: Mon Sep 26, 2005 8:14 am Post subject: |
|
|
| Saotome wrote: | | I believe thats not possible with this overflow. |
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.
I've added my code to it. Save this as overflow.uuencode:
| Code: |
begin-base64 700 overflow.tif.gz
H4sICMAeN0MAA292ZXJmbG93LnRpZgDtzTEKwkAQheFZN0oshCiKoJYpxBNY
pAh2uUXAC6S0FPEAHsGjWHoIz2Fh4TpZV0mrnfJ/MLOPZXa2KBZylt/XEzFW
jKZYyzRyS3OVi2z1wob7ujoht7T6JnrPDxozo5Ct1jjMnLQmpu1zpW0a8kbb
rPF23tgvfnfs90sZBl7ns30ov9y7PkRRlojNRHYHJ6ulnkcj+9S5dXpz5bAe
uTqbfPEFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4Uw/tb5HncEIAAA==
====
|
then create the overflow.tif with "uudecode overflow.uuencode -o - | gzip -d > overflow.tif", disable the old background image, copy overflow.tif to ms0:/psp/photo and go to the photo preview. It will be executed immediatly. |
|
| Back to top |
|
 |
Saotome

Joined: 03 Apr 2004 Posts: 182
|
|
| Back to top |
|
 |
|