Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/ZemerTeam/zemer-cipher/llms.txt

Use this file to discover all available pages before exploring further.

player_configs.json is the single source of truth for per-player deobfuscation parameters. It is bundled inside the APK as an asset and fetched from GitHub at runtime so new player entries can be delivered without an app update. This page documents the complete schema, all validation constraints, and the semantics of each field.

​
Top-Level Shape

{
  "schemaVersion": 1,
  "players": {
    "<8-hex-hash>": { ... }
  }
}
​
schemaVersion
integer
required
Must be a positive integer that does not exceed the library’s SUPPORTED_SCHEMA_VERSION (currently 1). Must be a JSON number — a string "1" is rejected. Files with a higher version are rejected by older library builds, keeping their last-good config table until they are updated.
​
players
object
required
A JSON object whose keys are 8-character lowercase hex player hashes. Each value is a player entry object (see below). Must be a JSON object — an array or any other type is rejected.

​
Player Entry Fields

Each entry under players must be keyed by an 8-hex hash and must contain the following fields.
​
sig
string
required
Signature call expression. Validated against ^[A-Za-z0-9$_]{1,8}\(\d+,\d+,INPUT\)$. Represents a call to the player’s signature deobfuscation function with two integer constant arguments and the obfuscated signature. The placeholder INPUT is replaced with the actual obfuscated signature string at evaluation time inside the cipher WebView.Example: "mP(4,155,INPUT)"
​
nClass
string
required
URL class identifier for the n-transform. Validated against ^[A-Za-z0-9$_]{1,8}$. Used to build the n-transform IIFE locally via PlayerConfigParser.buildNJsExpression — the IIFE template is never taken from the remote file.Example: "Yx"
​
sts
integer
required
signatureTimestamp. Must be a positive JSON integer (not a string). Sent in InnerTube /player API requests as the signatureTimestamp field. Values in the bundled asset are in the range 20000–29999.Example: 20613
​
aliases
array of string
An optional array of additional 8-hex hashes that map to the same config entry. Used as fallback hashes when the player URL hash cannot be extracted from the JS via URL patterns; in that case, FunctionNameExtractor falls back to the MD5 of the first 10,000 characters of the player JS, which is registered as an alias.Each element must match ^[a-f0-9]{8}$. An alias that collides with any other primary hash or alias in the file causes the entire file to be rejected.Example: ["d62bd338"]

​
Real Examples

The following entries are taken directly from the bundled asset: 
{
  "schemaVersion": 1,
  "players": {
    "445213fb": {
      "sig": "mP(4,155,INPUT)",
      "nClass": "Yx",
      "sts": 20613,
      "aliases": ["d62bd338"]
    },
    "959dabb2": {
      "sig": "IR(84,305,INPUT)",
      "nClass": "Ga",
      "sts": 20614,
      "aliases": ["79c1b58e"]
    },
    "bb52fe90": {
      "sig": "Ez(5,408,INPUT)",
      "nClass": "Oq",
      "sts": 20615,
      "aliases": ["f6046ecd"]
    },
    "ce74690f": {
      "sig": "$9(2,6487,INPUT)",
      "nClass": "cV",
      "sts": 20612,
      "aliases": ["a5669e32"]
    }
  }
}

​
Validation Rules

​
File-level rejection conditions

A file that fails any of these checks is rejected in its entirety. Callers keep their previous config table unchanged.
  • JSON is malformed (any syntax error)
  • schemaVersion is missing
  • schemaVersion is a string or any non-integer JSON type
  • schemaVersion is zero or negative
  • schemaVersion is greater than SUPPORTED_SCHEMA_VERSION (1)
  • players is missing
  • players is not a JSON object (e.g. it is an array)
  • Any primary hash key duplicates another primary hash key or alias anywhere in the file
  • Any alias duplicates any other primary hash key or alias anywhere in the file (including within its own entry)

​
Entry-level skip conditions

An entry that fails any of these checks is skipped; the rest of the file continues to be processed and a ParseResult.Success is returned with the failing key listed in skippedEntries.
  • The primary hash key does not match ^[a-f0-9]{8}$
  • sig is missing, is not a string, or does not match ^[A-Za-z0-9$_]{1,8}\(\d+,\d+,INPUT\)$
  • nClass is missing, is not a string, or does not match ^[A-Za-z0-9$_]{1,8}$
  • sts is missing, is a string, is not an integer, or is zero/negative
  • aliases is present but is not a JSON array
  • Any element in aliases is not a string or does not match ^[a-f0-9]{8}$

​
schemaVersion Semantics

The current schema version is 1. schemaVersion is only incremented for breaking changes — additions of new optional fields do not require a bump. When an older library build encounters a remote file with a higher schemaVersion, it rejects the file and continues using its last-good config table. This ensures that a schema upgrade does not break deployed apps: they receive a ParseResult.Failure and fall through to their cached or bundled data until the app is updated to a library version that understands the new schema.
Duplicate keys — whether a primary hash appearing twice, or an alias that matches any other primary hash or alias anywhere in the file — cause the entire file to be rejected. All deployed apps that have not yet cached a previous good version will revert to their bundled config; apps with a previously cached good copy will continue using that copy. The duplicate must be corrected and a new file deployed before apps will accept remote updates again.

Build docs developers (and LLMs) love

Get started for freeTalk to us