Connexion

[NEWS] Explications par KaKaRoTo sur les erreurs de contrôleurs : News - PS3-Infos

[NEWS] Explications par KaKaRoTo sur les erreurs de contrôleurs   

Les news du Hack PS3 postées sur PS3 Infos

[NEWS] Explications par KaKaRoTo sur les erreurs de contrôleurs

Messagepar orwel » Mer 27 Oct 2010 17:40

ImageKaKaRoTo, auteur du PL3, annonce sur Twitter avoir trouvé l'explication aux erreurs de contrôleurs qui surviennent avec certain jeux, mais également pourquoi les backups ont besoin du patch 5 et des erreurs de permission, aussi bien qu'une solution...


Voici l'explication fournie par KaKaRoTo :

<KaKaRoTo> Works fine with latest default payload.
<KaKaRoTo> So only with NUS (no_unauthorized_syscalls payload), so it's normal and expected.

<hObbit> so what does that mean

<KaKaRoTo> Just means that what I said the first day when i added the NUS payload still applies.
<KaKaRoTo> "only use it to put the ps3 back into restrictive access mode to unauthorized syscalls"

<hObbit> The NUS is for controller fix right?

<KaKaRoTo> Not for controller fix, it's just some (2 or 3) games that won't work without it. Eyepet is the only one I can remember.
<KaKaRoTo> The same would happen with hermes payload if you enable "patched mode" in it.
<KaKaRoTo> The only thing is that for him, the 'patched mode' only gets enabled after the drive is mounted, so maybe that's why noone noticed.
<KaKaRoTo> but it's basically the same code

<hObbit> Can we have that called via homebrew like hermes payload?

<KaKaRoTo> We could, but I don't want to, because it's an ugly hack.
<KaKaRoTo> Basically those patches disable a function that is used by every system call.
<KaKaRoTo> is_this_syscall_authorized_on_this_system/modem/whatever
<KaKaRoTo> Some games require a specific syscall to be enabled.
<KaKaRoTo> It's most probably related to the fact that the ps3 would only unlock the /dev_hdd0/game/<ID>/ of what the bluray player reads in sector 2.
<KaKaRoTo> So when a backup is launched and tries to 'install game data' it can't because it can't access the right directory.
<KaKaRoTo> So that patch makes it work.
<KaKaRoTo> It only has the side effect of enabling every other system call.
<KaKaRoTo> patch_func5 is what does all that (the is_authorized)
<KaKaRoTo> I suppose that patching it to return 1 all the time makes it return 1 to the 'syscall_is_root' or something, that's why permissions get ++
<KaKaRoTo> It also screws up the controller for games like F1 and SF4 because they need maybe something like 'syscall_is_special_usb_stick/wheel_plugged_in'
<KaKaRoTo> They think yes, so they try to use it, disable the controller, and then.. oups, nothing works.
<KaKaRoTo> (That's why you can 'fix' the controller if you plug in a wheel or the SF4 arcade usb thingy)
<KaKaRoTo> That's what patch 6 and 7 do, they force those 2 specific syscalls to return '0' instead of '1'.
<KaKaRoTo> But there are still other games that check other things and fail because of that (like eyepet, maybe it checks is_camera_plugged_in)

<hObbit> I see, so rather than enabling everything we'd need to find that specific syscall.

<KaKaRoTo> Exactly. The real fix is find just the right syscall to have elevated permissions, and fix just that one to think it's "1".
<KaKaRoTo> Instead of making it "1" for EVERY syscall, then return 0 selectively to fix specific games.

<hObbit> So what needs function 5 then? is that the eyepet game?

<KaKaRoTo> no no
<KaKaRoTo> you have this :

<KaKaRoTo> syscall_X (arguments)
<KaKaRoTo> {
<KaKaRoTo> can_i = function_5(args);
<KaKaRoTo> if (can_i == 1) { do stuff }
<KaKaRoTo> else { return error }
<KaKaRoTo> }

<KaKaRoTo> patch 5 is to overwrite the 'can_i_do_this' function completely
<KaKaRoTo> so EVERY syscall gets 'yes you can'
<KaKaRoTo> what function 6 and 7 does is just :

<KaKaRoTo> syscall_fix_for_f1 (arguments)
<KaKaRoTo> {
<KaKaRoTo> can_i = 0
<KaKaRoTo> ....
<KaKaRoTo> }
<KaKaRoTo> syscall_fix_for_ssf4 (arguments)
<KaKaRoTo> {
<KaKaRoTo> can_i = 0
<KaKaRoTo> ...
<KaKaRoTo> }

<KaKaRoTo> Patches 6 and 7 just patch the 'call func5' into 'func5 returned 0'
<KaKaRoTo> While patch 5 actually patches the content of func5 to always return 1.
<KaKaRoTo> You see how ugly it is? you understand why i didn't want to add a syscall to the payload just to enable/disable this 'patched mode'.
<KaKaRoTo> I want to do it properly, or not do it at all.


<iLLNESS> weird though... ssf4 works fine for me with NUS

<KaKaRoTo> yes it would
<KaKaRoTo> because NUS basically means 'all original'
<KaKaRoTo> it wouldn't work if you had patch 5, but not patch 6 and 7
<KaKaRoTo> but if there is no patch 5, then it would work


Pour faire simple, KaKaRoTo explique que certains jeux font appels à un syscall particulier. Ce syscall appelle une fonction pour évaluer si il a l'autorisation d'effectuer l'action. Le patch 5 permet de fausser cette fonction qui donnera alors toujours l'autorisation au syscall. Ce patch reste néanmoins une façon plutôt "bourrine" de régler le problème. Voila donc pourquoi elle n'est pas utilisée par le PL3 actuellement.

http://twitter.com/KaKaRoToKS/status/28851430715Source : http://twitter.com/KaKaRoToKS/status/28851430715
Avatar de l’utilisateur
orwel
Newseur
 
Messages: 437
Inscription: Jeu 9 Sep 2010 13:06

Re: [NEWS] Explications par KaKaRoTo sur les erreurs de contrôleurs

Messagepar fodil » Mer 27 Oct 2010 22:21

Trop fort ce KaKAROTO......! s'il pouvait se focaliser sur l'otheros dans le3.41 .......ainsi tout le monde pourra travailler sur un seul firmware!!!!
fodil
 
Messages: 8
Inscription: Dim 17 Oct 2010 23:14


Retourner vers News

 


  • Articles en relation
    Réponses
    Vues
    Dernier message

Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 6 invités

cron