[KDSBest]

Originally Posted by IngPereira Don't think so, because we have the 3.70 SDK and we can resign a prx with FSELF and swapping work's on 4.11 because we can use sc 837,838 to remount the vflash with the custom sprx trigger(xmb_ingame.sprx)... Remember we don't try to modify an existing sprx but we make our new one with the SDK and when we call it there will be a blackscreen but should trigger the Core dump.

First of all... If that is possible, I bet every dev i know would love you. *bing* xmb maybe lv2 code execution on 4.20. We are done belive me perfect.

Since we are not done this is not possible. Maybe 1-2 things I tell you might not fit 100% but I list enough. 1 Fail is enough to make this not work.

1. Fail: Your function sizes have to match the function sizes of the FW 4.20. Since we don't have a decrypted FW 4.20 we don't know them. Calls will fail. The XMB will most likely fail, but not the game => No Coredump because this is not a game exception .

2. Fail: VFlash is not used by GameOS it's Linux. If it's used by GameOS iirc it is an hdd region. On HDD files are encrypted so the decryption/signing will fail on FW 4.20 because system files are not downward compatible.

3. Fail: VFlash access is a patch in MFW so you can't access it iirc.

4. Fail: To go around Encryption/Decryption Signing fails and stuff you need to access the RAM directly which is not possible since OFW doesn't have the nice Peek/Poke Map/Unmap whatever patches.

[sardine]

Sound like its the end for ps3, hope you guys can crack it.

[KDSBest]

I know a way to get the PID now, but sony patched it in higher fws -.-.

So sad .

I managed to get a PPU Exception on most Games booted from original disc. I just get a crash log and no core dump.

Looks like on retail Eboots it is somehow deactivated .

[tweetymr]

Originally Posted by KDSBest I know a way to get the PID now, but sony patched it in higher fws -.-. So sad . I managed to get a PPU Exception on most Games booted from original disc. I just get a crash log and no core dump. Looks like on retail Eboots it is somehow deactivated .

Sounds like kind of stupid, but how long would it take to brute force the PID of a game? Don't know what you wanna do with this PID but I don't think there are so many Processes running...

[baargle]

Originally Posted by tweetymr Sounds like kind of stupid, but how long would it take to brute force the PID of a game? Don't know what you wanna do with this PID but I don't think there are so many Processes running...

Brute force?

That implies there is a way of doing it in software, there isn't. It would have to be done by hand - as in manually - as in non-starter.

[oPolo]

Originally Posted by tweetymr Sounds like kind of stupid, but how long would it take to brute force the PID of a game? Don't know what you wanna do with this PID but I don't think there are so many Processes running...

I don't know about the OS in the playstation, but windows does not seem to hand out PIDs sequentially, so you could just try one after another 0, 1, 2, 3, 4 (...) etc.... There would be alot of PIDs to choose from, if we can't assume something such as that (I guess the only thing we can assume probably, would be that the IDLE process would have PID 0 or so...)
************* [ - Post Merged - ] *************

Originally Posted by baargle Brute force? That implies there is a way of doing it in software, there isn't. It would have to be done by hand - as in manually - as in non-starter.

What he means with brute force, is just guessing for the PID till we hit it (I don't know if you misunderstood that, but I understood his point with writing bruteforce). Anyway, due to the nature of what is done = trying for the right PID and then crashing the PS3, it could perhaps quite easily have software made for bruteforcing it. But, the software would be extremely ineffective. The PID of the process would with almost certain certainty be a different one the next time the PS3 is started and the eboot is loaded.
So we couldn't even exclude PIDs we have already tried in our bruteforcing attack..

[JonahUK]

Can't you fself a retail self by changing the flag to 80 00?

[carldenning]

Originally Posted by JonahUK Can't you fself a retail self by changing the flag to 80 00?

lol dame why didnt we think of that when tb came out , we could of got rid of them a long time ago lol

do u even know what a fself is ?

[JonahUK]

@carldenning

Yes, I do. It was a response to the PID query regarding retail selfs.

[tweetymr]

Originally Posted by oPolo I don't know about the OS in the playstation, but windows does not seem to hand out PIDs sequentially, so you could just try one after another 0, 1, 2, 3, 4 (...) etc.... There would be alot of PIDs to choose from, if we can't assume something such as that (I guess the only thing we can assume probably, would be that the IDLE process would have PID 0 or so...) ************* [ - Post Merged - ] ************* What he means with brute force, is just guessing for the PID till we hit it (I don't know if you misunderstood that, but I understood his point with writing bruteforce). Anyway, due to the nature of what is done = trying for the right PID and then crashing the PS3, it could perhaps quite easily have software made for bruteforcing it. But, the software would be extremely ineffective. The PID of the process would with almost certain certainty be a different one the next time the PS3 is started and the eboot is loaded. So we couldn't even exclude PIDs we have already tried in our bruteforcing attack..

Ok, I thought it's all about getting the PID before the crash. But you are right, after the crash it would be a different ID. I think I shouldn't post directly after getting up or even before my brain booted correctly :D