Hey there.

So... you use an ad blocker. That's cool. Sometimes we do too.

But without ad revenue, we wouldn't even be here. And we might not be here much longer.

Please disable your ad blocker and click to continue.

Page 2 of 2 First 12
  1. #11
    flashpc Guest
    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?

  2. #12
    SwordOfWar Guest
    Quote Originally Posted by flashpc View Post
    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?
    Sure it is. The scene is making progress.

  3. #13
    plutomic Guest
    "making progress" sounds like an understatement. Something new happens EVERY DAY.

    The original xbox scene and the psp scene didn't move this fast.

  4. #14
    e3g Guest


    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?

  5. #15
    Join Date
    Apr 2005


    I posted another update HERE, and below are some more comments from graf_chokolo: http://xorloser.com/?p=297&cpage=5#comment-1611:

    graf_chokolo says:

    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 030 in Shadow Register Area you will find Stop Code (16 bit), if it’s 0100 then decryption was successful :-)
    12. Extract decrypted package from wireshark dump and inflate it
    graf_chokolo says:

    I’m from Germany, Stuttgart
    graf_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.

    1st method:
    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

    2nd method:

    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 reverse
    graf_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 rights
    graf_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 things
    graf_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 018 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 analyze
    graf_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.
    Dump2_HVDump_v0.3.1.5.bin: http://www.mediafire.com/?95cr4ybtpyq8rc3

  6. #16
    tjay17 Guest
    I wonder if this can be used to decrypt some eboots ?

  7. #17
    Join Date
    Apr 2005


    Some more comments from graf_chokolo and xorloser: http://xorloser.com/?p=297&cpage=7#comment-1710
    graf_chokolo says:

    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.

    xorloser says:

    that is how a packet id is commonly used, like a counter. it ensures each packet has a unique id.

    graf_chokolo says:

    No, packet_id is something diffrent in DM, it’s not request id.

    graf_chokolo says:

    Look for string “_USB_DONGLE_AUTH_USB_DONGLE_” in the dump In HV 3.15, the master key is before this string

    graf_chokolo says:

    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

    graf_chokolo says:

    I have got my 1st fat PS3 with HV 3.15. Let the fun begin, guys

    graf_chokolo says:

    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

    graf_chokolo says:

    Sorry, still waiting for my SX28 devboard I have got now 2 fat PS3 with 3.15 but no hardware to exploit it yet

    graf_chokolo says:

    In the mean time i’m working on self decryption

    graf_chokolo says:

    Look at function at address 000297640 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

    graf_chokolo says:

    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

Page 2 of 2 First 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Log in