Discussion of Theories for Newer PS4 Games on 4.05 Firmware

Following the recent PS4 Barthen Method for getting newer games running with PS4HEN, some forum members including @SkysTheLimit, @Goldenboy22 and @Picalo would like to open a discussion of theories on how newer PlayStation 4 game dumps can become playable on exploited 4.05 Firmware consoles.

We'll use this as an ongoing discussion thread for those who'd like to share their insight and research into getting newer PS4 games with Minimum Firmware Versions above 4.05 OFW dumped and running, which according to Mathieulh is currently the BEST PS4 Firmware to be on as 1.76 is now considered outdated since the 4.05 exploit chain from SpecterDev with popular 4.05 exploit forks and experiments by IDC alongside the PS4 Exploit Host by Al Azif.

Here are links to some current theories from the Barthen Method topic:

• From Goldenboy22
• From SkysTheLimit
• From Picalo
• Follow up by SkysTheLimit

Finally, below are some other PS4 MEME and Tweets making rounds on Twitter today:
Cheers to @B7U3 C50SS and @SSShowmik for tips in the PSXHAX Shoutbox!

 

[SkysTheLimit]

@73n1x69: Thanks anyway. Lets assume the following:

The SAMU is a processor - means it needs some RAM (Memory) to store at least his Stack. In the Process of decrypting a PKG - from all I read from the scene - the SAMU gets the PKG and then the PS4 OS mounts a decrypted Filesystem, in which the decryption Process is transparent to the OS. The SAMU for sure does not decrypt gigabytes of PKGs and then copies it the content to back to the filesystem.

-> Input: encrypted PKG
[SAMU Black Magic]
<-Output Decrypted PKG Filesystem for the PS4 OS

When Calling the SAMU to decrypt the PKG, it needs a STACK to operate it´s execution flow and function calls (or at least something similar to a stack, don´t know how SAMU operates). And on the Stack it gets a File-Handle or a BitStream or whatever Black Magic to the access the encrypted PKG, then gives back a Linux compatible filesystem which can be mounted.
Further assumption:
(Lets work with I-Node Numbers here to make it easy:

Horizon 4.07 has inode number 100
Game 4.05 has inode number 200

--> Call SAMU to decrypt 200
--> SAMU checks headers, 4.05 is fine
--> Kernel-Interrupt and exchange 200 with 100
--> SAMU decrypts 100 instead of 200

This could be also a possibility to trick the SAMU.

Does anybody know where to find infos / docs about the SAMU?
Do SAMU and OS share the same RAM (Memory), but a Memory Management Unit prevents us from seeing the SAMU Memory at all?

===
Horizon 4.07 has inode number 100
Game 4.05 has inode number 200

--> Call SAMU to decrypt 200
--> SAMU checks headers, 4.05 is fine
--> Kernel-Interrupt and exchange 200 with 100
--> SAMU decrypts 100 instead of 200
===

To validate or further test this theory, we could for example look at the syscall logs for file access in the OS. The Output could look like this:

- Call the SAMU to decrypt a PKG
- SAMU should access this files for the FW Check: the headers of encrypted sprx and eboot
- SAMU then should access all the files in order of the OS loading the game

After the 1st file access we could exchange a the 4.05 game with a 4.07 (or <4.50) game.

The idea behind the theory is that we might cannot control the SAMU, but we are in control of the files that the SAMU wants to access, so if we time an exchange of 4.05/4.07 file very well we could trick the SAMU in his flow of execution.

 

[Chaos Kid]

think of samu as a hypervisor of sort it protects the kernel but knowing this you should also know vm host vm guest

maybe read this >>. https://www.psxhax.com/threads/dumpfile405-ps4-4-05-file-decrypter-by-vvildcard777-libftps4-fix.3404/

taking this whole concept you come up with will be nothing but misalignment and more then likely not work or cause a bad dump. it's like trying to start a game based on another fw point are you gonna do that with every game?

 

[SkysTheLimit]

@Chaos Kid I´m very sorry to tell you that i honestly don´t understand what you want to tell me since the last two posts you made.

-->The SAMU itself is a hypervisor? Which kernel does it protect, it´s own (SAMU "Kernel") or the PS4 OS kernel? What do you want to tell me with VM Guest and VM Host, I dont know if the SAMU is actually a hypervisior having the BSD inside a guest VM - I though more about a blackbox which you can ask to do stuff for you but you can´t look inside (because you have "physically" no access to its ROM/RAM).

Read it two times already since it is the 2nd time you quote it. but I can´t find anything obviously related to this talk. Maybe you should point out or summarize what you want to tell us with that.

 

[Chaos Kid]

nevermind you are missing so much info on this stuff or understand what I'm pointing at cause your stuck with a one way track mind.

Kernel ELFs generated from memory dumps will not work since R/W segments might have been modified into a state where booting is not possible. Please generate proper binaries offline by decrypting ELF segments with SAMU, not by dumping memory.

 

[SkysTheLimit]

Make makes my theory about exchanging the files or check for the access to certain files of the PKG hard is that

1st the Hardware might use some Direct Memory Access, means that the SAMU directly talks to the Harddrive and PS4 OS is not able to interrupt or monitor it properly

2nd the PKG is given to SAMU in an encrypted state, means we could not check for certain file access inside the PKG to point out the actual point where it just checks for firmware and when it starts to decrypt the PKG, but on the other hand we could do some guessing of the timing here (like it always needs 200ms to check FW and then we can exchange the files)

As I said, sorry, maybe I am just lacking too much knowledge about PS4 architecture and OS-security in general.

"Kernel ELFs generated from memory dumps will not work since R/W segments might have been modified into a state where booting is not possible. Please generate proper binaries offline by decrypting ELF segments with SAMU, not by dumping memory."

This sentence is talking about BOOTING a Kernel Dump taken from Memory because the memory is changing while you dump, resulting in some messed up memory regions. In order to get a clean kernel dump use the encrypted kernel file on the file system and tell samu to decrypt.

Once again, I am not able to see where this is connected to what I said.

 

[Chaos Kid]

yes cause it helps you understand how things work when your running the emu to see how it all connects with samu. your just talking of misalignment to decrypt newer games which will not work. let's trick this and that and see what happens but it's different when you have an emu on a pc and testing what's possible

 

[turrinha]

exploit 4.55 no date release ? book

 

[SkysTheLimit]

@Chaos Kid Is there any publicly available Download to (properly) dumped & decrypted PS4 Kernels compatible with the Emulator (4.50 and 5.00)?

https://github.com/AlexAltea/orbital

 

[Horst von Braak]

the ps4 emu seems to be a good idea

 

[Chaos Kid]

not as far as I know he only has partial support due to missing parts of it I added the rest from what I have