We burn every anti-detect browser and choose the worst one

[Man]

An interesting technical article on the topic of antidetect browsers (list), about how they work and what they are detected on. The author took 4 browsers for review: Linken Sphere, AntBrowser, Aezakmi and Indigo (aka “multilogin”), he went over the surface and did not get into the depths of antidetect, but it is interesting for general development. In any case, everything needs to be compared.

Content
1. Introduction
2. First the theory
3. Dive
3.1. Indigo
3.1.1. What is it burned on?
3.2. Linken Sphere
3.2.1. What is it burned on?
3.3. AntBrowser
3.3.1. What is it burned on?
3.4. AEZAKMI
3.4.1. What is it burned on?
4. Conclusion

Introduction​

We all asked ourselves the question “which anti-detect browser should I choose?” and, most importantly, “how should I choose?” The problem is that due to the high complexity of emulating someone else’s system, all anti-detect browsers are exposed.

In this post I will tell you and show you with examples, reasonably, without speculation and theories, how they burn out, how to minimize the fuse, and I will give you a minimal idea of the structure of each of them, so that you can choose for yourself.

So, we have all four top browsers on our operating table today:

Linken Sphere, AntBrowser, Aezakmi and Indigo (aka “multilogin”).

All the browser developers are great guys and kindly agreed to provide me with a demo, but in vain.

First the theory​

1) Each anti-detection browser is based on a regular browser engine. As a rule, this is Chromium or Firefox. The fundamental differences in the internal structure of the engines are so great that with the help of javascript on the page, the site can always determine in which engine the site page we are viewing is actually loaded. This means that anti-fraud knows whether your browser is based on IE, Chrome or FF.

Examples:

• Only IE has support for ActiveX, objects Debug, and dozens of others document.security,navigator.cpuClass
• only FF and Safari have MathML support,
• only chrome has shape detection api,
• only Chrome and FF support the webM codec in the tag video,

And this list can be continued indefinitely. There are so many differences that a separate site has appeared for developers http://caniuse.com/, allowing you to check whether a particular functionality is supported in different browsers.

Hence the first rule of working with the anti-detect browser:

Use the UserAgent that matches your anti-detect engine.

For example, if your antidetect is made on Chromium, and your OS is a Mac, then use the most common UserAgent of Chrome on Mac, for exampleMozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36

2) The hardware should not be unique. It should be “the same as everyone else’s”.

The characteristics of your PC's hardware are reflected in the following fingerprints:

• Canvas simple (2d) - with assumptions is not unique within each version of each OS. Differences in prints are due to differences in font smoothing mechanisms in different operating systems.
• WebGL (aka Canvas-3d) – in this case, the image is drawn directly through the video card (if 3D acceleration support is enabled in the browser and in the OS/virtual machine), and inside the browser by its built-in renderer (if 3D acceleration support is unavailable in the OS or disabled in the browser), not unique for each combination of “OS+video card+video card driver” if there is 3D acceleration support, and not unique for each combination of “browser+OS” if 3D acceleration support is absent/disabled. In the sample of 1kk US traffic at the time of writing, 16% of users did not have 3D acceleration support on their PCs.
• Audio – is not unique within each version of your device's audio chipset.

There are no other ways to identify your hardware via a desktop browser, such as finding out the serial number of your hard drive or processor or the color profile of your monitor. On mobile devices, the accelerometer (and its calibration data) is added to the list, but that's a topic for a separate article.

Those who want to delve deeper into the theory can watch a presentation by a Google developer https://elie.net/publication/picasso-lightweight-device-class-fingerprinting-for-web-clients/ (eng) about a fingerprint based on WebGL, used in ReCaptcha, among other things.

The less unique each of these fingerprints is, the less questions there are about your device, because it is “the same as everyone else.” None of these fingerprints allow you to uniquely identify your device, but they allow you to conditionally determine its “class” (for example, “PC with discrete video,” or “phone, probably iPhone”). And the best way to keep these fingerprints believable is not to touch them. No joke.

The second rule for working with an anti-detect browser:

Don't touch your iron prints

3) When we use a proxy from another country, the question inevitably arises about changing the displayed language, time zone, and possibly a set of fonts corresponding to your locale (in case of working with Asian markets)

There are three main ways to replace the values of languages, time zones, screen resolutions, etc. returned via JavaScript in the browser:

• rewrite these functions in the browser's source code, before it is compiled. This is the most reliable and the most difficult to detect method.
• inject into the running process of the tab and intercept calls to the necessary functions in real time. Technically difficult, because the offsets and addresses of the functions float with each browser update.
• rewrite the values we need directly on the page via javascript, after initializing the page we are viewing. The easiest to implement, but the most disgusting way, because it is really difficult to do this unnoticed. As I will show further, almost all anti-detect browsers chose this path, which set up their users.

The third rule of anti-detect browser:

Do not touch or modify anything on the page/site via javascript

Let's turn to theory again to understand how a website/anti-fraud can determine that browser parameters have been substituted via javascript.

Most often we need to replace the OS language so that it matches the user's location. In addition to being passed to the site in the header Accept-Language, it is available to js through the variable navigator.language.

The properties of the navigator object cannot be simply overwritten, because they are read-only. Read-only objects in JavaScript are traditionally implemented by creating an empty setter and a non-empty getter for the object, returning the desired value. Therefore, we always have the opportunity to overwrite such objects by calling Object.defineProperty:

We can assign a to a mutable object value, or we can attach our own to it getter, overwriting its native one, and thus preserving the “native” read-only behavior of this object:

Voila, we have replaced the value we needed. But what could have gone wrong?

Everything. Everything went wrong, Natasha.

Initially, such objects as navigator, screenand some others do not have their own properties, but inherit all the properties from the constructor of the older brother (objects Navigatorand , Screenrespectively). And a call Object.definePropertyon any of these objects creates their own properties:

Thus, any site/antifraud simply by calling one line of code

if( Object.getOwnPropertyNames(navigator)[0] ) alert('fake parameters detected');

can determine that our browser parameters are fake. And at that moment all the sophisticated protections and emulations become useless.

Let's dive​

Now that we have decided where we will look, let's move on to our kittens. To create profiles, I chose default settings, without a proxy, with the minimum possible substitution of fingerprints and environment variables (screen, color, shit)

Indigo​

A variant based on Chromium, codenamed “Mimic”.

The most solidly built browser of all, and also the only browser in which parameter substitution is implemented in the source code, and not through js.

Nothing sticks out anywhere, nothing is exposed, except...

What is it that gets caught on?
1) The http3 protocol, which has been available in Chrome by default since 2013, is disabled. Each site sees the connection type and protocol (http1.1, h2 or http/2+quic, also known as http3) that it is accessed through. And if a site that supports http3 is accessed from Chrome, but via http2, then either this access is through a proxy, or it is not real Chrome. Both the first and second conclusions made by the anti-fraud system are bad for us.

2) When rendering text, the Times font is used as a monospace font, which is not monospace. In the wild, this is impossible and is an obvious sign of font substitution. A monospace font is one in which the width of all characters (for example w, and i) is the same, for example Courier new. According to the specification, when specifying an element in styles, font-family: monospace;the browser must take one of the available monospace fonts (at least one such font must be available in the system).

the difference is visible even to the eye

A site can determine a font mismatch by drawing it on a canvas and measuring whether the width of the symbol 'and matches w, for example. You can see the difference yourself in the screenshot above. In the case of Indigo, any site (and antifraud) can see that a fake font is used, not the native system font.

That's all for Indigo.

Linken Sphere​

Chromium-based antidetect. The most expensive of all, and the most advertised. People come to interviews in “People-Pro” in his hoodies, and he is promoted in the magazine “Hacker”. It was last updated on 13/09/2019 (half a year ago) and here is where the disgrace begins.

What is it that gets caught on?
1) In fact, it is based on Chromium from ~2018:

which means we're not only missing out on unnecessary things like support for apng, VP9, and AV1 codecs, but we're also open to a ton of vulnerabilities that have been fixed in Chrome over the years.

2) Just like in Indigo, http3 support does not work.

3) All parameters are faked after page initialization using javascript, and any site can see it (using the method I described above):

what can you say...

Lousy. But can it get any worse? Let's see.

AntBrowser​

Antidetect based on FF, positioning itself as a tool for working with Russian services such as Avito and Yula.

What is it that gets caught on?
1) Since the browser is based on FF, all attempts to introduce themselves as Chrome will fail, due to the difference in the design of the engines. The presence of a variable window.chromeis just such an unsuccessful attempt. The page simultaneously contains an object window.chromeand objects sidebar, screen.mozLockOrientation, navigator.oscpu, which clearly indicate that the browser engine is FF

2) Just like in Indigo, a mince of fonts is used. And a regular font is used instead of a monospaced one:

3) All variables on the page are replaced via javascript:

The developer tried to fix the situation, and replaced not the properties of the object itself navigator, but the properties of the prototype of its constructor navigator.constructor.prototype. And this would have worked if their getters did not contain tens of kilobytes of obfuscated code, which is available to every site/antifraud.

4) On each page in the dom tree, <html>a parameter is added to the tag, which indicates that the AudioContext Fingerprint Defender data-acxscriptallow="true" browser extension is running on the page. That is, the code for this extension was scraped and added to the antidetect “as is”.

Can it get any worse?

AEZAKMI​

Antidetect based on chromium. Positioned as “Cheat Code for Your Anonymity”.

At the start, when creating a profile, the developers try to keep us from being able to leak real webGL fingerprints by only allowing the creation of a profile with 3D acceleration disabled:

“ANGLE” in the name indicates the lack of 3D acceleration support in the browser

But that's where the good news ends.

What is it that gets caught on?
1) The browser out of the box launches with the –disable-web-security flag . This is as bad as it can get.

Running Chrome this way not only disables CORS, but also gives sites access to local files on your disk.

Any site can access, for example, facebook.com and get all our data, or request any files from our disk, such as a telegram session file or a Skype chat history.

2) just like in the case of AntBrowser, on each page <html>the parameters data-cbscriptallow="true"and are added to the tag data-acxscriptallow="true", which indicate the presence of code from extensions for spoofing canvas and audio fingerprints.

3) The plugin array is forged crookedly and does not have a field of its own length:

This clearly indicates that the plugin list is fake.

4) On each page, the entire current browser profile config is placed in the global variable webglResponseStr:

There is no reason in one's right mind to do this.

These data include, among other things:

• name of the current profile
• your login on the AEZAKMI website
• All data on the proxy used: proxyIp, proxyPort, proxyUser, proxyPassword in clear text.

And any site you open in this antidetect has access to this data.

To sum it up, AEZAKMI is a suicide booth priced at $70 a month.

Conclusion​

Is everything really that bad in the anti-detect market? Yes, at the moment, everything is certainly lousy.

Such an irresponsible attitude of most anti-detection developers to their clients and their material is not what the industry needs. The market needs knowledge, transparency and competition. In my heart, I expect that more players will appear who are guided by the principle “do it right – it will be right”, and not “it will do”.

“So what antidetect should I use?” My answer is “none”, but…

…the convenience that comes with managing dozens of profiles from one program is appealing, and if you still need an anti-detect browser, for now take Indigo – with some exceptions, you won’t be ashamed of it.

Source