Anonymity Check each AntiDetect browser and choose the worst one

An interesting technical article on the topic of antidetect browsers (list), how they work and what they burn. For the review, the author took 4 Linken Sphere browser (10% discount for CPARIP promo code), AntBrowser, Aezakmi (15% discount for CPARIP promo code) and Indigo (aka "multilogin"), he went to the top and did not get into the depths of the antidetect, but interesting for general development. In any case, everything must be compared.

Content
1. Introduction
2. First the theory
3. Diving
3.1. Indigo
3.1.1. What is firing on
3.2. Linken sphere
3.2.1. What is firing on
3.3. AntBrowser
3.3.1. What is firing on
3.4. AEZAKMI
3.4.1. What is firing on
4. Conclusion

The information provided in the article about the Aezakmi browser turned out to be incorrect.

Introduction
We all wondered “which antidetect browser to choose?", And, most importantly, "how to choose?" The problem is that in view of the high complexity of emulating a foreign system, all antidetect browsers are scorched.
In this post I will tell you and, using examples, reasonably, without conjectures and theories, I will show how they burn, how to minimize the fuse, and 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 the operating table today:




Linken Sphere (10% discount for CPARIP), AntBrowser, Aezakmi (15% discount for CPARIP) and Indigo (aka “multilogin”).
All browser makers are great guys and have kindly agreed to provide me with a demo, but in vain.

Theory first
1) Each antidetect browser is made on the basis of a regular browser engine. This is usually 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 page of the site that we are viewing is actually loaded in. This means that the anti-fraud knows if your browser is based on IE, chrome or ff.

Examples:
  • Only IE has ActiveX support, facilities Debug, document.security, navigator.cpuClassand dozens of others,
  • only FF and Safari have MathML support,
  • only Chrome has a shape detection api,
  • only in Chrome and FF there is support for the webM codec in the tag video,
And the list is endless. There are so many differences that a separate website http://caniuse.com has appeared for developers, allowing you to check whether this or that functionality is supported in different browsers.

Hence the first rule for working with an antidetect browser:
Use the UserAgent corresponding to your antidetect engine.
For example, if your antidetect is made on Chromium, and your axis is a Mac, then use the most common UserAgent of Chromium on a Mac, for example Mozilla/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) Iron does not have to be unique. It should be "the same as everyone else."

The hardware characteristics of your pc are reflected in the following prints:
  • Canvas simple (2d) - with assumptions, is not unique within each version of each OS. The differences in prints are due to the difference in font smoothing mechanisms in different operating systems.
  • WebGL (aka Canvas-3d) - in this case, the picture 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 in the os is not available, or disabled in the browser), is not unique for each combination "os + video card + video card driver" in case there is support for 3d acceleration, and is not unique for each combination of "browser + os" if support for 3d acceleration is absent / disabled. On a sample of 1kk US traffic at the time of this writing, 16% of users did not have support for 3d acceleration 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 through the browser on the desktop, for example, to find out the serial number of the hard drive or processor or the color profile of the monitor. On mobile phones, an accelerometer (and data on its calibration) is added to the list, but this is a topic for a separate article.

Those wishing to delve into the theory can watch the presentation of the Google developer Picasso: Lightweight Device Class Fingerprinting for Web Clients (eng) about the WebGL-based fingerprint, used in ReCaptcha.

The more not unique each of these prints, the fewer questions to your device, tk. it is "the same as everyone else." None of these fingerprints uniquely identify your device, but it allows you to provisionally define its "class" (for example, "PC with discrete video", or "phone, probably an iPhone"). And the best way to keep these prints believable is to leave them alone. No kidding.

The second rule for working with an antidetect 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 the case of working with Asian markets)

There are three main ways to change the values of languages, time zone, screen resolution, etc., returned via javascript in the browser:
  • rewrite these functions in the source code of the browser, before compiling it. This is the most reliable and most difficult to define method.
  • inject into the working process of the tab and intercept calls to the desired functions in real time. Technically difficult, because offsets and function addresses float with every browser update.
  • overwrite 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 it unnoticed. As I will show later, almost all antidetect browsers have chosen this path, by which they framed their users.
The third rule of the antidetect browser:

Do not touch or modify anything on the page / site via javascript
Let's go back to theory to understand how a site / antifraud can detect that browser settings have been tampered with via javascript.

Most often, we need to change the language of the os to match the user's location. In addition to being passed to the site in the header Accept-Language, it is available to js through a variable navigator.language.

2.png



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-a and a non-empty getter-a that returns the desired value. Therefore, we always have the opportunity to overwrite such objects through a call Object.defineProperty:

3.png



We can assign to the mutable object value, or we can hang our own on it getter, overwriting its native, and thus preserving the "native" read-only behavior of this object:

4.png



Voila, we changed 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 properties from the constructor of the older brother (objects Navigatorand, Screenrespectively). And a call Object.definePropertyon any of these objects creates their own properties:

5.png



Thus, any site / anti-fraud simply by calling one line of code

Code:
if( Object.getOwnPropertyNames(navigator)[0] ) alert('fake parameters detected');
Can determine that our browser settings are fake. And at this moment all the fancy protections and emulations become useless.

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

Indigo
A variant based on Chromium, codenamed "Mimic".
The hardest-hit browser of all, as well as the only browser in which the substitution of parameters is implemented in the source, and not through js.
Nothing sticks out anywhere, nothing burns, except ...

What is firing on
1) Disabled http3 protocol, which is available by default in chrome since 2013. Each site sees the type of connection and the protocol (http1.1, h2 or http / 2 + quic, aka http3), through which it is accessed. And if a site that supports http3 is accessed from chrome, but via http2, then either this request goes through a proxy, or it is not real chrome. Both the first and second conclusions drawn by the anti-fraud system are bad for us.

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

6.png



the difference is visible even by eye

The site can determine the mismatch of the font by drawing it on the canvas, and by measuring whether the width of the symbol 'and w, for example , match . 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 being used, not the native system font.

That's all with Indigo.

Linken sphere
Chromium-based antidetect. The most expensive of all, and the most advertised. In his sweatshirts they come for interviews in "People-Pro", and they advertise him in the magazine "Hacker". It was last updated on 09/13/2019 (half a year ago) and here the disgrace begins.

What is firing on
1) In fact, it is built on the basis of chromium from ~ 2018:

1-1.png



Which means that we are not only deprived of unnecessary things, such as support for apng, VP9 and AV1 codecs, but also open to many vulnerabilities that have been fixed in chrome over the years.

2) As well as in Indigo, http3 support does not work.

3) All parameters are faked after the page is initialized with javascript and any site can see this (using the method I described above):

2-1.png



what can you say ...

Lousy. But could it be worse? We'll see

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

What is firing on
1) Since the browser is based on FF, all attempts to pretend to be chrome will fail, due to the difference in the engine design. Having a variable window.chromeis just such a failed attempt. At the same time the object is present on the page window.chromeand objects sidebar, screen.mozLockOrientation, navigator.oscpuwhich clearly indicate that the browser engine - FF

3-1.png



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

8.png



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

9.png



The developer tried to correct 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 it would have worked if their getters did not contain tens of kilobytes of obfuscated code that is available to every site / antifraud.

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

Can you make it worse?

AEZAKMI
Chromium-based antidetect. Positioned as "Cheat Code for Your Anonimity".
At the start, when creating a profile, the developers try to keep us from being able to merge real webGL prints, allowing only the creation of a profile with disabled support for 3d acceleration:

10.png



"ANGLE" in the title indicates the lack of support for 3d-acceleration in the browser

But the good news ends there.

What is firing on
1) The browser is launched out of the box with the --disable-web-security flag. This is as bad as it can be.

11.png



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

Any site can go, for example, to facebook.com and get all our data, or request any files from our disk, such as a telegram session file or a history of correspondence in skype.

12.png


2) just as in the case of AntBrowser, on each page <html>, 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 prints.

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

13-1.png



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:

14.png



There is no reason to do this in a sober mind and sound memory.

This data contains, among other things:
  • name of the current profile
  • your login on the AEZAKMI website
  • All data on the used proxy: proxyIp, proxyPort, proxyUser, proxyPassword in clear text.
And any site that you open in this antidetect has access to this data.

In summary, AEZAKMI is a suicide booth, priced at $ 70 per month.

Conclusion
Is everything really that bad on the antidetect market? Yes, at the moment, absolutely everything is lousy.
Such an irresponsible attitude of the majority of antidetect 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 there will be more players who are guided by the principle “do it right, it will be okay”, not “it will do just that”.

"So what kind of antidetect should I use?" My answer is "none", But ...

... the convenience brought by the management of dozens of profiles from one program is captivating, and if you still need an antidetect browser, at the moment take Indigo - with some assumptions you will not be ashamed of it.

In the next article I will tell you about the Facebook antifraud system and show it using the example of "How to build your own antidetect to work with FB for free without registration without SMS", which is guaranteed to work as you expect from it.

See you soon.
 

stackv000

Newbie
Joined
31.01.22
Messages
1
Reaction score
0
Points
1
Man, what an absolutely shitty article.... To read. Great work on covering this. It was very interesting to read and thorough. It's uncommon to find new information or something so honest all around.
Appreciate your post!
 

Mr.Normal

Newbie
Joined
24.02.23
Messages
6
Reaction score
2
Points
3
This is very good article, many people don't understand how many different things get queried for device fingerprint. I'd also note from experience that Linken Sphere is detected more and it's bypass rate has fallen, I don't know how antifraud is able to detect it now though.
 

SMSvTelegram

Newbie
Joined
12.02.23
Messages
4
Reaction score
0
Points
1
Bravo for such a detailed review. I read it with pleasure. The main thing is that the information is still up to date
 
Top Bottom