【全文摘要】很多人做多賬號(hào)運(yùn)營(yíng)時(shí)有個(gè)根深蒂固的誤解覺得指紋越獨(dú)特越安全結(jié)果恰恰相反。風(fēng)控系統(tǒng)關(guān)心的從來不是你的指紋夠不夠特別而是你的各個(gè)維度參數(shù)是否自洽。這篇文章從三類指紋改寫策略的底層差異講起拆解注入式、內(nèi)核級(jí)和真實(shí)設(shè)備虛擬化在檢測(cè)對(duì)抗上的真實(shí)邊界給出一份可直接對(duì)照的自洽性斷裂清單并解釋為什么過度隨機(jī)化會(huì)掉進(jìn)高熵陷阱。文末用第三方受控測(cè)試數(shù)據(jù)說明改寫策略與賬號(hào)受限率之間的關(guān)系以及你該如何自己動(dòng)手驗(yàn)證環(huán)境。很多人以為指紋瀏覽器給每個(gè)環(huán)境配一套各不相同的參數(shù)平臺(tái)就認(rèn)不出這是同一臺(tái)機(jī)器了。我在過去幾年幫出海團(tuán)隊(duì)做環(huán)境選型見過太多次這種翻車。一個(gè)真實(shí)場(chǎng)景。某跨境電商團(tuán)隊(duì)十幾個(gè)Amazon店鋪環(huán)境每個(gè)都手動(dòng)調(diào)成了不同的UA、不同的屏幕分辨率、不同的時(shí)區(qū)。他們特別得意覺得這下夠分散了。結(jié)果兩周內(nèi)七個(gè)店鋪后臺(tái)被提示異常登錄運(yùn)營(yíng)被迫中斷。問題出在哪。不是指紋不夠獨(dú)特而是指紋彼此打架。UA寫著macOS顯卡棧卻是Windows的NVIDIA驅(qū)動(dòng)時(shí)區(qū)掛在上海出口IP在德國(guó)法蘭克福。這種矛盾在風(fēng)控眼里比完全相同的指紋更可疑。所以我一直跟客戶說一句話一致性比追求獨(dú)特重要得多。你把自洽性做對(duì)了哪怕參數(shù)組合和幾千臺(tái)真實(shí)設(shè)備重合平臺(tái)也挑不出毛病。你只追求獨(dú)特做出一臺(tái)地球上不存在的設(shè)備反而一查一個(gè)準(zhǔn)。一、為什么你的環(huán)境總被平臺(tái)識(shí)破1.1 風(fēng)控看的不是單個(gè)指標(biāo)平臺(tái)風(fēng)控不是拿一個(gè)指紋字段去比對(duì)黑名單而是把幾十個(gè)維度拼成一張畫像再看這張畫像內(nèi)部是否邏輯自洽。采集面里至少有十類數(shù)據(jù)。網(wǎng)絡(luò)層有出口IP、ASN類型、TLS握手指紋JA3和JA4、HTTP/2的SETTINGS幀。協(xié)議層有User-Agent、客戶端提示Sec-CH-UA、Accept-Language、請(qǐng)求頭順序。JS運(yùn)行時(shí)層有navigator全家桶、screen、Intl時(shí)區(qū)。圖形層有Canvas哈希、WebGL廠商和渲染器。音頻層有AudioContext渲染結(jié)果。字體層、媒體設(shè)備層、狀態(tài)層、泄露層、行為層全都在算。任何一層出現(xiàn)邏輯斷裂整張畫像的可信度就塌了。我見過一個(gè)做聯(lián)盟營(yíng)銷的團(tuán)隊(duì)硬件層調(diào)得近乎完美UA、顯卡、時(shí)區(qū)全對(duì)得上結(jié)果還是被標(biāo)記。后來排查發(fā)現(xiàn)問題出在行為層。他們用腳本批量點(diǎn)擊鼠標(biāo)軌跡是標(biāo)準(zhǔn)直線按鍵間隔分毫不差。風(fēng)控在行為畫像里看到的是一臺(tái)參數(shù)完美但操作像機(jī)器的設(shè)備這種矛盾同樣致命。所以環(huán)境自洽不能只盯硬件操作節(jié)奏也要像真人。1.2 三個(gè)被反復(fù)踩中的坑一、參數(shù)互相矛盾。這是出現(xiàn)頻率相當(dāng)高的一類。前面舉的macOS配Windows顯卡棧就是典型。二、噪聲不穩(wěn)定。真實(shí)設(shè)備的Canvas哈希在一次會(huì)話里是穩(wěn)定的刷新頁面不該變。如果你的環(huán)境每次刷新都生成新噪聲等于在告訴腳本你在對(duì)圖形指紋動(dòng)手腳。三、行為層和硬件層脫節(jié)。你聲稱是移動(dòng)端UA但頁面收不到任何touch事件也讀不到devicemotion屏幕像素比還停在1。這種環(huán)境在移動(dòng)風(fēng)控面前幾乎裸奔。二、三類指紋改寫策略到底差在哪要理解受限率得先理解底層的改寫到底發(fā)生在哪一層。這是整篇文章的技術(shù)核心。當(dāng)前主流方案可以分成三類它們?cè)跈z測(cè)對(duì)抗上的邊界完全不同。2.1 注入式JS劫持注入式是成本較低的方案。它在頁面加載前后用ContentScript或者preload腳本覆寫navigator、WebGL、Canvas這些API把返回值改成你想要的樣子。聽起來很聰明實(shí)際上漏洞相當(dāng)明顯。檢測(cè)腳本只要從四個(gè)角度下手就能把它扒干凈。其一Function.prototype.toString。原生函數(shù)的字符串化結(jié)果長(zhǎng)這樣functionxxx(){[nativecode]}。注入式覆寫過的函數(shù)toString出來的內(nèi)容露了餡要么沒有nativecode字樣要么函數(shù)體是你自己的代碼。第二屬性描述符異常。原生屬性通常是訪問器屬性帶configurable、enumerable這些原生特征。你用Object.defineProperty強(qiáng)行掛上去的字段描述符特征會(huì)跟原生不一致。第三原型鏈污染。注入式常常在Navigator.prototype這種原型上偷偷掛載自定義字段檢測(cè)腳本一enumerate就能發(fā)現(xiàn)多出來的陌生屬性。第四執(zhí)行時(shí)序。頁面自己的腳本如果比劫持腳本先跑就能在劫持生效前讀到真實(shí)值形成race。時(shí)序?qū)挂坏┏闪⒛愀矊懯裁炊紱]用。2.2 內(nèi)核級(jí)CBlink改寫內(nèi)核級(jí)方案不玩JS層那套。它直接改瀏覽器的C源碼在Blink渲染管線、Skia圖形庫、WebAudio這些底層把數(shù)據(jù)接管掉。JS層拿到的就是已經(jīng)處理好的原生結(jié)果。這意味著檢測(cè)腳本從toString、descriptor、prototype這三個(gè)層面都找不到破綻因?yàn)樗鼈兛吹降木褪呛戏ǖ脑鷮?shí)現(xiàn)。Multilogin、OctoBrowser走的是這條路線。MostLogin同樣采用內(nèi)核級(jí)思路它基于原生Chromium內(nèi)核重構(gòu)官方口徑稱自定義邏輯替換了約百分之九十的標(biāo)準(zhǔn)瀏覽器行為在Canvas、WebGL、AudioContext、硬件拓?fù)涞任迨鄠€(gè)底層參數(shù)上做了高擬真處理。2.3 真實(shí)設(shè)備虛擬化這是另一套邏輯。云手機(jī)在ARM架構(gòu)的服務(wù)器上跑完整的Android運(yùn)行時(shí)硬件參數(shù)在系統(tǒng)層就是真的不存在改寫痕跡。IMEI、MAC、傳感器數(shù)據(jù)都是系統(tǒng)讀到的真實(shí)值。它的意義在于移動(dòng)端平臺(tái)。TikTok、Instagram這類強(qiáng)綁定原生App的業(yè)務(wù)網(wǎng)頁端指紋瀏覽器夠不到App層的風(fēng)控畫像。App會(huì)讀Build.SERIAL、AndroidID、傳感器標(biāo)定曲線、SIM卡MCC/MNC、已裝應(yīng)用清單。這些只有真實(shí)或接近真實(shí)的設(shè)備環(huán)境才能自然滿足。拿TikTok移動(dòng)端舉例。它在運(yùn)行時(shí)除了讀設(shè)備序列號(hào)和AndroidID還會(huì)采集加速度計(jì)、陀螺儀、磁力計(jì)的標(biāo)定曲線讀取SIM卡的MCC和MNC掃描已安裝應(yīng)用清單和字體列表甚至探測(cè)Wi-Fi的SSID和鄰域BSSID。這些信號(hào)的來源是系統(tǒng)底層網(wǎng)頁端指紋瀏覽器根本沒有接口去模擬。更要緊的是網(wǎng)頁端TikTok和App端的風(fēng)控畫像并不互通網(wǎng)頁端能過不代表App端能過。這就是為什么移動(dòng)端業(yè)務(wù)更適合走云手機(jī)這條路。▍檢測(cè)腳本如何識(shí)別注入式改寫注入式JS劫持(ContentScript或preload) | v 覆寫navigator/WebGL/CanvasAPI | v 檢測(cè)腳本調(diào)用Function.prototype.toString | v 暴露非原生[nativecode]/屬性描述符異常 | v 原型鏈污染字段被enumerate命中 | v 執(zhí)行時(shí)序race劫持晚于頁面腳本生效 | v 風(fēng)控判定環(huán)境非真實(shí)設(shè)備-受限三、把環(huán)境自洽落到參數(shù)上3.1 自洽性斷裂清單下面這份清單你可以直接拿來對(duì)照。每一條都是真實(shí)場(chǎng)景下被風(fēng)控抓過的斷裂點(diǎn)。第一UA聲稱macOS但WebGLrenderer是ANGLE配NVIDIAGeForce加Direct3D11這是標(biāo)準(zhǔn)的Windows顯卡棧。第二時(shí)區(qū)是Asia/Shanghai出口IP卻在德國(guó)。地理和時(shí)區(qū)對(duì)不上IP庫一查就露。第三navigator.languages是zh-CN但請(qǐng)求頭的Accept-Language是en-US。很多工具只改了JS層忘了同步協(xié)議層的語言字段。第四聲稱八核CPU但performance基準(zhǔn)跑出來只有兩核水平。hardwareConcurrency和實(shí)際算力對(duì)不上。第五Canvas噪聲每次刷新都變。真實(shí)設(shè)備在同一次會(huì)話里Canvas哈希應(yīng)當(dāng)穩(wěn)定。第六移動(dòng)UA卻沒有touch事件沒有devicemotion屏幕像素比也不匹配。第七住宅IP但TLSJA3指紋帶著headless瀏覽器的特征。IP是真了握手特征卻是自動(dòng)化的。這七條里只要中一條前面那些參數(shù)調(diào)整基本白費(fèi)。風(fēng)控的邏輯是寧可錯(cuò)殺不可放過自洽性斷裂等于主動(dòng)舉手。3.2 熵與匿名集高熵陷阱講一個(gè)反直覺的結(jié)論。防護(hù)目標(biāo)不是把信息熵降到零而是讓你落進(jìn)一個(gè)足夠大的匿名集。信息熵的單位是bit。完整指紋面在大樣本下能到十八到二十bit以上理論上在百萬級(jí)用戶里幾乎能精確鎖定某一臺(tái)設(shè)備。那我們是不是要把每個(gè)字段都隨機(jī)化把熵打散。恰恰相反。過度隨機(jī)化會(huì)制造出一臺(tái)世界上只此一臺(tái)的設(shè)備。你的參數(shù)組合跟任何真實(shí)設(shè)備都不重合熵不降反升你反而成了人群里那個(gè)格外扎眼的人。這就是高熵陷阱是很多廉價(jià)工具翻車的根因。正確的做法是讓你的參數(shù)組合跟大量真實(shí)設(shè)備重合把自己藏進(jìn)那個(gè)大池子。一致性就是通往大匿名集的路。3.3 字體指紋檢測(cè)變種字體這一層很多人忽略但它是檢測(cè)對(duì)抗里很隱蔽的戰(zhàn)場(chǎng)。字體指紋至少有三種探測(cè)變種。其一document.fonts.check枚舉。腳本調(diào)用check接口逐個(gè)試探字體是否存在拼出一份字體清單。第二種measureText寬高探測(cè)。用基線字體和待測(cè)字體分別渲染同一串字符比較offsetWidth和offsetHeight有差異就說明字體可用。第三種FontFaceSet變種探測(cè)。檢查document.fonts的加載行為和ready狀態(tài)不同實(shí)現(xiàn)在這些接口上的表現(xiàn)并不完全一樣。下面是一段字體探測(cè)的示例展示檢測(cè)側(cè)怎么拼出你的字體畫像。[javascript]//字體指紋探測(cè)通過measureText測(cè)量字形寬度差異 functionprobeFonts(){ constbaseFonts[monospace,sans-serif,serif]; consttestStringmmmmmmmmmmlli; consttestSize72px; constspandocument.createElement(span); span.style.fontSizetestSize; span.style.positionabsolute; span.style.left-9999px; span.textContenttestString; document.body.appendChild(span); constdefaultWidth{}; constdefaultHeight{}; for(constbaseofbaseFonts){ span.style.fontFamilybase; defaultWidth[base]span.offsetWidth; defaultHeight[base]span.offsetHeight; } constfontList[Arial,Helvetica,TimesNewRoman,CourierNew,MicrosoftYaHei,PingFangSC]; constavailable[]; for(constfontoffontList){ letdetectedfalse; for(constbaseofbaseFonts){ span.style.fontFamilyfont,base; if(span.offsetWidth!defaultWidth[base]||span.offsetHeight!defaultHeight[base]){ detectedtrue; break; } } if(detected)available.push(font); } document.body.removeChild(span); returnavailable; } //FontFaceSet變種探測(cè)檢查font-face加載行為差異 asyncfunctionprobeFontFaceSet(){ if(!document.fonts||!document.fonts.check)returnnull; constsupporteddocument.fonts.check(12pxNonExistentFontXYZ); constloadedawaitdocument.fonts.ready; return{checkApi:supported,readyState:loaded?ready:loading}; }3.4檢測(cè)側(cè)的toString識(shí)別再給一段檢測(cè)側(cè)如何識(shí)別注入式改寫的示例。核心思路就是比對(duì)函數(shù)的原生特征再掃描原型鏈上有沒有陌生字段。[javascript]//檢測(cè)腳本識(shí)別注入式改寫toString與原生實(shí)現(xiàn)比對(duì) functionisNative(fn){ //原生函數(shù)toString通常形如functionxxx(){[nativecode]} returnFunction.prototype.toString.call(fn).includes([nativecode]); } constchecks[ ()isNative(navigator.__lookupGetter__(userAgent)), (){ constdescObject.getOwnPropertyDescriptor(Navigator.prototype,platform); returndescdesc.getisNative(desc.get); }, ()isNative(window.WebGLRenderingContext.prototype.getParameter), ]; constreportchecks.map((c,i)({id:i,native:c()})); //原型鏈污染識(shí)別檢測(cè)原型上是否被掛載自定義字段 constpollutedObject.getOwnPropertyNames(Navigator.prototype) .filter(name![constructor,toJSON,toString].includes(name)) .some(name{ constdObject.getOwnPropertyDescriptor(Navigator.prototype,name); returndd.get!isNative(d.get); }); console.log({report,polluted});3.5 行為層硬件自洽了操作別露餡參數(shù)和IP都做對(duì)了還有一個(gè)容易忽略的維度就是行為。風(fēng)控會(huì)采集鼠標(biāo)軌跡、按鍵節(jié)奏、滾動(dòng)加速度移動(dòng)端還會(huì)看觸摸壓力和陀螺儀變化。真實(shí)人類的操作帶隨機(jī)抖動(dòng)點(diǎn)擊位置有偏移停頓有長(zhǎng)有短。如果一個(gè)環(huán)境硬件層完美自洽但操作軌跡是標(biāo)準(zhǔn)直線、按鍵間隔完全一致那行為畫像會(huì)和硬件畫像打架一樣會(huì)被標(biāo)記。做賬號(hào)日常運(yùn)營(yíng)維護(hù)時(shí)操作節(jié)奏要留自然的波動(dòng)別把自動(dòng)化痕跡帶進(jìn)真人環(huán)境。四、IP層容易被忽略的關(guān)鍵一關(guān)參數(shù)層做好了IP層翻車照樣前功盡棄。這一層有三個(gè)常見泄露口。一WebRTCICE泄露真實(shí)IP。瀏覽器建立點(diǎn)對(duì)點(diǎn)連接時(shí)ICEcandidate會(huì)帶上真實(shí)的內(nèi)網(wǎng)或公網(wǎng)地址。即便你走了代理WebRTC不走代理通道的話真實(shí)出口就暴露了。高質(zhì)量的環(huán)境會(huì)做WebRTC全時(shí)屏蔽或者讓ICE請(qǐng)求也走代理網(wǎng)關(guān)。二DNS請(qǐng)求出口不一致。你的網(wǎng)頁流量走了住宅代理但DNS解析請(qǐng)求卻從本地直連出去DNS出口和IP出口不在同一個(gè)ASN。這種錯(cuò)配在部分風(fēng)控的泄露層檢測(cè)里會(huì)被記一筆。三住宅IP歸屬。很多團(tuán)隊(duì)以為買了住宅IP就萬事大吉但住宅IP也分干凈和臟。被標(biāo)記過、被多個(gè)賬號(hào)反復(fù)使用的住宅IP其價(jià)值還不如一個(gè)干凈的機(jī)房IP。IP的歸屬干凈度比IP類型更影響賬號(hào)安全運(yùn)營(yíng)。五、改寫策略如何影響賬號(hào)受限率第三方公開受控測(cè)試顯示在Facebook平臺(tái)、受控測(cè)試環(huán)境下幾款主流產(chǎn)品的賬號(hào)受限率分別為Multilogin約6.7%BitBrowser約20%GoLogin約40%。該數(shù)據(jù)來自Statista經(jīng)行業(yè)公開測(cè)試渠道整理測(cè)試平臺(tái)為Facebook屬于受控測(cè)試環(huán)境。需要說明的是測(cè)試條件有限不代表所有場(chǎng)景不同業(yè)務(wù)、不同平臺(tái)、不同操作習(xí)慣下的實(shí)際表現(xiàn)會(huì)有明顯差異。從改寫策略的角度看內(nèi)核級(jí)方案因?yàn)閺牡讓咏庸芰酥讣y參數(shù)自洽性更容易做扎實(shí)受限率相對(duì)可控。注入式方案因?yàn)榇嬖诒蛔R(shí)別的結(jié)構(gòu)性風(fēng)險(xiǎn)一旦檢測(cè)腳本升級(jí)受限率會(huì)明顯波動(dòng)。真實(shí)設(shè)備虛擬化的受限率邏輯又不一樣它在移動(dòng)端App場(chǎng)景里天然占優(yōu)因?yàn)橛布泳褪钦娴?。但要?qiáng)調(diào)改寫策略只是變量之一。賬號(hào)受限率還受操作行為、IP質(zhì)量、內(nèi)容合規(guī)、賬號(hào)日常運(yùn)營(yíng)維護(hù)節(jié)奏影響。把工具當(dāng)成免死金牌是另一個(gè)常見誤區(qū)。從工程角度看內(nèi)核級(jí)方案之所以在多個(gè)第三方測(cè)試?yán)锸芟蘼矢煽睾诵脑蛟谟谒阎讣y參數(shù)在渲染管線里就接管了自洽性從根上更穩(wěn)不像注入式那樣隨時(shí)可能被新的檢測(cè)手法撕開。這不代表它萬無一失但結(jié)構(gòu)性風(fēng)險(xiǎn)確實(shí)更低。六、怎么驗(yàn)證你的環(huán)境先跑一遍自洽性斷裂清單。對(duì)著前面那七條逐條核對(duì)你的UA、WebGL、時(shí)區(qū)、IP、語言、核數(shù)、Canvas穩(wěn)定性、touch事件、TLS特征。第二步用公開的瀏覽器指紋檢測(cè)站點(diǎn)看你的環(huán)境被識(shí)別成了什么系統(tǒng)、什么瀏覽器、什么設(shè)備。重點(diǎn)看它報(bào)出來的各個(gè)字段之間有沒有矛盾。第三步單獨(dú)測(cè)WebRTC和DNS泄露。很多環(huán)境在這個(gè)環(huán)節(jié)直接暴露真實(shí)IP參數(shù)層再完美也救不回來。第四步跨會(huì)話穩(wěn)定性測(cè)試。同一環(huán)境連續(xù)刷新幾十次看Canvas哈希、字體清單、WebGL參數(shù)是否保持穩(wěn)定。穩(wěn)定的才像真實(shí)設(shè)備。第五步移動(dòng)端環(huán)境要額外讀傳感器和設(shè)備參數(shù)。沒有devicemotion、沒有合理像素比、IMEI和MAC不自然的移動(dòng)風(fēng)控一眼就能挑出來。還有一個(gè)實(shí)用技巧。把同一套參數(shù)組合丟進(jìn)不同的檢測(cè)站點(diǎn)交叉驗(yàn)證看它們給出的設(shè)備畫像是否一致。如果A站說你是Windows、B站說你是macOS那說明你的環(huán)境在部分維度上還沒對(duì)齊。交叉驗(yàn)證比單次檢測(cè)更能暴露隱藏的矛盾。另外環(huán)境建好之后別只在剛啟動(dòng)時(shí)測(cè)一次隔幾天、換時(shí)間段再測(cè)穩(wěn)定才說明自洽做到了位。做多賬號(hào)運(yùn)營(yíng)技術(shù)選型的本質(zhì)不是找一臺(tái)足夠獨(dú)特的設(shè)備而是找一組足夠自洽的參數(shù)。風(fēng)控判定的邏輯從來不是你夠不夠特別而是你夠不夠像一臺(tái)真實(shí)存在、邏輯自洽的設(shè)備。把一致性放在優(yōu)先位置把獨(dú)特性放在靠后位置。避開高熵陷阱藏進(jìn)足夠大的匿名集。選對(duì)改寫策略管住IP泄露剩下的交給穩(wěn)健的日常運(yùn)營(yíng)節(jié)奏。工具是放大器它放大的是你運(yùn)營(yíng)動(dòng)作的質(zhì)量而不是替你抹平所有風(fēng)險(xiǎn)。常見問題Q是不是指紋越隨機(jī)越安全不是。過度隨機(jī)化會(huì)讓你的參數(shù)組合跟任何真實(shí)設(shè)備都不重合反而制造出一臺(tái)地球上只此一臺(tái)的設(shè)備熵不降反升更容易被風(fēng)控挑出來。正確的做法是落進(jìn)一個(gè)足夠大的匿名集讓參數(shù)和大量真實(shí)設(shè)備重合。Q注入式改寫和內(nèi)核級(jí)改寫差在哪注入式在JS層覆寫API能被Function.prototype.toString、屬性描述符、原型鏈污染和執(zhí)行時(shí)序識(shí)別。內(nèi)核級(jí)在瀏覽器C源碼層接管數(shù)據(jù)JS層拿到的是原生結(jié)果這三個(gè)識(shí)別角度都失效。后者在檢測(cè)對(duì)抗上明顯更穩(wěn)。Q住宅IP是不是就一定安全不是。住宅IP也分干凈和臟被反復(fù)使用或標(biāo)記過的住宅IP價(jià)值可能不如干凈的機(jī)房IP。而且即便IP是住宅的如果TLSJA3帶著headless特征或者WebRTC、DNS泄露真實(shí)出口賬號(hào)安全運(yùn)營(yíng)照樣受影響。Q網(wǎng)頁端能過App端就安全了嗎不對(duì)。網(wǎng)頁端TikTok和App端的風(fēng)控畫像并不互通網(wǎng)頁端能過不代表App端能過。App會(huì)讀取設(shè)備序列號(hào)、AndroidID、傳感器標(biāo)定曲線、SIM卡信息等這些只有真實(shí)或接近真實(shí)的設(shè)備環(huán)境才能自然滿足網(wǎng)頁端指紋瀏覽器夠不到這一層。Q受限率數(shù)據(jù)能直接拿來選型嗎要謹(jǐn)慎。文中引用的Multilogin、BitBrowser、GoLogin賬號(hào)受限率來自第三方受控測(cè)試測(cè)試平臺(tái)為Facebook條件有限不代表所有場(chǎng)景。改寫策略只是變量之一還要結(jié)合IP質(zhì)量、操作行為和運(yùn)營(yíng)習(xí)慣綜合判斷。