User talk:Hellsing9

added it to http://www.ps3devwiki.com/wiki/Talk:ReDRM_/_Piracy_dongles#another_clone.3F_-.3E_FAKE.21 - thanks :) Euss

Note: Im not held responsable of any damage done to your PS3. So read WELL and if you don't understand something just ASK and someone if it's not me will reply to your question/s. This is NOT a GOOGLE translated GUIDE. I done it because can be useful to put as tutorial in tutorials section and for understand some lost in translation words from the Spanish guide.

---

Since they are many problems with the original tutorial (in english) even can be problems in the c2d that's why i've done this guide.

Some clarifications:

In first place doing this you will NOT lose remmary of BD, this is false and not's only me the one saying it.

@naehrwert wrote: messing with eid4 on your box will destroy your bd-drive pairing, so I wouldn’t do that So play and modify something more than eEID0 can generate a unmarry BD, for example = eEID4 but here we not do any modifications only we use the first segment of eEID0.

Tricks to do in Linux and get the NOR dump and eEID(NOR)

---

TUTORIAL (eEID0 DEX)

- In first place we need the dump of the metldr hence in the firsts 0x30 bytes you have all the EID root key (erk and riv)

http://www.elotrolado.net/hilo_dump-...theros_1725034

Using HeX or any hexadecimal editor from 0x00 to 0x1F you well get eEID root key and from 0x20 to 0x2F the eEID root IV, you can get all this with the dump of the metldr.

Once you have that, you have to install OpenSSL to deal with the crypto part.

http://slproweb.com/products/Win32OpenSSL.html

Plus you need to download the 2 files = EID0_Key_Seed and EID0_First_Section_Key_Seed.

Download: http://www.mediafire.com/?azoliwucuez2dz0

Mirror Upload: http://mir.cr/1J5ZISSD

Well now i will explain the basic options that we will use with OpenSSL:

-in: Input the file that you will need to decipher. -out: the output file name that will be used after we cypher first. -k: It's to specify that we will use a key. -iv: In this case it's useful to indicate that will put an specific riv or irv for our cypher.

Advice: Put all the files in the same work folder with those 2 files, so it not turn into a pain in the eye having an easy access to our EID Root key and EID root IV, now we will start with the first step:

openssl aes-256-cbc -e -in EID0_Key_Seed.txt -out EID0.txt -nosalt -K HERO GOES YOU EID ROOT KEY -iv HERE GOES YOUR EID ROOT IV -p -nopad

Using EID0_key_Seed.txt as entry we will cypher it with our PCK they key and the IV as we see in the commands.

Then open EID0.txt this text file will be generated with the command input above, now you open this in a HEXEDITOR and from 0x10 to 0x1F there you have your EID0 IV and from 0x20 to 03F yuo have the EID0KEY.

If you want you can save them to easy access with another name like eid0_iv.txt and eid0_key_txt.

Well here we generated so far the EID0 key and EIDO IV of our PS3.

openssl aes-256-cbc -e -in EID0_Section_Key_Seed.txt -out EID0_First_Section_Key.bin -nosalt -K YOUR EID0 KEY -iv 0 -p -nopad

With the command above is normal to leave it in 0 the IV and once use that command we will have the EID0_First_Section.bin = the pass or key to decipher the first section where is target id cypher in the eEID.

Well the next step we will use that KEY to decipher the first section of the eEID0:

openssl aes-128-cbc -d -in eid0_1st_Section_CEX.bin -out eid0_1st_CEX_decrypt.bin -nosalt -K EID0 First Section Key -iv HERE GOES YOUR EID0 IV again -p -nopad

In NOR dump as you see in the image from 0x2F090 to 0x2F14F we will found the first section. It's highlighted in red.

On the section marked with blue color i want you to see what i mean with the IDPS of the first 0x20 bytes they are factory deciphered and it's the start of eEID0 but the IDPS can be found in the first 0x10 bytes.

eid0_1st_Section_CEX.bin: Is the name that i used to make an example to that section of eEID that we will extract directly from eEID0 offsets 0x20 to 0xDF (If it's a NOR dump it's from offsets 0x2f090 to 0x2F14F) as you see the lenght is = 0xC0 Bytes using the HEXEDITOR we put CEX in the end of the name to identify because the original section of our CEX console, this part will be ciphered and contains the IDPS. Now we paste the entry on openssl.

eid0_1st_CEX_decrypt.bin: It's the output name that we put to the FIRST CEX segment in order that be deciphered in the first line and to check if it was deciphered correctly.

When we load it in hex, if all the procedures went correct you will find a deciphered the FIRST line of our IDPS as was in the first 0x10 bytes of the eEID0 in (NOR = 0x2F070 | NAND = 0x80870) for example in my case something like this:

00 00 00 01 00 84 00 0B 14 01 A6 AE C3 1A 80 28 (THIS IS FROM MY CONSOLE, WARNING WITH THIS)

This bytes in my case are the same one that appears at the start of the eEID0 and in the image that i posted and marked the blue area, this is what you need to compare and check if the deciphered tasks went well, or if it's not in the first section.

In the first 5 bytes could be the same in your case hence the rest of the data is PCK or per console that 84 that appears in the 5th byte in my case is the target ID this represents or show that my console is a North American one but in your case, you have to find something similar along with our target ID.

If you notice that was REALLY deciphered (always double-triple check) you should find the target ID easy.

Note: From the FIRST 16 Bytes from the FIRST deciphered section of the EID0 MUST match with the first 16 BYTES of eEID0 as well the IDPS that can be found in your dumps = (NOR = 0x2F070 | NAND = 0x80870), if you notice something wrong o do not MATCH. DON'T KEEP ON GOING, HALT AND CHECK ALL THE STEPS AGAIN.

CMAC | TARGET ID:

Now will generate the CMAC (OMAC1) Hash from the first deciphered section from EID0 from 0x00 to 0xA8, that first section is the already deciphered one in the first steps with the name "eid0_1st_CEX_decrypt.bin" this file as you can see in the HEX EDITOR has a length of 0xC0

We will use that pass (key) that we already generated, also the EID0 First section Key and to keep on going with this tutorial you need to download this application that i created myself using as a base the algorithm cmac from the filtered source one week ago.

Download: http://www.mediafire.com/?kdetnwgb8s8fv9a

Mirror upload: http://mir.cr/0ZMKO3Q6

cmac file_in key_file

In our case we will see this: cmac eid0_1st_CEX_decrypt.bin EID0_First_Section_Key.bin

That eid0_1st_CEX_decrypt.bin as i said many times it's the FIRST section that we already deciphered and that key from EID0_First_Section_Key too that was generated in the last steps of this tutorial.

The objective of doing this along with the program is to get the ORIGINAL CMAC from our section without changing the target ID to DEX yes, the output of the program should we something like this:

Hash CMAC (OMAC1):f1053cc3818dd6ce2775f0273dfc212e

It's crystal clear that the numbers will be different, they are PCK and the way we generate them:

You will have to copy the calculated HASH that will give us the program and compare it with the one that you get from eid0_1st_CEX_decrypt.bin= 0xA8 to 0xB8 has to be the SAME (i repeat it's the first deciphered section that we use as entry) from 0xA8 to 0xB8, if it's not the same something is wrong. Check again the steps, if not your case and MATCHES you can go to the next step.

Now in the byte 0x5 of the first section of the EID0 that we already deciphered we have our target ID and you have to change it to 0x82

Once you changed the Target ID from the first deciphered section from EID0, you have to create a new valid CMAC hash for your new DEX and this new HASH you have to write it in the same section with the offsets where we already checked before (the old value) is from 0xA8 to 0xB8 this is done to replace the old hash with the new one. The new hash (as earlier in this tutorial) you will generate it EXACTLY the same as the CMAC.

cmac eid0_1st_CEX_decrypt.bin(NOW DEX because we changed the target ID) EID0_First_Section_Key.bin

The Hash generate from this step we will write it as i said in the FIRST deciphered section with the target ID already changed (i repeat the same eid0_1st_CEX_decrypt.bin with the target already modified that we just used with the CMAC to generate this new hash) from 0xA8 to 0xB8 replacing the *old one*.

Once we have the modification list from the first deciphered section (eid0_1st_CEX_decrypt.bin) finally we will go ahead to cypher it again.

openssl aes-128-cbc -e -in Section already modificated(eid0_1st_CEX_decrypt.bin) -out eid0_1st_DEX.bin -nosalt -K EID0 First Section Key -iv again your EID0 IV -p -nopad

Here we will use with -in input to the eid0_1st_CEX_decrypt.bin already modified and as output we will generate the file eid0_1st_DEX.bin this files will be the one we have to copy and insert in the DUMP replacing the *old* CEX.

The offsets where goes this section are the same ones where we extracted in NOR this segment is on 0x2F090 and im not sure about the NAND but should be on 0x80890 the ones who have NAND you can confirm this.

Once you have the modified dump the only thing you have to do is flash it with our own means, you can choose soft or hard (hard is more safer).

FW DEX TEST REPOSITORY: http://www.ps3devwiki.com/files/firmware/OFW-DEX/

Benefits of a DEBUG TEST console:

.- Run Homebrew and ANY eboot signed FSELF with the SDK in ANY debug fw until the last one 4.11.

.- Execute the last 3.6+ legit games in disk (even in 4.11) You can run homebrew and new games but with original disks NO BACKUPS because the eboots have to be signed again as FSELF.

.- You can use EVERY single option from SDK (Debug, Development, etc)

.- Execute backups max 3.55 using PS3gen or using debug pkgs and eboots FSELF 0x8000 (re-signed with the psn_package_npdrm, any package preparing them *geohot* type.

.- Direct downgrade from 3.6+ to 3.55 with ONE pup fast way to do it.

.- improves and many things from the latest FW (Support of new devices, etc).

Cons:

.- For the moment nothing complicated to fix, you have no BD or DVD playback because you can't do it on DEX but in 3.55 dex this is can be fixed (Easy way) in any 3.6+ you need certain check.

1) What do you mean retail functionality? You can restore dvd playback and ps store to name a few by some sprx copying and xml editing. Just unpack a dex fw for 3.55 and a cex fw for 3.55 and note the differences in sprx. Then just add the correct xml keys. For example for ps store add the #seg_commerce_new key to category_psn.xml.

.- Maybe a little bit more of charge (data) for PHAT with heat problems.

.- NO PSN hence you have to connect to devnet, you need at least one created account (From last year) the passphrase issue. So NO PSN in Dex.

.- There is a change that if you try to login too much times in PSN with the debug in environment default the sp-int you can be banned for trying it. Since when you are doing this you are sending your IDPS to a server and this is the way they check. So be careful.

Source = Elotrolado

Translated by me.

Any typo let me know.

Regards

Hellsing9

Passphrase issue that i posted some days ago:

The NP communication passphrase and signature will be provided within the Server Management Tools.

Details: NP communication ID, passphrase, and signature, required for certain PSN communication services, had been provided on the DevNet thread upon the completion of the requested Playstation®Network service configurations. From 2012/07/05 the NP Communication Passphrase and Signature will be provided within the Server Management Tools.

This change affects all the communication IDs issued after 2012/07/05. It will not be possible to access the NP communication passphrase or signature in the support issued after that date.

Only those users who have initially requested the NP communication services and was provided the files on DevNet thread will have access to the file on the request threads.

Note that the NP communication passphrase and signature are required with NP Matching 2 and Title Small Storage.