AutoHotkey2

UPX-packed and reporting "exe corrupt"; the CRC routine has to be debugged in the original, not the unpacked, file.

2026.08.18 Reversing original post

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

Figure 1

Figure 2

** 참고로 이 문제는 꽤나 오래걸렸는데, 알고보니 upx 를 언팩해 놓고 바보같이 까먹은채로 계속 그 파일로 풀고 있었다. 언팩 상태말고 꼭 원본 파일을 디버깅 해야한다** 문자열 찾기를해서 exe corrupt 문구가 뜨는곳을 x32 디버거에서 찾 았다. 여기서 어셈블리어를 분석해 보면, 함수 004508C7 에서 crc체크에 걸려 exe corrupted이라는 문자열을 출력하는 곳으로 점프 하는걸 알수있다. 이 함수 안으로 F7 을 눌러서 들어가보자.

Figure 3

함수내부를 분석하면 아래와 같은 코드를 볼수있다. 분석해보면 프로그램이 어떤 값(EAX)을 계산 그 값에 0xAAAAAAAA를 XOR 한다. 그 후 다음줄 어셈블리어에서는 파일에서 읽어온 값과 xor 한값을 비교한다. 또한 [ebp-10]은 파일의 마지막 4바이트(EOF-4) 에서 읽어온 값 즉, CRC 값이 파일 끝에 저장되어 있다는걸 알수있다. 즉 여 기서 “exe corrupted” 가는 이유는 맨 마지막 파일 끝에 4 바이트가 eax 를 0xAAAAAAAA와 XOR 한 값과 틀려서 그런 다.

Figure 4

그렇기에 헥스 에디터로 파일을 열어준다. 그리고 맨 끝에 4개를 위에 있는 eax 를 xor 한 값으로 바꿔준다 (리틀엔디안). 하지만 저장후 다시 실행하면 또 exe corrupt 가 뜨는것을 볼수있다. 이유를 살펴보자. 코드를 다시 분석해보면 EOF-8은 “환경 값” 그리고 EOF-4는 “그 환경에서의 CRC 결과” 인걸 알수있다. ‘정상적인 자기 검증용 파일 구조’를 복원하기 위해 정상적인 AutoHotkey 실행 파일 AHK1 파일을 헥스에디터에 틀어 EOF-8 부터 EOF-4 까지 배껴준다.

Figure 5

이 작업을 수행하면, 첫 번째 corrupt 분기는 정상적으로 통과한다.

챗지피티한테 물어보니 누구인지 나왔다.

Figure 6