Draan: the SHA1 implementation you're using seems to be bogus (doesn't give the same result as openssl's which is correct) also the insize is used not the outsize value (which makes sense since the output is always 20 bytes).
Also KIRK_CMD_ENCRYPT_IV_0 expects 4 as first value (something like: #define KIRK_MODE_ENCRYPT_CBC 4) instead of 5 and the output is a valid KIRK_CMD_DECRYPT_IV_0 packet (so it reconstruct the same header with 5 instead of 4 and encrypted data are written at outbuf + sizeof(KIRK_AES128CBC_HEADER)).
Notice that the KIRK can decrypt keys up to 0x7f but can only encrypt up to 0x3f.
Forging data to match the CMAC is a good idea (i don't think we can modify the header because of the 332 bytes SHA1 check run over it), i had a similar idea but i quickly dismissed it as i didn't think it would possible
One possible issue is that Sony might create a white list with SHA1 of all official demos (there aren't that many) and forbid anything not matching and then use a stronger PRX scheme for the next demos to be released (i think they sign the demos themselves not the developers otherwise signing tool would be in the wild already) this, together with a new firmware, would render any signed homebrews quickly obsolete (or they can also just use UMD ISO images from now on and drop those kind of PRX in the future).