thirdparty/ppsspp
2
0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Perform another PS1 eboot check before checking the PSAR magic.

Browse source 
It seems as if some PS1 eboots out there are malformed and will get past the PSISOIMG0000 check, so check the PARAM.SFO category, too. If the eboot gets past that too, PPSSPP will probably still crash, so we're screwed at that point anyway.
This commit is contained in:
The Dax 2014-03-03 11:46:26 -05:00
parent cc93e78076
commit 8342846609
1 changed files with 25 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

25
Core/Loaders.cpp
View file

@ -27,6 +27,8 @@
#include "Core/MemMap.h"
#include "Core/Loaders.h"
#include "Core/System.h"
#include "Core/ELF/PBPReader.h"
#include "Core/ELF/ParamSFO.h"
// TODO : improve, look in the file more
IdentifiedFileType Identify_File(std::string &filename)
@ -138,6 +140,29 @@ IdentifiedFileType Identify_File(std::string &filename)
return FILETYPE_UNKNOWN_ELF;
}
else if (id == 'PBP\x00') {
// Do this PS1 eboot check FIRST before checking other eboot types.
// It seems like some are malformed and slip through the PSAR check below.
PBPReader pbp(filename.c_str());
if (pbp.IsValid()) {
if (!pbp.IsELF()) {
size_t sfoSize;
u8 *sfoData = pbp.GetSubFile(PBP_PARAM_SFO, &sfoSize);
{
recursive_mutex _lock;
lock_guard lock(_lock);
ParamSFOData paramSFO;
paramSFO.ReadSFO(sfoData, sfoSize);
// PS1 Eboots are supposed to use "ME" as their PARAM SFO category.
// If they don't, and they're still malformed (e.g. PSISOIMG0000 isn't found), there's nothing we can do.
if (paramSFO.GetValueString("CATEGORY") == "ME") {
ERROR_LOG(LOADER, "PS1 EBOOTs are not supported by PPSSPP.");
return FILETYPE_PSP_PS1_PBP;
}
}
delete[] sfoData;
}
}
if (psar_id == 'MUPN') {
return FILETYPE_PSP_ISO_NP;
}