Classic_Blue_Note

Abex's crackme 5번 문제이다.

프로그램을 실행시켜 보면, 시리얼을 넣으라는 창이 뜨고, 아무 값이나 넣어 보니 시리얼이 틀렸다고 하며 프로그램 실행이 종료된다. 시리얼을 찾는 문제라고 판단하고, 디버깅을 시작하였다.

해당 프로그램의 경우, 시스템 콜 위주로 이루어져 있어서 분석이 용이하였다. 우리가 확인했던 메시지박스의 스트링을 기준으로 분기문을 찾아 가면서 프로그램을 분석해 본 결과, 내가 넣어 준 값과 특정 스트링이 비교되고 있는 것을 확인할 수 있었다.

비교해주는 시스템 콜에서 사용한 스트링인 L2C-57816784-ABEX를 시리얼 값에 넣어 준 결과, 프로그램이 정상 수행되고 종료되는 것을 확인할 수 있었다.

Abex's crackme 4번 문제이다.

실행 파일을 켜 본 결과, 값을 넣는 창과 registered라는 버튼이 잇는데, 해당 부분이 활성화가 되지 않는다.

해당 프로그램에서는 별도의 단서를 얻을 방법이 없어 보여서, 디버깅을 수행해 보았다.

디버깅을 수행했는데, 어디서 많이 보던 형태이다. crackme #2와 같이, 비주얼 베이직 형태의 프로그램이다. 따라서 해당 프로그램도 지난번 문제처럼 이벤트 핸들러를 찾는 것이 관건이 될 것 같다.

우선 스트링을 기반으로 탐색을 수행해 보았다. 스트링을 탐색해 본 결과, 아래와 같은 스트링이 보이는데, 해당 스트링 부분이 정상적으로 프로그램을 실행시켰을 때 발생하는 메시지박스일 것으로 추측된다. 따라서 해당 부분으로 이동하고, 상단으로 이동해서 스택 프레임 부분을 통해 이벤트 핸들러를 찾아 주었다.

해당 위치를 기반으로 분석을 진행해 보았는데, 프로그램의 실행 루틴이 해당 이벤트 핸들러 부분으로 돌아오지 않았다. 그 이유를 생각해 본 결과, 해당 이벤트 핸들러는 시리얼 넘버가 정답일 시 활성화되는 Registered 버튼이 클릭되었을 때 수행되는 이벤트 핸들러로 보인다. 따라서 해당 주소의 함수 부분을 호출하는 부분을 찾아 보았다.

Find reference 기능을 통해 00401E10 부분을 호출하는 부분을 찾을 수 있었다. 그러나 해당 부분을 찾아가 본 결과, 별다른 소득 없이 단순 점프문만 나열되어 있는 것을 볼 수 있었다.

다른 방법으로의 접근이 필요한 것 같았다. 그래서 클릭을 한 뒤에 나타나는 이벤트 핸들러가 아닌, 문자를 넣는 과정에서 꾸준한 비교 연산이 있어야 클릭이 활성화 되는 이벤트가 발생할 수 있을 것이라는 판단 하에, 스트링을 비교해주는 이벤트 핸들러 부분을 찾아보기로 했다. 그래서 모든 함수 호출들을 확인해 보았다.

확인 결과 strcmp와 유사한 형태의 호출이 존재하는 것을 확인할 수 있었다. 그래서 해당 부분에 브레이크포인트를 주고, 프로그램을 실행시켜 보았다.

그 결과, 스트링을 비교하는 이벤트 핸들러를 찾을 수 있었고, 해당 부분에서 비교해주는 값의 스택을 확인해 보니 2031105라는 값을 확인할 수 있었다. 해당 값을 넣어 주니 Registered 버튼이 활성화되었고, 프로그램이 정상 실행되었다.

Abex's crackme 3번 문제이다.

프로그램을 실행시키면, 키파일이 있을 경우 OK를 누르라고 한다.

그래서 그냥 OK를 눌러보면, 파일을 찾을 수가 없다고 뜨면서 프로그램이 종료된다. 프로그램 내부에서 인식되는 파일이 존재해야 넘어가는 구조인 것 같다. 디버깅을 수행해 보았다.

코드 부분이 매우 짧은 편이다. 전반적으로 시스템 콜도 간단한 것 위주로 사용되어서, 분석이 용이한 편이었다.

프로그램을 쭉 분석하면 CreateFileA라는 시스템 콜과, GetFileSize라는 시스템 콜이 눈에 띈다. 이 두 시스템 콜을 확인해 본 결과, CreateFileA라는 시스템 콜은 인자로 받은 파일의 포인터를 반환한다. 프로그램의 흐름을 확인해 보면, abex.l2c라는 이름의 파일의 포인터를 받고, 이를 GetFileSize라는 시스템 콜의 인자로 다시 넣어주는 것을 확인할 수 있다. GetFileSize라는 시스템 콜은 파일의 크기를 리턴한다. 이를 12와 비교하고, 00401049 주소 부분의 JNZ를 통해 분기를 수행한다.

따라서 해당 프로그램은 abex.l2c라는 이름의 파일이 키 파일이 된다. 이때, 비교해주는 12라는 값이 16진수 값이기 때문에 10진수 값으로는 18에 해당한다. 따라서 18바이트의 파일을 crackme #3와 같은 경로에 만들어 주면 프로그램이 정상적으로 수행된다.

Abex's crackme 2번 문제이다.

실행시키면 다음과 같은 창이 뜬다. 디자인이 비주얼 베이직 형태인데, 실제로 확인해본 결과 베이직으로 만들어진 언어였다.

처음에 아무 글자나 넣어서 시도해 본 결과, 틀린 시리얼이라는 창이 뜬다. 이름과 시리얼의 관계 또는 이름과 시리얼 자체를 찾아내는 것이 문제일 것이라고 예측하고, 디버깅을 시작하였다.

디버거를 통해 실행시켜 보았는데, 상태가 약간 복잡한 감이 있었다. step over를 통해 실행시켜 본 결과, 2번째 행에서 바로 프로그램이 실행되면서 별도의 디버깅이 진행되지 않았다.

그래서 해당 시스템 콜을 확인해 본 결과, 비주얼베이직에서 사용하는 api라고 한다. 해당 api는 ThuRTMain이라는 함수를 통해 메인 함수로 들어가고, 초기 세팅을 진행한 후 클릭에 따라 이벤트 기반으로 프로그램을 실행한다. 따라서 이벤트 핸들러 부분을 찾는게 필수적인데, Check 부분의 이벤트를 찾기 위해 "Nope, this serial is wrong"이라는 스트링을 기반으로 탐색을 진행했다.

 find string을 통해 해당 위치를 찾아본 결과, 00403476 부분에 해당 스트링이 존재했고, 해당 위치를 기반으로 위쪽으로 쭉 올라가 본 결과 함수가 시작하는 부분인 스택 프레임(PUSH EBP, MOV EBP ESP) 부분을 찾을 수 있었다. 해당 부분을 이벤트 핸들러라고 판단하였고, 이후 분석을 진행하였다.

쭉 분석을 진행한 결과 vbaVarTstEq라는 시스템 콜을 확인할 수 있었다. 해당 시스템 콜을 이용해서 나온 결과를 test연산한 뒤 flag 값을 저장해 두고, JE 연산을 수행하는 것을 확인할 수 있다. JE로 점프할 시 KEY가 틀렸다는 값 부분으로 점프하게 된다. 따라서, 해당 위치에서 점프를 수행하지 않도록 만들어 주는 방법이 존재한다.

그러나 필자는 해당 부분의 EAX, EDX 영역의 값을 확인해서 어떤 값을 서로 비교하는지 확인해 보는 방법으로 시리얼 넘버를 찾아보았다.

그 결과 AECDD2D9라는 값을 확인할 수 있었고, 해당 값이 곧 시리얼이었다.

시리얼 값이 생성되는 원리는 추후 추가 분석을 통해 수행해 볼 예정이다. 일단은 이정도로 클리어!

유명한 Abex's crackme 문제이다. crackme를 시작한 이유는 Pwnable을 시작하기 전, 어셈블리어에 대한 이해와 기본적인 리버싱에 대한 이해를 위해 시작했다. 시스템 콜, 스택 프레임, 어셈블리어 등 바이너리 디버깅을 통해서 얻을 수 있는 기본적인 내용에 대해 이해하고자 했다.

IDA와 같이 좋은 리버싱 도구들이 있지만, 최대한의 이해를 위해 가장 단순한 툴인 올리디버거만 사용하였다.

1번 문제 파일이다.

문제를 켜면 아래와 같은 창 하나가 반겨준다.

실행만 한번 시켜줘 봐도, 내부에서 분기문을 변경시켜 주거나, 조건을 만족시켜 주도록 프로그램을 변경해야 할 것 같다. 디버깅을 진행한다.

어셈블리 형태의 소스 코드이다. 코드 영역은 그렇게 길지 않아 분석이 쉬운 편이었다. 이중 중요한 부분은 중간의 00401026 부분의 분기문이다. JE는 바로 위의 CMP와 연동되어 움직이는데, CMP 연산을 진행하면 Zero Flag라는 레지스터의 부분이 0(거짓), 1(참)으로 변동되고, JE연산은 이 ZF를 확인해서 1이면 해당 위치로 점프하는 형식이다.

따라서 기존의 MessageBox가 아닌 다른 형태의 메시지박스를 얻기 위해서는  점프를 통해 0040103D로 가야 하고, 이를 위해서는 CMP EAX, ESI 부분이 True가 되어야 한다. 이를 위해 가장 간단한 방법으로, CMP의 operand를 변화시켰다.

이렇게 비교문을 변환해 주면, 우리가 원하는 메시지박스가 뜨는 것을 확인할 수 있다.