Emulators For 2.00
Posted: Fri Sep 16, 2005 9:34 amwe need emulator for 2.0, who else need emulators for 2.0, lets do something like find someone who can make homebrew for 2.0 that would be a 
Page 1 of 1
Posted: Fri Sep 16, 2005 9:34 amPosted: Fri Sep 16, 2005 10:36 amPosted: Fri Sep 16, 2005 2:13 pmLOL!
Homebrew on 2.0 Coming soon!...
Posted: Tue Sep 27, 2005 11:18 amjust saw this article wich states that Homebrew will soon be on 2.0 machines!!
Got an email from Xskorpion last night:
toc2rta free development network have done it again - one step closer to full homebrew on the 2.0!
I was just sent this binary from toc2rta.
Pure binary loader.
* it's loaded at 0×08810000
* it's max 64 kB
* it's pure binary MIPS code
* you have to use syscalls and not NIDs
* it runs in user space!
* it's called h.bin (Hello world) in the root of the MemoryStick
Set the frame_buffer.png as background like before and Place the new overflow.tif in the photos dir and the h.bin on the memory stick. It loads ms0:/h.bin
Screw the downgrader. This is how it all started with 1.5 hello world.
Finally has happened. Next steps? Well, for right now only MIPS machine code seems to be working, but there's nothing stopping someone from makeing a homebrew loader in assembler...
While it is correct that unsigned code is now running on 2.00 PSPs. However the code is running in USER mode not KERNEL mode.
For those who don't know what this means, code that runs in kernel mode (i.e. the PSP OS/firmware) is protected by the PSP hardware (CPU). Code running in user mode (games, apps) cannot access memory used by the kernel.
This means that at the moment, unsigned code can only access things that games/apps can access, such as the screen output, sound output and button/d-pad input. Unsigned code can only be run in the area of memory exploited by the buffer overflow (64Kb). In order to allocate enough RAM to run proper homebrew (e.g. emulators) kernel access is required. Only kernel code can allocate memory to user processes (homebrew). This is where we are at the moment. In order to get a fully exploited system, the kernel needs to be attacked. Then the PSP will be under total control of the homebrew code.
There are different layers of protection between user mode and kernel mode. Think of it as an onion where kernel mode is the core and user mode is the outer layer. As you remove the layers and move up privilige levels, you get closer to the kernel. You can make system calls in user mode which instruct the kernel to do various things but these calls are always controlled by the kernel and are not easy to exploit. By using system calls, it is possible to increase your privilige level and get closer to the kernel (peeling the layers from the onion). This will however take time and a lot more hardcore hacking to achieve
http://www.psphacks.net/content/view/376/2/
Got an email from Xskorpion last night:
toc2rta free development network have done it again - one step closer to full homebrew on the 2.0!
I was just sent this binary from toc2rta.
Pure binary loader.
* it's loaded at 0×08810000
* it's max 64 kB
* it's pure binary MIPS code
* you have to use syscalls and not NIDs
* it runs in user space!
* it's called h.bin (Hello world) in the root of the MemoryStick
Set the frame_buffer.png as background like before and Place the new overflow.tif in the photos dir and the h.bin on the memory stick. It loads ms0:/h.bin
Screw the downgrader. This is how it all started with 1.5 hello world.
Finally has happened. Next steps? Well, for right now only MIPS machine code seems to be working, but there's nothing stopping someone from makeing a homebrew loader in assembler...
While it is correct that unsigned code is now running on 2.00 PSPs. However the code is running in USER mode not KERNEL mode.
For those who don't know what this means, code that runs in kernel mode (i.e. the PSP OS/firmware) is protected by the PSP hardware (CPU). Code running in user mode (games, apps) cannot access memory used by the kernel.
This means that at the moment, unsigned code can only access things that games/apps can access, such as the screen output, sound output and button/d-pad input. Unsigned code can only be run in the area of memory exploited by the buffer overflow (64Kb). In order to allocate enough RAM to run proper homebrew (e.g. emulators) kernel access is required. Only kernel code can allocate memory to user processes (homebrew). This is where we are at the moment. In order to get a fully exploited system, the kernel needs to be attacked. Then the PSP will be under total control of the homebrew code.
There are different layers of protection between user mode and kernel mode. Think of it as an onion where kernel mode is the core and user mode is the outer layer. As you remove the layers and move up privilige levels, you get closer to the kernel. You can make system calls in user mode which instruct the kernel to do various things but these calls are always controlled by the kernel and are not easy to exploit. By using system calls, it is possible to increase your privilige level and get closer to the kernel (peeling the layers from the onion). This will however take time and a lot more hardcore hacking to achieve
http://www.psphacks.net/content/view/376/2/