Subtitle Decryption

The Problem

KissKH does not always deliver subtitles as plain .srt or .vtt files. Some subtitle URLs end in .txt or .txt1 — these are valid SRT structures, but each subtitle cue's text line has been replaced with a base64-encoded AES ciphertext.

A standard video player has no way to decrypt these. Without server-side handling, viewers would see garbled or missing subtitles.

---

The Solution

KissKH Video Player decrypts these files server-side, before delivering them to the browser.

When the proxy receives a request for a .txt or .txt1 subtitle file:

1. It fetches the raw encrypted file from the KissKH CDN
2. It runs the ciphertext through the appropriate KissKH decryption function (a1 for .txt, a2 for .txt1)
3. It serves the result as plain application/x-subrip — a normal SRT file the player can read

The browser receives a clean, decrypted subtitle file with no indication that it was ever encrypted.

---

Cipher Functions

KissKH uses three cipher functions — a1, a2, a3 — defined in their obfuscated client-side scripts. These are bundled in:

src/vendor/kisskh-scripts.js
src/vendor/kisskh-scripts2.js

The server runs these scripts in a Node.js vm sandbox that mocks just enough of the browser environment (window, document, navigator, location, atob) for the deobfuscation to complete.

---

Updating the Vendor Scripts

If KissKH rotates their encryption keys, the cipher functions inside their scripts*.js files will change. To update:

1. Download the latest scripts*.js files from the KissKH website
2. Replace src/vendor/kisskh-scripts.js and/or src/vendor/kisskh-scripts2.js with the new versions
3. Restart the server

No changes to the server logic are needed — the decryption code reads these files at startup and re-executes them in the sandbox.

---

Plain Subtitle Files

Subtitle files that end in .srt or .vtt (not encrypted) are proxied through the /sub/ endpoint without any modification — they are streamed directly to the browser as-is.