GLM 5.3과 REA가 20달러로 TikTok 앱의 서명 체계를 풀어냈다

한 개발자가 GLM 5.3과 에이전트 프레임워크 Hermes, 오픈소스 리버스 엔지니어링 도구 모음 REA(Reverse Engineer Anything)를 조합해 TikTok 앱의 비공개 API를 분석하고 영상 메타데이터 수집 경로를 재현했다. 비용은 20달러를 넘지 않았다는 것이 저자의 설명이다. 그는 리버스 엔지니어링 경험이 많지 않아 방향 설정과 결과 검증만 직접 맡고, 실제 분석 작업 대부분은 모델에 위임했다고 밝혔다.

출발점은 Hugging Face에 공개된 TikTok 데이터셋이었다. 56억 건 규모의 영상 메타데이터가 담긴 이 데이터셋을 보고 저자는 데이터 자체보다 수집 방식에 관심을 가졌다. 이를 설명한 DataSocial의 글이 있었지만 해당 문서는 1699달러 유료 장벽 뒤로 사라진 상태였고, 웹 아카이브에 남은 스냅샷으로 대략적인 방향만 확인할 수 있었다. 에뮬레이터 없이 완전한 헤드리스로 수집했다는 사실 정도가 남은 단서였다.

작업 환경은 세 층으로 구성됐다. GLM 5.3을 OpenRouter를 통해 호출하고 Hermes 에이전트가 이를 구동하며, REA가 MCP 서버 형태로 붙어 에이전트의 요청에 따라 jadx, Ghidra, IDA, Hopper, adb, TShark 같은 도구를 알아서 실행하고 결과를 정리해 돌려준다. 여기에 실행 중인 앱 내부를 들여다보는 Frida와 트래픽을 읽는 mitmproxy가 더해졌다. 저자는 보안 관련 요청을 강하게 차단하는 서구 모델 대신 GLM이나 Manus를 쓰는 방식을 이전 작업에서부터 유지해 왔다고 적었다.

TikTok의 비공개 API는 일반적인 모바일 API와 결이 다르다. 요청마다 앱 내부 네이티브 라이브러리가 계산한 서명이 붙고, 디바이스 아이덴티티와 리전별 엔드포인트, 휴대폰처럼 보이는 네트워크 지문까지 네 가지 조건이 동시에 맞아야 한다. 문제는 하나라도 어긋나면 서버가 오류를 주지 않고 HTTP 200과 빈 본문을 돌려준다는 점이다. 어디가 틀렸는지 알려주지 않으니 상태 코드만으로는 성공 여부를 판단할 수 없다.

그래서 가장 먼저 만들어진 것이 응답 내용을 기준으로 성공과 실패를 가르는 판정기였다. 짧거나 빈 본문이면 관문 중 하나가 어긋난 것이고, 실제 페이로드가 오면 네 조건이 모두 통과된 것으로 본다. 저자는 이후 모든 작업이 이 몇 줄짜리 판정에 의존한다고 강조한다.

분석 과정에서 드러난 함정도 구체적이다. 앱의 Java 코드와 네이티브 코드 경계에 Frida 훅을 걸었지만 정작 필요한 서명은 그 경계를 넘지 않았다. 실제 데이터 요청의 서명은 네이티브 네트워킹 스택 안쪽에서 라이브러리를 직접 호출해 만들어지기 때문에, 중간에 앉은 훅에는 보이지 않는다. 서명자를 후킹해 출력을 읽겠다는 손쉬운 계획이 초반에 무너지는 지점이다.

인증서 피닝도 걸림돌이었다. 프록시를 끼워 넣으면 앱이 자체 인증서만 신뢰해 요청조차 나가지 않는다. 에이전트가 처음 시도한 방식은 인증서 검사를 항상 통과로 바꿔치기하는 것이었고, 앱은 즉시 크래시했다. 이를 변조 탐지로 오해해 반나절을 허비한 끝에 디컴파일 결과를 다시 보니 해법은 검사를 없애는 것이 아니라 검사는 정상 수행하게 두고 최종 판정만 거부에서 수락으로 뒤집는 것이었다. 그렇게 트래픽이 열리면서 실제 서명이 붙은 요청들을 확보할 수 있었다.

개발자에게 이 사례가 주는 시사점은 도구의 조합 방식에 있다. 리버스 엔지니어링에 쓰이는 프로그램들을 에이전트가 필요할 때 호출하도록 MCP로 묶어두면, 도구 선택과 결과 해석을 사람이 일일이 이어붙이지 않아도 된다. 동시에 이 글은 상태 코드를 신뢰할 수 없는 API, 네이티브 계층에 숨은 로직, 피닝처럼 흔한 방어선을 다루는 실제 절차를 보여준다.

한계도 분명하다. 저자는 자신이 리버싱 전문가가 아니며 대부분의 작업을 모델이 수행했다고 거듭 밝히고 있고, 서명을 재사용할 수 있는지 검토하던 대목에서 글이 끝나 최종 결론까지 이어지지 않는다. 플랫폼 이용약관이나 법적 쟁점은 원문에서 다루지 않는다.