Skip to content

2026년 버전 업데이트 내역

[2026년 2월 6일] 버전: 7.10.20.219

버전: v7.10.20.219 Build 20260206 업데이트 수준: 중요 / 코어 업데이트 코드네임: "DeepFlight" (심해 비행)

버전 개요

이번 v7 업데이트는 약 반년 만에 이뤄진 Mbbrowser의 가장 중대한 저수준(Underlying) 변화를 담고 있습니다. 갈수록 엄격해지는 CloudFlare의 AI 대항 검증 메커니즘, 특히 모바일 환경을 타겟으로 한 TLS 지문 인식에 대응하기 위해 커널 수준에서 완전히 새로운 대항 로직을 도입했습니다. 동시에 Windows 7과 같은 구형 시스템과의 호환성 문제를 심층적으로 해결했으며, Chrome 140 커널로 업그레이드하여 JS 실행 환경의 미세한 차이를 보완했습니다.

특히 이번 업데이트는 사용자들이 오랫동안 겪어온 통증인 **"iPhone 시뮬레이션 환경에서 pcmax.jp와 같은 고보안 사이트 접속 시 CloudFlare 인간 인증을 통과하지 못하는 문제"**를 해결하는 데 집중했습니다.

공식 다운로드: Core 140 (Win10/11)


1. 핵심 돌파구: 완전히 새로운 "IphoneCloudFlare" 안티 디텍션 모드

📌 배경과 과제: pcmax.jp의 벽

지난 두 달간 많은 VIP 사용자들로부터 피드백을 받았습니다. Mbbrowser의 iPhone 6/7/8/X/11/12 iOS 프로필을 사용하여 일본의 인기 데이팅 사이트인 pcmax.jp에 로그인을 시도할 때 전례 없는 장벽에 부딪혔다는 내용이었습니다. CloudFlare의 Turnstile 인증이 이러한 모바일 환경에서 매우 높은 차단율을 보였으며, 거의 100%에 가까운 오탐지(False Positive) 차단이 발생했습니다.

구체적인 증상: 사용자는 완벽한 Mbbrowser 상업용 지문과 iPhone User-Agent를 구성하고, 화면 해상도(Retina)를 맞추고, 심지어 터치 이벤트(TouchEvent)까지 시뮬레이션했습니다. 하지만 pcmax.jp의 로그인 페이지를 열자마자 CloudFlare는 무한 인증 루프에 빠지거나 즉시 "Access Denied"를 표시했습니다.

📌 심층 기술 원인 분석: TLS 지문의 "불쾌한 골짜기" 효과

자사 핵심 R&D 팀은 MbFireWall 모듈을 통해 200시간 이상 캡처된 데이터 패킷을 심층 분석했으며, Wireshark를 사용하여 실제 iPhone 장치(iOS 15-17)와 Mbbrowser 시뮬레이션 환경 간의 네트워크 핸드셰이크 패킷을 비교했습니다.

결론은 놀라웠습니다. 문제는 애플리케이션 계층(HTTP Headers/JS)이 아니라 전송 계층(TLS/SSL)에 있었습니다.

Mbbrowser가 Windows 10/11에서 실행될 때, 저수준 네트워크 요청은 Windows의 SChannel 또는 OpenSSL 라이브러리를 호출합니다. 여기서 생성되는 TLS Client Hello 데이터 패킷(Cipher Suites 암호화 제품군 목록, Extensions 확장 필드 순서, Supported Groups 등 포함)은 전형적인 "IPHONE 하드웨어 매개변수 값 불일치" 특성을 보였습니다.

CloudFlare의 안티 스크레이핑 및 리스크 관리 엔진은 매우 민감합니다. 그들은 다음과 같은 논리적 모순을 감지했습니다:

"이 클라이언트는 iPhone(User-Agent)이라고 주장하고 JavaScript 환경도 iPhone을 시뮬레이션하고 있지만, 전송 계층의 TLS 핸드셰이크 특성(JA3/JA4 지문)은 CloudFlare 감지 서버에 대고 말하고 있다 — 나의 iPhone 데이터는 충분히 진짜 같지 않다."

이러한 애플리케이션 계층과 전송 계층 특성 간의 불일치는 CloudFlare의 리스크 관리(즉, "Bot Fight Mode")를 직접적으로 트리거합니다. 이로 인해 pcmax.jp는 사용자에게 인증 코드를 보여줄 기회조차 주지 않고, 즉시 '비실제 iPhone 및 비인가 작업 의심'으로 판정해 버리는 것이었습니다.

📌 해결책: 글로벌 설정 "IphoneCloudFlare"

이 문제를 해결하기 위해 우리는 단순한 패치를 선택하지 않고, 저수준 네트워크 패킷 로직을 **재설계(Refactoring)**하여 글로벌 설정에 "IphoneCloudFlare" 옵션을 도입했습니다.

이것은 우리 기술 부서가 프로젝트의 MbFireWallWinDivert 모듈 디렉토리에서 광범위한 코드 커밋을 수행한 이유이기도 합니다(반복적인 테스트와 데이터 드릴 비교).

기술 구현 세부 사항:

  1. 커널 수준의 트래픽 쉐이핑(Traffic Shaping)

    • 사용자가 글로벌 설정에서 "IphoneCloudFlare"를 체크하면 Mbbrowser는 내장된 Divert 드라이버 모듈을 활성화합니다.
    • 이 모듈은 시스템 커널 모드에서 실행되며 CloudFlare IP 대역으로 흐르는 모든 TCP/TLS 핸드셰이크 패킷을 가로챌 수 있습니다.
  2. 동적 TLS 지문 스푸핑(Dynamic TLS Fingerprint Spoofing)

    • MbBrowser가 Client Hello 패킷을 가로챌 때, 더 이상 OpenSSL의 기본 생성 구조를 사용하지 않고 실제 iOS Safari의 TLS 핸드셰이크 특성에 따라 바이트 단위 재구성을 수행합니다.
    • Cipher Suites 재정렬: 암호화 제품군의 우선순위를 iOS의 Network.framework 동작과 완벽히 일치하도록 강제 조정하여 TLS_AES_128_GCM_SHA256과 같은 모바일 전용 제품군을 우선 배치하고 Windows 전용 취약 암호화 제품군을 제거합니다.
    • Extension 패딩: Client Hello의 Extensions에 대한 iOS Safari의 패딩 방식은 Windows와 완전히 다릅니다. 새로운 기능은 이 패딩 길이와 순서를 정확하게 시뮬레이션합니다.
    • ALPN 협상: Safari의 동작과 일치하도록 h2(HTTP/2) 프로토콜 협상 순서를 강제 지정합니다.
  3. TCP/IP 프로토콜 스택 특성 시뮬레이션

    • TLS 외에도 TCP 계층의 특성(TTL 값, Window Size)을 미세 조정했습니다.
    • Windows의 기본 TTL은 보통 128인 반면, iOS/Linux는 보통 64입니다.
    • IphoneCloudFlare 모드는 드라이버 계층에서 나가는 패킷의 TTL을 자동으로 수정하여 서버에 도달할 때 모바일 OS에서 생성된 패킷처럼 보이게 합니다.

📌 실제 운영 결과

클린 IP 환경에서 500회 이상의 내부 테스트를 거친 결과입니다.

실제 운영 결과

  • Mbbrowser 클라이언트 설정 패널 -> 브라우저 설정 -> 미체크 시: pcmax.jp 로그인 페이지 통과율 0%.

  • Mbbrowser 클라이언트 설정 패널 -> 브라우저 설정 -> 체크 시: pcmax.jp 로그인 페이지 통과율 **98.5%**로 상승 (나머지 1.5%는 IP 자체의 블랙리스트 이슈).

이 기능은 pcmax.jp 문제를 완벽하게 해결할 뿐만 아니라, 모바일 구성 환경에서 다른 TLS 지문 민감 사이트(예: Nike, Ticketmaster 등)의 감지 문제도 함께 해결합니다.


2. Chrome 140 커널 동기화 및 JS 표시 일관성 수정

📌 Chrome 140 커널 업그레이드

Google Chromium 업스트림 업데이트에 따라 libcef 및 관련 렌더링 커널을 Chrome 140 버전으로 업그레이드했습니다. 이번 업그레이드에는 CDP (Chrome DevTools Protocol) 디렉토리의 방대한 헤더 파일 및 인터페이스 변경 사항이 포함되었습니다.

  • 성능 향상: V8 엔진의 JavaScript 실행 효율이 약 15% 향상되었습니다.
  • 새로운 기능 지원: 최신 CSS 속성 및 Web API 지원을 통해 브라우저의 "실제성"을 주류 브라우저 버전과 일치시켰습니다.

📌 iPhone 환경에서의 JS 표시 불일치 수정

이전 커널 버전에서 chromedp를 사용하여 iPhone의 viewportdevicePixelRatio를 시뮬레이션할 때, Chrome 140의 새로운 렌더링 파이프라인이 특정 CSS Media Queries를 처리하는 과정에서 버그가 발생하여 pcmax.jp 모바일 버전 등 일부 웹 페이지의 하단 탐색 바에서 1px의 어긋남이나 겹침 현상이 발생했습니다.

기능상 영향은 적지만, window.innerHeightouterHeight의 차이를 통해 시뮬레이터 여부를 판단하는 극도로 엄격한 지문 감지 스크립트에게는 치명적인 결함입니다.

수정 내용:

  • CDP 모듈의 Emulation.setDeviceMetricsOverride 호출 로직을 수정하여 모바일 상태 표시줄에 대한 높이 보상을 추가했습니다.
  • MbCommand에서 window.screen 객체에 대한 심층 Hook을 추가하여 JS 계층에서 얻은 화면 기하학 정보가 CSS 렌더링 결과와 엄격히 일치하도록 보장함으로써 픽셀 수준의 지문 결함을 제거했습니다.

3. 호환성 롤백: Go 1.20 및 Win7 32비트 시스템 구제

Windows 7은 이미 Microsoft에서 공식적으로 지원을 종료했으며 전체 사용자 층의 8%에 불과하지만, 동유럽 및 동남아시아의 가상 머신 환경 등 일부 해외 비즈니스에서는 여전히 가벼운 Win7 32비트 시스템에 크게 의존하고 있습니다. 우리는 이들의 안정성을 보장해야 합니다.

📌 문제 증상

이전 버전에서 CDP 컴파일 환경이 Go 1.21로 업그레이드되면서 Win7 32비트 커널에서 지원하지 않는 일부 시스템 콜(Syscall)이 도입되었습니다. 이로 인해 해당 시스템에서 Mbbrowser 실행 시 CDP 서비스 프로세스가 소리 없이 충돌하여 빈 페이지가 뜨거나 프록시에 연결되지 않는 현상이 발생했습니다.

📌 수정 방안

  • 환경 다운그레이드 및 조건부 컴파일: CDP 모듈을 위해 별도의 독립적인 컴파일 파이프라인을 구축했습니다. 대상 시스템이 Windows 7으로 감지되면 빌드 스크립트가 자동으로 Go 1.20.14 버전으로 전환하여 컴파일합니다. Go 1.20은 Win7을 완벽하게 지원하는 마지막 버전입니다.
  • 이를 위해 CDP 디렉토리 내의 빌드 스크립트를 수정하고 Go 1.21 신기능을 사용한 코드에 대해 호환성 재작성(Polyfill)을 수행했습니다.

4. 프로세스 관리 최적화: "좀비 크롬"과의 작별

📌 문제 설명

Windows 7 사용자들이 Mbbrowser 메인 프로그램을 종료한 후에도 내부의 chrome.exe 자식 프로세스들이 함께 종료되지 않고 백그라운드에 남아 200MB 이상의 메모리를 점유하는 "좀비 프로세스"가 된다고 보고해왔습니다. 브라우저를 자주 열고 닫을 경우 시스템 메모리 고갈과 프리징으로 이어질 수 있습니다.

📌 기술 분석

이는 UseAfterFree와 관련된 것이 아니라 IPC (프로세스 간 통신) 신호 손실 문제입니다. Win7에서는 부모 프로세스(DuiLib 기반의 UI 프로세스)가 TerminateProcess를 통해 강제 종료될 때, Chrome 자식 프로세스들이 Named Pipe를 통해 종료 지시를 받지 못하는 경우가 발생합니다.

📌 수정 조치

  • Job Object 바인딩
    • MbCommand의 프로세스 시작 로직에 Windows의 Job Object 메커니즘을 도입했습니다.
    • 수정된 코드는 실행된 모든 chrome.exe 자식 프로세스를 독립적인 Job Object에 자동으로 추가합니다.
    • 이제 메인 프로그램이 예기치 않게 충돌하거나 강제로 종료되더라도, 운영체제는 Job Object 내의 모든 자식 프로세스가 함께 종료되도록 보장합니다.
    • 이는 시스템 수준의 생명 주기 관리로, 좀비 프로세스 문제를 완벽하게 해결합니다.

5. 설치 패키지 경험 최적화: 버전 번호 디렉토리 정규화

📌 문제 설명

기존 SetupInstall 로직에서는 설치 패키지의 기본 압축 해제 경로가 고정되어 있었습니다(예: C:\Program Files\MBBrowser). 이 때문에 사용자가 버전 간 비교 테스트를 하거나 여러 버전을 공존시키려 할 때 폴더 이름을 수동으로 변경해야 하는 큰 불편함이 있었습니다.

📌 최적화 내용

  • 버전 인식 설치 경로: NSIS 설치 스크립트를 수정하여, 이제 설치 프로그램이 현재 빌드 버전 번호(Version Info)를 자동으로 읽습니다.
  • 기본 설치 경로가 C:\Program Files\MBBrowser_v7.10.20.219와 같이 변경되었습니다.
  • uninst.exe 생성 로직도 업데이트하여, 제거 프로그램이 다른 버전의 파일을 실수로 삭제하지 않고 해당 버전의 디렉토리만 정확하게 식별하여 정리하도록 보장합니다.
  • 이는 그레이 릴리스(Gray Release) 및 롤백 테스트를 수행하는 스튜디오 사용자들에게 큰 편의를 제공합니다.

6. Java 환경 다운로드 수정: 캐시 데드락 타파

📌 문제 배경

Mbbrowser의 일부 고급 플러그인은 JRE(Java Runtime Environment)에 의존합니다. Windows 7 시스템에서 다운로더가 JRE 업데이트를 시도할 때, Win7의 공격적인 WinINet 캐시 정책으로 인해 서버에 새 JRE 패키지가 올라와도 클라이언트가 로컬에 캐시된 이전 파일을 반복해서 다운로드하여 체크섬 오류(Hash Mismatch)와 무한 재시도가 발생하는 문제가 있었습니다.

📌 수정 방안

  • 강제 패스스루 (Cache Busting)
    • 다운로드 모듈의 HTTP 요청 헤더에 Cache-Control: no-cachePragma: no-cache를 강제 추가했습니다.
  • URL 무작위화: 끈질긴 중간자 프록시 캐시(ISP Cache)를 우회하기 위해 다운로드 URL 끝에 무작위 타임스탬프 파라미터 ?t=TIMESTAMP를 추가했습니다.
  • 이 수정 사항은 검증을 마쳤으며, Win7에서 Java 환경 업데이트가 99%에서 멈추는 문제를 완벽하게 해결했습니다.

버전 요약

이번 v7 업데이트는 겉으로 보기에는 평범해 보일 수 있지만, 내부적으로는 매우 중대한 변화를 포함하고 있습니다. 특히 "IphoneCloudFlare" 기능 출시를 통해 Mbbrowser는 안티 스크레이핑 분야의 깊은 수역인 "TLS 지문 인식"과의 전쟁에서 결정적인 승리를 거두었습니다.

일본 이커머스 및 소셜 비즈니스(pcmax, tinder 등)를 운영하는 모든 사용자는 즉시 업그레이드하고 해당 옵션을 활성화할 것을 권장합니다.

공식 다운로드 링크: Chromium 140 커널 버전 (Windows 10/11 호환)