PS3HEN PS3HEN - Official Release Thread (Homebrew Enabler for the PS3) v3.5.0 (4.93 support)

[LuanTeles]

it was probably already answered, but you could either instruct and use Cobra in a process hook, to do no mappaths, or just use the Cobra syscall (sth like map_path("your_path", NULL)

unsigned int get_cobraversion(void){
system_call_1(8, 0x7001);
return (unsigned int)p1;
}

the syscall definition is wrong. it takes 2 parameters, so it would look like this:

int get_cobraversion(uint16_t *version)
{
system_call_2(8, 0x7001, (uint64_t)(uint32_t)version);
return (int)p1;
}

thanks haxxxen but the compiler is giving me some errors now

int get_cobraversion(uint16_t *version)
{
lv2syscall2(8, 0x7001, (uint64_t)(uint32_t)version);
return (int)p1;
}

bool is_cobra(void){
int ver = get_cobraversion();
// Optional debug log
//#if DEBUG
//DPRINTF("syscall 8 get_version2: 0x%X",ver);
//#endif
return ver>0 && ver<=0xffff;
}

Errors:

c:/PS34KPROXINSTALL/source/syscalls.cpp: In function 'int get_cobraversion(uint16_t*)':
c:/PS34KPROXINSTALL/source/syscalls.cpp:40:2: error: cast from 'uint16_t*' to 'uint32_t' loses precision
c:/PS34KPROXINSTALL/source/syscalls.cpp: In function 'bool is_cobra()':
c:/PS34KPROXINSTALL/source/syscalls.cpp:46:37: error: too few arguments to function 'int get_cobraversion(uint16_t*)'
c:/PS34KPROXINSTALL/source/syscalls.cpp:38:5: note: declared here

 

[bguerville]

thanks haxxxen but the compiler is giving me some errors now

int get_cobraversion(uint16_t *version)
{
lv2syscall2(8, 0x7001, (uint64_t)(uint32_t)version);
return (int)p1;
}

bool is_cobra(void){
int ver = get_cobraversion();
// Optional debug log
//#if DEBUG
//DPRINTF("syscall 8 get_version2: 0x%X",ver);
//#endif
return ver>0 && ver<=0xffff;
}

Errors:

c:/PS34KPROXINSTALL/source/syscalls.cpp: In function 'int get_cobraversion(uint16_t*)':
c:/PS34KPROXINSTALL/source/syscalls.cpp:40:2: error: cast from 'uint16_t*' to 'uint32_t' loses precision
c:/PS34KPROXINSTALL/source/syscalls.cpp: In function 'bool is_cobra()':
c:/PS34KPROXINSTALL/source/syscalls.cpp:46:37: error: too few arguments to function 'int get_cobraversion(uint16_t*)'
c:/PS34KPROXINSTALL/source/syscalls.cpp:38:5: note: declared here

You forgot to pass an argument.
Try something like this rather...

int get_cobraversion(uint16_t *version)
{
if(version==0)
return 0x8001000D;
lv2syscall2(8, 0x7001, (uint64_t)version);
return (int)p1;
}
bool is_cobra(void){
uint16_t ver=0;
return get_cobraversion(&ver)==0 ? ver>0 ? true : false : false;
}

 

[haxxxen]

ok, let bg handle this further

 

[LuanTeles]

You forgot to pass an argument.
Try something like this rather...

int get_cobraversion(uint16_t *version)
{
if(version==0)
return 0x8001000D;
lv2syscall2(8, 0x7001, (uint64_t)version);
return (int)p1;
}
bool is_cobra(void){
uint16_t ver=0;
return get_cobraversion(&ver)==0 ? ver>0 ? true : false : false;
}

ok, let bg handle this further

Thanks guys it's working

I used chatGPT to help me formatting the cobra version and everything is as it should

else if (what == "payload_version")
{  
char buf[50];
uint16_t ver = 0;
get_cobraversion(&ver);
  
if (ver > 0)
{
int digit1 = (ver >> 8) & 0xF;
int digit2 = (ver >> 4) & 0xF;
sprintf(buf, " v%X.%X" , digit1, digit2);
result = (string)buf;
}
    else
{
result = "";
}
}

to get MAMBA version, it must be similar, right?, i haven't tested it yet

 

[LuanTeles]

@bguerville if you can, please, i need just something more to complete the installer

I just need now a way to unmap all mapped paths and a way to unmap just specific mapped paths

Thanks in advance

 

[bguerville]

@bguerville if you can, please, i need just something more to complete the installer

I just need now a way to unmap all mapped paths and a way to unmap just specific mapped paths

Thanks in advance

To remove specific mappings, just use the map path syscall to set the path redirection to NULL. The mapping will be removed UNLESS the mapping is flag protected.

To remove all mappings in one sweep with syscall 8 is more complicated at the moment for various reasons including legacy support and besides, some mappings can be protected from deletion by flag, it's the case for some HEN mappings iirc, stuff you don't want deleted in 99.99% of use cases.
It can be done quickly on mapping tables, making use of the MAP_PATHS syscall 8 subcode rather than the simple MAP_PATH.
Still, it would ONLY process the paths that were created through tables and not those single mappings that other apps or the payload could have put in place.

Of course, a new syscall 8 subcode could always be implemented to do this kinda job if it turned out to be pertinent, with the option to force deletions even on protected mappings.

 

[bguerville]

@LuanTeles

I should probably add at this stage that the entire remapping feature is flawed, because of the original design itself, implying now legacy issues with every change you try to make, but by concept too quite frankly, it might be necessary for a few things but it's a dodgy and costly hack, worse yet, it doesn't even work on all paths as you know which means it would need completed to handle all /dev_flash paths and the likes, which in turn means some more kernel research...

There's room for a few improvements, I told you before, this new implementation was ONLY a test originally, never meant for release.
The problem being that in order to make a real difference and turn that feature into something more robust (it would never be perfect by nature), we would lose legacy support eventually.

 

[aldostools]

In Cobra 8.4 & Mamba 8.4, sys_map_path(NULL, NULL); will remove all mapped paths, except the protected paths that start with././ (slash-dot-slash) in the new path.

int sys_map_path(const char *oldpath, const char *newpath)
{
char *paths[1] = { (char*)oldpath }, *new_paths[1] = { (char*)newpath };
system_call_4(8, 0x7964, (uint64_t)(uint32_t)paths, (uint64_t)(uint32_t)new_paths, 1);
return (int)p1;
}

NOTE: The protection is only against deletion. The protected paths can be redirected first to a non-protected paths, then you can remove them using sys_map_path(NULL, NULL); without adding a new opcode.

To know the mapped paths, the paths and the total number of mappings there is an opcode SYSCALL8_OPCODE_GET_MAP_PATH (0x7967)

 

[bguerville]

In Cobra 8.4 & Mamba 8.4, sys_map_path(NULL, NULL); will remove all mapped paths, except the protected paths that start with././ (slash-dot-slash) in the new path.

int sys_map_path(const char *oldpath, const char *newpath)
{
char *paths[1] = { (char*)oldpath }, *new_paths[1] = { (char*)newpath };
system_call_4(8, 0x7964, (uint64_t)(uint32_t)paths, (uint64_t)(uint32_t)new_paths, 1);
return (int)p1;
}

NOTE: The protection is only against deletion. The protected paths can be redirected first to a non-protected paths, then you can remove them using sys_map_path(NULL, NULL); without adding a new opcode.

To know the mapped paths, the paths and the total number of mappings there is an opcode SYSCALL8_OPCODE_GET_MAP_PATH (0x7967)

Hmm.. I see..
I dunno if I can adapt that system to the current HEN code very easily though, I would need to look, I think it would require a few changes..
Damn, I wish that code had never been released other than as a beta test.. I fear it's a mistake to lose more and more sync between Cobra and HEN..

 

[aldostools]

Hmm.. I see..
I dunno if I can adapt that system to the current HEN code very easily though, I would need to look, I think it would require a few changes..
Damn, I wish that code had never been released other than as a beta test.. I fear it's a mistake to lose more and more sync between Cobra and HEN..

The easiest solution would be to implement the same mappath.c of Cobra/Mamba.

Honestly I don't see a practical reason having it with a different behavior. Stability? Performace? More features? Easier to maintain?

 

[bguerville]

The easiest solution would be to implement the same mappath.c of Cobra/Mamba.

Honestly I don't see a practical reason having it with a different behavior. Stability? Performace? More features? Easier to maintain?

Well I wrote this test code originally because both LuanTeles and esc0 needed specific requirements, one for his apps and the other for some HEN mappings behaviour that the original code wouldn't let them do. For that I had to change the fixed array system into a dynamically allocated linked list and added an optional syscall flag argument to describe the mappings so they could potentially behave differently.

Also mappath.c was already different in HEN and Cobra before I made any changes, I wasn't the first to break sync.
Iirc sys_map_path(NULL,NULL); wasn't implemented like you described in HEN, otherwise I would have kept the behaviour.

Look at this 2.0 version in 2019, I think that's when mappath.c was added to HEN for the first time..
https://github.com/Joonie86/PS3HEN/blob/f7f7d1d1457975a28a34304508ba600f8123311f/stage2/mappath.c
Before that it looks like the mapping code was added to main.c, but the code is essentially the same.

 

[haxxxen]

imo, doing it in hooked process is much better, cause if you have mapped flash files with active Cobra, and doing system update, the mapped files (probably lying on /dev_hdd path) will get updated instead of the devflash files. so in this case for example, I have removed all mappings as soon as 'ps3swu.self' is called

edit
erm, screw it! this is only better for general mappings doing in payload directly

 

[aldostools]

Well I wrote this test code originally because both LuanTeles and esc0 needed specific requirements, one for his apps and the other for some HEN mappings behaviour that the original code wouldn't let them do. For that I had to change the fixed array system into a dynamically allocated linked list and added an optional flag system to describe the mappings so they could potentially behave differently.

Also mappath.c was already different in HEN and Cobra before I made any changes, I wasn't the first to break sync.
Iirc sys_map_path(NULL,NULL); wasn't implemented like you described in HEN, otherwise I would have kept the behaviour.

Look at this 2.0 version, I think that's when mappings were added to HEN for the first time..
https://github.com/Joonie86/PS3HEN/blob/f7f7d1d1457975a28a34304508ba600f8123311f/stage2/mappath.c

I'm only suggesting an easy solution for future releases.

Anyway sys_map_path(NULL,NULL); is already implemented in HEN
https://github.com/PS3Xploit/PS3HEN/blob/master/payload/mappath.c#L762-L795

This feature exists since the initial public release of Cobra USB & Cobra 7.0 for 4.46
https://github.com/Joonie86/CobraUSB/blob/master/USB/stage2/mappath.c#L151-L196
https://github.com/Joonie86/Cobra-7.00/blob/master/446/stage2/mappath.c#L150-L195

Indeed multiMAN and IRISMAN call it to clear all the mapped paths when they start. This is the main reason why we need the "protected" mapped paths. Otherwise, several features that rely on mapped paths get broken by these old apps.

 

[bguerville]

imo, doing it in hooked process is much better, cause if you have mapped flash files with active Cobra, and doing system update, the mapped files (probably lying on /dev_hdd path) will get updated instead of the devflash files. so in this case for example, I have removed all mappings as soon as 'ps3swu.self' is called

Yes, a mapping which is processed through the open_path hook could potentially backfire on you at system feature level, like I said the mapping hack is a dodgy concept in many ways.

 

[bguerville]

I'm only suggesting an easy solution for future releases.

Anyway sys_map_path(NULL,NULL); is already implemented in HEN
https://github.com/PS3Xploit/PS3HEN/blob/master/payload/mappath.c#L762-L795

I know this code snippet, it's mine.
sys_map_paths is the function dedicated for tables.
Notice the FLAG_TABLE flag, when deletion occurs, it deletes ONLY those mappings made with that flag, not the others so it won't delete all mappings.

LuanTeles could use sys_map_path for single mappings and provide the FLAG_TABLE flag as third argument, this way he could then call via syscall sys_map_paths(NULL,NULL) to delete them all in one sweep BUT that won't delete mappings made through sys_map_path by other apps or by HEN that don't have the FLAG_TABLE flag.
I didn't invent that table flag it was there before I began to help with this code, I kept the existing behaviour even though I don't really like it, AFAIK that part of the code is similar in Cobra 7.x..

As is, from the top of my head, the easiest (may not be the best though) way would probably be to add a new FLAG_ALL flag and allow the use of the single mapping function this way
sys_map_path(NULL, NULL,FLAG_ALL);
to signal an all mappings deletion, but then what about protected ones? Do they go as well?

 

[aldostools]

I know this code, it's mine.
sys_map_paths is the function dedicated for tables.
Notice the FLAG_TABLE flag, when deletion occurs, it deletes ONLY those mappings made with that flag, not the others so it won't delete all mappings.

LuanTeles could use sys_map_path for single mappings and provide the FLAG_TABLE flag as third argument, this way he could then call via syscall sys_map_paths(NULL,NULL) to delete them all in one sweep BUT that won't delete mappings made through sys_map_path by other apps or by HEN that don't have the FLAG_TABLE flag.
I didn't invent that table flag it was there before I began to help with this code, I kept the existing behaviour even though I don't like it.

That flag is used when a map path is created through sys_map_paths (opcode SYSCALL8_OPCODE_MAP_PATHS of syscall 8).
ret = map_path_user((char *)(u64)u_paths, (char *)(u64)u_new_paths, FLAG_TABLE);

In the case of webMAN MOD, it uses that function in syscall 8 for all map paths.

NOTE: The map paths created through syscall 35 use 0 for the flag. Therefore they aren't cleared by sys_map_paths(NULL,NULL).

 

[bguerville]

That flag is used when a map path is created through sys_map_paths (opcode SYSCALL8_OPCODE_MAP_PATHS of syscall 8).
ret = map_path_user((char *)(u64)u_paths, (char *)(u64)u_new_paths, FLAG_TABLE);

In the case of webMAN MOD, it uses that function in syscall 8 for all map paths.

NOTE: The map paths created through syscall 35 use 0 for the flag. Therefore they aren't cleared by sys_map_paths(NULL,NULL).

I understand that.
All I am saying to you that is that it doesn't delete all mappings, ONLY those created with the FLAG_TABLE flag, whether it is done via sys_map_paths automatically or via sys_map_path passing the flag as 3 argument as it's now possible in HEN.

LuanTeles was asking me for a way to delete ALL mappings, I assume he means both the ones his app might have added and also the ones other apps and HEN may have added. For now there's no way to do that fully in one sweep and there's no way to guess what exotic mapping any app might have made in the first place to seek to delete it..

 

[LuanTeles]

To be honest, I don't really need to clean all mapped paths.

On CFW, I use the webMAN mod to perform the mappings and i only map some XMLs that require webMAN functions. However, when I launch my uninstaller, if it attempts to restore any file that is currently mapped, it cannot proceed because it can't replace them. To resolve this issue, I'm using webMAN per-title script. So, when my uninstaller is launched, webMAN unmaps all the mapped paths.

The problem arises with HEN, as I'm doing the remapping directly in the payload because i'm mapping a lot of modded sprxs that is not releated to webman in anyway. If webMAN is enabled, the user can launch my uninstaller and uninstall the Pro mod. However, if the user disables webMAN for any reason, the webMAN script will not run and the uninstaller will fail due to the mapped files.

I asked about a method to clear all mapped paths just as a precaution, in case any mappings other than the ones I defined are active.

 

[LuanTeles]

I'm only suggesting an easy solution for future releases.

Anyway sys_map_path(NULL,NULL); is already implemented in HEN
https://github.com/PS3Xploit/PS3HEN/blob/master/payload/mappath.c#L762-L795

LuanTeles was asking me for a way to delete ALL mappings, I assume he means both the ones his app might have added and also the ones other apps and HEN may have added. For now there's no way to do that fully in one sweep and there's no way to guess what exotic mapping any app might have made in the first place to seek to delete it..

I followed Aldo's suggestion of using `sys_map_path(NULL, NULL)`, but no luck there. However, when I used `sys_map_path` to unmap specific paths, it did the job.

 

[bguerville]

I followed Aldo's suggestion of using `sys_map_path(NULL, NULL)`, but no luck there. However, when I used `sys_map_path` to unmap specific paths, it did the job.

You must use sys_,map_paths for that, not sys_,map_path.
If you do so, remember there are 3 arguments, `sys_map_paths(NULL, NULL,0);


FYI
Mappings must be added with the FLAG_TABLE flag in order to get deleted this way.
The flag is added automatically when creating mappings with sys_,map_paths, but you can also manually provide that flag as an argument with single mapping creation through sys_,map_path.

This method would delete in one sweep all mappings added with FLAG_TABLE, the ones you may have added as well as any other apps that used it like wMM.
It won't delete other mappings created without the FLAG_TABLE flag or protected with the FLAG_PROTECT flag.