Easy_UnpackMe

ReversingKr UnpackMe

Find the OEP

ex) 00401000

이번 txt파일에는 이렇게 적혀있었다

OEP를 찾으라는 것이다.

OEP(Original Entry Point) : 프로그램의 진짜 실행 위치를 뜻한다.

패킹된 바이너리에서 언패킹을 하고 OEP로 가게 되면 원래 프로그램의 흐름이 보이게 되는 것이다.

문제는 패킹되어있으나 무엇으로 되어있는지 모른다.

직접 패킹을 풀어봐야 알것 같다.

음...UPX처럼 처음에 PUSHAD라도 있으면 POPAD를 찾을텐데 그런게 없다..

직접 트레이싱을 해봐야겠다.

이 문제는 풀이는 쉽다 근데 하다보니 분석을 하게 되었다.

우선 kernel32.dll아스키값을 PUSH하고 LoadLibrary 함수를 실행시켜 라이브러리를 로드하고

라이브러리 주소를 넣고 GetProcAddress 함수를 실행시켜 GetModuleHandle함수 주소를 얻어온다.

그 후 FreeLibrary 함수 주소도 얻어온다.

마지막으로 NULL을 넣어 0x0040000 주소까지 얻어온다.

​그 후에 0x409000과 0x4094EE 주소를 넣고 루프를 돌린다.

이 루프는 ECX의 각바이트마다 10~50까지 ECX를 증가시키며 1바이트씩 XOR연산을 시킨다.

0x4094EE까지.

그렇게 루프를 탈출하면

GetprocAddress함수에 KERNEL32.dll Base주소를 넣고 VritualProtect함수의 주소를 얻어온다.

그리고 VirtualProtect(pOldProtect, NewProtect=PAGE_READWRITE, 0x1000, 0x405000)함수를 실행시켜서 KERNEL32.dll의 영역을 만든다.

다음은 USER32.dll을 로드하는 루프이다.

USER32.dll의 문자열 길이를 체크하는 루프

이 부분과 바로 위의 Loop Start 부분을 이용해 ntdll 부분을 로드, 문자열 길이 체크

​이번엔 USER32.dll의 영역을 만든다. size = 0x4000(16384)

​영역을 만들고 그 안의 문자열을 XOR연산으로 변환시킨다.

​이 부분은 0x401000부터 0x3000만큼 영역을 만드는것 같다.

그렇게 하고 다시 또 그안에 XOR연산을 한 후 마지막 JMP 명령어가 보인다.

​저 주소가 우리의 OEP가 되는것 같다.

정리를 해보면

KERNEL32.DLL, USER32.DLL, 그 안에 ntdll등 각 영역마다 자리를 만들어주고

그 후에 XOR연산으로 문자열 등을 넣는것 같다

그리고 마지막으로 0x401150으로 JMP하면 우리의 원래 프로그램을 볼 수 있다.

​What the...? 하지만 디버거에 기능이 있다

우클릭-> Analysys -> Analyse Code를 누르면 아래처럼

​정상적으로 언패킹이 된 모습을 볼 수 있다.