3.detectStackTrace doesn't seem to be working!

[dpnishant]

Running phantomjs hsloader 3.detectStackTrace.html doesn't return anything.
Tested it on PhantomJS 2.1, 2.0 and 1.9.8
https://github.com/ikarienator/phantomjs_hide_and_seek/blob/master/3.detectStackTrace.html

[shekyan]

@dpnishant our testcases are organized as pair of files:

• x.detectxxx to show how typical detection would be implemented on the webpage.
• x.spoofxxx to demonstrate how some browser property can be spoofed and how detection will fail.

In case of stack trace detection, our point was that it is not possible to spoof the stack trace without recompiling phantomjs, therefore there is no corresponding 3.spoofStackTrace.html file.

[dpnishant]

Hi @shekyan,

I understand your point and that's exactly how I have tested other cases. All of them are working as expected (both detection and spoofing) except this one. Running this one doesn't return any output and sort of "hangs".

And also 5.detectMissingFunctionBind.html returns "environment not detected" every time.

Refer to the attached screenshot.

[shekyan]

Just created #3 that might help to understand stacktrace detection.
run
./hsloader 3.detectStackTraceEmpty.html 3.spoofStackTrace.js

to see how querySelectorAll('div') returns the right thing, and run
./hsloader 3.detectStackTrace.html 3.spoofStackTrace.js

to see how detection code returns html element instead of divs.

[shekyan]

@dpnishant regarding detecting missing bind() . That detection works only in PhantomJS version < 2.0, which doesn't implement native bind(). PhantomJS 2.0 and up uses WebKit that implements native Function.prototype.bind .

[dpnishant]

Wow! That was fast. It is working flawlessly now. Thank you so much @shekyan 👍

[dpnishant]

Hey @shekyan What am I doing wrong in here: http://pastie.org/10708473 that it says "PhantomJS detected in all browsers?" How is this test then specific to only Phantomjs?

[shekyan]

@dpnishant I would recommend reading the blog post or watch the presentation. Slides or the actual presentation.

Key paragraph in the blog post on this is:

Errors thrown by JavaScript code evaluated by PhantomJS via the evaluate command contain a uniquely identifiable stack trace, from which we can identify the headless browser.

Calling honeypot querySelectorAll from the webpage's JS context is not going to reveal PhantomJS stacktrace. It needs to be done by PhantomJS itself through evaluate() in order to work properly.

The real life scenario is that if you know that somebody is doing something with your website with PhantomJS and, for example, is calling querySelectorAll, you can feed it overloaded version of it which will detect the stacktrace.

[dpnishant]

Thanks @shekyan for being so patient! 👍 I did watch the youtube talk, read the slides and the blog which is how I got know this repository exists. I read the code as well and it somewhat seems confusing to me that if I "know" someone is using PhantomJS why would I again need to "know" it by detecting the stack-trace. To me this seems to be more of a false positive reduction technique may be combined with User-Agent method to be double-sure. But it comes with a cost that this can cause a FP for all other browsers.

Is my understanding right, Sergey?

[shekyan]

The idea is to have a honeypot DOM API that preserves it's original behavior if called by a legitimate browser and reports a phantomjs AND maybe does something to prevent phantomjs from functioning properly. Original example was reading a local file (/etc/passwd as example) and sending it somewhere. That'd be possible if same origin policy is disabled, which is a requirement by many frameworks that use phantomjs.

Another point is that it is not possible (without heavily modifying webkit's JavaScriptCore code) to make phantomjs stack trace to look like a real browser's stacktrace, while most of the other techniques people use to identify phantomjs can be relatively easily bypassed.