문제 확인

풀이

아래와 같이 POPAD를 찾은 후에 JUMP를 통하여 OEP로 가기전에 이루어지는 동작이 바로 StolenByte이다. 

아래와 같이 OEP로 점프하기 바로 전에 스택을 보면 위의 붉은 상자 부분이 Stack에 Push 되어 있는 것을 확인 할 수가 있다. 이러한 것이 바로 StolenByte로써 이를 구하는 문제 였던 것이다. 

그렇다면 이러한 StolenByte가 제대로 스택에 있는지 확인하기 위해 OEP로 JUMP 해볼 경우 아래와 같이 Stack에는 이미 Push 되어 있는 StolenByte를 확인 할 수가 있다.

추가풀이

OEP를 찾은 후를 계속 풀어 본다면 우선 이 프로그램은 키파일이 있는 지를 확인 하는 것이다. 따라서 CreateFile 함수를 통하여 해당 파일이 존재하는지( Mode = OPEN EXISTING) 확인을 하고 그 해당 파일의 크기가 0x12인지 확인하기 위하여 GetFileSize 함수를 통하여 확인을 한다. 따라서 해당 폴더에 abex.l2c 라는 파일이 18Byte의 크기로 존재하여야 프로그램이 성공적으로 실행이 된다.

문제확인

OEP를 찾으면 된다. UPX패킹의 경우 흔히 PUSHAD로 먼저 시작을 하고 끝부분에 가서 POPAD를 통하여 스택을 해제한 후에 JUMP를 통하여 OEP로 이동을 한다. 따라서 이를 유념하고 문제를 풀면 쉽게 풀 수가 있다.

풀이

POPAD를 Ctrl+F : POPAD를 통하여 찾은 다음에 Ctrl+L을 통하여 다른 POPAD 또한 찾으면 손쉽게 찾을 수가 있다.

OEP지점으로 JMP한 이후에 Ctrl+A를 통하여 코드를 다시 분석을 하면 아래와 같이 기존의 코드를 복원 할 수가 있다.

문제확인

파일을 실행할 경우 아래와 같이 틀린 시리얼에 의하여 프로그램이 바로 종료가 된다.

풀이

손쉽게 성공분기점을 찾을 수가 있으며, 이를 통하여 우리는 GetVolumeInformationA 와 lstrcat과 lstrcmp를 볼 수가 있다.  하지만 여기서 중요한 것은 바로 4562-ABEX 밑 부분에 알고리즘이 있다는 것이다. 이 알고리즘은 4562의 숫자를 1씩 총 두번 상승 시키므로 인하여 결국 6784-ABEX가 위치하게 된다.

알고리즘을 거친 문자열은 L2C-5781뒤에 덧붙여 지게 되어 시리얼을 형성하는 것을 볼수가 있다.

여기서 GetVolumeInformationA에서 VolumeNameBuffer의 위치에 바로 드라이브의 이름이 위치하는 것을 볼 수가 있다. 따라서 드라이브의 이름이 CodeEngn일 경우 Code-Engn이 위치하게 되어 앞의 Code부분이 2칸씩 상승하게 되고 그러한 상승이 이루어진뒤에 기존의 문자열에 덧붙여져 이번 문제를 풀 수가 있다.

문제확인

UPX패킹이므로 언패킹을 해야한다. 본인이 사용하는 방법은 3가지이다.

1. OEP를 찾아서 그 부분부터 분석을 하는것

2. OEP를 찾아서 OllyDump를 통행 덤프를 뜬 후 LoadPE를 통하여 Rebuild를 한 후에 분석

3. UPX.exe를 통하여 언패킹을 한 후에 분석을 한다.

여기서 나는 3번의 방법을 통하여 분석을 실시하였다.      >>    $ upx -d 06.exe

풀이

아래의 JMP가 가르키는 곳이 OEP지점이다. 이 지점으로 점프를 하여 분석을 하면 된다.

아래와 같이 성공부분의 분기점이 나뉘어진 곳을 찾을 수가 있다. 이 부분에서 ASCII AD46DFS547 이라는 키 값을 찾을 수가 있다. 따라서 OEP+Key 이므로 00401360AD46DFS547이 이번 문제의 정답이다. 

문제확인

프로그램을 실행하면 다음과 같다. 이와 같이 아이디와 시리얼 값을 찾는 것이 문제이다.

디버깅에 앞서 PEID를 통하여 분석을 해보면 UPX로 패킹이 되어 있는 것을 확인 할 수가 있다.

풀이

방법은 두가지이다. POPAD 다음의 점프 부분이 본래의 코드 부분으로 점프를 한 후에 분석을 진행 할 수가 있다. 하지만 이는 지속적으로 분석하기에 번거로움이 있다.

따라서 우리는 upx를 통하여 unpacking을 진행 한 후에 프로그램을 분석 할 것이다.

분석을 하다보면 문자열을 검색하여 성공 구문을 찾은 후에 분석을 하면 되는데 총 두번의 문자열비교가 일어난다. 아이디와 시리얼 값이 각 각 따로 비교가 진행이 되며 진행 되는 방법은 다음과 같이 EAX에는 우리가 입력한 값과 EDX에는 비교에 사용될 원래의 값이 존재한다. 이를 통하여 우리는 시리얼 값을 찾을 수가 있다.

이에 따라 입력을 한후에 실행을 할 경우 성공 구문이 나타나는 것을 확인 할 수가 있다.

추가

OEP지점으로 이동하여 OllyDump를 통하여 직접 덤프를 뜰 수가 있다. 해당 플러그인을 통하여 OEP지점에서 DUMP를 클릭한 후에 rebuild를 해제 한 후에 완료를 클릭한 후에 LoadPE를 통하여 프로그램을 다시 재설정 해주면 upx패킹을 언패킹 할 수가 있다.

LordPE Deluxe.zip

OllyDump.dll

문제확인

<일반적인 방법으로 프로그램을 실행할 경우>

<디버깅을 통하여 프로그램을 실행할 경우>

풀이

프로그램을 천천히 분석하다 보면 디버깅이 걸리는 시점을 찾을 수가 있다. 바로 아래의 IsDebuggerPresent 지점이다. 이 부분에 의하여 디버깅이 걸리는 것이다.

따라서 안티디버깅을 피하기 위해서는 IsDebuggerPresent를 NOP로 채우는 것도 하나의 방법이다. NOP로 채움으로 인하여 디버깅일 정상적으로 실행 되는 것을 확인 할 수가 있다. 또는 MOV EAX,0을 통하여 무력화 할 수도 있다.

문제 확인

문제를 실행 할 경우 아래와 같이 동작하는 것을 확인 할 수가 있다.

풀이

123을 키 값으로 넣었을 경우 아래와 같이 비교 문자열이 존재하는 것을 확인 할 수가 있다.

따라서 문자열 비교 함수는 vbaStrCmp이며 키 값은 2G83G35Hs2 인 것을 확인 할 수가 있다.

문제확인

아래와 같이 패스워드를 확인하는 문제이다. 하지만 실행파일이 손상되어 실행이 되지 않는다. 실행을 하여보자.

실행을 할 경우 windows8.1에서는 아래와 같이 뜨는 것을 확인 할 수가 있다. 따라서 우리는 다른 방법으로 이 프로그램을 분석하여야 한다. 참고로 손상이 되었기에 디버깅도 가능 하지 않다. 따라서 우리는 HexEditor를 통하여 프로그램을 분석하여 보자.

풀이

아래와 같이 문자열이 기록되는 부분으로 추측 되는곳에 패스워드로 추측이 되는 문자열을 확인 할 수가 있다. 이처럼 우리는 패스워드를 쉽게 찾을 수가 있다.