You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are prototypes of PSP games that are on DVD-R rather than UMD. These prototypes are special as they include multipart 2048 byte isos of an actual PSP image on the disc. The only other difference between these and UMDs is that PSP DVD-Rs are always understood to utilize the decrypted BOOT.BIN and not EBOOT.BIN, which seems to always be filled with null bytes. PSP UMDs use EBOOT.BIN, which are encrypted.
At this point, we always treat EBOOT.BIN as "md5" and BOOT.BIN as "alt_md5" regardless. This should probably change as nothing will ever match since you'll be comparing a purposely blank file to an encrypted file.
here are my thoughts:
so first we need to determine if the container is a psp dvd-r or a psp umd, that indicates the main executable used by the game. if its a psp dvd-r then the executable is BOOT.BIN, if it's a umd based proto then the executable is EBOOT.BIN. for psp dvd-rs, the BOOT.BIN file is decrypted already, we dont need to do anything besides take its hash. for EBOOT.BIN we need to decrypt it (and maybe strip it from non-data segments? since its an elf file?).
for psp dvd-rs:
BOOT.BIN - is md5
EBOOT.BIN - is alt md5
for psp umds:
EBOOT.BIN (decrypted) - is md5
EBOOT.BIN (encrypted) - is alt md5
then we should prolly adjust the alt composite sums to exclude any system files, so the BOOT/EBOOT.BINs, the ICON0.PNG, ICON1.PMF, PARAM.SFO, and PIC0.PNG/PIC1.PNG, UMD_DATA.BIN files
The text was updated successfully, but these errors were encountered:
There are prototypes of PSP games that are on DVD-R rather than UMD. These prototypes are special as they include multipart 2048 byte isos of an actual PSP image on the disc. The only other difference between these and UMDs is that PSP DVD-Rs are always understood to utilize the decrypted BOOT.BIN and not EBOOT.BIN, which seems to always be filled with null bytes. PSP UMDs use EBOOT.BIN, which are encrypted.
At this point, we always treat EBOOT.BIN as "md5" and BOOT.BIN as "alt_md5" regardless. This should probably change as nothing will ever match since you'll be comparing a purposely blank file to an encrypted file.
here are my thoughts:
so first we need to determine if the container is a psp dvd-r or a psp umd, that indicates the main executable used by the game. if its a psp dvd-r then the executable is BOOT.BIN, if it's a umd based proto then the executable is EBOOT.BIN. for psp dvd-rs, the BOOT.BIN file is decrypted already, we dont need to do anything besides take its hash. for EBOOT.BIN we need to decrypt it (and maybe strip it from non-data segments? since its an elf file?).
for psp dvd-rs:
BOOT.BIN - is md5
EBOOT.BIN - is alt md5
for psp umds:
EBOOT.BIN (decrypted) - is md5
EBOOT.BIN (encrypted) - is alt md5
then we should prolly adjust the alt composite sums to exclude any system files, so the BOOT/EBOOT.BINs, the ICON0.PNG, ICON1.PMF, PARAM.SFO, and PIC0.PNG/PIC1.PNG, UMD_DATA.BIN files
The text was updated successfully, but these errors were encountered: