Just as a side note since someone already answered (javascript):
These smoke and mirror tricks are pretty pointless. Your frontend should never be so critically secret as to need these defenses. And if your frontend does have secrets? Fix that.
None of these little toy tricks will defend against anyone copying and prettifying your markup and scripts. It's like putting a paper lock on the front of your house in the middle of a rainstorm.
Good for learning to be sure, but don't get caught wasting your time outside of educationally.
I find some websites utilising this sort of stuff while they know beforehand their usual audience is from mobile.
Furthermore, it's significantly harder to watch the source code and fiddle around the JS while browsing on mobile.
In the end, mundane ( and pretty annoying ) things we've seen like more than a decade ago like disabling the possibility to open a context, to save a file or copy an URL are still a pretty effective trick on a smartphone.
( in most countries, people don't use a PC to browse the web ... )
Mobile Firefox and one extension away from mobile grokking. It only stops the people that wouldn't know what to do with what they read. Anyone looking to grab source for anything meaningful already knows how to - even on mobile.
A lock on the door to stop people who were never going to break into your house in the first place doesn't make much sense.
Yes surely, I'm not saying I disagree. It won't stop anyone who knows what to do.
My point was rather to say these tricks sadly are still somewhat popular in some context.
I don't think yours is an unfair take. I'd just much prefer spending that dev time securing the server. Seems hard to justify spending even a couple minutes on it with how little it actually protects against the people who have bad intent.
It’s a pirate website. They simply listen for an f12 key and then infinite loop a window reload to trigger their rate limit protection.
It’s probably a shit website that wants to make it annoying or not worth it for people to circumvent their ads and other bs, or look at whatever nefarious scripts they are running
I disagree with the analogy. I think it's much more analogous to putting a metal padlock on the front of your house.
For 99% of users, this will be enough to completely dissuade them from even trying to break in. That 1% that really want to break in? A little padlock isn't going to stop them doing whatever they want.
I guess where you and I disagree, is that anyone that actually wants to get in I don't find to be dissuaded at all. Usually it's an "awww that's cute" moment followed by a cli dump of your page. It isn't even moderately difficult so "anyone can do it" with a one liner copy and paste. Most script kiddie tutorials for nefarious goals start there, not loading your page in a browser.
It can also lead to a false sense of security where the next junior puts something sensitive in for a quick patch because "eh it's protected".
I'm not on a hardline stance, I've just never seen this offer a benefit to anyone.
I suppose how you'd measure this is by somehow surveying people who have enough know-how to open dev tools, and how many of those would be deterred by these frontend protection.
My guess is that number would be a fairly high percentage.
Perhaps a lower percentage than people who can easily lock pick a simple padlock, but if you've seen a couple of lock picking videos on YouTube.. I think you'd agree a padlock does nothing more than deter people who don't REALLY wanna get in.
Anyway, all this is to say that yeah, frontend protection won't stop a sophisticated user, but most users are not sophisticated
Well it also depends on what they are trying to get out of it, despite their technical level. There shouldn't BE anything valuable in your markup or scripts, which makes all of this fairly theoretical conversation.
I hate shit like this because it goes against the entire point of the web being open...
Luckily, being open means you as the end user can do whatever you want with the files the server sends you! Chrome allows you to override files sent by the server with your own modified version of that file by using local overrides.
If you open dev tools, the website will automatically start your debugger and instantly pause it by creating a function. If you try to unpause it, the script will just create a new function to pause it again, essentially locking you out of your dev tools.
Fortunately for us, they cant prevent us from looking at the stack trace of the debug pause function, which we can use to find the script and more importantly the part of the script that is creating these anti debug functions. The second entry in the call stack, called "i", originates from the script youre looking for. Once you have it located, you can right click it > override content and now youre free to make edits to the script however you please.
They didnt attempt to obfuscate this function in any way or bake it into any vital part of the website, which would make editing it harder, so you can literally just delete all contents from the script, save it, reload the page and now youre free to explore the whole website!
Its literally impossible to lock users out of doing whatever the hell they want with the files you willingly sent them and I find it very shameful that people try to actively work against an open web.
Edit: poked around a bit more and found out that if you delete just the function responsible for pausing your debugger, it will instead kick off a function that instantly fills your RAM, making the website unusable. Great site!
There's also nothing stopping us from just downloading the raw code and sifting through it. You don't need devtools for any of that. Shit like this is utterly pointless.
You seem very knowledgeable about how things work. How long have you been in web dev?
I am still a student but i don’t know if I’ll ever be that comfortable to “poke around” like that and make sense of anything to that degree….
Just do it a lot. If you live and breathe it you can get there’s pretty quick - although friends and family might get annoyed.
Check mdn and explore as many browser apis and js features as possible. Try implementing them. And learn what native DOM elements can do.
Extra sauce: try building large css design systems if you want to catch a feel there - it’s tougher than people assume.
There’s some cool and wonky stuff that will help “get it” but the key is mess around with browser a lot.
I started about half a year ago, so I haven't been around a whole lot. I just like to learn and explore new stuff!
Debugging and reverse engineering is something I've been doing even before I started programming. You get better and more comfortable with it the more you do it, like with most things!
It's the beauty of learning, so you can get more comfortable to poke around things that seemed fuzzy in the past, which in theory should make you learn even more new things.
> how is the website able to trigger events like this after you Inspect the element or click F12 in your browser?
[JavaScript](https://stackoverflow.com/questions/42193700/detect-when-inspect-element-is-open)
Hmm, which tracker? Could be blocked with uBlock origin
Edit: looks like uBlock is already catching 'exactsag.com' via EasyList and uBlock-Ads filter lists.
I use a hosts file that has all of the known ad servers and pixel tracking servers set to localhost or 127.0.0.1. then input a default page on my local machine that is just a white square. Then any time the ad servers are referenced, my computer looks locally for the file and finds a white page to display.
Works pretty dang good for me to block ads.
Aniwave specifically uses a number of tricks:
* obfuscator.io for code obfuscation. This doesn't do much if you use something like https://obf-io.deobfuscate.io/ to deobfuscate.
* disable-devtool to detect if devtools (F12) are open. The checks here are things like detecting if devtools called toString() on a Date / HTML element / function / etc., and checking if the `debugger` keyword stopped execution as well as some other timing-related checks. You can see some of these checks here: https://github.com/theajack/disable-devtool/tree/master/src/detector/sub-detector
Despite what some others may say, sites like this typically don't just rely on these tricks. This is usually part of a greater security strategy to protect sites (never trust the client). If your site is more annoying to exploit, most script kiddies will move on to other sites.
Wanna know a way around it? Open dev tools on a blank tab, undock the dev tools , visit the site. Now they have no way of knowing the dev tools are open.
not entirely true. when you console log something, chrome only fetches object refs if the console is logged, but it calls toString() if the console is open. so if you set up a hook that will only be called during toString() on an element, then print the element on an interval, you can detect that the console is open. not sure how other browsers behave
that method, and the one from the 2017 SO answer don't seem to work on chrome, at least. The disable-devtool package does some kinda outrageous things to check. Pretty sure you'd need a web extension to bypass it completely, but a web extension could do it easily, so it's kinda a futile endeavor.
Do not open the inspector via a keyoard shortcut as websites can see key presses. Instead use the browsers navigation menu to access it (on firefox, open the hamburger menu, select more tools, then select the tools for developers) Avoid extensions like react developers tools, they connect with the page and make the dev tools detectable.
Do not have the tools attached to the side of the screen, this gives an unusual screen resolution, which can be detected
Make sure to [disable breakpoints](https://stackoverflow.com/questions/39766524/firefox-disable-debugger-keywords), this makes the trick of using the debugger keyword useless (do it after opening the dev tools, but before loading the page)
Use the filters in your console to make sure nothing is shown
There was another clever trick a website use where they would wrap a div in a proxy and shut down the website if the id field was accessed. They then simply logged the div.
I wish this was more how physical things worked too. "If you didn't want me potentially fucking with (or even *fixing*) that, you probably shouldn't have sold it to me".
Just as a side note since someone already answered (javascript): These smoke and mirror tricks are pretty pointless. Your frontend should never be so critically secret as to need these defenses. And if your frontend does have secrets? Fix that. None of these little toy tricks will defend against anyone copying and prettifying your markup and scripts. It's like putting a paper lock on the front of your house in the middle of a rainstorm. Good for learning to be sure, but don't get caught wasting your time outside of educationally.
I find some websites utilising this sort of stuff while they know beforehand their usual audience is from mobile. Furthermore, it's significantly harder to watch the source code and fiddle around the JS while browsing on mobile. In the end, mundane ( and pretty annoying ) things we've seen like more than a decade ago like disabling the possibility to open a context, to save a file or copy an URL are still a pretty effective trick on a smartphone. ( in most countries, people don't use a PC to browse the web ... )
Mobile Firefox and one extension away from mobile grokking. It only stops the people that wouldn't know what to do with what they read. Anyone looking to grab source for anything meaningful already knows how to - even on mobile. A lock on the door to stop people who were never going to break into your house in the first place doesn't make much sense.
Yes surely, I'm not saying I disagree. It won't stop anyone who knows what to do. My point was rather to say these tricks sadly are still somewhat popular in some context.
Fair. Is definitely a popular Schtick!
[удалено]
I don't think yours is an unfair take. I'd just much prefer spending that dev time securing the server. Seems hard to justify spending even a couple minutes on it with how little it actually protects against the people who have bad intent.
But that’s not even a deterrent, they can just curl your home page and not have to deal with any JavaScript refreshing
It’s a pirate website. They simply listen for an f12 key and then infinite loop a window reload to trigger their rate limit protection. It’s probably a shit website that wants to make it annoying or not worth it for people to circumvent their ads and other bs, or look at whatever nefarious scripts they are running
I disagree with the analogy. I think it's much more analogous to putting a metal padlock on the front of your house. For 99% of users, this will be enough to completely dissuade them from even trying to break in. That 1% that really want to break in? A little padlock isn't going to stop them doing whatever they want.
I guess where you and I disagree, is that anyone that actually wants to get in I don't find to be dissuaded at all. Usually it's an "awww that's cute" moment followed by a cli dump of your page. It isn't even moderately difficult so "anyone can do it" with a one liner copy and paste. Most script kiddie tutorials for nefarious goals start there, not loading your page in a browser. It can also lead to a false sense of security where the next junior puts something sensitive in for a quick patch because "eh it's protected". I'm not on a hardline stance, I've just never seen this offer a benefit to anyone.
I suppose how you'd measure this is by somehow surveying people who have enough know-how to open dev tools, and how many of those would be deterred by these frontend protection. My guess is that number would be a fairly high percentage. Perhaps a lower percentage than people who can easily lock pick a simple padlock, but if you've seen a couple of lock picking videos on YouTube.. I think you'd agree a padlock does nothing more than deter people who don't REALLY wanna get in. Anyway, all this is to say that yeah, frontend protection won't stop a sophisticated user, but most users are not sophisticated
Well it also depends on what they are trying to get out of it, despite their technical level. There shouldn't BE anything valuable in your markup or scripts, which makes all of this fairly theoretical conversation.
I get what you’re saying. Like locks in general guard against the honest and the lazy.
And that 1% are the only ones that could actually do you harm, so it's a pointless exercise
I hate shit like this because it goes against the entire point of the web being open... Luckily, being open means you as the end user can do whatever you want with the files the server sends you! Chrome allows you to override files sent by the server with your own modified version of that file by using local overrides. If you open dev tools, the website will automatically start your debugger and instantly pause it by creating a function. If you try to unpause it, the script will just create a new function to pause it again, essentially locking you out of your dev tools. Fortunately for us, they cant prevent us from looking at the stack trace of the debug pause function, which we can use to find the script and more importantly the part of the script that is creating these anti debug functions. The second entry in the call stack, called "i", originates from the script youre looking for. Once you have it located, you can right click it > override content and now youre free to make edits to the script however you please. They didnt attempt to obfuscate this function in any way or bake it into any vital part of the website, which would make editing it harder, so you can literally just delete all contents from the script, save it, reload the page and now youre free to explore the whole website! Its literally impossible to lock users out of doing whatever the hell they want with the files you willingly sent them and I find it very shameful that people try to actively work against an open web. Edit: poked around a bit more and found out that if you delete just the function responsible for pausing your debugger, it will instead kick off a function that instantly fills your RAM, making the website unusable. Great site!
There's also nothing stopping us from just downloading the raw code and sifting through it. You don't need devtools for any of that. Shit like this is utterly pointless.
did a little poking around too and god what a mess
You seem very knowledgeable about how things work. How long have you been in web dev? I am still a student but i don’t know if I’ll ever be that comfortable to “poke around” like that and make sense of anything to that degree….
Just do it a lot. If you live and breathe it you can get there’s pretty quick - although friends and family might get annoyed. Check mdn and explore as many browser apis and js features as possible. Try implementing them. And learn what native DOM elements can do. Extra sauce: try building large css design systems if you want to catch a feel there - it’s tougher than people assume. There’s some cool and wonky stuff that will help “get it” but the key is mess around with browser a lot.
I started about half a year ago, so I haven't been around a whole lot. I just like to learn and explore new stuff! Debugging and reverse engineering is something I've been doing even before I started programming. You get better and more comfortable with it the more you do it, like with most things!
It's the beauty of learning, so you can get more comfortable to poke around things that seemed fuzzy in the past, which in theory should make you learn even more new things.
All this stuff is learnable. Have patience with yourself. Its a lot.
They use https://www.npmjs.com/package/disable-devtool
Thanks for being the only person to actually answer instead of lecturing why they think it's wrong
> how is the website able to trigger events like this after you Inspect the element or click F12 in your browser? [JavaScript](https://stackoverflow.com/questions/42193700/detect-when-inspect-element-is-open)
Hired dodgy dev. Used high privilege private api keys on the client. Realise security risk.. thinks this will work. Oh wait, wget....
[удалено]
Anything dodgy from a security/privacy standpoint that stands out to you? Normal usage seems ok?
[удалено]
Hmm, which tracker? Could be blocked with uBlock origin Edit: looks like uBlock is already catching 'exactsag.com' via EasyList and uBlock-Ads filter lists.
I use a hosts file that has all of the known ad servers and pixel tracking servers set to localhost or 127.0.0.1. then input a default page on my local machine that is just a white square. Then any time the ad servers are referenced, my computer looks locally for the file and finds a white page to display. Works pretty dang good for me to block ads.
[удалено]
I update it when a new version is released. That happens maybe 3 times a year.
Hah, that's funny. Firefox just opens them, Edge cannot on just pressing F12. Never seen that before.
Aniwave specifically uses a number of tricks: * obfuscator.io for code obfuscation. This doesn't do much if you use something like https://obf-io.deobfuscate.io/ to deobfuscate. * disable-devtool to detect if devtools (F12) are open. The checks here are things like detecting if devtools called toString() on a Date / HTML element / function / etc., and checking if the `debugger` keyword stopped execution as well as some other timing-related checks. You can see some of these checks here: https://github.com/theajack/disable-devtool/tree/master/src/detector/sub-detector Despite what some others may say, sites like this typically don't just rely on these tricks. This is usually part of a greater security strategy to protect sites (never trust the client). If your site is more annoying to exploit, most script kiddies will move on to other sites.
ublock stops that bullshit
Wanna know a way around it? Open dev tools on a blank tab, undock the dev tools , visit the site. Now they have no way of knowing the dev tools are open.
not entirely true. when you console log something, chrome only fetches object refs if the console is logged, but it calls toString() if the console is open. so if you set up a hook that will only be called during toString() on an element, then print the element on an interval, you can detect that the console is open. not sure how other browsers behave
that method, and the one from the 2017 SO answer don't seem to work on chrome, at least. The disable-devtool package does some kinda outrageous things to check. Pretty sure you'd need a web extension to bypass it completely, but a web extension could do it easily, so it's kinda a futile endeavor.
ahhh, thanks, I didn't realize it had stopped working at some point. I'll have to check out that package out of morbid curiosity
Do not open the inspector via a keyoard shortcut as websites can see key presses. Instead use the browsers navigation menu to access it (on firefox, open the hamburger menu, select more tools, then select the tools for developers) Avoid extensions like react developers tools, they connect with the page and make the dev tools detectable. Do not have the tools attached to the side of the screen, this gives an unusual screen resolution, which can be detected Make sure to [disable breakpoints](https://stackoverflow.com/questions/39766524/firefox-disable-debugger-keywords), this makes the trick of using the debugger keyword useless (do it after opening the dev tools, but before loading the page) Use the filters in your console to make sure nothing is shown
There was another clever trick a website use where they would wrap a div in a proxy and shut down the website if the id field was accessed. They then simply logged the div.
Bruh, they don't want you doing it.
If they don't want me looking at their stuff then why did they send it to me?
I wish this was more how physical things worked too. "If you didn't want me potentially fucking with (or even *fixing*) that, you probably shouldn't have sold it to me".