Downgrading with linux: Difference between revisions
(proper linque) |
mNo edit summary |
||
Line 102: | Line 102: | ||
'''To install debug firmware, EID0 (and EID5?) should be reencrypted and rehashed with the proper [[Target ID]] and [[ | '''To install debug firmware, EID0 (and EID5?) should be reencrypted and rehashed with the proper [[Target ID]] and [[DeviceID]]/type''' | ||
Line 115: | Line 115: | ||
*Per ps3 values (console id, psid...) | *Per ps3 values (console id, psid...) | ||
"The kernel and most of the loaders check the [[Target ID]] as well as the [[ | "The kernel and most of the loaders check the [[Target ID]] as well as the [[DeviceID]]/type to see if your unit is debug or not and if not they disable all the fancy things such as running unsigned code (in the case of appldr). | ||
* a good read about SC http://rmscrypt.wordpress.com/2011/02/01/lets-look-at-syscon/ | * a good read about SC http://rmscrypt.wordpress.com/2011/02/01/lets-look-at-syscon/ |
Revision as of 01:16, 31 December 2011
You should have grafchokolos modules, and patches installed
This works on 3.55 without a physical dongle
Use this method to install lower firmware! You can install a newer firmware ex 3.60 with this method but you will be loosing your homebrew
Thanks to graf_chokolo for bringing linux, with all this goodies back to the PS3
Downgrade Method - Emulating JIG with Linux
1st step – Generating a challenge
- ps3dm_usb_dongle_auth /dev/ps3dmproxy gen_challenge
2nd step – Generating a valid response for a challenge
You need a dongle id. Valid range for dongle IDs is 0×0000 – 0xffff. So choose one, doesn’t matter which one, but some are revoked !!!
- ps3dm_usb_dongle_auth /dev/ps3dmproxy gen_resp 0xBABE “here is a challenge like this 0xXX 0xXX … of size 20 bytes”
3rd step – Verifying response (Enabling “Product Mode”)
- ps3dm_usb_dongle_auth /dev/ps3dmproxy verify_resp 0xBABE
“here is the response from step 2 like this 0xXX 0xXX … of size 20 bytes”
4th step – Checking if “Product Mode” is enabled
The returned value shouldn’t be 0xff.
- ps3dm_um /dev/ps3dmproxy read_eprom 0x48C07
5th step - Inspect if CORE_OS_PACKAGE.pkg isn't damaged
ps3dm_um /dev/ps3dmproxy inspect_pkg 1 0x9 CORE_OS_PACKAGE.pkg
6th step - Install CORE_OS_PACKAGE.pkg
ps3dm_um /dev/ps3dmproxy update_pkg 1 0x9 CORE_OS_PACKAGE.pkg
7th step – Disabling “Product Mode”
- ps3dm_um /dev/ps3dmproxy write_eprom 0x48C07 0xff
This step is really important, if Product Mode isn't disabled you will need a dongle to get out of it
ALTERNATIVE METHOD - not tested
1st step – Enabling product mode
- ps3dm_um /dev/ps3dmproxy write_eprom 0x48C07 0xfe
2th step – Checking if “Product Mode” is enabled
The returned value shouldn’t be 0xff.
- ps3dm_um /dev/ps3dmproxy read_eprom 0x48C07
3th step - Inspect if CORE_OS_PACKAGE.pkg isn´t damaged
ps3dm_um /dev/ps3dmproxy inspect_pkg 1 0x9 CORE_OS_PACKAGE.pkg
4th step - Install CORE_OS_PACKAGE.pkg
ps3dm_um /dev/ps3dmproxy update_pkg 1 0x9 CORE_OS_PACKAGE.pkg
5th step – Disabling “Product Mode”
- ps3dm_um /dev/ps3dmproxy write_eprom 0x48C07 0xff
This step is really important, if Product Mode isn´t disabled you will need a dongle to get out of it
Install debug firmware
High brick risk! Don´t try this if you don´t know what you are doing
If you brick with this the only way to recover is Hardware flashing the prior to conversion made dump back to the NAND/NOR flash
To install debug firmware, EID0 (and EID5?) should be reencrypted and rehashed with the proper Target ID and DeviceID/type
Debugging Station Target ID: 0x82
eEID contains
- system model data
- target ID
- PS3 motherboard revision
- Per ps3 values (console id, psid...)
"The kernel and most of the loaders check the Target ID as well as the DeviceID/type to see if your unit is debug or not and if not they disable all the fancy things such as running unsigned code (in the case of appldr).
- a good read about SC http://rmscrypt.wordpress.com/2011/02/01/lets-look-at-syscon/