So I tried the idea, can you fit a cracktro/pre-loader in the sectors before the volume descriptor (16)? The answer is surprisingly yes, but this isn't as great as it might seem.
Sectors 0, 1, 2, 3 are zero-filled so they are fine to use.
4 is the license data, which depending on what console it is has to match the region. Some consoles must have this matching so it can't be used for additional data.
5-11 are the logo data, which is the real issue. By having some of the PS-EXE data where the logo data is, the console never gets past the white sony screen (tested on SCPH-1000 and SCPH-5501, both don't care about sector 4 data so this is the actual issue.
12, 13, 14, 15 are 'reserved' zero-filled sectors as well. Besides sector 12 being abused for EDC-based detection in some of the late Japanese games, these are fine as well to use.
So how do I know this technically works? I'm using sectors 0-13 to fit a PS-EXE and it does actually work just fine with a soft-mod (Tonyhax International with SCPH-1000).
adding-file.png
cdmage.png
So realistically, if your executable is 2048*4=8192 (0x2000) bytes or lower you can put it at LBA 0-3 and it completely works.
Possible fixes:
1) If you can somehow place an unsigned char array of sector 4-11 user data at 0x2001 to whatever in the middle of the executable and have it end up in the exact sectors 4-11 that need that data, you might be able to continue to use sectors 12-15 for the rest of the exe?
2) If you did 2 files, stage 1 is 0-3 and stage 2 is 12-15.
Again the problem is nothing but issues after sector 4, because even if you do one of the above solutions those EDC protected games will not work correctly because they lock up the game if sector 12 EDC checksum is non-zero (which it would be after writing the PS-EXE, and if it's not, then it would corrupt the user data of the sector by trying to 'fix' the user data it thinks is corrupted).
An idea with this would maybe be even to put a small bit of assembly at sectors 0-3 which just reads a PS-EXE too large for just 4 sectors off of a memory card and runs that as a stage 2. Again you do have 0x2000 bytes to work with that causes zero issues.
Don't mean to clutter up this thread but I've never seen anyone try anything similar. This is a 3rd possible way to do a cracktro that is somewhat realistic.