문제가 되게 귀엽네요. 프로그램을 한번 봅시다.

실행해보면 ECED01 부근에 있는 루프에서 계속 뺑뻉이를 돌고 있는 것을 확인할 수 있습니다. 뭔가 느낌적인 느낌으로 언패킹을 하고 있다는 생각이 들었습니다.

이런식으로 0x401000 번지부터 값을 계속 쓰고 있으니까요.

일단 패킹을 다 풀지 않은 채로 0x401000 번지로 이동봤습니다.

뭔가 좀 의심스럽긴 하네요. 일단 0x401000번지에 breakpoint를 걸고 run을 했습니다. 401000번지부터 패킹을 푼다는건 OEP가 401000번지일 확률이 높다는 뜻일테니까요. 아닐수도 있지만 아니면 다른 방법으로 시도해보면 되겠죠. run을 돌리자 breakpoint에서 걸렸고, 401000번지 쪽은 아래와 같이 조금 이상했지만

0x44B11C번지라던가, intermodular calls 쪽을 확인해보면 패킹이 잘 풀렸음을 확인할 수 있습니다.(이전에는 intermodular calls을 봐도 아무것도 없었습니다.)

중요하게 볼 부분은 아마 키의 입력, 파일 입/출력 부분일 것으로 보입니다. 일단 그럴싸한 함수에 싹 다 breakpoint를 걸고 진행하다보면 핵심적인 루틴을 확인할 수 있습니다.

바로 이 부분입니다. 이 루프를 확인해보면

파일 내용이 저 위치에 써지고 있음을 확인할 수 있습니다. feof가 true가 될 때 까지 진행하니 아마 파일 전체를 0x5415B8 번지에 쓰게 되겠죠.

그리고 file이 write될 때를 보면 파일 내용이 이미 바뀌어있습니다.

그럼 그 사이에 데이터가 이미 바뀌었다는 소리이네요. 다시 살펴봐야겠습니다.

루틴 부분을 열심히 따라가다보면 결국

1. 내가 입력한 키를 byte 단위로 XOR함.(예를 들어 1234를 입력했으면 file의 첫 번째 바이트에는 '1'(0x20)을 XOR, 두 번째 바이트에는 '2'(0x21)을 XOr...)

2. XOR 하고나서 bit을 반전시킴.(즉 0xFF를 XOR함)

이 연산을 수행함을 알 수 있습니다.

그런데 key 길이를 모르는데 뭔 수로 맞추나요.. 라는 생각이 듭니다. 원본 파일의 hex를 한번 확인해보니

뭔가 살짝 9A 8B 8C 8F 93 9E 86 9C 97 9A 8C 8C 93 이런 13글자 짜리가 반복되는 느낌입니다. 저 부분이 0으로 꽉차있다거나 그림 파일의 같은 색깔이라던가 하는 것들을 떠올릴 수가 있는데, 만약 그림파일이라면 3의 배수일텐데 애매하게 13글자 반복인걸 보면 저기가 0으로 차있는 것 같습니다. 키가 13을 주기로 가진다고 생각하고, 또 저 반복되는 부분의 평문이 0이라고 생각할 때, 밑의 사진을 보면 키를 쉽게 추론해낼 수 있습니다.

  키는 93 9A 8B 8C 8F 93 9E 86 9C 97 9A 8C 8C 의 비트반전으로 추론할 수 있고, 그 값을 간단하게 코드를 짜서 알아보면 아래와 같습니다.

또한 결과는 아래와 같습니다.

얻어낸 키로 복호화를 해보면

실행파일을 얻을 수 있고  실행해보면

Key를 얻을 수 있습니다.