(adsbygoogle = window.adsbygoogle || []).push({}); I have recently seen users posting about the eboot.bin and nand theories; However good they may be, and may I add we appreciate your intellectual contributions, this cannot be done with a retail console. I myself have posted on the theory of enabling a retail console to run a debug patch,[You must login or register to view this content. However, I have discovered that debug consoles have different software that enable editing of the game executables. To access the nand and eboot "modafiable files" you need to perform a dump, which is only done with a ps3 test tool. This will allow you to boot the retail game directly from the HDD also allowing you to change game exacutables, which I posted on last week. Here is a quote I found; extending the one I posted in my other thread:
-----------------------------------------------------------------------------------------------
Originally Posted by itwong You must login or register to view this content.
I want to make sure I understand this correctly. This thread is about packing fake-signed debug executables obtained from debug .pkg along with contents decrypted from retail game disc using cellftp.self into a single .pkg file that can be installed via debug units' "install dev package" feature. However, this does not solve the fundermantal road-block we have, that is, you gotta have a debug patch(.pkg) to start with.

"..or make the retail console boot in debug mode. The package format is known on beforehand. Seen that from mobiles and the psp. The encryption scheme is different, though.

Geohot for example, was apparently absolutely certain that it was possible to disable the protection with a switch (like on the iPhone and other systems - because of bad design, the interface layer had write ability to the lower level system, so user-programs could make changes that way).

So on the ps3 that doesn't work. There's no switch to pull out - the encryption scheme needs to function for the rest of the system to work. Meaning: only way to get these packages for hdd games to work on a retail console is to get hold of developer tools, and their encryption keys.

Or just, you know, rewrite all the hardware interfaces from scratch. You must login or register to view this content. "

Read more: You must login or register to view this content.
----------------------------------------------------------------------------------------------
So to quickly extinguish the flames doubt, I have attached this tutorial found on PS3 news.

[NOTE]: this tutorial was not written by me, nor do I claim it as my intellectuel property. It was written by a member of the ps3 news, and full credit is given to them.
-----------------------------------------------------------------------------------------------



PS3 TEST / TOOL Debug Game Backup Guide

We get a lot of questions in the forums, asking how to run a backup of an original game on a DECH unit – and it is a complicated process. However, I finally decided to stop being lazy and write a nice guide for people to follow.

For starters, what you will need to get this done:

* A PS3 Development Station (ie, a PS3 Test / PS3 Tool)

You must login or register to view this content. or You must login or register to view this content.
PS3 SDK
(Ideally, something around 1.6-2.0ish, although others will work)
* Original Game Disc
* Time

This guide will be using old Linux version, same should apply with the Windows version and MinGW. For newer versions (with ProDG/Target Manager) things will be different, so ideally try to use an older version (something ~1.6-2.2ish).

The leaked 1.60 is missing a key file for TEST user's, “dtnetm”. Namely, as of 1.60, TEST "debugging" was not supported - this feature was not fully added in until around 2.00. dtnetm basically runs on a PC, and facilitates communication between the PC and PS3. The PS3 TOOL has its own version of dtnetm that runs on the TOOL's CP. Since the PS3 TEST lacks a CP, it's necessary to run dtnetm on a PC to 'emulate' this aspect.

SDK Setup

To start, install the SDK, and get it up and running. Sony provides a nice guide on how to do this in the “Reference_System-Setup_e.pdf”. Of note, make sure to set the environmental variable DTNETM, to 127.0.0.1 (DTNETM=127.0.0.1) - this is explained in more detail further down. If you are using a PS3 Test, do NOT use the IP of your PS3 TEST. However, if you happen to have a PS3 TOOL, then use it's IP.

So, you should have the SDK installed, and the environmental variable DTNETM set to 127.0.0.1. Once this is done, turn on your PS3 (in debugger mode) fire up the dtnetm app, and point it to the IP of your PS3, like so:

dtnetm -d IP_OF_YOUR_PS3

Keep that window open, in another window, go to your working directory (you may want to make a folder called work), and run bedbg -prepare. You should get a message saying:

You must login or register to view this content.

Another window (dtccons) should also pop up. If not, ensure DTNETM is exported properly

Dtccons is basically the way you will be communicating with the PS3, it's output gets sent to the screen, and your input in that window goes to the PS3.

Dumping the PS3 Game

The easiest way to dump the game is to use a provided file, called cellftp.self. Although it has ftp in its name, it is not a ftp program - it works more like a simple shell through the debugger output, and allows simple put/get of files to and from the PS3.

Copy the file to your work directory (from earlier), and run: bedbg -nodebug cellftp.self

You should get a message in dtccons along the lines of:

You must login or register to view this content.

If not, hit enter a few times, COMMAND> should pop up.

Issuing the “help” command will give you some usage examples, however for our purposes, stick in a BD-ROM, and type:

cd ../dev_bdvd/

This will change the directory to that of the BD-ROM.

Now, we want to get the PS3_GAME folder. You can do it simply by typing: put PS3_GAME

You must login or register to view this content.

This will copy the entire PS3_GAME folder to your HDD in the directory in which you ran "bedbg -prepare" from. I'd make sure to have enough free space on your PC's HDD to let this happen. Of course depending on the game you may need anywhere from 4-50GB, and it could take some time.

Once it is done, it will return you to the COMMAND> prompt – from here you can simply type exit, and it will say goodbye.

You must login or register to view this content.

Decrypting Executables

Games made prior to firmware 2.10, you could simply run the executables, dump them out of memory, and rebuild – it worked most of the time, was a bit of the pain, but it worked. Of course, since then Sony closed that hole – so now its a bit more challenging. Luckily, Sony provides patches for most games, online, through one of a handful of environments.

There are different NP (PlayStation Network) Environment:

np – PlayStation Network (ie, retail)
sp-int – Sony PlayStation Initial Environment
prod-qa – Production Quality Assurance Environment

There are also a few others (ei-np, q-spint, q-pqa, q-pmgt, pmgt, r-spint, ei-pmgt, r-pqa, r-pmgt, r-np, q2-spint, q2-pqa, q2-pmgt, mgmt, h-pmgt, q2-np, rc, etc), however those are all internal networks – and can not be accessed without a PS3 TEST/TOOL in internal mode.

For the sake of this guide, we are focusing on the accessible ones above. Of course, any package on the “np” (the retail) environment is encrypted with the retail package keys – short of an internal box, any TEST/TOOL over 1.60 will not be able to decrypt these. You could get the packages, downgrade, install, and upgrade again if needed, but it is of course, a pain to do.

There are however the sp-int and prod-qa environments which tend to have (for a short time) packages that a debug unit can decrypt. The biggest problem, is that they tend to only be available for a short time.

You can check
You must login or register to view this content. or You must login or register to view this content.
PS3-Debug.PS3News.com
to see if there is a package available - if not, and you happen to come across one, please add it in for the rest of the community!

So the trick becomes: Do you get a nice debug patch quickly which you can then decrypt, and re-use the SELF(s) to burn to disc, or boot from HDD. Or do you get a retail package, downgrade, become limited to where you can run it from – best bet is to find the debug package!

Getting a Debug Package

Your asking “How do I find a debug package?”. For starters, check
You must login or register to view this content. or You must login or register to view this content.
PS3-Debug.PS3News.com
for a debug patch. But, if its not at the site, its somewhat simple to check for it.

Boot up your PS3 to the XMB, make sure in debug settings that NP environment is set to “sp-int” or “prod-qa”, sign into PSN (with sp-int or prod-qa credentials, you can use the quick sign-up), and launch the game. If your in luck, it will say an update is available – download it!

To get the URL you have a few options. You could either sniff out the connection with something like Wireshark - that takes a bit more setup. Other times the URL is actually passed right to dtccons - so make sure you have the debugging windows open. Or, you could use any number of the PS3 Proxy applications to grab the link.

Package Extracting

Assuming you were lucky enough to get the link – now, using the tool “make_package_npdrm” from the SDK, you can extract the debug package:

make_package_npdrm -x PACKAGE-NAME.PKG

This will create a folder with the TITLE ID, which should, hopefully contain development versions of all of the executable files on disc. Alas, if not you are out of luck (for now), as you need to replace ALL encrypted executables with their non-encrypted development equivalents. Lets assume, that your game only needed one, EBOOT.BIN.

Copy out the eboot.bin, and run “unfself” on it: unfself EBOOT.BIN MyDecryptedGameName.elf

You will then have a nice, decrypted, ELF – now lets re-fake self it: make_fself MyDecryptedGameName.elf NewEBOOT.BIN

Of course, you can't just copy the original EBOOT over, as it is in NPDRM format (which run's from HDD), vs. running from wherever you want (PC, HDD, BD).

Now, to run it from a BD, you can simply remaster it with the BD Generator tool in the SDK, its fairly self explanatory - however if you want to save a disc, you can actually run it from your PC!

That PS3_GAME folder in your work directory can be served right up to the PS3 – you just need to (depending on the game) tweak the executable a bit. Basically, open up the “MyDecryptedGameName.elf” in a hex editor, look around for “dev_bdvd” entries, and replace them with “app_home”, then run make_fself on the ELF like stated above, and replace the Main EBOOT.BIN with your newly created one. Most games, and your set!

To get the game running from here, simply boot the system to the XMB, scroll down to “app_home/ps3_game” in the Game section, and hit X!

Final Thoughts

Of course, its not always that easy – assuming you only could find a retail package, you can still get the game running, but its a more involved process. You need to of course be able to install the package first. That means, either an old (60gb) TEST, an old TOOL, or a box in internal mode - it narrows the playing field (see the PS3 Test/Tool FAQ for more details on each).

Then, you can remaster the game to a disc pretty much the same way, but the system will run the executables that were installed from the patch PKG (automatically) from the HDD, vs the BD drive since it sees the data as a 'patch'. This way is a bit sloppy however, and its advised to find a real, development package – and help the community, share the link for the debug package at
You must login or register to view this content. or You must login or register to view this content.
PS3-Debug.PS3News.com
by clicking "Add Debug PSN Link" there!

This Guide is Copyright © 2010 PS3News.com.

READ MORE: You must login or register to view this content.

Well, apart from copy and paste, cool.

That's basically what NGU's "hacking scene" is these days.

I only copy and pasted to allow everyone to see this is legitimate. Simply posting a link would not have had the same effect. I truly believe that the unkn0wn and hunter have debug consoles, or a test kit. Just look around at some posts of theirs, they talk about debug methods on numerous sites.

I see how everyone complains about checksums but there are only 2 exact ways to make sure a checksum is correct

1. The Internet Solution: Go offline
2. A file inside of the .pkg itself. Solutions: Well it depends what type of file. A Text/XML file you simply re-write the checksums with the new one. Which is most likely the case.