Obfuscator.io

Obfuscator.io

विकल्प संदर्भ

विषय-सूची

compact

Type: boolean Default: true

एक ही लाइन में कॉम्पैक्ट कोड आउटपुट।

config

Type: string Default: ``

JS/JSON कॉन्फ़िग फ़ाइल का नाम जिसमें ऑब्फ़स्केटर विकल्प होते हैं। इन्हें सीधे CLI को पास किए गए विकल्पों द्वारा ओवरराइड कर दिया जाएगा

controlFlowFlattening

Type: boolean Default: false

⚠️ यह विकल्प प्रदर्शन पर काफ़ी असर डालता है, रनटाइम गति 1.5x तक धीमी हो सकती है। कितने प्रतिशत नोड्स control flow flattening से प्रभावित होंगे यह तय करने के लिए controlFlowFlatteningThreshold का उपयोग करें।

कोड control flow flattening सक्षम करता है। Control flow flattening सोर्स कोड का एक संरचनात्मक रूपांतरण है जो प्रोग्राम को समझना कठिन बना देता है।

उदाहरण:

// input
(function(){
    function foo () {
        return function () {
            var sum = 1 + 2;
            console.log(1);
            console.log(2);
            console.log(3);
            console.log(4);
            console.log(5);
            console.log(6);
        }
    }
    
    foo()();
})();

// output
(function () {
    function _0x3bfc5c() {
        return function () {
            var _0x3260a5 = {
                'WtABe': '4|0|6|5|3|2|1',
                'GokKo': function _0xf87260(_0x427a8e, _0x43354c) {
                    return _0x427a8e + _0x43354c;
                }
            };
            var _0x1ad4d6 = _0x3260a5['WtABe']['split']('|'), _0x1a7b12 = 0x0;
            while (!![]) {
                switch (_0x1ad4d6[_0x1a7b12++]) {
                case '0':
                    console['log'](0x1);
                    continue;
                case '1':
                    console['log'](0x6);
                    continue;
                case '2':
                    console['log'](0x5);
                    continue;
                case '3':
                    console['log'](0x4);
                    continue;
                case '4':
                    var _0x1f2f2f = _0x3260a5['GokKo'](0x1, 0x2);
                    continue;
                case '5':
                    console['log'](0x3);
                    continue;
                case '6':
                    console['log'](0x2);
                    continue;
                }
                break;
            }
        };
    }

	_0x3bfc5c()();
}());

controlFlowFlatteningThreshold

Type: number Default: 0.75 Min: 0 Max: 1

वह प्रायिकता कि किसी दिए गए नोड पर controlFlowFlattening रूपांतरण लागू किया जाएगा।

यह सेटिंग बड़े कोड आकार के लिए खासकर उपयोगी है, क्योंकि बड़ी मात्रा में control flow रूपांतरण आपके कोड को धीमा कर सकते हैं और कोड का आकार बढ़ा सकते हैं।

controlFlowFlatteningThreshold: 0 का मतलब है controlFlowFlattening: false।

deadCodeInjection

Type: boolean Default: false

⚠️ ऑब्फ़स्केटेड कोड का आकार नाटकीय रूप से बढ़ा देता है (200% तक), इसका उपयोग केवल तभी करें जब ऑब्फ़स्केटेड कोड का आकार मायने न रखता हो। कितने प्रतिशत नोड्स dead code injection से प्रभावित होंगे यह तय करने के लिए deadCodeInjectionThreshold का उपयोग करें।
⚠️ यह विकल्प stringArray विकल्प को ज़बरन सक्षम कर देता है।
⚠️ जब vmObfuscation सक्षम हो, तो यह विकल्प चुपचाप अक्षम हो जाता है।

इस विकल्प के साथ, ऑब्फ़स्केटेड कोड में डेड कोड के बेतरतीब ब्लॉक जोड़ दिए जाएँगे।

उदाहरण:

// input
(function(){
    if (true) {
        var foo = function () {
            console.log('abc');
        };
        var bar = function () {
            console.log('def');
        };
        var baz = function () {
            console.log('ghi');
        };
        var bark = function () {
            console.log('jkl');
        };
        var hawk = function () {
            console.log('mno');
        };

        foo();
        bar();
        baz();
        bark();
        hawk();
    }
})();

// output
var _0x37b8 = [
    'YBCtz',
    'GlrkA',
    'urPbb',
    'abc',
    'NMIhC',
    'yZgAj',
    'zrAId',
    'EtyJA',
    'log',
    'mno',
    'jkl',
    'def',
    'Quzya',
    'IWbBa',
    'ghi'
];
function _0x43a7(_0x12cf56, _0x587376) {
    _0x43a7 = function (_0x2f87a8, _0x47eac2) {
        _0x2f87a8 = _0x2f87a8 - (0x16a7 * 0x1 + 0x5 * 0x151 + -0x1c92);
        var _0x341e03 = _0x37b8[_0x2f87a8];
        return _0x341e03;
    };
    return _0x43a7(_0x12cf56, _0x587376);
}
(function () {
    if (!![]) {
        var _0xbbe28f = function () {
            var _0x2fc85f = _0x43a7;
            if (_0x2fc85f(0xaf) === _0x2fc85f(0xae)) {
                _0x1dd94f[_0x2fc85f(0xb2)](_0x2fc85f(0xb5));
            } else {
                console[_0x2fc85f(0xb2)](_0x2fc85f(0xad));
            }
        };
        var _0x5e46bc = function () {
            var _0x15b472 = _0x43a7;
            if (_0x15b472(0xb6) !== _0x15b472(0xaa)) {
                console[_0x15b472(0xb2)](_0x15b472(0xb5));
            } else {
                _0x47eac2[_0x15b472(0xb2)](_0x15b472(0xad));
            }
        };
        var _0x3669e8 = function () {
            var _0x47a442 = _0x43a7;
            if (_0x47a442(0xb7) !== _0x47a442(0xb0)) {
                console[_0x47a442(0xb2)](_0x47a442(0xb8));
            } else {
                _0x24e0bf[_0x47a442(0xb2)](_0x47a442(0xb3));
            }
        };
        var _0x28b05a = function () {
            var _0x497902 = _0x43a7;
            if (_0x497902(0xb1) === _0x497902(0xb1)) {
                console[_0x497902(0xb2)](_0x497902(0xb4));
            } else {
                _0x59c9c6[_0x497902(0xb2)](_0x497902(0xb4));
            }
        };
        var _0x402a54 = function () {
            var _0x1906b7 = _0x43a7;
            if (_0x1906b7(0xab) === _0x1906b7(0xac)) {
                _0xb89cd0[_0x1906b7(0xb2)](_0x1906b7(0xb8));
            } else {
                console[_0x1906b7(0xb2)](_0x1906b7(0xb3));
            }
        };
        _0xbbe28f();
        _0x5e46bc();
        _0x3669e8();
        _0x28b05a();
        _0x402a54();
    }
}());

deadCodeInjectionThreshold

Type: number Default: 0.4 Min: 0 Max: 1

कितने प्रतिशत नोड्स deadCodeInjection से प्रभावित होंगे, यह सेट करने की अनुमति देता है।

debugProtection

Type: boolean Default: false

⚠️ अगर आप Developer Tools खोलते हैं तो यह आपके ब्राउज़र को फ़्रीज़ कर सकता है।
⚠️ जब vmObfuscation सक्षम हो, तो यह विकल्प चुपचाप अक्षम हो जाता है। इसके बजाय vmDebugProtection का उपयोग करें।

यह विकल्प Developer Tools के debugger फ़ंक्शन का उपयोग करना लगभग असंभव बना देता है (WebKit-आधारित और Mozilla Firefox दोनों पर)।

debugProtectionInterval

Type: number Default: 0

⚠️ आपके ब्राउज़र को फ़्रीज़ कर सकता है! अपने जोखिम पर उपयोग करें।
⚠️ जब vmObfuscation सक्षम हो, तो यह विकल्प चुपचाप अक्षम हो जाता है। इसके बजाय vmDebugProtection का उपयोग करें।

अगर सेट किया गया हो, तो Console टैब पर डिबग मोड को ज़बरन लागू करने के लिए मिलीसेकंड में एक इंटरवल उपयोग होता है, जिससे Developer Tools की अन्य सुविधाओं का उपयोग करना कठिन हो जाता है। यह तभी काम करता है जब debugProtection सक्षम हो। अनुशंसित मान 2000 और 4000 मिलीसेकंड के बीच है।

disableConsoleOutput

Type: boolean Default: false

⚠️ यह विकल्प सभी स्क्रिप्ट्स के लिए console कॉल्स को विश्व-स्तर पर बंद कर देता है

console.log, console.info, console.error, console.warn, console.debug, console.exception और console.trace को खाली फ़ंक्शन्स से बदलकर उनके उपयोग को बंद कर देता है। इससे डिबगर का उपयोग करना कठिन हो जाता है।

domainLock

Type: string[] Default: []

⚠️ यह विकल्प target: 'node', target: 'service-worker' या target: 'bytenode' के साथ काम नहीं करता

ऑब्फ़स्केटेड सोर्स कोड को केवल विशिष्ट डोमेन और/या सब-डोमेन पर चलाने की अनुमति देता है। इससे किसी के लिए आपके सोर्स कोड को कॉपी-पेस्ट करके कहीं और चलाना वाकई कठिन हो जाता है।

अगर सोर्स कोड इस विकल्प द्वारा निर्दिष्ट डोमेन पर नहीं चलता, तो ब्राउज़र को domainLockRedirectUrl विकल्प में पास किए गए URL पर रीडायरेक्ट कर दिया जाएगा।

एक से अधिक डोमेन और सब-डोमेन

अपने कोड को एक से अधिक डोमेन या सब-डोमेन तक लॉक करना संभव है। उदाहरण के लिए, इसे इस तरह लॉक करने के लिए कि कोड केवल www.example.com पर चले, www.example.com जोड़ें। इसे रूट डोमेन सहित किसी भी सब-डोमेन (example.com, sub.example.com) पर काम कराने के लिए .example.com उपयोग करें।

domainLockRedirectUrl

Type: string Default: about:blank

⚠️ यह विकल्प target: 'node', target: 'service-worker' या target: 'bytenode' के साथ काम नहीं करता

अगर सोर्स कोड domainLock द्वारा निर्दिष्ट डोमेन पर नहीं चलता, तो ब्राउज़र को पास किए गए URL पर रीडायरेक्ट करने की अनुमति देता है

exclude

Type: string[] Default: []

फ़ाइल नाम या ग्लोब्स जो यह बताते हैं कि किन फ़ाइलों को ऑब्फ़स्केशन से बाहर रखना है।

forceTransformStrings

Type: string[] Default: []

पास किए गए RegExp पैटर्न से मेल खाने वाले स्ट्रिंग लिटरल्स का ज़बरन रूपांतरण सक्षम करता है।

⚠️ यह विकल्प केवल उन स्ट्रिंग्स पर असर डालता है जिन्हें stringArrayThreshold (या भविष्य में संभावित अन्य थ्रेशोल्ड्स) द्वारा रूपांतरित नहीं किया जाना चाहिए

इस विकल्प की प्राथमिकता reservedStrings विकल्प से अधिक है, लेकिन conditional comments से अधिक नहीं है।

उदाहरण:

	{
		forceTransformStrings: [
			'some-important-value',
			'some-string_\d'
		]
	}

identifierNamesCache

Type: Object | null Default: null

इस विकल्प का मुख्य उद्देश्य कई सोर्स/फ़ाइलों के ऑब्फ़स्केशन के दौरान एक ही आइडेंटिफ़ायर नामों का उपयोग करने की क्षमता है।

फ़िलहाल आइडेंटिफ़ायर के दो प्रकार समर्थित हैं:

  • ग्लोबल आइडेंटिफ़ायर:
    • सभी ग्लोबल आइडेंटिफ़ायर कैश में लिखे जाएँगे;
    • सभी मेल खाने वाले अघोषित ग्लोबल आइडेंटिफ़ायर कैश की वैल्यूज़ से बदल दिए जाएँगे।
  • प्रॉपर्टी आइडेंटिफ़ायर, केवल तब जब renameProperties विकल्प सक्षम हो:
    • सभी प्रॉपर्टी आइडेंटिफ़ायर कैश में लिखे जाएँगे;
    • सभी मेल खाने वाले प्रॉपर्टी आइडेंटिफ़ायर कैश की वैल्यूज़ से बदल दिए जाएँगे।

Node.js API

अगर null वैल्यू पास की जाती है, तो कैश पूरी तरह बंद हो जाता है।

अगर एक खाली ऑब्जेक्ट ({}) पास किया जाता है, तो कैश-ऑब्जेक्ट (TIdentifierNamesCache प्रकार) में आइडेंटिफ़ायर नामों को लिखना सक्षम हो जाता है। इस कैश-ऑब्जेक्ट तक ObfuscationResult ऑब्जेक्ट की getIdentifierNamesCache मेथड कॉल के ज़रिए पहुँचा जा सकेगा।

परिणामी कैश-ऑब्जेक्ट को आगे identifierNamesGenerator विकल्प की वैल्यू के रूप में उपयोग किया जा सकता है, ताकि अगले सोर्स के सभी मेल खाने वाले आइडेंटिफ़ायर नामों के ऑब्फ़स्केशन के दौरान इन्हीं नामों का उपयोग हो।

उदाहरण:

const source1ObfuscationResult = JavaScriptObfuscator.obfuscate(
    `
        function foo(arg) {
           console.log(arg)
        }
        
        function bar() {
            var bark = 2;
        }
    `,
    {
        compact: false,
        identifierNamesCache: {},
        renameGlobals: true
    }
)

console.log(source1ObfuscationResult.getIdentifierNamesCache());
/*
    { 
        globalIdentifiers: {
            foo: '_0x5de86d',
            bar: '_0x2a943b'
        }
    }
*/



const source2ObfuscationResult = JavaScriptObfuscator.obfuscate(
    `
        // Expecting that these global functions are defined in another obfuscated file
        foo(1);
        bar();
        
        // Expecting that this global function is defined in third-party package
        baz();
    `,
    {
        compact: false,
        identifierNamesCache: source1ObfuscationResult.getIdentifierNamesCache(),
        renameGlobals: true
    }
)

console.log(source2ObfuscationResult.getObfuscatedCode());
/*
    _0x5de86d(0x1);
    _0x2a943b();
    baz();
 */

CLI

CLI में एक अलग विकल्प --identifier-names-cache-path है जो मौजूदा .json फ़ाइल का पाथ परिभाषित करने की अनुमति देता है, जिसका उपयोग आइडेंटिफ़ायर नामों का कैश पढ़ने और लिखने के लिए किया जाएगा।

अगर किसी खाली फ़ाइल का पाथ पास किया जाए, तो आइडेंटिफ़ायर नामों का कैश उस फ़ाइल में लिखा जाएगा।

मौजूदा कैश वाली इस फ़ाइल को फिर से --identifier-names-cache-path विकल्प की वैल्यू के रूप में उपयोग किया जा सकता है, ताकि अगली फ़ाइलों के सभी मेल खाने वाले आइडेंटिफ़ायर नामों के ऑब्फ़स्केशन के दौरान इन्हीं नामों का उपयोग हो।

identifierNamesGenerator

Type: string Default: hexadecimal

आइडेंटिफ़ायर नाम जनरेटर सेट करता है।

उपलब्ध मान:

  • dictionary: identifiersDictionary सूची से आइडेंटिफ़ायर नाम
  • hexadecimal: _0xabc123 जैसे आइडेंटिफ़ायर नाम
  • mangled: छोटे आइडेंटिफ़ायर नाम जैसे a, b, c
  • mangled-shuffled: mangled जैसा ही, लेकिन शफ़ल किए गए अल्फ़ाबेट के साथ

identifiersDictionary

Type: string[] Default: []

identifierNamesGenerator: dictionary विकल्प के लिए आइडेंटिफ़ायर डिक्शनरी सेट करता है। डिक्शनरी के हर आइडेंटिफ़ायर का उपयोग हर अक्षर की अलग-अलग केसिंग के साथ कुछ रूपों में किया जाएगा। इसलिए, डिक्शनरी में आइडेंटिफ़ायर की संख्या मूल सोर्स कोड में आइडेंटिफ़ायर की मात्रा पर निर्भर होनी चाहिए।

identifiersPrefix

Type: string Default: ''

सभी ग्लोबल आइडेंटिफ़ायर के लिए प्रीफ़िक्स सेट करता है।

इस विकल्प का उपयोग तब करें जब आप कई फ़ाइलों को ऑब्फ़स्केट करना चाहते हों। यह विकल्प इन फ़ाइलों के ग्लोबल आइडेंटिफ़ायर के बीच टकराव से बचने में मदद करता है। प्रीफ़िक्स हर फ़ाइल के लिए अलग होना चाहिए।

randomIdentifiersPrefix

Type: boolean Default: false

सभी ग्लोबल आइडेंटिफ़ायर में एक seed-आधारित रैंडम प्रीफ़िक्स (6 अल्फ़ान्यूमेरिक अक्षर) जोड़ता है। अलग-अलग ऑब्फ़स्केट किए गए बंडल्स के बीच टकराव से बचने के लिए इस विकल्प का उपयोग करें जब वे एक ही ग्लोबल स्कोप में लोड होते हों - इससे हर बंडल के लिए मैन्युअल रूप से एक अद्वितीय identifiersPrefix चुनने की ज़रूरत नहीं रहती।

  • रैंडम वैल्यू seed विकल्प और सोर्स कोड हैश से प्राप्त होती है, इसलिए एक ही seed वाली पुनरुत्पादनीय बिल्ड्स एक ही प्रीफ़िक्स देती हैं।
  • जब identifiersPrefix के साथ जोड़ा जाता है, तो रैंडम अक्षर उपयोगकर्ता द्वारा दिए गए प्रीफ़िक्स में जोड़े जाते हैं (उदा., myApp + रैंडम aBc123 → myAppaBc123)।
  • जब vmObfuscation के साथ जोड़ा जाता है, तो रैंडम वैल्यू डिफ़ॉल्ट vm प्रीफ़िक्स की जगह ले लेती है - रैंडमनेस स्वयं ही अद्वितीयता की गारंटी देती है।

ignoreImports

Type: boolean Default: false

require इम्पोर्ट्स के ऑब्फ़स्केशन को रोकता है। कुछ मामलों में यह उपयोगी हो सकता है जब किसी कारण रनटाइम वातावरण को इन इम्पोर्ट्स के लिए केवल स्टैटिक स्ट्रिंग्स की आवश्यकता होती है।

inputFileName

Type: string Default: ''

सोर्स कोड वाली इनपुट फ़ाइल का नाम सेट करने की अनुमति देता है। इस नाम का उपयोग आंतरिक रूप से source map जनरेशन के लिए किया जाएगा। NodeJS API का उपयोग करते समय और जब sourceMapSourcesMode विकल्प का मान sources हो, तब आवश्यक है।

log

Type: boolean Default: false

कंसोल में जानकारी की लॉगिंग सक्षम करता है।

numbersToExpressions

Type: boolean Default: false

संख्याओं को एक्सप्रेशन में बदलना सक्षम करता है

उदाहरण:

// input
const foo = 1234;

// output
const foo=-0xd93+-0x10b4+0x41*0x67+0x84e*0x3+-0xff8;

optionsPreset

Type: string Default: default

options preset सेट करने की अनुमति देता है।

उपलब्ध मान:

  • vm-default;
  • vm-low-obfuscation;
  • vm-medium-obfuscation;
  • vm-high-obfuscation;
  • vm-ultra-high-obfuscation;
  • default;
  • low-obfuscation;
  • medium-obfuscation;
  • high-obfuscation।

सभी अतिरिक्त विकल्प चयनित options preset के साथ मर्ज कर दिए जाएँगे।

parseHtml

Type: boolean Default: false

HTML <script> टैग्स के भीतर के JavaScript का ऑब्फ़स्केशन सक्षम करता है।

सक्षम होने पर, ऑब्फ़स्केटर यह करेगा:

  • स्वतः पता लगाएगा कि इनपुट HTML है या नहीं (<!DOCTYPE, <html>, <head>, <body>, या <script> टैग्स की जाँच करके)
  • data-javascript-obfuscator एट्रिब्यूट से चिह्नित <script> टैग्स से JavaScript निकालेगा
  • HTML संरचना को बनाए रखते हुए हर चिह्नित स्क्रिप्ट को अलग-अलग ऑब्फ़स्केट करेगा
  • ऑब्फ़स्केटेड कोड को वापस मूल स्थानों पर डालेगा

महत्वपूर्ण: केवल data-javascript-obfuscator एट्रिब्यूट वाली स्क्रिप्ट्स ही ऑब्फ़स्केट होती हैं। हर चिह्नित स्क्रिप्ट को अलग-अलग और स्वतंत्र रूप से ऑब्फ़स्केट किया जाता है। इसका मतलब है:

  • चिह्नित script टैग्स के भीतर का कोड अलग-थलग होना चाहिए - इसे अन्य चिह्नित script टैग्स में परिभाषित वेरिएबल्स, फ़ंक्शन्स या क्लासेस का संदर्भ नहीं देना चाहिए
  • अचिह्नित स्क्रिप्ट्स अब भी चिह्नित स्क्रिप्ट्स द्वारा परिभाषित ग्लोबल्स तक पहुँच सकती हैं (var घोषणाओं या स्पष्ट globalThis असाइनमेंट्स के ज़रिए)
  • इससे आपको यह स्पष्ट नियंत्रण मिलता है कि किन स्क्रिप्ट्स को सुरक्षित करना है

ऑब्फ़स्केटेड (data-javascript-obfuscator एट्रिब्यूट होना चाहिए):

  • <script data-javascript-obfuscator> - सामान्य स्क्रिप्ट्स
  • <script type="text/javascript" data-javascript-obfuscator> - स्पष्ट रूप से टाइप की गई स्क्रिप्ट्स
  • किसी भी अतिरिक्त एट्रिब्यूट्स वाली स्क्रिप्ट्स (id, class, अन्य data-*, आदि)

छोड़ी गईं (अपरिवर्तित रहती हैं):

  • data-javascript-obfuscator एट्रिब्यूट के बिना स्क्रिप्ट्स
  • <script type="module"> - ES मॉड्यूल्स (एट्रिब्यूट होने पर भी)
  • <script src="..."> - बाहरी स्क्रिप्ट्स (एट्रिब्यूट होने पर भी)
  • खाली script टैग्स

नोट: parseHtml सक्षम होने पर source maps जनरेट नहीं होते, क्योंकि वे HTML आउटपुट से सही मैप नहीं होंगे।

उदाहरण:

// input
const html = `<!DOCTYPE html>
<html>
<body>
<!-- This script will NOT be obfuscated -->
<script>
var helper = 'utility';
</script>

<!-- This script WILL be obfuscated -->
<script data-javascript-obfuscator>
var greeting = 'Hello World';
console.log(greeting);
</script>
</body>
</html>`;

JavaScriptObfuscator.obfuscate(html, {
    parseHtml: true,
    stringArray: true
});

// output: HTML with only the marked script obfuscated

renameGlobals

Type: boolean Default: false

⚠️ यह विकल्प आपके कोड को तोड़ सकता है। इसे केवल तभी सक्षम करें जब आप जानते हों कि यह क्या करता है!

ग्लोबल वेरिएबल और फ़ंक्शन नामों का ऑब्फ़स्केशन घोषणा सहित सक्षम करता है।

जब यह विकल्प अक्षम हो और इनपुट कोड ग्लोबल स्कोप में फ़ंक्शन्स या क्लासेस घोषित करता हो (यानी कोड किसी IIFE में लपेटा नहीं गया हो), तो ऑब्फ़स्केटेड आउटपुट में उनके नाम जस के तस रखे जाते हैं - अन्य स्क्रिप्ट्स उन्हें नाम से संदर्भित कर सकती हैं। vmObfuscation के तहत इन नामों को सूचीबद्ध करती हुई एक VMGlobalFunctionNamesNotRenamed चेतावनी रिपोर्ट की जाती है, क्योंकि फ़ंक्शन बॉडी बाइटकोड के रूप में छिपा दी जाती है लेकिन पठनीय टॉप-लेवल नाम अब भी यह उजागर करता है कि कोड क्या करता है (उदा. किसी LLM को)। इस उजागर होने से बचने के लिए, कोड को किसी IIFE में लपेटें या इस विकल्प को सक्षम करें।

renameProperties

Type: boolean Default: false

⚠️ यह विकल्प आपके कोड को तोड़ सकता है। इसे केवल तभी सक्षम करें जब आप जानते हों कि यह क्या करता है!

प्रॉपर्टी नामों का नाम बदलना सक्षम करता है। सभी बिल्ट-इन DOM प्रॉपर्टीज़ और कोर JavaScript क्लासेस की प्रॉपर्टीज़ को अनदेखा किया जाएगा।

इस विकल्प के safe और unsafe मोड्स के बीच स्विच करने के लिए renamePropertiesMode विकल्प का उपयोग करें।

नाम बदले गए प्रॉपर्टी नामों का फ़ॉर्मैट सेट करने के लिए identifierNamesGenerator विकल्प का उपयोग करें।

कौन-सी प्रॉपर्टीज़ के नाम बदले जाएँ यह नियंत्रित करने के लिए reservedNames विकल्प का उपयोग करें।

उदाहरण:

// input
(function () {
    const foo = {
        prop1: 1,
        prop2: 2,
        calc: function () {
            return this.prop1 + this.prop2;
        }
    };
    
    console.log(foo.calc());
})();

// output
(function () {
    const _0x46529b = {
        '_0x10cec7': 0x1,
        '_0xc1c0ca': 0x2,
        '_0x4b961d': function () {
            return this['_0x10cec7'] + this['_0xc1c0ca'];
        }
    };
    console['log'](_0x46529b['_0x4b961d']());
}());

renamePropertiesMode

Type: string Default: safe

⚠️ safe मोड में भी, renameProperties विकल्प आपके कोड को तोड़ सकता है।

renameProperties विकल्प का मोड निर्दिष्ट करता है:

  • safe - 2.11.0 रिलीज़ के बाद का डिफ़ॉल्ट व्यवहार। रनटाइम एरर से बचने के लिए प्रॉपर्टीज़ का नाम अधिक सुरक्षित तरीके से बदलने का प्रयास करता है। इस मोड में कुछ प्रॉपर्टीज़ को नाम बदलने से बाहर रखा जाएगा।
  • unsafe - 2.11.0 रिलीज़ से पहले का डिफ़ॉल्ट व्यवहार। बिना किसी प्रतिबंध के प्रॉपर्टीज़ का नाम असुरक्षित तरीके से बदलता है।

अगर एक फ़ाइल दूसरी फ़ाइल की प्रॉपर्टीज़ का उपयोग कर रही है, तो इन फ़ाइलों के बीच समान प्रॉपर्टी नाम बनाए रखने के लिए identifierNamesCache विकल्प का उपयोग करें।

reservedNames

Type: string[] Default: []

पास किए गए RegExp पैटर्न से मेल खाने वाले आइडेंटिफ़ायर के ऑब्फ़स्केशन और जनरेशन को बंद करता है।

उदाहरण:

	{
		reservedNames: [
			'^someVariable',
			'functionParameter_\d'
		]
	}

reservedStrings

Type: string[] Default: []

पास किए गए RegExp पैटर्न से मेल खाने वाले स्ट्रिंग लिटरल्स के रूपांतरण को बंद करता है। मेल खाने वाली स्ट्रिंग्स ऑब्फ़स्केटेड आउटपुट में दृश्यमान रहेंगी।

VM ऑब्फ़स्केशन का उपयोग करते समय, reserved strings को दृश्यमान रखने के लिए एक अलग अनएन्क्रिप्टेड ऐरे में संग्रहीत किया जाता है। यह उन स्ट्रिंग्स के लिए उपयोगी है जिन्हें पठनीय रहना ज़रूरी है, जैसे मॉनिटरिंग के लिए API एंडपॉइंट्स या लाइब्रेरी आइडेंटिफ़ायर।

उदाहरण:

	{
		reservedStrings: [
			'react-native',
			'\.\/src\/test',
			'some-string_\d'
		]
	}

seed

Type: string|number Default: 0

यह विकल्प रैंडम जनरेटर के लिए seed सेट करता है। यह दोहराए जा सकने वाले परिणाम बनाने के लिए उपयोगी है।

अगर seed 0 है - तो रैंडम जनरेटर बिना seed के काम करेगा।

selfDefending

Type: boolean Default: false

⚠️ इस विकल्प के साथ ऑब्फ़स्केशन के बाद ऑब्फ़स्केटेड कोड को किसी भी तरह न बदलें, क्योंकि कोड को uglify करने जैसा कोई भी बदलाव self defending को ट्रिगर कर सकता है और कोड फिर काम नहीं करेगा!
⚠️ यह विकल्प compact का मान ज़बरन true सेट कर देता है
⚠️ जब vmObfuscation सक्षम हो, तो यह विकल्प चुपचाप अक्षम हो जाता है। इसके बजाय vmSelfDefending का उपयोग करें।

यह विकल्प आउटपुट कोड को फ़ॉर्मैटिंग और वेरिएबल नाम बदलने के विरुद्ध टिकाऊ बना देता है। अगर कोई ऑब्फ़स्केटेड कोड पर JavaScript beautifier उपयोग करने की कोशिश करता है, तो कोड फिर काम नहीं करेगा, जिससे इसे समझना और बदलना कठिन हो जाता है।

simplify

Type: boolean Default: true

सरलीकरण के ज़रिए अतिरिक्त कोड ऑब्फ़स्केशन सक्षम करता है।

⚠️ भविष्य की रिलीज़ में boolean लिटरल्स का ऑब्फ़स्केशन (true => !![]) इस विकल्प के अंतर्गत ले जाया जाएगा।

उदाहरण:

// input
if (condition1) {
    const foo = 1;
    const bar = 2;
  
    console.log(foo);
  
    return bar;
} else if (condition2) {
    console.log(1);
    console.log(2);
    console.log(3);
  
    return 4;
} else {
    return 5;
}

// output
if (condition1) {
    const foo = 0x1, bar = 0x2;
    return console['log'](foo), bar;
} else
    return condition2 ? (console['log'](0x1), console['log'](0x2), console['log'](0x3), 0x4) : 0x5;

sourceMap

Type: boolean Default: false

ऑब्फ़स्केटेड कोड के लिए source map जनरेशन सक्षम करता है।

Source maps आपके ऑब्फ़स्केटेड JavaScript सोर्स कोड को डिबग करने में मदद के लिए उपयोगी हो सकते हैं। अगर आप प्रोडक्शन में डिबग करना चाहते हैं या करना ज़रूरी है, तो आप अलग source map फ़ाइल को किसी गुप्त स्थान पर अपलोड कर सकते हैं और फिर अपने ब्राउज़र को वहाँ इंगित कर सकते हैं।

sourceMapBaseUrl

Type: string Default: ``

जब sourceMapMode: 'separate' हो, तब source map के import url के लिए base url सेट करता है।

CLI उदाहरण:

javascript-obfuscator input.js --output out.js --source-map true --source-map-base-url 'http://localhost:9000'

परिणाम:

//# sourceMappingURL=http://localhost:9000/out.js.map

sourceMapFileName

Type: string Default: ``

जब sourceMapMode: 'separate' हो, तब आउटपुट source map के लिए फ़ाइल नाम सेट करता है।

CLI उदाहरण:

javascript-obfuscator input.js --output out.js --source-map true --source-map-base-url 'http://localhost:9000' --source-map-file-name example

परिणाम:

//# sourceMappingURL=http://localhost:9000/example.js.map

sourceMapMode

Type: string Default: separate

source map जनरेशन मोड निर्दिष्ट करता है:

  • inline - हर .js फ़ाइल के अंत में source map जोड़ता है;
  • separate - source map के साथ संबंधित '.map' फ़ाइल जनरेट करता है। अगर आप ऑब्फ़स्केटर को CLI के ज़रिए चलाते हैं - तो ऑब्फ़स्केटेड कोड वाली फ़ाइल के अंत में source map फ़ाइल का लिंक जोड़ता है //# sourceMappingUrl=file.js.map।

sourceMapSourcesMode

Type: string Default: sources-content

source map के sources और sourcesContent फ़ील्ड्स को नियंत्रित करने की अनुमति देता है:

  • sources-content - एक डमी sources फ़ील्ड जोड़ता है, मूल सोर्स कोड के साथ sourcesContent फ़ील्ड जोड़ता है;
  • sources - एक वैध सोर्स विवरण के साथ sources फ़ील्ड जोड़ता है, sourcesContent फ़ील्ड नहीं जोड़ता। NodeJS API का उपयोग करते समय inputFileName विकल्प परिभाषित करना आवश्यक है, जिसका उपयोग sources फ़ील्ड की वैल्यू के रूप में किया जाएगा।

splitStrings

Type: boolean Default: false

लिटरल स्ट्रिंग्स को splitStringsChunkLength विकल्प की वैल्यू की लंबाई वाले चंक्स में बाँटता है।

उदाहरण:

// input
(function(){
    var test = 'abcdefg';
})();

// output
(function(){
    var _0x5a21 = 'ab' + 'cd' + 'ef' + 'g';
})();

splitStringsChunkLength

Type: number Default: 10

splitStrings विकल्प की चंक लंबाई सेट करता है।

stringArray

Type: boolean Default: true

स्ट्रिंग लिटरल्स को हटाकर एक विशेष ऐरे में रख देता है। उदाहरण के लिए, var m = "Hello World"; में स्ट्रिंग "Hello World" को var m = _0x12c456[0x1]; जैसी किसी चीज़ से बदल दिया जाएगा

stringArrayCallsTransform

Type: boolean Default: false

⚠️ stringArray विकल्प सक्षम होना चाहिए

stringArray की कॉल्स का रूपांतरण सक्षम करता है। इन कॉल्स के सभी आर्गुमेंट्स stringArrayCallsTransformThreshold की वैल्यू के आधार पर एक अलग ऑब्जेक्ट में निकाले जा सकते हैं। इससे string array की कॉल्स को स्वचालित रूप से ढूँढना और भी कठिन हो जाता है।

उदाहरण:

function foo() {
    var k = {
        c: 0x2f2,
        d: '0x396',
        e: '0x397',
        f: '0x39a',
        g: '0x39d',
        h: 0x398,
        l: 0x394,
        m: '0x39b',
        n: '0x39f',
        o: 0x395,
        p: 0x395,
        q: 0x399,
        r: '0x399'
    };
    var c = i(k.d, k.e);
    var d = i(k.f, k.g);
    var e = i(k.h, k.l);
    var f = i(k.m, k.n);
    function i(c, d) {
        return b(c - k.c, d);
    }
    var g = i(k.o, k.p);
    var h = i(k.q, k.r);
}
function j(c, d) {
    var l = { c: 0x14b };
    return b(c - -l.c, d);
}
console[j(-'0xa6', -'0xa6')](foo());
function b(c, d) {
    var e = a();
    b = function (f, g) {
        f = f - 0xa3;
        var h = e[f];
        return h;
    };
    return b(c, d);
}
function a() {
    var m = [
        'string5',
        'string1',
        'log',
        'string3',
        'string6',
        'string2',
        'string4'
    ];
    a = function () {
        return m;
    };
    return a();
}

stringArrayCallsTransformThreshold

Type: number Default: 0.5

⚠️ stringArray और stringArrayCallsTransformThreshold विकल्प सक्षम होने चाहिए

आप इस सेटिंग का उपयोग यह प्रायिकता (0 से 1 तक) समायोजित करने के लिए कर सकते हैं कि string array की कॉल्स रूपांतरित होंगी।

stringArrayEncoding

Type: string[] Default: []

⚠️ stringArray विकल्प सक्षम होना चाहिए

यह विकल्प आपकी स्क्रिप्ट को धीमा कर सकता है।

stringArray के सभी स्ट्रिंग लिटरल्स को base64 या rc4 का उपयोग करके एन्कोड करता है और एक विशेष कोड जोड़ता है जो रनटाइम पर उसे वापस डिकोड करने के लिए उपयोग होता है।

हर stringArray वैल्यू को पास की गई सूची से बेतरतीब चुनी गई एन्कोडिंग द्वारा एन्कोड किया जाएगा। इससे कई एन्कोडिंग्स का उपयोग करना संभव हो जाता है।

उपलब्ध मान:

  • 'none' (boolean): stringArray वैल्यू को एन्कोड नहीं करता
  • 'base64' (string): stringArray वैल्यू को base64 का उपयोग करके एन्कोड करता है
  • 'rc4' (string): stringArray वैल्यू को rc4 का उपयोग करके एन्कोड करता है। base64 से लगभग 30-50% धीमा, लेकिन प्रारंभिक वैल्यूज़ प्राप्त करना कठिन।

उदाहरण के लिए, निम्नलिखित विकल्प वैल्यूज़ के साथ कुछ stringArray वैल्यू एन्कोड नहीं होंगी, और कुछ वैल्यूज़ base64 और rc4 एन्कोडिंग से एन्कोड होंगी:

stringArrayEncoding: [
    'none',
    'base64',
    'rc4'
]

stringArrayIndexesType

Type: string[] Default: ['hexadecimal-number']

⚠️ stringArray विकल्प सक्षम होना चाहिए

string array कॉल इंडेक्स के प्रकार को नियंत्रित करने की अनुमति देता है।

हर stringArray कॉल इंडेक्स को पास की गई सूची से बेतरतीब चुने गए प्रकार द्वारा रूपांतरित किया जाएगा। इससे कई प्रकारों का उपयोग करना संभव हो जाता है।

उपलब्ध मान:

  • 'hexadecimal-number' (default): string array कॉल इंडेक्स को हेक्साडेसिमल संख्याओं के रूप में रूपांतरित करता है
  • 'hexadecimal-numeric-string': string array कॉल इंडेक्स को हेक्साडेसिमल न्यूमेरिक स्ट्रिंग के रूप में रूपांतरित करता है

2.9.0 रिलीज़ से पहले javascript-obfuscator सभी string array कॉल इंडेक्स को hexadecimal-numeric-string प्रकार से रूपांतरित करता था। इससे कुछ मैनुअल डीऑब्फ़स्केशन थोड़ा कठिन होता है, लेकिन यह स्वचालित डीऑब्फ़स्केटर द्वारा इन कॉल्स का आसान पता लगाने की अनुमति देता है।

नया hexadecimal-number प्रकार कोड में string array कॉल पैटर्न का स्वतः-पता लगाना कठिन बनाने का प्रयास करता है।

भविष्य में और प्रकार जोड़े जाएँगे।

stringArrayIndexShift

Type: boolean Default: true

⚠️ stringArray विकल्प सक्षम होना चाहिए

सभी string array कॉल्स के लिए अतिरिक्त इंडेक्स शिफ़्ट सक्षम करता है

stringArrayRotate

Type: boolean Default: true

⚠️ stringArray सक्षम होना चाहिए

stringArray ऐरे को एक निश्चित और बेतरतीब (कोड ऑब्फ़स्केशन के समय जनरेट किए गए) स्थानों से शिफ़्ट करता है। इससे हटाई गई स्ट्रिंग्स के क्रम को उनके मूल स्थान से मिलाना कठिन हो जाता है।

stringArrayShuffle

Type: boolean Default: true

⚠️ stringArray सक्षम होना चाहिए

stringArray ऐरे के आइटम्स को बेतरतीब ढंग से शफ़ल करता है।

stringArrayWrappersCount

Type: number Default: 1

⚠️ stringArray विकल्प सक्षम होना चाहिए

हर रूट या फ़ंक्शन स्कोप के भीतर string array के लिए रैपर्स की संख्या सेट करता है। हर स्कोप के भीतर रैपर्स की वास्तविक संख्या उस स्कोप के भीतर literal नोड्स की संख्या द्वारा सीमित होती है।

उदाहरण:

// Input
const foo = 'foo';
const bar = 'bar';
        
function test () {
    const baz = 'baz';
    const bark = 'bark';
    const hawk = 'hawk';
}

const eagle = 'eagle';

// Output, stringArrayWrappersCount: 5
const _0x3f6c = [
    'bark',
    'bar',
    'foo',
    'eagle',
    'hawk',
    'baz'
];
const _0x48f96e = _0x2e13;
const _0x4dfed8 = _0x2e13;
const _0x55e970 = _0x2e13;
function _0x2e13(_0x33c4f5, _0x3f6c62) {
    _0x2e13 = function (_0x2e1388, _0x60b1e) {
        _0x2e1388 = _0x2e1388 - 0xe2;
        let _0x53d475 = _0x3f6c[_0x2e1388];
        return _0x53d475;
    };
    return _0x2e13(_0x33c4f5, _0x3f6c62);
}
const foo = _0x48f96e(0xe4);
const bar = _0x4dfed8(0xe3);
function test() {
    const _0x1c262f = _0x2e13;
    const _0x54d7a4 = _0x2e13;
    const _0x5142fe = _0x2e13;
    const _0x1392b0 = _0x1c262f(0xe7);
    const _0x201a58 = _0x1c262f(0xe2);
    const _0xd3a7fb = _0x1c262f(0xe6);
}
const eagle = _0x48f96e(0xe5);

stringArrayWrappersChainedCalls

Type: boolean Default: true

⚠️ stringArray और stringArrayWrappersCount विकल्प सक्षम होने चाहिए

string array रैपर्स के बीच चेन की गई कॉल्स सक्षम करता है।

उदाहरण:

// Input
const foo = 'foo';
const bar = 'bar';
        
function test () {
    const baz = 'baz';
    const bark = 'bark';

    function test1() {
        const hawk = 'hawk';
        const eagle = 'eagle';
    } 
}

// Output, stringArrayWrappersCount: 5, stringArrayWrappersChainedCalls: true
const _0x40c2 = [
    'bar',
    'bark',
    'hawk',
    'eagle',
    'foo',
    'baz'
];
const _0x31c087 = _0x3280;
const _0x31759a = _0x3280;
function _0x3280(_0x1f52ee, _0x40c2a2) {
    _0x3280 = function (_0x3280a4, _0xf07b02) {
        _0x3280a4 = _0x3280a4 - 0x1c4;
        let _0x57a182 = _0x40c2[_0x3280a4];
        return _0x57a182;
    };
    return _0x3280(_0x1f52ee, _0x40c2a2);
}
const foo = _0x31c087(0x1c8);
const bar = _0x31c087(0x1c4);
function test() {
    const _0x848719 = _0x31759a;
    const _0x2693bf = _0x31c087;
    const _0x2c08e8 = _0x848719(0x1c9);
    const _0x359365 = _0x2693bf(0x1c5);
    function _0x175e90() {
        const _0x310023 = _0x848719;
        const _0x2302ef = _0x2693bf;
        const _0x237437 = _0x310023(0x1c6);
        const _0x56145c = _0x310023(0x1c7);
    }
}

stringArrayWrappersParametersMaxCount

Type: number Default: 2

⚠️ stringArray विकल्प सक्षम होना चाहिए
⚠️ फ़िलहाल यह विकल्प केवल stringArrayWrappersType function विकल्प वैल्यू द्वारा जोड़े गए रैपर्स पर असर डालता है

string array रैपर्स के पैरामीटर्स की अधिकतम संख्या को नियंत्रित करने की अनुमति देता है। डिफ़ॉल्ट और न्यूनतम मान 2 है। अनुशंसित मान 2 और 5 के बीच है।

stringArrayWrappersType

Type: string Default: variable

⚠️ stringArray और stringArrayWrappersCount विकल्प सक्षम होने चाहिए

stringArrayWrappersCount विकल्प द्वारा जोड़े जाने वाले रैपर्स का प्रकार चुनने की अनुमति देता है।

उपलब्ध मान:

  • 'variable': हर स्कोप के शीर्ष पर वेरिएबल रैपर्स जोड़ता है। तेज़ प्रदर्शन।
  • 'function': हर स्कोप के भीतर बेतरतीब स्थानों पर फ़ंक्शन रैपर्स जोड़ता है। variable की तुलना में धीमा प्रदर्शन, लेकिन अधिक सख़्त ऑब्फ़स्केशन प्रदान करता है।

जब प्रदर्शन में गिरावट का ऑब्फ़स्केटेड एप्लिकेशन पर अधिक असर न हो, तब उच्च ऑब्फ़स्केशन के लिए function रैपर्स उपयोग करने की ज़ोरदार सिफ़ारिश की जाती है।

'function' विकल्प वैल्यू का उदाहरण:

// input
const foo = 'foo';

function test () {
    const bar = 'bar';
    console.log(foo, bar);
}

test();

// output
const a = [
    'log',
    'bar',
    'foo'
];
const foo = d(0x567, 0x568);
function b(c, d) {
    b = function (e, f) {
        e = e - 0x185;
        let g = a[e];
        return g;
    };
    return b(c, d);
}
function test() {
    const c = e(0x51c, 0x51b);
    function e (c, g) {
        return b(c - 0x396, g);
    }
    console[f(0x51b, 0x51d)](foo, c);
    function f (c, g) {
        return b(c - 0x396, g);
    }
}
function d (c, g) {
    return b(g - 0x3e1, c);
}
test();

stringArrayThreshold

Type: number Default: 0.75 Min: 0 Max: 1

⚠️ stringArray विकल्प सक्षम होना चाहिए

आप इस सेटिंग का उपयोग यह प्रायिकता (0 से 1 तक) समायोजित करने के लिए कर सकते हैं कि कोई स्ट्रिंग लिटरल stringArray में डाला जाएगा।

यह सेटिंग बड़े कोड आकार के लिए खासकर उपयोगी है, क्योंकि यह बार-बार string array को कॉल करती है और आपके कोड को धीमा कर सकती है।

stringArrayThreshold: 0 का मतलब है stringArray: false।

strictMode

Type: boolean | null Default: null

ऑब्फ़स्केटर को JavaScript strict mode के संबंध में कोड को कैसे मानना चाहिए, यह निर्दिष्ट करने की अनुमति देता है।

उपलब्ध मान:

  • null (डिफ़ॉल्ट) - कोड से strict mode का स्वतः पता लगाता है। अगर कोड में स्पष्ट 'use strict' डायरेक्टिव, ES मॉड्यूल सिंटैक्स, या क्लास मेथड्स हों, तो उसे strict mode माना जाता है। अन्यथा, sloppy mode मान लिया जाता है।
  • true - सभी कोड के लिए strict mode व्यवहार ज़बरन लागू करता है, भले ही स्पष्ट 'use strict' डायरेक्टिव न हो। इसका उपयोग तब करें जब आपका कोड strict mode संदर्भ में चलेगा (उदा., ES मॉड्यूल्स, बंडलर्स, या आधुनिक फ़्रेमवर्क्स में)।
  • false - केवल स्पष्ट strict mode संकेतक ('use strict', ES मॉड्यूल्स, क्लास मेथड्स) को strict माना जाता है। JS स्पेक के अनुसार पैरेंट स्कोप इनहेरिटेंस अब भी लागू होता है।

target

Type: string Default: browser

ऑब्फ़स्केटेड कोड के लिए टारगेट वातावरण सेट करने की अनुमति देता है।

उपलब्ध मान:

  • browser (डिफ़ॉल्ट) - मानक वेब पेज वातावरण। आउटपुट कोड node के समान है, लेकिन कुछ ब्राउज़र-विशिष्ट विकल्पों का उपयोग node टारगेट के साथ करने की अनुमति नहीं है
  • browser-no-eval - browser जैसा ही, लेकिन आउटपुट eval() का उपयोग नहीं करता। इसका उपयोग तब करें जब टारगेट पेज की Content Security Policy eval/unsafe-eval को प्रतिबंधित करती हो।
  • node - Node.js वातावरण। ब्राउज़र-विशिष्ट विकल्प अक्षम रहते हैं (उन्हें window/document की आवश्यकता होती है और Node में वे निष्क्रिय होंगे या एरर देंगे)। कुछ vmSelfDefending रक्षा उपाय जो केवल-ब्राउज़र APIs पर निर्भर हैं - headless-browser डिटेक्शन, iframe-आधारित clean-realm रिकवरी, anti-inspector/DOM जाँचें - इस टारगेट के लिए नहीं जोड़े जाते।
  • service-worker - Service Worker संदर्भ। कोई window नहीं, कोई document नहीं, अलग self ग्लोबल।
  • userscript - userscript मैनेजर सैंडबॉक्स (उदा. Tampermonkey)। vmSelfDefending रक्षा उपाय तदनुसार समायोजित किए जाते हैं।
  • bytenode - Node.js कोड जिसे ऑब्फ़स्केशन के बाद bytenode लोडर (V8 कैश्ड बाइटकोड .jsc) से कंपाइल किया जाएगा। ऑब्फ़स्केटर स्वयं bytenode को इनवोक नहीं करता; यह VM-ऑब्फ़स्केटेड JavaScript उत्पन्न करता है जिसका रनटाइम इस तरह संरचित है कि वह bytenode के कंपाइलेशन चरण को झेल सके, और vmSelfDefending रक्षा उपाय तदनुसार समायोजित किए जाते हैं। अंतिम .jsc बनाने के लिए ऑब्फ़स्केटेड आउटपुट पर bytenode आप स्वयं चलाएँ।

transformObjectKeys

Type: boolean Default: false

ऑब्जेक्ट कीज़ का रूपांतरण सक्षम करता है।

उदाहरण:

// input
(function(){
    var object = {
        foo: 'test1',
        bar: {
            baz: 'test2'
        }
    };
})();

// output
var _0x4735 = [
    'foo',
    'baz',
    'bar',
    'test1',
    'test2'
];
function _0x390c(_0x33d6b6, _0x4735f4) {
    _0x390c = function (_0x390c37, _0x1eed85) {
        _0x390c37 = _0x390c37 - 0x198;
        var _0x2275f8 = _0x4735[_0x390c37];
        return _0x2275f8;
    };
    return _0x390c(_0x33d6b6, _0x4735f4);
}
(function () {
    var _0x17d1b7 = _0x390c;
    var _0xc9b6bb = {};
    _0xc9b6bb[_0x17d1b7(0x199)] = _0x17d1b7(0x19c);
    var _0x3d959a = {};
    _0x3d959a[_0x17d1b7(0x198)] = _0x17d1b7(0x19b);
    _0x3d959a[_0x17d1b7(0x19a)] = _0xc9b6bb;
    var _0x41fd86 = _0x3d959a;
}());

warnings

Type: string | object Default: all

नियंत्रित करता है कि कौन-सी गैर-घातक ऑब्फ़स्केशन चेतावनियाँ दी जाती हैं।

उपलब्ध मान:

  • 'all' (डिफ़ॉल्ट) - हर चेतावनी दी जाती है।
  • 'none' - सभी चेतावनियाँ दबा दी जाती हैं।
  • चेतावनी प्रकारों को boolean से मैप करने वाला एक ऑब्जेक्ट - false पर मैप किया गया कोई प्रकार दबा दिया जाता है; हर वह प्रकार जो मौजूद नहीं है (या true पर मैप है) सक्षम रहता है। उदाहरण के लिए, { "VMGlobalFunctionNamesNotRenamed": false } उस एक को छोड़कर हर चेतावनी बनाए रखता है।

चेतावनी प्रकार:

  • VMGlobalFunctionNamesNotRenamed - vmObfuscation के तहत, टॉप-लेवल फ़ंक्शन घोषणाओं, क्लास घोषणाओं, और फ़ंक्शन/arrow/क्लास एक्सप्रेशन असाइन किए गए वेरिएबल्स के नाम जस के तस रखे गए (renameGlobals विकल्प अक्षम है और कोड किसी IIFE में लपेटा नहीं गया), इसलिए बॉडी बाइटकोड के रूप में छिपी होने के बावजूद वे आउटपुट में पठनीय रहते हैं। एक्सपोर्ट किए गए नाम रिपोर्ट नहीं किए जाते।
  • VMTopLevelInitializerNotVirtualized - VM ऑब्फ़स्केशन के तहत टॉप-लेवल वेरिएबल इनिशियलाइज़र्स सादे JavaScript में रह गए क्योंकि vmWrapTopLevelInitializers अक्षम है या उन्हें वर्चुअलाइज़ नहीं कर सका।
  • DynamicCodeRenameRisk - कोड रनटाइम पर किसी स्ट्रिंग से फ़ंक्शन बनाता है (direct eval, Function कंस्ट्रक्टर, या <script>/Worker में इंजेक्ट किया गया fn.toString()), जो ऐसे आइडेंटिफ़ायर्स को संदर्भित कर सकता है जिनका ऑब्फ़स्केटर ने नाम बदल दिया है।
  • VMDynamicCodeSkipped - किसी फ़ंक्शन को VM बाइटकोडिंग से छोड़ दिया गया क्योंकि उसमें direct eval / dynamic new Function / Function है (देखें vmForceCompileDynamicCode)।
  • VMNoFunctionsToVirtualize - vmObfuscation सक्षम है, पर कोड में वर्चुअलाइज़ करने के लिए कोई फ़ंक्शन नहीं है (जैसे alert(1); जैसा केवल टॉप-लेवल कोड), इसलिए कोई VM सुरक्षा लागू नहीं हुई। VM ऑब्फ़स्केशन केवल फ़ंक्शन बॉडी की सुरक्षा करता है; जिस कोड को सुरक्षित करना हो उसे किसी फ़ंक्शन में लपेटें।
  • VMSyncFunctionSkippedInAsyncMode - vmAsyncExecutor सक्षम होने पर, comment मोड में आपके द्वारा स्पष्ट रूप से चिह्नित किया गया कोई फ़ंक्शन सिंक्रोनस निकला और छोड़ दिया गया (उस मोड में केवल async फ़ंक्शन्स वर्चुअलाइज़ होते हैं)।
  • VMAsyncGeneratorSkippedInAsyncMode - vmAsyncExecutor और एक async key getter सक्रिय होने पर, कोई चिह्नित async जनरेटर वर्चुअलाइज़ नहीं किया जा सका (उसे अपना iterator सिंक्रोनस रूप से लौटाना होता है)।
  • BrowserTargetWithNodeStyleCode - कोड ऐसा लगता है जैसे यह Node.js को टारगेट करता है (उदा. require('fs'), __dirname, process.argv) जबकि target विकल्प किसी ब्राउज़र-जैसे वातावरण पर सेट है।
  • ParseHtmlNoMarkedScripts - parseHtml सक्षम है, लेकिन इनपुट में data-javascript-obfuscator एट्रिब्यूट वाले कोई <script> टैग्स नहीं हैं, इसलिए कुछ भी ऑब्फ़स्केट नहीं हुआ और HTML बिना बदलाव के लौटा दिया गया।

vmObfuscation

Type: boolean Default: false

VM-आधारित बाइटकोड ऑब्फ़स्केशन सक्षम करता है। सक्षम होने पर, JavaScript फ़ंक्शन्स को कस्टम बाइटकोड में कंपाइल किया जाता है जो एक एम्बेडेड वर्चुअल मशीन पर चलता है। यह सुरक्षा का उच्चतम स्तर प्रदान करता है क्योंकि मूल कोड का तर्क पूरी तरह रूपांतरित हो जाता है।

उदाहरण: आपका पठनीय कोड जैसे return qty * price संख्याओं की एक सूची [0x15,0x03,0x17,...] बन जाता है जिसे केवल एम्बेडेड VM इंटरप्रेटर ही चला सकता है। मूल तर्क अब JavaScript के रूप में दृश्यमान नहीं रहता।

vmTargetFunctions

Type: string[] Default: []

ठीक-ठीक बताएँ कि किन रूट-लेवल फ़ंक्शन्स को नाम से VM सुरक्षा मिलनी चाहिए।

उदाहरण:

{
    vmObfuscation: true,
    vmTargetFunctions: ['someFunctionName']
}

परिणाम: केवल इन तीन फ़ंक्शन्स को VM-सुरक्षा मिलती है। बाकी सब कुछ सामान्य (लेकिन फिर भी ऑब्फ़स्केटेड) JavaScript रहता है। संवेदनशील लाइसेंस जाँचों या ऑथेंटिकेशन तर्क को सुरक्षित करने के लिए बिल्कुल उपयुक्त, जबकि आपके बाकी कोड को हल्का बनाए रखता है।

vmExcludeFunctions

Type: string[] Default: []

ऐसे रूट-लेवल फ़ंक्शन्स बताएँ जिन्हें कभी VM सुरक्षा नहीं मिलनी चाहिए। यह अन्य सेटिंग्स पर प्राथमिकता रखता है।

उदाहरण:

{
    vmObfuscation: true,
    vmExcludeFunctions: ['someFunctionName']
}

कब उपयोग करें: प्रदर्शन-संवेदनशील रूट-लेवल फ़ंक्शन्स (एनिमेशन लूप्स, रियल-टाइम डेटा प्रोसेसिंग) को VM ओवरहेड से बचने के लिए बाहर रखा जा सकता है, जबकि बाकी सब कुछ सुरक्षित रहता है।

vmTargetFunctionsMode

Type: string Default: root

नियंत्रित करता है कि VM ऑब्फ़स्केशन के लिए फ़ंक्शन्स/मेथड्स कैसे चुने जाते हैं।

मोडविवरण
rootडिफ़ॉल्ट व्यवहार। केवल रूट-लेवल फ़ंक्शन्स को VM ऑब्फ़स्केशन के लिए विचारित किया जाता है। फ़िल्टर करने के लिए vmTargetFunctions allow-list और vmExcludeFunctions deny-list का उपयोग करता है।
commentकेवल /* javascript-obfuscator:vm */ कमेंट से सजाए गए फ़ंक्शन्स/मेथड्स VM-ऑब्फ़स्केट होते हैं। किसी भी nesting स्तर पर फ़ंक्शन्स/मेथड्स के साथ काम करता है।

उदाहरण - Comment मोड:

// Source code
function regularFunction() {
    return 'not virtualized';
}

/* javascript-obfuscator:vm */
function sensitiveFunction() {
    return 'this will be VM-protected';
}

function outer() {
    /* javascript-obfuscator:vm */
    function nestedSensitive() {
        return 'nested but still VM-protected';
    }
    return nestedSensitive();
}

// Obfuscator options
{
    vmObfuscation: true,
    vmTargetFunctionsMode: 'comment'
}

कब उपयोग करें: जब आपको ठीक-ठीक इस बात पर सर्जिकल नियंत्रण चाहिए कि किन फ़ंक्शन्स को VM सुरक्षा मिले, खासकर संवेदनशील तर्क वाले nested फ़ंक्शन्स। vmTargetFunctions के विपरीत, जो केवल रूट-लेवल नामित फ़ंक्शन्स के साथ काम करता है, comment मोड आपको अपने कोड में कहीं भी किसी भी फ़ंक्शन को सुरक्षित करने देता है।

vmForceCompileDynamicCode

Type: boolean Default: false

नियंत्रित करता है कि VM ऑब्फ़स्केशन ऐसे फ़ंक्शन के साथ क्या करता है जिसमें direct eval, new Function(...), या Function(...) कॉल हो।

डिफ़ॉल्ट रूप से, ऐसे फ़ंक्शन (और उसके भीतर परिभाषित हर फ़ंक्शन) को VM बाइटकोडिंग से छोड़ दिया जाता है और एक VMDynamicCodeSkipped चेतावनी रिपोर्ट की जाती है। ऐसा इसलिए क्योंकि रनटाइम पर बना सोर्स आसपास की स्कोप चेन के आइडेंटिफ़ायर्स को संदर्भित कर सकता है - ऐसे आइडेंटिफ़ायर्स जिनका ऑब्फ़स्केटर ने नाम बदल दिया है।

जब true सेट किया जाता है, तो फ़ंक्शन को फिर भी बाइटकोड किया जाता है और VMDynamicCodeSkipped चेतावनी अब नहीं दी जाती।

अलग DynamicCodeRenameRisk चेतावनी इस विकल्प की परवाह किए बिना फ़ायर होती रहती है, क्योंकि यह जिस rename जोखिम का वर्णन करती है वह VM skip से स्वतंत्र है - इस विकल्प को चालू करने से अंतर्निहित पैटर्न कोई अधिक सुरक्षित नहीं हो जाता।

// Source code
function loadConfig(src) {
    return eval(src);
}
loadConfig('1 + 2');

// Options
{
    vmObfuscation: true,
    vmForceCompileDynamicCode: true
}

विकल्प बंद (डिफ़ॉल्ट) होने पर, loadConfig सादे JavaScript के रूप में छोड़ दिया जाता है। विकल्प चालू होने पर, loadConfig को किसी भी अन्य फ़ंक्शन की तरह VM बाइटकोड में कंपाइल किया जाता है। इसका उपयोग तब करें जब आपने कॉल साइट का ऑडिट कर लिया हो और जानते हों कि रनटाइम पर बना कोड closure में नाम बदले गए आइडेंटिफ़ायर्स पर निर्भर नहीं है।

vmWrapTopLevelInitializers

Type: boolean Default: false

कुछ टॉप-लेवल वेरिएबल इनिशियलाइज़र्स को IIFEs (तुरंत इनवोक किए गए फ़ंक्शन एक्सप्रेशन) में लपेटता है ताकि उन्हें VM-ऑब्फ़स्केट किया जा सके।

यह क्या करता है: इस विकल्प के बिना, टॉप-लेवल कॉन्स्टैंट्स और वेरिएबल्स आउटपुट में दृश्यमान रहते हैं:

// Input
const MY_STRING = "my-string";

// Output (without vmWrapTopLevelInitializers)
const MY_STRING = "my-string";  // String is visible!

इस विकल्प के सक्षम होने पर, इनिशियलाइज़र को एक IIFE में लपेटा जाता है जो VM-ऑब्फ़स्केट हो जाता है:

// Input
const MY_STRING = "my-string";

// Output (with vmWrapTopLevelInitializers: true)
const MY_STRING = (() => { return /* VM bytecode call */ })();  // String hidden in bytecode

नोट: यह विकल्प केवल तभी काम करता है जब vmTargetFunctionsMode 'root' (डिफ़ॉल्ट) हो।

चेतावनियाँ: जब भी VM ऑब्फ़स्केशन के तहत कोई टॉप-लेवल इनिशियलाइज़र सादे JavaScript में रह जाता है, तो प्रभावित वेरिएबल नामों को सूचीबद्ध करती हुई एक VMTopLevelInitializerNotVirtualized चेतावनी रिपोर्ट की जाती है। इसमें शामिल है: इस विकल्प का अक्षम होना, ऐसे इनिशियलाइज़र्स जिन्हें इस विकल्प को छोड़ना पड़ा (हर एक कारण सहित - उदा. इनिशियलाइज़र किसी सहोदर declarator को संदर्भित करता है या उसमें टॉप-लेवल await है), और vmAsyncExecutor मोड जहाँ सिंक्रोनस रैपर्स को बिल्कुल वर्चुअलाइज़ नहीं किया जा सकता।

vmDynamicOpcodes

Type: boolean Default: false

VM इंटरप्रेटर को हर बिल्ड के लिए छोटा और अद्वितीय बनाता है।

यह क्या करता है:

  1. अनुपयोगी निर्देशों को फ़िल्टर करता है - अगर आपका कोड क्लासेस का उपयोग नहीं करता, तो क्लास-संबंधी निर्देश पूरी तरह हटा दिए जाते हैं
  2. संरचना को रैंडमाइज़ करता है - निर्देश हैंडलर्स का क्रम हर बिल्ड में शफ़ल किया जाता है

परिणामस्वरूप - छोटा आउटपुट और हर बिल्ड अलग दिखती है।

vmBytecodeEncoding

Type: boolean Default: false

प्रत्येक बाइटकोड निर्देश को एन्कोड करता है (निष्पादन के दौरान इन्हें एक-एक करके डिकोड किया जाता है) और बाइटकोड पूल में संग्रहीत स्ट्रिंग स्थिरांकों को छिपा देता है, जिससे संकलित बाइटकोड में सादे पाठ वाली स्ट्रिंग्स नहीं रहतीं।

vmBytecodeArrayEncoding

Type: boolean Default: false

पूरे बाइटकोड ऐरे को एक ही ब्लॉक के रूप में एन्कोड करता है। ऐरे को निष्पादन शुरू होने से पहले स्टार्टअप पर एक बार डिकोड किया जाता है। दो-परत सुरक्षा के लिए इसे vmBytecodeEncoding के साथ उपयोग करें।

vmBytecodeArrayEncodingKey

Type: string Default: ''

बाइटकोड ऐरे एन्कोडिंग के लिए कस्टम एन्क्रिप्शन कुंजी। सेट होने पर, डिफ़ॉल्ट वातावरण-व्युत्पन्न कुंजी के बजाय इस कुंजी का उपयोग किया जाता है। कुंजी रनटाइम पर vmBytecodeArrayEncodingKeyGetter के ज़रिए दी जानी चाहिए।

यह विकल्प एन्क्रिप्शन कुंजी को बाहरी बना देता है - यह ऑब्फ़स्केटेड कोड में स्वयं एम्बेड नहीं होती। हालाँकि कुंजी अब भी रनटाइम पर सुलभ है (और इसलिए वास्तव में गुप्त नहीं है), यह अलगाव स्टैटिक विश्लेषण टूल्स को केवल कोड की जाँच करके कुंजी ढूँढने से रोकता है।

महत्वपूर्ण: जब ऑब्फ़स्केटेड कोड लोड होता है तब कुंजी सिंक्रोनस रूप से उपलब्ध होनी चाहिए। सिंक्रोनस स्टोरेज उपयोग करें जैसे cookies, localStorage, sessionStorage, ग्लोबल वेरिएबल्स, या DOM एलिमेंट्स (उदा., सर्वर-इंजेक्टेड meta टैग्स)। fetch() जैसे async तरीके key getter एक्सप्रेशन में सीधे उपयोग नहीं किए जा सकते।

vmBytecodeArrayEncodingKeyGetter

Type: string Default: ''

सिंक्रोनस JavaScript एक्सप्रेशन जो रनटाइम पर एन्क्रिप्शन कुंजी लौटाता है। यह एक्सप्रेशन तब मूल्यांकित होता है जब ऑब्फ़स्केटेड कोड लोड होता है, और उसे वही कुंजी लौटानी चाहिए जो vmBytecodeArrayEncodingKey में दी गई थी। कुंजी को एसिंक्रोनस रूप से (एक Promise) हल करने के लिए, vmAsyncExecutor सक्षम करें।

नोट: Promise लौटाने वाले getter को vmAsyncExecutor की आवश्यकता होती है। इसे बिल्ड समय पर जाँचा नहीं जा सकता, इसलिए vmAsyncExecutor बंद होने पर एक Promise getter रनटाइम पर विफल हो जाता है - डिकोडर को कुंजी के बजाय Promise मिलता है।

ऑब्फ़स्केटेड कोड तभी काम करेगा जब की-गेटर ठीक वही की लौटाए जो ऑब्फ़स्केशन के दौरान इस्तेमाल हुई थी। यदि कीज़ मेल नहीं खातीं - या गेटर undefined, null या खाली स्ट्रिंग लौटाता है - तो डिक्रिप्शन एक गलत कीस्ट्रीम बनाता है और कोड रनटाइम पर मुसीबत भरे आउटपुट या एक सामान्य रनटाइम एरर के साथ विफल हो जाता है। की-विशिष्ट कोई अलग एरर संदेश जानबूझकर नहीं है, इसलिए विफल की किसी भी अन्य रनटाइम खराबी से अलग नहीं पहचानी जा सकती।

महत्वपूर्ण: कुंजी को ऑब्फ़स्केटेड कोड वाली उसी फ़ाइल/स्क्रिप्ट से बाहर रखें - उसे वहाँ इनलाइन करने से बंडल का केवल स्टैटिक स्कैन भी उसे प्राप्त कर सकता है। इसके बजाय उसे किसी अलग सोर्स में संग्रहीत करें: सर्वर-सेट cookies, किसी अन्य स्क्रिप्ट द्वारा भरा गया localStorage, एक सर्वर-इंजेक्टेड HTML meta टैग, किसी अलग स्क्रिप्ट द्वारा सेट किया गया एक ग्लोबल, या (vmAsyncExecutor के साथ) रनटाइम पर आपके बैकएंड से लाया गया।

जब कुंजी आपके बैकएंड से लाई जाती है (vmAsyncExecutor के ज़रिए), तो उस एंडपॉइंट पर session- या origin-आधारित जाँचें जोड़ें: असली उपयोगकर्ताओं को सही कुंजी लौटाएँ (वैध session, अपेक्षित Origin/Referer) और संदिग्ध अनुरोधों को कचरा कुंजी (उदा. localhost/अनपेक्षित origin, कोई session नहीं)। असली उपयोगकर्ता सामान्य रूप से चलते हैं; आपके वातावरण के बाहर चलने वाली कोई प्रति एक ऐसी कुंजी पाती है जो कुछ भी डिक्रिप्ट नहीं करती। सटीक तर्क आपकी साइट पर निर्भर करता है।

उदाहरण:

// From cookie
vmBytecodeArrayEncodingKeyGetter: "document.cookie.match(/vmKey=([^;]+)/)?.[1]"

// From localStorage
vmBytecodeArrayEncodingKeyGetter: "localStorage.getItem('vmKey')"

// From global variable
vmBytecodeArrayEncodingKeyGetter: "window.__VM_KEY__"

// From meta tag (server-injected)
vmBytecodeArrayEncodingKeyGetter: "document.querySelector('meta[name=\"vm-key\"]').content"

// From nested object
vmBytecodeArrayEncodingKeyGetter: "window.config.encryption.key"

// From backend, async (requires vmAsyncExecutor)
vmBytecodeArrayEncodingKeyGetter: 'fetch("/vm-key").then((res) => res.text())'

उपयोग उदाहरण:

// Build time
JavaScriptObfuscator.obfuscate(code, {
    vmObfuscation: true,
    vmBytecodeArrayEncoding: true,
    vmBytecodeArrayEncodingKey: 'mySecretKey123',
    vmBytecodeArrayEncodingKeyGetter: 'window.__VM_KEY__'
});

// Runtime - key must be set before obfuscated code runs
window.__VM_KEY__ = 'mySecretKey123';

vmAsyncExecutor

Type: boolean Default: false

एसिंक्रोनस VM executor सक्षम करता है, जो vmBytecodeArrayEncodingKeyGetter को एक Promise लौटाने देता है (एक एसिंक्रोनस key getter) - ताकि डिक्रिप्शन कुंजी को रनटाइम पर लाया जा सके (नेटवर्क अनुरोध, IndexedDB, आदि) बजाय इसके कि कोड लोड होते समय उसे सिंक्रोनस रूप से उपलब्ध होना पड़े।

पूरी तरह async कोडबेस के लिए ज़ोरदार अनुशंसित। इस मोड में केवल async फ़ंक्शन्स वर्चुअलाइज़ होते हैं - किसी सिंक्रोनस फ़ंक्शन को उसकी रिटर्न वैल्यू को Promise में बदले और उसके कॉलर्स को तोड़े बिना async नहीं बनाया जा सकता - इसलिए वह कोड जो पूरी तरह async है सबसे अधिक कवरेज पाता है। यह तब भी काम करता है जब रूट सिंक्रोनस हो (उदा. एक sync IIFE / UMD रैपर): उसके भीतर के सबसे बाहरी async फ़ंक्शन्स सुरक्षित होते हैं, और sync हिस्से जस के तस छोड़ दिए जाते हैं।

क्या रूपांतरित होता है: हर सबसे बाहरी async फ़ंक्शन, चाहे वह कहीं भी हो (sync रैपर्स के भीतर nested सहित)। हर चेन में सबसे बाहरी async ही सुरक्षित इकाई है - उसके भीतर सब कुछ, sync और async, कंपाइल हो जाता है। सिंक्रोनस फ़ंक्शन्स और सादे जनरेटर अनऑब्फ़स्केटेड छोड़ दिए जाते हैं।

function foo() {              // sync — left as-is
    function bar() {}         // sync — left as-is

    async function baz() {    // transformed
        // any code here, including calls to other async or sync functions
    }

    async function bark() {   // transformed
        // any code here, including calls to other async or sync functions
    }
}

स्किप और चेतावनियाँ। जब कोई एसिंक्रोनस key getter सक्रिय होता है, तो async जनरेटर भी अनऑब्फ़स्केटेड छोड़ दिए जाते हैं (एक async जनरेटर को अपना iterator सिंक्रोनस रूप से लौटाना होता है और वह कुंजी की प्रतीक्षा नहीं कर सकता)। डिफ़ॉल्ट vmTargetFunctionsMode: 'root' में स्किप मौन होते हैं (चयन स्वचालित है); comment मोड में जब भी आपके द्वारा स्पष्ट रूप से चिह्नित कोई फ़ंक्शन वर्चुअलाइज़ नहीं किया जा सकता, तो एक चेतावनी दी जाती है - वह सिंक्रोनस निकला, या वह किसी async key getter के तहत एक async जनरेटर है।

एसिंक्रोनस key getter को अतिरिक्त रूप से एक vmBytecodeArrayEncodingKeyGetter के साथ vmBytecodeArrayEncoding की आवश्यकता होती है।

उपयोग उदाहरण:

JavaScriptObfuscator.obfuscate(code, {
    vmObfuscation: true,
    vmAsyncExecutor: true,
    vmBytecodeArrayEncoding: true,
    vmBytecodeArrayEncodingKey: 'mySecretKey123',
    // the key getter may now return a Promise
    vmBytecodeArrayEncodingKeyGetter: 'fetch("/vm-key").then((res) => res.text())'
});

vmJumpsEncoding

Type: boolean Default: false

बाइटकोड में jump टारगेट्स को एन्कोड करता है। Jump ऑफ़सेट्स रनटाइम पर गणना किए जाते हैं, जो स्टैटिक विश्लेषण से control flow संरचना (if/else, loops, आदि) को छिपा देते हैं।

vmMacroOps

Type: boolean Default: false

सामान्य निर्देश-अनुक्रमों को एकल "मैक्रो" ऑपकोड में जोड़ता है। उदाहरण के लिए, LOAD_ARG + PUSH_CONST + SUB बनकर MACRO_SUB_ARG_CONST हो सकता है, जिससे इंटरप्रेटर डिस्पैच कम होते हैं। यह डिफ़ॉल्ट स्टैक VM और vmRegisterBased: true दोनों के साथ काम करता है; किसी भी मोड में vmMacroOps: true को स्पष्ट रूप से सक्षम करें।

vmDebugProtection

Type: boolean | object Default: false

VM रनटाइम में बहुस्तरीय एंटी-डिबगिंग, एंटी-विश्लेषण और एंटी-LLM रक्षा उपाय जोड़ता है। browser/browser-no-eval टारगेट्स के साथ सबसे अच्छा काम करता है।

इसे सक्षम करने के लिए true पास करें, या अक्षम करने के लिए false। किसी विशिष्ट सुरक्षा को बंद करते हुए इसे सक्षम करने के लिए एक ऑब्जेक्ट पास करें:

{
    vmDebugProtection: {
        // most defenses are always on; but CDP/devtools detection is disabled
        inspectorDetection: false
    }
}

⚠️ यह ऑब्जेक्ट चालू करने के लिए रक्षा उपायों का मेनू नहीं है। जब डिबग सुरक्षा सक्षम होती है, तो इसके अधिकांश रक्षा उपाय हमेशा सक्रिय रहते हैं और बंद नहीं किए जा सकते। नीचे दिए गए उप-विकल्प केवल उन कुछ रक्षा उपायों को उजागर करते हैं जिन्हें कुछ उपयोगकर्ता जानबूझकर ढीला करना चाह सकते हैं (उदाहरण के लिए, क्योंकि कोई गलत-सकारात्मक किसी वैध वर्कफ़्लो को तोड़ देगा) - बाकी हर सुरक्षा परवाह किए बिना चालू रहती है।

उप-विकल्पप्रकारडिफ़ॉल्टविवरण
inspectorDetectionbooleantrueएक संलग्न CDP (Chrome DevTools Protocol) इंस्पेक्टर का पता लगाता है और प्रतिक्रिया देता है - CDP Runtime डोमेन के सक्षम होने (Runtime.enable) और एक सक्रिय डिबगर (CDP Debugger डोमेन, जैसे ब्रेकपॉइंट या डेवलपर-टूल का Sources पैनल) दोनों का। ब्राउज़र के डेवलपर टूल खोलने से ये डोमेन सक्षम हो जाते हैं, इसलिए खुला इंस्पेक्टर पहचाना जाता है और उस पर प्रतिक्रिया होती है। इसे सक्षम रखने की अनुशंसा की जाती है; इसे false तभी सेट करें जब आपके उपयोगकर्ता वैध रूप से डेवलपर टूल खोलते हों।

💡 ऑब्जेक्ट रूप API के माध्यम से उपलब्ध है

⚠️ ऑटोमेशन फ़्रेमवर्क। inspectorDetection चालू होने पर (डिफ़ॉल्ट), संरक्षित पृष्ठ को किसी CDP-आधारित टूल (Puppeteer, Playwright, Selenium/ChromeDriver) से चलाना एक संलग्न इंस्पेक्टर के रूप में पहचाना जाता है। यदि आप संरक्षित कोड पर स्वचालित परीक्षण चलाते हैं, तो उन बिल्ड को vmDebugProtection: { inspectorDetection: false } के साथ बनाएँ।

vmSelfDefending

Type: boolean Default: false

VM रनटाइम में बहुस्तरीय टैम्पर डिटेक्शन, anti-hooking, और anti-reverse-engineering सुरक्षा जोड़ता है।

⚠️ यह विकल्प vmBytecodeArrayEncoding को ज़बरन सक्षम करता है।

⚠️ संवेदनशील वातावरण डिटेक्शन। यह विकल्प ऑब्फ़स्केटेड कोड को उसके टारगेट रनटाइम वातावरण से बाँध देता है और ऑटोमेशन टूल्स का पता लगाने के लिए उन्नत browser fingerprinting का उपयोग करता है। इस विकल्प से सुरक्षित कोड इनमें चलने पर जानबूझकर टूट जाएगा:

  • Headless ब्राउज़र्स (headless Chrome/Chromium, PhantomJS)
  • Browser automation टूल्स (Puppeteer, Playwright, Cypress, Selenium/ChromeDriver, Nightmare)
  • Node.js (जब target browser पर सेट हो)
  • jsdom या समान सर्वर-साइड DOM एमुलेशन
  • ऐसे वातावरण जहाँ नेटिव browser builtins को हुक या बदल दिया गया हो

कोड नियमित ब्राउज़र्स (Chrome, Firefox, Safari, Edge) में सही ढंग से काम करेगा, जिसमें iframes के भीतर, browser extensions (content scripts), और Web Workers में लोड होने पर भी शामिल है। अगर आपको सुरक्षित कोड के विरुद्ध स्वचालित परीक्षण चलाने हैं, तो टेस्ट बिल्ड्स के लिए vmSelfDefending अक्षम करें - यह विकल्प स्वचालित विश्लेषण को रोकने के लिए बनाया गया है और किसी भी automation फ़्रेमवर्क के साथ सुरक्षित रूप से उपयोग नहीं किया जा सकता।

vmDebugProtection, vmBytecodeArrayEncodingKey, और vmBytecodeArrayEncodingKeyGetter के साथ मिलकर उपयोग करने की ज़ोरदार सिफ़ारिश की जाती है।

vmDefenseHook

Type: { name: string, aliases?: object } | null Default: null

vmDefenseHook या तो null (अक्षम) है या दो कुंजियों वाला एक ऑब्जेक्ट: name (आवश्यक) और aliases (वैकल्पिक)।

name एक ग्लोबल फ़ंक्शन है जिसे आपका होस्ट पेज परिभाषित करता है और जिसे कोई VM defense (vmDebugProtection / vmSelfDefending) किसी signal ऑब्जेक्ट के साथ कॉल करता है जब वह किसी हॉस्टाइल signal का पता लगाती है - एक debugger या inspector, एक headless / automation ब्राउज़र, एक AI-coding-agent प्रोसेस, एक अननुमत डोमेन, इत्यादि। इसका उपयोग इवेंट को अपने बैकएंड को रिपोर्ट करने के लिए करें (उदा. navigator.sendBeacon)। यह hook एक शुद्ध telemetry sink है: इसकी रिटर्न वैल्यू अनदेखी की जाती है, और एक अनुपस्थित या एरर फेंकने वाला hook एक मौन no-op है जो किसी defense को कभी अक्षम नहीं कर सकता। डिटेक्शन पर कोई defense क्या करती है यह बदलने के लिए, vmDefenseReaction का उपयोग करें।

aliases वैकल्पिक रूप से उस signal ऑब्जेक्ट के फ़ील्ड्स का नाम बदल देता है - नीचे signal फ़ील्ड्स का नाम बदलना में इसका वर्णन है।

signal ऑब्जेक्ट। hook को एक ही signal मिलता है:

  • source - वह विशिष्ट detector जो फ़ायर हुआ (तालिका देखें)।
  • category - वह समूह जिसके अंतर्गत यह रिपोर्ट करता है: automation (गैर-मानव ब्राउज़र), debugger (एक debugger/inspector सक्रिय है), sandbox (instrumented/नकली होस्ट), domain (domain-lock उल्लंघन), tamper (रनटाइम पर built-ins पैच किए गए), या integrity (VM का अपना कोड बदला गया)।
  • score / threshold - detector कितनी दृढ़ता से फ़ायर हुआ और जिस मान तक उसे पहुँचना था; hook केवल तभी फ़ायर होता है जब score >= threshold। अधिकांश जाँचें सब-या-कुछ नहीं (एक ही निर्णायक signal) होती हैं; headless कई browser-shape signals को जोड़ता है, इसलिए इसका score आम तौर पर इसके threshold से अधिक होता है।
sourceपता लगाता हैcategory
integrityऑब्फ़स्केटेड VM कोड स्वयं संशोधित किया गया हैintegrity
nodeब्राउज़र-लक्षित कोड जो Node.js के तहत चल रहा हैdebugger
debuggerएक संलग्न या सक्रिय debugger या inspector सेशन, या एक debug वातावरणdebugger
headlessकोड चलाने के लिए एक headless ब्राउज़र उपयोग हो रहा हैautomation
agentकोड चलाने वाला एक AI coding-agentautomation
agentBrowserएक असली ब्राउज़र चलाने वाला AI agent कोड चला रहा हैautomation
timingएक निष्पादन ठहराव जो किसी breakpoint या stepping debugger का संकेत देता हैdebugger
sandboxकोड किसी sandbox या नकली host वातावरण में चलता हैsandbox
domainपेज origin vmDomainLock allow-list में नहीं हैdomain
nativeHookकोई नेटिव built-in फ़ंक्शन बदला या हुक किया गया हैtamper

hook को रजिस्टर करना। इसे ऑब्फ़स्केटेड बंडल लोड होने से पहले एक सादे ग्लोबल के रूप में परिभाषित करें - VM रनटाइम और उसकी defenses आपके (सुरक्षित) प्रोग्राम से पहले चलती हैं, इसलिए कई डिटेक्शन स्टार्टअप के दौरान फ़ायर होते हैं:

// in your page, before the obfuscated script:
window.__vmDetection = function (signal) { navigator.sendBeacon('/vm-defense', JSON.stringify(signal)); };

// obfuscation option:
vmDefenseHook: { name: '__vmDetection' }

ऑब्फ़स्केटेड सोर्स के भीतर परिभाषित एक hook स्टार्टअप-समय के डिटेक्शन पकड़ने के लिए बहुत देर से रजिस्टर होता है, और अगर वह VM-कंपाइल हो जाए तो आपके प्रोग्राम के चलने तक उस तक पहुँचा नहीं जा सकता। यह किसी भी तरह सुरक्षित रखा जाता है (एक अनुपस्थित hook no-op करता है, और एक re-entrancy guard किसी भी अनियंत्रित प्रवाह को रोकता है), लेकिन पूर्ण कवरेज के लिए इसे पहले से रजिस्टर करें। अपने रिपोर्टिंग तर्क को फिर भी सुरक्षित रखने के लिए, रजिस्टर किए गए hook को एक एक-लाइन buffer ((window.__vmDet = window.__vmDet || []).push(signal)) रखें और उस buffer को अपने ऑब्फ़स्केटेड कोड से पढ़ें/भेजें।

signal फ़ील्ड्स का नाम बदलना (aliases)। डिफ़ॉल्ट source/category वैल्यूज़ वर्णनात्मक नाम हैं, इसलिए callback को instrument करने वाला (या आउटपुट पढ़ने वाला) कोई भी सुरक्षा और यह पहचान सकता है कि कौन-सा detector फ़ायर हुआ। aliases signal फ़ील्ड्स का नाम बदलकर आपकी पसंद के opaque tokens कर देता है, जो signal उत्सर्जित होने से पहले VM के भीतर लागू होते हैं, इसलिए वे नाम कभी आउटपुट में नहीं आते या callback तक नहीं पहुँचते। आपका ऐप अपनी मैपिंग जानता है और tokens को अपने बैकएंड को अग्रेषित करता है।

Aliases प्रति फ़ील्ड होते हैं, key और value के नाम बदलने को अलग रखते हुए: हर फ़ील्ड एक key लेता है (वह प्रॉपर्टी नाम जो callback को मिलता है); स्ट्रिंग name-फ़ील्ड्स source और category एक values map भी लेते हैं, जबकि score/threshold संख्याएँ हैं और केवल एक key लेते हैं। जिन नामों को आप map कर सकते हैं (और कुछ भी बिल्ड समय पर अस्वीकृत होता है):

  • field keys - source, category, score, threshold
  • source values - headless, agent, agentBrowser, node, debugger, timing, sandbox, domain, nativeHook, integrity
  • category values - automation, debugger, sandbox, domain, tamper, integrity
vmDefenseHook: {
    name: '__vmDetection',
    aliases: {
        source:    { key: 'a8Qm', values: { headless: 'xP4m9Q' } },
        category:  { key: 'p3Tx', values: { automation: 'bQ7s1M' } },
        score:     { key: 's1' },
        threshold: { key: 't1' }
    }
    // the callback now receives e.g. { a8Qm: 'xP4m9Q', p3Tx: 'bQ7s1M', s1: <score>, t1: <threshold> }
}

यह fingerprint से बचाव है, गोपनीयता नहीं - मैपिंग का अनुमान अब भी बार-बार परीक्षण से लगाया जा सकता है - इसलिए इसका एकमात्र लाभ स्थिर, स्वतः-स्पष्ट नामों को उजागर न करना है। सेट न की गई प्रविष्टियाँ अपने डिफ़ॉल्ट नाम बनाए रखती हैं।

vmDefenseReaction

Type: object Default: { automation: 'break', debugger: 'decoy', sandbox: 'decoy', domain: 'break', tamper: 'break', integrity: 'break' }

कॉन्फ़िगर करता है कि हर डिटेक्शन category कैसे प्रतिक्रिया करती है। यह किसी चीज़ को सक्षम नहीं करता - defenses स्वयं vmSelfDefending, vmDebugProtection, और vmDomainLock द्वारा चालू की जाती हैं; यह विकल्प केवल यह चुनता है कि एक सक्षम defense कैसे प्रतिक्रिया करती है। नियंत्रण की इकाई category है - किसी category का हर detector उसी category की प्रतिक्रिया लागू करता है।

हर category उन detectors को समूहित करती है जो एक प्रकार की हॉस्टाइल स्थिति पर नज़र रखते हैं। एक category केवल तभी प्रतिक्रिया करती है जब उसके detectors उत्सर्जित करने वाला विकल्प सक्षम हो:

Categoryकिससे सक्षम होती हैकब प्रतिक्रिया करती है
automationvmSelfDefending या vmDebugProtectionकोड को किसी व्यक्ति के बजाय सॉफ़्टवेयर द्वारा चलाया जा रहा है: एक headless या automated ब्राउज़र, एक scraping / testing फ़्रेमवर्क, या पेज को step करता एक AI coding-agent।
debuggervmDebugProtection या vmSelfDefendingकिसी ने debugger या ब्राउज़र का developer-tools inspector खोल रखा है और चल रहे कोड को समझने के लिए उसमें step कर रहा है।
sandboxvmDebugProtectionकोड किसी असली ब्राउज़र में चल ही नहीं रहा - इसे offline निष्पादित और अध्ययन करने के लिए एक emulated या scripted JavaScript वातावरण में उठा लिया गया है।
domainvmDomainLockकोड किसी ऐसी साइट पर चल रहा है जिसे आपने अधिकृत नहीं किया: एक ऐसा host जो आपकी vmDomainLock allow-list में नहीं है (उदाहरण के लिए, आपका बंडल किसी और के डोमेन पर कॉपी किया गया)।
tampervmSelfDefendingVM के आसपास का JavaScript वातावरण उस पर नज़र रखने या उसे hijack करने के लिए संशोधित किया गया है, जैसे नेटिव browser built-ins को instrumented संस्करणों से बदल देना।
integrityvmSelfDefendingसुरक्षित बंडल का अपना कोड, आपके जनरेट करने के बाद से, संपादित या पैच किया गया है।

हर category vmSelfDefending, vmDebugProtection, और vmDomainLock में से एक या अधिक से मैप होती है; इन तीन विकल्पों के बाहर कोई category नहीं है, और जिस category का विकल्प बंद है उसके लिए सेट की गई प्रतिक्रिया का बस कोई असर नहीं होता।

कीज़ ये छह category नाम हैं, या default (अनिर्दिष्ट categories के लिए एक fallback)। वैल्यूज़ हैं:

  • break - तुरंत break करें
  • decoy - poisoned state पर चलते रहें, चुपचाप गलत परिणाम उत्पन्न करते हुए
  • none - स्थानीय रूप से कुछ न करें (केवल telemetry)

प्रति-category डिफ़ॉल्ट ऊपर दिखाए गए हैं; जो category आप सेट नहीं करते (या उसके डिफ़ॉल्ट मान पर सेट करते हैं) वह उस डिफ़ॉल्ट का उपयोग करती है। default हर category तक पहुँचता है, जिसमें निर्माण-रूप-से-सही (integrity, tamper) भी शामिल हैं, इसलिए { default: 'none' } वास्तव में एक non-breaking, केवल-telemetry वाली बिल्ड है:

vmDefenseReaction: { default: 'none' }              // never break — pair with vmDefenseHook
vmDefenseReaction: { automation: 'none', domain: 'break' }   // tolerate automation FPs, still break on a bad domain

browserEnvironment

Type: object Default: {}

उस वातावरण के बारे में तथ्य घोषित करता है जिसमें आपका प्रोडक्शन बिल्ड चलता है, ताकि सुरक्षित कोड स्वयं को उनसे बाँध सके, उन पर प्रतिक्रिया दे सके या उन्हें सहन कर सके। केवल browser / browser-no-eval / service-worker टारगेट्स के लिए उपलब्ध - node, userscript और bytenode के लिए इसे अस्वीकार कर दिया जाता है। हर फ़ील्ड किसी एक निश्चित सुरक्षा के साथ प्रभावी होता है, जैसा नीचे बताया गया है।

फ़ील्ड:

  • transport - वह स्कीम जिससे आपका प्रोडक्शन बंडल सर्व करता है: 'http' या 'https'। 'https' के साथ बिल्ड अपनी अखंडता को HTTPS पर सर्व किए जाने से बाँध देता है, इसलिए कोई विश्लेषक जिस प्रति को उठाकर सादे HTTP पर सर्व करता है (स्थानीय रिवर्स इंजीनियरिंग का एक आम सेटअप), वह सही ढंग से नहीं चलेगी। 'http' या फ़ील्ड न सेट करने पर कोई बंधन नहीं जुड़ता। vmSelfDefending के साथ प्रभावी होता है।
browserEnvironment: { transport: 'https' }
  • hosting - आपका प्रोडक्शन बंडल कहाँ से सर्व होता है: 'remote' या 'local'। 'remote' के साथ बिल्ड अपनी अखंडता को रिमोट होस्ट से सर्व किए जाने से बाँध देता है, इसलिए कोई विश्लेषक जिस प्रति को उठाकर अपने स्थानीय सेटअप में चलाता है, उसे रनटाइम वातावरण का बेमेल माना जाता है और ऑटोमेशन रक्षा उपाय प्रतिक्रिया देते हैं (देखें vmDebugProtection और vmDefenseReaction)। 'local' या फ़ील्ड न सेट करने पर कोई बंधन नहीं जुड़ता। vmDebugProtection के साथ, केवल browser / browser-no-eval पर प्रभावी होता है।
browserEnvironment: { transport: 'https', hosting: 'remote' }
  • hookedBuiltins - यह घोषित करने के लिए true सेट करें कि जिस रनटाइम में आपका प्रोडक्शन बिल्ड चलता है, वह वैध रूप से नेटिव बिल्ट-इन्स को JavaScript रैपर से बदलता है: ऐप का अपना एंटी-टैम्पर, होस्ट पेज, या उसी realm को साझा करने वाले अन्य ब्राउज़र एक्सटेंशन। सामान्यतः vmSelfDefending बदले गए नेटिव बिल्ट-इन को छेड़छाड़ मानता है और बिल्ड को चलने से रोक देता है; इसे सेट करने पर यह ऐसे वातावरण को सहन करता है और कोड चलता है। false या अनसेट फ़ील्ड सख़्त व्यवहार बनाए रखता है। vmSelfDefending के साथ प्रभावी होता है।
browserEnvironment: { hookedBuiltins: true }

यह विकल्प केवल नेटिविटी जाँचों को ढीला करता है; क्लीन-रेल्म सत्यापन और आवश्यक बिल्टिन व्यवहार लागू बने रहते हैं।

⚠️ hookedBuiltins जानबूझकर छेड़छाड़ की पहचान को ढीला करता है: एक बार सेट होने पर, आपके कोड की जाँच के लिए उन्हीं बिल्ट-इन्स को रैप करने वाला विश्लेषक भी अब रोका नहीं जाता। VM वर्चुअलाइज़ेशन, एंटी-डिबगिंग और अखंडता सुरक्षा अप्रभावित रहती हैं। इसे केवल तभी सक्षम करें जब यह ज्ञात हो कि आपका प्रोडक्शन रनटाइम बिल्ट-इन्स को हुक करता है और वह कमज़ोर गारंटी स्वीकार्य हो।

⚠️ transport और hosting फ़ील्ड सुरक्षित बिल्ड को आपके द्वारा घोषित वातावरण से बाँध देते हैं। वही बिल्ड किसी भी ऐसे वातावरण में लोड होने पर - भले ही अस्थायी रूप से, अपने अंतिम वातावरण तक पहुँचने से पहले - जो मेल नहीं खाता, जानबूझकर सही ढंग से नहीं चलेगा। किसी फ़ील्ड को तभी घोषित करें जब आपका प्रोडक्शन बिल्ड लोड करने वाला हर संदर्भ उससे मेल खाता हो, और इन घोषणाओं को स्थानीय डेवलपमेंट, टेस्टिंग और CI वाले बिल्ड्स से दूर रखें।

vmStatefulOpcodes

Type: boolean Default: false

opcode के अर्थ को बाइटकोड में स्थिति पर निर्भर बना देता है। हर स्थिति के पास एक seed से व्युत्पन्न अलग opcode-से-handler मैपिंग होती है, इसलिए एक ही opcode संख्या अलग-अलग स्थितियों पर अलग-अलग ऑपरेशन करती है।

vmCallContextOpcodes

Type: boolean Default: false

किसी सुरक्षित फ़ंक्शन को इस पर निर्भर बना देता है कि उसे कहाँ से कॉल किया जाता है, ताकि उसे कोड से बाहर निकालकर अकेले चलाया या विश्लेषित न किया जा सके - वह केवल तभी सही व्यवहार करता है जब उसे प्रोग्राम में उसके असली कॉल साइट्स के ज़रिए इनवोक किया जाए। यह विकल्प रनटाइम प्रदर्शन पर असर डालता है।

फ़िलहाल केवल निम्नलिखित निर्माण समर्थित हैं:

  • फ़ंक्शन घोषणाएँ (function f() {});
  • किसी वेरिएबल को असाइन किए गए फ़ंक्शन एक्सप्रेशन और arrow फ़ंक्शन्स (const f = () => {});
  • इंस्टेंस प्राइवेट मेथड्स (this.#m())।

हर मामले में फ़ंक्शन तक हमेशा एक सीधी कॉल (f(), this.#m()) के ज़रिए पहुँचना होगा। अगर उसे किसी अन्य वेरिएबल में संग्रहीत किया जाए, आर्गुमेंट के रूप में पास किया जाए, या अन्यथा एक वैल्यू के रूप में उपयोग किया जाए, तो वह असुरक्षित छोड़ दिया जाता है। Async फ़ंक्शन्स समर्थित हैं; जनरेटर नहीं।

यह विकल्प प्रायोगिक है और आपके कोड को तोड़ सकता है, इसलिए उपयोग से पहले आउटपुट का पूरी तरह परीक्षण करें।

vmStackEncoding

Type: boolean Default: false

निष्पादन के दौरान VM stack पर वैल्यूज़ को एन्क्रिप्ट करता है। वैल्यूज़ push किए जाने पर एन्कोड और pop किए जाने पर डिकोड होती हैं, इसलिए मेमोरी निरीक्षण वास्तविक वैल्यूज़ के बजाय एन्क्रिप्टेड डेटा दिखाता है।

यह विकल्प प्रदर्शन पर भारी असर डालता है।

vmCompactDispatcher

Type: boolean Default: false

दोहरे executors (sync + generator) के बजाय एक ही VM executor का उपयोग करता है। ऑब्फ़स्केटेड कोड का आकार घटाता है लेकिन recursion-भारी कोड पर ~20% प्रदर्शन ओवरहेड जोड़ता है।

  • false (डिफ़ॉल्ट): दोहरे executors - इष्टतम प्रदर्शन, बड़ा आउटपुट
  • true: एकल executor - छोटा आउटपुट, थोड़ा धीमा

vmRegisterBased

Type: boolean Default: false

VM को डिफ़ॉल्ट स्टैक-आधारित बाइटकोड से रजिस्टर-आधारित निष्पादन मॉडल पर स्विच करता है, जिससे कुछ मामलों में VM का रनटाइम प्रदर्शन ~15-20% बेहतर होता है, लेकिन ऑब्फ़स्केटेड कोड का आकार थोड़ा बढ़ जाता है।

चूँकि यह संरचनात्मक रूप से अलग बाइटकोड और executor उत्पन्न करता है, इसलिए यह VM को डिफ़ॉल्ट स्टैक-आधारित रूप की तुलना में अधिक विशिष्ट फ़िंगरप्रिंट भी देता है - इसका उपयोग तब करें जब आप VM का स्वरूप बदलना चाहते हों ताकि वह सामान्य विश्लेषण के लिए कम पहचानने योग्य हो।

अंदरूनी तौर पर यह कोई नेटिव रजिस्टर-आधारित कंपाइलर नहीं है - बाइटकोड अब भी सामान्य स्टैक-आधारित कंपाइलर ही बनाता है, जिसे बाद में एक अलग ट्रांसफ़ॉर्मेशन चरण रजिस्टर-आधारित रूप में फिर से लिखता है।

यह विकल्प प्रायोगिक है - जाँचें कि vmRegisterBased सक्षम होने पर आपका कोड ठीक चलता है।

vmStringArrayBytecodeOnly

Type: boolean Default: false

सक्षम होने पर, string array केवल बाइटकोड डेटा से स्ट्रिंग्स निकालेगा - कोड की अन्य कोई स्ट्रिंग रूपांतरित नहीं होती। यह stringArray को ज़बरन सक्षम कर देता है भले ही वह स्पष्ट रूप से सेट न हो।

इसका उपयोग क्यों करें: सभी VM रनटाइम स्ट्रिंग्स को string array में निकालना धीमा है। यह विकल्प string array निष्कर्षण के लिए केवल बाइटकोड सामग्री को लक्षित करता है, जिससे प्रदर्शन बेहतर होता है और साथ ही बाइटकोड कॉन्स्टैंट्स सुरक्षित रहते हैं।

  • जब vmBytecodeArrayEncoding: false - बाइटकोड कॉन्स्टैंट पूल्स (c ऐरे) के भीतर की स्ट्रिंग्स निकाली जाती हैं
  • जब vmBytecodeArrayEncoding: true - टॉप-लेवल base64 एन्कोडेड बाइटकोड स्ट्रिंग्स निकाली जाती हैं
  • stringArrayThreshold अब भी नियंत्रित करता है कि उन बाइटकोड स्ट्रिंग्स का कितना प्रतिशत निकाला जाए

vmDomainLock

Type: string[] Default: []

⚠️ यह विकल्प target: 'node', target: 'service-worker' या target: 'bytenode' के साथ काम नहीं करता

ऑब्फ़स्केटेड कोड को विशिष्ट डोमेन और/या सब-डोमेन तक सीमित करता है, और इसे domainLock की तुलना में ढूँढना और हटाना कहीं अधिक कठिन है।

अगर सोर्स कोड इस विकल्प द्वारा निर्दिष्ट डोमेन पर नहीं चलता, तो ब्राउज़र को vmDomainLockRedirectUrl में पास किए गए URL पर रीडायरेक्ट कर दिया जाएगा, और redirect को दबा देने पर भी आगे की सुरक्षित कॉल्स गलत परिणाम लौटाएँगी।

एक से अधिक डोमेन और सब-डोमेन

अपने कोड को एक से अधिक डोमेन या सब-डोमेन तक लॉक करना संभव है। उदाहरण के लिए, इसे इस तरह लॉक करने के लिए कि कोड केवल www.example.com पर चले, www.example.com जोड़ें। इसे रूट डोमेन सहित किसी भी सब-डोमेन (example.com, sub.example.com) पर काम कराने के लिए .example.com उपयोग करें।

vmDomainLockRedirectUrl

Type: string Default: about:blank

⚠️ यह विकल्प target: 'node', target: 'service-worker' या target: 'bytenode' के साथ काम नहीं करता

अगर सोर्स कोड vmDomainLock द्वारा निर्दिष्ट डोमेन पर नहीं चलता, तो ब्राउज़र को पास किए गए URL पर रीडायरेक्ट करने की अनुमति देता है।

Preset Options

उच्च ऑब्फ़स्केशन, कम प्रदर्शन

प्रदर्शन ऑब्फ़स्केशन के बिना की तुलना में बहुत धीमा होगा

{
    compact: true,
    controlFlowFlattening: true,
    controlFlowFlatteningThreshold: 1,
    deadCodeInjection: true,
    deadCodeInjectionThreshold: 1,
    debugProtection: true,
    debugProtectionInterval: 4000,
    disableConsoleOutput: true,
    identifierNamesGenerator: 'hexadecimal',
    log: false,
    numbersToExpressions: true,
    renameGlobals: false,
    selfDefending: true,
    simplify: true,
    splitStrings: true,
    splitStringsChunkLength: 5,
    strictMode: null,
    stringArray: true,
    stringArrayCallsTransform: true,
    stringArrayEncoding: ['rc4'],
    stringArrayIndexShift: true,
    stringArrayRotate: true,
    stringArrayShuffle: true,
    stringArrayWrappersCount: 5,
    stringArrayWrappersChainedCalls: true,    
    stringArrayWrappersParametersMaxCount: 5,
    stringArrayWrappersType: 'function',
    stringArrayThreshold: 1,
    transformObjectKeys: true
}

मध्यम ऑब्फ़स्केशन, इष्टतम प्रदर्शन

प्रदर्शन ऑब्फ़स्केशन के बिना की तुलना में धीमा होगा

{
    compact: true,
    controlFlowFlattening: true,
    controlFlowFlatteningThreshold: 0.75,
    deadCodeInjection: true,
    deadCodeInjectionThreshold: 0.4,
    debugProtection: false,
    debugProtectionInterval: 0,
    disableConsoleOutput: true,
    identifierNamesGenerator: 'hexadecimal',
    log: false,
    numbersToExpressions: true,
    renameGlobals: false,
    selfDefending: true,
    simplify: true,
    splitStrings: true,
    splitStringsChunkLength: 10,
    strictMode: null,
    stringArray: true,
    stringArrayCallsTransform: true,
    stringArrayCallsTransformThreshold: 0.75,
    stringArrayEncoding: ['base64'],
    stringArrayIndexShift: true,
    stringArrayRotate: true,
    stringArrayShuffle: true,
    stringArrayWrappersCount: 2,
    stringArrayWrappersChainedCalls: true,
    stringArrayWrappersParametersMaxCount: 4,
    stringArrayWrappersType: 'function',
    stringArrayThreshold: 0.75,
    transformObjectKeys: true
}

कम ऑब्फ़स्केशन, उच्च प्रदर्शन

प्रदर्शन अपेक्षाकृत सामान्य स्तर पर होगा

{
    compact: true,
    controlFlowFlattening: false,
    deadCodeInjection: false,
    debugProtection: false,
    debugProtectionInterval: 0,
    disableConsoleOutput: true,
    identifierNamesGenerator: 'hexadecimal',
    log: false,
    numbersToExpressions: false,
    renameGlobals: false,
    selfDefending: true,
    simplify: true,
    splitStrings: false,
    strictMode: null,
    stringArray: true,
    stringArrayCallsTransform: false,
    stringArrayEncoding: [],
    stringArrayIndexShift: true,
    stringArrayRotate: true,
    stringArrayShuffle: true,
    stringArrayWrappersCount: 1,
    stringArrayWrappersChainedCalls: true,
    stringArrayWrappersParametersMaxCount: 2,
    stringArrayWrappersType: 'variable',
    stringArrayThreshold: 0.75
}

डिफ़ॉल्ट प्रीसेट, उच्च प्रदर्शन

{
    compact: true,
    controlFlowFlattening: false,
    deadCodeInjection: false,
    debugProtection: false,
    debugProtectionInterval: 0,
    disableConsoleOutput: false,
    identifierNamesGenerator: 'hexadecimal',
    log: false,
    numbersToExpressions: false,
    renameGlobals: false,
    selfDefending: false,
    simplify: true,
    splitStrings: false,
    strictMode: null,
    stringArray: true,
    stringArrayCallsTransform: false,
    stringArrayCallsTransformThreshold: 0.5,
    stringArrayEncoding: [],
    stringArrayIndexShift: true,
    stringArrayRotate: true,
    stringArrayShuffle: true,
    stringArrayWrappersCount: 1,
    stringArrayWrappersChainedCalls: true,
    stringArrayWrappersParametersMaxCount: 2,
    stringArrayWrappersType: 'variable',
    stringArrayThreshold: 0.75
}

VM Ultra High ऑब्फ़स्केशन (अधिकतम सुरक्षा)

यह प्रीसेट indirect dispatch सहित सभी hardening सुविधाओं के साथ VM-आधारित बाइटकोड ऑब्फ़स्केशन सक्षम करता है। सबसे मज़बूत सुरक्षा प्रदान करता है, लेकिन बड़े आउटपुट आकार और काफ़ी धीमे निष्पादन के साथ।

{
    optionsPreset: 'vm-ultra-high-obfuscation'
}

या अलग-अलग कॉन्फ़िगर करें:

{
    compact: true,
    simplify: true,
    identifierNamesGenerator: 'mangled-shuffled',
    vmObfuscation: true,
    vmForceCompileDynamicCode: false,

    vmWrapTopLevelInitializers: true,
    vmDynamicOpcodes: true,

    vmBytecodeEncoding: true,
    vmBytecodeArrayEncoding: true,
    vmBytecodeArrayEncodingKey: '',
    vmBytecodeArrayEncodingKeyGetter: '',
    vmAsyncExecutor: false,
    vmJumpsEncoding: true,
    vmMacroOps: true,
    vmDebugProtection: true,
    vmSelfDefending: true,
    vmDefenseHook: null,
    vmDefenseReaction: {
        automation: 'break',
        debugger: 'decoy',
        sandbox: 'decoy',
        domain: 'break',
        tamper: 'break',
        integrity: 'break'
    },
    vmStatefulOpcodes: true,
    vmCallContextOpcodes: false,
    vmStackEncoding: true,
    vmCompactDispatcher: true,
    controlFlowFlattening: true,
    controlFlowFlatteningThreshold: 0.5,
    deadCodeInjection: true,
    deadCodeInjectionThreshold: 0.5,
    debugProtection: true,
    debugProtectionInterval: 4000,
    disableConsoleOutput: true,
    identifierNamesGenerator: 'hexadecimal',
    log: false,
    numbersToExpressions: true,
    renameGlobals: false,
    selfDefending: true,
    simplify: true,
    splitStrings: true,
    splitStringsChunkLength: 5,
    strictMode: null,
    stringArray: true,
    stringArrayCallsTransform: true,
    stringArrayEncoding: ['rc4'],
    stringArrayIndexShift: true,
    stringArrayRotate: true,
    stringArrayShuffle: true,
    stringArrayWrappersCount: 5,
    stringArrayWrappersChainedCalls: true,
    stringArrayWrappersParametersMaxCount: 5,
    stringArrayWrappersType: 'function',
    stringArrayThreshold: 0.5,
    transformObjectKeys: true
}

VM High ऑब्फ़स्केशन (उच्चतम सुरक्षा)

यह प्रीसेट अधिकांश hardening सुविधाओं के साथ VM-आधारित बाइटकोड ऑब्फ़स्केशन सक्षम करता है। ultra-high प्रीसेट की तुलना में बेहतर प्रदर्शन के साथ मज़बूत सुरक्षा प्रदान करता है।

{
    optionsPreset: 'vm-high-obfuscation'
}

या अलग-अलग कॉन्फ़िगर करें:

{
    compact: true,
    simplify: true,
    identifierNamesGenerator: 'mangled-shuffled',
    vmObfuscation: true,
    vmForceCompileDynamicCode: false,
    vmWrapTopLevelInitializers: true,
    vmDynamicOpcodes: true,
    vmBytecodeEncoding: true,
    vmBytecodeArrayEncoding: true,
    vmBytecodeArrayEncodingKey: '',
    vmBytecodeArrayEncodingKeyGetter: '',
    vmAsyncExecutor: false,
    vmJumpsEncoding: true,
    vmMacroOps: true,
    vmDebugProtection: true,
    vmSelfDefending: true,
    vmDefenseHook: null,
    vmDefenseReaction: {
        automation: 'break',
        debugger: 'decoy',
        sandbox: 'decoy',
        domain: 'break',
        tamper: 'break',
        integrity: 'break'
    },
    vmStatefulOpcodes: true,
    vmCallContextOpcodes: false,
    vmStackEncoding: true,
    vmCompactDispatcher: false
}

VM Medium ऑब्फ़स्केशन (संतुलित सुरक्षा)

यह प्रीसेट hardening सुविधाओं के एक संतुलित सेट के साथ VM-आधारित बाइटकोड ऑब्फ़स्केशन सक्षम करता है। सुरक्षा और प्रदर्शन के बीच अच्छा समझौता।

{
    optionsPreset: 'vm-medium-obfuscation'
}

या अलग-अलग कॉन्फ़िगर करें:

{
    compact: true,
    simplify: true,
    identifierNamesGenerator: 'mangled-shuffled',
    vmObfuscation: true,
    vmForceCompileDynamicCode: false,
    vmWrapTopLevelInitializers: true,
    vmDynamicOpcodes: true,
    vmBytecodeEncoding: true,
    vmBytecodeArrayEncoding: false,
    vmBytecodeArrayEncodingKey: '',
    vmBytecodeArrayEncodingKeyGetter: '',
    vmAsyncExecutor: false,
    vmJumpsEncoding: true,
    vmMacroOps: true,
    vmDebugProtection: true,
    vmSelfDefending: false,
    vmDefenseHook: null,
    vmDefenseReaction: {
        automation: 'break',
        debugger: 'decoy',
        sandbox: 'decoy',
        domain: 'break',
        tamper: 'break',
        integrity: 'break'
    },
    browserEnvironment: {},
    vmStatefulOpcodes: false,
    vmCallContextOpcodes: false,
    vmStackEncoding: false,
    vmCompactDispatcher: false
}

VM Low ऑब्फ़स्केशन (बेसिक सुरक्षा, बेहतर प्रदर्शन)

यह प्रीसेट बिना अतिरिक्त hardening सुविधाओं के बेसिक VM-आधारित बाइटकोड ऑब्फ़स्केशन सक्षम करता है। सुरक्षा और आउटपुट आकार के बीच अच्छा संतुलन।

{
    optionsPreset: 'vm-low-obfuscation'
}

या अलग-अलग कॉन्फ़िगर करें:

{
    compact: true,
    simplify: true,
    identifierNamesGenerator: 'mangled-shuffled',
    vmObfuscation: true,
    vmForceCompileDynamicCode: false,
    vmWrapTopLevelInitializers: true,
    vmDynamicOpcodes: false,
    vmBytecodeEncoding: false,
    vmBytecodeArrayEncoding: false,
    vmBytecodeArrayEncodingKey: '',
    vmBytecodeArrayEncodingKeyGetter: '',
    vmAsyncExecutor: false,
    vmJumpsEncoding: false,
    vmMacroOps: false,
    vmDebugProtection: false,
    vmSelfDefending: false,
    vmDefenseHook: null,
    vmDefenseReaction: {
        automation: 'break',
        debugger: 'decoy',
        sandbox: 'decoy',
        domain: 'break',
        tamper: 'break',
        integrity: 'break'
    },
    browserEnvironment: {},
    vmStatefulOpcodes: false,
    vmCallContextOpcodes: false,
    vmStackEncoding: false,
    vmCompactDispatcher: false
}

VM Default (VM + String Array सुरक्षा)

यह प्रीसेट बेसिक VM-आधारित बाइटकोड ऑब्फ़स्केशन को string array सुरक्षा के साथ जोड़ता है। स्ट्रिंग सुरक्षा के साथ VM ऑब्फ़स्केशन के लिए अच्छा शुरुआती बिंदु।

{
    optionsPreset: 'vm-default'
}

या अलग-अलग कॉन्फ़िगर करें:

{
    compact: true,
    simplify: true,
    identifierNamesGenerator: 'mangled-shuffled',
    vmObfuscation: true,
    vmForceCompileDynamicCode: false,
    vmWrapTopLevelInitializers: true,
    vmDynamicOpcodes: true,
    vmBytecodeEncoding: true,
    vmBytecodeArrayEncoding: true,
    vmStringArrayBytecodeOnly: true,
    vmAsyncExecutor: false,
    vmJumpsEncoding: true,
    vmMacroOps: true,
    vmDebugProtection: {
        inspectorDetection: true
    },
    vmSelfDefending: true,
    vmDefenseHook: null,
    vmDefenseReaction: {
        automation: 'break',
        debugger: 'decoy',
        sandbox: 'decoy',
        domain: 'break',
        tamper: 'break',
        integrity: 'break'
    },
    browserEnvironment: {},
    vmStatefulOpcodes: false,
    vmCallContextOpcodes: false,
    vmStackEncoding: false,
    vmCompactDispatcher: false,
    stringArray: true,
    stringArrayRotate: true,
    stringArrayShuffle: true,
    stringArrayThreshold: 1,
    stringArrayIndexShift: true,
    stringArrayIndexesType: ['hexadecimal-number'],
    stringArrayCallsTransform: true,
    stringArrayCallsTransformThreshold: 1,
    stringArrayWrappersCount: 3,
    stringArrayWrappersType: 'function',
    stringArrayWrappersParametersMaxCount: 5,
    stringArrayWrappersChainedCalls: true,
    stringArrayEncoding: ['base64'],
    splitStrings: true,
    splitStringsChunkLength: 6
}