PSP File (Research Thread)

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

th0mas
Posts: 43
Joined: Sun Apr 24, 2005 1:59 am
Location: Canada
Contact:

Post by th0mas »

Krevnik wrote:So here is the thing, Sony probably doesn't give a rats-ass if we find a public key used to verify binaries.
If (there are a number of if's to follow, hope it's still informative) the firmware is loaded into RAM for speed purposes, and if we can locate the public key, then we can patch it with our own public key (if we can trick the kernel to let us write to this portion of memory without segfaulting). Now we could validate our own binaries assuming we have the rest of the system figured out. Reboot, and the RAM is refreshed from the firmware and we're back to having the sony public key.

this is what a number of "softmod" exploits on the xbox do.
Krevnik
Posts: 71
Joined: Wed Mar 09, 2005 12:07 pm

Post by Krevnik »

Hmm, this is pretty tricky business still. Since a piece of code has to be signed in order to run, how can you patch it to run your self-signed code when it needs to be properly signed to apply the patch? (Catch-22)

The XBox has a couple of holes AFAIK, but the PSP seems to be a little tighter.
th0mas
Posts: 43
Joined: Sun Apr 24, 2005 1:59 am
Location: Canada
Contact:

Post by th0mas »

there are a number of potential buffer overflow exploits already being looked at, and I'm sure that's only a small subset of what may exist.
Krevnik
Posts: 71
Joined: Wed Mar 09, 2005 12:07 pm

Post by Krevnik »

Since Verisign is involved in the process (see the PSP Dump thread), it might be possible to circumvent the trust tree, but the more I research it, the less likely it seems.
Krevnik
Posts: 71
Joined: Wed Mar 09, 2005 12:07 pm

Post by Krevnik »

I have been mucking around with the Wipeout EBOOT/BOOT.BIN files myself... the header is rather interesting. I have been analyzing it in a hex editor while creating a Unix CLI which will dump a full header from EBOOT.BIN (the header is 336 bytes long, with 128 bytes at the end forming some sort of signature in Wipeout).

The value which seems to be fixed at 128 is probably the size of the signature, although it will be hard to confirm until we see something signed with something larger than a 1024-bit key.
MelGibson
Posts: 58
Joined: Sun Apr 10, 2005 10:19 pm

Post by MelGibson »

I've written a quick and dirty PSP Header Parser thats rougly based on Gorims SFO parser:

Update:

Fixed infinty loop bug under linux - thanks to fireether for pointing it out

Code: Select all

// PSPParse.cpp : Defines the entry point for the console 

application.
//

#include "stdafx.h"


/*
 * PSP File Parser v 0.1, based on Gorims SFO parser
 *
 * This source is licensed under the terms of the Academic Free License 
 */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define STRBUFSZ 512

// Some data type definitions for Intel Doze platforms, 2005/05/06

typedef unsigned int u_int32_t;
typedef unsigned short int u_int16_t ;
typedef unsigned char u_int8_t;


/* Change endianess*/ 
u_int32_t le32&#40;int i&#41;
&#123;
  unsigned char b1, b2, b3, b4;

  b1 = i & 255;
  b2 = &#40; i >> 8 &#41; & 255;
  b3 = &#40; i>>16 &#41; & 255;
  b4 = &#40; i>>24 &#41; & 255;

  return &#40;&#40;int&#41;b1 << 24&#41; + &#40;&#40;int&#41;b2 << 16&#41; + &#40;&#40;int&#41;b3 << 8&#41; + b4;
&#125;

u_int16_t le16&#40;short s &#41;
&#123;
  unsigned char b1, b2;
  
  b1 = s & 255;
  b2 = &#40;s >> 8&#41; & 255;

  return &#40;b1 << 8&#41; + b2;
&#125;


struct PSPHdr
&#123;
   u_int8_t		type&#91;4&#93;;
   u_int32_t	version;
   u_int16_t	sect1;
   u_int8_t		title&#91;28&#93;;
   u_int16_t	sect2;
   u_int32_t	size&#91;2&#93;;
   u_int32_t	unkwn_ptr&#91;3&#93;;
   u_int32_t	sect3;
   u_int32_t	nulls&#91;40&#93;;
&#125;;


char pspMagic&#91;&#93; = "~PSP";
char DefaultFile&#91;&#93; = "DATA.PSP";

int main&#40;int argc, char *argv&#91;&#93;&#41;
&#123;
   FILE      *PSPFile;
   char      *Filename;
   struct    PSPHdr   *header;
   u_int8_t  *psp;
   int       fsize, i, nc;


   Filename = &#40;argc != 2&#41; ? DefaultFile &#58; argv&#91;1&#93;;

   if &#40;!&#40;PSPFile = fopen&#40;Filename, "r+b"&#41;&#41;&#41;
   &#123;
      perror&#40;"File cannot be opened."&#41;;
      exit&#40;1&#41;;
   &#125;

   fseek&#40;PSPFile, 0, SEEK_END&#41;;
   fsize = ftell&#40;PSPFile&#41;;
   psp = &#40;u_int8_t*&#41;malloc&#40;fsize&#41;;
   rewind&#40;PSPFile&#41;;
   fread&#40;psp, fsize, 1, PSPFile&#41;;
   fclose&#40;PSPFile&#41;;

   if &#40;memcmp&#40;pspMagic, psp, 4&#41;&#41;
   &#123;
      printf&#40;"WARNING&#58; %s is not a PSP file !\n", Filename&#41;;
   &#125;

   header = &#40;struct PSPHdr*&#41;psp;


   

printf&#40;"=============================================================================\n"&#41;;
   printf&#40;"PlayStation Portable PSP File Data\n"&#41;;
   

printf&#40;"=============================================================================\n"&#41;;
   printf&#40;"\nFilename&#58; %s\n", Filename&#41;;

   //\tFilesize           &#58; %i\n", fsize
   
   printf&#40;"Exe-Type      &#58; %c%c%c%c\t\tFile Type           &#58; %08x\n\n"
	   ,header->type&#91;0&#93;,header->type&#91;1&#93;,header->type&#91;2&#93;,header->type&#91;3&#93;, le32&#40;header->version&#41;&#41;;

   printf&#40;"Title           &#58; %s\n", header->title&#41;;
   
   printf&#40;"Section1        &#58; %04x\t\tSection2            &#58; %04x\n", le16&#40;header->sect1&#41;, le16&#40;header->sect2&#41;&#41;;

  // printf&#40;"Section       &#58; %04x\n", le16&#40;header->sect2&#41;&#41;;
   printf&#40;"Size &#40;unenc.&#41;   &#58; %i\tEnc-to-Unenc Diff   &#58; %i\n", header->size&#91;0&#93;, abs&#40;header->size&#91;1&#93; - header->size&#91;0&#93;&#41;&#41;;

   if&#40;int&#40;header->size&#91;1&#93;&#41; == int&#40;fsize&#41;&#41;&#123;
   printf&#40;"Size &#40;enc.&#41;     &#58; %i\tequals Filesize     &#58; yes\n\n", header->size&#91;1&#93;&#41;;
   &#125;

   else&#123;
   printf&#40;"Size &#40;enc.&#41;     &#58; %i\tEquals Filesize     &#58;  NO!!!!\n\n", header->size&#91;1&#93;&#41;;
   &#125;



   nc = 0;
   for &#40;i = 0; i <= 2; i ++&#41;&#123;
   printf&#40;"Unkown Pointer%i &#58; %08x\tValue&#58;  %i\n",i+1, le32&#40;header->unkwn_ptr&#91;i&#93;&#41;, header->unkwn_ptr&#91;i&#93;&#41;;
   &#125;

   printf&#40;"Section3        &#58; %08x\n\n", le32&#40;header->sect3&#41;&#41;;

   printf&#40;"2 x usual NULLs &#58; %08x  %08x, followed by %08x\n",le32&#40;header->nulls&#91;0&#93;&#41;, le32&#40;header->nulls&#91;1&#93;&#41;, le32&#40;header->nulls&#91;2&#93;&#41;&#41;;
   printf&#40;"2 x usual NULLs &#58; %08x  %08x, followed by %08x &#40;last 3 bytes !?&#41;\n",le32&#40;header->nulls&#91;3&#93;&#41;, le32&#40;header->nulls&#91;4&#93;&#41;, le32&#40;header->nulls&#91;5&#93;&#41;&#41;;

   printf&#40;"Unkown Data     &#58; %08x\t Value&#58;  %i\n\n", le32&#40;header->nulls&#91;6&#93;&#41;, header->nulls&#91;6&#93;&#41;;
   
   printf&#40;"8 x usual NULLs &#58; %08x  %08x  %08x  %08x\n                  %08x  %08x  %08x  %08x\n",
   le32&#40;header->nulls&#91;7&#93;&#41;, le32&#40;header->nulls&#91;8&#93;&#41;, le32&#40;header->nulls&#91;9&#93;&#41;, le32&#40;header->nulls&#91;10&#93;&#41;,
   le32&#40;header->nulls&#91;11&#93;&#41;, le32&#40;header->nulls&#91;12&#93;&#41;, le32&#40;header->nulls&#91;13&#93;&#41;, le32&#40;header->nulls&#91;14&#93;&#41;&#41;;

   printf&#40;"Unkown Data     &#58; %08x\t Value&#58;  %i\n\n", le32&#40;header->nulls&#91;15&#93;&#41;, header->nulls&#91;15&#93;&#41;;
   printf&#40;"Key/MD5/Encrypted Start Sequence ??\n"&#41;;

   for &#40;i = 16; i < 28; i ++&#41;&#123;
   printf&#40;"%08x ",le32&#40;header->nulls&#91;i&#93;&#41;&#41;;
	 if &#40;&#40;i+1&#41;%4==0&#41;&#123;
		 printf&#40;"\n"&#41;;
	 &#125;

   &#125;

   if &#40;int&#40;header->nulls&#91;28&#93;&#41; == int&#40;header->size&#91;0&#93;&#41;&#41;&#123;
   printf&#40;"\nUnkown Data     &#58; %08x\t Value&#58;  %i  matches Size &#40;unenc.&#41;&#58; yes\n", le32&#40;header->nulls&#91;28&#93;&#41;, header->nulls&#91;28&#93;&#41;;
   &#125;

   else&#123;
   printf&#40;"\nUnkown Data     &#58; %08x\t Value&#58;  %i  matches Size &#40;unenc.&#41;&#58; NO!\n", le32&#40;header->nulls&#91;28&#93;&#41;, header->nulls&#91;28&#93;&#41;;
   printf&#40;"   Size &#40;unenc.&#41;&#58; %08x\t Value&#58;  %i\n", le32&#40;header->size&#91;0&#93;&#41;, header->size&#91;0&#93;&#41;;
   printf&#40;"   Size &#40;enc.&#41;  &#58; %08x\t Value&#58;  %i\n\n", le32&#40;header->size&#91;1&#93;&#41;, header->size&#91;1&#93;&#41;;

   &#125;
   printf&#40;"Unkown Data     &#58; %08x\t Value&#58;  %i      hint to %ibit AES ?\n", le32&#40;header->nulls&#91;29&#93;&#41;, header->nulls&#91;29&#93;, header->nulls&#91;29&#93;&#41;;
   printf&#40;"6 Values &#40;normally NULL&#41; %i, %i, %i, %i, %i, %i followed by 0x%08x\n",header->nulls&#91;30&#93;,header->nulls&#91;31&#93;, header->nulls&#91;32&#93;,header->nulls&#91;33&#93;, header->nulls&#91;34&#93;, header->nulls&#91;35&#93;, le32&#40;header->nulls&#91;36&#93;&#41;&#41;;

   

printf&#40;"=============================================================================\n"&#41;;


   return 0;
&#125; 

Here's the output of the latest Firmware 1.51

=============================================================================
PlayStation Portable PSP File Data
=============================================================================

Filename: firmware\1.51\content\DATA.PSP
Exe-Type : ~PSP File Type : 00080000

Title : updater
Section1 : 0101 Section2 : 0102
Size (unenc.) : 3703968 Enc-to-Unenc Diff : 336
Size (enc.) : 3704304 equals Filesize : yes

Unkown Pointer1 : 18300000 Value: 12312
Unkown Pointer2 : 68430f00 Value: 1000296
Unkown Pointer3 : b45f0300 Value: 221108
Section3 : 40004000

2 x usual NULLs : 00000000 00000000, followed by 004a1000
2 x usual NULLs : 00000000 00000000, followed by 004a1000 (last 3 bytes !?)
Unkown Data : 40702600 Value: 2519104

8 x usual NULLs : 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
Unkown Data : 0c000000 Value: 12

Key/MD5/Encrypted Start Sequence ??
7dd213c7 858fa3b3 0e728038 5f7dd546
a0eb88a2 9ff70b7a 77c9199c cd8a8efb
fc389e7b fec3b73b aa11d9db 28acabbd

Unkown Data : a0843800 Value: 3703968 matches Size (unenc.): yes
Unkown Data : 80000000 Value: 128 hint to 128bit AES ?
6 Values (normally NULL) 0, 0, 0, 0, 0, 0 followed by 0x0000000b
=============================================================================
Last edited by MelGibson on Thu May 12, 2005 8:02 am, edited 2 times in total.
fireether
Posts: 27
Joined: Fri Apr 22, 2005 8:40 am
Location: Rochester, NY

Post by fireether »

To compile on Linux:
-Comment out stdafx.h
-Change i = i++ to i++. Otherwise it will loop forever.
-g++ <name of file>.c -o <name of progra,>

I had to modify the code to get it to work so it wont loop forever..
But good job, it works and looks good.
fireether
Posts: 27
Joined: Fri Apr 22, 2005 8:40 am
Location: Rochester, NY

Post by fireether »

I know that the information for 1.51 has already been posted, but reposting here so it can be compared with 1.50.

bash-2.05b$ ./psp-psp-parser ./Unpacked150/UNKNOWN.PSP
=============================================================================
PlayStation Portable PSP File Data
=============================================================================

Filename: ./Unpacked150/UNKNOWN.PSP
Exe-Type : ~PSP File Type : 00080000

Title : updater
Section1 : 0101 Section2 : 0102
Size (unenc.) : 3737568 Enc-to-Unenc Diff : 336
Size (enc.) : 3737904 equals Filesize : yes

Unkown Pointer1 : d42f0000 Value: 12244
Unkown Pointer2 : 88410f00 Value: 999816
Unkown Pointer3 : b45f0300 Value: 221108
Section3 : 40004000

2 x usual NULLs : 00000000 00000000, followed by 00481000
2 x usual NULLs : 00000000 00000000, followed by 00481000 (last 3 bytes !?)
Unkown Data : d0f52600 Value: 2553296

8 x usual NULLs : 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
Unkown Data : 0c000000 Value: 12

Key/MD5/Encrypted Start Sequence ??
37bd421e 467612e3 b651a791 e184a08f
e48122d6 8c0e7902 f5bc5275 1388e811
a946c56e 69cde5ca cc8feda6 4adf3996

Unkown Data : e0073900 Value: 3737568 matches Size (unenc.): yes
Unkown Data : 80000000 Value: 128 hint to 128bit AES ?
6 Values (normally NULL) 0, 0, 0, 0, 0, 0 followed by 0x0000000b
=============================================================================
bash-2.05b$ ./psp-psp-parser ./Unpacked151/UNKNOWN.PSP
=============================================================================
PlayStation Portable PSP File Data
=============================================================================

Filename: ./Unpacked151/UNKNOWN.PSP
Exe-Type : ~PSP File Type : 00080000

Title : updater
Section1 : 0101 Section2 : 0102
Size (unenc.) : 3703968 Enc-to-Unenc Diff : 336
Size (enc.) : 3704304 equals Filesize : yes

Unkown Pointer1 : 18300000 Value: 12312
Unkown Pointer2 : 68430f00 Value: 1000296
Unkown Pointer3 : b45f0300 Value: 221108
Section3 : 40004000

2 x usual NULLs : 00000000 00000000, followed by 004a1000
2 x usual NULLs : 00000000 00000000, followed by 004a1000 (last 3 bytes !?)
Unkown Data : 40702600 Value: 2519104

8 x usual NULLs : 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
Unkown Data : 0c000000 Value: 12

Key/MD5/Encrypted Start Sequence ??
7dd213c7 858fa3b3 0e728038 5f7dd546
a0eb88a2 9ff70b7a 77c9199c cd8a8efb
fc389e7b fec3b73b aa11d9db 28acabbd

Unkown Data : a0843800 Value: 3703968 matches Size (unenc.): yes
Unkown Data : 80000000 Value: 128 hint to 128bit AES ?
6 Values (normally NULL) 0, 0, 0, 0, 0, 0 followed by 0x0000000b
=============================================================================
bash-2.05b$
MelGibson
Posts: 58
Joined: Sun Apr 10, 2005 10:19 pm

Post by MelGibson »

fireether wrote:To compile on Linux:
-Change i = i++ to i++. Otherwise it will loop forever.
Ohh.. thats definitly sloppy of me :D... Wonder why it works and doesn't complain under windows !? Gonna have to fix that in the source...
Krevnik
Posts: 71
Joined: Wed Mar 09, 2005 12:07 pm

Post by Krevnik »

It works because of the assignment order. It won't loop forever, but it is sloppy.

i = i++; assigns, then increments. So it is the equivilent of writing:

i = i;
i++;

Even if you wrote 'i = ++i', i would be incremented correctly.

This is definitely a bug, but not one that actually /does/ anything.

Additional: If it is indeed an infinite loop on Linux, then a bug report should be filed to GCC to get that fixed. That is definitely undesired compiler behavior.
fireether
Posts: 27
Joined: Fri Apr 22, 2005 8:40 am
Location: Rochester, NY

Post by fireether »

Krevnik wrote:It works because of the assignment order. It won't loop forever, but it is sloppy.

i = i++; assigns, then increments. So it is the equivilent of writing:

i = i;
i++;

Even if you wrote 'i = ++i', i would be incremented correctly.

This is definitely a bug, but not one that actually /does/ anything.

Additional: If it is indeed an infinite loop on Linux, then a bug report should be filed to GCC to get that fixed. That is definitely undesired compiler behavior.
It does loop forever, for sure. I had to hard-break out of the program (good ole CRTL-Z). It only looped forever at the points in the code that had i = i++;.

Most likely GCC follows i = i and ignores the ++. Either way, I agree that a bug report should be filed to GCC. However, when you look at it, (no offense) i = i++ IS sloppy code.

I'm using gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) so maybe somebody else could (if they want to, off topic) see if it also affects newer versions of gcc.
MelGibson
Posts: 58
Joined: Sun Apr 10, 2005 10:19 pm

Post by MelGibson »

fireether wrote: i = i++ IS sloppy code.
Thats for sure. And i apologize for that... happens when you want to get things finished fast late at night ;)

But back to topic - the PSP files:

From what I have gathered so far, there are 4 types of PSP files:
  • Firmware updates - File Type: 00080000
    Game executables - File Type: 00000000
    Library Files Type 1 - File Type: 06100000
    Library Files Type 2 - File Type: 06100100
All library files I have checked so far have a negative "Unkown Pointer2".
Type 2 Libraries have round about half the size encrypted compared to unencrypted.
In Type2 Libraries the Unkown Data field just after the assumed key/md5 field NEVER matcher Size (unenc.). In all other PSP file types this field matches.

I assume one Library file Type statically linked and the othe dynamically linked... but not sure which one is which.
Vyrus001
Posts: 30
Joined: Tue Apr 26, 2005 4:25 am

Post by Vyrus001 »

well im sure this is toeing the line of "things that can and can not be posted" but let me just say that when compareing code compiled with the devkit vs the debian "linux-mips-as", the devkit elf is quite a bit smaller...

btw, ive knowticed that the same eboot from the update is recognised when placed in any other folder other than update if it is in the games dir, and is apperintly read as a game. Might this be a way to run the same testing apps under diffrents modes to analyse error msgs ? (i.e. perhaps we can get away with some stuff if it dosent think it's an update but a game instead)
Guest

Post by Guest »

Vyrus001 wrote:well im sure this is toeing the line of "things that can and can not be posted" but let me just say that when compareing code compiled with the devkit vs the debian "linux-mips-as", the devkit elf is quite a bit smaller...
If you legally have a devkit, you are contractually under NDA and shouldn't be revealing stuff here. If you illegally have a devkit, it is no favor to folx here to be providing any information you have gained from it.
mrbrown
Site Admin
Posts: 1537
Joined: Sat Jan 17, 2004 11:24 am

Post by mrbrown »

It's also against the rules. Vyrus, read the forum rules here: http://forums.ps2dev.org/viewtopic.php?t=1567.

Repeat and you'll be banned.
steddy
Posts: 139
Joined: Mon Apr 04, 2005 3:53 am

Post by steddy »

Since this thread is back alive, let me post my findings on the ~PSP files so far from this thread: http://forums.ps2dev.org/viewtopic.php?t=1744

~PSP File format explained
Offset : Description
00-03 : ~PSP Magic Identifier
04 : File Type -
  • 00 - BIN
    06 - PRX Library
    07 - Driver / Service
05 : Sub Type (or kernel ring)?? -
  • 00 - User Module
    08 - Library Module / System
    10 - Kernel Module
06 : Compression flag - 00 Uncompressed, 01 Compressed
07 : Padding (00)
08-09 : 0x01 0x01 - Part of file name shown in uncompressed file (section 1?)
0A-25 : Filename (26 characters)
26-27 : 0x01 0x02 - Always the same (section 2?)
28-2B : Uncompressed file size
2C-2F : Compressed file size including header
B0-B3 : See below...

I think that the value of B0-B3 is used differently between compressed and uncompressed files. This actually suggests to me that it is related to the number of compressed bytes and is used by the compression functions, not the encryption functions. If this is the case then Sony would ignore it for uncompressed files and just set it to the file size.

Given my numbered list of points on how the file is reassembled to make the executable, it is most likely the number of compressed bytes to feed into the algorithm (step 5). Since encryption functions require 16 byte alignment, 0x2C-0x2F records the encrypted size for decryption and possibly signing.

Once the data is decrypted though, the decompression function needs to know how many bytes need decompressing. This figure is different since it doesn't include the headers and doesn't include the padding. If however no decompression is required then this information is not required and B0-B3 can contain anything.

Sorry for the duplication but this is the correct location for this information.

Steddy
Vyrus001
Posts: 30
Joined: Tue Apr 26, 2005 4:25 am

Post by Vyrus001 »

mrbrown wrote:It's also against the rules. Vyrus, read the forum rules here: http://forums.ps2dev.org/viewtopic.php?t=1567.

Repeat and you'll be banned.
my intention was simply to atempt to aid in ansuring some questions without devouching specific information, i apologize for failing at this.
skranker
Posts: 1
Joined: Thu May 26, 2005 11:05 am

error code 80020148

Post by skranker »

ok ive been messing around with the pbp unpacker for a while, and i finally thought of something, but if i sound like a dumb ass dont mind me cuz really dont know what im doin. so i figured either the data.psp or the data.psar had to be digitally signed by sony or whatever. then i thought hey i should take one of them and pack it in with the snes emulator. i used the psar file and packed it all in. it came up on the memory stick games on the menu but when i tried it it came up with 80020001. after that i thought i would try the data.psp. but the snes emulator already has a .psp file so there was a problem. then i just opened the .psp file from the update in word pad (wich was all encrypted er whatever) and copied and pasted the stuff from the .psp file of the snes into the other .psp file of the update. then again i compiled all of the files n things into another pbp file and tried it. that is when i got the error code 80020148. but the weird thing was that i actually saw the main menu thing for the snes before it went back to the xmb bar and stated the error. and mind u i have a version 1.5 psp so i thought some o u might want to know.
Vesty
Posts: 1
Joined: Fri Apr 08, 2005 4:09 am

Re: error code 80020148

Post by Vesty »

skranker wrote: but the weird thing was that i actually saw the main menu thing for the snes before it went back to the xmb bar and stated the error.
Er... You saw the SNES Emulator menu on your 1.5 PSP? As in, it launched the menu then crashed back out to the error message?

Sounds a little bizarre (wordpad??) so going to have to try this...
RATiX
Posts: 48
Joined: Sat Apr 30, 2005 5:02 pm

Post by RATiX »

Wow.. we might be getting somewhere... Rather than word, it might be better to open it up in a hex editor or something (I'm no expert, though...) and then see if there are any bytes which do important things.
Sonikku_a
Posts: 5
Joined: Tue May 24, 2005 12:18 pm

Post by Sonikku_a »

skranker , nothing personal but are you sure? That sounds a bit odd...but if you can send your file over to [email protected], at least i can verify your claim. otherwise, people here are going to eat you alive w/o proof :-)
mrbrown
Site Admin
Posts: 1537
Joined: Sat Jan 17, 2004 11:24 am

Post by mrbrown »

I think this one was long overdue. Moved to the 'sploit board.
piercer
Posts: 21
Joined: Fri Apr 01, 2005 4:45 pm

Post by piercer »

Mr Sonikku_a

Did Skranker send you his file?

Somehow I doubt it :-(
CMX
Posts: 1
Joined: Mon May 30, 2005 12:09 pm

Post by CMX »

the Unknown pointer1 is the EntryPoint

If you look at a game's EBOOT.BIN and BOOT.BIN, the BOOT.BIN is a regular ELF file, entrypoint is at offset 0x18

It will match the Unknown Pointer1 value.

And Unknown Pointer2 matches the section length inside the ELF header for the first section in the ELF header.
GotaruO
Posts: 3
Joined: Mon Jun 06, 2005 6:10 pm

Post by GotaruO »

Some more header field meaning:

Code: Select all

30-34&#58; Entry point
34-38&#58; Code section physical address
48-4c&#58; Data section virtual address
54-58&#58; Code section memory size
58-5c&#58; Data section memory size
ZID
Posts: 7
Joined: Wed Jun 08, 2005 9:05 pm
Location: United Arab Emirates

Post by ZID »

Hi,
this is my first post at PS2Dev forums, but I want to say if we found the
key how can we decrypt or encrypt the files ??
steddy
Posts: 139
Joined: Mon Apr 04, 2005 3:53 am

Post by steddy »

ZID wrote:Hi,
this is my first post at PS2Dev forums, but I want to say if we found the
key how can we decrypt or encrypt the files ??
DOH!
annerajb
Posts: 40
Joined: Thu Mar 31, 2005 6:16 am

Post by annerajb »

he does not says if we can he says how we are going to do it.
Phour20
Posts: 26
Joined: Fri May 06, 2005 1:38 am

Post by Phour20 »

yeah, me being a newbie to Encryption (never used it ever), what prog/app would we use.. Ive checked out a few free (or trial apps) recently in hopes to better understand but I havent found one that seems to do AES or maybe im just overlookin something..

my guess is thats what the ? is.. Just like Im asking..

thanks in advance.. :)-
steddy
Posts: 139
Joined: Mon Apr 04, 2005 3:53 am

Post by steddy »

If we knew everything required to encrypt it, then it would probably be a custom executable.

You may be able to use this, its certainly a valuable learning tool and allows you to SHA1 function names to find new ones and much more:-

http://www.cryptool.com/cryptool2.en.html

Steddy
Post Reply