The 1.00 updater's DATA.PSAR is a version 1 archive, the only one there is,
and its blocks carry tag 0x06000000, which the PRX decrypter had no key for.
1.50's mesg_led.prx keeps its keys raw in a table after their tags, the
0x0E000000 one we already use among them, and the 0x06000000 one there
decrypts all of 1.00 (with KIRK code 0x49, following the other tags). Its
first record has no version text either, so the version now comes from the
firmware's own version.txt when that's missing.
Fix a zlib usage bug.
Headless --unpack-updater also exited 0 when every file failed, so now it
fails if any did.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Written from reading 43 firmware versions, 1.50 through 6.61, while building the
unpacker - most of it isn't obvious from the code, and several parts only show
up if you look at more than one generation of updater.
Covers the three shapes an updater arrives in, the archive header and the record
layout, the two-step block decryption (KIRK CMD7 demangle, then an ordinary PRX
blob), the entry fields, the compression formats, and the three different naming
schemes with the DES-encrypted file lists that back two of them - including
which key set goes with which firmware, though not the key material itself,
which is already in the source.
Ends with the gotchas that each cost a debugging round: walking by the length in
the header rather than the file size, the slack the decrypter needs but the last
record can't provide, not assuming which entry numbers are file lists, and the
path spelling changing between generations.
Everything in here was checked against an actual updater.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GZq8ZtJmFY7bkX5FVkr3P9
