Is a usable CFW available yet? Or is this the first of many steps before we see the likes of the PSP CFW. It would be awesome to build on the vunerability of the 3.41 firmware, with the added extras of the 3.50+
It may be a stupid question so I'm sorry, but is it even possible?
"making progress" sounds like an understatement. Something new happens EVERY DAY.
The original xbox scene and the psp scene didn't move this fast.
Could this same decryption method be used to decrypt retail eboot's/psn games as well, or is that a completely different type of encryption?
I posted another update HERE, and below are some more comments from graf_chokolo: http://xorloser.com/?p=297&cpage=5#comment-1611:
How to decrypt PKGs
1. Dump your FLASH with my code
2. Extract spu_pkg_rvk_verifier.self
3. Extract RL_FOR_PACKAGE.pkg from 3.41 PUP
4. Convert it to C hex and paste into rvk_pkg_341.c
5. Extract CORE_OS_PACKAGE.pkg from PUP
6. Run PSGroove with my payload
7. Send spu_pkg_rvk_verifier.self to PS3
8. Send CORE_OS_PACKAGE.pkg to PS3
9. Run wireshark
10. First 3 packet you will receive is the Shadow Register Area
11. At offset 0×30 in Shadow Register Area you will find Stop Code (16 bit), if it’s 0×100 then decryption was successful :-)
12. Extract decrypted package from wireshark dump and inflate itgraf_chokolo says:
I’m from Germany, Stuttgartgraf_chokolo says:
Guys, you realize that i could only use USB Dongle Master Key on already exploited GameOS to bring PS3 into product mode :-) because only on an exploited GameOS i have access to Dispatcher Manager and USB Dongle Authenticator.graf_chokolo says:
And you will not be able to use it on 3.50. And don’t waste your money on PSDowngrader because as soon as YNOS releases a new firmware, they will change at least the USB Dongle Master Key or the whole authentication algorithm and all your dongles will not work :-) I hope you realize it and won’t waste your money :-)graf_chokolo says:
PS Jailbreak people “borrowed” some things from $ONY that allow them to initiate the challenge/response protocol between USB Dongle Authenticator and unexploited GameOS :-) I don’t have these things and will not use them :-) I can only initiate the challenge/response protocol on an exploited GameOS.graf_chokolo says:
I dont’ know what they use. Maybe i’m wrong and you don’t need any stuff from SONY to initiate challenge/response protocol. I only know how to bring PS3 into product mode by using HV calls and how the protocol is implemented in Hypervisor.graf_chokolo says:
There 2 methods how to get/decyrpt USB Dongle Master Key.
Both methods need HV access.
1. Initiate USB Dongle Authentication protocol from GameOS
2. Reboot GameOS and dump HV from Linux but without rebooting HV
3. USB Dongle Master Key is stored unencrypted in HV after USB Dongle Authenticator service was used first time
1. Extract encrypted USB Dongle Master Key from HV (already done)
2. Patch Dispatcher Manager in HV Process 3 so that it allows access to SYSCON Manager
3. Use exploited GameOS to communicate with SYSCON through Dispatcher Manager to decrypt the USB Dongle Master Key
I didn’t have time to reverse HDD encryption yet. Have more interesting things to reversegraf_chokolo says:
USB Dongle Master Key is decrypted by using Virtual TRM Manager service Decrypt Master. This service just routes the request to SYSCON Manager. The SYSCON Manager does the real job.
The request to decrypt the Master Key contains of course the encrypted Master Key, seed and 2 8-byte values: LPAR Authenticator ID and Program Authenticator ID. These 2 values are used during decryption process and they have to be the same values that are used by USB Dongle Authenticator. I know the values used by USB Dongle Authenticator. So, i know all these value and how to do it So, you should now ask me, why i didn’t decrypt it, damn
The problem is, that Dispatcher Manager through which all the communication between GameOS and HV Process is passed, doesn’t allow you to use LPAR Authenticator ID and Program Authenticator ID that are used by USB Dongle Authenticator By patching Dispatcher Manager we could fix this But for this we need HV rightsgraf_chokolo says:
Both methods are possible on a PS3 with exploited HV 3.15
Don’t turn off power, just shutdown GameOS and boot Linux, HV should not be rebooted in that case.graf_chokolo says:
With HV access you can do a lot, not only decrypt Master Key but also downgrade and other cool thingsgraf_chokolo says:
HV uses real memory addressing. But LPAR 1 processes use virtual memory address space, so if a process crashes or does something stupid it won’t bring the whole HV down So, because of virtual address space HV processes are not continuous in HV dump. You have first to extract every page of a process before you can analyze them. But all processes are in the HV dump You just have to extract them first. It’s not very hard.
If you have HV dump 3.15 then it’s easy. You can use my HV Reverse Engineering Page to locate processes in your dump.
At offset 0×18 of each process object you will find a pointer to AddressProtectionDomain object. Go there. AddressProtectionDomain has at offset 0x3C a 32 bit pointer to first ProtectionPage of the process’s address space. All pages of a process are linked in a list
So just traverse the list of ProtectionPages and extract Virtual Address (VA) and Real Address (RA) of each page. On my HV Reverse Engineering page you will find what a ProtectionPage looks like
ProtectionPages build memory segments. HV processes have 4 memory segments: code, data, heap and stack. I f you see that the virtual address of a ProtectionPage jumps then a new memory segment begins
So, extract all pages, write down their VAs and RAs. After that extract the pages from HV dump and build memory segments. The memory segments you can now import into IDA and analyzegraf_chokolo says:
I will get soon PS3 with 3.15. But i only know how to make downgrades on an exploited GameOS, actually we don’t need GameOS to make downgrades. I’m able to communicate with Update Manager directly through Dispatcher Manager and know how updates work and how to do downgrades. But i’m not sure that GameOS 3.50 will allow us to make downgrade even in product mode.
It needs testing.
I wonder if this can be used to decrypt some eboots ?
Some more comments from graf_chokolo and xorloser: http://xorloser.com/?p=297&cpage=7#comment-1710
No, it’s not packet_id I think it’s just a counter, request id maybe or something like that. GameOS reads it, stores into DM header and then increments it.
that is how a packet id is commonly used, like a counter. it ensures each packet has a unique id.
No, packet_id is something diffrent in DM, it’s not request id.
Look for string “_USB_DONGLE_AUTH_USB_DONGLE_” in the dump In HV 3.15, the master key is before this string
For method 2, you have first to reconstruct Process 3 where DM runs. After that you have to translate EA address from Process 6 to RA and patch it in HV By patching DM, you can enable access to SYSCON Manager
I have got my 1st fat PS3 with HV 3.15. Let the fun begin, guys
2E 02 01 is the header of data that is sent by USB Dongle Authenticator. And 2E 02 02 is the header of data that is sent to USB Dongle Authenticator. JIG doesn’t communicate with USB Dongle Authenticator directly
First, USb packets are sent to GameOS. then GameOS extracts them, repacks and send it to DM and DM sends it to USB Dongle Authenticator. The same is for the data sent by USB Dongle Authenticator. So, GameOS just adds it’s own header or something like that
Sorry, still waiting for my SX28 devboard I have got now 2 fat PS3 with 3.15 but no hardware to exploit it yet
In the mean time i’m working on self decryption
Look at function at address 0×00297640 in HV dump. I called this function get_proc_table_entry because it returns a pointer to a HV proc. This function references the HV proc table And from HV proc table you will be able to get all HV procs Feel free to ask questions about HV, i will try to help anyone who is really intereset in HV reversing and learning new stuff about HV
The HV procs are not continuous in HV dump, you have first to extract/dump them from HV dump, every page of a proc have to be extracted from HV dump before you will be able to see any string refrences HV procs use virtual address space, so they are only continuous within one page