Sponsored Links

Sponsored Links

Page 29 of 87 FirstFirst ... 1927282930313979 ... LastLast
Results 281 to 290 of 861

  1. #281
    Senior Member Ezio's Avatar
    Join Date
    Aug 2011
    Sponsored Links
    Sponsored Links
    Bartholomy +Rep from me, too.

    HeyManHRU, I think the list will always be longer because Indonesian guys have probably found an exploit for fw 3.60+ so they can fix all new games.

  2. #282
    Senior Member HeyManHRU's Avatar
    Join Date
    Dec 2010
    Sponsored Links
    Sponsored Links
    These guys must be making lots of money , I reckon they could have easily released a 3.60+ CFW but they wanted to make some $$$ out of it too.

    Either way, it's good to see a way to play 3.60+ games.

  3. #283
    Senior Member GotNoUsername's Avatar
    Join Date
    Feb 2007
    Sponsored Links
    Sponsored Links
    Does anyone know if there is a RE Project to make their trick usable on CFW ? We have a lot a RE Info but still lack any use for the end user ....

  4. #284
    Registered User chrisdu06's Avatar
    Join Date
    Sep 2010
    i think it's a fake

  5. #285
    Banned User CS67700's Avatar
    Join Date
    Oct 2011
    It is NOT fake, some trusted scene users got their hands on it, and it does boot 3.6+ games.

    As for the 3.7+, needs to be verified.

  6. #286
    Contributor TDMaster's Avatar
    Join Date
    Nov 2009

    PS3 JB2 Dongle Called True Blue, Official Features Now Confirmed

    Following up on the PS3 JB2 Reverse-Engineering news, today Gary Wayne Bowser (aka GaryOPA) has confirmed that the official name of the JailBreak 2 USB dongle will be True Blue.

    A list of supported PlayStation 3 games is outlined HERE, and below are the details, to quote: "The actual name of the JB2 dongle has now been announced along with official confirmed features and specs:

    Welcome to the era of True Blue for your PS3 which enables all your Jailbreak dreams and needs!

    True Blue features:
    • Booting of games from v3.6+ (up to v3.73) from special BD-R discs available from official resellers
    • Runs games up to v3.56 from HDD in conjunction with backup managers
    • Does not require the Power/Eject trick
    • Custom v3.55 Dongle firmware behaves like OFW when True Blue is not inserted
    • Manufactured from highest grade components and Actel based
    • Durable and high quality metal case design
    • Tough and durable plastic packaging
    • Further features to be added as they are developed
    • On board 2 MBytes SPI flash
    • Supports Fat and Slim consoles currently running any firmware up to v3.55
    • And any PS3 which can be downgraded from v3.6+ to v3.55 (NOTE: Requires other tools, True Blue currently can't downgrade a Console)
    • Supports all regions of consoles
    • Supports all regions of ISO’s to be released
    • Rock solid crystal oscillator on board for flawless timing

    The True Blue dongle allows booting of the latest the ISO’s (3.6+) from special BD-R discs which can be purchased from all official resellers. The discs can be burned by any BD-R recorder and there are no special requirements on either PC or BD burner types.

    Whilst we can disclose that the discs are specially manufactured to allow booting of the latest ISO’s, further technical information on the way by which the BD-R discs can allow booting cannot be provided, for obvious reasons.

    Update: Clearer note on the above info, in regard to questions being asked!

    The special BD-R discs being SOLD are BLANK, they are not warez in some cases less shady modshops operating in countries like Asia were local law enforcement turn a blind eye to 'flea market' operators they may infact FILL the disc with information turning the blank disc into warez, but that is not fault of the True Blue designers, and those places will NOT be official resellers. Information and pricing and list of official resellers will be forcoming in new news post later this week once details are confirmed.

    Second, there is a lot more games working then the 5 listed in the forums and emails from the original JB2 rumors, and the full list of all the tested games will be published once it is official and confirmed by us, don't trust other sources of information there a lot of people out there trolling and passing around mis-information still for various reasons.

    Third, even tho there is effort to crack this dongle already even tho it is not in the actual hands of any of the people posting information about it, there is a lot of stuff unknown about how and why it works and for many reasons we can't give further technical information but there is KEY reason why you have to buy special BLANK BD-R discs, due to some background research on the Blu-ray specs and maybe you understand why this is only way to get your dreams filled on running the latest v3.60+ games on your PS3 correctly!"

    Sony PlayStation 3 hacker [Register or Login to view links] states the following on the PS3 JB2 USB dongle device to quote:

    "They actually do encrypt the elf data sections on the fself and have fself + decryption support handled in lv2 but part of the routine is decrypted through the dongle, it'd be possible to dump it from ram, but honestly, I don't own a dongle and I am not interested."

    Below are some PS3 JB2 / True Blue in-depth testing demo videos from leksetengah:

    There are 3 Element in JB2:

    1. Dongle-FW (3.55)
    2. USB Dongle JB2
    3. Burning Game (which being Modified)

    In order to play game you need all of 3 element above, can't work if one is missing.

    PS3 Backup game can't work without JB2 dongle

    First thing is update your PS3 with Dongle-FW. In this video i show that after Update PS3 with Dongle-FW you CAN'T PLAY any backup game without JB2 dongle.

    Backup PS3 game works with JB2 dongle

    In this video i show that after Update PS3 with Dongle-FW you CAN Play any backup game WITH JB2 dongle.

    Playing burned PS3 disc without JB2 dongle

    Note: Burning game also have cover and label disc but made with printed sticker. PS3 cannot play burning game (3.55 above) without JB2 dongle. XMB and Multiman can not detect the burning game. PS3 cannot play Original game (3.55 above) without JB2 dongle. Update software needed, you Know what happen next if you update, don't you?

    Playing Burning Game with JB2 dongle

    PS3 can play burning dan modified game (3.55 above) with JB2 dongle. XMB and Multiman can not detect the burning game. But multiman can not backup burning game, also file manager multiman can't open root of Burning game.. same result with comgenie, after press start to copy nothing is happened.

    PS3 cannot play Original game (3.55 above) with JB2 dongle. Update software needed, you Know what happen next if you update, don't you? Backup original game in multiman is no problem.

    Finally, to quote from PlayStation 3 developer [Register or Login to view links] on the PS3 True Blue USB device: "Appears to be pretty simple. Apparently the dongle itself is just DRM so I would expect this to be completely cloned in software. Don't bother wasting your money on these."

    PS3 JB2 Dongle Called True Blue, Official Features Now Confirmed

    More PlayStation 3 News...

  7. #287
    Senior Member cfwprophet's Avatar
    Join Date
    Jul 2008
    We can't press disks by our own. To get license to make pressed disks is very hard. And simply ordering some pressed disks with some data one it is not cheap. For our private use we only can buy burners not presses. But if you today buy a CD it will looks like a pressed one but have to be burned. So i think it has something to do with the chemical liquid inside the layers.

  8. #288
    Registered User Score12's Avatar
    Join Date
    Oct 2011

    Details and Payloads for Dumping PS3 Per Console Keys Surface

    PlayStation 3 developers have been busy recently working on payloads for dumping the PS3 per console keys, as once the per_console_key_0 is obtained with full EID decryption dongles and burned BR-D's may be a thing of the past.

    Below are details from sphinxkoma and the PS3 Wiki (ps3devwiki.com/index.php?title=Talk:Per_Console_Keys) on dumping the per_console_key_1 via Kaz... it's only a matter of time for per_console_key_0 which unlocks everything we need.

    To quote: PS3 Per Console Keys

    EID crypto is very complicated, it is done so on purpose. first of all EID0 isn't decrypted with one key, and one algorithm alone. it is decrypted in several parts which use different algos and keys. the keys are all derivations of a per console key (per_console_key_1) which is stored inside metldr and copied by it to sector 0 and never leaves isolation. that same key is a derivation of the per console key (per_console_key_0) used to encrypt metldr and the bl in the first place as well.

    isoldr clears that key from sector 0 before jumping to the isolated module. but before doing so it encrypts it with another keyset and stores it in a buffer so that the isolated module can use the new crafted key. since the operation is AES, if you know that keyset you can decrypt the crafted key and get the eid root key without pwning a loader or metldr through an isolated module.

    that is not like you really need it because you can already use the crafted key to decrypt some of eid0, but not all of it. and the crafted key also uses the first elf section to be built as in your isolated module will have a small section which only contains a key. and that key is used as another layer by isoldr to encrypt the buffer with it. so basically you have 2 encryption layers over the root key. the final key then decrypts a specific part of the EID.

    eid crypto is actually done smart. that is because most of it originally comes from the cell bootrom, as in they reuse the same algo used for metldr binaries and bl in the eid crypto, including some of the keys and the steps. and you cannot decrypt all of the eid sections unless you gathered every single keys and steps. and there are a lot then you still have to figure out wtf it is you decrypted because eid is actually full of keys.

    1. payloader3 create new possible source of or precompiled:

    payloader3-341.pkg: [Register or Login to view links]
    payloader3-315.pkg: [Register or Login to view links]

    2. Install payloader3 pkg on the ps3

    3. export in the terminal set
    a. export PS3LOAD = tcp: ipaddress.of.ps3
    b. start socat (socat tcp-recv: 18194 stdout)

    4. payloader3 pkg start on ps3

    5. It is quite likely to see is not the picture (black screen) but you will hear a distinct sound (like C64) Now things are different feasible:

    a. X 4eck then starts with ps3load ethdebug
    b. then you will want to circle back to the xmb and invites ethdebug (for Debuging pkg files)

    6. Use your ps3load the mode used to send your ps3 dump_eid_root_key.self (ps3load dump_eid_root_key.self) Now you should see debug Terminal in your debugging and then hopefully you'll find the PCK .. (theoretically)

    The per console key is used to derive other keys, some of which Sony can't change as this appears to be the bottom of their encryption chain. It's also important to note that this method is intended for dumping per_console_key_1 and per_console_key_n while per_console_key_0 is currently still required.

    However to speculate, in future PS3 CFW updates users may need to be on a Custom Firmware to begin with (or downgrade to one first) and then run a .PKG to get their per console encryption key, followed by using it in a PS3 MFW Builder and installing the resulting modified PS3 Firmware on their PlayStation 3 console.

    From ps3devwiki.com/index.php?title=Per_Console_Keys#per_console_root_ key_0:
    • metldr is decrypted with this key
    • bootldr is decrypted with this key
    • might be obtained with per_console_root_key_1? (largely speculative, not nec. true - need more looked into, only based on the behavior of the other derivatives known to be obtained through AES)

    Finally, from the PlayStation 3 Wiki (ps3devwiki.com/index.php?title=Per_Console_Keys and ps3devwiki.com/index.php?title=Boot_Order#Chain_of_Trust for the PS3 boot order) pages:

    Per Console Keys

    • metldr is decrypted with this key
    • bootldr is decrypted with this key
    • might be obtained with per_console_root_key_1? (largely speculative, not nec. true - need more looked into, only based on the behavior of the other derivatives known to be obtained through AES)

    per_console_root_key_1 / EID_root_key
    • derived from per_console_key_0
    • stored inside metldr
    • copied to sector 0 by metldr
    • cleared by isoldr
    • Used to decrypt part of the EID
    • Used to derive further keys
    • can be obtained with a modified isoldr that dumps it
    • can be obtained with a derivation of this key going backwards

    obtaining it

    launch the patched isoldr with your prefered method

    Option 1 - dumper kernel module
    • modify glevands spp_verifier_direct to dump the mbox to wherever_you_want and then (use the payload below as an example)
    • the example code on how to dump the mbox can be found on the Option 2 - dumper payload below
    insmod ./spp_verifier_direct.ko
    cat metldr > /proc/spp_verifier_direct/metldr
    cat isoldr_PATCHED > /proc/spp_verifier_direct/isoldr
    echo 1 > /proc/spp_verifier_direct/run
    cat /proc/spp_verifier_direct/debug
    cat /proc/spp_verifier_direct/wherever_you_want
    Option 2 - dumper payload

    [Register or Login to view links]
    #include <stdio.h>
    #include <stdlib.h>
    #include <unistd.h>
    #include "types.h"
    #include "netrpc.h"
    #include "lv1.h"
    #include "spu.h"
    #include "mm.h"
    #include "util.h"
    #define PS3HOST ""
    u8 *_read_file(const char *name, u32 *size)
    	u8 *buf;
    	u32 len;
    	FILE *fp;
    	if((fp = fopen(name, "rb")) == NULL)
    		printf("could not open %s\n", name);
    		return NULL;
    	//Read into buffer.
    	fseek(fp, 0, SEEK_END);
    	len = ftell(fp);
    	fseek(fp, 0, SEEK_SET);
    	buf = (u8 *)malloc(sizeof(u8) * len);
    	fread(buf, sizeof(u8), len, fp);
    	//Set buffer size.
    	if(size != NULL)
    		*size = len;
    	return buf;
    u64 _vas_get_id(netrpc_ctxt_t *ctxt)
    	u64 id;
    	netrpc_hvcall(ctxt, _N_lv1_get_logical_ppe_id, NULL, 0, &id, 1);
    	netrpc_hvcall(ctxt, _N_lv1_get_virtual_address_space_id_of_ppe, &id, 1, &id, 1);
    	return id;
    s64 _get_spe_intr_status(netrpc_ctxt_t *ctxt, u64 spe_id, u64 cls, u64 *stat)
    	u64 args[] = {spe_id, cls};
    	return netrpc_hvcall(ctxt, _N_lv1_get_spe_interrupt_status, args, 2, stat, 1);
    s64 _clr_spe_intr_status(netrpc_ctxt_t *ctxt, u64 spe_id, u64 cls, u64 stat)
    	u64 args[] = {spe_id, cls, stat, 0};
    	return netrpc_hvcall(ctxt, _N_lv1_clear_spe_interrupt_status, args, 4, NULL, 0);
    #define LDR_BASE 0x100000
    #define LDR_SIZE 0x2300000
    #define METLDR_SIZE 0x100000
    #define ISOLDR_SIZE 0x100000
    #define SPU_SHADOW_SIZE 0x1000
    #define SPU_PROBLEM_SIZE 0x20000
    #define SPU_PRIV2_SIZE 0x20000
    #define SPU_LS_SIZE 0x40000
    //static volatile u64 ldr_lpar_addr = 0x700020000000ULL + 0xE900000ULL - LDR_SIZE;
    static u64 esid = 0x8000000018000000;
    static u64 vsid = 0x0000000000001400;
    int main(int argc, char **argv)
    	netrpc_ctxt_t ctxt;
    	s64 res;
    	if(netrpc_connect(&ctxt, inet_addr(PS3HOST), NETRPC_PORT) < 0)
    		return 1;
    	if(netrpc_ping(&ctxt) < 0)
    		return 1;
    	//Get vas id.
    	u64 vas_id = _vas_get_id(&ctxt);
    	//File adresses.
    	u64 metldr_addr, isoldr_addr;
    	metldr_addr = LDR_BASE;
    	isoldr_addr = metldr_addr + METLDR_SIZE;
    	//Map region.
    	//res = mm_map_lpar_memory_region(&ctxt, vas_id, MM_EA2VA(metldr_addr), LDR_BASE /*ldr_lpar_addr*/, LDR_SIZE, 0xC, 0, 0);
    	//printf("map_lpar_memory_region : %lld\n", res);
    	netrpc_addmmio(&ctxt, LDR_BASE, LDR_SIZE);
    	printf("copy files out...");
    	//Read files.
    	u32 metldr_size;
    	u8 *metldr = _read_file("./data/metldr", &metldr_size);
    	u32 isoldr_size;
    	u8 *isoldr = _read_file("./data/isoldr", &isoldr_size);
    	//u8 *isoldr = _read_file("./data/isoldr_patched", &isoldr_size);
    	//Copy files out.
    	netrpc_memcpy_out(&ctxt, metldr_addr, metldr, metldr_size);
    	netrpc_memcpy_out(&ctxt, isoldr_addr, isoldr, isoldr_size);
    	printf("construct spe...");
    	//Construct SPE.
    	u64 cspe_args[] = {0xc, 0xc, 0xc, 0xc, 0xc, vas_id, 0};
    	u64 cspe_res[] = {0, 0, 0, 0, 0, 0};
    	netrpc_hvcall(&ctxt, _N_lv1_construct_logical_spe, cspe_args, 7, cspe_res, 6);
    	//SPE info.
    	u64 priv2_addr, problem_addr, ls_addr, shadow_addr, spe_id;
    	priv2_addr = cspe_res[0];
    	problem_addr = cspe_res[1];
    	ls_addr = cspe_res[2];
    	shadow_addr = cspe_res[4];
    	spe_id = cspe_res[5];
    	netrpc_addmmio(&ctxt, priv2_addr, SPU_PRIV2_SIZE);
    	netrpc_addmmio(&ctxt, problem_addr, SPU_PROBLEM_SIZE);
    	netrpc_addmmio(&ctxt, shadow_addr, SPU_SHADOW_SIZE);
    	netrpc_addmmio(&ctxt, ls_addr, SPU_LS_SIZE);
    	printf("done\n  priv2 @ 0x%016llx\n  problem @ 0x%016llx\n  ls @ 0x%016llx\n  shadow @ 0x%016llx\n  id : 0x%016llx\n",
    		priv2_addr, problem_addr, ls_addr, shadow_addr, spe_id);
    	printf("setup spe...");
    	//Setup SPE.
    	u64 setup_spe_args[] = {spe_id, 0, 0};
    	setup_spe_args[1] = 6;
    	netrpc_hvcall(&ctxt, _N_lv1_enable_logical_spe, setup_spe_args, 2, NULL, 0);
    	setup_spe_args[1] = 0;
    	setup_spe_args[2] = 0x7;
    	netrpc_hvcall(&ctxt, _N_lv1_set_spe_interrupt_mask, setup_spe_args, 3, NULL, 0);
    	setup_spe_args[1] = 1;
    	setup_spe_args[2] = 0xf;
    	netrpc_hvcall(&ctxt, _N_lv1_set_spe_interrupt_mask, setup_spe_args, 3, NULL, 0);
    	setup_spe_args[1] = 2;
    	setup_spe_args[2] = 0xf;
    	netrpc_hvcall(&ctxt, _N_lv1_set_spe_interrupt_mask, setup_spe_args, 3, NULL, 0);
    	u64 set_reg_args[] = {spe_id, _OFFSET_MFC_SR1, 0x10};
    	res = netrpc_hvcall(&ctxt, _N_lv1_set_spe_privilege_state_area_1_register, set_reg_args, 3, NULL, 0);
    	printf("set_spe_privilege_state_area_1_register : %lld\n", res);
    	printf("start spe in isolation mode...");
    	spu_slb_invalidate_all(&ctxt, priv2_addr);
    	spu_slb_set_entry(&ctxt, priv2_addr, 0, esid, vsid);
    	write_u64(&ctxt, SPU_RADDR(priv2_addr, _OFFSET_SPU_Cfg), 0);
    	spu_in_mbox_write_64(&ctxt, problem_addr, isoldr_addr);
    	spu_sig_notify_1_2_write_64(&ctxt, problem_addr, metldr_addr);
    	spu_isolation_req_enable(&ctxt, priv2_addr);
    	spu_isolation_req(&ctxt, problem_addr);
    	FILE *fp = fopen("ls.bin", "wb");
    	u32 spu_status, size = 0;
    	u64 intr_status;
    		res = _get_spe_intr_status(&ctxt, spe_id, 0, &intr_status);
    			printf("intr_status (0) : %016llx\n", intr_status);
    			printf("clear_intr_status : %lld\n", _clr_spe_intr_status(&ctxt, spe_id, 0, intr_status));
    		res = _get_spe_intr_status(&ctxt, spe_id, 1, &intr_status);
    			printf("intr_status (1) : %016llx\n", intr_status);
    			printf("clear_intr_status : %lld\n", _clr_spe_intr_status(&ctxt, spe_id, 1, intr_status));
    		res = _get_spe_intr_status(&ctxt, spe_id, 2, &intr_status);
    		if(intr_status & 0x1)
    			printf("mailbox interrupt\n");
    			printf("intr_status (2) : %016llx\n", intr_status);
    			printf("clear_intr_status : %lld\n", _clr_spe_intr_status(&ctxt, spe_id, 2, intr_status));
    		while(size <= 0x40000)
    			//Wait for mbox value to be written.
    			while(spu_mbox_stat_out_mbox_count(&ctxt, problem_addr) == 0);
    			//Read mbox value.
    			u32 mbox_value;
    			read_u32(&ctxt, SPU_RADDR(problem_addr, _OFFSET_SPU_Out_Mbox), &mbox_value);
    			//Write to file.
    			fwrite(&mbox_value, sizeof(u32), 1, fp);
    			size += 4;
    			printf("\rdumped 0x%08x of 0x40000", size);
    		read_u32(&ctxt, SPU_RADDR(problem_addr, _OFFSET_SPU_Status), &spu_status);
    		if((spu_status & 0x1) == 0)
    	printf("spu_status: 0x%08x\n", spu_status);
    	return 0;
    • patched isoldr to dump it
    • patched isoldr: [Register or Login to view links]
    • this can be loaded as the payload stage2 in the payload marcan used to load linux
    • [Register or Login to view links]
    • [Register or Login to view links]
    • this can also be loaded as with lv2patcher and payloader3
    • [Register or Login to view links]

    • What this selfs do is dump your ISOLATED SPU LS through your mbox, so you only need a way to cach this info with PPU code in lv2 enviroment aka a dongle payload or linux kernel
    • This has been tested and proven to work on 3.55 MFW
    • In the dump the remaining dump is the metldr clear code. metldr clears itself and all the registers an jumps to isoldr.
    • Overwriting that code lets you dump your key + metldr
    • Consider that per_console_key_1 and per_console_key_n are in fact still in need decryption.
    • per_console_key_0 particularly needs to be dumped once revived from per_console_key_1.

    per_console_root_key_2 / EID0_key
    • this key can be obtained through AES from EID_root_key
    • EID can be partially decrypted by setting this key in anergistics and fireing aim_spu_module.self
    • Load aim_spu_module.self + EID0 + EID0_key in anegistics = decrypted EID0
    • This code is to decrypt your EID0 on your PC [Register or Login to view links]
      ## channel.h
      //Add this defines.
      //SPU channels.
      #define SPU_RdEventStat 0
      #define SPU_WrEventMask 1
      #define SPU_WrEventAck 2
      #define SPU_RdSigNotify1 3
      #define SPU_RdSigNotify2 4
      #define SPU_WrDec 7
      #define SPU_RdDec 8
      #define SPU_RdEventMask 11
      #define SPU_RdMachStat 13
      #define SPU_WrSRR0 14
      #define SPU_RdSRR0 15
      #define SPU_WrOutMbox 28
      #define SPU_RdInMbox 29
      #define SPU_WrOutIntrMbox 30
      //MFC channels.
      #define MFC_WrMSSyncReq 9
      #define MFC_RdTagMask 12
      #define MFC_LSA 16
      #define MFC_EAH 17
      #define MFC_EAL 18
      #define MFC_Size 19
      #define MFC_TagID 20
      #define MFC_Cmd 21
      #define MFC_WrTagMask 22
      #define MFC_WrTagUpdate 23
      #define MFC_RdTagStat 24
      #define MFC_RdListStallStat 25
      #define MFC_WrListStallAck 26
      #define MFC_RdAtomicStat 27
      //MFC DMA commands.
      #define MFC_PUT_CMD 0x20
      #define MFC_GET_CMD 0x40
      //MFC tag update commands.
      #define MFC_TAG_UPDATE_ANY 1
      #define MFC_TAG_UPDATE_ALL 2
      ## channel.c
      // Copyright 2010 fail0verflow <master@fail0verflow.com>
      // Licensed under the terms of the GNU GPL, version 2
      // http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt
      #include <stdio.h>
      #include <string.h>
      #include <stdarg.h>
      #include <stdlib.h>
      #include <unistd.h>
      #include "types.h"
      #include "main.h"
      #include "config.h"
      #include "channel.h"
      //Channel names.
      static char *ch_names[] = 
      	"SPU_RdEventStat", //0
      	"SPU_WrEventMask", //1
      	"SPU_WrEventAck", //2
      	"SPU_RdSigNotify1", //3
      	"SPU_RdSigNotify2", //4
      	"UNKNOWN", //5
      	"UNKNOWN", //6
      	"SPU_WrDec", //7
      	"SPU_RdDec", //8
      	"MFC_WrMSSyncReq", //9
      	"UNKNOWN", //10
      	"SPU_RdEventMask", //11
      	"MFC_RdTagMask", //12
      	"SPU_RdMachStat", //13
      	"SPU_WrSRR0", //14
      	"SPU_RdSRR0", //15
      	"MFC_LSA", //16
      	"MFC_EAH", //17
      	"MFC_EAL", //18
      	"MFC_Size ", //19
      	"MFC_TagID", //20
      	"MFC_Cmd", //21
      	"MFC_WrTagMask", //22
      	"MFC_WrTagUpdate", //23
      	"MFC_RdTagStat", //24
      	"MFC_RdListStallStat", //25
      	"MFC_WrListStallAck", //26
      	"MFC_RdAtomicStat", //27
      	"SPU_WrOutMbox", //28
      	"SPU_RdInMbox", //29
      	"SPU_WrOutIntrMbox" //30
      //MFC channel values.
      static u32 _MFC_LSA;
      static u32 _MFC_EAH;
      static u32 _MFC_EAL;
      static u32 _MFC_Size;
      static u32 _MFC_TagID;
      static u32 _MFC_TagMask;
      static u32 _MFC_TagStat;
      //Endian swap.
      #define _BE(val) ((((val) & 0xff00000000000000ull) >> 56) | \
                        (((val) & 0x00ff000000000000ull) >> 40) | \
                        (((val) & 0x0000ff0000000000ull) >> 24) | \
                        (((val) & 0x000000ff00000000ull) >> 8 ) | \
                        (((val) & 0x00000000ff000000ull) << 8 ) | \
                        (((val) & 0x0000000000ff0000ull) << 24) | \
                        (((val) & 0x000000000000ff00ull) << 40) | \
                        (((val) & 0x00000000000000ffull) << 56))
      void handle_mfc_command(u32 cmd)
      	printf("Local address %08x, EA = %08x:%08x, Size=%08x, TagID=%08x, Cmd=%08x\n",
      		_MFC_LSA, _MFC_EAH, _MFC_EAL, _MFC_Size, _MFC_TagID, cmd);
      #ifdef DEBUG_CHANNEL
      	switch (cmd)
      	case MFC_PUT_CMD:
      		printf("MFC_PUT (DMA out of LS)\n");
      			FILE *fp = fopen("out.bin", "a+");
      			fwrite(ctx->ls + _MFC_LSA, sizeof(u8), _MFC_Size, fp);
      	case MFC_GET_CMD:
      		printf("MFC_GET (DMA into LS)\n");
      			static int round = 0;
      			                         //module debug output address, set both to 0x0 for none
      			static u64 data0[2] = {_BE(0xbeef0110dead0000), _BE(0xbeef0220dead0000)};
      			static u64 data1[4] = {_BE(0xbeef0110dead0000), _BE(0xbeef0220dead0000), 
      			                       _BE(0x0000000200000000), _BE(0x0000000000000000)};
      			                                  //^-- 1,2,3,4 (device type/id, pscode, psid)
      			if(round == 0)
      				memcpy(ctx->ls + _MFC_LSA, &data0, _MFC_Size);
      			else if(round == 1)
      				memcpy(ctx->ls + _MFC_LSA, &data1, _MFC_Size);
      			else if(round == 2)
      				//Load EID0.
      				printf("loading eid...");
      				FILE *fp = fopen("EID0", "rb");
      				fread(ctx->ls + _MFC_LSA, sizeof(u8), _MFC_Size, fp);
      		printf("unknown command\n");
      void handle_mfc_tag_update(u32 tag)
      	switch (tag)
      		printf("-> MFC_TAG_UPDATE_IMMEDIATE\n");
      		_MFC_TagStat = _MFC_TagMask;
      	case MFC_TAG_UPDATE_ANY:
      		printf("-> MFC_TAG_UPDATE_ANY\n");
      	case MFC_TAG_UPDATE_ALL:
      		printf("-> MFC_TAG_UPDATE_ALL\n");
      		printf("-> UNKNOWN\n");
      	_MFC_TagStat = _MFC_TagMask;
      void channel_wrch(int ch, int reg)
      	u32 r = ctx->reg[reg][0];
      	printf("CHANNEL: wrch ch%d(= %s) r%d(= 0x%08x)\n", ch, (ch <= 30 ? ch_names[ch] : "UNKNOWN"), reg, r);
      #ifdef DEBUG_CHANNEL
      	case MFC_LSA:
      		_MFC_LSA = r;
      	case MFC_EAH:
      		_MFC_EAH = r;
      	case MFC_EAL:
      		_MFC_EAL = r;
      	case MFC_Size:
      		_MFC_Size = r;
      	case MFC_TagID:
      		_MFC_TagID = r;
      	case MFC_Cmd:
      	case MFC_WrTagMask:
      		_MFC_TagMask = r;
      	case MFC_WrTagUpdate:
      void channel_rdch(int ch, int reg)
      	u32 r = 0;
      	printf("CHANNEL: rdch ch%d(= %s) r%d\n", ch, (ch <= 30 ? ch_names[ch] : "UNKNOWN"), reg);
      #ifdef DEBUG_CHANNEL
      	switch (ch)
      	case SPU_RdDec:
      	case MFC_RdTagStat:
      		r = _MFC_TagStat;
      	case MFC_RdAtomicStat:
      	//Set register.
      	ctx->reg[reg][0] = r;
      	ctx->reg[reg][1] = 0;
      	ctx->reg[reg][2] = 0;
      	ctx->reg[reg][3] = 0;
      int channel_rchcnt(int ch)
      	u32 r = 0;
      	printf("CHANNEL: rchcnt ch%d(%s)\n", ch, (ch <= 30 ? ch_names[ch] : "UNKNOWN"));
      #ifdef DEBUG_CHANNEL
      	switch (ch)
      	case MFC_WrTagUpdate:
      		r = 1;
      	case MFC_RdTagStat:
      		r = 1;
      	case MFC_RdAtomicStat:
      	return r;
      ## main.c
      int main(int argc, char *argv[])
      	u32 done;
      	memset(&_ctx, 0x00, sizeof _ctx);
      	ctx = &_ctx;
      	parse_args(argc, argv);
      	//Remove old output.
      	system("rm -f out.bin");	
      	//Set module parameters.
      	//PU DMA area start address.
      	//Dummy to make the module happy.
      	ctx->reg[3][0] = 0xdead0000;
      	ctx->reg[3][1] = 0xbeef0000;
      	//PU DMA area size.
      	//ctx->reg[4][0] = 0x80;
      	ctx->reg[4][1] = 0x80;
      	//PU EID area start address (first param).
      	//Dummy to make the module happy.	
      	ctx->reg[5][0] = 0xcafe0000;
      	ctx->reg[5][1] = 0xbabe0000;
      	//First param size.
      	//ctx->reg[6][0] = 0x860;
      	ctx->reg[6][1] = 0x860;
      	ctx->ls = malloc(LS_SIZE);
      	if (ctx->ls == NULL)
      		fail("Unable to allocate local storage.");
      	memset(ctx->ls, 0, LS_SIZE);
      	//Write EID master key (to start of LS).
      	u8 eid_mkey[] = {/* ... */};
      	memcpy(ctx->ls, eid_mkey, sizeof(eid_mkey));
    • The prerequisites are:
    • dump your EID0 from your ps3 and save it in the same folder as EID0
    • dump your EID0_key from your ps3 and put it on the code above where the key is needed
    • load all of them in anergistic
    • EID0_key could also be obtained with EID_root_key directly in the following manners:
    • knowing the algorithm (located in isoldr)and applying it to the EID_root_key
    • letting isoldr apply that algorithm directly in anergistic
    • the process is exactly as the one above (modifing anergistic to feed isoldr with EID_root_key

    obtaining it
    • patched aim_spu_module to dump it
    • [Register or Login to view links]

    • these are further derivations of the per_console_key_1/EID_root_key

    • polarssl.org/trac/browser/trunk/library/aes.c

    From VenomousX: How to obtain this EID_root_key?
    • Patch isoldr to dump the local storage of sector 0
    • Load the patched isoldr
    • Dump the local storage
    • You will find eid_root_key
    • Use it to decrypt the eid0.

    How to load back the isoldr:
    • Use glevand's tools, spp_verifier_direct to be specific: "spp_verifier_direct is a kernel module which shows you how to run isolated SPE modules on OtherOS++ Linux by using metldr directly.
    • It decrypts default.spp profile.
    • Once you get the eid rootkey, load aim_spu_module.self with eid0 and the eid root key within anergistics it will decrypt it.
    • You can modify it easily to run other SPE modules.
    • Has been done and tested on 3.41 and 3.55 (not by myself)

    So yes, you can obtain the eid rootkey and partially decrypt the eid0, but the problem if you want to modify the eid0 (say... to get a DEX idps to convert CEX=>DEX (which doesnt have much got use for end-users, only devs)) then you'd need to re-encrypt the EID0, which you can't. Not with those keys at least.

    Oh, and while PS3 rootkeys are per console, and usually FW independent. However I dont know about 3.6+ because I didn't test it on it. But it might be true that 3.6+ eid rootkey have changed since $ony changed a load of keys with 3.6+. So using the 3.55 eid_root_key on 3.6+ to decrypt anything probably wont work.

    Sony PlayStation 3 hacker [Register or Login to view links] states the following on this via Twitter: "There are 3 per console keys. it tells you how to obtain 2 (per console key 1 and per console key n) not THE root key. It will not lead to a new CFW, it is fun for devs, you can decrypt a lot of eid and reverse it.. it is not newb friendly at all."

    PlayStation 3 hacker defyboy has also added the following: "I don't think this is a step closer to discovering the per-console root key. The EID root key is generated at factory and incorporated into metldr. metldr is encrypted with your per-console root key and stored on flash. Please note that while it is speculated that the EID root key is a derivative of the root key, that does not mean that it can be used to calculate the root key. Infact, being able to do so is idiotically counter-intuitive of the purpose of having two separate keys.

    The per-console root key is likely burnt into the CPU via One Time Programming over the JTAG port, of which is disabled after programming. There is a hardware decryption routine that uses this key called Runtime Secure Boot, you cannot access or invoke this routine because it only runs when you load an encrypted image into an isolated SPU.

    This is IBM's design, not sony's. This was designed to be a very secure multi-purpose processor and it was designed by a company that designs security and military systems for governments and large organizations, not a company that mostly makes consumer grade TV's and DVD Players. It was Sony's implementation of the secure chain of trust that failed but I don't see IBM's part failing anytime soon.

    This paper explains everything: [Register or Login to view links]

    Anyway, Sony cannot change metldr or bootldr on current hardware so they no longer have control of those, we only need to dump bootldr to get the lv0 key, this is the highest level sony can change. If we get the lv0 key we can generate a private key where we will be able to decrypt/re-encrypt the entire chain of firmware for current/future firmware."

    The Per Console Key in the Cell decrypts bootldr, which is encrypted with the PCK. Bootldr decrypted is the same in EVERY console to date (except possibly the 3K series). When bootldr decrypts lv0, bootldr will be as if it were nowhere to be found. Then you go from there to the Chain of Trust.

    Below is Gitbrew's feedback on the PS3 Per Console Key and future developments from them, as follows:

    what do you think about the new method of getting the per_console_key?

    Durandal: Glevand and many others have been working feverishly to develop methods of obtaining this key. Itís nice to see itís paid off. Iím looking forward to a day when the PS3 is as open a development as the PSP.

    Snowy: One step closer, sooner or later ibm is going to finally send a cease and desist. Weíll put that right up next to dasmoovers sign.

    Do you have anyone working on an easy to use tool for the key? we are already used to gitbrew pkgs

    Durandal: If we werenít, weíd have to quit gitbrew and join PS360...

    Snowy: Iím pretty sure anything related to the rootkey, we might leave out just so that people actually learn how to get their own keys. As a sort of accomplishment type thing, but eventually there will be simple pkg files released to do it.

    What next projects are we going to see from gitbrew regarding the ps3 scene? can we see some sort of "one day one announcement", like you did a couple of weeks ago?

    Durandal: Well RSX is taken care of, NPDRM is getting very close to being irrelevant, and Iíve heard thereís almost usable versions of psl1ght floating around. I guess the next really big thing youíll see is the release of the gitSkeet flasher.

    We teamed up with progskeet and rebug to create a special edition of the progskeet2 that will have solderless clips and the kind of support and documentation only gitbrew is capable of providing. It also gives us an opportunity to branch out into the actual hardware exploitation as well. As far as having announcement a day weeks, expect to see more of them in the not so distant future.

    What is your thought on the recent discoveries on the ps3 scene?

    The new jb2 dongle AKA true blue.

    Durandal: Iím always very wary of dongles. Usually theyíre just a ploy to make a buck, and these days it doesnít take long for someone to reverse what the software theyíre trying to hide does. Expect to see the same happen here. If we want to deter others from trying to peddle their software in a dongle form, we should make a point of reversing a dongleís functionality
    and implementing it in a package. Iím sure that group paid a lot of money to get all those dongles made, and theyíd hate to see that money go to waste.

    Snowy: Yet again as durandal said, dongles are dongles, regardless someone is going to take a crack at them and release a free version of it. Cobra hasnít even been touched by most of the developers, and those who have touched it donít really care for piracy. I would like to thank dean for taking the first step in making psx backups working though, a small step but none the less towards the proper direction for the scene.

    Finally, FiniteElement via ps3devwiki.com/index.php?title=Special:Contributions/FiniteElement states the following hint for those interested, to quote: "(you have all you need already just read carefully (compare option2 code with the kernel module code))

    He also updated the PS3 SPU Isolated Modules Reverse Engineering page with the changes documented here: ps3devwiki.com/index.php?title=SPU_Isolated_Modules_Reverse_Engin eering&diff=prev&oldid=6328

    Details and Payloads for Dumping PS3 Per Console Keys Surface

    Details and Payloads for Dumping PS3 Per Console Keys Surface

    Details and Payloads for Dumping PS3 Per Console Keys Surface

    More PlayStation 3 News...
    Attached Thumbnails<br><br> Attached Thumbnails


  9. #289
    Banned User CS67700's Avatar
    Join Date
    Oct 2011
    It's not worth burning it. BR's are still quite expensive to burn, not the best way to go.

    I'm sure you can run this from HDD, just needs time to be studied.

  10. #290
    Senior Member Hipmans's Avatar
    Join Date
    Jan 2011
    Agreed, my guess is it will take about a month before some clever dev figures out how this whole JB2 can be implemented in a CFW.
    Or at least they will figure out a way to fix the games for CFW 3.55.

    Maybe Deank is working on some sort of eboot fix/mod already, since we haven't heard from him in a while
    Last edited by Hipmans; 10-26-2011 at 05:22 PM


Sponsored Links
Page 29 of 87 FirstFirst ... 1927282930313979 ... LastLast
Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News