Man I wish I knew ^_^. I'm praying that sony possibly used a readily available compression algo because I'm about to start testing the blocks of data that looked compressed with zlib and such. Here is a good article (and site altogether) that explains the idea. "https://www.openrce.org/articles/full_view/16"
Been doing some of my own analysis and came upon this thread. The last 20 bytes of the file (excluding the final 12-byte zero pad) is indeed the SHA-1 value of the PKG file minus the last 32-bytes (20-byte SHA-1 + 12-byte zero pad).
So, for all the PSP license files (since they're all the same size):
0x0 - 0x18FDF = block of data to calculate SHA-1 on
0x18FE0 - 0x18FF3 = SHA-1 of the block from 0x0-0x18FDF
0x18FF4 - 0x18FFF = 12-byte zero pad at the end
Likewise for the other PKG files. For example, using the Q*Bert PKG file:
0x0 - 0x8E3FBF = block of data to calculate SHA-1 on
0x8E3FC0 - 0x8E3FD3 = SHA-1
0x8E3FD4 - 0x8E3FDF = 12-byte zero pad at the end
The SHA-1 of the Q*Bert file is:
C6 54 7C 88 D2 CB 72 C8 05 E1 AB 6F 31 E0 22 88 5C D7 85 06
Using a hex editor, I wrote out the block of data and calculated the SHA-1 value on that block. They matched exactly. I confirmed this with a few other PKG files as well.
So it appears the SHA-1 is used as a checksum to prevent tampering of the PKG file. But now that we know how the SHA-1 is calculated, we can start tampering :-)
I've got more PKG structure analysis that I'll write up later, but at least wanted to confirm that the PKG file does indeed contain the SHA-1 at the end.
I did some compare of .pkg headers, there are any interesting on offset CB. That value is 02 for pay files like (lemmings/qbert/tekken) and 03 for "free" files like gripSHIT and demos (ridge racer, gthd, etc). See the picture:
i will make modification on offset CB (02 to 03) and test the install of lemmings, soon iŽll post the results.