One of our users recently reported an Android resources.arsc file seemingly unprocessed by JEB. Upon closer inspection, it turned out this file was not a regular binary resources file, but instead, a compressed resources container serving as a generator for localized resources.arsc. Older versions of Google Play (eg, com.android.vending 11.6.18) and other official Google applications have been using this type of file, which is stored as a raw asset and sometimes named metaresources.arsc.

I decided to have a quick look. However, for better or worse, what was planned as a superficial exploration turned into a deep-dive into the rabbit-hole that was the “meta-arsc” parsing code.

Those files, as said above, are used to generate localized (non-English) resources.arsc files. That means that the client application can generate lightweight resources files on the fly. And presumably, APKs as well. Since this mechanism seems to be primarily used by the Play Store app, a reasonable use case could be Dynamic Delivery.

  • Full support was added into JEB (3.5-Beta)
  • A brief description of the file format can be found below
  • The fully annotated JDB2 is here (as well as the source apk) if you’d like to write your own implementation of a parser and localized arsc generator. The parser and generator have been thoroughly deobfuscated and commented out where need be. Package: com.google.d.a.a.a.a. Client code: FilteredResourceHelper.
    Drop both files (jdb2, apk) in a folder and open the JDB2 file in JEB

What does it look like when metaresources.arsc is processed in JEB?

JEB arsc_meta plugin, here seen processing a metaresources.arsc file. All localized resources.arsc files are generated and attached as children of the original meta file.
A french localized resources generated from a metaresources container. JEB processes those files as regular, stand-alone arsc files, and provides textual output similar to the one generated by the aapt2-dump tool from the Android SDK.

Binary Format

Disclaimer: Specification is a work-in-progress. Refer to the JDB2 annotation and code to fill in the gaps.

metaresources.arsc=
BE_UINT32                     cnt           count of languages
BE_UINT16[cnt]                langs         2-char language codes
MetaEntry[cnt]                metaentries   meta entries matching the language codes
CompressedResourceTableChunk  restab        a compressed resource table (code: 0x1002)
EOF                           -             not necessarily the EOF, but all metares
                                            files examined contained a single resource
                                            chunk, which is a compressed resource tab
MetaEntry=
BE_UINT32                     magic         the value 'META'
BE_UINT32                     entrysize     complete entry size (including the above
                                            magic) in bytes
BE_UINT16                     lang          language code
VAR_INT32                     cnt1          .
VAR_INT32[cnt1]               offsets1      a custom serialization of java.util.BitSet
                                            (refer to JDB2 for details) holding
                                            positions for strings and string styles
                                            stored in string pool chunks
VAR_INT32                     cnt2          .
VAR_INT32[cnt2]               offsets2      offsets to Table Package chunk entries
                                            (types, typespecs)
=> Compressed entries:
- 5 types exist, basically non-XML chunk types
- Their type code is the same as arsc's with the 0x1000 bit set
- List of chunks:
    StringPool=     refer to JDB2, class CompressedStringPoolChunk
    ResourceTable=  refer to JDB2, class CompressedResourceTableChunk
    Package=        refer to JDB2, class CompressedPackageChunk
    Type=           refer to JDB2, class CompressedTypeChunk
    TypeSpec=       refer to JDB2, class CompressedTypeSpecChunk