저는 @edulazaro와 함께 Carmageddon을 플레이하곤 했는데, 올해 신작이 출시된다는 소식에 다시 플레이해 보기로 했습니다.

우리는 또한 새로운 자동차들을 추가하려고 시도했고, 질량(mass), 최고 속도(top speed), 서스펜션(suspension) 등의 수치가 합리적인 범위 내에 있기를 원했습니다.

1997년 오리지널 버전이 명백한 참조 대상입니다. 하지만 한 가지 문제가 있습니다. Carmageddon은 디스크에 이 모든 정보를 **암호화 (encrypted)**하여 저장합니다. 예를 들어 CARS/BLKEAGLE.TXT는 그저 암호화된 쓰레기 데이터일 뿐입니다.

그래서 처음에는 Claude에게 암호(cipher)를 풀어달라고 요청했지만, 작동하지 않았습니다. 우리는 빈도 분석 (frequency analysis), 패턴, 단순 XOR 등을 기대하며 암호화된 파일들을 입력했습니다. 하지만 아무것도 작동하지 않았습니다.

그곳에는 16바이트 키(16-byte key)가 있었고, length % 16에서 시작하여 7씩 증가하는 인덱스, 0x9f로 재매핑된 탭(tabs), 그리고 // 주석이 나타나자마자 작동하는 두 번째 키가 있었습니다. 바이트를 뚫어지게 쳐다본다고 해서 이런 것을 추측할 수는 없습니다. 문제는 LLM에게 오직 알아내야만 알 수 있는 것을 추측하라고 요청하면, 잘못된 답을 내놓는다는 점입니다.

성공한 방법

게임의 디컴파일 (decompilation) 버전인 dethrace 리포지토리가 존재한다는 것을 발견했습니다. 실제 코드는 그 안에 있습니다. 그래서 저는 질문을 "이것을 추측해 봐"에서 "이것을 찾아서 나에게 설명해 줘"로 바꾸었습니다. 그러자 Claude는 src/DETHRACE/common/utility.c에서 EncodeLine을 찾아냈고, C 로직을 JavaScript로 번역했습니다.

하지만 모든 시도가 버그가 있었습니다. 키의 엔디언 (endianness) 문제였는데, 이를 해결해 준 것은 utility.c:125에 있는 GENERAL.TXT가 0.01로 복호화되어야 한다는 주석이었습니다. 빅 엔디언 (Big-endian)은 이를 생성했지만, 리틀 엔디언 (little-endian)은 그렇지 않았습니다. 대조할 수 있는 알려진 값이 없었다면, 우리는 여전히 똑같이 그럴듯한 변형들 사이에서 고민하고 있었을 것입니다.

여전한 어려움

41대의 자동차를 모두 복호화한 후, 우리는 위치에 따라 필드를 읽는 추출기 (extractor)를 작성했습니다: 12행은 질량, 15행은 기어 수 등과 같은 방식입니다. 하지만 결과 숫자는 터무니없었습니다. 최고 속도가 4이고 기어가 200개인 자동차가 나왔습니다.

파일은 서로 다른 필드를 가진 세 가지 형식 버전(v2, v3, v4)으로 제공되므로, 위치 기반으로 읽을 경우 일부 파일에서는 열(column)이 밀리게 됩니다. 가장 최악인 점은 오류가 발생하지 않는다는 것입니다. 그저 숫자를 내뱉을 뿐이며, 그중 일부는 심지어 그럴듯해 보이기까지 합니다. 해결책은 각 값을 주석 텍스트를 통해 찾는 것이었습니다. 모든 줄에는 // mass in tonnes 등이 포함되어 있어 어느 정도 미리 알 수 있으며, 버전 간에도 안정적으로 유지되는 것으로 보입니다.

그리고 이것으로 끝입니다

일반적으로, 코드를 작성하기 전에 이미 알고 있는 값을 찾는 것은 암호 해독 (decryption)에서 매우 유용해 보입니다. 그 0.01이라는 값은 엔디언 (endianness)에 대해 추론하는 그 어떤 것보다 더 가치 있었습니다.

여기 순수 Node/JS로 작성된 extractor가 있습니다.

그리고 이것으로 끝입니다 😊