param.sfo parsing bug still in 2.01
Well, sort of. Remember that thread where akumaatr was pursuing a possible 2.0 exploit using a malformed eboot file that crashes the psp?
Well, 2.01 still crashes from the file - if, and only if, the data in the UPDATER_VER field is exactly 80 bytes long. If it's shorter or longer, the file shows up as corrupted data. If it's 80 bytes, the PSP will hang and power off after about 10 seconds.
Here's my take on what happens: obviously they added some error checking to the sfo parsing, but made an off-by-one mistake in the size comparison. So my theory is, it's something like (very simple / probably incorrect example):
This is a common C mistake in overestimating the size of a buffer by not taking into account the trailing 0 byte. So 1 byte is being overwritten somewhere in memory by a 0, but I don't know what, and I'm pretty sure that it probably can't be exploited :(
int dumb_example(char *memptr)
// memptr is pointing to the buffer from which we need to copy the data
// the data is: 80 nonzero characters, plus 4 trailing zeroes
if (strlen(memptr) > 80) return CORRUPT_DATA;
strcpy(buffer, memptr); // whoops, copied 81 chars! The last one, a 0, has overwritten something.
// do something with buffer, like check it for allowed versions
But maybe someone more knowledgable in the PSP's function call mechanism/ memory management/whatever might have something to add?
(I included the sample eboot that crashes my 2.01 psp, it goes in psp/game/update)