Looking at https://github.com/javascript-obfuscator/javascript-obfuscator/blob/master/README.md it looks like "Debug Protection Interval" requires "Debug protection". If we have contact with the developer, what does the behavior looks like if "Debug protection" is on but "Debug Protection Interval" is off? Still trying to figure out what the "Debug protection" option actually does by digging through the source, but based on https://github.com/javascript-obfuscator/javascript-obfuscator/blob/master/src/templates/debug-protection-nodes/debug-protection-function-interval-node/DebugProtectionFunctionIntervalTemplate.ts it adds a ``` setInterval(debugProtectionFunctionName, 4000); ``` to ... where? How many of these interval timers end up live? "debugProtectionFunctionName" is defined in https://github.com/javascript-obfuscator/javascript-obfuscator/blob/master/src/templates/debug-protection-nodes/debug-protection-function-node/DebugProtectionFunctionTemplate.ts which when the timer fires will presumaby call debugProtectionFunctionName with `ret` undefined, which will call `debuggerProtection(0)`. What that does I think depends on the "ObfuscationTarget.BrowserNoEval" option per <https://github.com/javascript-obfuscator/javascript-obfuscator/blob/62168969786dbfed949012397cc06d0d9ce4c262/src/custom-nodes/debug-protection-nodes/DebugProtectionFunctionNode.ts#L63-L65>. So either <https://github.com/javascript-obfuscator/javascript-obfuscator/blob/master/src/templates/debug-protection-nodes/debug-protection-function-node/DebuggerTemplate.ts> or <https://github.com/javascript-obfuscator/javascript-obfuscator/blob/master/src/templates/debug-protection-nodes/debug-protection-function-node/DebuggerTemplateNoEval.ts>. The latter seems to boil down to either an infinite loop if counter is a string (not in this case), or a bunch of debugger calls. But note that the caller in "debuggerProtection" looks like this: ``` function debuggerProtection (counter) { {debuggerTemplate} debuggerProtection(++counter); } ``` and gets called with "0" as the arg. So yes, this will in fact do infinite recursion, with a `debugger;` at every level (in the no-eval case; in the eval case it does something more complicated like: ``` (function () {return false;}.constructor('debu' + 'gger').apply('stateObject')); ``` or whatnot. Anyway, this will stop when the stack is exhausted. If we started allowing a much deeper recursion level, that could definitely significantly increase the time until the stack exhausts... (I think I'm glad we don't implement tail recursion; seems to me that `debuggerProtection` is an infinite loop in a browser with tail recursion....)
Bug 1537609 Comment 12 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Looking at https://github.com/javascript-obfuscator/javascript-obfuscator/blob/master/README.md it looks like "Debug Protection Interval" requires "Debug protection". If we have contact with the developer, what does the behavior looks like if "Debug protection" is on but "Debug Protection Interval" is off? Still trying to figure out what the "Debug protection" option actually does by digging through the source, but based on https://github.com/javascript-obfuscator/javascript-obfuscator/blob/master/src/templates/debug-protection-nodes/debug-protection-function-interval-node/DebugProtectionFunctionIntervalTemplate.ts it adds a ``` setInterval(debugProtectionFunctionName, 4000); ``` to ... where? How many of these interval timers end up live? "debugProtectionFunctionName" is defined in https://github.com/javascript-obfuscator/javascript-obfuscator/blob/master/src/templates/debug-protection-nodes/debug-protection-function-node/DebugProtectionFunctionTemplate.ts which when the timer fires will presumaby call debugProtectionFunctionName with `ret` undefined, which will call `debuggerProtection(0)`. What that does I think depends on the "ObfuscationTarget.BrowserNoEval" option per <https://github.com/javascript-obfuscator/javascript-obfuscator/blob/62168969786dbfed949012397cc06d0d9ce4c262/src/custom-nodes/debug-protection-nodes/DebugProtectionFunctionNode.ts#L63-L65>. So either <https://github.com/javascript-obfuscator/javascript-obfuscator/blob/master/src/templates/debug-protection-nodes/debug-protection-function-node/DebuggerTemplate.ts> or <https://github.com/javascript-obfuscator/javascript-obfuscator/blob/master/src/templates/debug-protection-nodes/debug-protection-function-node/DebuggerTemplateNoEval.ts>. The latter seems to boil down to either an infinite loop if counter is a string (not in this case), or a bunch of debugger calls. But note that the caller in "debuggerProtection" looks like this: ``` function debuggerProtection (counter) { {debuggerTemplate} debuggerProtection(++counter); } ``` and gets called with "0" as the arg. So yes, this will in fact do infinite recursion, with a `debugger;` at every level (in the no-eval case; in the eval case it does something more complicated like: ``` (function () {return false;}.constructor('debu' + 'gger').apply('stateObject')); ``` or whatnot. Anyway, this will stop when the stack is exhausted. If we started allowing a much deeper recursion level, that could definitely significantly increase the time until the stack exhausts... (I think I'm glad we don't implement tail recursion; seems to me that `debuggerProtection` is an infinite loop in a browser with tail recursion....)