PS4 EMX. New PS4 emulator is a reality (or scam)

[Cyan]

These people are true geniuses. They made it so fast. It's not easy at all to create a console emulator. At the moment, they managed to make the bios run.

This is their official homepage:

https://github.com/ghaststeam/ps4emx

 

[Deleted member 11852]

These people are true geniuses. They made it so fast. It's not easy at all to create a console emulator. At the moment, they managed to make the bios run.

Getting the BIOS to run is an accomplishment but isn't the hard part. If they can get a game running, I'll be impressed.

 

[Rikimaru]

It's a fake. Boot image is encrypted with per console key. Nobody obtained it yet.

 

[Deleted member 11852]

It's a fake. Boot image is encrypted with per console key. Nobody obtained it yet.

Would you mind sharing your source for this? This is the first I've read of it and the drive clone tricking exploit used in Brazil suggests this is not the case.

 

[Rikimaru]

Would you mind sharing your source for this? This is the first I've read of it and the drive clone tricking exploit used in Brazil suggests this is not the case.

Cloning uses image from the same console. It does not transfer image from another one.

Per console key is used since previous gen (even on Wii). Why would not they do it now? Even if not per console, it is still enrypted with some key.

 

[MrFox]

They are looking for donations, and have no reasonable proof of having anything to work with at all.

"We don't have a PS4 or PS4 games, we can't afford high-end computers with Blu-ray drives right now"

Yep, this is my red flag.

 

[BRiT]

Cloning uses image from the same console. It does not transfer image from another one.

Per console key is used since previous gen (even on Wii). Why would not they do it now? Even if not per console, it is still enrypted with some key.

So you're saying "cloning" is copying from console 1 hard drive 1 to console 1 hard drive 1?

Where the image steps are done at 2 moments in time:

First a backup image is created when all the games are installed and the console is marked as the active console.
Next the console is deactivated and no longer marked as primary.
Finally the backup image is restored to the console hard drive to trick it to think its still active.

Seems like it could be faster to remove/replace the hard drive with a slab drive before you deactive the console so you dont have to restore the drive image. Though this depends on how many sectors have to be recopied to restore the console into thinking its still active.

 

[Shortbread]

They are looking for donations, and have no reasonable proof of having anything to work with at all.

"We don't have a PS4 or PS4 games, we can't afford high-end computers with Blu-ray drives right now"

Yep, this is my red flag.

That. Plus, the splash PS boot is similar across all Playstation systems. Just saying...

 

[Rikimaru]

So you're saying "cloning" is copying from console 1 hard drive 1 to console 1 hard drive 1?

Where the image steps are done at 2 moments in time:

First a backup image is created when all the games are installed and the console is marked as the active console.
Next the console is deactivated and no longer marked as primary.
Finally the backup image is restored to the console hard drive to trick it to think its still active.

Seems like it could be faster to remove/replace the hard drive with a slab drive before you deactive the console so you dont have to restore the drive image. Though this depends on how many sectors have to be recopied to restore the console into thinking its still active.

afaik they are doing backup of the nand.

 

[Deleted member 11852]

Per console key is used since previous gen (even on Wii). Why would not they do it now? Even if not per console, it is still enrypted with some key.

Because from a security hardening perspective, it's pointless. If you can break the encryption on one PS4 you can break them all using the same method. Not that you need to compromise the BIOS on them all because they're all going to be the same, save for those that have not had any updates applied.

The only reason to employ per-device encryption with a device-unique key is to protect information that is unique to that device, i.e. user's personal data and we know from the Brazil exploit that is all located on NAND and the HDD.

 

[Rikimaru]

Because from a security hardening perspective, it's pointless. If you can break the encryption on one PS4 you can break them all using the same method. Not that you need to compromise the BIOS on them all because they're all going to be the same, save for those that have not had any updates applied.

The only reason to employ per-device encryption with a device-unique key is to protect information that is unique to that device, i.e. user's personal data and we know from the Brazil exploit that is all located on NAND and the HDD.

It's more difficult to modify console if it has unique key. It's not pointless.
Glitching 360 would be much easier without unique key.

 

[pMax]

Because from a security hardening perspective, it's pointless. If you can break the encryption on one PS4 you can break them all using the same method. Not that you need to compromise the BIOS on them all because they're all going to be the same, save for those that have not had any updates applied.

The only reason to employ per-device encryption with a device-unique key is to protect information that is unique to that device, i.e. user's personal data and we know from the Brazil exploit that is all located on NAND and the HDD.

er... don't become a security architect - really...

OT: are NAND dumps from different PSs identical?

by the way, the project is a scam, just check the sources and you see they just put some fake header files and so on. More interesting to discuss - how much donations did they get already?

 

[Shifty Geezer]

This news is from 2014. Comments on the vid say it's a scam called out as such by RPCS3 emu devs.

 

[Deleted member 11852]

It's more difficult to modify console if it has unique key. It's not pointless.
Glitching 360 would be much easier without unique key.

It depends wholly on how the unique key is used and arguably, the real value is knowing how the BIOS works. But once you've you extracted the BIOS from one machine, the game is largely over. The real hurdle in the initial compromise is not knowing exactly what the BIOS image should look like so you have a raw dump of the encrypted image and you're running various decryption strikes using industrial algorithms but for each decrypted data image, you then have to check/test it to see if it's produced viable code. However..

er... don't become a security architect - really... OT: are NAND dumps from different PSs identical?

You've not really said why you think this but it's a view I've encountered a lot over the years and is counterintuitive or rather, endemic of dated thinking that encrypting everything is better. It is not. Using tens of millions of unique keys (one per PS4) to encrypt identical data provides a metric shit tonne of cipher blocks to analyse and improve the decryption algorithm.

Unique keys are best employed when they can not be compromised in this way, i.e. used to encrypt unique data like user data that will be different from device to device. Thereby there is no reference cipher block to aid analysis. It would have made sense for Sony to use any unique device key to encrypt the contents of NAND in this way but we know it didn't because of the Brazil exploit. You probably want to read this thread.

The most secure way would be collectively encrypt the BIOS, NAND and HDD according to a unique device key but that would preclude user upgradable HDDs. Collective encryption of BIOS and NAND would be the obvious fallback but we know that's not the case.

 

[pMax]

[...] but it's a view I've encountered a lot over the years and is counterintuitive or rather, endemic of dated thinking that encrypting everything is better. It is not.

Thank you for schooling me on this. Yet, I beg to differ.

this thread.

Yet, HDD on PS4 seems encrypted on per device key. PS3 is a classic example of that - you cannot access the HDD unless you can turn on the PS3 to fish the key.

The most secure way would be collectively encrypt the BIOS, NAND and HDD according to a unique device key but that would preclude user upgradable HDDs. Collective encryption of BIOS and NAND would be the obvious fallback but we know that's not the case.

See above.

 

[Deleted member 11852]

Thank you for schooling me on this. Yet, I beg to differ.

It's a mathmatical fact. The more data cipher blocks available for any given reference target greatly introduces the vector of attack.

Yet, HDD on PS4 seems encrypted on per device key. PS3 is a classic example of that - you cannot access the HDD unless you can turn on the PS3 to fish the key.

No it obviously isn't, otherwise the cloning exploit being used in Brazil would not work. Read the thread where this was discussed.

 

[Davros]

If its true don't expect it to be end user ready for at least 5 years

 

[Exophase]

This is a very strange scenario. Why start a github only to not actually host the code doing what's done in the youtube video? Since then (April 2014 when the video was released) other people have started committing the start of CPU and GPU emulation, but still barely a start. So they're letting others commit emulation code on top of their unreleased emulation code? And if they're relying on a virtualization approach (assuming that's really viable) I don't see why they'd be accepting CPU interpretation at this stage anyway. What I also don't see is why virtualization would be as slow as this is, even at an early state, although there could legitimately be something sucking up cycles badly.

The readme file also feels very misleading. I've never seen an emulator's readme have a "list of emulated hardware" that goes on to include all of the things that they hope to have emulated in the future. They're usually pretty explicit about what is and isn't currently emulated, if they list anything at all. Furthermore, this is pretty strange to include in their list of primary planned features:

"Ability to map emulated memory to secondary-storage, so computers will little RAM can still replicate PS4 RAM in emulation mode."

Assuming there's any potential at all for virtual memory to not end up unusably slow, I can hardly see why this would even be worth thinking about at such an early stage. Any sane emu dev would first focus on getting it working well on systems that do have enough RAM.

Whole thing just screams fishy.

 

[Deleted member 11852]

"Ability to map emulated memory to secondary-storage, so computers will little RAM can still replicate PS4 RAM in emulation mode."

You mean you don't have a HDD with faster access times than GDDR5? Upgrade your HDD, you peasant!

 

[pMax]

It's a mathmatical fact. The more data cipher blocks available for any given reference target greatly introduces the vector of attack.

er...... you use ciphers which are not resistant to known plaintext attacks? It is not a good idea...

No it obviously isn't, otherwise the cloning exploit being used in Brazil would not work. Read the thread where this was discussed.

Maybe you should be more focused when reading articles.
They format the HDD and reinstall everything. If it werent encrypted uniquely, why would you need to do it?