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
Related
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.
There is a certain Chrome extension and I want to get a PNG file from it by XMLHttpRequest. If the extension is enabled, I want to write 'load' to the console, and if the extension is disabled, I want to write 'error' to the console.
It works fine, but if the Extension is disabled, Chrome writes an error in the console that I do not want to appear:
How can I remove this error from the console?
(I have tried window.onerror but it doesn't work)
The code:
var loadHref = function(href) {
var xmlhttp = new XMLHttpRequest();
xmlhttp.onload = function(){console.log('load')};
xmlhttp.onerror = function() {console.log('error');};
xmlhttp.open('GET', href);
xmlhttp.send();
}
loadHref('chrome-extension://77672b238520494cba8855547dd00ba8/img/icon24.png');
Basically, you can't silence those errors, as they are not JS errors but network errors.
Assuming your goal is to detect that a specific extension is present:
Assume you need it at a specific domain and for a specific extension that is controlled by you.
In this case, the optimal approach is externally_connectable communication. Here's a sample.
Assume you need it at a non-specific domain not known in advance, but you control the extension.
In this case, a Content Script can be injected (probably with "run_at": "document_start") and add something to the document signalling the presence of the extension. For example, injecting a page-level script that sets a variable.
Assume you don't control the extension.
Well, in that case you're screwed. If an extension won't cooperate in the manners described above, probing its web-accessible resources (if any!) is the only way to detect it, short of watching for specific content script activity in the DOM (again, if any).
Actually, there is already an existing issue on error when chrome cast extension is not installed with google-cast-sdk and based on that issues tracker, this hasn't been totally resolved yet. There are, however, given workarounds from one of the comments:
the workarounds would be to either install the Google Cast extension or disable network warnings (please note you may miss some warnings that could be on interest to you) so you don't see these additional logs.
And, you may also try with the probable solutions given in this SO post - Google chrome cast sender error if chrome cast extension is not installed or using incognito and who knows, it might help. :)
I'm using IE9 to debug a web app. I made some changes to the javascript after loading the page. I'm not able to get IE9 to stop on the new code. The message is "The code in the document is not loaded". I can set breakpoints when I'm not debugging, but they won't be valid when I start debugging. I'm using IE7 Browswer Mode, IE7 Document Mode.
Things I've tried:
close dev tools window, re-open
stop debugging, start debugging
Ctrl R in dev tools window (same as Clear Browser Cache button)
Ctrl R on the IE9 web page
Ctrl F5 on the Ie9 web page
Clear browser cache for this domain
Check (set) Always refresh cache from server
Next thing to try (I guess) would be closing IE completely. Is that the fix for this? If so, yuck. It takes me a couple of minutes to set the page up so doing that after every JS change really stinks. I can use FF4 to develop the JS, but the JS issue I'm seeing is specific to IE7 so I have to do it this way.
>> How can I get IE9 (running in IE7 mode) to reliably debug the most current JS from the server?
This issue wasn't related to caching etc. IE9 was hitting a script error (missing closing paren) in the new code and not allowing breakpoints anywhere in the script. IE seemed very quiet about the script error though. Anyway, fixing the script error fixed the issues with breakpoints / caching.
If you have access to the code:
In you javascript file reference add a query string, something like this:
<script src="Scripts/main.js?v=1" type="text/javascript"></script>
And every time you change in the js file change the v value to something else, like that the browser will feel that this is a new file and will get it.
Add this:
window.applicationCache.addEventListener('updateready', function (e)
{
if (window.applicationCache.status == window.applicationCache.UPDATEREADY)
{
window.applicationCache.swapCache();
if (confirm('A new version of this site is available. Load it?'))
window.location.reload();
}
}, false);
I found this solution somwhere in the Net. Sorry, but I don't remember the author. It works for me when I debug Web App with JavaScript in Visual Studio and use IE.
I found this question based on the "the code in the document is not loaded" error message. I'm not using IE7 document mode or any of that, just IE9.
Like jcollum, my issue wasn't related to caching.
I'm using MVC.Net, and someone had set up a piece of javascript to rely on a string in the ViewBag. I changed a couple things, and that ViewBag string disappeared, so the resulting javascript looked something like this:
if(!()) {
// Some code
}
Javascript died right here, and wouldn't process the rest of the code in the block. This was confusing, as it was still trying to execute javascript in a different set of script tags, but which relied on a variable set in the other block it wouldn't load.
So, basically, a syntax error was introduced via strange means, and the debugger refused to load some of the code which came after it. Another lesson on the dangers of ViewBag.
Hey guys --
The website I'm working on requires a bookmarklet launchable from your bookmark toolbar.
I've noticed that some browsers are blocking my bookmarklet.
However, similar bookmarklets such as Tumblr's, Twitter's, and Delicious' have workarounds where their bookmarklet pages are not getting blocked.
My current launch script looks like:
javascript:void(window.open(%22http://mywebsite.com/share/form?
u=%22+encodeURIComponent(location.href)+%22
&t=%22+encodeURIComponent(document.title),
%xz%22,%22status=0,toolbar=0,location=0,menubar=0,resizable=false,scrollbars=false,height=379,width=379%22));
It's a simple window.open, which is clearly not enough to handle certain exceptions
The sites, below is Delicious' launch script, all seem to have workarounds that look very similar to that of below:
javascript:(function(){
f='http://www.delicious.com/save
?url='+encodeURIComponent(window.location.href)+
'&title='+encodeURIComponent(document.title)+
'¬es='+encodeURIComponent(''+(window.getSelection?window.getSelection():document.getSelection?document.getSelection():document.selection.createRange().text))+
'&v=6&';
a=function(){
if(!window.open(f
+'noui=1&jump=doclose','deliciousuiv6','location=yes,links=no,scrollbars=no,toolbar=no,width=550,height=550'))
location.href=f+'jump=yes'};
if(/Firefox/.test(navigator.userAgent))
{setTimeout(a,0)}else{a()}})()
It seems like they append some extra GET parameters to the URL if the user agent is firefox.
I'm assuming then, if that is the case, that the init scripts on the actual page loading from the bookmarklet handles this exception somehow?
Has anyone had any experience with this issue? Would you be able to point me to any resources or tips? I have been stuck with this roadblock for sometime now.
Thanks in advance
the delicious bookmark does not directly invoke the window.open() - it creates a function (called a in there) which is then executed in a setTimeout(a,0) for firefox (i assume the problem you have is in firefox).
You can try a similar method, and see if it works for you.
I'm trying to figure out why something with Javascript isn't working inside of a UIWebView. To my knowledge, there is no way to set a breakpoint inside of XCode for a js file. No problemo, I'll just go back to 2004 and use alert statemen-- oh wait they don't seem to work inside of a UIWebView either!
The only thing I could think of is by exporting my HTML And JS files to my desktop and then just doing my debugging inside of Safari. And that works! But of course, the bug I'm fighting with in the UIWebView doesn't occur in Safari.
Are there any other ways for debugging inside of a UIWebView, or any tricks that I can use akin to using the old-school alert method?
If you're using iOS >= 6 and you have mountain lion (10.8) or Safari >= 6, you can just:
Open the application in the simulator (or your device in XCode >= 4.5.x).
Open Safari (go to Preferences -> Advanced and make sure "Show Develop Menu in Menubar" is on.
From the Menu-bar (of Safari) select Develop -> iPhone Simulator -> [your webview page].
That's it !
This query tops google, so worth linking to the remoteInspector hidden in iOS5 - by far the best way found so far to debug your UIWebViews - just conditional compile out before you send to Apple.
alert() certainly works for me.
However, you can also do lots of other things, like make your own DHTML alert that pops up in a layer. This can be nice because you can do multiple alerts to a single div, without stopping your app. You should also be able to write a stack trace to it (the stack trace is in the exception object, and you can always throw your own exceptions).
Alternatively, if running on the simulator your custom "alert()" could call into objective C, and display the string in the iPhone simulator's console window:
document.location.href = "http://debugger/" +
encodeURIComponent(outputString);
and on the objective C side:
//--------------------------------------------------------------------
- (BOOL)webView:(UIWebView*)webView
shouldStartLoadWithRequest: (NSURLRequest*)req
navigationType:(UIWebViewNavigationType)navigationType {
if ([[[req URL] host] isEqualToString:#"debugger"]){
// do stuff with [[req URL] path]
}
}
That said, I have an app that is heavy on the UiWebView / javascript stuff, and I tend to do most javascript dev in Chrome (simulating what is necessary from the iPhone environment)
I get the awesome way to debug UIWebView Or
SFSafariViewController.
I hope It will Help.
Step 1:
Open Safari VC In Your Mac (hahaha Don't make your face, If I am saying in your Macbook just follow this my steps)
Step2: Go at Safari preferences And Click on Advance.
You will Get this setting on your MacBook Screen.
Now enable the Show to develop menu in menu bar.
Now Your All work is done.
Are you thinking I am kidding :P :P no man...
Step3: Run your application in Device or Simulator. (Don’t Think Just run )
And go in your application where you are opening your Webview or SFSafariViewController.
Till now you did not understand I know. Be cool and see my next step.
Step4: Open Safari In your MacBook and Click on Develop Option from the Menu bar.
Did you get something your MacBook, iPad/ iPhone is Displaying Right?????
Step5: Its Done. click your device and click on URL New popup will come out like This.
Step6: what are you looking now its over here all the steps.
Now debug your Webpage on this console.
Be happy and enjoy your day while doing coding With a cup of tea or
Coffee.
IMP: Don't forget to enable See Below Image
I haven't tried this yet, but take a look at this Weinre
Looks very promising.
This is an old question. But I'll still like to share my two cents.
I have been using jsconsole.com for remote debugging. It's easy. Just include a script tag and use console logs to debug by printing. This can also be used for debugging on a real device.
Old question, but I think I found the best solution, in my case you need to debug uiwebview, but I had no access to the IOS app and only to the html content and I had to view some JS logs, I added the following code to load the light firebug JS and show it automatically:
calling it from JS
var script = document.createElement('script');
script.type = 'text/javascript';
script.src = 'https://getfirebug.com/firebug-lite-debug.js';
document.head.appendChild(script);
or load it from html
<script type="text/javascript" src="https://getfirebug.com/firebug-lite-debug.js"></script>
You can set up a system like that used in PhoneGap to send messages from JavaScript to Objective-C and log from there. In a nutshell, they are setting document.location with a custom scheme and blocking that scheme in the delegate callback.
You can take advantage of the fact that a UIWebView is most of the delegates for a WebView. WebKit is technically undocumented for iPhone, but mostly the same as specified in the desktop WebKit headers, possibly including the WebScriptObject. I use this for debugging, but be sure to strip this code out before submitting to Apple.
To get a WebView from a UIWebView, implement a delegate method like -(void) webView:(id)inWebView didFinishLoadForFrame:(id)inWebFrame in a subclass of UIWebView. Call super if you use that one.