‘For every technical problem that arises, there must be a technological solution.’
Background
Assuming a project launches a 'Click to Get $1' campaign, the rules are as follows:
❶ Visit the website to receive rewards
❷ Each user can claim only once
❸ Identify and ban multiple accounts
Think about it, if you were the project team, how would you handle the multi-account users?
1️⃣ Round One: Basic Attack and Defense
The project team's initial defenses
① UA+IP Dual-factor Identification: Bans accounts based on the combination of UA (User Agent is a string sent in requests to inform the server about the client type, version, operating system, etc.) and IP address.
Cracking Strategies
❶ Use UA modification plugins: UA is controllable and can be easily modified.
❷ Pair with proxy pools: Switch multiple IPs at any time.
The project team discovered the existence of multi-account users and initiated the first phase of bans, ‘Recording the request IP and UA, if multiple accounts have identical UAs and the same IP, they are deemed to be operated by the same person,’ easily banning a large number of accounts.
However, since UA is sent by us, it can be changed arbitrarily, and the IP issue can easily be resolved by using a VPN or switching nodes, allowing multi-account users to bypass restrictions effortlessly. The defense cannot be said to be non-existent; it can only be said to be completely useless.
2️⃣ Round Two: Basic Fingerprint Detection
The project team's advanced defenses
① Time Zone: Determines if the physical location matches the IP location based on the system time zone.
② Screen Resolution: A user with a resolution of 1920×1080 cannot operate on an 800×600 device simultaneously.
③ System Font List: Obtains font information through JavaScript (e.g., Windows defaults to including Microsoft YaHei, Mac includes PingFang font).
④ WebRTC Leakage: Exposes the real internal IP (even using a VPN can reveal it).
Cracking Strategies
❶ Virtual Environment Isolation: Creates independent environments for each account, automatically generating different time zones, resolutions, and font lists.
❷ WebRTC Blocking: Used to completely disable WebRTC or return false internal IPs.
Many have crashed here, for example:
- User A creates multiple accounts on the same computer. Although they switched IPs and UAs, all accounts have identical screen resolutions and font lists → Accounts banned.
- User B uses a free VPN, but WebRTC leaks their real IP from mainland China → Determined to be fraudulent.
Here, there's no need for a fingerprint browser; simply downloading a fingerprint obfuscation plugin from the Chrome Web Store can bypass it (keywords: Finger, Canvas, WebRTC).
3️⃣ Round Three: Advanced Graphical Fingerprint Detection
The project team's trump card
① Canvas Fingerprint: Forces the user's browser to render a hidden Canvas, generating a unique hash based on GPU differences (for example, NVIDIA and Intel GPUs have different pixel distributions).
② WebGL Fingerprint: Extracts hardware information such as GPU model (e.g., AMD Radeon RX 7900 XT) and driver version.
③ AudioContext Fingerprint: Generates device identifiers through audio hardware clock frequency deviations.
The moment of despair for ordinary users arrives. Even if users change the hard drive and MAC address of their computer, as long as the GPU and sound card remain unchanged, all accounts will have identical Canvas/WebGL/Audio fingerprints, leading to a complete crackdown.
Are there ways to bypass this? Yes, some brothers have found solutions. For every technical problem that arises, there must be a technological solution.
Cracking Strategies
❶ Canvas Noise Injection: Adds random pixels during canvas rendering, generating different hash values with each visit.
❷ Virtual Hardware Parameters: Customizes GPU models (e.g., forges Apple M2 chip parameters) and sound card clock frequencies.
❸ Kernel-level Browser Spoofing: Modifies Chromium source code to prevent the platform from calling sensitive APIs.
4️⃣ Round Four: Beyond Technology
Having said so much, there are already technical means to identify whether users are real. Fingerprint browsers have already provided solutions, and some users can appear more real than actual humans. So why are so many still identified as witches?
Because the real skill often lies outside of technology. For instance, during the L0 anti-witch phase, a highly controversial game theory model was designed.
❶ Self-reporting program: Classic prisoner's dilemma, encourages users to confess, and confessions can earn 15% of the expected tokens.
❷ Bounty reporting and deposit: Deposit 0.5 ETH, successful reports earn 10% of the reported address's tokens, while failures result in destruction. This led to absurd situations where studio employees reported former employers, and major accounts were subjected to concentrated attacks, even mistakenly harming real users.
5️⃣ The Final Final
Due to the recent AdsPower theft incident, I specifically allocated a low-configuration device solely for running the Depin project, and this machine is the only one with a fingerprint browser.
Although AdsPower stole user assets through wallet plugins, no one can guarantee that next time it won't control computers by directly distributing updated trojan files.
This machine is completely unrelated to any financial wallets and is still very useful for running projects. For example, the recent Nexus was run on this machine. Security is no small matter; if there are spare machines, it’s best to keep them separate.