Introduction: The Unsung Hero of Android Apps

The Android Resource Table, commonly known by its file extension .ARSC, is a critical component within every Android application (APK). While often overshadowed by DEX files containing the application’s bytecode, the ARSC file holds the meticulously organized metadata for all compiled resources – strings, layouts, drawables, animations, and more. For reverse engineers, understanding and effectively parsing the ARSC file is paramount. It’s the key to localizing applications, identifying obfuscated resource names, understanding application themes, and even manipulating runtime behavior. This deep dive will dissect the ARSC format, providing an expert-level understanding necessary for advanced analysis.

The Fundamental Chunk Structure

The entire ARSC file is a sequential collection of chunks. Each chunk begins with a standard header, ResChunk_header, which defines its type, size, and the size of the header itself. This allows parsers to navigate the file linearly, skipping unknown or unneeded chunks.

struct ResChunk_header {    uint16_t type;       // Type of the chunk. E.g., RES_TABLE_TYPE, RES_STRING_POOL_TYPE    uint16_t headerSize; // Size of the chunk header.    uint32_t size;       // Total size of this chunk (including header).};

The type field is crucial. Common types include RES_TABLE_TYPE (for the main resource table), RES_STRING_POOL_TYPE (for string pools), RES_XML_TYPE (for compiled XML), and more granular types for specific resource entries.

The Resource Table Header: Entry Point

The ARSC file always begins with a ResTable_header chunk. This top-level header specifies the total number of packages contained within the resource table.

struct ResTable_header {    ResChunk_header header; // Type: RES_TABLE_TYPE    uint32_t packageCount; // Number of packages in the file.};

Each ‘package’ generally corresponds to an application or library module, identifiable by its unique ID and name.

Mastering String Pools: The Heart of Localization

Android applications store all their strings in highly optimized string pools to save space and facilitate internationalization. The ARSC file contains at least one global string pool immediately following the ResTable_header. Each package can also have its own string pools for resource keys and type names.

struct ResStringPool_header {    ResChunk_header header; // Type: RES_STRING_POOL_TYPE    uint32_t stringCount;   // Number of strings in this pool.    uint32_t styleCount;    // Number of styles in this pool.    uint32_t flags;         // Flag bits: UTF8, SORTED    uint32_t stringsStart;  // Offset from chunk start to the first string.    uint32_t stylesStart;   // Offset from chunk start to the first style.};

The flags field is vital; STRING_POOL_UTF8_FLAG (0x00000100) indicates if strings are UTF-8 (otherwise UTF-16). String offsets are stored as an array of uint32_t values, pointing to the actual string data within the pool. Understanding how to correctly decode these strings based on the flags is fundamental for human-readable output during reverse engineering.

Packages: Organizing Resources by Application ID

Following the global string pool, the ARSC file contains one or more ResTable_package chunks. Each package represents a distinct set of resources, typically corresponding to an application or a library module (e.g., com.android.APP_NAME or android for framework resources).

struct ResTable_package {    ResChunk_header header;  // Type: RES_TABLE_PACKAGE_TYPE    uint32_t id;             // Package identifier.    char name[256];          // Null-terminated package name (UTF-16).    uint32_t typeStrings;    // Offset to typeStrings string pool.    uint32_t lastPublicType; // Last public type ID.    uint32_t keyStrings;     // Offset to keyStrings string pool.    uint32_t lastPublicKey;  // Last public key ID.};

The typeStrings and keyStrings fields are offsets to string pools specific to this package. The type strings define resource types like