Develop Reference

Avoid/Bypass Dev tools detection in Chrome?

I've been trying to get a video source from a web site but when I open the dev tools to do so, It shows me this message: "Dont open Developer Tools".
So far I have tried:
Turn off javascript ->doesn't work, doesn't load the video.
Find the function:
olplayer.src({type:"application/x-mpegURL",src:"https://127.0.0.1/no_video.mp4.m3u8"});
document.body.innerHTML="";
document.write(" Dont open Developer Tools. ");
throw new Error(" Dont open Developer Tools. ");
self.location.replace('https:'+window.location.href.substring(window.location.protocol.length));
set a breakpoint and reload, run:
Object.defineProperty(window, "console", {configurable: false});
Any ideas how to bypass this protection?

You are probably talking about a video hosted on hqq.tv. Their code uses a check() function which does all the nasty magic to block all hacking attempts, so the easiest way to bypass the protection altogether is to disable this function.
Since recently, Chrome supports local overrides for javascript code (I found out about this from this SO thread). A bit nicer explanation on how this works can be found on Medium.
So I went ahead and located the check() function (in my case it was hqq.tv/js/embed.129.js) and added it to Overrides. In the overridden version I found the check() function and added return true; to its beginning:
function check(){return true; var element=new Image(); ...
However, this only disables the Dev Tool protection, but doesn't make your life much easier in terms of saving the video. My own solution doesn't work on hqq.tv, nor had I any luck with the solution suggested on videohelp forum. However, I was able to capture the stream using Stream Recorder Chrome extension.

I Found a bypass for the detection, use FireBug Lite extension for chrome (or the browser u prefer). It bypasses the detection because it is an extension

Firefox 68: local files now treated as cross-origin; is there a way to override?

Firefox 68 fixes a security problem with local files (https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730), but in so doing breaks testing code locally. Is there a way to override this as can be done with Chrome and Opera (e.g., --allow-file-access-from-files)?
I cannot find anything relevant on the Firefox site, and cannot find a suitable command-line option or anything in about:config.
try {
main = opener.document;
}
catch (e) {
console.log(e);
console.log(e.name);
}
}
I get the following messages in the console:
DOMException: "Permission denied to access property "document" on cross-origin object"
SecurityError

[2023 Update]: This pref has been removed since this answer was posted. See user3611642's answer for an up to date solution].
Letting the original answer if someone comes back to using FF68 and faces this issue.
You can leverage this restriction by going to about:config url and then uncheck privacy.file_unique_origin boolean value.
However be aware that this only reverts to < 68 protection mode, which is to only allow digging in, even with this flag down you won't be able to fetch ../some_other_dir/foo.bar.

In my case: Firefox ver. 98.0.2 (64-bit) going to about:config and changing the flag helped:
security.fileuri.strict_origin_policy = false

Avoid the detection of "whether Chrome DevTools(console) is open"

Today I see this post
Find out whether Chrome console is open .
#zswang gave the way to detect if Chrome DevTools(console) is open. That's really suprise me, then I began to think is there any way to walk around this detection technique?
There are two way to detect chrome DevTools is open(detail in above post)
Using Object.defineProperty
I can walk around this, it can be assign to another function.I have tried Object.defineProperty=null ,then the detect function die(I know write a mock function is better, here just an example)
Using obj.__defineGetter__ (Object.prototype.__defineGetter__)
Object.prototype.__defineGetter__= null would not break the detection, how to walk around?
Finally, I have to say I don't like to be monitored.Hope there is a proper way to walk around.

There are so many ways to detect the use of DevTools, that it would be difficult to block them all. As DevTools gains new features, there are new ways to detect its use. Any third-party tool to block detection can't be trusted to block 100% of detection techniques.
There is a bug reported to the Chromium team here on the idea of integrating detection blocking directly into Chrome.
Disable javascript
The only way to definitively block any detection of the use of DevTools is to disable javascript. You can still execute javascript in the DevTools console when javascript for a page is disabled. I have found it sufficient to disable javascript immediately after opening DevTools, like this:
Open DevTools Command+Option+J (Mac) or Control+Shift+J (Windows, Linux)
Type the hotkey to open the command menu – Cmd+Shift+P (Mac) or Ctrl+Shift+P (Windows, Linux)
Type dis and hit return to select the Disable Javascript option.
… inspect the website …
Re-enable javascript by evoking the command menu and typing ena and hit return (selecting the Enable Javascript option)
Of course, this method is useless for monitoring malicious code because no code is running when javascript is disabled. But at least it may give you a chance to set breakpoints before re-enabling javascript.
Chrome DevTools Protocol
It may be possible to use the Chrome DevTools Protocol to connect to a separate instance of Chrome and inspect a website without opening DevTools in that instance at all:
The Developer Tools front-end can attach to a remotely running Chrome instance for debugging. For this scenario to work, you should start your host Chrome instance with the remote-debugging-port command line switch:
chrome.exe --remote-debugging-port=9222
Then you can start a separate client Chrome instance, using a distinct user profile:
chrome.exe --user-data-dir=<some directory>
Now you can navigate to the given port from your client and attach to any of the discovered tabs for debugging: http://localhost:9222

The most popular method of detecting if dev tools is open involves invoking console.log() which happens only when devtools is opened.
Below is an example:
var image = new Image();
Object.defineProperty(image, 'id', {
get: function() {
$('#<element_to_remove_on_detection>').remove();
console.clear();
}
});
console.log('%c', image);
In the above case, a new image object is created and the getter is overridden for the 'id'. When console.log is invoked, the getter is called as well.
So basically, any time the getter is called, the website knows that the devtools has been opened because console.log() doesn't get called until devtools is open.
It is a really clever way of detection. Nonetheless, when trying to debug such code, Simply using extension like Resource Override and injecting
console.log = null;
Into the head of the page should stop the website from detecting if devtools is open.

For me, I just added a breakpoint at the top of the offending script, then ran Image = null in the developer console.
I found this solution by googling how websites do that, which brought me this stackoverflow post, I could see in my console a new Image was being logged, so setting Image to null causes an error, which causes the detection to fail.

You could try something like this:
var oldDefineProperty = Object.defineProperty;
Object.defineProperty = function() {
var firstArg = arguments[0];
arguments[0] = _.extend({
get id() {
return firstArg.id;
}
}, arguments[0]);
return oldDefineProperty.apply(this, arguments);
}
var element = new Image();
element.id = "something";
Object.defineProperty(element, 'id', {
get: function() {
alert("detected");
}
});
console.log('%cHello', element);
<script src="http://underscorejs.org/underscore-min.js"></script>
This seems to prevent the alert from showing for me. I'm using the _extend function from Underscore. I don't know if I'm missing anything but just playing around.
As for __defineGetter__, this was deprecated so you'd expect this not to be used.

Failure installing the debug extension of your Crossrider Extension - Firefox

FF25.0, Fedora 18.
This just keeps going round in circles. The staging extension installs, and parts of it are active as the extension modifies a bit of the dom (I think even the background script is running too as the local storage is initialized). Not all of the extension works, such as the sidebar and other dom injection that should run on page load. But the debug mode page in crossrider fails to recognise the running extension.
I suspect this is due to a bug in my code but there appears to be no way to debug it. When I commented out the sidebar, it still showed briefly after another install, which makes me suspect a proxy/cache is getting in the way but adding an extra GET argument on the extension URL didn't help. I've tried adding debugger to extension.js. The console is empty. No errors are reported by firebug. The extension works fine in chrome, and I really don't want to go back to a blank extension and try adding bit by bit till it fails. There must be a simpler way such as making firefox just say, "here's your problem, right on line number X". Any ideas?
[EDIT]
After turning on some debug options, I've got errors in the console, but clicking on the offending file/line number just opens the "Source of:..." window. In google chrome I get the file in the debugger, can hit break points, refresh and catch the error as it happens. Better yet, how about a "break-on-exceptions" option that both works but also actually works.
[EDIT]
I finally got the Browser Debugger working. The first error is a NS_ERROR_XPC_BAD_OP_ON_WN_PROTO.

Well, to start actually getting messages you need to set some flags in "about:config" listed here: Setting_up_extension_development_environment
I'll copy a few...
javascript.options.showInConsole = true (this was already on for me)
browser.dom.window.dump.enabled = true
javascript.options.strict = true (there's also a debug version I turned on too)
devtools.chrome.enabled = true (nothing to do with google chrome)
devtools.debugger.remote-enabled = true (the important one, allowing Firefox->Web Developer->Browser Debugger, make sure to allow the remote debugger otherwise it undoes the config change)
devtools.errorconsole.enabled = true
extensions.logging.enabled = true
It looks like quite a few options have been removed too. This has at least got me started.
[EDIT]
This answer also mentions the "Web Developer->Browser Debugger" (which is currently blank - "no sources" - I have no idea) and "Web Developer->Browser Console" windows (just seems to have the same output as the in-window console).

Throw a giant try/catch around ALL your extension code. At least this allows the crossrider "staging" extension to install and be recognised.
Print the exception (I assume all the stupid about:config stuff has to be set for this to work)
appAPI.ready(function($) {
try {
...rest of extension code
}
catch (e)
{
console.log("#################", e);
}
}
Locate the error in the console, and click on the [object exception]. Note the line number (it won't be correct as other code is injected). Also note we've managed to print an exception and firefox failed to break on it. FFFFFFFFFFFFFFFFFFFF
Add some newlines approximately in the middle of the code.
Reload. Note the line number. If it's changed the error is after the newlines. If not the error is before.
Repeat from step 4 until the error is found.
Take a moment to reflect on the stupidity of this process. (this isn't exactly a comment directed at crossrider, more at the severe lack of simple web development tools and APIs currently available)

Firefox Web Console Disabled?

How come I get this message from Firefox Web Console
The Web Console logging API (console.log, console.info, console.warn, console.error) has been disabled by a script on this page
The same webpage can print messages in Chrome Console but not Firefox. I opened the same webpage in another computers' Firefox (don't know what version) Web Console can print messages. My Firefox version is the latest, 8.0.

This happens when the page itself defines a global variable called console, for example. If the page is browser-sniffing to decide whether to define it, the behavior could differ in different browsers.
In the case of Firefox it also happens when Firebug is installed and its console is enabled, since that overrides the default window.console.

I had the same exact error message, and once I removed firebug, it went away.
I'm not saying you should remove firebug, I love firebug, but that is most probably the source of the error for you as well. One more note, the error was still there even if firebug was turned off (disabled) for that particular page.

Here is a JavaScript workaround I used to restore console API after it was set to empty function by a script on the page (works in Firefox 46, tested in Firebug and in greasemonkey script):
function restoreConsole() {
var i = document.createElement('iframe');
i.style.display = 'none';
document.body.appendChild(i);
window.console = i.contentWindow.console;
i.parentNode.removeChild(i);
}
More info and credentials: Restoring console.log()

Right click over firebug console tab and uncheck "enabled" option (the first one).