Anti Debugging Mechanism Full Example

Imagine there is a malicious third-party script originated from px-blog-source-map-anti-debug.perimeterx.com in this innocent website of ours called px-blog-source-map-anti-debug.appspot.com.
that third party script steals cookies from the browser and sends them all back to px-blog-source-map-anti-debug.perimeterx.com servers.
that script can use Source Map feature to hide its activity pretty well, by setting a cookie once the user of the browser opened their
devtools, and serve back an innocent script in case that cookie exists instead of the malicious one,
that way hiding its malicious activity from users who might have tried to have a look at it!
Alternately, other actions can be made when devtools are detected as open. Read the Demo Instructions for more!

back to menu







remember - command will execute with every refresh until exoneration time has come (which is configured by the server to be 15 seconds since devtools detection occurred by default)


Demo Instructions

hiding malicious activity: when it's off, malicious.js script will always be the script that the malicious server serves, regardless of whether open devtools were detected or not.
when it's on, server will serve an "innocent" script instead of malicious.js as long as open devtools are detected or were in the past, for a configured (by the server) amount of time, in order to hide its malicious activity from the user.
set it to on by clicking the button, refresh the page and see how the "I stole your COOKIES!" message stops appearing when open devtools are detected. checkout the content of malicious.js too and see how it is different from before!

commands

location.href = "" command is a trick to hide your trails (this example goes much better with hiding malicious activity turned on).
the second the user opens their devtools, that command is executed, which causes the browser to refresh. since hiding malicious activity is turned on,
after the refresh malicious.js's true malicious content will be replaced with an innocent script thus covering the trails of malicious.js only when is about to be inspected!
if you found yourself stuck in an infinite refresh loop, that is because you've set this command with hiding malicious activity turned off! don't worry, it'll be over in 15 seconds anyway.

while (1) {} command is another trick to get the user's tab stuck the second devtools are detected to be opened, and by that forcing the user to shut the tab down.

ANYTHING: insert any JS command you want and see how it is executed only when devtools detected to be opened, you don't have to use the options i gave you!


Mechanism Implementation Explained ...

Reading the source code of this example will be tricky mostly because i did a bad job implementing this full example (but hey, it works right?), so
i feel like i owe you an explanation of "what just happened here?":

malicious.js is served by a cross domain called px-blog-source-map-anti-debug.perimeterx.com. it then creates an iframe to px-blog-source-map-anti-debug.perimeterx.com which will store the "communication cookie".

the communication cookie is the cookie that stores the commands that you set. if it exist, it means the user was marked as a "devtools opener" for
the next 15 seconds (can be configured in the server), and the current command will execute with every refresh as long as the user is still marked.
the temporary marking is done by setting an expires attribute on the communication cookie to 15 seconds from the time of detection.

i chose cookies for my 2-way (client-->server & server-->client) communication mechanism because it allows me to
simulate a request and response mechanism between the client side and the server side considering how real
responses are not possible when using Source Map feature requests.

since malicious.js and the iframe it creates are not at the same domain, i use postMessage to communicate between the two
and pass commands from their manager (the px-blog-source-map-anti-debug.perimeterx.com iframe) to the component that is responsible of their execution (malicious.js).

when you click the button, the server is updated with the new command to execute
on detection (the way i update the server with new commands is kind of crooked and confusing, so don't pay too much attention to it).

the button is flipping a boolean flag at the server that determines whether to normally serve malicious.js (off)
or serve an innocent script instead (on) when devtools opening is detected, in order to hide the malicious server's source code. this mechanism is also affected by the 15 seconds exoneration time.

And that is how you implement a command and control server and client side mechanism that

Only kicks in when trying to investigate it using the Source Map feature!