In my other thread (which was locked... I don't think it's useless since PS2DIS doesn't currently decode PSP files because they're encrpted or compressed, but whatever) I decoded some of the R4000 opcodes into hex and binary. As near as I could tell, there was only one that took no arguments: sync. It's 0x0000000F.
Now, I reckon based on the description of sync in the R4000 user's manual, there ought to be at least one place in the firmware flasher and several in the actual firmware that utilize that opcode; yet it doesn't appear at all in DATA.PSP or DATA.PSAR from the Jap 1.5 firmware PBP.
I don't know much about AES, and don't pretend to. That said, does AES shift characters based on the key in a reliable manner? What I mean is, would there be a pattern that we could look for based on what we know the input was?
If this is a stupid idea, lock it up too. It's the only thing I can come up with that doesn't involve brute-forcing the key.
Shortcut to decrypting the PSP firmware file?
-
TerryMathews
- Posts: 19
- Joined: Thu Mar 31, 2005 5:35 am
-
Guest
No, that would be too easy, and what you are describing is still akin to brute forcing, the searching for known patterns.
None of the cryptos involved are likely to be able to be attacked directly. Only 3-letter agencies and Ph.D. Math cryptographers with too much time and research dollars on their hands can afford to lead such efforts (and that includes famous successful efforts in the past announced on the internet).
Besides, do not think for one moment there won't be a severe reaction from Sony if we are able to decrypt intellectual property meant to remain unseen. Not that Sony needs to worry that much, of course. But there might be some lines we need to define so that we don't cross them, and that can be hard to do.
For example, MagicGate has always been hands-off. We were able to homebrew without it and there was no need to touch things that were better off being left alone. Here, we cannot yet homebrew on the PSP, so people will grasp at anything. Still are there some rules we should define ?
None of the cryptos involved are likely to be able to be attacked directly. Only 3-letter agencies and Ph.D. Math cryptographers with too much time and research dollars on their hands can afford to lead such efforts (and that includes famous successful efforts in the past announced on the internet).
Besides, do not think for one moment there won't be a severe reaction from Sony if we are able to decrypt intellectual property meant to remain unseen. Not that Sony needs to worry that much, of course. But there might be some lines we need to define so that we don't cross them, and that can be hard to do.
For example, MagicGate has always been hands-off. We were able to homebrew without it and there was no need to touch things that were better off being left alone. Here, we cannot yet homebrew on the PSP, so people will grasp at anything. Still are there some rules we should define ?
-
TerryMathews
- Posts: 19
- Joined: Thu Mar 31, 2005 5:35 am
Well, someone feel free to correct me if I'm wrong, but the only way we're going to be able to create code that will work within the bounds of the XMB (PSP's OS) is to reverse-engineer the encryption/compression/signing method the PSP expects binaries to utilize. It doesn't have to be perfect, it just has to be such that the PSP sees what it wants to see.gorim wrote:Besides, do not think for one moment there won't be a severe reaction from Sony if we are able to decrypt intellectual property meant to remain unseen. Not that Sony needs to worry that much, of course. But there might be some lines we need to define so that we don't cross them, and that can be hard to do.
For example, MagicGate has always been hands-off. We were able to homebrew without it and there was no need to touch things that were better off being left alone. Here, we cannot yet homebrew on the PSP, so people will grasp at anything. Still are there some rules we should define ?
If we're not going to try and figure out that, the only other way to run code on the PSP is to buffer exploit the system and load our own OS/kernel into RAM. I don't think anyone wants to reboot their PSP into Linux every time they want to play an NES/SNES game if they can avoid it.
-
blackdroid
- Posts: 564
- Joined: Sat Jan 17, 2004 10:22 am
- Location: Sweden
- Contact:
Yes your idea of finding opcode patterns is stupid, I suggest reading a good book on cryptography to understand why and when the idea of finding patterns in cryptographed streams was abandoned.
And as gorim said we are able to run code on the PS2 without having the key.
If you want more opcodes that takes no args, grep through the mips opcode table in a recent gcc source, you will find some more, like the ever present nop wich we all love and adore.
And as gorim said we are able to run code on the PS2 without having the key.
If you want more opcodes that takes no args, grep through the mips opcode table in a recent gcc source, you will find some more, like the ever present nop wich we all love and adore.
Kung VU
-
TerryMathews
- Posts: 19
- Joined: Thu Mar 31, 2005 5:35 am
And as I said, the only way to do it on the PSP (just like on the PS2) is to overflow the system in some manner and replace what's in memory with your own code. That's fine on the PS2, since it doesn't run an underlying OS like the PSP does.blackdroid wrote:Yes your idea of finding opcode patterns is stupid, I suggest reading a good book on cryptography to understand why and when the idea of finding patterns in cryptographed streams was abandoned.
And as gorim said we are able to run code on the PS2 without having the key.
Drop the background processes on the PS2 and you lose nothing. Do the same on the PSP and you lose the functionality of the Home button, and the soft-off support.
My idea may very well have been "stupid", and I very well know what a nop is.
The PS2 does have an operating system. All of ps2dev goes through the PS2's OS to get anything done - for example you couldn't talk to the IOP without it. If you want to nitpick you could say half of the PS2's OS is in the kernel and the other half is in the official SDK or ps2sdk.TerryMathews wrote:And as I said, the only way to do it on the PSP (just like on the PS2) is to overflow the system in some manner and replace what's in memory with your own code. That's fine on the PS2, since it doesn't run an underlying OS like the PSP does.
Drop the background processes on the PS2 and you lose nothing. Do the same on the PSP and you lose the functionality of the Home button, and the soft-off support.
Anyway, once code is running on the PSP it will use whatever OS it uses, and you won't have to do anything special to work with it except to figure out how it works :). We've already seen that apps run in user mode (see attempts to dump the first 8MB of memory using the SFO hack), so my "guess" is that architecturally it isn't all that different from the PS2's kernel. Maybe they did add more "processes" or threads, who knows.
Like many posters you put the cart before the horse and start speculating on this and that. Just get code running and we'll see what happens. Anything before that is just blowing smoke.
"He was warned..."
Where did you found that XMB is the PSP's OS? XMB is the "Cross Media Bar" interface from Sony, which defines some GUI guidelines, but I don't see how this has to do something with the underlying OS. Some "official" information about the OS:TerryMathews wrote:Well, someone feel free to correct me if I'm wrong, but the only way we're going to be able to create code that will work within the bounds of the XMB (PSP's OS)
The OS might provide some system functions for graphics and IO, but the XMB is just a program which uses these functions. Perhaps it is an "utility applet":
I think we should not break the encryption (which is very unlikly anyway), but using something like a buffer overflow to execute code should be OK. And then reading the RAM and analyzing some code in order to make use of the PSP APIs for graphics and sound output and documenting the API or registers should be OK, too, but of course, only things we have written ourself and not providing decoded firmware binaries, PSP encryption keys or something similar.gorim wrote:Here, we cannot yet homebrew on the PSP, so people will grasp at anything. Still are there some rules we should define ?
I expect the "utility applets" are stuff like the screen you get when pressing HOME. As far as could be seen from the SFO experiments, the XMB interface is a normal application running in user space, and not part of the 8MB kernel.
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people
Having the courage
Getting over crisis
I rescue the people
-
Guest
It's a matter of trust. It's saying that we're just as serious about preventing the use of homebrew code for piracy as we are about making homebrew code in the first place. The trust comes from the decision that when homebrew conflicts with preventing piracy, we err on the side of preventing piracy. We don't just release something and claim no responsibility if it's used for ill.
-
Guest
Ichan, my response was a bit strong, for that I apologize. It need not have included any personal elements.
Suffice to say, the concepts of not interfering with copyrights and the industry business models are held important here. And it has served this community well.
Its often fashionable to hold nothing sacred, but people here are not out to make politics, screw businesses, or follow OSS religions. They see a console and want to run code, and do it without undue interference. And hey, they might be a part of that industry some day, so why not be a good boy/girl right now ? Can't hurt.
Suffice to say, the concepts of not interfering with copyrights and the industry business models are held important here. And it has served this community well.
Its often fashionable to hold nothing sacred, but people here are not out to make politics, screw businesses, or follow OSS religions. They see a console and want to run code, and do it without undue interference. And hey, they might be a part of that industry some day, so why not be a good boy/girl right now ? Can't hurt.