일단 문제풀이를 바로 시작해보겠다. 

이 문제는 보는 바와 같이 시작부터 사람을 도발한다.

영리하다고 생각하면 도전해보라는..!! 

(멋드러지게 문제를 격파하고 싶었지만 참 구질구질하게 풀어냈다ㅠㅠ)

해당 로직을 파악하는 건 그리 어렵지 않았다. 

흐름을 간단히 설명하자면, 

하나의 긴 문자열에서 순차적으로 문자를 추출해서 CRC 값의 최하위 바이트 값과 XOR 연산을 한 뒤 이를 인덱스로 하여 CRC 테이블의 값을 가져오고 이를 기존 CRC 값에 쉬프트 연산한 값으로 XOR 연산해준다.  

말이 좀 주저리 주저리하네.. ㅡㅡ ...

어째든 아래와 같은 코드가 될 수 있다.  

여기에서 crc 변수는 생성되는 값이고, CRCTable 은 미리 생성된 int64 형 값이다. 

Strings은 CRC 알고리즘이 무결성을 확보하기 위한 주체라고 보면 된다. 

즉 Strings 변수에 포함된 문자열에 따라 CRC 값이 변경된다. 

이 문제는 최종 CRC 값과 문자열이 주어지며 이를 역연산해서 원래 삽입된 문자를 찾아내는 것이다. 

문제에서 내가 입력한 값이 0x00, 0x10, 0x20, 0x30, 0x40, 0x50, 0x60, 0x70 번째에 입력되며 변경된 문자열을 통해 CRC 값을 생성하고 해당 값을 비교하게 된다. 

처음에는 어떻게 역연산이 가능할 지 몰라서 고민했다. 

그러다 검색의 유혹을 뿌리치지 못하고 구글의 도움을 얻었다. 

그래서 역연산까지 방법을 얻었지만 브루트포씽의 범위가 굉장히 넓어 다시 한번 깊은 고민에 빠졌다. 

해서 이미 문제를 푸신 분께 약간의 자문을 얻어 실마리를 얻었다. 

그 때 당시에는 힌트를 들어도 아무것도 떠오르는 게 없었는데 시간이 지나니 뭔가 하나 떠오르기 시작했다.

참 희안하게도 시간이 지나면 뭔가 떠오른다. 

그리고 문제를 풀면 그렇게 애먹었는데도 아 이리 간단했구나 싶다.

이제 한문제 남았다 !!

참고하고 도움을 얻은 사이트는 아래에 별도로 표기해놓겠다. 

References

[1] crc 알고리즘과 취약점, http://anch0vy.tistory.com/60

[2] Reversing.kr CRC1, http://blog.naver.com/wlstngus0504/220606858247

이 문제는 이전에 MetroApp 문제의 업그레이드 버전이라고 보면 될 것 같다. 

게임으로 동작되는 터라 낯선 부동소수점 연산을 눈에 익히는 과정과 객체를 분석하는 과정에 애를 먹었다. 

낯선 어셈블리 명령어를 보니 문제가 더욱 더 어려워보였다. 

하지만 막상 문제를 풀었을 때는 핵심을 놓치고 주변 것들에 너무 신경을 쓰고 있었구나 라는 느낌을 받았다. 

그럼 문제풀이를 시작해보겠다.

우선 ReadMe.txt 파일을 먼저 열어보았다.

해당 파일을 보았을 때 두개의 플래그가 존재하고 이를 결합한 뒤 md5 해시 함수를 적용하면 되겠구나 싶었다. 물론 정답은 소문자로 입력하고..!!

이후 애플리케이션을 동작시켜 보았다.

짠 ~ 저 네모난 주인공이 빨간 악마를 총으로 쏴 죽이는 게임이다. 

이를 보았을 때 뭐를 어떻게 해야 답을 맞출까 고민을 했다. 게임 난이도는 엄청나게 어렵다.

활성화되어 있는 악마만 죽일 수 있고 속도도 다양하고 움직이는 방향도 다르다. 

쩜쩜쩜.. 마음을 가다듬고 문제를 분석했다. 

저기에 보이는 빨간 박스에 존재하는 게 첫번째 조건이다. 0xDDB 수만큼 악마를 죽이면 된다. 그래도 이건 양호하다.

두번째 조건은 0x31159cd 마리를 잡아야 한다. - - ;

순간 별의별 생각을 다했다. 악마를 일렬로 내려오게 할까? 모든 악마를 활성화 시켜볼까? 등등..

결국 걍 알아서 죽이게끔 만들어서 동작시켰다. 

흠흠.. 게임할 땐 엄청 빨리 내려오던 악마들이 너무 천천히 내려왔다. 물론 속도는 동일하겠지만 스코어가 올라가는걸 보고 있자니 가슴이 답답했다. 약 1시간? 가량 돌리다보니 첫번째 플래그를 얻을 수 있었다. 

1초에 한마리씩이라고 가정했을 때의 속도랑 거의 유사했다. 

이후 고민을 했다. 

0x31159cd 마리는 약 51468749 초가 걸리고... 이는 857812분이 걸리고.. 이는 14296시간이 걸리고.. 이는 595일이 걸린다. 이 문제를 풀기 위해 약 2년이 안되는 시간을 컴퓨터만 켜놓고 요놈만 바라보고 있을 것인지.. 다른 해결책을 찾을 것인지..!!

결국 다른 해결책을 찾았다. !

걍 정답 로직을 구현해서 돌려버렸당. 그러니 뭐 금방 답이 나왔따 ! 냠냠

이제 CRC 문제들만 남았넹.. 아직 머릿속에 그림이 안그려지는디 어떻게 접근해야 할랑가~

이 문제는 윈도우 앱을 리버싱하는 문제이다. 

이 문제 하나로 윈도우 앱 분석을 어떻게 해야하는지 알겠다라고 깨닫긴 힘들었지만

그래도 접근은 어떻게 해야겠다 라는건 알았다. 

나중에 시간이 되면 더 깊게 공부해봐야겠다. 할때마다 느끼지만 참 공부란게 끝도 없다. 

그래서 이쪽 일이 재미있는 거지만 하루가 너무 짧다. 이것만 할수도 없고 ㅠㅠㅠ

푸념은 이정도로 하고 문제풀이 들어가보도록 하겠다. 

문제를 동적으로 풀기 위해서는 윈도우 8 이상 앱이 동작할 수 있는 환경을 깔아줘야 한다. 

일단 문제를 다운받으면 읽어달라는 놈을 읽어보자. 

이 시점에는 저게 먼 의미가 있을랑가 ~ 일단 음 저렇구나 하고 넘어가보자. 

환경이 구축되었으면 앱을 실행시켜보자. 

동작화면은 이렇다. 패스워드를 입력하고 "OK" 버튼을 누르면 뭐 옳다, 그르다 이런 팝업이 뜬다. 

사실 앱을 설치할 때 주의해야 할 사항이 있다. 

인증서가 만료되어 신뢰할 수 없기 때문에 파워쉘을 켜서 날짜를 조절해주고 설치를 시작한다.

또한, 신뢰되지 않은 사용자가 게시한 소프트웨어를 실행하기 위해서는 아래와 같이 설정해줘야한다.  

간단히 명령어만 나열하자면, 

 > Set-ExecutionPolicy -ExecutionPolicy Unrestricted 

 (캡쳐를 안찍었는데 다시 찍기는 귀찮다 ㅠㅠ)

이런 일련의 과정을 겪고 나면 위처럼 정상적으로 실행될 것이다. 

만약!!!!! 이 모든게 귀찮다. 

환경 구성도 귀찮고 다 싫다! 하시는 분은 appx 파일의 확장자를 zip으로 변경한 뒤 압축을 풀면 된다. 

그럼 뙇!! 하고 실행파일이 생기는데 이거를 머 IDA로 열어서 확인해보면 된다. 

얼떨결에 만지다보니 파일 시그니처가 압축 파일인 걸 알아서 풀어보니 걍 저렇게 있었다. 

어째든 실제 동작 로직을 찾아가기 위해서는 동적분석이랑 같이 해주는게 편하다(for me). 

아직 익숙하지 않아서 그냥 찾아가기가 복잡스러워보인다. 

분석해야 하는 함수에 맞딱뜨리면 저렇게 기이이인 뭔가가 보기만해도 짜증나게 나타난다.

근데 사실 분석해야 하는 부분은 극도의 일부이다. 저것까지 알려주면 보시는 분의 재미를 빼앗아가는 것 같아 하지 않겠다.

진행하다보면 눈에 보이는 트릭이 존재하는데 알아서 잘 판단하시길 바란다. 

너무 얽매이지 않기를!!

극도의 일부를 분석하고 나면 답을 구할 수 있다. 답을 구할 때 힌트가 유용할 것이다. :) 

드디어 100위권 진입

이번 문제는 플래쉬에 있는 액션스크립트를 분석해서 문제를 푸는 것이다. 

바로 문제풀이로 들어가보자~!

플래쉬 로더를 이용하여 플래시 파일을 실행시켜보자. 

위에 캡쳐와 같이 그냥 회색 화면에 입력받는 곳이 딸랑 하나 존재한다. 

프레임은 총 7개가 존재했다. 

디컴파일러를 구동시켜 내부를 살펴보도록 하겠다. 

swf 파일 역시 디컴파일러가 존재하여 검색한 뒤 다운받아 실행시켜 보았다. 

대충 위와 같은 구성으로 되어있다. 

내부의 액션스크립트는 음 인터넷으로 검색해서 봤던 거와는 달랐다. 

감이 잘 안와서 아 또 처음부터 차근차근해야하나 싶은 마음이 들었다. 

물론 공부하면야 좋지만,,, 왠지 그닥 관심이 가지 않았다. ㅠㅠ

그래서 스크립트를 걍 훑어보던 중 

위와 같이 전역 함수 gotoAndPlay()를 보게되었다. 다른 조건문에는 포함되지 않았는데 유독 저기에만 있었다. 

그래서 혹시나 싶어 다른 버튼 이벤트도 확인해보았다. 

여기도 존재했다. 각 입력란에 조건에 맞는 값을 넣어주니 정답이 뙇 !!

음 먼가 얻어걸린 느낌이다. 나중에 시간되면 차근차근 공부해봐야지~~ 나ㅏㅏㅏㅏ중에 ..

나중에 검색해서 알아보니 해당 디컴파일러에 난독화 해제 기능도 존재했고 이를 해제하니 완전 간단한 소스가 나왔다. 쩜쩜쩜...

이번 문제는 ELF 파일구조에 대한 문제였다. 

ELF 파일 리버싱은 익숙하지 않기도 하고, 도대체 익숙한건 뭔지- -,  말로만 듣던 난독화 기법 중 가상머신이 적용된 내용이라 사전학습이 좀 필요했다. 개념을 잡기에 괜찮은 사이트를 하나 발견했는데 아래에 주소를 적어놓았으니 관심있는 사람은 한번쯤 읽어볼만 하다. 

간단히 가상머신 기법에 대한 설명을 하자면,

실행 프로그램안에 별도의 OPCODE를 정의하고 해당 OPCODE가 동작할 수 있는 기반을 마련하여 개발자가 정의한 OPCODE로 프로그램을 동작하는 것이다. 그러기 위해선 일단 사용자가 정의한 OPCODE가 동작할 수 있는 메모리(스택, 레지스터 등)가 필요하고 정의한 OPCODE가 어떻게 동작하는 지에 대한 정의는 필수적이다. 

그럼 문제풀이를 시작하도록 하겠다. 

우선 문제를 동작시키면 아래와 같은 형태로 실행된다. 여러 다른 문제들과 같이 프로그램 내에 정의된 값을 맞추는 것이다. 

내부를 보기 위해 디스에셈블러를 이용하여 한번 열어보았다. 그러니 아래처럼 툴이 정상적으로 캐치를 하지 못한다. 

처음부터 호락호락하지 않은 문제구나 싶었다. :( 

왜 그럴까 싶었는데 프로그램의 EP가 프로그램 헤더에서 정의한 영역을 벗어나서 그런거 같았다. 그래서 현재 EP에 있던 명령어를 실행한 뒤 상태로 만들어놓고 EP를 수정한 뒤 다시 로드하니 아래처럼 인식을 하게 되었다. 

근데 저 위에 로직은 문제 해결에 핵심적인 부분은 아니다. 이는 문제를 생성하기 위한 기반을 만드는 로직인 것 같다. 뭐 메모리를 할당하고 해당 메모리에 별도의 실행 로직을 만들고 파기했다가 어쩌구 저쩌구 한다. 이런저런 행위가 지나고 나면 프로세스는 0x8048000-0x804a000 범위로 IP를 옮기게 된다.  

위에서 언급한 메모리를 덤프떠서 디스어셈블러 툴에서 열어보면 흐름을 파악할 수가 있다. 

대충 핵심만 얘기해보자면 프로세스는 자식 프로세스를 생성하고 생성된 자식 프로세스에서 Input: 에 입력된 값과 OPCODE 셋을 부모 프로세스에게 전달해준다. 이를 전달받은 부모 프로세스는 OPCODE 셋에 특정 연산을 한 뒤 저장하고 이를 활용하여 자신만의 OPCODE를 실행하게 된다. 

바로 위 두개의 캡쳐가 이번 문제를 풀기 위한 핵심이다. 위 부분을 잘 분석하면 답을 얻을 수 있다. 

짜잔 ~ 

가상머신 난독화 기법에 대한 개념을 잡아보기에 좋은 문제인 것 같다. 좋은 경험이었다 :)

Reference

[1] Reversing Engineering Virtual Machine Protected Binaries, 

    http://resources.infosecinstitute.com/reverse-engineering-virtual-machine-protected-binaries/

이번 문제는 닷넷 리버싱 관련 문제이다. 이전에도 닷넷 문제가 있었으나 블로깅은 하지 않았다. 

보통 닷넷 문제는 디컴파일러를 이용해서 문제를 해결한다. 이번 문제도 물론 디컴파일러(JetBrains dotPeek)를 이용했다. 하지만 이번 문제는 디컴파일러로만 해결할 순 없었다. 이와 더불어 디어셈블러(ILDasm.exe), 헥스에디터(Hxd)도 활용했다. 

CSHARP은 여러가지 방법으로 접근해서 문제를 해결할 수 있었다. 

우선 문제가 어떤식으로 출제됬는지 확인한 뒤 다시 논하도록 하겠다. 

프로그램을 실행시키면 위와 같은 화면이 뜨고 문자열을 입력한 뒤 Check를 입력할 경우 "Correct!!" 또는 "Wrong" 팝업을 띄운다. 그럼 디컴파일러를 이용하여 로직을 살펴보도록 하자.

우선 생성자 부분을 확인해보도록 하겠다. 

생성자 부분에서는 "MetMett" 함수 바디에서 MSIL 바이트를 배열 단위로 가져온 뒤 byte[] 에 삽입한다. 그 뒤에 반복문과 특정 값 대입을 실행한 뒤 InitializeComponent 함수를 호출한다. 해당 함수는 화면 구성과 이벤트 핸들러 등록 등 그닥 살펴볼 부분이 없기 때문에 넘어가도록 하겠다. 

MetMett 함수의 몸체는 아래와 같이 디컴파일에 실패한다. 

그 뒤 "MetMetMet" 함수가 존재하는데 프로그램에서 "Check" 버튼을 눌렀을 때 발생하는 함수다. 여기서 어셈블리가 동적으로 생성된다. 닷넷 프로그램에서 사용되는 어셈블리라는 개념은 흔히 사용하는 어셈블리 언어와 개념은 다르나 여기서는 크게 유념치 않아도 될 것 같다. 여기서는 단순히 하나의 동적 함수를 생성한다 정도로만 받아드리면 될 듯 하다(정확한 의미는 아님).

바로 위의 캡쳐를 잘보면 Form1 클래스의 생성자에서 생성된 Form1.bb 배열을 이용하여 메소드를 생성한다. 여기까지만 보면 대충 느낌이 오지 않는가 ?! 

위에서 문제를 풀 수 있는 방법에 대해 언급하다만 내용을 다시 얘기해보겠다. 

크게 두가지 방법으로 접근해서 해당 문제를 해결할 수 있겠다. 

첫 번째, MetMett 함수의 hex 값을 가져와서 수동으로 변조한 뒤 바이너리 파일의 hex 값을 덮어쓰는 것 

두 번째, 디버거를 이용하여 동적 어셈블리가 생성되어 호출될 곳에 BP를 걸고 분석하는 것 

각 방법에 대한 자세한 방법은 따로 기재하지 않겠다. 

우선 첫 번째 방법을 이용하여 hex 값을 수정한 뒤 디스어셈블러를 이용해 불러보면 아래와 같이 나타난다. 

그리고 두번째 방법을 이용하여 접근했을 경우는 이렇다. 

문자열 비교 로직은 여지껏 진행해 온 문제들과 다르지 않다. 한가지 정도 다른데 다들 눈치챘을거라 생각하고 ~슥 

빠밤~~ 미션 컴플릿 !!

이번 문제는 64비트에서 실행되는 것 외에는 특별한게 없었던 문제였다. 

문제를 풀기 전에 알아야 할 건 64비트에서는 어떻게 함수에 파라미터를 전달하느냐 정도이다. 64비트 프로그램은 기존 방식과 다르게 총 4개의 레지스터를 사용하여 파라미터를 전달하고 그 이상 파라미터가 존재할 경우 스택을 이용한다. 

사용되는 레지스터 (순차적으로)

 - 정수형 : RCX, RDX, R8, R9 

 - 실수형 : XMM0, XMM1, XMM2, XMM3

그럼 문제풀이를 진행해보도록 하겠다. 

문제는 문제 이름을 보면 알수있듯이 랜덤으로 생성되는 6개의 수를 맞추는 것(또는 우회)이다. 

그럼 퀵하게 한번 보도록 하겠다. 

우선 문제를 시작하면 아래와 같이 동작한다. 여기서 숫자는 내가 임의로 입력한 값이다. 

로직을 살펴보도록 하겠다. 아래 보이는 부분은 wscanf_s 함수를 호출하는 부분이다. 

특별한 건 없고 어디에 내가 입력한 값이 저장되는지 정도만 확인하고 넘어가자.

아래 캡쳐는 6개의 수가 어떻게 생성되는지 나타낸다. rand 함수를 호출하고 곱셈, 쉬프트 연산 등등을 이용해서 값을 생성해낸다. 

아래 부분은 단순히 내가 입력한 값과 바로 위에서 생성된 값을 비교한다. 총 6번 비교를 진행한다. 

머 어찌저찌 위 비교 로직을 통과하게 되면 문제에 대한 해답을 나타내주는 부분이 진행된다. 

여기선 따로 분석을 진행하지 않겠다.

위 부분이 쭉쭉 지나고 나면 답을 출력해준다. 

Clear!

음 이번 문제는 못풀었다고 보는게 맞다. 

문제 초기에 완전 혼자 딴 생각에 빠져서 삽질만 겁나 하다가 지쳐서 검색했다. 

나는 왜 이것을 키젠 문제라고 생각했을까 ? ㅠㅠ

문제에 원본 프로그램과 패킹된 프로그램 두개를 떡하니 넣어놓고 

패커 탐지툴도 탐지했었는데 패스워드 체크란 타이틀만 보고 덥석 패스워드 푸는것만 생각하고

다른 생각을 아예 하지 못했다. 원래 입력된 값을 어떻게 추측할 수 있을까만 내내 고민했다.

좀 더 다양한 측면에서 생각할 수 있도록 하자. !!

고로, 이번 문제는 문제풀이 대신 참고한 사이트를 게시하도록 하겠다. 

thx to http://revers3r.tistory.com/9 

이번 문제는 이전에 푼 AutoHotkey1 문제와 유형이 다른 문제였다. 

인터넷에서 알아보니 오토핫키 프로그램은 컴파일 시 자동으로 UPX 패커를 적용시킨다고 나와있었다. 

근데 내가 테스트해봤을 땐 자동으로 패킹되진 않았다(옵션이 있나,, 아님 수동으로 적용시키는건가,,).  

어째든 이번 문제는 오토핫키 실행파일이 정상적으로 작동되지 않는 걸 동작시키는게 목표다. 우선 문제를 다운받아 압축을 풀어보자. 

이번에도 실행파일과 나를읽어 파일로 구성되어 있다. 

나를 읽어 파일을 읽어보자. 

동작하기 위해선 수정을 해야한단다. 우선 동작시켜보자 !! 

음.. 사실 이 에러는 이전에 AutoHotkey1 문제에서 언패킹을 한 뒤에도 동일하게 나타났던 현상이다. 그땐 문제를 해결하는데 언패킹이 필요가 없는 걸 깨닫고나서 더 이상 알아보지 않았다.  

근데 이번 문제는 그냥 실행하자마자 이 화면이.. 그리고 이것을 해결해야 답을 알수있으니.. 어쩔수 없이 분석을 진행해야했다. 

에러를 발생시키는 곳을 찾아가는 것은 어렵지 않으니 생략하도록 하겠다. 

아래 캡쳐는 문제가 발생되는 곳을 그래프로 표현한 것이다. 

처음엔 그냥 대충대충 분석안하고 플래그 변조나 하면서 지나갔는데 에러가 발생했다. 

역시 제일 빠른 건 차근차근 원인을 분석하는 것이었다. 어차피 결국 분석할테니까... ㅠㅠ 

위 구문을 봐서 알겠지만 함수명이 표현되지 않는다. 

추측인데 특정 함수를 인라이닝해서 컴파일해서 그런 것 같다. 

다행스럽게도 아이다님께선 함수를 알고 계셨다. 

어째든 여기서 사용되는 몇몇 함수는 파일 관련 함수였다. 읽고 위치 변경하고 하는.. 

조금 내려가다보면 프로세스에서 어떤 값을 저장한다. 이것도 역시 나중에 나를 물맥이려고 하는 수작이다. 

0x10 크기만큼 어떤 값을 가져와 어떤 위치에 저장한다. 

그리고 이어서 ~ 

우선 파일의 위치를 변경하고 특정 값을 읽어온다. 위에서 읽어오는 값이 이후에 비교될 값의 대상이 된다. 게다가 읽어온 값이 어떠냐에 따라 프로세스가 뻗어버리던지 돌아가던지 한다. 음음. 

여기서는 파일을 무결성을 검증하기 위한 값을 만든다. 간단하게 말하면 파일의 값을 가져와서 XOR 연산을 한뒤 위에서 읽어온 값 중 하나와 비교한다. 여기는 뭐 그냥 쩜프만 뛰어도 충분하다. 

그 다음에 위에서 0x10 크기만큼 가져온 값과 파일의 내용을 참조해서 비교한다. 

0x10 크기만큼 다 맞으면 통과 !! 위에서 힌트가 있으니 이 값만 맞추면 왠만하면 문제없이 동작할 것이다.

하지만 동작한다고 해서 끝이 아님!!

이번엔 동작한 프로그램에서 문제가 나타난다. 

인터넷 검색하니까 금방 답이 나오긴 했지만 :) 

어째든 동작한 프로그램은 이렇게 생겼다. 

끄으으읏!!

이 문제는 블로그에 안쓸까 했따. 

문제 의도만 알아채면 어렵지 않은 문제라, 

사실 다른 분들이 만들어놓은 디컴파일러 때문에 쉽게 풀렸다고 보는게 맞겠다. 

우선 AutoHotkey 가 무엇인지 알아보자. 

AutoHotkey ?

AutoHotkey는 매크로를 오픈소스 프로그램이다. 이를 이용하면 반복적인 작업을 간결하게 만들 수 있고 각종 단축키를 지정할 수 있다. 이를 스크립트로 이용할수도 있고 컴파일해서 실행파일로 변환하여 사용할 수도 있다. 

간략히 이정도만 알아보고 문제풀이에 들어가겠다. 

일단 문제를 다운받아 압축을 풀면 아래와 같은 구성으로 되어있다. 

나를읽어.txt 파일을 읽어보겠다. 

어떤 해쉬 값의 원래 값을 알아내서 조합하는 게 이 문제의 답이다. 

하지만 어떻게 알아낼까 ?! 원래 해쉬 함수는 함수의 출력 값을 이용해서 입력 값을 알 수 없는 법이다. 하지만 일부 사이트에서 다량의 해쉬 함수의 결과 값과 입력 값을 수집하여 매핑시켜 놓고 검색을 허용해준다. 아마 이 문제도 그걸 노리는 것 같았다. 사실 이 느낌 반과 다른 트릭이 있을 거 같단 느낌 반반이었다.  그래서 약간의 삽질 좀 했쥐..

우선 나도 오토핫키를 처음 봐서 DecryptKey가 뭔지 몰랐다. 또한 Exe's Key 도 무슨뜻인지 단번에 와닿진 않았다. 

어째든 오토핫키에 대해 검색을 하다보니, 오토핫키를 컴파일하는 과정에 패스워드를 입력할 수 있고 이를 이용하여 무분별한 디컴파일을 막는 것 같았다. 하지만 입력한 패스워드가 평문으로 저장되고 찾기가 용이한 듯 보였다(실제 분석하진 않았음). 

주저리 주저리 떠들다 보니 문제 실행 사진을 안올렸군...

문제를 실행했을 때는 아래와 같다. 

What a simple window..

어째든 , 이를 디컴파일할 수 있는 툴이 인터넷에 돌아당기고 쉽게 찾을 수 있땅.

또한 패스워드를 입력하지 않아도 자동으로 패스워드를 검출해주고 디컴파일까지 해주는 프로그램도 존재한다.

어째든 해당 툴을 이용하면 패스워드가 노출되고 이 값이 DecryptKey 가 된다. 

그리고 디컴파일되면 간단한 해쉬값이 나오는데 이 값이 Exe's Key 값이 된다. 

해당 해쉬 값들을 해쉬 함수 검색 사이트에서 검색하면 금방 해쉬 함수의 입력 값을 찾을 수 있다. 

처음에 시도한 해쉬 함수 검색 사이트에서 찾아내질 못해서 괜히 딴생각하고 삽질했었음..ㅠㅠ

이렇게하면 게임 클리어!!