Last year they covered Exploiting PS4 Video Apps, and at the 36th annual Chaos Communication Congress (36c3) from December 27th to the 30th 2019 in Leipzig Germany scene developer @Octopus (aka oct0xor on Twitter) will discuss Sony PlayStation 3 and PS4 firmware dumping, reversing and getting code execution on Blu-ray drives for those who love to learn all about their internals and security.
This comes following his previous PS4 Registry Editor / Viewer release, and in the Tweets below he states the intention of his research findings is NOT to circumvent copy protection noting that (in this case) fully compromised firmware doesn't lead to fully compromised security.
For those new to the PlayStation 4 scene, ever since the first unplayable PS4 game dump backups surfaced by ripping with PC optical drives hackers started examining the PS4 Blu-ray drive discovering everything from BDLive Bugs to Dumping PS4 Disc Games.
The PS4 scene eventually evolved to Loading PS4 Payloads via Blu-ray (Server-less Option) BD-J, PS4 Optical Drive to USB Game File Dumping, Blu-Play PS4 Homebrew Games and most recently some interesting PS4 NoBD Firmware Update Solutions.
Below are several of the related Tweets for those following:
PS4 Blu-ray Optical Drive Chip Swap Re-marry by NorthRidgeFix.com
a question that was kept in my mind for a very long time, even after contacting
oct0xor himself, was regarding ps3 sony drives having xorstream trick to be able to send crafted payload and run our own code. it baffled me how this was possible when it was not so on the renesas drives, that had similar crypto xorstream ctr bug. well, now I know the answer for such thing.
it seems that sony did not protect their own emboot code, by leaving some sort of signature back then (ecdsa was very famous and was secure, of course if properly implemented). renesas however did this by leaving R,S pair at the bottom of the emboot firmware to protect tampering
as a result, you can happily craft payloads if you possess an old drive (say, of a CECHA, for example, model 302R), and apply xor stream of emboot to it and run it when the bluray drive is either bricked or in state when it requires firmware flash. this is however not the case for renesas models (say 304R) where the R,S pair prevents u from doing so
as such, the mystery of why the xorstream size is exactly 0x10000 bytes is finally solved (this is because both sony and renesas have emboot of exactly 0x10000 bytes and both use aes-ctr to apply it in order to decrypt it)
This comes following his previous PS4 Registry Editor / Viewer release, and in the Tweets below he states the intention of his research findings is NOT to circumvent copy protection noting that (in this case) fully compromised firmware doesn't lead to fully compromised security.
For those new to the PlayStation 4 scene, ever since the first unplayable PS4 game dump backups surfaced by ripping with PC optical drives hackers started examining the PS4 Blu-ray drive discovering everything from BDLive Bugs to Dumping PS4 Disc Games.
The PS4 scene eventually evolved to Loading PS4 Payloads via Blu-ray (Server-less Option) BD-J, PS4 Optical Drive to USB Game File Dumping, Blu-Play PS4 Homebrew Games and most recently some interesting PS4 NoBD Firmware Update Solutions.
Below are several of the related Tweets for those following:
PS4 Blu-ray Optical Drive Chip Swap Re-marry by NorthRidgeFix.com
a question that was kept in my mind for a very long time, even after contacting
oct0xor himself, was regarding ps3 sony drives having xorstream trick to be able to send crafted payload and run our own code. it baffled me how this was possible when it was not so on the renesas drives, that had similar crypto xorstream ctr bug. well, now I know the answer for such thing.
it seems that sony did not protect their own emboot code, by leaving some sort of signature back then (ecdsa was very famous and was secure, of course if properly implemented). renesas however did this by leaving R,S pair at the bottom of the emboot firmware to protect tampering
as a result, you can happily craft payloads if you possess an old drive (say, of a CECHA, for example, model 302R), and apply xor stream of emboot to it and run it when the bluray drive is either bricked or in state when it requires firmware flash. this is however not the case for renesas models (say 304R) where the R,S pair prevents u from doing so
as such, the mystery of why the xorstream size is exactly 0x10000 bytes is finally solved (this is because both sony and renesas have emboot of exactly 0x10000 bytes and both use aes-ctr to apply it in order to decrypt it)