forums.ps2dev.org

[TyRaNiD]

Seeing as someone has already posted a strings dump of the kernel I thought we should get out a tool so everyone with v1.0 can dump their kernel memory regions too. And lucky for you it comes with source as well (not that there is much of it :P)

have fun and don't do anything with it you shouldn't :)

http://ps2dev.org/kb.x?T=1154

[djhuevo]

thanks for sharing TyRaNiD...

sometimes people forget to share this kind of stuff, and do thing in private form.
_________________
sobreviviendo en la tierra de los trolldev

[Sirwhizz]

thanks to bad I don't have a 1.0 to try it out. Patience I feel is the way to go. I think in the long run all this work on the 1.0 will help out for later firmware out there.

[Shine]

[mrbrown]

[Shine]

[steddy]

Where are the support headers required to compile it available from? Are you part of another application already released? I presume its a standards PS2DEV toolchain without need for the Sony SDK.

What is the trick here? Sorry for being dumb but the code looks normal. Is there something special about creating a thread called "update_thread", or is it something else.

This is a dev forum after all so it would be nice of the devs explained the example presented.

Steddy

[Vampire]

[steddy]

Thanks Vampire, appreciated.

Steddy

[Shine]

[fungus]

[fungus]

[konfig]

Could this mean we can do homebrew on 1.5 soon?

[Guest]

[konfig]

[Shine]

[konfig]

[TyRaNiD]

As shine pointed out unless you can get the encrytion key (whether symmetric or asymmetric is doesn't really make a difference) then knowing how the psp loads a file is close to irrelevant.

It is certainly the case that with access the kernel mode you will be able decrypt existing PSP files (once you find the appropriate routines to do it) but that doesn't mean you will be any closer to encrypting your own file. But that said if that happened there would be little Sony could do to stop our software running on any PSP.

I would definetly say that the 1.5 uses the exact same encryption and the exact same key as it is going to be hardware based, no firmware update would change that, They also cannot (easily) just change it in later hardware revisions as that would break existing software on UMD.

[konfig]

edit:
I've carefully read the above again. I think I know what you means.
But I don't understand why symmetric/asymmetric makes no difference.
As the text referenced, is the decryption key also the encryption key?


original:
I am not an expert on AES encrypt method. But I read some basic matters about the AES. Here's some important words:


"AES is a symmetric encryption algorithm processing data in block of 128 bits. A bit can take the values zero and one, in effect a binary digit with two possible values as opposed to decimal digits, which can take one of 10 values. Under the influence of a key, a 128-bit block is encrypted by transforming it in a unique way into a new block of the same size. AES is symmetric since the same key is used for encryption and the reverse transformation, decryption. The only secret necessary to keep for security is the key."


So I think now if we can decrypt data, we can also encrypt it.
I don't know if it is right. Please tell me if I am wrong.

[Shine]

[TyRaNiD]

Of course if you can get the key you can encrypt the file as well, but this is the point we are trying to make and I will only say it once ;)

If, as is very very likely, there is hardware in the psp to do the encryption then it is also likely that the key is stored in hardware. Now a simplistic interface sony could have provided is you send a block of data and it will process it. In the decryption case it will obviously decrypt the block and return it to the user. You never see the key itself just the end result. Now you can imagine that the likelyhood Sony would have also added an encrypt facility as well to be pretty low (though never say never).

Now these types of systems can be broken, I seem to recall a IBM ATM box being tricked into giving out it's keys, and it might be feasible to do similar here but I think it is unlikely. The other method some people like to talk about is taking the top off the chips and running they under a microscope to read out the key. While this is a relatively trivial process if you are talking about a few kb of rom (which is easily identifiable) a 256 bit key hidden inside some custom hardware would not be and might require extensive reverse engineering. Still not impossible but very very difficult.

Of course this is even supposing they are using a symmetric key :)

[0xdeadface]

"Now you can imagine that the likelyhood Sony would have also added an encrypt facility as well to be pretty low (though never say never). "

Savegames?

0xdf

[TyRaNiD]

If you believe Sony would be stupid enough to use the same key for both executables and savegames then you must be slightly mad ;)

Of course would be amused if proven wrong.

[Danj]

[0xdeadface]

"If you believe Sony would be stupid enough to use the same key for both executables and savegames then you must be slightly mad ;) "

Maybe not same key, but it might tell more about the encryption in general?

I must admit I have no knowledge whatsoever about encryption.

0xdf

[konfig]

[TyRaNiD]

Well because the encryption is still under software control as long as you can get code running in another way (game exploit or even kernel) then things like checking for encrypted executables can just be patched out.

But who knows what the future holds.

[konfig]

If sony really uses 128bit AES on elf, and we really take full control of the 1.0 psp. We can give the 1.0 psp an unencrypted elf and tell the psp it is an encrypted file, let psp 'decrypt' the file and write the data to ms for us.

Because encryption and decryption key is the same, 'decrypt' the original data is equal to encrypt it.

Maybe though this way we can let the 'decrypted' elf run on 1.5? -- if AES, and key not change from 1.0 to 1.5.

edit:
Key could not change due to backwards software compatibility.

[Guest]

If I remember correct with respect to symmetric encryption, that won't work.

decrypt(a) != encrypt(a)

Even though it is true that:
a == decrypt(a_encrypted) == encrypt(a_decrypted)

The reason being that though the encryption (here "decryption" is a synonym for encryption, just in the opposite direction) is symmetric both directions, the results of both directions of encryption are not the same.

What you are suggesting results in this when the psp tries to decrypt it
-- decrypt(decrypt(a))
rather than the
-- encrypt(decrypt(a))
you were hoping for.

[Marco_N]