No no, that's my job to do powerpoint slides :Dsteddy wrote:Emm... they look far to offical :)
Yep, I agree, signing before encrypting may be a safer choice, I chosed this schema as I was thinking the encryption could be done by the dev studio and not the authentication.... But it is not a relevant assumption... why the hell this session key would be generated by the studio...steddy wrote: I would have this point to make made in my original post..
3. Its safer and common practise to sign data BEFORE encrypting it. There are known crypto attacks against RSA if done the other way around.
Therefor, the signature is taken off the decrypted data, not the encrypted data. If these images come from a legit source then its possible Sony haven't done it this way, but it is common practice.
Also, maybe worth updating the diagrams to include compression as per my list on page 1.
Good work
Steddy
Here is the source code to decrypt data2.bin for those that are interested. It takes two parameters. Parameter 1 is the input filename and path and parameter 2 is the output filename and path. Eg. data2reader data2.bin datadecoded.binThe file loader should do all of the following and this may give a clue to those other fields:-
1. Decrypt the data using the Session key and IV value contained in the file (its possible this is encrypted with another key in ROM)
2. Hash the decrypted data with SHA1.
3. Decrypt the digital signature in the header with the Public key in ROM
4. Compare the output from 2 and 3 to ensure the file hasn't been tampered with and was created by Sony
5. Expand the file if its compressed.
6. Maybe write it to a temporary area unencrypted or just place it directly in memory.
Code: Select all
package data2reader;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.File;
import java.io.InputStream;
import java.io.OutputStream;
import net.scee.drm.mypsp.download.hash.SHA1CipherStream;
public class Data2Reader
{
private static final char HEX[] =
{
'0', '1', '2', '3', '4', '5', '6', '7', '8', '9',
'A', 'B', 'C', 'D', 'E', 'F'
};
public static void main (String[] args)
{
boolean bWrite=false;
File data2File=new File(args[0]);
if(args.length==2) {
bWrite=true;
}
long fileLength = data2File.length();
if(fileLength % 276L != 0L)
{
System.out.println("Error: File length not multiple of 276");
System.exit(1);
}
else
{
try
{
InputStream dis = new FileInputStream(data2File);
int nIdent = (int) (fileLength / 276L);
for(int i = 0; (long)i < nIdent; i++)
{
byte[] version = new byte[4];
byte[] hardwareId = new byte[20];
byte[] timeStamp = new byte[4];
byte[] nickName = new byte[208];
byte[] fingerprint = new byte[20];
byte[] key = new byte[20];
dis.read(version);
dis.read(hardwareId);
dis.read(timeStamp);
dis.read(nickName);
dis.read(fingerprint);
dis.read(key);
SHA1CipherStream cipher = new SHA1CipherStream(key);
cipher.xor(version);
cipher.xor(hardwareId);
cipher.xor(timeStamp);
cipher.xor(nickName);
cipher.xor(fingerprint);
System.out.println("Found identity: "+convertToString(nickName));
System.out.println("HardwareID: "+dump(hardwareId));
System.out.println("Version: "+dump(version));
System.out.println("TimeStamp: "+dump(timeStamp));
System.out.println();
if(bWrite==true) {
// Now output the file if required
OutputStream out = new FileOutputStream(args[1]);
out.write(version);
out.write(hardwareId);
out.write(timeStamp);
out.write(nickName);
out.write(fingerprint);
}
}
}
catch (Exception e)
{
System.out.println("Error: "+e);
}
}
}
public static final String convertToString(byte[] input)
{
try
{
int n=0;
while (input[n]!=0) n++;
return new String(input, 0, n, "UTF8");
}
catch(Exception e)
{
return null;
}
}
public static final String dump(byte a[])
{
StringBuffer buf = new StringBuffer();
for(int i = 0; i < a.length; i++)
{
buf.append(HEX[a[i] >> 4 & 0xf]);
buf.append(HEX[a[i] & 0xf]);
}
return buf.toString();
}
}
~PSP files are not signed by certificates. The rest of this thread is lacking any useful content. Locked.
Checksums do a pretty good job of preventing folks from tampering as well :P.steddy wrote:No MrBrown did.
~PSP files must be signed by certificates or Sony would have no way of preventing us running malicious code.
Steddy
Ah ah Mr Brown !!! You cannot stop like that !!! Tell us what you discovered !!! Did you dump the load*.prx ?mrbrown wrote:
Checksums do a pretty good job of preventing folks from tampering as well :P.
But here it is again: the certificates found in flash have nothing to do with ~PSP files.
My impression also. These are certificates for Sony websites, DNAS. Used your online connect disk lately ?mrbrown wrote:Checksums do a pretty good job of preventing folks from tampering as well :P.steddy wrote:No MrBrown did.
~PSP files must be signed by certificates or Sony would have no way of preventing us running malicious code.
Steddy
But here it is again: the certificates found in flash have nothing to do with ~PSP files.
Not really, since they contain nothing that cannot be recreated by the hacker. The signature does because its signed by the PRIVATE key which is NOT on the device (only the PUBLIC one).Checksums do a pretty good job of preventing folks from tampering as well :P.
This is not true for every PRX File:laichung wrote:I dont know anyone notice this before :
At 3C-3F :
Data.psp : 40 00 40 00
EBoot.psp : 40 00 40 00
Compressed prx : 10 00 10 00
no compress prx : 10 00 40 00
For Library Modulesit might be most of the time, but not for updates and Game executables... there 34-37 seems to be the section length inside the ELF header for the first section in the ELF header. (c.f. : http://forums.ps2dev.org/viewtopic.php?t=1463&start=30 )and for those prx I had checked, they have same value at 36-37 : 00 80
Seems to be like this.. nice findings.and 7C should be a flag , 01 for prx and 09 for bin , 0C for Update