thermoptic

"믿을 수 없어, 열광학 위장!"

무엇인가요?

이것은 JA4+와 같은 핑거프린팅을 사용하여 특정 HTTP 클라이언트를 차단하는 서비스를 우회하기 위해 설계된 HTTP 프록시입니다. 이 프록시를 사용하면 curl과 같은 선호하는 HTTP 클라이언트를 사용하면서도 실제 (Chrome/Chromium) 웹 브라우저와 마법처럼 구별할 수 없는 핑거프린트를 가질 수 있습니다. thermoptic은 또한 JavaScript 기반 핑거프린팅을 완화하기 위한 몇 가지 재미있는 기능을 제공합니다. 또한 웹 브라우저와 저수준 HTTP 클라이언트를 함께 사용하여 하이브리드 스크래핑을 쉽게 수행할 수 있게 해줍니다.

JA4+ 핑거프린팅에 익숙하지 않더라도, 스크래핑을 해본 적이 있다면 아마 이로 인해 차단된 경험이 있을 것입니다. Cloudflare와 같은 인기 서비스는 이러한 기법(및 기타 트릭)을 사용하여 "비인간적인" HTTP 클라이언트의 사용을 탐지하고 요청을 차단합니다. 이러한 서비스는 또한 이 핑거프린팅을 사용하여 실제 브라우저로 세션을 시작한 후 나중에 curl과 같은 저수준 클라이언트로 전환하는지를 탐지할 수 있습니다. thermoptic은 모든 스크래핑 요청에 대해 통합된 "실제" 브라우저 핑거프린트를 제시함으로써 이러한 모든 문제를 해결합니다.

예시

다음은 프록시 없이 curl의 JA4H (HTTP) 핑거프린트 예시입니다:

$ curl https://ja4db.com/id/ja4h/
ge11nn090000_b6a016211e8a_000000000000_e3b0c44298fc

이는 URL을 직접 방문할 때 Chrome이 생성하는 핑거프린트와 상당히 다릅니다:

ge11cn19enus_f2808f0d04cf_9a10d4221160_7068f58def6e

하지만 프록시를 사용해 요청을 보내면, 우리의 JA4H 지문은 마법처럼 동일해진다:

$ curl --proxy http://thermoptic:1234 https://ja4db.com/id/ja4h/
ge11cn19enus_f2808f0d04cf_9a10d4221160_7068f58def6e

(우리의 JA4 TLS 지문도 마찬가지입니다).

설정

Ubuntu 22.04에서 컨테이너화된 Chrome 인스턴스를 통해 트래픽을 위장하는 thermoptic 프록시를 시작하려면:

일반 Docker 설정 (GPU 런타임이 없는 호스트에서 작동):

docker compose up --build

이제 끝났습니다. 이제 이를 통해 트래픽을 프록시할 수 있습니다:

curl --proxy http://127.0.0.1:1234 --insecure https://ja4db.com/id/ja4h/

중요 사항:

• 기본적으로 프록시는 인증 없이 실행됩니다. 프록시를 외부에 노출할 계획이라면 환경 변수 PROXY_USERNAME과 PROXY_PASSWORD로 인증을 설정해야 합니다.
• ---insecure를 사용하고 싶지 않다면 ./ssl/rootCA.crt에 있는 생성된 CA 파일을 사용해야 합니다. 이 파일은 thermoptic을 처음 실행할 때 생성됩니다.
• --remote-debugging-port 플래그로 실행된 모든 Chrome/Chromium 인스턴스에 thermoptic을 연결할 수 있습니다. 이는 지문을 최대한 눈에 띄지 않게 유지하기 위해 더 일반적으로 사용되는 환경(예: Windows의 Chrome)을 설정하고 이를 통해 프록시하려는 경우 필수적입니다.
• GPU compose 오버레이는 Docker의 NVIDIA 런타임/툴킷이 이미 설치된 NVIDIA 호스트를 대상으로 합니다. GPU 장치를 예약하고 /dev/dri를 마운트하며, 번들된 Chrome 컨테이너가 NVIDIA/Vulkan 렌더링 경로로 전환할 수 있게 합니다. 이를 사용하려면 docker compose -f docker-compose.yml -f docker-compose.gpu.yml up --build를 실행하세요.

기능

• 🕵️ 실제 Chrome 세션을 통해 요청을 재생하여 JA4 지문을 바이트 단위로 일치시키는 브라우저 동등 프록시.
• 🤝 HTTP 클라이언트(예: curl, requests 등)를 thermoptic과 통합하는 데 거의 또는 전혀 사용자 정의 코드가 필요하지 않으며, 프록시만 설정하면 지문이 처리됩니다.
• 🪝 요청 전/요청 후/시작 시 자동화를 위한 훅 프레임워크로, 전체 브라우저를 구동하여 챌린지를 해결하거나 아티팩트를 캡처할 수 있습니다.
  • 📘 Cloudflare turnstile 해결 훅의 예시는 ./hooks/onstart.js에서 확인할 수 있습니다.
• 🖥️ Docker화된 Chrome 브라우저 창을 제어할 수 있는 웹 브라우저 제어 UI(http://127.0.0.1:14111). 사이트에 수동으로 로그인한 다음 로그인된 세션으로 프록시를 통해 원활하게 요청을 보내는 데 유용합니다(디버깅에도 유용).
• 🔌 docker-compose.yml의 UPSTREAM_PROXY 환경 변수를 통해 업스트림 HTTP 또는 SOCKS 프록시 URI를 설정합니다.
• 🛡️ 내장된 상태 확인 및 재시작 제어 루프로 멈춘 브라우저를 감지하고 운영자의 개입 없이 자동으로 복구합니다.
• ⚡ HTTP/1.1 및 HTTP/2를 지원하여 어느 프로토콜로든 트래픽을 프록시할 수 있습니다. (프록시와는 HTTP/1.1로 통신하고, 조종되는 Chrome은 최종 사이트와 다른 프로토콜로 협상할 수 있습니다.)

이 클로킹은 정확히 어떻게 작동하나요?

• curl과 같은 HTTP 클라이언트를 사용하여 thermoptic을 프록시로 설정한 상태에서 HTTP 요청을 보냅니다.
• thermoptic은 요청을 분석하여 이것이 원래 어떤 유형의 브라우저 요청이어야 하는지(예: 수동 URL 방문? 양식 제출? fetch() 요청?)를 최대한 판단합니다.
• thermoptic은 Chrome 디버깅 프로토콜(CDP)을 사용하여 브라우저를 조종하고, 실제 웹 브라우저에서 정상적으로 발생하는 것과 정확히 동일하게 요청을 모킹하는 페이지를 설정합니다.
• thermoptic은 모킹된 컨텍스트를 통해 요청을 트리거하고 HTTP 응답을 캡처합니다.
• thermoptic은 HTTP 응답을 클라이언트로 다시 보냅니다.

브라우저가 실제로 전체 스택을 사용하여 요청을 수행하기 때문에 결과적인 JA4 지문은 동일합니다.

참고: 많은 WAF가 웹 브라우저의 JavaScript 수준 지문 채취를 사용하기 때문에, thermoptic은 스크래핑 과정의 핵심 단계에 브라우저를 활용할 수 있는 훅도 제공합니다. 이에 대한 자세한 내용은 이 섹션을 참조하세요.

다른 솔루션 대신 이 접근 방식을 선택하는 이유는?

솔직히 말하자면: 다른 접근 방식에는 브라우저 지문 채취 문제에 대한 실용적인 장기 솔루션이 되는 것을 막는 근본적인 결함이 있습니다.

브라우저 JA4+ 지문 채취를 "이기려는" 다른 많은 시도는 브라우저 스택의 여러 계층을 재구현하는 방식으로 이루어집니다. 이 접근 방식에는 다음과 같은 여러 심각한 단점이 있습니다:

• "실제" 브라우저 구현의 동작을 완벽하게 일치시키기 위해 각별한 주의가 필요합니다. 결과적으로 어떤 특이점이나 불일치라도 이러한 클라이언트를 "실제" 브라우저 구현과 구별하는 데 사용될 수 있습니다.
• 스택의 한 계층에서만 문제를 해결하려고 시도합니다. Chrome은 웹 브라우징 경험을 제공하기 위해 여러 프로토콜을 활용합니다. 결과적으로 완벽하게 일치하는 TLS 계층을 만들었더라도 HTTP 계층이 바이트 단위로 완벽하지 않으면 정체가 드러날 수 있습니다.
• "실제" 브라우저는 정기적으로 동작을 변경하므로 지문도 변경되며, 결과적으로 이러한 도구는 이를 보완하기 위해 지속적으로 더 많은 개발 작업이 필요합니다.

반면, thermoptic은 브라우저 자체를 사용하여 HTTP 요청을 수행하기 때문에:

• TCP, TLS, HTTP와 같은 스택의 각 계층은 요청이 정상적으로 발생하는 방식으로 실제 브라우저를 사용하여 이루어지므로 실제 브라우저와 구별할 수 없습니다.
• 여러 계층에서의 브라우저 동작 변경은 최소한의 지장만 주며, thermoptic이 제어하는 브라우저를 최신 지문 세트에 맞게 업데이트하기만 하면 됩니다.

물론, 단점이 없는 솔루션은 없습니다. thermoptic 접근 방식의 단점에 대한 자세한 목록은 DOWNSIDES.md 문서를 참조하세요.

FAQ

이름이 thermoptic인 이유는?

"Thermoptic"("thermoptic camouflage"의 줄임말)은 Ghost in the Shell (1995) 애니메이션에서 Major가 사용하는 가상의 위장을 가리킵니다. 영화에서 이 위장은 착용자를 가시광선과 열복사를 포함한 여러 탐지 스펙트럼에 걸쳐 숨길 수 있는 것으로 묘사됩니다. 마찬가지로, 이 도구는 여러 채널(HTTP, TLS 등)에 걸쳐 사용자를 지문 채취로부터 숨기려고 시도합니다.

JA4+는 지문의 모음입니다! 어떤 것을 스푸핑하나요?

이 도구는 연결된 Chrome/Chromium 브라우저와 정확히 동일하게 다음 JA4 지문을 스푸핑합니다:

• JA4 (TLS 지문)
• JA4H (HTTP 지문)
• JA4X (X509 TLS 인증서 지문)
• JA4T (TCP 지문)

이것과 함께 다른 업스트림 HTTP/SOCKS 프록시를 사용하고 싶다면?

thermoptic은 이제 제어되는 Chrome 인스턴스를 내부 proxyrouter 서비스를 통해 라우팅하므로, Chrome을 업스트림 HTTP 또는 SOCKS 프록시(자격 증명이 필요한 프록시 포함)로 지정할 수 있습니다. docker-compose.yml의 proxyrouter 서비스 아래에 있는 UPSTREAM_PROXY 값을 편집하여 업스트림 프록시 URI를 설정하세요. 비워 두면 Chrome은 인증되지 않은 클러스터 내 프록시를 통해 인터넷에 직접 연결됩니다.

업스트림 SOCKS 프록시 설정 예시:

  proxyrouter:
    environment:
      UPSTREAM_PROXY: "socks5://username:[email protected]:1080"

일부 업스트림 프록시는 저수준 핑거프린트(예를 들어 TCP 메타데이터)를 변경할 수 있으며, 이는 주거용 브라우저와의 일치도를 떨어뜨릴 수 있다는 점을 유의하세요.

쿠키는 어떻게 되나요?

thermoptic은 클라이언트가 Cookie 헤더에 지정한 쿠키를 사용하여 브라우저를 로드합니다. 그러면 요청이 브라우저 컨텍스트에서 실행될 때 이 쿠키들이 포함됩니다. 이는 서버가 쿠키의 순서나 그와 유사한 값싼 트릭으로 핑거프린팅을 할 수 없도록 하기 위해 수행됩니다.

참고: 이 쿠키들은 요청 이후에도 남아 있습니다. 쿠키에 대한 정리 로직을 구현하고 싶다면 thermoptic 훅을 작성하세요.

좋아요, 그런데 인간 검증을 통과하기 위해 X 프롬프트를 클릭하려면 전체 웹 브라우저가 필요해요!

네, thermoptic은 이런 하이브리드 사용을 지원합니다. 자세한 내용은 이 섹션을 참조하세요.

요청 X에 대한 내 핑거프린트가 브라우저 핑거프린트와 일치하지 않아요!

X-Fetch-*, Origin, Referer와 같은 헤더를 올바르게 설정하고 있는지 확인해야 합니다. thermoptic에 이러한 헤더를 알려주지 않으면 적절하게 은밀한 방식으로 요청을 실행할 수 없습니다.

컨텍스트 헤더를 설정하지 않으면 thermoptic은 대상 사이트가 기대하는 것과 정확히 일치하지 않을 수 있는 기본값을 설정합니다. 예를 들어, Origin 헤더를 설정하지 않으면 Origin을 null로 설정하고, Referer 헤더를 설정하지 않으면 Referer를 전혀 보내지 않습니다.

요청이 가능한 한 은밀하도록 이러한 컨텍스트 헤더를 포함하는 것이 최선의 이익입니다! thermoptic은 당신의 마음을 읽을 수 없고, 오직 요청만 읽을 수 있습니다 :).

Chrome 디버깅 프로토콜 자체가 핑거프린팅될 수 있습니다!

일반적으로 이는 JavaScript/브라우저 수준 검사를 통과하기 위해 일시적으로 전체 웹 브라우저를 활용하는 thermoptic 훅의 경우에만 적용됩니다. 이러한 훅과 전체 브라우저 모드를 일시적으로 사용할 때는 봇으로 핑거프린팅되지 않도록 주의해야 합니다(예: Runtime.enable과 같은 함정을 피하세요).

왜 이 도구를 공개하나요? 당신이 가능하게 하는 악의적인 행위자들에 대해 신경 쓰지 않나요?!

여기서 작용하는 윤리적 고려 사항과 복잡한 게임 이론은 README에서 답할 수 있는 범위를 넘어섭니다. 그래도 이메일/트위터/Github을 통해 저를 비난하실 때 이 지나치게 단순화된 요점 중 어느 것이든 자유롭게 반박해 주세요: