Thread: Middle man hack for BD drive
My original thought was to use a MCU+HDD to emulate the BD. the MCU shall receive the instructions from PS3 MB ATA bus and read data from HDD, then send it back to PS3 MB. The only way to make it success, is to understand the data protection being used on the ATA bus inside PS3. To log the data is the 1st step, then we have to figure out how and what the PS3 MB is communicating with the BD drive. If we're lucky, we might figure out a way to emulate the BD drive.
This is finally something worth reading and considering (versus all the newbie "we need a hack like XBox 360"). However this seems to be pretty low-level stuff.
By using MCU and HDD you mean something like this:
- Connecting MCU (micro controller unit?) in between PS3 and original BD drive
- MCU (micro controller unit?)
- receives ATA commands
- forwards it to original BD drive
- logs the command and received response (data)
- returns the received data back to PS3
- collected logs can be analyzed - common data can be identified and sroted out from anything suspicious/special
- Connecting MCU in between PS3 and HDD with logs from previous step
- Attempt to emulate BD drive using logged data
Do I understand that correctly?
If that worked and you'd be able to identify what data is just common data readable from BD filesystem and what is something special, you could replace that common data with ISO and just emulate those special parts.
This however requires MCU knowledge (both HW and SW)...
well, not that complicate.. to log the data, a LA (logic analyzer) will do the job very well.
if we could understand the protocol between PS3 OS and the BD, then we could possibly build our own BD, or something behaves like a BD.
the MCU and HDD is to emulate the BD, not to intercept or log the data. We can implement the protocol learned from the ATA bus, and then program the MCU to response to the PS3 OS just like a BD drive does. the HDD is to store the huge data which should be stored in the BD disk.
so it will act like a daemon tool/virtual BD drive, but it's made by hardware circuit, not a software.
perhaps, you can use a mainboard with 2 ata ports ... one to ps3 mb and the other port to the bd drive.
and you have to programm a little dos-prog to get the data from the bus and put the data to the bd drive.
here a nice link for your project: http://www.pjrc.com/tech/8051/ide/wesley.html
From my humble point of view BR-P pass data encrypted to the system as well as PSN pass enc. data to HDD, without any way to have a decrypted copy o' some encrypted files I think it's not so easy to make the whole process useful, I mean, the CPU for sure doesn't need to decrypt on the fly the data to run, it could overhelm it's capacity and slow unnecessairly down the performance, if the CPU runs the code "as it is" for example there is no way to set up a face-off between the very same crypted and plain files that's the goal to achieve, as far as I know, in the effort to find the algo. Am I wrong, am I ?
Or ... yes, of course, stupid me, what are you searching for it's only a way to replace BR-P when it breaks itself down ... without having to bother $ony ...
Sorry for the terrible way in which I explain myself in english.
..and good luck, of course.
Since this thread seems to be enough full of propellerheads I will put here what for me is an interesting option....
Lineage: PSN sends data to HDD and data runs through a network () connection ..
...data from PSN are "bond" to every console and/or user, it could be of some interest to face-off data before they enter blackbox and after they're stored onto it ?
Of course data could have been signed on the fly on the user account basis before leaving the source and in this case there is nothing to do but to consider that they are probably not only signed with user account but they've left the server already encrypted and also signed....this thing could be a rubberwall....
For sure the CPU, at least has a "switch" to open and allow some functions that can be activated only by an encrypted code but no algo no party and for sure I don't think there's a function "gimmedacode" to retrieve it ....and...even if there were it should be activated only by an encrypted command....
...but maybe I'm running a little OT and i don't want.
Whaddayathink about interviewing the NIC instead of the BDP ?