It's hard to know exactly what is in a package file, but it would certainly help. For some reason I have a gut feeling that these files may not be fully encrypted, but just compressed and signed. The signature, of course, need be some form of public/private key instead of a simple hash. I'd guess the signature to be within the 0x60-0xbf section within the header, or alternatively 0x100-0x13f. I'm prone to believe content starts at 0x140 as pointed to by the qword at 0x20.
Also, I believe you are correct and there is an eboot.bin although I am unsure if it is encrypted in the same style as the blu-ray disks, or if it is a regular signed exec. If it is in the style of blu-ray it'll need an encryption key somewhere, which I'd guess in the opposite section of the above 0x60/0x100 choices. Of course, there is some heavy guessing here.
With respect to known text (credits) will be hard to search for because of compression/encryption. I have no idea what algorithms have been applied. I haven't seen any text fragments that you would see on straight compression of a text file, which goes completely against my gut feeling above... unless it is a compression scheme using a bit stream and not a byte stream. Someone with PSP knowledge can probably give us some starting points on which compression and encryption algorithms to look at. I expect there will be some overlap.
It'd be useful if we could collect as many different versions of the same program to compare the headers to find things like region codes, for instance the differences between the same demo from the NA store and the JP store... You are welcome to check this out.
I have been thinking about hex editing values with one of the (small) working demos to figure out which regions can be changed before errors are triggered. It makes sense that some validation is stored in the file, as there appears to only be a single connection for demos (no additional credit card transactions.) Knowing what triggers the errors and what the different errors are may potentially be useful... You are more than welcome to try this too , but be warned it is tedious. The smaller the file the better.
To be honest though, I think we have better chances of attacking the encrypted/compressed licence agreement in the firmware update files. These files are tiny, and the plaintext isn't to hard to come by. It'd likely give insight to the PKG files, and the signed executables themselves.
It doesn't help that I am generally lazy, and a lot if not all of the above is really theory and guesses.