Howdy guys, I've been messing about trying to create a kernel debugger and memory patcher (think GDB/action replay for PSP) but I'm having some serious problems with sceIoOpen and sceIoRead -- I'm trying to open the executable from the UMD, but I'm getting an error every time.
Anyone have some working code for this? It's really starting to get aggrivating.
Thanks.
Also -- any data on the USB 2.0 or networking hardware yet? I need some way of dumping the data out of memory in real time for analysis and command & control over either TCP/IP or USB URBs.
UMD help needed
As written here, providing any information related to "activating" the UMD is currently against the forum rules.
In this thread Tyranid provides a program to dump the PSP's kernel. Right now this is your best bet for USB and networking info.
In this thread Tyranid provides a program to dump the PSP's kernel. Right now this is your best bet for USB and networking info.
Ahhhh. Well, that makes sense. And I suppose; is answer enough -- there's another function I'm missing.
Anyway, in the kernel dump, I happened acrost this...
FAT over USB Mass
-unit=
Usage: usbfat [<option>...]
<option>:
-unit=<U> # %d <= <U>
-node=<N> # %d <= <N>
-buf=<B> # %d <= <B>
This driver manages up to <U> drive(s) simultaneously.
(allocate %d bytes per unit. default: <U>=%d)
This driver manages up to <N> node(s) simultaneously.
(allocate %d bytes per node. default: <N>=%d)
The number of disk buffer entries is <B>.
(allocate %d bytes per entry. default: <B>=%d)
<U>,<N> and <B> must be specified by decimal.
SceLFatFs
USB Mass Storage drivers, eh?
And,
sceHP_Remote_Driver
module
sceLED_Service
SceUtils5120
SceUtils4096
photo_plugin_module
Kern
sceHP_Remote_Driver
sceLED_Service
module
sceMesgLed
"HP_Remote_Driver" and "LED_Service".... interesting. Infrared remote?
Anyway, in the kernel dump, I happened acrost this...
FAT over USB Mass
-unit=
Usage: usbfat [<option>...]
<option>:
-unit=<U> # %d <= <U>
-node=<N> # %d <= <N>
-buf=<B> # %d <= <B>
This driver manages up to <U> drive(s) simultaneously.
(allocate %d bytes per unit. default: <U>=%d)
This driver manages up to <N> node(s) simultaneously.
(allocate %d bytes per node. default: <N>=%d)
The number of disk buffer entries is <B>.
(allocate %d bytes per entry. default: <B>=%d)
<U>,<N> and <B> must be specified by decimal.
SceLFatFs
USB Mass Storage drivers, eh?
And,
sceHP_Remote_Driver
module
sceLED_Service
SceUtils5120
SceUtils4096
photo_plugin_module
Kern
sceHP_Remote_Driver
sceLED_Service
module
sceMesgLed
"HP_Remote_Driver" and "LED_Service".... interesting. Infrared remote?
Ahha! found it.
Thanks, mrbrown -- that tip about activating it paid off. Much appreciated.
I'm trying to get a project started here -- one that will make all jobs on the PSP much simpler.
A common kernel mode debug system that can monitor nearly anything's execution in real time and feed it back to the developer over (hopefully) USB 2.0 URBs and a custom XP driver and monitor, OR, a TCP/IP link over wireless (USB2.0 preferred for profiling and debugging due to the high volume of data being transferred.)
Something like this will allow us to monitor the execution of any program and what function calls it attempts to use on the fly -- thus allowing us to watch what goes on between a game saving to the memory card -- and the encryption key used for such. Due to compatibility reasons, saves have to be encrypted with a key all PSPs have -- including the 1.5s and 1.51s. This approach also allows us to locate a potential buffer overflow in the save code of an arbitrary peice of software -- IE the X-box Mechassult/007 Agent Under Fire savegame buffer overflow exploits.
Somehow I doubt Sony would bother changing the savegame encryption in newer firmwares, as that would piss off the bulk of PSP owners who now could not load any of their previous saves.
It's quite obvious that the PSP's save system uses some kind of symetrical encryption that uses a single key to encrypt and decrypt, otherwise the saves wouldn't work on any other PSP. The fact that I happen to have a 100% mercury save I got off some site is proof of that.
Anyway, I think something like an in-kernel-memory debugger could very well work considering the kernel's 8MB memory allocation isn't full while running other software, and this would most defintely help with debugging of homebrewn software -- it's quite possible a program such as this could even do full system profiling just like the SDK's battery simulator and emulator are capible of (Which I'm making an assumption that it is from the SN systems webpages I've perused through) and allow profiling of homebrewn software for scaled back processor speeds to save battery life. I've already taken a look at the kernel memory dumper's code and I'm working on some code that might possibly be the beginnings, but since I'm a rank amature I'm sure it's riddled with bugs and f--kups and horrible coding style.
Thanks, mrbrown -- that tip about activating it paid off. Much appreciated.
I'm trying to get a project started here -- one that will make all jobs on the PSP much simpler.
A common kernel mode debug system that can monitor nearly anything's execution in real time and feed it back to the developer over (hopefully) USB 2.0 URBs and a custom XP driver and monitor, OR, a TCP/IP link over wireless (USB2.0 preferred for profiling and debugging due to the high volume of data being transferred.)
Something like this will allow us to monitor the execution of any program and what function calls it attempts to use on the fly -- thus allowing us to watch what goes on between a game saving to the memory card -- and the encryption key used for such. Due to compatibility reasons, saves have to be encrypted with a key all PSPs have -- including the 1.5s and 1.51s. This approach also allows us to locate a potential buffer overflow in the save code of an arbitrary peice of software -- IE the X-box Mechassult/007 Agent Under Fire savegame buffer overflow exploits.
Somehow I doubt Sony would bother changing the savegame encryption in newer firmwares, as that would piss off the bulk of PSP owners who now could not load any of their previous saves.
It's quite obvious that the PSP's save system uses some kind of symetrical encryption that uses a single key to encrypt and decrypt, otherwise the saves wouldn't work on any other PSP. The fact that I happen to have a 100% mercury save I got off some site is proof of that.
Anyway, I think something like an in-kernel-memory debugger could very well work considering the kernel's 8MB memory allocation isn't full while running other software, and this would most defintely help with debugging of homebrewn software -- it's quite possible a program such as this could even do full system profiling just like the SDK's battery simulator and emulator are capible of (Which I'm making an assumption that it is from the SN systems webpages I've perused through) and allow profiling of homebrewn software for scaled back processor speeds to save battery life. I've already taken a look at the kernel memory dumper's code and I'm working on some code that might possibly be the beginnings, but since I'm a rank amature I'm sure it's riddled with bugs and f--kups and horrible coding style.