I found something you may find a bit interesting...
I unpacked the 1.5.2(?) update EBOOT.PBP, and then i unencrypted the Data.PSP file using the prx decryptor to successfully get an unencrypted .elf file... while i was scrolling down through all the stuff I found something interesting... there is another PSP file nested inside Data.PSP. Im guessing it is a PSAR Driver: "~PSP......scePSAR_Driver..." (thats how it starts...). I copied and pasted everything after ~PSP and put it in a new .psp file, and i decrypted that using the prx decryptor, and it gave me an unencrypted elf file...
Could this possibly help in figuring out PSAR...? If you want a copy of the PSAR driver please pm me (if this is against the rules then dont PM me and forget that I suggested that idea).
I really hope this helps!
(I dont know if this has already been found but i have dont a forums search and it doesnt look like anyone has found this yet...)
Discussion of the PSAR file format
> ... there is another PSP file nested inside Data.PSP.
In fact there are 10 extra drivers/libraries (as well as the main program)
-----
> ...if this is against the rules then ...
Sharing of any (unauthorized) copyrighted material is against the rules.
Generally explaining how to get the data, or posting a program is ok. Like the firmware grab program - the program is ok to share, the results are not -- Sony copyrighted material. Slightly different rules if the data comes from a UMD.
Might I politely suggest writing a relatively simple program (eg: a modified prx decrypt) to double decrypt and save the results to memory stick. Be sure to include all prx modules. That's ok to share and may spur more interest in the topic.
----
re: scePSAR
Relatively small module, only ~8KB, four exported entries (3 used). Doesn't appear to access the PSAR file directly, but it looks like you load in the data and pass in memory blocks to the library for decoding.
> it's not trivial to decrypt PSAR files. Others have done it successfully though.
I someone has this working already, please post info.
=======
[I gave up on it a while ago, but with a pending 2.0 release it becomes more interesting]
DISCLAIMER
this won't help in the various "downgrading" attempts. You can't run the initial homebrew program on the 1.51/1.52/2.0 firmware -- unless a new exploit is found - and if an exploit is found "downgrading" is not necessary!
However this is potentially interesting if you want to look at the new firmware (perhaps to use in your homebrew apps). Much more interesting with the 2.0 firmware release.
In fact there are 10 extra drivers/libraries (as well as the main program)
Code: Select all
scePSAR Driver
sceChkuppkg
sceLflashFatfmt
sceTestMode driver
IplUpdater -- does the NAND writing
sceSuspendCaneler
sceUmdEx driver
LeptonUpdater for 103 -- I assume for the "1.0" devices
LeptonUpdater for 150 -- I assume for the "1.50" and "1.51" devices
sceReboot - replacement rebooter> ...if this is against the rules then ...
Sharing of any (unauthorized) copyrighted material is against the rules.
Generally explaining how to get the data, or posting a program is ok. Like the firmware grab program - the program is ok to share, the results are not -- Sony copyrighted material. Slightly different rules if the data comes from a UMD.
Might I politely suggest writing a relatively simple program (eg: a modified prx decrypt) to double decrypt and save the results to memory stick. Be sure to include all prx modules. That's ok to share and may spur more interest in the topic.
----
re: scePSAR
Relatively small module, only ~8KB, four exported entries (3 used). Doesn't appear to access the PSAR file directly, but it looks like you load in the data and pass in memory blocks to the library for decoding.
> it's not trivial to decrypt PSAR files. Others have done it successfully though.
I someone has this working already, please post info.
=======
[I gave up on it a while ago, but with a pending 2.0 release it becomes more interesting]
DISCLAIMER
this won't help in the various "downgrading" attempts. You can't run the initial homebrew program on the 1.51/1.52/2.0 firmware -- unless a new exploit is found - and if an exploit is found "downgrading" is not necessary!
However this is potentially interesting if you want to look at the new firmware (perhaps to use in your homebrew apps). Much more interesting with the 2.0 firmware release.
Quick overview and trying to bring this topic up-to-date:
The .PSAR file is an encrypted and scrambled archive of individual files to be written to the "flash0:" volume. The format has changed a little over time (from the original 1.00 "bogus" update to the current 2.00 update)
The .PSP file is the updater program. It includes necessary support libraries. The format of the program has changed over time too.
-----
The PSP program:
The .PSP program is a PRX file that can be decrypted using the SDK 'prxdecrypt' sample. For earlier versions, it contains the program with the support libraries tacked on the end as PRX files (ie. PRXs inside of a PRX) as mentioned by 'l3vi'.
In firmware version 2.0, they changed the layout so the support libraries are stored inside the main program itself in scrambled form.
[as a general rule, when the Sony engineers see the homebrew folks have figured out a file format, they will change it to make it more obscure]
The main data decoding from the PSAR file is done in the "scePSAR" helper library. It does some of its own descrambling, and calls the system for decryption using one of the built in magic/public keys.
------
The PSAR data file.
The original version PSAR file has an obvious plain-text structure intermixed with encrypted contents. Check the first page of this thread for discussion that goes back to January.
When you discover the block boundaries, you can run it through the system decryption engine (magic key #6) and extract two blocks for each file (one the file name, AKA "TypeA" and the other compressed data, AKA "TypeB")
Later updates (1.5x and 2.0) scrambled the plain-text parts of the file to make the structure harder to figure out [see the general rule]. Now using magic decryption key #14.
I suspect the next firmware update will include a different structure with additional changes to obscure the format even more.
Bottom line: you can decrypt the current version 2.0 firmware (and the slightly older 1.52) version with a simple program that runs through the .PSAR data file, extracts/unscramble/decrypts/expands the data blocks and gives them human readable file names.
See this thread for the results of the 2.0 firmware dump file names: http://forums.ps2dev.org/viewtopic.php?t=2829
NOTE: all done under "fair user" reverse engineering under the rules of the DMCA.
I'm still working on the compressed data block format (aka TypeB). As before, if someone has figured this out already, please share so I don't have to reinvent everything ;-<
The .PSAR file is an encrypted and scrambled archive of individual files to be written to the "flash0:" volume. The format has changed a little over time (from the original 1.00 "bogus" update to the current 2.00 update)
The .PSP file is the updater program. It includes necessary support libraries. The format of the program has changed over time too.
-----
The PSP program:
The .PSP program is a PRX file that can be decrypted using the SDK 'prxdecrypt' sample. For earlier versions, it contains the program with the support libraries tacked on the end as PRX files (ie. PRXs inside of a PRX) as mentioned by 'l3vi'.
In firmware version 2.0, they changed the layout so the support libraries are stored inside the main program itself in scrambled form.
[as a general rule, when the Sony engineers see the homebrew folks have figured out a file format, they will change it to make it more obscure]
The main data decoding from the PSAR file is done in the "scePSAR" helper library. It does some of its own descrambling, and calls the system for decryption using one of the built in magic/public keys.
------
The PSAR data file.
The original version PSAR file has an obvious plain-text structure intermixed with encrypted contents. Check the first page of this thread for discussion that goes back to January.
When you discover the block boundaries, you can run it through the system decryption engine (magic key #6) and extract two blocks for each file (one the file name, AKA "TypeA" and the other compressed data, AKA "TypeB")
Later updates (1.5x and 2.0) scrambled the plain-text parts of the file to make the structure harder to figure out [see the general rule]. Now using magic decryption key #14.
I suspect the next firmware update will include a different structure with additional changes to obscure the format even more.
Bottom line: you can decrypt the current version 2.0 firmware (and the slightly older 1.52) version with a simple program that runs through the .PSAR data file, extracts/unscramble/decrypts/expands the data blocks and gives them human readable file names.
See this thread for the results of the 2.0 firmware dump file names: http://forums.ps2dev.org/viewtopic.php?t=2829
NOTE: all done under "fair user" reverse engineering under the rules of the DMCA.
I'm still working on the compressed data block format (aka TypeB). As before, if someone has figured this out already, please share so I don't have to reinvent everything ;-<
You guys are really good at this. Kudos!
(I wish I could hire you guys for reverse engineering the GT4 game and filesave compression, as we're starting the annual Board Challenge competition soon, and our replay file inspector was a great help for both managing the competition and detecting foul play. I'm even willing to bet I could raise some few hundred bucks from the community - thousands - to get it done. If anyone happens to be interested, let me know ... I can describe what the format looked like in preview and demo versions, and GT4 Prologue, before they encrypted it)
(I wish I could hire you guys for reverse engineering the GT4 game and filesave compression, as we're starting the annual Board Challenge competition soon, and our replay file inspector was a great help for both managing the competition and detecting foul play. I'm even willing to bet I could raise some few hundred bucks from the community - thousands - to get it done. If anyone happens to be interested, let me know ... I can describe what the format looked like in preview and demo versions, and GT4 Prologue, before they encrypted it)