Kernel Memory Dumping Tool

[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.

[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]

And lucky for you it comes with source as well (not that there is much of it :P)

I can't compile it. What is the PSPSDK? I hope it is not the official SDK.

[mrbrown]

I can't compile it. What is the PSPSDK? I hope it is not the official SDK.

Of course it's not the official SDK. pspsdk hasn't been released yet. But since you have source, you're sure to be able to get it to build another way.

[Shine]

Of course it's not the official SDK. pspsdk hasn't been released yet. But since you have source, you're sure to be able to get it to build another way.

Yes, finally I saw the two tricks :-) I'm not sure if the forum rules allow to post it, but would be more useful than the program, if someone else wants to built it without the PSPSDK or some other programs, like writing to kernel space.

PS: the temporary buffer is not necessary, sceIoWrite accesses the kernel space without problems with the two tricks on my PSP.

[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]

What is the trick here?

the module flags is the key to getting into kmode:

Code: Select all

        .section    ".xodata.sceModuleInfo","wa",@progbits
__moduleinfo:
        #.word  0x01011006
        .word   0x01011000
        .ascii  "PSPSDK"        #up to 28 char
        .align  5

the .word is important. if bit 12 is set to 1 it starts in kmode.

[steddy]

Thanks Vampire, appreciated.

Steddy

[Shine]

Is there something special about creating a thread called "update_thread", or is it something else.

The thread handling is some other nice work by TyRaNiD, which could be used to end programs like normal games, see http://forums.ps2dev.org/viewtopic.php?t=1723.

[fungus]

What is the trick here?

the module flags is the key to getting into kmode:

Code: Select all

        .section    ".xodata.sceModuleInfo","wa",@progbits
__moduleinfo:
        #.word  0x01011006
        .word   0x01011000
        .ascii  "PSPSDK"        #up to 28 char
        .align  5

the .word is important. if bit 12 is set to 1 it starts in kmode.

is this all there is to it ? - I'm getting 0x80020001 if I set the word at __moduleinfo to 0x01011000 - my app launches fine when I use the standard 0x01010000

I'm sure I'm missing something obvious - any help appreciated

fungus

[fungus]

What is the trick here?

the module flags is the key to getting into kmode:

Code: Select all

        .section    ".xodata.sceModuleInfo","wa",@progbits
__moduleinfo:
        #.word  0x01011006
        .word   0x01011000
        .ascii  "PSPSDK"        #up to 28 char
        .align  5

the .word is important. if bit 12 is set to 1 it starts in kmode.

is this all there is to it ? - I'm getting 0x80020001 if I set the word at __moduleinfo to 0x01011000 - my app launches fine when I use the standard 0x01010000

I'm sure I'm missing something obvious - any help appreciated

fungus

anyone ?

[konfig]

Could this mean we can do homebrew on 1.5 soon?

[Guest]

Could this mean we can do homebrew on 1.5 soon?

Doesn't seem that way to me. Looks more like it will soon be possible to have nearly full control over PSP at 1.0, which is currently hampered by lack of access to kernel mode.

[konfig]

Could this mean we can do homebrew on 1.5 soon?

Doesn't seem that way to me. Looks more like it will soon be possible to have nearly full control over PSP at 1.0, which is currently hampered by lack of access to kernel mode.

If really full control over 1.0 is performed, how psp loads and decrypts the 1.5 update pbp will be known, and then the following: 1.5 psp's elf loader.

But as you said, "nearly full control". Seems something is missing.

[Shine]

If really full control over 1.0 is performed, how psp loads and decrypts the 1.5 update pbp will be known, and then the following: 1.5 psp's elf loader.

Maybe you are right, a loader could be written, which runs on 1.5 PSP's, but how do you start it? It must be itself an encrypted program and there is no way to encrypt it, because you need the private key, which only Sony has.

Looks more like it will soon be possible to have nearly full control over PSP at 1.0, which is currently hampered by lack of access to kernel mode.

Programs can read and write kernel memory with TyRaNiD's tricks, do we need some more access? In theory now you could disassemble all and could reverse engineering most of the low-level hardware registers, too (not all, because some might be used in games, only), for example for low level kernel drivers when porting Linux.

[konfig]

If really full control over 1.0 is performed, how psp loads and decrypts the 1.5 update pbp will be known, and then the following: 1.5 psp's elf loader.

Maybe you are right, a loader could be written, which runs on 1.5 PSP's, but how do you start it? It must be itself an encrypted program and there is no way to encrypt it, because you need the private key, which only Sony has.

There is no need to write a new elf loader for 1.5.


full control of 1.0 ----> disasmble the 1.0 elf loader ----> know how 1.0 loads the 1.5 updater ----> decrypt the 1.5 updater ----> know what the updater do to the 1.0 system ----> know what the 1.5 elf loader is ----> know how to encrypt elfs to fit the 1.5 elf loader

That is what I thought. Once knowing how to let code run on 1.5, there is no need to write new loader to replace the 1.5 official one.

edit and add:

There may be shortcuts. It is quite possible that 1.5 and the 1.0 use the same encrypt method, and 1.5 loader just does not let the unencrypted elf run.

[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]

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.

You are wrong. Try Google for public/private key encryption and read something about this.

[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]

"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

Has anyone actually found out how savegames are encrypted yet? It seems to me that this knowledge might not only be useful for homebrew (i.e. finding a savegame related exploit) but also for utilities on the PC to allow management and editing of save games.

[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]

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 :)

Tnank you. I now understand the situation.

I've seen many threads here before about finding key in the software. So I thought key was stored in software.

As you said, if the key is stored in some hardware rom, it is hard to get. What's more, if sony put the encryption/decryption method and the key altogether, turn them into a custom chip(a full hardware chip, no rom needed. Or even not in the form of a chip, just some unshaped circuit), Could we never do homebrew on it?

[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]

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.

So far, just feeding the PSP an encrypted prx to decrypt would be a major milestone IMHO.