Automation markers

What the payload says about you when a driver is present. Measured by planting one marker before any page script, decoding the first payload, and diffing it against a clean run, with addresses that also move between two identical clean runs dropped as noise.

The 32-bit mask

Generation 2 reports the whole automation set as one integer at -115[28]. Generation 3 reports it as signals. One bit per marker:

Bits 3 and 4 were not triggered by any marker planted so far, so two names in the build's own list are still unaccounted for. fmget_targets came back as value 2, the same bit as the ChromeDriver _Array name; either it shares a bit or that single run was noise.

Note that the mask is emitted as a signed 32-bit integer, so bit 31 appears in a payload as -2147483648.

Markers with their own fields

Several things report outside the mask, in more than one place at once:

The generation 3 equivalents are named rather than positional: din.wdr for navigator.webdriver, din.pha for _phantom, din.dau for domAutomation, sde for the $cdc_ probes on both window and document, din.npl for the plugin count and din.adp for the marker list.

How it is detected: the same fact is reported through two or three independent addresses. Hiding navigator.webdriver while leaving window.webdriver set, or the reverse, produces a payload that contradicts itself, which is a stronger signal than either flag alone.

Planting watinExpressionError moves more than one field

One marker in the sweep moved the pointer event log as well as the mask: with it installed, -102 went absent and -109 gained five fields. That is worth knowing because it means the mask is not the only consequence of a marker, and a diff limited to -115[28] will under-report.

What did not move anything

window.driver, window.selenium, a patched Function.prototype.toString, a replaced Navigator.prototype.vendor getter, a Proxy-wrapped userAgent getter, a patched navigator.permissions.query, a deleted window.chrome, an emptied navigator.languages and hardwareConcurrency of 1 all produced nothing outside the noise on the property tested.

Read that carefully. It does not mean those are undetectable. The build holds stripProxyFromErrors and the string at newHandler.<computed> [as apply], and it calls Function.prototype.toString 34 times per load. It means those checks either report through a field that also moves on its own, or feed a verdict this property never acts on, or run on a path a monitoring configuration does not reach.

The mask is not what gates

Setting the automation mask by hand in an otherwise correct payload and sending it to two production endpoints that do gate on the payload: both served the request. One is a login POST that refuses a payload with a moved key, and it serves the same payload with the automation mask set.

So on the endpoints measured, the payload check is "does this decode into a coherent session", not "does this session admit to being automated". The mask is collected and reported; it is not what the gate reads. That may be scoring rather than gating, and a property configured differently may well act on it.