--- ## Introduction Most online course platforms use standard DRM solutions like Widevine or FairPlay to protect video content. ClassX took a different approach — they built their own **custom 6-layer encryption architecture** from scratch, wrapping HLS video streams in multiple layers of AES encryption, code obfuscation, and anti-tamper protections. This post documents how I systematically reverse-engineered each layer, from the disguised JavaScript player to the final AES-128 segment decryption. The goal isn't to encourage piracy — it's to demonstrate why **security through obscurity fails** and what better alternatives exist. > **Disclaimer:** This research was conducted as part of a security audit --- ## The Target ClassX serves premium video courses through a custom-built Next.js frontend. When you open a video, the browser: 1. Makes an API call to get encrypted video metadata 2. Loads a heavily obfuscated video player 3. Derives cryptographic keys in the browser 4. Decrypts and plays HLS video segments in real-time What makes this interesting is the **depth of the defense** — six distinct layers, each designed to prevent a different attack vector. --- ## Architecture Overview ```mermaid flowchart TB subgraph "Layer 1: Code Protection" A["video1.webp
(Fake PNG)"] -->|"SJCL Decrypt
password: appx123"| B["Base64 String"] B -->|"atob() + pako.inflate()"| C["50K-line video.js"] end subgraph "Layer 2: Key Derivation — bd()" D["API: strtotime"] --> F["SHA-256 Hash"] E["API: video_player_token"] -->|"slice(start, end)"| F F --> G["AES Key
(128/192/256 bit)"] end subgraph "Layer 3: AES-CBC Decrypt — k1()" G --> H["Decrypt manifestString
→ m3u8 URL"] G --> I["Decrypt keyString
→ 16-byte HLS Key"] end subgraph "Layer 4: HLS Segment Decryption" I --> J["AES-128-CBC per segment"] H --> J J --> K["Playable Video"] end style A fill:#c41e3a,color:#fff,stroke:none style G fill:#f59e0b,color:#fff,stroke:none style K fill:#10b981,color:#fff,stroke:none ``` --- ## Layer 1: The Invisible Player ### The Disguise The first surprise: the entire video player JavaScript (**50,000 lines**) is encrypted and served disguised as a PNG image. ``` GET /uhs-hls-player/images/watermark-2/video1.webp Content-Type: text/html ← Not actually a PNG! ``` The browser downloads what looks like a harmless image file, but it's actually a JSON blob encrypted with [SJCL](https://bitwiseshiftleft.github.io/sjcl/) (Stanford JavaScript Crypto Library): ```json { "iv": "base64...", "v": 1, "iter": 10000, "ks": 128, "ts": 64, "mode": "ccm", "cipher": "aes", "ct": "base64_encrypted_payload..." } ``` ### Cracking the Password The SJCL password is obfuscated through a multi-step encoding chain: ```javascript // What the code looks like const pwd = encodeBytes("ZXZ2fjU0Mw=="); // What encodeBytes actually does: function encodeBytes(encoded) { let decoded = atob(encoded); // "ZXZ2fjU0Mw==" → "evv~54M" let reversed = decoded.split('').reverse().join(''); // → "M45~vve" let xored = reversed.split('').map(c => String.fromCharCode(c.charCodeAt(0) ^ 7) // XOR each byte with 7 ).join(''); // → "J32yssx" let shifted = xored.split('').reverse().join(''); // → "xss2y3J" // ... more steps return "appx123"; // Final result } ``` **The password is `appx123`** — hardcoded and identical for every user, every session. This is the first major weakness. ### Decompression After SJCL decryption, the payload is: 1. Base64 decoded 2. Pako (gzip) decompressed 3. Evaluated as JavaScript → a modified **video.js v7.19.0** ```mermaid flowchart LR A["video1.webp
(3.2 MB)"] -->|"SJCL AES-CCM
key: appx123"| B["Base64 String
(5.8 MB)"] B -->|"atob()"| C["Pako Compressed
(4.3 MB)"] C -->|"pako.inflate()"| D["video.js Source
(50K lines, 2.1 MB)"] style A fill:#c41e3a,color:#fff,stroke:none style D fill:#10b981,color:#fff,stroke:none ``` --- ## Layer 2: Dynamic Key Derivation ### The `bd()` Function This is the brain of the crypto system. Found in the Next.js chunk `chunk_8586.js` (webpack module `2302`): ```javascript function bd(datetime, token) { const last4 = datetime.substring(datetime.length - 4); const startIdx = Number(last4.charAt(0)); // 1st char → slice start const endIdx = Number(last4.charAt(1) + last4.charAt(2)); // 2nd+3rd → slice end const keyType = last4.charAt(3); // 4th char → key size const material = datetime + token.slice(startIdx, endIdx); const hash = SHA256(material); // Key size selection if (keyType == '6') return hash.slice(0, 16); // AES-128 (16 bytes) if (keyType == '7') return hash.slice(0, 24); // AES-192 (24 bytes) return hash; // AES-256 (32 bytes) } ``` ### How the Parameters Encode the Algorithm The last 4 digits of `strtotime` serve as a **configuration string**: ``` strtotime = "1774150320" ^^^^ 0320 Position 0 → startIdx = 0 (where to start slicing the token) Position 1+2 → endIdx = 32 (where to stop slicing) Position 3 → keyType = 0 (not 6/7/8 → defaults to AES-256) ``` This means the **algorithm selection is encoded in the timestamp itself** — a clever trick that makes static analysis harder because the crypto parameters change with every API response. ### Key Derivation Walkthrough ```mermaid flowchart TB A["API Response"] --> B["strtotime = '1774150320'"] A --> C["token = 'a6d54cddb8e7a6cc...'"] B -->|"last 4 chars: '0320'"| D["startIdx=0, endIdx=32, keyType=0"] C -->|"token.slice(0, 32)"| E["'a6d54cddb8e7a6cc2bef4f92f0967bfb'"] B --> F["material = strtotime + slice"] E --> F F -->|"SHA-256"| G["32-byte hash"] G -->|"keyType=0 → full hash"| H["AES-256 Key"] style A fill:#c41e3a,color:#fff,stroke:none style H fill:#10b981,color:#fff,stroke:none style B fill:#171717,stroke:#525252,color:#fff style C fill:#171717,stroke:#525252,color:#fff style D fill:#171717,stroke:#525252,color:#fff style E fill:#171717,stroke:#525252,color:#fff style F fill:#171717,stroke:#525252,color:#fff style G fill:#171717,stroke:#525252,color:#fff ``` --- ## Layer 3: The Window Variable Bridge ### Setting Up the Decrypt Environment Before the encrypted player JS loads, the parent page sets global variables on `window`: | Variable | Value Source | Purpose | |:---------|:------------|:--------| | `window.lv` | `bd(strtotime, token).toString('base64')` | The AES key (base64) | | `window.ivb6` | `iv_string` from API (double-base64) | Initialization Vector | | `window.tmpfn` | `(e,t,i) => k1(e,t,i,n)` | The decrypt function itself | | `window.keyString` | `encrypted_links[].key` | Encrypted HLS key | | `window.manifestString` | `encrypted_links[].path` | Encrypted m3u8 URL | This is the **critical vulnerability**: all five values are readable from the browser console. When you type `window.lv` in DevTools, you get the raw AES key. ### The `k1()` Decrypt Function ```javascript function k1(encryptedBase64, keyBase64, ivBase64, n) { const key = base64ToBytes(keyBase64); const iv = base64ToBytes(ivBase64); const data = base64ToBytes(encryptedBase64); const algBits = { 6: '128', 7: '192', 8: '256' }[n] || '256'; return AES_CBC_Decrypt(`aes-${algBits}-cbc`, key, iv, data); } ``` The platform aliases this as `window.tmpfn` — a function that takes encrypted data + key + IV and returns plaintext. Once you have `lv` and `ivb6`, you can decrypt anything: ```javascript // In browser console: const m3u8Url = window.tmpfn(window.manifestString, window.lv.split(':')[0], window.ivb6); // → "https://d1d34p8vz63oiq.cloudfront.net/playlist.m3u8?token=..." ``` --- ## Layer 4: HLS Segment Encryption ### The Encrypted Playlist Once decrypted, the m3u8 manifest looks like a standard HLS playlist: ``` #EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:10 #EXT-X-MEDIA-SEQUENCE:0 #EXT-X-KEY:METHOD=AES-128,URI="enc.key",IV=0xfedcba9876543210fedcba9876543210 #EXTINF:10.0, segment_000.ts #EXTINF:10.0, segment_001.ts ... #EXTINF:4.2, segment_380.ts #EXT-X-ENDLIST ``` Each `.ts` segment is encrypted with **AES-128-CBC**. The key is fetched from `enc.key` (served from the CDN), and the IV is specified in the playlist header. ### Segment Decryption Flow ```mermaid sequenceDiagram participant B as Browser participant CDN as CloudFront CDN participant P as Player.js B->>CDN: GET playlist.m3u8 CDN-->>B: Encrypted playlist B->>P: tmpfn(manifestString, lv, ivb6) P-->>B: Decrypted m3u8 URL B->>CDN: GET enc.key CDN-->>B: 16-byte AES key loop For each .ts segment B->>CDN: GET segment_N.ts CDN-->>B: Encrypted segment B->>P: AES-128-CBC decrypt(segment, key, IV) P-->>B: Decrypted video data end ``` --- ## Layer 5: Domain Whitelist ### Reversed String Trick The player validates that it's running on an authorized domain using **reversed strings** — a simple anti-tamper check: ```javascript // Inside the decrypted video.js: const allowedDomains = [ "ni.oc.xssalc.yalp-xppa", // → appx-play.classx.co.in "ni.oc.xssalc.reyalp", // → player.classx.co.in ]; const currentDomain = window.location.hostname.split('').reverse().join(''); if (!allowedDomains.includes(currentDomain)) { throw new Error("Unauthorized domain"); } ``` This prevents hosting the player on a different domain, but it's trivially bypassed by: - Modifying the JavaScript before execution - Using a local proxy that serves content under the same domain - Overriding `window.location` before the check runs --- ## Layer 6: Anti-Tamper Protections ### Object.freeze on Media APIs The player freezes browser APIs to prevent monkey-patching: ```javascript Object.freeze(MediaSource.prototype); Object.freeze(SourceBuffer.prototype); ``` This prevents attackers from intercepting the `appendBuffer()` calls that feed decrypted video data to the `

Insights & Research

Breaking ClassX: How I Reverse-Engineered a 6-Layer Video Encryption System