Thanks for the news need, I will promote this to the main page shortly and +Rep!
Also in case anyone is wondering, we are fine with posting links to these modded PKG files or filepacks of them in this ongoing thread (I will update the first post with them) as long as they are all hosted on free file-sharing sites as stated in the OP.
Today PlayStation 3 scene release group DUPLEX, who recently leaked the full PS3 3.40 SDK which was then followed by the PS3 3.60 SDK, have now released a bunch of PSN games decrypted for PS3 Custom Firmware 3.55 and 3.41 users!
Below is one of the PS3 NFO files for Alien.Breed.Impact.PSN.PS3-DUPLEX.nfo from their PlayStation Network game releases along with an ongoing list of NPDRM decrypted titles, as follows:
Release Info: Alien BreedT Impact is an explosive science fiction arcade-shooter that resurrects a much revered franchise with an epic story, swarms of highly intelligent alien enemies, high-impact weapons, highly detailed and rich environments; all implemented with superb technology in a state-of-the-art gaming experience.
Notes: Since no scene group managed yet, we thought it's time to work on some PSN games to give everyone something to play for CFW 3.55. Fully decrypted .elfs are included as proof and of course for educational purposes
1.) copy files to FAT32 USB Key/USB Disk
2.) install game *DUPLEX.*.Install.pkg
3.) install patch *DUPLEX.*.Patch.vX.XX.pkg if any
4.) install crack *DUPLEX.*.Crack.pkg
Lets hope for more coming, and feel free to post links to free file-sharing sites for the modded PKG files to download below! Here are some of the initial download links courtesy of VenomusX:
IF YOU ALREADY HAD A DEMO OF ANY OF THOSE GAMES, or LOST THE ACTIVATION/LICENSE, Just delete the installed PSN game first (your savegame should be intact) and reinstall the Duplex version as a clean install. Should work!
PS: the .elf file is useless. Delete it if you want! It's only for those who want to understand how it works.
From JuanNadie aka John Doe comes details on the PlayStation 3 NPDRM Self Algorithm below, as follows:
PS3 NPDRM Self Algorithm
THIS DOES NOT ALLOW TO OBTAIN 3.60+ keys, nor piracy as you require the rif, act.dat and IDPS.
On NPDRM self decryption all the security levels of the PS3 are involved: user space (vsh), kernel space(lv2), hypervisor( lv1) and isolated SPU (metldr + appldr)
The process start on vsh.elf...
Once the vsh detects that user is trying to start a self, it looks for the appinfo header type. If the type is 8, then the control digest element type 3 (NPD element) is located. From this NPD header the vsh gets the license type (free, local or network license).
If a free content(type 3) is detected then a generic klicense will be use for further steps (go to LV2). That klicensee is already public (see geohot npdrm_omac_key_1).
However if a paid content is to be loaded the vsh loads the act.dat and the rif associated to the content (if local it will locate a file with the same titleid on NPD element, if remote it will download to vsh process memory)
Then the signature is checked (last 0x28 bytes of both RIF and act.dat). The curves used are on vsh.self. It is a 3 element table, having the first curve nulled. The curve index for rif/act is 2. The curve values are negated as in the apploader and has the following structure:
The lv2 keeps a memory table with contentID and the associated key. When it receives a free content (r5 is not null) then copies the titleID and the klicensee to the table. For a paid content the rif.key is converted to the klicensee using:
where CONSTACTDAT is a constant value on lv2, IDPSVaritaion appears to be IDPS (not checked but DRM_Manager_initialize (see graf_chokolo's "bible") to something with the same structure), actdat are the 0x10bytes selected by rif keyIndex, and rif is rif.key (bytes 0x50-0x5f).
Once transformed it is stored on memory table... I haven't check further steps on vsh nor lv2 so perhaps there are further transformations on the paid case (NOT FOR THE FREE AS I HAVE DECRYPTED THOSE) so we are jumping directly to the appldr
As you can see from graf_chokolo payloads a parameter is passed on spu_args.field60. That parameter is the previously stored klicensee.
However this key must be transformed (again) even for the free case. The transformation is:
Decrypt using AESCBC256 with the NPDRM keys to obtain the metadata keys
Decrypt using AESCTR128 the data sha, hmac, iv keys
Decrypt the data.
First of all, I want to congratulate Euss of ps3devwiki on finding the klicensee decrypt key and provide a proof of concept of the AppLoder part of the algorithm. Check ps3devwiki.com/index.php?title=Talk:SELF_File_Format_and_Decryption
Now you have the tools to decrypt all free executable content. Euss they key is not duplicated... there are two cases that lead to the same (similar to the keys, two cases so two repeated tables).
Some of you asked what this algorithm is for. It has several use from backing up PSN games so they can be used with/without license (some countries allow backups, but NEVER sharing copyrighted material...) or use game updates on lower firmwares (some updates are NPDRM so they could not be decrypted and downgraded). I don't know if DUPLEX used this method or if they replaced the data with debug versions as some implied...
Also, it can be use is to modify geohot's make_self_npdrm to use non static keys for encoding. I don't know if that would be enough to make a self runnable on 3.56+ firmware. However it is a step on the right direction (I think extra modifications are required). If someone knows which parts of the self is whitelisted it would be an interesting addition to the thread. Sony was publishing 3.55 after 3.56 went online so I really interested to see which part of the SELF was whitelisted.
Others asked for the keys. I can not provide them nor functional code to avoid being sued... Graf and geohot were sued for providing the keys and/or functional code.
However, I can provide a tip on getting the RIF key.... once decrypted bytes 0x40 to 0x4F should be xx xx xx xx xx xx xx xx xx xx xx xx 00 00 00 aa where x is random and aa is a number between 0x00 and 0x7F. It is located on the VSH.elf (remember that PPC64 has 8 byte aligment). That is a plaintext attack + dictionary(vsh). You don't need the curves as you can not sign rif nor act.dat (You can only check that file is valid). And the vsh keys can be easily find... graf chokolo called IDPS as device_id_ptr.... and the CONST is very near on code execution...
To yolbulduran: That is a piracy related question. In addition you have published confidential info, which anyone who does RCE should avoid (I do not have the SDK). The answer is NO. Why?. See this code:
First part is an example of how a developers can easily catch that modification and stop execution making it dangerous (could get a ban!!!). You modification says that the console has access to a fake content, which only CFW will have. When patching code the modification should be done only to the case you want to fix. That modification should go on the executable not on npd libraries. That way we do not patch the first verify but we will patch the second...
The second part is the real reason why it wont work... you REQUIRE the rif for opening the edat. The rif holds the klicensee for both SELF and EDAT. In fact I assume that the klicensee follows the same transformation upto the apploader. That key that you see on the command it is only used to check the HMAC on the NPD element (see geohot make_self_npdrm omac calculations)
For executable the problem is similar as when trying to run another PPU executable the program will finish and ask the vsh to run the other process which will undergo the full decryption algorithm... again you need the rif.
But... what will happen if we decrypt the paid edat/SELF using the rif and then resign and encrypt as a free content before executing the code??? (Assuming we can sign edat)
WE CAN SIGN EXECUTABLES UP TO 3.55 THANKS TO FAIL0VERFLOW'S EPIC FAIL... I think people do not really understands what that means...
From granberro: Congratulations and thanks for sharing JuanNadie. Regarding EDAT files, IMHO their encryption is FW version independent, at least for the free content. I have changed geohot's make_self_npdrm to encrypt elfs using a given keypair rather than the static one.
Using that tool and unself2 I have managed create and install LBP2 updates 1 to 4 on a 3.41 PS3. Those updates contains EDAT files and were decrypted by the game flawlessly.
I don't know if it is ok to post links to those pkgs. The npdrm diff (just) the important stuff is:
The first (digest) is a hash of the decrypted data. I don't know the algorithm nor if it is checked.
The second is a CMAC. The key is npdrm_omac_key3, and the message is the titleID (0x30 bytes) concat to the filename (excluding path and case sensitive),
The third is again a CMAC. This time the message is the whole NPD from NPD magic to the second hash both included. The key for SELFs launched from the VSH is npdrm_omac_key1 xored with npdrm_omac_key2
But for the rest (Selfs executed inside a program and EDAT) instead of using npdrm_omac_key1 another key is used. That key is called the klicensee (however as that name is already used I would call it devklic (developer klicensee),
That key is selected randomly by the developer(activision, ea, ubisoft, square...) and it is a parameter used when creating a pkg. So for EDAT the key for the third hash is devklic xored with npdrm_omac_key2.
If we are going to recrypt an EDAT we need that key. There are several procedures to obtain it:
Decrypt the SELF and use RCE to get it. We'll need an idc that locates the call. Very slow, tricky, requires large knowledge but always work.
Hook the call that opens EDAT. Then we retrieve it on parameter r3. Faster, requires modifying the firmware. Always work
Brute force it: Decrypt the self and try every combination of 16 sequential bytes on the file. I obtained using this method the key on Buzz and LBP. It faster than RCE but it does not always work (the key could be in other file or obfuscated).
I repeat we will need that key to encrypt an EDAT.
We SONY uses this key? To avoid the following exploit?:
Obtain the devklic.
On a PS3 where the EDAT is authorized write a program with the following command;
That will create a file descriptor. The read of it will be on clear... and we can then write it to an output file.
How I think this works? Well, you provide the correct klicense, so the system will validate the NPD and send a request to LV2 to set the decryption key (This would be related to rif for paid or to the devklic if free). Then when reading if the LV2 Will ask the appldr to decrypt it).... Note that seek works so probably the decryption can be made by blocks.
BTW something similar was done on PSP.
How can we use this?
First is good to have the plain text of something you0re trying to reverse so for devs it could be useful to reverse EDAT algorithm
Second you can replace the original file and patch the EBOOT to not use encryption.
Third you can create a debug EDAT and path lv2 to accept debug files.
However IMHO any warez release that uses those tricks should be NUKED as that is not the correct procedure (that would be reencrypt the EDAT as free).
The first hash of NPD needs to be obtained
The first 0x80 encrypted bytes of an EDAT (0x90-0x10F) contains a key for decrypting the rest of the file. I think that key is constant for the rest of the file. Reason: the 2 EDAT I decrypted from Buzz has the same contain... which means hash1 is the same (2 and 3 are different cause the filename is different), but the encrypted content in the metadata section changes. Perhaps a signature but I think there is a different key there (the data also changes)
Update from JuanNadie: Well, a year passed since I opened this thread so lets celebrate with an update
I have been able to resolve the EDAT v4 version. Basically Sony add a new key/hash. When creating the hv99 call, field38 contains the key index. For version 0 to 3 key index zero is used (older key). For version 4, index 1 (the new key) is used.
In addition to that I reversed more fields of the edat header:
0x40 - 0x4F: Before I said that is was a unknown hash. The value actually is the first 0x10 bytes of the SHA1 of the file before is packed (after using make_edata_npdrm)
0x70 - 0x77 and 0x78 to 0x7F: While normally zero on some betas has a value. This is actually dates (since and upto) of validity. When used in combination of a riff the most restrictive is used
0xD8 - 0xFF: Here are the bad news. This is an ECDSA signature. The pub/curve used is the same that the one used on rifs or act.dats. I haven't found a collision so priv can not be obtained. Fortunately the check is not active (I don't know why... perhaps older version have this not properly implemented)
Finally an update version of the code. I have to break compatibility with KDSBest release in order to integrate the additional key. Also I added the ecdsa check as a warning (won't stop decryption) as well as minor fixes.
On the .ENC files (AKA PS2 remastered games on PSN):
I started reversing those. At the moment I know that the OMAC checks are still there (the klicensee is the default). The ECDSA check is ENABLED for PS2 games and on lv2 an ENC is required to be a paid content (so patching vsh.self and lv2 will be required to use a fake ISO.BIN.ENC). I can not gave more information of the encryption although I suspect that an encryption similar to BDEMU is used.
From Gamma Argon: Here is a small update to Juan Naide's Bootloader (Btldr) Exploit to allow running the exploit on firmware 3.41, 4.21, 4.30, 4.41, as well as the original 3.55. Includes source code and compiled binaries for RR5 and RR7.
Note: Requires Other Os, CFW, and a NOR console. Tested only on 3.41, 3.55, and 4.21. Apologies for releasing untested for 4.30 and 4.41. Thanks to Juan Nadie for releasing source. Thanks to G. and A.P.
granberro Buen trabajo. I saw your work at elotrolado allowing the use of non static keys on a NPDRM.
mathieulh thanks for the compliments on type 2 NPDRM. I also think that someone should modify make_self_npdrm to make SELFs that work "at least" on 3.55 official firmware...
I haven't fully reversed the EDAT algorithm (I’m missing bytes from 0xB0 to 0xFF) but there is enough info for a post. The explanation is for those with flag (offset 0x80-0x83) equals to 0xC which is a normal EDAT. For others values minor changes should be made. Let's begin.
USER SPACE: (Probably incomplete (enough for decryption), most of it is guessed) On previous post I mentioned the command useds by developers to open/read an EDAT. That command has 3 parts:
Verify: This parts verifies the NPD element by checking that user is authorized to open the file (using the devklic). In addition it calls LV2 to create an entry in the memory (probably using syscall471) so for further steps it will use the devklic (free) or the decrypted rif key (paid) (see SELF algorithm). I’ll call this rifkey on the rest of the document.
Open the file: This will call kernel space. Performs several checks and creates an entry on another table.
Read: It also calls LV2, which will decrypt and send data back.
When an open request is received:
Read the first 0x100 bytes of the file.
Validates first 0xA0 bytes on EDAT. This uses appldr with the following execution (see below):
CMAC. Key: rifkey, expectedHash: data at 0xA0-0xAF
No Encryption erk:null,riv:null
Validates metadatasections. Again uses appldr:
Multi execution. Blocks upto 0xFC00.
CMAC. Key: rifkey, expectedHash:data at 0x90-0x9F
No Encryption: erk:null, riv:null
Once the NPD is validated (We have validated header upto 0xAF and the metadatasections( which validate the data itself)) an entry on a memory table is created, the entry created by syscall471 is erased and returns. I’ll call this the EDATEncryptionDataTable. This table has 10 entries (remember the limitation of simultaneous files opened??...). Each entry has the following structure:
-fileDescriptor: The file descriptor
-offset: An additional offset to calculate the position of the metadataSection. Origin unknown. Values seen 0
-File len: Length of the uncompressed data. Copied from EDAT offset 0x88-0x8F
-flag: Flags required to process the data. Copied from EDAT offset 0x80-0x83. Some flags are:
blockSize: The data is stored on blocks of that length. Required for decryption. Copied from EDAT offset 0x84-0x87
numBlocks: Number of blocks on file. Calculated using: numBlocks = (fileLen + blockSize - 1)/blockSize
blockBase: Common part of the key used on decryption. First 0xC bytes of headerHash. Copied from EDAT offset 0x60-0x6B.
devklic: Our rif key. Copied from the entry created by syscall471. FOR SDAT it is calculated using other algorithm.
padding: the digest from NPD. Will be the IV. Copied from EDAT offset 0x40-0x4F.
When an read request is received:
The system determines the blocks required (E.g; read from 0x3FFF to 0x8001 will read blocks 0,1 and 2).
For each of the blocks:
Calculate the blockKey as blockBase concat blockNumber.
Calculate block offset: Start of NPD + offset + 0x100 + metadataSectionLen* numBlocks + blockSize*blockNumber. metadataSectionLen is 0x10 for flag 0xC (if compressed or with special hash would be 0x20).
As you know the appldr is used for decrypting SELFs (that part is documented on the wiki). However there is a second mode that is used for EDAT. To use that mode spu_arg.field35 is 5. For values 0 to 4 it will process a SELF and for others will return error. Graf_chokolo described the structure of spu_args for the SELF. However this changes for EDATs…
The multiple execution /single execution refers to the ability of appLdr to store an encrypted (and hashed) data on main memory to resume the hashing/decryption operations on next execution. That data is stored at stateAddress. Basically the functioning has several submodes. One for initialization (that decrypts erk, riv and hkey) and copies the state to main memory, another for processing data, which retrieves the state, process the data and updates the state, and finally another that receives the expected hash and validates. Another submode does all these ops on a single execution (calls the three submodes).
Summing up (for 0xC) for each block:
Calculate data offset: 0x100 + offset(0) + metadataSectionLen*numberOfBlocks + currentBlockNumber*blockSize
Generate block key: concat first 0xC byte of headerHash with current block number
Encrypt block key with rifKey using AESECB128Encrypt. This would be erk and hkey
Calculate riv. It is NPD digest field
Decrypt erk using AESCBC128Decrypt with EDATKEY and RIVKEY -> call result decryptionKey.
Using AESCBC128Decrypt decrypt data from offset to offset + blockSize (if last block calculate remaining bytes rounded up to 0x10 multiple). Key is decryptionKey iv is riv
Copy data to output file
After searching for those missing bytes I did not found any reference on code. So I zeroed them and feed the file to the PS3... The file was properly loaded and decrypted so:
Those bits are a random padding or
They are not checked, nor required for creating an EDAT.
That means that you are able to "free" your EDATs using the method above. Remember that you're going to need the devklic and the rifkey.
Octopus For p3T you don't require the devklic cause for paid decryption you only need the key from rif... so decrypt it and use it directly like any other theme
EXE.trim.ALL You're right on version. LV2 uses that value to check which flags are valid. However unk4 (and unk3) which are at 0x70 are zeroes. Your info is for the next 16 bytes located at 0x80. Also you separate finalize and type. From the assembly I can say that the original source code considers it a signed integer (int32_t) (that or they have a really weird compiler cause it always load that field as a word (PPC can read a single byte)).
BTW the text on flowers says something about "werewolves" and the devklic is written as an ASCII text (not binary). It was the first non free content that I decrypted on PC.
euss IMHO best topic of the last half year was written recently by math on lan.st... half year? nah... last year. It's a pity that I would never enter on efnet (nor other sites) as long as they don't allow proxy and TOR.
Finally a bit of drama: Hotz8611, I reversed your reactPSN to see the your method and discovered that you just used the info on this post. I haven't check the vsh.self mode but I suppose that youre nullifyng the curve check and generate RAP by encrypting the rifkey (An AES and another crypto algorithm of 5 rounds with shuffle, acummulation and xoring.). I thank you for making people provide me all those RAP than I'm able to transform to rifkey but next time give proper credits (I don't know if your works is based on mallory or mine but obviously is based on info in this topic).
First of all, here is an implementation of the algorithm. It is not fully tested (for example with ISO.BIN.EDAT it validates but fails when decrypting) and is missing the decompression algorithm (I tried deflate but is does not work if someone identifies the algorithm please post it. Blocks start with 0x05). Also keys have been eliminated. On previous port you have the SHA1: http://pastebin.com/SuAukd8B
You probably forgot to decrypt the key. The result of syscall471 must be decrypted using EDATKEY and RIVKEY.
To make free files:
Create a memory image of the file.
Decrypt the data, so you have a memory copy of the file decrypted (for compressed no need to decompress)
Modify NPD to make if free (0x03 instead of 0x02). Recalculate hashes using devlikc (that why we need it).
Recrypt each block using the devklic as base to calculate blocks keys (wich will then be transformed again as does the appldr for that type).
Once recrypted, recalculate the hashes of the sections so they matched the new value for the encrypted data.
If compressed recalculate the offset and len on the metadatasection
Using the new metadatasection recalculate data 0x90-0x9F.
Using the new NPD header + new metadatasectionHash calculate hash and place it at 0xA0-0xAF.
Write file to disk (Remember, that file is function of filename, you must overwrite (not recommend while testing) or remember to rename it properly).
The code I posted already implements SDAT. You just need the SDATKEY. The SHA1 is ED2A015EEB1BD0CE06D0447F1A22AF4C1C401E4A
However you won't find it by bruteforce as it is coded as a series of inmediate values. If you check routine sub_5529C at graf_chokolo's dump_lv2 you'll see the routine that checks the edat/sdat header. Few lines below at address 5543C you'll see those inmediate values that are xored with the hash of the NPD to create the fake rifkey (the first 0x100 bytes of the npd are loaded starting at sp + 0x110)
About compression: We don't know the algorithm but if we decrypt the data and modify the NPD so it looks like a debug you can use make_edata_npdrm to decompress it.
Added support for versions 0 and 1 (ISO.BIN.EDAT). See below.
When version is 0 or 1 instead of using the digest and the hash of the NPD for calculating the block key and the apploader's IV a zeroed byte array is used as base. I hope this helps your project Snowy.
I don't think I could help Kakaroto cause most of the checks are not on current code (They probably added further checking on later firmware version) and my expertise is reading assembly which I don't have. However if I can help then in any form they only need to contact me. In fact the only think that I know that is not already public is that 0x20 bytes are copied from the appldr to main memory just before setting mailbox to 7. Those bytes are at 0x890 and probably is the hash for the whitelist.
There is no hash for SDAT. Those values are unknow and not checked (not confirmed). The only function as you have seen is to be xored to generate the key. To get the exacts values I'll need to check the SDK as those are generated there.
I haven't look for the second part of the act.dat. My hyphotesis is that the second part of the file is used when debug is enabled and is common for all the consoles (will explain the COD trick). About the digest as I said there is no checked (is a hash of the original data which is unknown until the whole file is read so it can not be used as check). Geohot zeroed it on his code, An analysis of make package will obtain then (or wait until Kakaroto has the SELF fix and hope that it included the algorithm)
About the keys:
For the header hashes there is no change you still use rifkey to get them.
To obtain that key (get the keys from wiki. i'm using the names used there):
Decrypt rif 0x40-0x4F with the RIF's act.dat index decryption key. Get act.dat index (last four decrypted bytes)
Encrypt klicensee constant with your IDPS-> I'll call the result actdatkey
Using actdatkey decrypt act.dat values from 0x10 + index*0x10 to 0x1F + index*0x10
Using that value as key decrypt rif 0x50-0x5F
If the file is free then use the devklic directly. There are no changes for checking the headerhashes. However for the data there are two variations.
The input keys: Previously the npd.digest was used as IV. Now it is a 0x16 bytes array of zeroes. For blockbase use 0xC zeros instead of the first 0sxc bytes of npd hash. Then append the block number. Remember to encrypt this with the rifkey.
The apploader mode: For types 0 and 1 the keys provided to appldr are not encrypted (only compression and debug flags are allowed). They are used directly on the data
The mode for uncompressed 0x20 bytes metadata section is not tested as I do not have retail files supporting it. The only files I have with that flag on are debug... which disables hash checks (see my code). If you have one retail with that flag please send me info on it so I can adapt the code.
I'll change the flag on compression as soon as I confirm it (I have not seen that flag with value 0). The hashes on NPD element use devklic. The ones on EDAT header use rifkey(paid) or devklic(free). Check my code routines for checking NPD and EDAT header.
There is always a SELF for any EDAT (even a SELF for a SELF if NPD type is 0x20). If your version 0/1 is an EDAT for PSX or PSP you should check their emulators (located at dev_flash). In fact for PSX I can tell you that two of the 3 SELFs produce a match.
You are calculating properly the hash. However you probably are not considering FLAG0x10. This flags indicates that the algorithm for hash is HMAC instead of CMAC. If FLAG0x20 is set the hash len is 0x14, otherwise the hash is truncated to 0x10 bytes.
Also another effect of FLAG0x10 is that the hashkey != encryptionKey. When this byte is set the hashKey has to be reencrypted again to calculate the proper value. Check the code above
BTW I confirm that for files with flag0x20 the structure changes from all metadatasection + all data to metadatasection and data interleaved. That means that the metadatasectionhash is ignored. I also confirm your isEncrypted. (credits to EXE.trim.ALL)
Extract any License, DRM file Content PKG from OFW 4.11 etc from PSN by IngPereira:
Well people i have this info there because I want that more people become to be getting on this stuff there are some good contents right now on 4.11 PSN and we can extract the License files created when you purchase on OFW and the content itself PKG and i thing that this can help some people.
We can extract all drm files and because there is a exploit with the NPDRM (Edata algorithm by JuanNadie, etc) we can make FREE that files with EDATA etc so the people can use all that content, ExeTRIMall just make Fifa 12 PLAYABLE on CFW so there is some opportunity you can try to Help guys like ExeTRIMall and others if you extract content with his license now purchased on PSN from your PS3 and “maybe” that content will be PLAYABLE on CFW but the truth is that the content can be PLAYABLE on any PS3 OFW 4.11 etc if the DRM license files of that game become to be FREE.
There is Assassins creed revelations on PSN and many more content.
Well my friends in order to extract license files of content (But they will not work so quick there are more steps in order to make it PLAYABLE on CFW but this a really good step) so you can have the drm license files edat or rif) you should need you need to do this:
1. - Things you need:
E3Flasher Dual boot or any other working FAST DUAL BOOT
A PS3 on MA 3.56 or 3.55 CFW (NOT TESTED) and the OFW 4.11 etc.
A Dongle that can put the PS3 on Service Mode.
The Lv2diag.self from PRELOADER ADVANCE 2.0 by JaiCraB.
A good knowledge about this.
Obviously you need to have your Dual boot setup ready to go.
PRELIMINARY PROCEDURE to keep using the same HDD on OFW:
We need to have the HDD like when we are on CFW again DON’T FORMAT THE HDD we just need to update on 3.55 CFW to 4.11 etc without format and keep the hdd like that on 4.11 and when we gonna down to CFW to extract content just use the good procedure by restoring a dev_flash backup with preloader advance with the Nor or nand Setup to use a CFW with the same HDD.
Well to be started you need to make the Purchase and downloading of the PKG File (obviusly take the URL of the Download).
What we should do its just keep using the same hdd of the 4.11 OFW on PSN but with a working dev_flash for the CFW 3.56 or 3.55 so the CFW can init good and we want to keep the dev_hdd0 with the folders created on 4.11 to extract all on CFW.
Like you can see is more easy to do it on the 3.56 MA because there are links working of a Backup of dev_flash to be restored with preloader advance and leave you using the same HDD (With the same dev_hdd0 of 4.11 on PSN) but now with a CFW on 3.55 you need to make a backup of dev_flash first of the CFW that you use (Kmeaw, rebug, etc) to later restore that backup when we are back to the CFW from OFW.
Later is just be on OFW and flash nor or nand on dual boot etc and put a CFW to later restore the dev_flash of that CFW on Service Mode with Preloader advance 2.0 and try to start the system to be on the XMB and copy everything.
If you try to keep using the same HDD this will work for you! If you will do this on JFW 3.56 MA you can use this backup created by good people on DemonHades.org.
On CFW 3.55 I don’t know any link of backups created by preloader advance 2.0 so just make your own backup by modifying the CFG (Preloader Advance 2.0) on the line “Backup dev_flash” that is on 0 put 1 to activate the option.
When you get the URL of the PKG and the purchase become to be completed so the game or whatever is working then you can go down to use the CFW.
When your Nor or Nand is setup to use a CFW 3.56 MA or 3.55 etc (Nor or nand flashed with the right CFW) you just should be care to insert the Jig dongle in the USB Port at the right close to the BD and keep the same procedure to put the PS3 on Service Mode (You need to be sure to are on the CFW).
If you just use the dongle and you see that it worked (The PS3 should be OFF depending on the dongle) you can put the lv2diag.self and the cfg file from Preloader advance 2.0 by JaiCraB.
The CFG file is ready to make a backup of dev_flash2 (Some drl files and account xregistry user) and restore a backup of a dev_flash in the same time.
It restores "/dev_usb000/flash1.bin” and make "/dev_usb000/Backupflash2.bin" the PS3 should be OFF when it finished.
If the process was OK then when you start again the PS3 you should be on the XMB and you can use a file manager or FTP to start the copying process of the HOME Folder on HDD0 and what you thing is needed maybe you can check the PKG Install created on dev_hdd0/game on OFW.
If there is no XMB repeat the first steps about the “PRELIMINARY PROCEDURE”.
The HDD need to be using the same encryption method (So you don’t need to format) just updating and later down to 3.55(Using dual boot with the same HDD!).
If you want to help in the investigations you can upload that content with the license purchased on some sites and other guys and me will try to do something with that, you just need to upload the license drm files of the purchase because you can grab the url of the package from the Store.
Working and extracting data from the Backups created by Preloader Advance 2.0:
You just need to use Winhex and open the dump backup on winhex and use the option from the "specialist" TAB "Interprect Image file as disk" and Winhex will show the dump now in a disk format so you can extract the data from that dump too easy by just selecting and extracting.
Thanks to DemonHades.org and JaiCraB by Preloader Advance 2.0, to exeTRIMall, JuanNadie and any more people that want to upload all his content license files.