PerimeterX/restringer

Add support for ignoring certain global variables

Closed this issue · 4 comments

For things like malware or extremely obfuscated extensions, restringer seems to fail on things like the chrome object.
I propose adding in a flag (or option) to handle those types of object (chrome, browser, etc.) - or rather,t o ignore them and treat them as predefined objects in the global scope.

That sounds doable. Can you provide a code example of such a script?

Absolutely I can!
I'll provide an obfuscated example, as well as a real-world (somewhat dodgy) obfuscated chrome extension example.
Here's the hello_world example from the Google Chrome repo:
https://github.com/GoogleChrome/chrome-extensions-samples/blob/4da98eada44ab6db2e35e361f08343cc5ea568e6/examples/hello-world/background.js

chrome.runtime.onInstalled.addListener(async () => {
  // ...
})

chrome object reference: https://developer.chrome.com/docs/extensions/reference/

And I've been picking apart those dodgy youtube bot extensions to see how they tick, so here's a pastebin of their popup.js file. It's not malicious at all I've found, just reeeaaally annoyingly obfuscated.
https://gist.github.com/brocococonut/1ce48b090fb5c5c06eb399986d0f01dd

One way keys for potentially undefined objects could be represented is using optional chaining. So converting it to something like chrome?.runtime?...
The downside with this is that it might get stripped as unreachable or always false code false positives depending on how things are done at the moment

I've reviewed the code you added and seen the error you're talking about.
The thing is, the error doesn't indicate a failure in deobfuscation. In fact, the script was completely deobfuscated, but an error was printed after the program finished its run.

I'm now catching async errors, so the issue should be resolved.
Thanks for bringing this to my attention!
Closing this as fixed in v1.0.2