Android 앱에서 인증서 고정 기능이 점점 더 많이 채택되는 것을 보니 반갑습니다. 요청을 프록시하려고 시도하는 동안 연결 오류가 발생하는 앱을 만나면 더 깊이 파고드는 데 관심이 더 커지는 경향이 있습니다. 최근 서브웨이 앱을 사용할 때도 그랬다. APK를 반전시키면 다른 흥미로운 결과 중에서 인증서 고정이 드러났습니다.
요청을 프록시하는 동안 앱을 시작하면 다음 오류가 발생합니다.
고정은 우회할 만큼 간단합니다. 저는 앱을 디컴파일하고 키워드 고정을 위한 소스 코드를 분석하는 것부터 시작했습니다. 실제로 구현한 두 개의 별도 클래스에서 고정 구현을 찾았습니다. X509신뢰관리자. 고정을 시행하는 방법 중 하나는 다음과 같습니다.
// Code removed at request of Subway leadership
이를 우회하는 것은 위 메서드에서 고정 코드를 건너뛰기 위해 smali 코드에 return 문을 추가하는 것만큼 간단했습니다. 추가된 내용을 참고하세요. 반품 무효 아래 진술:
// Code removed at request of Subway leadership
앱을 다시 컴파일하고 설치한 후 다음과 같은 새로운 오류를 보고 놀랐습니다.
Subway는 APK 역전을 방지하기 위해 맞춤형 앱 서명 확인 프로세스를 사용하고 있었습니다. 이 프로세스에 대한 언급이 있는 소스를 찾아 다음 방법으로 추적했습니다.
// Code removed at request of Subway leadership
이는 리버스 엔지니어링을 방지하려는 흥미로운 시도였지만 실제로는 약간의 지연만 발생시켰을 뿐입니다. 이 프로세스를 우회하기 위해 다른 행을 추가하여 메서드 실행을 건너뛰는 행을 추가했습니다. 반품 무효 위의 피닝 바이패스 프로세스와 유사합니다.
// Code removed at request of Subway leadership
앱을 다시 컴파일하고 설치한 후 요청을 성공적으로 프록시할 수 있었습니다.
조사하다가 우연히 발견한 이 Reddit 게시물. 분명히 Subway는 사용자의 기기가 루팅되었는지 여부도 확인하고 있었습니다. 소스를 뒤져보니 루트 탐지 방법에 대한 언급이 있는 것을 확인했습니다.
// Code removed at request of Subway leadership
이는 보안을 매우 중요하게 생각하는 앱의 좋은 예이지만 루트 검사 프로세스의 이유가 무엇인지 잘 모르겠습니다. 인증서 고정 및 서명 확인 기술은 일반적으로 좋은 생각이지만 리버스 엔지니어링 프로세스를 약간 방해할 뿐입니다.