Enthält eine Funktion an irgendeiner Stelle ihres Rumpfs einen direkten Aufruf von eval(code) (auch in verschachtelten Funktionen), wird die gesamte Funktion samt aller darin verschachtelten Funktionen von der VM-Obfuskierung übersprungen. Der Grund: Direktes eval greift auf die lokalen Variablen der umgebenden Funktion zu, und diese stehen nicht mehr zur Verfügung, sobald die Funktion zu VM-Bytecode kompiliert wurde.

// ❌ Entire IIFE is NOT VM-obfuscated because of direct eval inside
(function () {
    function loadConfig() {
        eval(decodedLoader); // direct eval - blocks VM for the whole IIFE
    }
    // ... all your code ...
})();

// ✅ Use indirect eval - runs in global scope, does not block VM
(function () {
    function loadConfig() {
        (0, eval)(decodedLoader); // indirect eval - VM obfuscates the IIFE
    }
    // ... all your code ...
})();

// ✅ Or unwrap the IIFE - each top-level function is checked independently
function loadConfig() {
    eval(decodedLoader); // only this function is skipped
}
// ... other top-level functions are still VM-obfuscated ...

Die Erkennung erfasst direktes eval (eval(code) und eval?.(code)). Indirekte Formen wie (0, eval)(code) und window.eval(code) laufen im globalen Scope und blockieren die VM-Obfuskierung nicht.

Notausgang (v6.14.0+): Setzen Sie vmForceCompileDynamicCode: true (oder aktivieren Sie den Schalter Force Compile Dynamic Code in der Gruppe Überschreibungen des VM-Bereichs), damit die umgebende Funktion dennoch in Bytecode überführt und VMDynamicCodeSkipped unterdrückt wird. Das ist nur dann sicher, wenn der zur Laufzeit erzeugte Rumpf keinen Bezeichner referenzieren kann, den der Obfuscator umbenennt; andernfalls wirft der Code zur Laufzeit einen ReferenceError. Die vollständige Abwägung finden Sie auf der Rezeptseite.