Software Design Information Respository

[Neila]

(voted as unrelyable and taken down)

[Guest]

In the act of splitting out backup/warezing related posts that hijacked this thread, some innocent bystander were caught in friendly fire, so I am pasting them back in here. My apologies.

80020130 - file read error
80020001 - generic kernel error (default)
80020148 - PRX type unsupported
800200D9 - failed to allocate the memory block

This info seems to have some from some official development documentation... The guy didn't mention any NDA, but expect that it existed and either he or someone he knew violated it.

a Quick summary of information and speculation:

UMD:
Contents of (some) Demo disk:
528 Bytes - PARAM.SFO
12171 Bytes - ICON0.PNG
120832 Bytes - ICON1.PMF
85299 Bytes - ICON1.PNG
82029 Bytes - PIC1.PNG
87212 Bytes - SND0.AT3
3387376 Bytes - DATA.PSP
11183216 Bytes - DATA.PSAR

The memory stick update (eboot) and I suppose any game have the same files(or part of them) packed in PBP.

Looks like the contents of a known eboot.pbp leak, not a demo UMD.

[Pavel_]

.PSP _are_ containing key tables for hardware decoder. Positive.
.PSAR is crypted executable/overlays etc. Positive.

Im off...

Nazis

[pixel]

Im off...

Nazis

Great. That way, we won't need to ban you.

[Neila]

(the first post is updated)

[mc]

I am still not clear on the RSA's Publik Key Infrastructure.
I assume that the main idea is having public and private key to decrypt a file.

Not quite. You only need one key to encrypt and only one to decrypt. If you encrypt with the public key, you need the private one to decrypt. If you encrypt with the private key, you need the public one to decrypt.

Usually the guy with the private key also has the public one (on account of it being public, and he probably generated the key pair in the first place), but it is not required for the infrastructure to work. The distinction "public" and "private" is purely by convention, because for most practical uses you want to share one of the keys and keep one to yourself.

Also, you woudln't use RSA to encrypt a file, but rather you would RSA-encrypt a key for a symmetrical crypto (e.g. AES) and then encrypt the file with that.

[Neila]

(update)

[morbo]

I would wager all of these efforts to decrypt may run into some difficulties if Sony has embedded the keys at the bottom of that 90nm asic. I.e. buried logic in the lower layers of the chip.

I have yet to hear of anyone layer peel the logic from a 90nm device. If they have buried the secret in that asic I dont think casual hackers will get anywhere near it. (I work in the chip biz).

My pessimistic assessment is that key is pure unobtainium.

[Neila]

(update)

[th0mas]

I'm unsure who speculated originally that the PSP contains the private key/public key pair on the PSP itself, but I question the validity of that statement.

We may be talking about different keys for different purposes, but one can only assume that sony did something similiar to what microsoft did to the xbox, something like:

There is a single, unified keypair for the authentication of games. Sony keeps the private key private, signing licensed games that have passed their test procedures. Each PSP contains solely the public key, used to authenticate the game.

the question of "how is the game authenticated" comes up. Well, we hear about AES in every second sentence regarding PSP encryption. What if:

the game were encrypted with an AES key (unique to each game).
this AES key is encrypted via the PSP private key and stored alongside the game in the header. When it comes time to load, the PSP grabs the AES key (decrypting it via the public key stored internally), and uses that to AES decrypt the game's contents.

This doesn't make full sense, I'm only bringing it up because I don't see the sense in the prior description either. My scenario doesn't make full sense because if this were the case, the public key would have to be guarded incredibly well - if it were recovered, each and every game could be decrypted. I'm sure the public key IS well secured, but I dunno.


My reasoning why the original poster's description is invalid is because, if each PSP contains it's own public/private keypair, then it can only decrypt data that it itself encrypted. Each game in that case would have to be signed to whichever PSP wants to use it, which we already know is not the case (obviously).


Maybe sony's repeated mention that all code run on the PSP is encrypted (and iirc, hardware AES support?) is a big hint in some direction.

(this is all conjecture, all most likely completely incorrect.)

[Neila]

(update)

[pedroleite]

This probably:

https://eval.rsasecurity.com.au/downloa ... index.html

[Neila]

thanx pedroleite

post updated, and speculations removed.

[th0mas]

Note: read the document yourself. I very likely interpreted some of it incorrectly; it's lunch and I'm only half here.

I gleamed some information from the BSAFE specifications (linked in original post, http://quimby.gnus.org/internet-drafts/ ... afe-00.txt ).

The basic concept is that you provide a nice modularized environment for encryption. Modular in the sense that, a single set of functions ( B_EncryptInit, B_EncryptUpdate, and B_EncryptFinal) are the functions called to do encryption, independent of what algorithm is used. The way one determines which algorithm used is by the creation and passing of an "algorithm object" to the encryption functions. From the doc:

1.4 The Algorithm Object

In the example, B_EncryptInit, B_EncryptUpdate, and B_EncryptFinal
use an algorithm object called desAlgorithm. An algorithm object is
used to hold information about an algorithm's parameters (for
example, the DES initialization vector), and to keep a context during
a cryptographic operation (for example, DES encryption).

Before it can be used by BSAFE, an algorithm object must be created
and set with B_CreateAlgorithmObject and B_SetAlgorithmInfo.

Every algorithm object that is created by B_CreateAlgorithmObject
must be destroyed by B_DestroyAlgorithmObject. For security, when
BSAFE destroys an algorithm object, it zeroizes any sensitive memory
that the object allocated, as well as freeing it. Note that an
algorithm object can be used for either encryption or decryption, but
not for both. You must create separate algorithm objects to handle
each case. Once an algorithm has been set, it should not be reset, so
that once B_SetAlgorithmInfo has been called for a particular
algorithm object, it should not be called for the same object until
it has been destroyed and recreated.

As shown in Section 4, B_SetAlgorithmInfo has three input arguments,
algorithmObject, infoType, and info. algorithmObject is the name of
the algorithm object you are setting. infoType is one of the AI
algorithm info types listed in Section 2. The algorithm info type
specifies which algorithm to use, such as DES-CBC, as well as the
format of the algorithm information supplied by info.

As shown in Section 2, the format of info supplied to
B_SetAlgorithmInfo for AI_FeedbackCipher is a pointer to a
B_BLK_CIPHER_W_FEEDBACK_PARAMS structure that holds the necessary
information for the encryption object. This data includes the
encryption method name ("des"), the feedback method name ("cbc"), and
a pointer to an ITEM structure that contains the 8 bytes of the
initialization vector. In the example, the data in the item structure
is the iv input argument to EncryptData.

The description of the various algorithm objects takes up the majority of this paper.

As well as various encryption algorithms (RSA, DES(as of 1999), DSA, SHA1, etc..), there are objects that support extracting random bytes from hardware, initializing public/private keypairs and accellerator tables, and similiar helping functions.

To use the encryption/decryption functions the other object required is a Key object. From the text:

1.5 The Key Object

In the example, B_EncryptInit uses a key object called desKey. A key
object is used to hold a key's value, such as the DES key, and to
supply this value to functions such as B_EncryptInit that need a key.
A key object is also used to receive the output of key generation
such as B_GenerateKeypair.

Before it can be used by BSAFE, a key object must be created and set
with B_CreateKeyObject and B_SetKeyInfo. Every key object that is
created by B_CreateKeyObject must be destroyed by B_DestroyKeyObject.
For security, when BSAFE destroys a key object, it zeroizes any
sensitive memory that the object allocated, as well as freeing it.
Once B_SetKeyInfo has been called for a particular key object, it
should not be called for the same object until it has been destroyed
and recreated.

Other points of interest:
- When calling an encryption function you can supply the library with a callback function (referred to as the "Surrender" function, as in.. the library surrenders control to the calling program) that can update state, and potentially cancel, during encryption.

- you can only link in a subset of the algorithm objects instead of all of them. This is done by maintaining a list of the objects you want to compile into the app.

- also provided are a reimplementation of malloc, free, etc (named T_malloc, T_free, ...). Assumably these are secure versions of the originals, maybe locking memory permissions?


It's my guess that if the PSP is using B-SAFE, they added support for the PSP AES hardware (in other words, there's some new algorithm objects that are optimized for the PSP) and that all encryption/decryption calls are made through the BSAFE API. That's just a guess obviously, but if I were using a global system like BSAFE I would ensure that its use was truly global.

anyways, better technical detail is obviously in the document itself, including header file examples (with a lot of #define'd static flags and whatnot). This file is definitely should be the first step introduction to BSAFE for anyone wanting to know more.

[Neila]

UMD update: