[feature request] Support viewing Chromium `.pak` files

[AnAwesomGuy]

Chromium ships a lot of stuff in resources.pak files

currently, when opening these files in 7-zip, it finds a gzip header in the middle of the file, and then fails to extract it due to garbage data

Chromium .pak files are generated with this python script: https://github.com/chromium/chromium/blob/main/tools/grit/pak_util.py#L76 (standalone grit if you don't want to clone the entire codebase)

• you can run python3 pak_util.py -h to use the cli

https://github.com/chromium/chromium/blob/main/tools/grit/grit/format/data_pack.py#L135 is where most of the work is done

"spec": https://www.chromium.org/developers/design-documents/linuxresourcesandlocalizedstrings/#data-file-format-version-4

file-format from me reading the code, so it might not be super accurate (see the document above):

• everything is little-endian
• header:
  • first 4 bytes are the version: can only be 4 or 5
  • on version 4:
    • uint32, resource entry count
    • next byte is the encoding for all text resources:
      • 0: binary (no text resources)
      • 1: UTF-8
      • 2: UTF-16
  • on version 5:
    • next byte is the encoding for all text resources (same definition)
    • next 3 bytes are ignored
    • uint16, resource entry count
    • uint16, alias count
• next are resource count + 1 entry headers, 6 bytes each:
  • uint16, resource id
  • uint32, file offset
  • each resource data goes from the current file offset to the next entry's file offset
    • that means the last entry header doesn't refer to any data (I think, fact check this)
• next are aliases, 4 bytes each (there are 'alias count' alias entries)
  • uint16, alias resource id
  • uint16, index of the resource that the alias is pointing to
• rest is the actual data
  • if a resource's data starts with 1f 8b, the data should be decompressed with gzip
  • if a resource's data starts with 1e 9b, then the next 6 bytes are the size of the uncompressed data, and the data should be decompressed with brotli (excluding those first 8 bytes of course)

so basically, header summary:

• 05 00 00 00 uu ?? ?? ?? nn nn mm mm or 04 00 00 00 nn nn nn nn uu
  • everything is little endian
  • us are the encoding:
    • 0: binary (no text resources)
    • 1: UTF-8
    • 2: UTF-16
  • ns are the resource_count
  • ms are the alias_count

an example pak file (inside a zip file because GitHub doesn't let me upload it directly)

• inside are two files: an image with resource id 1111 and a text file with resource id 2222

[DenisAnisimov]

If you are a Windows user, you can try using a third-party plugin for working with pac files, Grit7z - https://www.tc4shell.com/en/7zip/grit7z/

[sebres]

Me is wondering which practical sense adding of that may have... Are there some real use cases? Read only or compress too?

[AnAwesomGuy]

I just thought that it would be useful to have because pak files aren't super rare (there's a bunch in every Chromium installation). Read-only should definitely be good enough, I don't think anyone is really making pak files.

[myfreeer]

The pak being used in chromium-based browsers comes with 3 variants, Chromium V5, Chromium V4, and MS Edge Private v5.
See https://github.com/myfreeer/chrome-pak-customizer/wiki/Binary-Patterns for binary patterns I've discovered from a msedge pak file, and myfreeer/chrome-pak-customizer#19 for related discussions

[AnAwesomGuy]

oh, so that's why my resources.pak file for Edge seemed to be very different...