풀이 날짜: 2026-09-16 (사용자 확정). 익스플로잇 성공은 2026-09-16 사용자 확인에 따른다. 아래 실행 결과는 보존된 원본 기록이며 이번 감사에서 새로 실행한 결과가 아니다.
프로토콜을 상태 기계로 읽기
이 문제는 Windows 클라이언트와 Linux authd가 사용하는 자체 인증 프로토콜이다. 문자열 비밀번호 비교 하나로 설명할 수 없고, 연결마다 유지되는 상태와 HELLO·PROOF의 서로 다른 책임을 분리해야 한다. STATIC_ANALYSIS의 주소는 ELF RVA이며 Ghidra 표시 주소와 혼용하지 않는다.
실제 연결 상태와 수명
정적 분석은 연결별 상태가 56바이트라고 정리한다. 주소 상수 없이 필드 구성만 나타내면 다음과 같다.
connection_state:
normalized_username[32]
account_record_pointer
nonce
mode
ready
연결 처리 함수는 진입 시 한 번 초기화한다. HELLO 처리와 VM은 사용자명·nonce·mode·ready 및 계정 레코드를 갱신한다. 이 필드들이 언제나 한 계정·한 인증 시도에 속한다는 보장은 별도로 확인해야 한다.
핵심 문제는 계정 조회 실패 경로에서 일부 상태가 갱신되더라도 기존 레코드 참조가 제거되지 않는다는 후속 SOLUTION의 관찰이다. 확인할 불변조건은 다음과 같다.
ready인 인증 상태에서는:
요청의 사용자명과 account_record가 같은 주체를 나타내야 한다
nonce와 mode도 그 인증 시도에 속해야 한다
조회 실패 후에는 이전 시도의 인증 재료를 유효한 것으로 사용하면 안 된다
이는 어떤 메시지를 보내 우회하는 순서가 아니라, 실패 분기에서 깨지는 상태 일관성의 설명이다.
검증과 응답을 분리한 분석
PROOF 처리에는 저장 이름·nonce·mode·ready·레코드 검사, 공통 proof 비교와 특수 추가 조건이 있다. 개별 비교문이 존재한다는 사실만으로 서로 다른 필드의 주체 일치가 보장되지는 않는다.
SOLUTION은 제한된 두 탐색 공간을 연결하는 meet-in-the-middle을 사용했다고 기록한다. 전 조합을 순회하는 것과 한쪽의 계산 결과를 저장해 다른 쪽과 대조하는 것은 시간·메모리 비용이 다르다. 기존 로컬 측정에는 테이블 메모리가 약 117 MiB였다고 남아 있다. 비밀값·proof 생성식·우회 메시지 순서는 본문에 옮기지 않는다.
PCAP이 입증하는 것과 입증하지 않는 것
제공 PCAP의 세 시도는 모두 실패라는 정적 분석 결과를 유지한다. 초기 메시지의 계산값이 캡처와 일치한 것은 프로토콜·계산 모델의 대조 근거이지 성공 proof의 증거가 아니다. 오류 응답과 정상 challenge의 길이도 다르므로 고정 길이를 잘못 가정하면 이후 메시지 해석이 틀어진다.
최종 성공 근거는 별도의 로컬 검증 기록이다. 서로 다른 K0를 넣은 세 번의 clean restart에서 응답 처리 결과가 각 테스트 값과 일치했다. 테스트에서 알고 있는 값과 공식 인스턴스의 알려지지 않은 비밀을 구분한다.
결과와 범위
사용자는 익스플로잇 성공을 확인했다. 후속 SOLUTION은 aarch64 호스트에서 제공 x86-64 authd를 QEMU로 실행한 로컬 결과를 기록한다. 실제 플랫폼의 비밀값과 공식 flag는 미확인이다. 복구된 credential·검증 키와 flag 값은 싣지 않았다. 이번 감사에서 클라이언트·서버·solver·검사기를 실행하지 않았다.
근거 자료
sources/try_again/analysis/STATIC_ANALYSIS.mdsources/try_again/analysis/SOLUTION.mdsources/try_again/analysis/STATE.md
원본 문서·solver·검증 로그는 전달 staging에 보존되어 있다. 이 경로들은 provenance이며 CMS의 다운로드 첨부 링크가 아니다.