PS3 PSNpatch - Releases / Usage Information (Official Support Thread)

[kokotonix]

Lol... pretty hard to achieve that people understand what i'm talking about.

4 sure i know that i can use PSNPatch combo... i'm not stupid ! (Ok ok... a little bit crazy may be)
If i need to use PSNPatch combo anyways then webMAN_mods [online]-tag is useless because PSNPatchs combo does the same job as the tag.
You should realy try youself that situation.

I believe we are looking into different scopes or contexts.
Probably looking into different sides of the same apple and seeing different colors - my side is red, while your side is yellow

We are clearly in a situation where a set of different tools have somehow overlapping functions.
We ought to choose which tool we prefer to each function we need.


My own personal choice is as follows:
1. Use webman to mount (and auto-mount) the images made from the original blurays.
2. Disable all other webman on-boot options and syscall disabling (that's why I prefer webman-mod light versions)
3. Use psnpatch to auto-lock psn access at boot;
4. Use psnpatch to disable syscalls at the psn login prompt;

 

[Rudi Rastelli]

My own personal choice is as follows:
1. Use webman to mount (and auto-mount) the images made from the original blurays.
2. Disable all other webman on-boot options and syscall disabling (that's why I prefer webman-mod light versions)
3. Use psnpatch to auto-lock psn access at boot;
4. Use psnpatch to disable syscalls at the psn login prompt;

That's exactly what i was doing 'til yesterday. So even if u see the red side of the apple and i see the yellow side we both bite at the same side

I've asked aldostools if it might be possible that webMAN_mod "sends" the combo (L3+R3+R2) so PSNPatch Plugin will be triggert to disable syscalls and un-block PSN.
Think of it like a "remote control" for PSNPatch-Plugin.

All i want is to stay with PSNPatchs approach, because i believe it's better(saver). I guess you are much deeper into that kind of disable-syscalls-thing in order to be as much stealth as possible.
But i must assume i don't have enough knowledge about these things to really decide with approach is the better one or that they are equivalent.
Fact is : Both tools are amazing homebrews from my point of view(the yellow side ) and i have the highest respect for each of the involved developers.

Regards
Rudi

 

[kapa]

webman and psnpatch are different projects, so i cant see the issue on press 3 buttons 1 time before go online... anyway, kokotonix is not responsible for another project code, maybe talking between devs, webman could disable psnpatch... but this is only my opinion.. only kokotonix / aldo can talk about this...

 

[Rudi Rastelli]

webman and psnpatch are different projects, so i cant see the issue on press 3 buttons 1 time before go online... anyway, kokotonix is not responsible for another project code, maybe talking between devs, webman could disable psnpatch... but this is only my opinion.. only kokotonix / aldo can talk about this...

I'm aware of that these are to different projects initially... but now it has happend that i've come across an intersection between these 2 projects which leads to a small problem. I just wanted to point that out.
The main concern in my own projects is to make things as easy as possible for the end user... god knows i'm far from being perfect doing so... but my hope is that i share this concern with other devs.
And as being an active member of the communitiy and not only a speechless consumer it's obvious 4 me to not :zipped:

And yes... kokotonix and aldo hopefully talk about this... indeed it's my firm believe that devs should talk to each other. 4 me that's the way to go.

Regards
Rudi

 

[kokotonix]

We'll think in something.
An approach may be psn patch auto disable syscalls at certain games mounting, but it will need some development.



Sent from nowhere Using Tapatalk

 

[Rudi Rastelli]

We'll think in something.
An approach may be psn patch auto disable syscalls at certain games mounting, but it will need some development.

1st off... Nice to see i could finally raise your awareness for this intersection/overlapping problem.

But... you might me for this:
1) Your suggested solution sounds like a workaround and i'll bet if you implement this a lot people will complain: "Hey... why are syscalls disabled for game XY and not for game YX ?". It'll generate a lot of support you don't really want !?
2) There's another intersection/overlapping problem regarding plugins : There is no elegant solution right now how to avoid double defined Pad-Combos. Currently any dev has to check out if a combo he would like to implement is already in use by another plugin.

As you can see there are already 2 intersection/overlapping problems i've come across and there might be others i'm not aware off or will come up in the future.


1st Idea
May be it's time for developing a "plugins communication protocoll" or global flags or...
Possibly this could also be a "control-plugin" where any plugin requests available(unused) combos or requests a another plugin to do a certain job or other things that might be needed in the future.
For example: webMAN requests PSNPatch-Plugin(if it's installed) via the "control-plugin" to disable syscalls.
I already had a little discussion about that idea with aldos. He repied that it's basically a good idea but the drawbacks from his point of view are:
- it will take up one of the available 6 slots for plugins
- devs have to re-build their plugins to work with this control plugin.
I basicly I agree to his arguments and I guess it's a matter of to decide between the benefits and the drawbacks... and... if there's any dev out there to develop such a thing with the risk that may be no one will use his control plugin.

2nd Idea
A more simple solution for especially the intersection/overlapping problem i might think of:
Let PSNPatch-Plugin regulary check if a special file exists.
For example: IF "dev_hdd0/tmp/PSNP_request_disable_syscalls" exists THEN disable syscalls AND delete the file afterwards to sign the requesting plugin that the job is done.

I guess the 1st idea might take a long time to develop(if ever)... but the 2nd idea could be short term implemented (at least i hope so)

But anyway... to make a long story short I would vote for:
Either a good general solution for intersection/overlapping problems should be found... or...
The minimal solution(see above)... or ...
Leave anything as it is and drop the idea of any kind of workarounds (may be just inform users about possible intersection problems in the readme)

And please... don't think i wanna tell you or anyone else what to do... these are just my thoughts and ideas... hope it might be helpful.

Regards
Rudi

 

[kokotonix]

I was preparing an answer but you bet me to the second.
Well, let-me rephrase it and quote you in the way:

1) Your suggested solution sounds like a workaround and i'll bet if you implement this a lot people will complain: "Hey... why are syscalls disabled for game XY and not for game YX ?". It'll generate a lot of support you don't really want !?

Yes. This was the main reason for the answer I was preparing. It is to complicated.
A lot of usage issues would arise.
And it wouldn't be safe. It would certainly have occur in some situation a user expecting to have syscalls disable without that being true and risking a ban,
I've gave up on this idea.

2) There's another intersection/overlapping problem regarding plugins : There is no elegant solution right now how to avoid double defined Pad-Combos. Currently any dev has to check out if a combo he would like to implement is already in use by another plugin.

As you can see there are already 2 intersection/overlapping problems i've come across and there might be others i'm not aware off or will come up in the future.

May be it's time for developing a "plugins communication protocoll" or global flags or...
Possibly this could also be a "control-plugin" where any plugin requests available(unused) combos or requests a another plugin to do a certain job... eg webMAN requests PSNPatch-Plugin(if it's installed) to disable syscalls.
I already had a little discussion about that idea with aldos. He repied that it's basically a good idea but the drawbacks from his point of view are : it will take up one of the available 6 slots for plugins and devs have to re-build their plugins to work with this control plugin. I basicly I agree to his arguments.
I guess it's a matter of to decide between the benefits and the drawbacks... and... if there's any dev out there to develop such a thing with the risk that may be no one will use his control plugin.

But anyway... to make a long story short I would vote for:
Either a good general solution for intersection/overlapping problems should be found... or...
As a minmal local solution: Allow PSNPatch-Plugin to recieve requests from other plugins... or ...
Leave anything as it is and drop the idea of any kind of workarounds (may be just inform users about possible intersection problems in the readme)

Imo is too complicated to implement and normalize between different plugins.
All this, would take a very big effort and we must accept that ps3 scene is already in the "way down" - to avoid saying it is dying, to justify such investment.


Note that psnpatch was one of the first solutions to use key combos, and before any overlappings.
It will be strange forusers to have key combos being changed.
In the beginning, KW adjusted with Deank in order to use the exact same combo for both psnpatch and webman. This is for being possible to disable syscalls and unload webman at the same time. All this with a unique combo key press - as it still stands for today.


All things considered, it seems to me that is is best to leave psnpatch as it is.
It is much user frindly and much technically cleaner to keep the shortcut to disable syscalls and enable psn access when the login is displayed.

I will keep tracing the scene evolution, and if some kind of different approach is explored I will gladly study it and join it.

 

[Rudi Rastelli]

[MENTION=124]kokotonix[/MENTION]
Thx for your reply... and i can follow you argumentation to the point. I assume the 1st Idea is to complicated and to much effort for a starving system

Did you checkout my 2nd idea i've added while you wrote ?

Let me explain it a bit more detailed:
1. PSNPatch-Plugin waits in background for it's Combo (L3+R3+R2) or for "PSNP_request_DisableSyscalls" to appear
2. Any other plugin creates "PSNP_request_DisableSyscalls" and waits for it to be deleted within a timeout. If it's not deleted within that timeout (because PSNPatch-Plugin is perhaps not installed or running) it does it's own job to disable syscalls.
3a. PSNPatch-Plugin deletes "PSNP_request_DisableSyscalls" right after it's been detected(in order to stay within the timeout) as a flag to the requesting plugin that i takes over the job and then disables syscalls and unlocks PSN
OR
3b. PSNPatch-Plugin renames "PSNP_request_DisableSyscalls" to "PSNP_request_Processing" -> Disables Syscalls -> Deletes "PSNP_request_Processing" (now the requesting plugin knows when the request is accepted and when it's done... slightly more advanced then 3a to avoid that the requesting plugin does some nasty things while PSNPatch-Plugin still isn't finished with it's job)

This way everything could stay as it is... just a little expansion which can be used by other plugins or even not.

Regards
Rudi

 

[kokotonix]

[MENTION=124]kokotonix[/MENTION]
Thx for your reply... and i can follow you argumentation to the point. I assume the 1st Idea is to complicated and to much effort for a starving system

Did you checkout my 2nd idea i've added while you wrote ?

Let me explain it a bit more detailed:
1. PSNPatch-Plugin waits in background for it's Combo (L3+R3+R2) or for "PSNP_request_DisableSyscalls" to appear
2. Any other plugin creates "PSNP_request_DisableSyscalls" and waits for it to be deleted within a timeout. If it's not deleted within that timeout (because PSNPatch-Plugin is perhaps not installed or running) it does it's own job to disable syscalls.
3a. PSNPatch-Plugin deletes "PSNP_request_DisableSyscalls" right after it's been detected(in order to stay within the timeout) as a flag to the requesting plugin that i takes over the job and then disables syscalls and unlocks PSN
OR
3b. PSNPatch-Plugin renames "PSNP_request_DisableSyscalls" to "PSNP_request_Processing" -> Disables Syscalls -> Deletes "PSNP_request_Processing" (now the requesting plugin knows when the request is accepted and when it's done... slightly more advanced then 3a to avoid that the requesting plugin does some nasty things while PSNPatch-Plugin still isn't finished with it's job)

This way everything could stay as it is... just a little expansion which can be used by other plugins or even not.

Regards
Rudi

That's more or less already implemented.
PSnpatch in cobra mode, creates a random syscall (for greater security must be random).
When this random syscall is called, it restores the syscall table and psnpatch unloads itself from memory.

In order to be possible for other apps to use this special syscall it would be need to change the syscall to a fixed place, but this would pose a security risk - easy detectable.

Another way would be to receive commands to and older/ "named pipe" strategy - but to do this only if interesting to other devs. This or any other proposed approach.
I would wait for dev comments on this in order to decide the best approach.

 

[Rudi Rastelli]

Just wanna add why i'm so persistent about this topic:
For me it's not a prob to use PSNPatchs combo before i go online.
But i think about families with kids playing online unattended. I think for these users it's best to have things as easy as possible.
And to just mount a game that starts automaticly and is also ready to play online with max possible security is simply perfect !
Furthermore with the [online]-tag parents could clearly mark the games they allow the kids to play online.

Regards
Rudi

 

[aldostools]

That's more or less already implemented.
PSnpatch in cobra mode, creates a random syscall (for greater security must be random).
When this random syscall is called, it restores the syscall table and psnpatch unloads itself from memory.

In order to be possible for other apps to use this special syscall it would be need to change the syscall to a fixed place, but this would pose a security risk - easy detectable.

Another way would be to receive commands to and older/ "named pipe" strategy - but to do this only if interesting to other devs. This or any other proposed approach.
I would wait for dev comments on this in order to decide the best approach.

As I understand it, the main issue is the random syscall. If the syscall would be fixed, you only would have to tell "call <this syscall> with <this opcode> and these <params>".

But as the syscall is random, webMAN needs a way to know the random value, in order to be able to disable psnpatch protection.

As both plugins typically are loaded during the boot time, an approach could be:
- Define a static address in LV1 or LV2 memory where usually has 0x0000000000000000 or a known value (e.g. 0x800000000000000080 in lv1 or lv2).
- PSN Plugin would poke the "random" syscall value to that address and wait for 10 seconds or until the poked value in that static address is changed, then clear the poked value.
- In that period webMAN could peek that address to get "random" value and also clear it (restoring the zeros or the known value).

This is just an idea.... you decide what's the better approach (if ever this interaction would happen).

Code required in PSN Patch:

lv1_poke(shared_address, random_syscall); for(u8 s=0; s<10; s++) {sys_timer_sleep(1); if(lv1_peek(shared_address) != random_syscall) break;}
lv1_poke(shared_address, 0);

Code required in webMAN:

random_syscall=0; for(u8 s=0; s<10; s++) {random_syscall = lv1_peek(shared_address); if(random_syscall) break; sys_timer_sleep(1);}
lv1_poke(shared_address, 0);

 

[kokotonix]

As I understand it, the main issue is the random syscall. If the syscall would be fixed, you only would have to tell "call <this syscall> with <this opcode> and these <params>".

But as the syscall is random, webMAN needs a way to know the random value, in order to be able to disable psnpatch protection.

As both plugins typically are loaded during the boot time, an approach could be:
- Define a static address in LV1 or LV2 memory where usually has 0x0000000000000000 or a known value (e.g. 0x800000000000000080 in lv1 or lv2).
- PSN Plugin would poke the "random" syscall value to that address and wait for 10 seconds or until the poked value in that static address is changed, then clear the poked value.
- In that period webMAN could peek that address to get "random" value and also clear it (restoring the zeros or the known value).

This is just an idea.... you decide what's the better approach (if ever this interaction would happen).

Code required in PSN Patch:

lv1_poke(shared_address, random_syscall); for(u8 s=0; s<10; s++) {sys_timer_sleep(1); if(lv1_peek(shared_address) != random_syscall) break;}

Code required in webMAN:

random_syscall=0; for(u8 s=0; s<10; s++) {random_syscall = lv1_peek(shared_address); if(random_syscall) break; sys_timer_sleep(1);} lv1_poke(shared_address, 0);

Yeah. I like it [emoji3]
Then webman can try to use psnpatch syscall to disable syscalls .
If it fails will use normal approach.
Give me some days [emoji3]


Sent from nowhere Using Tapatalk

 

[Joonie]

Yeah. I like it [emoji3]
Then webman can try to use psnpatch syscall to disable syscalls .
If it fails will use normal approach.
Give me some days [emoji3]


Sent from nowhere Using Tapatalk

If that's the case I advise removing disable syscalls on startup option from webman as many noobs don't read enough understand how things work and end up complaining about games not being mounted


Sent from my iPhone using Tapatalk

 

[aldostools]

If that's the case I advise removing disable syscalls on startup option from webman as many noobs don't read enough understand how things work and end up complaining about games not being mounted

The option that disables the syscalls on startup is turned off by default... I don't see any reason to remove the feature...

Indeed that suggestion invites me to add the option "[ ] Brick your console" for the noobs that don't read J/K

 

[Joonie]

The option that disables the syscalls on startup is turned off by default... I don't see any reason to remove the feature...

Indeed that suggestion invites me to add the option "[ ] Brick your console" for the noobs that don't read J/K

Ok, let's say a user used that "disabling syscalls on startup" was applied via psnPATCH/webMAN together, how does a user remove that option? reinstalling CFW?

To me, disabling syscalls = bricking PS3, because I can't live without custom calls. lol

 

[kokotonix]

If webman is still running the user could go into setup and disable auto disable syscalls.

(Note that I'm also not a great fan of disabling syscalls at boot - I prefer the auto lock psn access until syscalls are disabled).


Sent from nowhere Using Tapatalk

 

[aldostools]

Ok, let's say a user used that "disabling syscalls on startup" was applied via psnPATCH/webMAN together, how does a user remove that option? reinstalling CFW?

To me, disabling syscalls = bricking PS3, because I can't live without custom calls. lol

Syscall 8 is faked but not removed. Do you say that webMAN does not load if the syscalls are disabled on startup?

Also deleting /dev_hdd0/tmp/wmconfig.bin is possible without using syscalls

 

[Joonie]

If webman is still running the user could go into setup and disable auto disable syscalls.

(Note that I'm also not a great fan of disabling syscalls at boot - I prefer the auto lock psn access until syscalls are disabled).


Sent from nowhere Using Tapatalk

Syscall 8 is faked but not removed. Do you say that webMAN does not load if the syscalls are disabled on startup?

Also deleting /dev_hdd0/tmp/wmconfig.bin is possible without using syscalls

Currently it's possible to re-enable syscalls via changing setup, I'm saying "WHAT IF" all the custom syscalls are permanently disabled on startup if webMAN uses the psnPATCH way of disabling, like you are having issues while on Rogero 4.46 cobra without stage2 loaded.

 

[kokotonix]

Syscall 8 is faked but not removed. Do you say that webMAN does not load if the syscalls are disabled on startup?

Also deleting /dev_hdd0/tmp/wmconfig.bin is possible without using syscalls

With psnpatch syscall even sc8 is disabled.
But webman should be loaded with syscalls still enabled, so it would control the situation.


Sent from nowhere Using Tapatalk

 

[aldostools]

Currently it's possible to re-enable syscalls via changing setup, I'm saying "WHAT IF" all the custom syscalls are permanently disabled on startup if webMAN uses the psnPATCH way of disabling, like you are having issues while on Rogero 4.46 cobra without stage2 loaded.

I really don't pretend to use PSNpatch way to remove the syscalls on startup

I only want that PSNpatch give the permission to use PSN in an automated way when a game is mounted... and maybe let it to re-enable the syscalls (if possible).

The issues that I had with Cobra disabled were not critical (only IRISMAN could not detect the FW).... but I understand your worries