AutoHotkey2

파일을 다운로드하고 exeinfo 로 보니 UPX 팩이 되어 있었다. 실행해보니 exe corrupt 라는 문구가 나오고 언팩해봐도 똑같다. 텍스트 파일을 읽으면 뭘 해야 하는지 확인할 수 있다.

참고로 이 문제는 꽤나 오래 걸렸는데, 알고 보니 UPX 를 언팩해 놓고 바보같이 까먹은 채로 계속 그 파일로 풀고 있었다. 언팩 상태 말고 꼭 원본 파일을 디버깅해야 한다.

문자열 찾기를 해서 exe corrupt 문구가 뜨는 곳을 x32 디버거에서 찾았다. 여기서 어셈블리어를 분석해 보면, 함수 004508C7 에서 CRC 체크에 걸려 exe corrupted 이라는 문자열을 출력하는 곳으로 점프하는 걸 알 수 있다. 이 함수 안으로 F7 을 눌러서 들어가보자.

함수 내부를 분석하면 아래와 같은 코드를 볼 수 있다. 분석해보면 프로그램이 어떤 값(EAX)을 계산하고, 그 값에 0xAAAAAAAA 를 XOR 한다. 그 후 다음 줄 어셈블리어에서는 파일에서 읽어온 값과 XOR 한 값을 비교한다.

또한 [ebp-10] 은 파일의 마지막 4바이트(EOF-4) 에서 읽어온 값이다. 즉, CRC 값이 파일 끝에 저장되어 있다는 걸 알 수 있다. 즉 여기서 “exe corrupted” 로 가는 이유는, 맨 마지막 파일 끝의 4바이트가 EAX 를 0xAAAAAAAA 와 XOR 한 값과 틀려서 그런 거다.

그렇기에 헥스 에디터로 파일을 열어준다. 그리고 맨 끝에 4개를 위에 있는 EAX 를 XOR 한 값으로 바꿔준다 (리틀엔디안). 하지만 저장 후 다시 실행하면 또 exe corrupt 가 뜨는 것을 볼 수 있다.

이유를 살펴보자. 코드를 다시 분석해보면 EOF-8 은 “환경 값”, 그리고 EOF-4 는 “그 환경에서의 CRC 결과” 인 걸 알 수 있다. ‘정상적인 자기 검증용 파일 구조’를 복원하기 위해, 정상적인 AutoHotkey 실행 파일 AHK1 파일을 헥스에디터에 띄워 EOF-8 부터 EOF-4 까지 베껴준다.

이 작업을 수행하면, 첫 번째 corrupt 분기는 정상적으로 통과한다. 챗지피티한테 물어보니 누구인지 나왔다.