Same thing as Hello World PSP on a 1.5... nothing. :Psq377 wrote:Out of curiosity, what does this do on a 1.5?
PSP [firmware] Dump [program]
Niiiiice Nem :) Does your toolchain permites to display shift-jis or euc japanese characters ?
(´ヘ｀;)　なんで１．５アップデート実行したかな～＊しくしく*
(´ヘ｀;)　なんで１．５アップデート実行したかな～＊しくしく*
I got to say a big thank to you nem . Great work !!
Now I have some ideas why those file existed in the flash , I guess those files are part of the XMB. I think after the bootstrap finish bootup the PSP , it will start the XMB if no UMD or apps selected , which mean that XMB just a standalone program.
If the idea is right , we can look forward to having our own media centre just like xbox. (May be we can view DIVX movie in future too! haha)
Also I think people can give up about the certificate , every stantard browser have these file , I dont think these certificate is using for encrypt/decrypt the prx.
If hardware encrypt/decrypt really does on PSP , I think game developer no need to call a function to encrypt/decrypt the apps when it run , except encrypt/decrypt a save file. But I wonder , are they using the same key to encrypt/decrypt the save file and apps? I'm sure you can find the key to decrypt the save file from those game dump , but how about the key to run program? It really hard to trace it.
I think the bootstrap call the decrypt function when we run the apps. But that's the part we dont know too much about it. Also that's why we can run program on 1.0 but not 1.5. We got to keep working.
Thanks all!
Now I have some ideas why those file existed in the flash , I guess those files are part of the XMB. I think after the bootstrap finish bootup the PSP , it will start the XMB if no UMD or apps selected , which mean that XMB just a standalone program.
If the idea is right , we can look forward to having our own media centre just like xbox. (May be we can view DIVX movie in future too! haha)
Also I think people can give up about the certificate , every stantard browser have these file , I dont think these certificate is using for encrypt/decrypt the prx.
If hardware encrypt/decrypt really does on PSP , I think game developer no need to call a function to encrypt/decrypt the apps when it run , except encrypt/decrypt a save file. But I wonder , are they using the same key to encrypt/decrypt the save file and apps? I'm sure you can find the key to decrypt the save file from those game dump , but how about the key to run program? It really hard to trace it.
I think the bootstrap call the decrypt function when we run the apps. But that's the part we dont know too much about it. Also that's why we can run program on 1.0 but not 1.5. We got to keep working.
Thanks all!
nem wrote: laichung:
Total size of the files in flash0: is around 12MBytes. Where are those files come from? My obserbation/guess as follows:
- Memory chip on board contains 32MByte SDRAM and 32MByte FlashROM.
- 32MByte FlashROM consists of 1MByte bootstrap area and 31MByte disk storage area.
- Disk storage area have two partitions, 24MByte flash0: and 4MByte flash1:
- flash0: as system file volume, flash1: as configuration file volume
SONY says 32MByte SDRAM is divided to two parts, 8MByte kernel memory and 24MByte user memory.
User memory seems to be 0x08800000..0x09ffffff.
When system starts up, some files/modules are loaded to kernel memory, not all.
I haven't claimed they are used for encryption, but signing. Sony has also mentioned code signing in their promotion of security features, which means not only do we need to crack any encryption, we have to crack the signature too. (Or just bypass all this via some sort of exploit that allows unencrypted/unsigned code, like the one on the 1.00 firmware)laichung wrote:Also I think people can give up about the certificate , every stantard browser have these file , I dont think these certificate is using for encrypt/decrypt the prx.
I seriously doubt Sony would be setting themselves up as a Certificate Authority, and Verisign as the Primary Certificate Authority, and NOBODY else if it was for a 'standard browser'. It is being used for code signing. The presense of the BSAFE certificates are also key, since those provide some form of confirmation of what is behind the encryption on wrieless communication. Plus, if you look at the modules, there isn't anything for SSL, so while SSL might be in the http lib, it still doesn't account for the BSAFE and SCE certificate authorities.
The thing is, there is a difference between full-software, hardware-assist, and full-hardware encryption. Signatures and the like are a great way to securely provide the AES encryption key, ensuring knowledge of the source of the code/save file. Remember, the encryption isn't there just because, it is there to prevent unauthorized code from executing (i.e. anyone not paying Sony license fees). Their design will reflect these goals (code-signing).If hardware encrypt/decrypt really does on PSP , I think game developer no need to call a function to encrypt/decrypt the apps when it run , except encrypt/decrypt a save file. But I wonder , are they using the same key to encrypt/decrypt the save file and apps? I'm sure you can find the key to decrypt the save file from those game dump , but how about the key to run program? It really hard to trace it.
Here you admit we don't know much about the decryption mechanism for executables. So, how can you claim that the certificates (which include a timestamp authority, which is useful for game save timestamping, but really no other purpose on a system like this) aren't somehow attached to the system?I think the bootstrap call the decrypt function when we run the apps. But that's the part we dont know too much about it. Also that's why we can run program on 1.0 but not 1.5. We got to keep working.
Thanks all!
I bring up the issues that should be considered to increase the breadth of what is looked into, and possibly get someone to go 'Aha!' and maybe stumble on some information they didn't before. I don't have a 1.00 PSP, although I have gained a fair amount of knowledge of reverse engineering from mucking about on my PS2 and other projects in my past. I don't think it is wise to dismiss /anything/ simply because it appears to be useless at first.
Now if the files are dumped to the memstick, would that in essence be able to be reconstructed into a firmware 'downgrade' for those of us stuck on 1.5?
As well, if it were possible to downgrade to 1.0, perhaps a similarly constructed program could be run during the upgrade from 1.0 to 1.5 to possibly find where the encryption measures are contained? It seems to me that the encryption/signed software only came in the 1.5 update. Perhaps if a unit being upgraded to 1.5 has program to dump the 1.5 upgrade files to the memstick as they are being installed we can find a way to circumvent this encryption/signing method?
Just a thought...
As well, if it were possible to downgrade to 1.0, perhaps a similarly constructed program could be run during the upgrade from 1.0 to 1.5 to possibly find where the encryption measures are contained? It seems to me that the encryption/signed software only came in the 1.5 update. Perhaps if a unit being upgraded to 1.5 has program to dump the 1.5 upgrade files to the memstick as they are being installed we can find a way to circumvent this encryption/signing method?
Just a thought...
May be or may be not. We just get some files from flash roms doesnt mean we got the whole firmware. As nem said , the bootstrap area cannot access by the program. Unless we can run a program to read the flash rom from begin to the end , then write it back to correct position , I think we cant put 1.5 PSP back to 1.0
And the most important thing is , we cant run any program in 1.5 , what can we do ??haha~~~
And the most important thing is , we cant run any program in 1.5 , what can we do ??haha~~~
F9zDark wrote:Now if the files are dumped to the memstick, would that in essence be able to be reconstructed into a firmware 'downgrade' for those of us stuck on 1.5?
As well, if it were possible to downgrade to 1.0, perhaps a similarly constructed program could be run during the upgrade from 1.0 to 1.5 to possibly find where the encryption measures are contained? It seems to me that the encryption/signed software only came in the 1.5 update. Perhaps if a unit being upgraded to 1.5 has program to dump the 1.5 upgrade files to the memstick as they are being installed we can find a way to circumvent this encryption/signing method?
Just a thought...
While you /can/ do whatever you like with those CA, what would there be a use for Sony to be a CA for websites alone? They can get certificates for that a lot cheaper than setting up a few CAs.
Sony has stated their connection to BSAFE, and signed code. This is evidence that this is true. I was just annoyed that someone shrugged off these certs as 'nothing' when code-signing requires these certs and Sony has been midly open about their code-signing.
Sony has stated their connection to BSAFE, and signed code. This is evidence that this is true. I was just annoyed that someone shrugged off these certs as 'nothing' when code-signing requires these certs and Sony has been midly open about their code-signing.
My guess about why sony need their own CAs because PSP have "downloadable game/apps/firmware" feature. BSAFE is a safe connection between internet and PSP , but it cant make sure the things you download from internet is came from sony (or a place cert. by sony). That's just a step to protect your PSP from download a virus.
Does CAs essential for encrypt/decrypt? I dont know , I think KEY is more than CAs(from my point of view).
Anyway , thanks for your hard working in PSP development.
Does CAs essential for encrypt/decrypt? I dont know , I think KEY is more than CAs(from my point of view).
Anyway , thanks for your hard working in PSP development.
Krevnik wrote:While you /can/ do whatever you like with those CA, what would there be a use for Sony to be a CA for websites alone? They can get certificates for that a lot cheaper than setting up a few CAs.
Sony has stated their connection to BSAFE, and signed code. This is evidence that this is true. I was just annoyed that someone shrugged off these certs as 'nothing' when code-signing requires these certs and Sony has been midly open about their code-signing.
I don't disagree with the BSAFE bit, but considering Japanese owners discovered that Ad-Hoc transmission is also encrypted, BSAFE is very likely used there.
Well, here is the thing... apps are:
- Encrypted
- Signed
If neither is correctly done, the app will likely not be loaded by firmware. This forms the basis of 'trusted code'. You can't just encrypt it, you also have to verify that it was authorized to run via a signature that is trusted. Remember, Sony is protecting their license income, not the code.
So, how do we sign? With a private key of course. A certificate is really just a bit of encoded information, a public key, and a signature to verify the certificate is authentic (signed by the public key's counterpart, encrypting the hash of the certificate). The certificate also signed by the CA, to setup actual trust that this certificate is vouched for, which also contains an encrypted hash of the certificate being vouched for, but contains some normal information about which certificate owner signed it so trust can be established.
This system is pretty secure, as long as the public key isn't compromised in such a way that the private key is discovered from the public key (which is difficult, try factoring a number in the range of 2^1024 looking for only TWO factors).
I think encryption is a problem, yes, and should probably be looked at first since it will be the first to be worked around/defeated. However, the signature poses a huge threat, since barring exploits, the system is secure enough that we cannot feasibly defeat it (and when we do, Sony will not care about the platform as it has developed the next one).
My personal opinion is to delve into the encryption to figure out EXACTLY what is going on, then if there is a signature that is verified (very likely IMO) by the firmware, instead of banging against that for awhile, focus entirely on alternative methods, since a direct attack on such a system would be a waste of time.
Well, here is the thing... apps are:
- Encrypted
- Signed
If neither is correctly done, the app will likely not be loaded by firmware. This forms the basis of 'trusted code'. You can't just encrypt it, you also have to verify that it was authorized to run via a signature that is trusted. Remember, Sony is protecting their license income, not the code.
So, how do we sign? With a private key of course. A certificate is really just a bit of encoded information, a public key, and a signature to verify the certificate is authentic (signed by the public key's counterpart, encrypting the hash of the certificate). The certificate also signed by the CA, to setup actual trust that this certificate is vouched for, which also contains an encrypted hash of the certificate being vouched for, but contains some normal information about which certificate owner signed it so trust can be established.
This system is pretty secure, as long as the public key isn't compromised in such a way that the private key is discovered from the public key (which is difficult, try factoring a number in the range of 2^1024 looking for only TWO factors).
I think encryption is a problem, yes, and should probably be looked at first since it will be the first to be worked around/defeated. However, the signature poses a huge threat, since barring exploits, the system is secure enough that we cannot feasibly defeat it (and when we do, Sony will not care about the platform as it has developed the next one).
My personal opinion is to delve into the encryption to figure out EXACTLY what is going on, then if there is a signature that is verified (very likely IMO) by the firmware, instead of banging against that for awhile, focus entirely on alternative methods, since a direct attack on such a system would be a waste of time.
noob idea
probably a dumb as hell idea...but maybe yall could just rewrite the bios to get rid of the signing check and flash it? like vid. card bios's--ive seen some rewritten to enable OCing
or with the analogy with wimdows and linux...write your own OS for the thing (or just edit theirs)
just a thought...
or with the analogy with wimdows and linux...write your own OS for the thing (or just edit theirs)
just a thought...
-
Guest
Re: noob idea
Cart before the horse.hanakuma wrote:probably a dumb as hell idea...but maybe yall could just rewrite the bios to get rid of the signing check and flash it? like vid. card bios's--ive seen some rewritten to enable OCing
or with the analogy with wimdows and linux...write your own OS for the thing (or just edit theirs)
just a thought...
What you suggest can be done on any embedded device, in theory. Often is done in reality for cool gadgets. But it requires a minimal understanding of the hardware. Takes time.
BTW, what you suggest has implications for warezing. We cannot support activities that make it easy for warezing to occur. A gray area I know with such new hardware since its hard to know what is and isn't kosher with so little information still.
-
Guest
Ace, the rules of the forum state you may not ask people to send copyrighted materials to you, especially bios dumps, files, etc... You want them, find the program that lets you do it on your own PSP.
You have been warned. Next forum rules violaton is a ban. You may wish to read up before your next post.
You have been warned. Next forum rules violaton is a ban. You may wish to read up before your next post.
Last edited by Guest on Thu May 12, 2005 4:05 pm, edited 1 time in total.
If someone else would try it:F9zDark wrote:I would try it with mine, since I hate the damn background colors not being interchangeable, but my PSP is 1.5. So until there is a workaround for the 1.5 signing I can't do a damned thing.
I've written a FileTool to select a file from the Memory Stick (ms0:) and copy the selected file from the Memory Stick to the Flash (flash0:/vsh/resource/01.bmp).