# JavaScript obfuscation FAQ

AfterPack के बारे में सबसे ज़्यादा पूछे जाने वाले सवाल, हर एक का जवाब कुछ छोटे पैराग्राफ़ में।

Source: https://www.afterpack.dev/hi/docs/faq

सामान्य सवाल — AfterPack क्या है, क्या यह free है, क्या यह आपका app तोड़ता है — [landing FAQ](https://www.afterpack.dev/hi/#faq) पर जवाब दिए गए हैं। यह पेज build-स्तर का विवरण है।

## Free और Pro में क्या अंतर है?

Free पूरी pipeline को पूरे bundle पर एक समान चलाता है। Pro निशाना जोड़ता है: आप [एक region mark करते हैं](https://www.afterpack.dev/hi/docs/directives) और केवल उसी code को भारी treatment मिलता है। [Tiers](https://www.afterpack.dev/hi/docs/tiers) में पूरी matrix और कीमतें हैं।

## क्या मुझे framework plugin चाहिए?

[First-class framework](https://www.afterpack.dev/hi/docs/frameworks) के लिए, हाँ। [Plugin install करें](https://www.afterpack.dev/hi/docs/quickstart#pick-your-framework) dev dependency के रूप में और एक config लाइन जोड़ें, और आपकी **सामान्य build** obfuscated output emit करती है। Engine कहाँ चलता है, यह bundler पर निर्भर है: Vite, Rollup, webpack और Parcel bundler की अपनी pipeline के अंदर obfuscate करते हैं, [Next.js](https://www.afterpack.dev/hi/docs/frameworks/nextjs) `next build` के अंदर एक hook से obfuscate करता है, और esbuild व Angular अपनी build लिख लेने के बाद एक pass चलाते हैं।

```bash
npm install -D @afterpack/vite
```

Pure-bundler या [zero-plugin stacks](https://www.afterpack.dev/hi/docs/cli) के लिए, इसके बजाय [CLI](https://www.afterpack.dev/hi/docs/cli) को अपने build output पर point करें:

```bash
npx afterpack@latest dist/
```

दोनों ही तरह से, AfterPack सख़्ती से post-build, आपके built output पर चलता है। [Build directory](https://www.afterpack.dev/hi/docs/cli#usage) देना वैकल्पिक है: न दें, तो CLI आपका build output खुद पहचान लेता है। Plugin-supported frameworks पर [CI](https://www.afterpack.dev/hi/docs/builds) और manual एक-बार के runs के लिए भी CLI ही तरीका है।

## एक ही code हर build में अलग output क्यों देता है?

यह [per-build polymorphism](https://www.afterpack.dev/hi/docs/glossary#per-build-polymorphism) है, और यही मुख्य बचाव है। डिफ़ॉल्ट random [seed](https://www.afterpack.dev/hi/docs/config#seed) के साथ, एक ही input की दो builds संरचना में अलग निकलती हैं। जो static deobfuscator build N का आकार सीखता है, उसे build N+1 के लिए दोबारा इस्तेमाल करने लायक कुछ नहीं मिलता, इसलिए production को समय-समय पर दोबारा build करना attacker की प्रगति को बार-बार शून्य पर लाता रहता है।

जब आपको एक जैसे bytes चाहिए, CI cache hits या golden-snapshot tests के लिए, तो seed को [`--seed`](https://www.afterpack.dev/hi/docs/config#seed) से pin करें:

```bash
npx afterpack@latest dist/ --seed=git
```

Release model: तेज़ iteration के लिए dev builds un-obfuscated रहती हैं; production obfuscated artifact को **एक बार** build करता है और वही bytes qa, preprod और prod में promote करता है। देखें [Builds & CI](https://www.afterpack.dev/hi/docs/builds)।

## क्या Free सिर्फ़ renaming है?

नहीं। Free पूरा engine चलाता है। डिफ़ॉल्ट `light` preset identifiers को rename करता है और हर उस string literal को encode करता है जिसे वह फिर से लिख सकता है। `medium` और ऊपर, Free control flow को flatten भी करता है, logic को fuse और inflate करता है, और constants को materialize करता है, सब कुछ एक फ़ाइल के भीतर। उस output की संरचना बदली जाती है, सिर्फ़ नाम नहीं, और यह polynomial-injective [reversal class](https://www.afterpack.dev/hi/docs/reversal-classes) में रहता है: मूल संरचना केवल असली मेहनत से recover की जा सकती है, और यह मेहनत हर build पर दोबारा करनी पड़ती है।

## क्या directive केवल एक लाइन पर असर करता है?

नहीं। Directive एक पूरे **[region](https://www.afterpack.dev/hi/docs/directives#what-you-can-set)** का scope तय करता है, सिर्फ़ अपनी लाइन का नहीं। किसी function के ऊपर वाली लाइन पर अकेले [`/* @afterpack preset=hard */`](https://www.afterpack.dev/hi/docs/config#preset) से block खोलें और closing brace के बाद [`/* @afterpack end */`](https://www.afterpack.dev/hi/docs/directives#what-you-can-set) से बंद करें, तो यह body समेत पूरे function को कवर करता है:

```ts
/* @afterpack preset=hard */
export function checkLicense(token: string) {
  // the entire function body is covered
}
/* @afterpack end */
```

यह [block रूप](https://www.afterpack.dev/hi/docs/directives#writing-one) है: अपनी लाइन पर अकेला एक opener, जिसे मेल खाने वाला `/* @afterpack end */` बंद करता है। एक अकेले value के लिए, inline [`/* @afterpack preset=extreme */`](https://www.afterpack.dev/hi/docs/config#preset) अपनी लाइन के बाकी हिस्से को कवर करता है, यानी ठीक उसके बाद वाले literal या expression को। पूरे grammar के लिए [Directives](https://www.afterpack.dev/hi/docs/directives#writing-one) देखें।

## अगर Pro cloud down हो तो क्या होता है?

यह backoff के साथ retry करता है, फिर [fail closed](https://www.afterpack.dev/hi/docs/diagnostics#fail-closed-no-exceptions) होता है: cloud outage आपकी माँगी गई सुरक्षा से कम सुरक्षा ship करने के बजाय CI को तोड़ देता है।

अगर आपको build path में कोई भी third-party dependency नहीं चाहिए, तो [Free](https://www.afterpack.dev/hi/docs/pro#what-free-already-gives-you) को local पर चलाएँ — यह कभी network call नहीं करता। देखें [Deployment modes](https://www.afterpack.dev/hi/docs/deployment-modes)।

## Source maps कैसे काम करते हैं?

AfterPack के source maps obfuscated output को आपके मूल source से वापस जोड़ते हैं। वे local debugging के लिए उपयोगी हैं। इन्हें कभी production में ship न करें: एक public `.map` attacker को उसी source तक सीधा रास्ता दे देता है जिसे आपने अभी obfuscate किया।

AfterPack डिफ़ॉल्ट रूप से उन्हें आपके production bundle से बाहर रखता है: [production](https://www.afterpack.dev/hi/docs/config#build-mode) build पर [source-map emission](https://www.afterpack.dev/hi/docs/config#sourceMap-enabled) बंद रहता है, [`//# sourceMappingURL=`](https://www.afterpack.dev/hi/docs/config#sourceMap-emitUrl) comment हटा दिया जाता है, और आपके bundler के लिखे source maps मिटा दिए जाते हैं, CSS maps समेत। हर build production है जब तक वह ख़ुद को development न बताए, local `npx afterpack` भी। देखें [Best practices](https://www.afterpack.dev/hi/docs/best-practices)।

## क्या मैं CI में AfterPack इस्तेमाल कर सकता हूँ?

हाँ। First-class framework के लिए plugin आपकी सामान्य build के हिस्से के रूप में चलता है, इसलिए आपका मौजूदा build चरण पहले से obfuscated output emit करता है। दूसरे stacks के लिए, post-build चरण के रूप में [`npx afterpack@latest <path>`](https://www.afterpack.dev/hi/docs/cli#usage) जोड़ें।

Reproducible artifacts के लिए [seed](https://www.afterpack.dev/hi/docs/config#seed) को अपने release identifier पर pin करें, obfuscated output एक बार build करें, और वही bytes अपने environments में promote करें। हर release का [audit](https://www.afterpack.dev/hi/docs/audit) करें और [Protection Map](https://www.afterpack.dev/hi/docs/protection-map) को CI artifact के रूप में जोड़ें। पूरी pipeline के उदाहरण के लिए [Builds & CI](https://www.afterpack.dev/hi/docs/builds) देखें।

## क्या obfuscation मेरे code को धीमा करता है?

थोड़ा। Control flow की संरचना बदलने और constants को दोबारा बनाने से runtime पर काम बढ़ता है, लेकिन एक सामान्य web app पर यह लागत network और rendering के समय की तुलना में आमतौर पर छोटी होती है।

[Preset](https://www.afterpack.dev/hi/docs/presets#the-ladder) जितना बड़ा, लागत उतनी ज़्यादा: हर पायदान एक ऊँची [`complexity`](https://www.afterpack.dev/hi/docs/config#complexity) से जुड़ा है, और default `light` है। भारी preset ज़्यादा transformation लगाता है; यह सुरक्षा में मापी गई बढ़त नहीं है। Global preset को `light` पर रखें जब तक कोई भारी preset अपनी लागत के लायक न हो, और `extreme` को उन [regions](https://www.afterpack.dev/hi/docs/directives) के लिए रखें जिन्हें आप mark करते हैं। पायदान और उनकी values [Presets](https://www.afterpack.dev/hi/docs/presets#the-ladder) पर हैं।

## API keys और license logic को कैसे protect करूँ?

उन्हें mark करें। किसी secret literal पर inline [`/* @afterpack preset=extreme */`](https://www.afterpack.dev/hi/docs/config#preset) इस्तेमाल करें, और licensing को gate करने वाले function को [`/* @afterpack preset=hard */`](https://www.afterpack.dev/hi/docs/config#preset) … [`/* @afterpack end */`](https://www.afterpack.dev/hi/docs/directives#what-you-can-set) block में लपेटें:

```ts
const LICENSE_SECRET = /* @afterpack preset=extreme */ "YOUR_SECRET";

/* @afterpack preset=hard */
export function checkLicense(token: string) {
  /* ... */
}
/* @afterpack end */
```

[`preset=extreme`](https://www.afterpack.dev/hi/docs/config#preset) उस region को [complexity target](https://www.afterpack.dev/hi/docs/config#complexity) 25 तक ले जाता है और [string floor](https://www.afterpack.dev/hi/docs/config#strings-encode) को ज़बरदस्ती चालू रखता है, इसलिए literal cleartext में ship होने के बजाय encode होता है। वह फिर भी output में मौजूद रहता है, और program इस्तेमाल के समय उसे दोबारा बनाता है। जिस literal से आपका code तुलना करता है, उसे output से पूरी तरह बाहर रखने के लिए [`transforms.comparisonHardening.enabled`](https://www.afterpack.dev/hi/docs/config#transforms-kind-enabled) चालू करें: तुलना एक one-way digest check बन जाती है और केवल digest ship होता है। दोनों ही तरह से, जो attacker code को एक instrumented runtime में चलाता है, वह फिर भी value तक पहुँच सकता है (अगला सवाल देखें)। ये directives हर release पर static recovery की लागत बढ़ाते हैं। वे किसी high-value secret को ऐसी चीज़ में नहीं बदलते जिसे client-side रखना सुरक्षित हो। पूरे pattern के लिए [Best practices](https://www.afterpack.dev/hi/docs/best-practices) देखें।

## क्या मेरा code चलाने वाला कोई secret निकाल सकता है?

हाँ। एक दृढ़ attacker जो आपका code एक instrumented runtime में चलाता है, वह किसी भी ऐसे secret तक पहुँच सकता है जिसे code खुद इस्तेमाल करता है। कोई भी build-time obfuscator इसे नहीं बदलता: अगर चलते हुए program को अपना काम करने के लिए value चाहिए, तो वह उस व्यक्ति को दिख सकती है जो runtime को patch करता है, सही call को hook करता है, या सही पल पर heap का snapshot लेता है।

AfterPack value को सस्ते attacks से अदृश्य बनाता है: static reader और वह blind LLM जो code को चलाए बिना समझाता है। [Non-materialization](https://www.afterpack.dev/hi/docs/glossary#non-materialization) एक gated literal को artifact से पूरी तरह बाहर रखता है, [string floor](https://www.afterpack.dev/hi/docs/config#strings-encode) बाकी को cleartext से बाहर रखता है, और [per-build polymorphism](https://www.afterpack.dev/hi/docs/glossary#per-build-polymorphism) की वजह से एक build के patterns के लिए लिखे गए tools अगले पर टूट जाते हैं। Code चलाने वाला व्यक्ति फिर भी उसमें इस्तेमाल होने वाली values पढ़ सकता है।

Obfuscation client-side secret की static और re-extraction लागत बढ़ाता है। किसी high-value secret को attacker की पहुँच से बाहर रखने का एकमात्र तरीका है उसे कभी client तक ship न करना: उसे server-side रखें और फ़ैसला server से करवाएँ। [`preset=extreme`](https://www.afterpack.dev/hi/docs/config#preset) उन secrets के लिए इस्तेमाल करें जो सच में server-side नहीं जा सकते, और इसे लागत बढ़ाने वाला मानें, कभी तिजोरी नहीं।

## कौन-से frameworks supported हैं?

इन stacks का published plugin है: [Next.js](https://www.afterpack.dev/hi/docs/frameworks/nextjs), [Vite](https://www.afterpack.dev/hi/docs/frameworks/vite), [Webpack](https://www.afterpack.dev/hi/docs/frameworks/webpack), [Rollup](https://www.afterpack.dev/hi/docs/frameworks/rollup), [esbuild](https://www.afterpack.dev/hi/docs/frameworks/esbuild), [Astro](https://www.afterpack.dev/hi/docs/frameworks/astro), [Svelte](https://www.afterpack.dev/hi/docs/frameworks/svelte), [SvelteKit](https://www.afterpack.dev/hi/docs/frameworks/sveltekit), [Vue 3](https://www.afterpack.dev/hi/docs/frameworks/vue), [Nuxt 3](https://www.afterpack.dev/hi/docs/frameworks/nuxt), [Angular v17+](https://www.afterpack.dev/hi/docs/frameworks/angular), [Electron](https://www.afterpack.dev/hi/docs/frameworks/electron) और [Parcel](https://www.afterpack.dev/hi/docs/frameworks/parcel)। Plugin अपनी output directory जानता है, इसलिए उसे कहीं point करने की ज़रूरत नहीं।

[Remix](https://www.afterpack.dev/hi/docs/frameworks/remix) और [plain JS](https://www.afterpack.dev/hi/docs/frameworks/plain) post-build [CLI](https://www.afterpack.dev/hi/docs/cli#usage) से चलते हैं, जहाँ directory का नाम आप खुद देते हैं (`npx afterpack@latest dist/`; Next.js `.next/` में लिखता है, Nuxt `.output/` में)। पूरी matrix और हर stack के setup के लिए [Frameworks](https://www.afterpack.dev/hi/docs/frameworks) देखें, और अगर आप देखना चाहते हैं कि किसी असली bundle पर सुरक्षा कैसी दिखती है तो public [Security Scanner](https://www.afterpack.dev/hi/security-scanner) देखें।

## सवाल कहाँ पूछूँ, bug कहाँ report करूँ या feature का प्रस्ताव कहाँ दूँ?

GitHub पर। सवाल और प्रस्ताव [GitHub Discussions](https://github.com/afterpack-dev/afterpack/discussions) में जाते हैं; bugs [GitHub Issues](https://github.com/afterpack-dev/afterpack/issues) में। Security issue public thread के बजाय **security@afterpack.dev** पर भेजें, देखें [SLAs, SLOs & support](https://www.afterpack.dev/hi/docs/sla#security-disclosure)।

## आगे

- [Quickstart](https://www.afterpack.dev/hi/docs/quickstart): कुछ ही मिनटों में install, build, ship
- [Tiers](https://www.afterpack.dev/hi/docs/tiers): Free बनाम Pro, feature-दर-feature
- [Config](https://www.afterpack.dev/hi/docs/config): हर option, और कौन-सा रूप उसे सेट कर सकता है
- [Directives](https://www.afterpack.dev/hi/docs/directives): `@afterpack` grammar और कौन-सी keys लागू होती हैं
- [Presets](https://www.afterpack.dev/hi/docs/presets): पाँच पायदानों की सीढ़ी
- [Best practices](https://www.afterpack.dev/hi/docs/best-practices): secrets, source maps, और CI