| View previous topic :: View next topic |
| Author |
Message |
Shazz
Joined: 31 Aug 2004
Posts: 244
Location: Somewhere over the rainbow
|
|
| Back to top |
|
 |
Guest
|
 Posted: Tue May 24, 2005 11:01 pm Post subject: |
 |
|
| Hey Shazz, that looks cool...did you make that slide yourself ? or what was the source ? :) |
|
| Back to top |
|
|
Shazz
Joined: 31 Aug 2004
Posts: 244
Location: Somewhere over the rainbow
|
| Posted: Tue May 24, 2005 11:11 pm Post subject: |
|
|
Yep by myself :D or maybe some images ripped from Google, no $ony material...
_________________
- TiTAN Art Division -
http://www.titandemo.org |
|
| Back to top |
|
|
steddy
Joined: 04 Apr 2005
Posts: 139
|
| Posted: Tue May 24, 2005 11:49 pm Post subject: |
|
|
Emm... they look far to offical :)
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 |
|
| Back to top |
|
|
Shazz
Joined: 31 Aug 2004
Posts: 244
Location: Somewhere over the rainbow
|
| Posted: Wed May 25, 2005 12:03 am Post subject: |
|
|
| steddy wrote: | Emm... they look far to offical :)
|
No no, that's my job to do powerpoint slides :D
| 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 |
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...
So in this case, the binary will be decrypted before authentication check
So I think you're right... the plaintext binary should be signed first :D
I'll update my slides !
About compression, Do you think it is a separated process, I should have seen somewhere some kind of modified encrypting algortihms which performs packing while encrypting too... no ?
I can add the step but quite unclear for me...
Thanks for the comment :D
I always thought a good schema worths tons of words :D
_________________
- TiTAN Art Division -
http://www.titandemo.org |
|
| Back to top |
|
|
steddy
Joined: 04 Apr 2005
Posts: 139
|
| Posted: Wed May 25, 2005 3:06 am Post subject: |
|
|
Well, you sure are good at those slides :)
Its also possible that the session key is NOT encrypted, but just stored in the file. I would leave that step in your slides for now though since its more complete. These are the decode steps I had which mention decompression... I recommend re-reading the entire thread on how offset 6 is used:
| Quote: | The 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. |
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.bin
| Code: | 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();
}
}
|
As you can see its a modification of the code presented by piercer in the PSP Download Agent thread. It requires the jar file libraries provided in the following download from Sony:
https://www.yourpsp.com/download/static/downloadapplet/MyPSPAppletS.jar
Steddy |
|
| Back to top |
|
|
Shazz
Joined: 31 Aug 2004
Posts: 244
Location: Somewhere over the rainbow
|
| Posted: Wed May 25, 2005 3:59 am Post subject: |
|
|
Eh eh that's really nice to exchange my primary thoughts to your discoveries to finaly have a relevant security architecture with an good level of confidence :D
Really great... I'll update it tomorrow
eh eh and funny I downloaded yesterday Wipeout packs and so I decompiled the applet too :D Need to go in depth into :D
By the way, I think sony did a good job... implementing a true PKI in a portable console is really something I never saw before...(but I did not see a lot of things :D, MagicGate is far away...)
_________________
- TiTAN Art Division -
http://www.titandemo.org |
|
| Back to top |
|
|
djhuevo
Joined: 10 Mar 2005
Posts: 47
|
| Posted: Wed May 25, 2005 4:35 am Post subject: |
|
|
very nice slides Shazz
_________________
sobreviviendo en la tierra de los trolldev |
|
| Back to top |
|
|
Shazz
Joined: 31 Aug 2004
Posts: 244
Location: Somewhere over the rainbow
|
| Posted: Wed May 25, 2005 6:17 pm Post subject: |
|
|
Thanx DJ Huevo :D Did you find something to use the base64 bug ?
By the way, I have updated the slides based on the discussion... Considering the number of certificates in the firmware, probably some steps stil missing...
_________________
- TiTAN Art Division -
http://www.titandemo.org |
|
| Back to top |
|
|
Shazz
Joined: 31 Aug 2004
Posts: 244
Location: Somewhere over the rainbow
|
| Posted: Mon May 30, 2005 6:44 pm Post subject: |
|
|
Mr Brown said:
| Quote: | | ~PSP files are not signed by certificates. The rest of this thread is lacking any useful content. Locked. |
Do we miss something ????
_________________
- TiTAN Art Division -
http://www.titandemo.org |
|
| Back to top |
|
|
steddy
Joined: 04 Apr 2005
Posts: 139
|
| Posted: Mon May 30, 2005 6:48 pm Post subject: |
|
|
No MrBrown did.
~PSP files must be signed by certificates or Sony would have no way of preventing us running malicious code.
Steddy |
|
| Back to top |
|
|
mrbrown
Joined: 17 Jan 2004
Posts: 1536
|
| Posted: Mon May 30, 2005 7:50 pm Post subject: |
|
|
| 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 |
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. |
|
| Back to top |
|
|
Shazz
Joined: 31 Aug 2004
Posts: 244
Location: Somewhere over the rainbow
|
| Posted: Mon May 30, 2005 7:57 pm Post subject: |
|
|
| 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. |
Ah ah Mr Brown !!! You cannot stop like that !!! Tell us what you discovered !!! Did you dump the load*.prx ?
Tell us our I'll plug the SIO in your nose ! ;-)
www.0xd6.org is back ! :D
ah ah ! I was sure $ony threatened you :D after you forced the poor ps1drv coder to harakiri himself :D
Nice to see you on board :D
_________________
- TiTAN Art Division -
http://www.titandemo.org
Last edited by Shazz on Mon May 30, 2005 9:25 pm; edited 1 time in total |
|
| Back to top |
|
|
pedroleite
Joined: 10 Apr 2005
Posts: 39
|
| Posted: Mon May 30, 2005 8:01 pm Post subject: |
|
|
| mrbrown wrote: | | 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 |
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 ? |
|
| Back to top |
|
|
steddy
Joined: 04 Apr 2005
Posts: 139
|
| Posted: Tue May 31, 2005 5:17 am Post subject: |
|
|
| Quote: | | Checksums do a pretty good job of preventing folks from tampering as well :P. |
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).
They don't have to be in the certs directory. The public key could be in some other part of the ROM (like the BOOTSTRAP area which contains the decryption functions).
The only way you could be 100% sure about this is if you have decoded the encoded files already. Come on, do share.
Steddy |
|
| Back to top |
|
|
laichung
Joined: 06 May 2005
Posts: 123
|
| Posted: Fri Jun 03, 2005 3:32 pm Post subject: |
|
|
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
and for those prx I had checked, they have same value at 36-37 : 00 80
another common thing:
49 - 4B and 55-57 always has same value , but 48 and 54 may different
if two of them are same , 58 - 59 will be zero
if 48 and 54 has different value , then 58 - 59 may have value
and 7C should be a flag , 01 for prx and 09 for bin , 0C for Update |
|
| Back to top |
|
|
MelGibson
Joined: 10 Apr 2005
Posts: 58
|
| Posted: Sat Jun 04, 2005 9:48 pm Post subject: |
|
|
| 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
|
This is not true for every PRX File:
for example \flash0\kd\audio.prx has a "file type" flag: 06 10 01 00
so it it commpressed but has 10 00 40 00 at 3c-3f
same for flash0\kd\blkdev.prx which ist compressed, too but also has
10 00 40 00 at 3c-3f
| Quote: |
and for those prx I had checked, they have same value at 36-37 : 00 80
|
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 )
| Quote: |
and 7C should be a flag , 01 for prx and 09 for bin , 0C for Update |
Seems to be like this.. nice findings. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
