आज हम तीन चीज़ें लॉन्च कर रहे हैं:
- AfterPack, AI युग के लिए एक आधुनिक JavaScript ऑब्फ़स्केटर। यह आपके प्रोडक्शन बिल्ड को हर बार एक अलग प्रोग्राम में बदल देता है: हर बिल्ड पर एक नया रूप, और Cloudflare Worker के अंदर, हर रिक्वेस्ट पर भी एक नया रूप।
- रीफ़्रेश किया गया साइट स्कैनर, जो किसी भी वेबसाइट के कोड में जो कुछ भी पढ़ा जा सकता है उसे ढूँढ निकालता है: पब्लिक source map, पढ़ने लायक लॉजिक और लीक हुए credentials।
- एक ऑनलाइन playground, जहाँ आप सीधे अपने ब्राउज़र में, अपने ही कोड पर AfterPack आज़मा सकते हैं।
AfterPack (afterpack.dev), JavaScript ऑब्फ़स्केटर, किसी भी framework के साथ काम करता है। CLI और plugins ओपन सोर्स हैं, लोकल इंजन मुफ़्त है, और Pro क्लाउड बिल्ड $49 प्रति माह से शुरू होते हैं। बिल्ड के बाद npx afterpack@latest चलाकर शुरू करें, या अपने coding agent से इसे जोड़ने के लिए कहें।
मिलिए AfterPack से: एक मुफ़्त बिल्ड टूल जो आपके शिप किए हुए कोड को scanners और लोगों के लिए अपठनीय बना देता है, और AI के लिए एक चलता-फिरता टार्गेट। हर बिल्ड पूरी तरह अलग कोड शिप करता है, इसलिए एक रिलीज़ के ख़िलाफ़ लिखी गई patch स्क्रिप्ट — कोई cheat, userscript या bypass — अगली रिलीज़ में फ़िट नहीं बैठती। आपके कोड के ख़िलाफ़ लिखा गया टूल आपकी अगली रिलीज़ पर काम करना बंद कर देना चाहिए, और अब, आपके अपने Cloudflare Worker के अंदर, यह आपकी अगली रिक्वेस्ट पर ही काम करना बंद कर सकता है।
अब जब AI इसे पढ़ सकता है, तो JavaScript ओबफस्केट क्यों करें?
क्योंकि AI जो भी पढ़ सकता है, उसे दोबारा लिख और दोबारा पैकेज भी कर सकता है। अपने बंडल की ओर एक coding agent भेजिए, और कुछ ही मिनटों बाद किसी के पास आपके प्राइसिंग नियम, आपका paywall check या आपका anti-bot logic साफ़, editable सोर्स के तौर पर आ चुका होता है — साथ ही एक ऐसी स्क्रिप्ट भी जो उन्हें patch या bypass कर देती है। यह पहले किसी विशेषज्ञ का काम हुआ करता था; अब यह बस एक प्रॉम्प्ट है। और जब तक आपका कोड अपना आकार बनाए रखता है, तब तक वह patch काम करता रहता है। Minification उस कोड को कभी छिपा नहीं रहा था: Claude Code «लीक» एक पढ़ने लायक बंडल था जो लॉन्च से ही npm पर पड़ा था। Minified बंडल अब भी क्या उजागर करता है, और अपनी साइट कैसे जाँचें, यह यूज़र्स आपके JavaScript में क्या देख सकते हैं और उसे कैसे सुरक्षित करें में है।
मई 2026 में मैंने दो लोकप्रिय ओबफस्केटर्स के फ़्लैगशिप डेमो चार पैराग्राफ के एक प्रॉम्प्ट के साथ Claude Code को दिए। Claude Opus 4.6 साफ़ सोर्स के साथ लौटा, 10 मिनट में; Claude Opus 4.7 को 20 मिनट लगे। वे छोटे डेमो थे, पूरे ऐप नहीं, और अब वे models आज के मुक़ाबले एक पीढ़ी पीछे हैं।
आपके प्राइसिंग के नियम, लाइसेंस चेक, anti-fraud heuristics और बिना घोषणा वाले फ़ीचर हमेशा से बंडल में थे। बदला यह है कि उन्हें कौन पढ़ सकता है, और कितनी तेज़ी से। आप अब भी जिस पर काबू रखते हैं, वह यह है कि उस काम का कितना हिस्सा आपकी अगली रिलीज़ पर carry over होता है।
क्या ओबफस्केट किया हुआ JavaScript रिवर्स किया जा सकता है?
हाँ। पर्याप्त समय मिले तो किसी भी ओबफस्केटर का आउटपुट रिवर्स किया जा सकता है, AfterPack का भी। AfterPack जो बदलता है वह है carry-over: एक रिलीज़ को रिवर्स करने का काम अगली रिलीज़ पर कितना काम आता है। हमारे अपने माप में (सितंबर 2026, छह seeds × पाँच samples), एक बिल्ड से deobfuscator ने जो recover किया, उसका 6% से भी कम अगले बिल्ड पर resolve हुआ (हमने कैसे मापा)।
जो लॉजिक कोई एक बार पढ़ चुका है, वह पढ़ा ही रहता है: अगर उसने आपका डिस्काउंट नियम एक बार समझ लिया, तो नया बिल्ड उसे भुला नहीं देगा।
जिसकी मियाद ख़त्म हो सकती है, वह है उस पढ़ाई पर बना टूल। लाइसेंस चेक हटाने वाली स्क्रिप्ट, paywall का patcher, हर रिलीज़ से आपके स्कोरिंग नियम निकालने वाला extractor: हर एक किसी एक बिल्ड की संरचना के ख़िलाफ़ लिखा जाता है। सबसे लोकप्रिय ओपन-सोर्स ओबफस्केटर तय आकार वाला आउटपुट बनाता है, और मुफ़्त पब्लिक deobfuscators उनके लिए hardcoded recognizers के साथ आते हैं, इसलिए एक बार लिखा गया टूल भविष्य के हर बिल्ड पर चलता रहता है।
AfterPack हर बिल्ड पर एक नए random seed से शुरू होता है। Identifiers के नाम, एनकोड किए गए strings, decoder का signature, states की नंबरिंग और masked constants सब अलग निकलते हैं, इसलिए जो बारीकियाँ कोई टूल hard-code करता है, वे हर बार बदल जाती हैं। इंजन को Worker के अंदर चलाएँ, और यह खिड़की एक रिलीज़ से सिकुड़कर एक ही रिक्वेस्ट भर की रह जाती है।
AfterPack में क्या है?
एक CLI, उन bundlers के लिए plugins जिन्हें आप पहले से इस्तेमाल करते हैं, Workers के लिए एक WebAssembly बिल्ड, Pro क्लाउड बिल्ड, हर बिल्ड ने क्या सुरक्षित किया उसकी रिपोर्ट, और एक मुफ़्त साइट स्कैनर।
| तथ्य | AfterPack |
|---|---|
| यह क्या है | प्रोडक्शन बिल्ड के लिए एक JavaScript ओबफस्केटर: यह आपके bundler के बनाए आउटपुट को दोबारा लिखता है, आपकी सोर्स फ़ाइलों को नहीं |
| इंजन | Rust, CLI और plugins द्वारा लोकली चलाया जाता है, या WebAssembly (@afterpack/wasm) के रूप में आपके अपने Worker के अंदर |
| आउटपुट | CLI और plugins में डिफ़ॉल्ट रूप से हर बिल्ड पर अलग; seed तभी पिन करें जब आपको एक जैसी बाइट्स चाहिए |
| लाइसेंस | CLI और plugins Apache-2.0; इंजन AfterPack Engine License के तहत मुफ़्त इस्तेमाल के लिए |
| क़ीमत | लोकल इंजन मुफ़्त; Pro $49 प्रति माह से (plans) |
| शुरुआत | अपने बिल्ड के बाद npx afterpack@latest, या एक framework plugin |
जो टेबल में नहीं दिखता:
- Framework plugins: Next.js, Vite, webpack, Astro, Nuxt, SvelteKit, Svelte, Vue, Angular, Parcel, esbuild, Rollup और Electron के लिए। आपका सामान्य प्रोडक्शन बिल्ड ही ओबफस्केट किया हुआ आउटपुट देता है।
- Pro: एक key पास करें और वही कॉल AfterPack के क्लाउड में चलती है, directives के साथ जो भारी सुरक्षा उस कोड पर लगाते हैं जो मायने रखता है। अगर key या क्लाउड उपलब्ध न हो, तो बिल्ड चुपचाप कम सुरक्षा के साथ शिप होने के बजाय फ़ेल हो जाता है।
- Protection Map: आपके मूल सोर्स की एक HTML रिपोर्ट, जिसमें हर token इस हिसाब से रंगा होता है कि उस पर कितना transformation हुआ। यह तब लिखी जाती है जब आपका बिल्ड source map बनाता है; plugins इसे आपके लिए चालू कर सकते हैं।
- मुफ़्त security scanner, जो
npx afterpack audit <url>के रूप में भी उपलब्ध है।
AfterPack का ओबफस्केट किया हुआ आउटपुट कैसा दिखता है?
Identifiers ग़ायब हो जाते हैं और string literals एक runtime decoder के पीछे एनकोड हो जाते हैं; इससे आगे कितना होता है, यह preset पर निर्भर करता है। light (डिफ़ॉल्ट) strings को एनकोड करता है और syntax को फिर से लिखता है, कोई structural layer नहीं जोड़ता — ज़्यादातर प्रोजेक्ट्स के लिए सही baseline। medium प्रोडक्शन कोड को समझ पाना काफ़ी मुश्किल बना देता है; hard उस कोड के लिए है जो मायने रखता है, जैसे प्राइसिंग, gating और लाइसेंस चेक; extreme सभी presets में सबसे ऊँची complexity सेट करता है, जिसे पूरे bundle के बजाय किसी एक फ़ंक्शन या फ़ाइल पर लगाना बेहतर है।
एक 139-बाइट फ़ंक्शन, पहले:
| 1 | export function discount(plan, seats) { |
| 2 | if (plan === "team" && seats >= 10) return 0.2; |
| 3 | if (plan === "team") return 0.1; |
| 4 | return 0; |
| 5 | } |
और बाद में, डिफ़ॉल्ट light preset पर एक npx afterpack@latest रन (27 सितंबर 2026):
| 1 | export function discount(N, O) { |
| 2 | if (N === Jr("T|P4") && O >= 10) return 0.2; |
| 3 | if (N === Jr("T|P4")) return 0.1; |
| 4 | return 0; |
| 5 | } |
"team" ग़ायब है, इसकी जगह एक ciphertext और एक decoder call है; इसे दोबारा चलाएँ तो नाम, ciphertext और decoder का signature — सब अलग निकलते हैं। light पर 10, 0.2 और 0.1 जैसी संख्याएँ पढ़ने लायक़ रहती हैं; medium और उससे ऊपर के presets उस 10 जैसे integer constants को भी mask कर देते हैं। decoder ख़ुद भी कुछ जगह लेता है, इसलिए इतनी छोटी फ़ाइल असली bundle के मुक़ाबले अनुपात में कहीं बड़ी दिखती है: असली bundle पर light gzip के बाद इनपुट का 1.9 से 2.4 गुना निकलता है (presets)।
अपने किसी फ़ंक्शन को playground में पेस्ट करके देखें कि हर preset उसके साथ क्या करता है — न इंस्टॉल, न अकाउंट।
अभी AfterPack आज़माएँ
- कोड पेस्ट करें: playground आपके पेस्ट किए किसी भी कोड को ब्राउज़र में ही ओबफस्केट कर देता है, बिना इंस्टॉल के।
- अपनी साइट स्कैन करें: security scanner दिखाता है कि आपका प्रोडक्शन JavaScript पहले से क्या उजागर करता है।
- एक प्रॉम्प्ट: किसी coding agent को दें —
Add AfterPack to this project: read afterpack.dev/llms.txt, follow the quickstart for my framework, then run a production build and show me the Protection Map. - एक कमांड: अपने अगले बिल्ड के बाद
npx afterpack@latestचलाएँ।
Cloudflare Worker में हर रिक्वेस्ट पर JavaScript ओबफस्केट करें
@afterpack/wasm इंजन को WebAssembly के रूप में आपके अपने Worker के अंदर चलाता है, इसलिए हर कॉल पर एक ताज़ा seed हर response को अलग तरह से ओबफस्केट कर देता है:
| 1 | import { obfuscate } from "@afterpack/wasm"; |
| 2 | |
| 3 | export default { |
| 4 | async fetch(request) { |
| 5 | const upstream = await fetch("https://example.com/app.js"); // your origin's bundle |
| 6 | if (!upstream.ok) return upstream; |
| 7 | const source = await upstream.text(); |
| 8 | const result = await obfuscate( |
| 9 | { path: "app.js", source }, |
| 10 | { preset: "hard", seed: crypto.randomUUID() }, |
| 11 | ); |
| 12 | return new Response(result.bytes, { |
| 13 | headers: { "content-type": "application/javascript" }, |
| 14 | }); |
| 15 | }, |
| 16 | }; |
अगर हम यह handler Apple M2 Max पर Node में चलाएँ (27 सितंबर 2026), और यह एक लोकल origin से discount फ़ाइल सर्व करे, तो चार रिक्वेस्ट चार अलग आउटपुट देती हैं, हर एक सही डिस्काउंट के साथ। मॉड्यूल गर्म होने के बाद हर ओबफस्केशन में 4 ms से कम लगते हैं; पहली कॉल में, जो इंजन को instantiate करती है, लगभग 40 ms लगते हैं। यह 139 बाइट का इनपुट है; असली बंडल कहीं ज़्यादा CPU लेता है, और यह क़ीमत हर response पर चुकानी पड़ती है। Workers गाइड प्लान की लिमिट्स बताती है, और यह भी कि कब हर rotation विंडो के लिए एक रूप कैश करना बेहतर सौदा है।
wrangler कॉन्फ़िग, हर टाइम विंडो के लिए एक कैश किए गए रूप और असली curl आउटपुट के साथ पूरा सेटअप Cloudflare Workers के साथ हर रिक्वेस्ट पर JavaScript कैसे ओबफस्केट करें वाले ट्यूटोरियल में है।
Next.js, Vite, webpack या किसी भी बिल्ड को कैसे ओबफस्केट करें
अपने बिल्ड के बाद CLI चलाएँ, या अपने bundler का plugin इंस्टॉल करें ताकि हर प्रोडक्शन बिल्ड ओबफस्केट होकर निकले। CLI को किसी सेटअप की ज़रूरत नहीं; बिल्ड करने के बाद प्रोजेक्ट रूट में यह चलाएँ:
| npx afterpack@latest |
यह आपका बिल्ड आउटपुट ढूँढ लेता है (dist/, .next/, .output/, build/ या out/), उसे उसी जगह दोबारा लिखता है और एक बैकअप रखता है; npx afterpack@latest restore रन को पलट देता है।
ओबफस्केशन को ख़ुद बिल्ड का हिस्सा बनाने के लिए, अपने bundler का plugin इंस्टॉल करें:
| npm install -D @afterpack/next # or @afterpack/vite, @afterpack/webpack |
हर plugin को कॉन्फ़िग में एक छोटा बदलाव चाहिए, जैसे अपने Next.js कॉन्फ़िग को withAfterpack(config) में लपेटना; frameworks हर समर्थित bundler के लिए यह दिखाता है, Astro से Parcel तक। आपकी लाइव साइट आज क्या उजागर करती है, यह देखने के लिए पहले उसे स्कैनर से गुज़ारें।
AfterPack की सीमाएँ क्या हैं?
AfterPack आपका कोड पढ़ने की और उसके ख़िलाफ़ टूलिंग दोबारा इस्तेमाल करने की लागत बढ़ाता है; चलते प्रोग्राम को instrument करने वाले से यह values नहीं छिपा सकता, इसलिए secrets और access देने वाली हर चीज़ आपके सर्वर पर होनी चाहिए। जो यह देता है, वह उसी बिल्ड के साथ आता है जो आप पहले से चलाते हैं: हर रिलीज़ एक नया टार्गेट, कोई अतिरिक्त क़दम याद रखने की ज़रूरत नहीं।
AfterPack में आगे क्या है?
अगला नंबर network obfuscation का है: network transport cloaking आपके API requests और responses को एक ऐसे codec से गुज़ारेगा जो हर बिल्ड के साथ बदलता है। cross-module obfuscation लॉजिक को module boundaries के आर-पार जोड़ेगा, और AfterPack on Workers for Platforms हर रिक्वेस्ट पर बिना कुछ इंस्टॉल किए नया रूप देगा। JavaScript के बाद, अगला पड़ाव HTML और CSS है।
AfterPack: अक्सर पूछे जाने वाले सवाल
क्या AfterPack मुफ़्त है?
हाँ। CLI, framework plugins और लोकल इंजन मुफ़्त हैं, और आपका सोर्स कभी आपकी मशीन से बाहर नहीं जाता। Pro $49 प्रति माह से क्लाउड बिल्ड और हर हिस्से के लिए अलग directives जोड़ता है, और एक रजिस्टर्ड Free workspace को हर महीने 10 MB के Pro बिल्ड मिलते हैं। पूरी टेबल plans और tiers पर है।
क्या AfterPack ओपन सोर्स है?
CLI और framework plugins ओपन सोर्स हैं, Apache-2.0 के तहत, GitHub पर। जिस इंजन को वे चलाते हैं, वह AfterPack Engine License के तहत मुफ़्त इस्तेमाल के लिए है।
क्या ओबफस्केशन मेरे कोड को धीमा करता है?
थोड़ा, और ज़्यादा मज़बूत presets पर ज़्यादा। डिफ़ॉल्ट light है। पूरे प्रोजेक्ट के लिए preset बढ़ाएँ, या Pro directive से hard या extreme सिर्फ़ उन फ़ंक्शनों पर लगाएँ जिन्हें इसकी ज़रूरत है।
AfterPack दूसरे JavaScript ओबफस्केटर्स से कैसे अलग है?
यह आपके प्रोडक्शन बिल्ड पर उसी bundler के plugin के ज़रिए काम करता है जिसे आप पहले से इस्तेमाल करते हैं, और डिफ़ॉल्ट रूप से हर बिल्ड अलग आउटपुट देता है, इसलिए एक रिलीज़ के लिए लिखा गया deobfuscator अगली पर ज़्यादातर काम करना बंद कर देता है। दूसरे ओबफस्केटर्स के साथ-साथ मापे गए बिल्ड टाइम, आउटपुट साइज़ और carry-over comparison पेज पर हैं।
क्या ओबफस्केशन API keys छिपाता है?
नहीं। आपका चलता कोड जो भी इस्तेमाल करता है, उसे अपने नियंत्रण वाले ब्राउज़र में चलाने वाला कोई भी देख सकता है, इसलिए API keys और दूसरे secrets अपने सर्वर पर रखें। एनकोडिंग key को grep और ऑटोमेटेड secret scanners से ज़रूर दूर रखती है, जिससे ग़लती से शिप हुई key को बदलने का समय मिल जाता है (best practices)।
कोई bug मिला, या ऐसा bundler चाहिए जो हम अभी सपोर्ट नहीं करते? अपने bundler और उसके वर्ज़न के साथ GitHub पर एक issue खोलें; वहीं मैं फ़ीडबैक पढ़ता हूँ।
आप जो कोड शिप करते हैं, वह हमेशा से पढ़ा जा सकता था। आज से, कोई एक रिलीज़ से जो सीखता है, वह अगली रिलीज़ पर काम आना ज़रूरी नहीं रहा।
— Nikita