이 글은 2025-10-14 10:59에 Summer가 마지막으로 편집했습니다
저자가 이전에 해킹한 가상 카메라 버전이 빌리빌리에 영상을 올렸습니다
제가 크랙한 이전 버전도 이미 크랙된 상태였습니다
링크:하이퍼링크 로그인이 보입니다.
최근에 한 고객이 같은 작가의 가상 카메라 버전을 하나 더 해독해서 단순히 연구해 보라고 요청했습니다
먼저 셸을 확인해 보세요. Bangbang Free Reforcement는 비교적 간단하고, Frida를 간단히 감지하는 것뿐입니다. 위 링크는 ebpf 같은 다양한 도구를 사용해 Bangbang Free 버전의 보강 및 감지에 대해 매우 상세한 분석을 했습니다
먼저 frida로 훅을 사용하세요. 충돌 징후가 있습니다. 발걸음이 너무 일찍 삽입되었거나, 훅이 준비되었을 때 주소가 접근 불가능할 수 있습니다. 스크립트의 훅 코드를 frida로 수정하면
일반적으로 주입 시간이 약간 지연되어 주입 충돌 문제를 해결했습니다
훅 활성화 과정에서 활성화 데이터가 반환되고, 서버에 활성화 타임스탬프를 확인해 달라고 요청해야 합니다
사용자는 시간 차이를 계산하여 시간을 부여받습니다.
이 가상 카메라는 루트 권한도 요청하며, 그렇지 않으면 버전 간 프로세스 간 통신이 없습니다.
총 세 가지 프로세스가 시작되었습니다
하나는 카메라 앱의 주요 프로세스로, Java 계층과 C++ 계층 간의 교차 프로세스 통신입니다
두 번째는 메인 프로세스가 자바 계층을 통해 명령줄에서 이진 실행 가능한 vcmplay 입력 매개변수를 실행하여 두 번째 프로세스를 시작하는 것입니다. 두 번째 프로세스는 주로 카메라 vcmpaly의 메인 프로세스와 시스템 카메라 서비스에 주입되는 libvc.so 프로세스 간의 교차 프로세스 통신을 담당하며, 주요 통신 방식은 ibinder입니다.
세 번째는 카메라 카메라서버의 SO 파일로 시스템 서비스에 주입됩니다.
애플리케이션이 루트 권한을 얻지 못하거나 네트워크 문제가 발생하면 프로세스가 시작되지 않습니다
이 카메라는 활성화 코드가 필요하고, Java 계층을 분석하면 모든 인터페이스가 연결됩니다
활성화하려면 서버에 인증 정보를 요청해야 합니다
받는 데이터는 모두 암호화되어 있습니다
VCMPLAY 이진 실행 파일을 분석해 보면, 요청된 데이터가 RSA 암호화이며, 키는 stackplz의 EBPF 도구를 통해 위치하고 있으며 암호화 키는 128비트임을 알 수 있습니다
한 단어만 더
이 애플리케이션은 매우 교묘합니다. vcmplay에 so 접미사를 붙여서 사람들이 SO 파일인 줄 알게 만들고, 자바 메모리에 로드해야 한다고 생각하지만, 실제로는 또 다른 프로세스입니다.
카메라 서비스 카메라서버를 연결했더 libvc.so 카메라 서비스가 다운되자마자 프리다가 다운된 것을 발견했습니다. 감지되었는지는 모르겠지만, 오랫동안 분석한 결과 VCMPLAY가 한 번 꺼졌고, 후크가 성공한 것을 우연히 발견했습니다. VCMPLAY 프로세스가 카메라서브 프로세스를 감지한 것일 가능성이 있습니다
저는 ida를 이용해 VCMpay 프로세스를 디버깅했고, 그가 여전히 안티디버깅을 하고 있음을 발견했습니다. tracepid를 proc/self/status에서 스캔해 디버깅되었는지 확인했습니다. 더 무서운 점은 안티디버깅이 프로그램 크래시가 아니라는 사실을 발견했다는 것입니다. 그는 루트 권한을 통해 안드로이드 시스템에서 중요한 파일을 삭제했고, 폰이 이중 지우기 상태로 재시작되었으며, 시스템에 들어가려면 초기화되어야 했고, 폰 안의 모든 것이 사라졌습니다. kernelpatch를 통해 커널 훅 모듈 kpm을 작성하고 디버깅을 우회했습니다
여기서 몇 밤 밤을 새운 끝에 일반적인 논리가 파악되었고, 쉽게 해독할 수 없을 것으로 추정됩니다.
계속됩니다......
|
2025-10-14 10:40:57에 게시됨
|
|
|
|
