Hi,
could anyone here tell me in what memory regions the VSH modules reside in? What memory range has to be dumped to get access to the decrypted VSH prx files?
Thanks in advance,
-mc
VSH memspace?
They are in user memory and gone when a game is run. Here's a simple program to decrypt and dump prx's from the flash.
Code: Select all
#include <psptypes.h>
#include <pspkernel.h>
typedef struct pInfo {
int size;
int unk[9];
void *init_func;
void *unk1;
void *load_addr;
int unk2;
int unk3;
int unk4;
short unk5;
char unk6;
char unk7;
char name[27];
char unk8;
} pInfo_t;
int sceKernelQueryModuleInfo(int modid, pInfo_t info);
PSP_MODULE_INFO("dump_module", 0x1000, 1, 1);
PSP_MAIN_THREAD_ATTR(0);
int main(int param1, int param2)
{
int fd, uid;
pInfo_t info;
info.size = sizeof(pInfo_t);
uid = sceKernelLoadModule("flash0:/kd/mebooter_umdvideo.prx", 0, 0);
if(uid > 0)
{
sceKernelQueryModuleInfo(uid, info);
fd = sceIoOpen("ms0:/mem", PSP_O_CREAT | PSP_O_TRUNC | PSP_O_WRONLY, 0777);
sceIoWrite(fd, info.load_addr, 0x60000);
sceIoClose(fd);
}
sceKernelExitGame();
return 0;
}
Note that the code above does not work for decrypting/dumping VSH PRXs that are already loaded in memory. However, it's fairly easy to achieve that as well, if you know the name of the module you want to dump (which you can find from Vampire's list for instance).
The code below is not very elegant (it goes through a complete UID range to find the requested module), but it will dump system PRX's that are not accessible from the code above.
In example below, we dump the hpremote.prx (sceHP_Remote_Driver):
It is also likely that the uncompressed/unecrypted size of the module can be retrieved from the pInfo struct (we dump a 0x60000 chunk of memory regarless of the module size), but I haven't looked into it yet.
The code below is not very elegant (it goes through a complete UID range to find the requested module), but it will dump system PRX's that are not accessible from the code above.
In example below, we dump the hpremote.prx (sceHP_Remote_Driver):
Code: Select all
for (uid = 1; uid <0x1000000; uid++)
{
if (!sceKernelQueryModuleInfo(uid, info))
{
printf("%08X: %s\n", uid, info.name);
if (!strcmp("sceHP_Remote_Driver", info.name))
{
printf("Module found - Dumping\n");
fd = sceIoOpen("ms0:/module.dump", PSP_O_CREAT | PSP_O_TRUNC | PSP_O_WRONLY, 0777);
sceIoWrite(fd, info.load_addr, 0x60000);
sceIoClose(fd);
break;
}
}
}I'm fairly sure the VSH modules, other then vsh_bridge, are wiped before a game is run.Note that the code above does not work for decrypting/dumping VSH PRXs that are already loaded in memory.
You could try sceSearchModuleByName, trouble is it's a kernel routine.The code below is not very elegant (it goes through a complete UID range to find the requested module), but it will dump system PRX's that are not accessible from the code above.
Probably, that was just quick and dirty though. I wrote it to dump the media engine bootstrap, but later found it was in the kdumper dump at address 0x88300000.It is also likely that the uncompressed/unecrypted size of the module can be retrieved from the pInfo struct (we dump a 0x60000 chunk of memory regarless of the module size), but I haven't looked into it yet.
Yeah, I'm not sure what really happens there. It would sound logical for apps to start with a clean environment and let them manage their modules.crazyc wrote:I'm fairly sure the VSH modules, other then vsh_bridge, are wiped before a game is run.
For some reason though, I was unable to load the PRXs I was interested in using this code, which I suspect boils down to sceKernelLoadModule() failing if the module is already in memory.
I would also think that sceKernelQueryModuleInfo() checks that the UID provided is valid, which, from what I could see (~90 modules being retreived with UIDs < 0x1000000) means that we still have a whole bunch of modules when a game starts. Or it could be that UIDs don't behave like file descriptors and stay "valid" even after the resource has been discarded. But then again, I found out that the UIDs for PRXs that are being successfully loaded through sceKernelLoadModule(), do change from one execution to another.
Yeah, I looked into module search functions for a while, but then I went the lazy way and decided to it was much simpler to just brute force the UIDs ;)You could try sceSearchModuleByName, trouble is it's a kernel routine.
Well, this quick and dirty code was great help to me! :)Probably, that was just quick and dirty though. I wrote it to dump the media engine bootstrap, but later found it was in the kdumper dump at address 0x88300000.
[lots of little topics]
re: loading
You should be able to load all the VSH user modules (IIRC there is one kernel module). Your app will start with a relatively clean slate (something like 60 core "KD" modules, none from VSH)
If having problems with "sceKernelLoadModule", you may not have the right attributes. To load from flash0: you need 0x1000 kernel memory access flag, and a kernel thread, ie:
> PSP_MODULE_INFO("dump_module", 0x1000, 1, 1);
> PSP_MAIN_THREAD_ATTR(0);
Semi-related - http://forums.ps2dev.org/viewtopic.php?p=16537 search for "LoadModule tips and tricks"
-----
re: query module info
The sceQueryModuleInfo API had problem for me under 1.0 (checking access bits, allowing nothing)
You can 'roll your own' module probe using "sceKernelModuleFromUID" (system entry). Also good for getting at lower level details (eg: for patching lazy import tables)
-----
re: Enumerating all the UIDs to find the modules
> for (uid = 1; uid <0x1000000; uid++)
FWIW: A little more elegant is
These are system entries too [use the jump to hard coded address trick with KMEM access]
=======
re: what to dump (the more interesting topic IMHO)
Taking a memory snapshot from a single load address is a rough approximation. That will save the important user memory region.
Another alternative is to load many modules into memory, then save the kernel *AND* user memory (ala kdumper). Then dump them both (depending on what dumping/disassembling tools you use). This gives you a system wide view of the program in memory. Also if you sceKernelStartModule the libraries, the memory you capture will be slightly different (ie. you are dumping the code and the data regions)
Lastly if you prefer to decode things more atomically, you can grab the .PRXs after they have come out of the decryption process and save them before they become un-gzipped and loaded/flattened into memory. This gives you a more generic view of the modules (ie. no specific load addresses, just like disassembling an unencrypted .PRX you find elsewhere).
-----
Bottom line: looks like everyone is using different disassembly tools. Adapt advice to what approach you use. The "VSH" modules have a treasure trove of information on how to use some of the more obscure parts of the system. Not that useful for normal "ForUser" API access.
Eg: figured out a ~20 line program to initiate the "USB Mode" (to memory stick storage). Not very useful otherwise...
re: loading
You should be able to load all the VSH user modules (IIRC there is one kernel module). Your app will start with a relatively clean slate (something like 60 core "KD" modules, none from VSH)
If having problems with "sceKernelLoadModule", you may not have the right attributes. To load from flash0: you need 0x1000 kernel memory access flag, and a kernel thread, ie:
> PSP_MODULE_INFO("dump_module", 0x1000, 1, 1);
> PSP_MAIN_THREAD_ATTR(0);
Semi-related - http://forums.ps2dev.org/viewtopic.php?p=16537 search for "LoadModule tips and tricks"
-----
re: query module info
The sceQueryModuleInfo API had problem for me under 1.0 (checking access bits, allowing nothing)
You can 'roll your own' module probe using "sceKernelModuleFromUID" (system entry). Also good for getting at lower level details (eg: for patching lazy import tables)
-----
re: Enumerating all the UIDs to find the modules
> for (uid = 1; uid <0x1000000; uid++)
FWIW: A little more elegant is
Code: Select all
u32 count = sceKernelModuleCount();
u32 uid_array[200];
err = sceKernelGetModuleList(200, uid_array);
for (i = 0; i < count; i++)
DoDumpModuleInfo(uid_array[i]); // or whatever
=======
re: what to dump (the more interesting topic IMHO)
Taking a memory snapshot from a single load address is a rough approximation. That will save the important user memory region.
Another alternative is to load many modules into memory, then save the kernel *AND* user memory (ala kdumper). Then dump them both (depending on what dumping/disassembling tools you use). This gives you a system wide view of the program in memory. Also if you sceKernelStartModule the libraries, the memory you capture will be slightly different (ie. you are dumping the code and the data regions)
Lastly if you prefer to decode things more atomically, you can grab the .PRXs after they have come out of the decryption process and save them before they become un-gzipped and loaded/flattened into memory. This gives you a more generic view of the modules (ie. no specific load addresses, just like disassembling an unencrypted .PRX you find elsewhere).
-----
Bottom line: looks like everyone is using different disassembly tools. Adapt advice to what approach you use. The "VSH" modules have a treasure trove of information on how to use some of the more obscure parts of the system. Not that useful for normal "ForUser" API access.
Eg: figured out a ~20 line program to initiate the "USB Mode" (to memory stick storage). Not very useful otherwise...
So do you have any experience how to hook into the system to grab the PRX's right after the decryption process? I found a call to the gunzip routine but no clue yet how to hook in right before there...Lastly if you prefer to decode things more atomically, you can grab the .PRXs after they have come out of the decryption process and save them before they become un-gzipped and loaded/flattened into memory. This gives you a more generic view of the modules (ie. no specific load addresses, just like disassembling an unencrypted .PRX you find elsewhere).
re: grabbing the PRX's right after the decryption process
Trying to be somewhat vague here (don't want to raise the ire of Mr Closer ;-)
Hint: An interesting validation check routine goes by the obvious name "sceKernelCheckExecFile" [[ thank goodness for SHA1 discovered names !!! ]]
If you save what comes out of that routine you may find it looks a lot like a gzip file. It should handle most of the VSH cases. There are other approaches too.
As mentioned the VSH modules use more obscure system interfaces (things you can't use in a regular "ForUser" game/app). Great if you like probing into the depths of the system. Not something to rely on for generic games/apps.
Trying to be somewhat vague here (don't want to raise the ire of Mr Closer ;-)
Hint: An interesting validation check routine goes by the obvious name "sceKernelCheckExecFile" [[ thank goodness for SHA1 discovered names !!! ]]
If you save what comes out of that routine you may find it looks a lot like a gzip file. It should handle most of the VSH cases. There are other approaches too.
As mentioned the VSH modules use more obscure system interfaces (things you can't use in a regular "ForUser" game/app). Great if you like probing into the depths of the system. Not something to rely on for generic games/apps.
Are you going to add that to the SDK? That would be quite useful for some purposes, such as uploading new version of a script without restarting if your app is using a scripting language, etc..PspPet wrote: Eg: figured out a ~20 line program to initiate the "USB Mode" (to memory stick storage). Not very useful otherwise...
> Are you going to add [the USB Mode sample] to the SDK? That would be quite useful for some purposes,
Sure. I have to SDK-ize a bunch of samples (including AiboRemote and WiFi picture frame). Hopefully later in the week.
[HelloWorld structured version of USB Mode available now - send email if interested]
True it is useful as a game addon. My disappointment was that it doesn't do more (I wanted USB hosting support - I guess we'll have to wait a while for the USB keyboard device)
mrbrown wrote:
> Ah, I don't have anything against decrypting PRXes
Cool, I'll add my lame decoder to the list of samples to SDK-ize. I suspect TyRaNiD's version is more general, but the simple approach will grab all the VSH user modules. Snapshotting the functionality of a running PSP, so I'm not decrypting anything explicitly.
Sure. I have to SDK-ize a bunch of samples (including AiboRemote and WiFi picture frame). Hopefully later in the week.
[HelloWorld structured version of USB Mode available now - send email if interested]
True it is useful as a game addon. My disappointment was that it doesn't do more (I wanted USB hosting support - I guess we'll have to wait a while for the USB keyboard device)
mrbrown wrote:
> Ah, I don't have anything against decrypting PRXes
Cool, I'll add my lame decoder to the list of samples to SDK-ize. I suspect TyRaNiD's version is more general, but the simple approach will grab all the VSH user modules. Snapshotting the functionality of a running PSP, so I'm not decrypting anything explicitly.
I tried to call sceKernelCheckPspConfig with the config.txt (loaded to a buffer ) passed as parameter - it gave me some "cant handle plain config..." errormessage... mind telling me how this method works? Does the decryption thing has to be initialized somehow? I'd love to chat about some details with you guys ;)
Anyways, i'll try the sceKernelChecExecFile approach... i wonder - is the decrypted file is a valid ELF (PRX)...?
Mind telling me the struct of the param block that has to be passed to this function? :))
Anyways, i'll try the sceKernelChecExecFile approach... i wonder - is the decrypted file is a valid ELF (PRX)...?
Mind telling me the struct of the param block that has to be passed to this function? :))
> i wonder - is the decrypted file is a valid ELF (PRX)...?
Gzip compressed too. Once uncompressed any PRX analysis tool should work (dumpers/disassemblers).
Notice the encrypted files are much smaller (eg: the encypted/compressed flash0 version of "pspnet.prx" is 27KB, while the equivalent uncompressed/unencrypted file you find on many game UMDs is 60KB)
Gzip compressed too. Once uncompressed any PRX analysis tool should work (dumpers/disassemblers).
Notice the encrypted files are much smaller (eg: the encypted/compressed flash0 version of "pspnet.prx" is 27KB, while the equivalent uncompressed/unencrypted file you find on many game UMDs is 60KB)