Chrome 125 in headless mode has the "headless" user agent.

[Ghxst]

Hey, just wanted to report that from my testing on Linux after applying the patch, the user agent will show as

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/125.0.0.0 Safari/537.36

navigator.webdriver will show

false

Wondering if I'm doing something wrong on my end or if the patch isn't applied correctly 🤔 .

Patch output:

root@Ubuntu-2004-focal-amd64-base ~ # fabricbin patch.yaml
Using config: patch.yaml
Input file: /root/./chrome_linux_x64/chrome_original
Patching signature: blink::Navigator::webdriver
  Pattern found at 668ebb0
Patching signature: embedder_support::GetUserAgentInternal headless switch
  Pattern found at 3433e8b
Patched file successfully.

edit: For context if it helps, I am using raw CDP to create a new target and connect to it, I am not using selenium or puppeteer or anything else.

[makindotcc]

Hi, I fixed it. Signature found duplicated instructions and first match was unfortunately wrong It should work now, but I haven't tested it.

[Ghxst]

Thanks! Will test shortly and let you know.

[Ghxst]

Seems to be working, User-Agent is showing as

"User-Agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36",

However it seems I'm still not able to pass the invisible hcaptcha challenge on some websites like shop.app/pay/authentication/login :/

I'll investigate further to see what it could be related to.

[makindotcc]

From my quick look into this website i can tell it probably doesn't detect web browser itself, but rather behaviour like mouse movement, too many retries from same device (ip address), ip reputation (?).

I tried to enter email manually in a flarelessheadlessbrowser and the captcha didn't appear, but when e.g. instead of typing email i pasted it, visible captcha appeared.

[Ghxst]

It's true that input data is captured, however I don't think the Input I am sending through CDP is the issue since my windows based testing box when using headless is never producing a captcha, for now I seem to have it isolated to potentially being related to the operating system / environment.

I'm testing both through the devtools interface at devtools://devtools/bundled/inspector.html?ws= and making sure the headful tests are not polluted by accidental direct Input events.

Could be fonts, could be something else 🤔. My test boxes and browser envs are identical besides operating system, I am passing --disable-webgl and --disable-gpu to both to isolate webgl / canvas fingerprinting as much as possible, both boxes have identical hardware.

If you like to collab or have any other tips let me know, also if you have any more questions about my testing setup let me know too.

[Ghxst]

also @makindotcc you email is visible in the image, not sure if that's unintended so figure I'd let you know. 👀

[makindotcc]

Best way is to tackle hcaptcha javascript and wasm with debugger, console.log etc. JS is not hardly obfuscated (or I missed some additional scripts somewhere, i thought same shit about cloudflares until i discovered they have virtualization based obfuscation in fingerprinting scripts). You can treat wasm as blackbox, because to access any browser APIs from wasm there must be javascript bridge (passed in WebAssembly.instantiate as a second argument). JS functions used by their wasm are in one spot, clearly visible (var Cg = / imports here /):

Or just use captcha resolving service like 2captcha if they support invisible version.

also @makindotcc you email is visible in the image, not sure if that's unintended so figure I'd let you know. 👀

thank you hah, this isn't mine email, i just typed something random 😁

[Ghxst]

We don't want to rely on external solvers but rather have an env that is hardened enough to pass all anti bot measurements as our users are legitimate this should be possible.

I did more testing today with the bare metal boxes we have and they are both failing, even with headful, it seems that somehow hcaptcha is detecting that we're running without a dedicated or integrated gpu, even when passing --disable-webgl and --disable-gpu.

Will do more testing and see if I can snipe some bare metal boxes with intergrated graphic cpus or even dedicated gpus, this is ridiculous though, I have no clue what they are doing but I cannot find any difference in the hcap fingerprints they are collecting, I debugged the JS they load for the challenge and dumped the string table (it's like a jsvm similar to F5/Shape) + values for the APIs they are accessing, if you wanna check for yourself you can set a conditional breakpoint here like this:

Edit: We tried Brave, Chrome, Chromium and Firefox fwiw, all are showing captchas on our bare metal server boxes, the operating systems we tried are Ubuntu and Windows Server 2022, currently the only thing that's passing is my main PC on Windows, and 50/50 Brave through WSL2, everything in my Windows VM is passing as well (no gpu passthrough). To make sure IP wasn't the issue we made sure to have the same exit IP (both TCP and UDP) on all boxes.

[Ghxst]

Got a box with an intel CPU that has a integrated cpu, still seeing captchas on windows server 2022 standard, gonna move that OS to my local box and see if it's an OS thing, also probably need to install proper display drivers on the intel box.

Edit: Locally same OS is working, I tried install graphic drivers on the remote intel box and it's still showing captchas, kill me. 😢

[Ghxst]

Still not been able to beat this lol 😭, had brief success with integrated gpu but my boxes are still getting captchas. @makindotcc if you feel like you could beat this issue and work with us (paid ofc) hit me up (petwanties on discord).

[makindotcc]

Sorry, I'm too busy for next months now 😔