Proxy Detection bypass, SSL Pinning Bypass, Socket Redirection

1. Socket Redirection

- Socket Redirection = App의 통신을 물리적으로 BurpSuite로 보내기 위한 방식

Socket Redirection을 위한 환경 설정은 다음과 같다.

- AOS 내 Proxy 수동 설정 X

Mobile 과 PC 간 연결을 위해 Wifi 설정 내 proxy를 수동으로 설정하지만,

Socket Redirection을 위해 proxy 설정을 비활성화하고 PC와 연결하도록 한다.

- Burpsuite의 Proxy Listener 내 invisible proxying 설정

Socket redirect는 HTTP CONNECT 터널링 단계가 아예 없다.
따라서 앱이 Burpsuite을 웹 proxy로 쓰는 게 아니라, 그냥 raw TCP 연결 대상으로만 쓰게 된다.

만약 Proxy 수동 설정을 한 후 앱을 사용하게 되면

Android wifi proxy는 Java HttpURLConnection/OkHttp 같은 high-level lib에만 자동 적용되고

native socket에는 적용되지 않게된다.
따라서, 특정 앱 중 native socket을 쓰는 경우 Frida hook이나 wifi proxy로는 packet을 잡을 수 없게 된다.

2. How To Detect?

- Phase 1: APP 통신 방식 판별

Mobile 내 APP 단에서 Server까지 통신이 이뤄지는 환경은 APP 개발 환경마다 상이하다.

Java 단의 High layer에서 이뤄질 수도 있고 Native 단의 Socket을 통한 외부 IP 직접 접근도 이뤄질 수 있다.

따라서 이를 Case By Case로 나눠 통신 환경을 유추해볼 수 있다.

Case 1. IPv4 connect가 Burp IP 로 가면 = system Proxy OK = Java High-Level API 사용
Wifi Proxy 수동 설정 + SSL Pinning Bypass로 사용 가능

Case 2. connect가 외부 IP로 직접 가면 = 직접 연결
Socket.connect() 직접 사용
Socket Redirect + Invisible Proxy 필요

Case 3. connect가 외부 IP로 직접 가지만 Java Socket hooking 으로 안잡히면
libc connect()를 Interceptor.replace로 redirect 필요
또는 PC를 hotspot으로 만들어 모든 트래픽 강제 경유

Case 4. IPv6 connect가 보이면 = IPv6 bypass
getaddrinfo() 후킹으로 IPv4 강제
또는 libc connect()에서 AF_INET6 차단

Phase 2: APP 통신에 따른 Bypassing 적용 방법

프록시 탐지 우회, SSL Pinning 우회, Socket Redirection 과 같은 방식이 어떻게 이뤄지는지 알아보고

frida 코드 작성 전 어떤 함수들을 사용하는지 정리해보았다.

1단계: Proxy Detection Bypass (LAYER 1)
    - System.getProperty("proxy") → null

2단계: SSL Pinning Bypass (LAYER 2)
    - TrustAllManager 등록 + SSLContext.init 교체

  3단계: Traffic Redirection (LAYER 3)
    - Case 1. → WiFi Proxy 수동 설정만
    - Case 2. → Socket.connect() redirect
    - Case 3. → libc connect() redirect
    - Case 4. → getaddrinfo() IPv4 강제

Phase 3: Result

- Proxy Detection Bypass = 앱이 프록시를 감지 못하게

안드로이드 설정에서 프록시를 수동으로 잡았을 때, 앱이 "너 프록시 썼지?"
라고 물어보는 API에 대해 null 값으로 bypassing 하기

동작 조건: 안드로이드 Wi-Fi 프록시 설정 필수.
핵심: 탐지 로직만 피하면, 실제 통신은 OS가 설정된 프록시 경로(Burp)로 보냄

- SSL Pinning Bypass = 앱이 가짜 인증서를 수락

TrustManagerImpl 등을 후킹하여 "인증서가 달라도 일단 무조건 맞다고 해!"라고 강제하는 과정
교정 포인트: > "앱에서 검증이 이뤄지지 않으면 Burp로 패킷 자체가 나가지 않는다?"
- 패킷은 Burp의 현관문(Handshake 단계)까지는 도착함.
- 하지만 인증서가 가짜라는 걸 확인한 앱이 데이터(HTTP 내용)를 주기도 전에 연결을 끊어버림.
- Burp history에는 아무것도 안 남지만, Dashboard 탭에는 Client SSL handshake failed라는 에러 로그가 남게됨 즉, 연결 시도는 하지만 대화(Data)는 안 하는 상태

- Socket Redirection = 앱의 트래픽을 Burp으로 보내게 (패킷 보이게)

IP 변조: Socket.connect가 호출될 때 목적지를 내 PC로 꺾어버리는 것이 핵심
Wireshark vs Burp: Wireshark는 암호화된 것만 보고, Burp는 SSL/TLS를 복호화해서 HTTP packet data를 보여줌.
가장 중요한 점 (SSL Pinning 여부): > "소켓 리다이렉트만으로 웹 패킷을 봤다면 SSL Pinning이 없었던 건가?"
- "그럴 확률이 높다". 만약 SSL Pinning이 걸려 있었다면, 소켓을 꺾어서 Burp로 패킷을 보냈더라도 Burp의 가짜 인증서를 본 앱이 "이건 내가 아는 인증서가 아니야!" 라며 통신을 끊어버렸을 것.