Ch4nh33

다운로드 후 실행하면 Key를 입력하는 창이 나온다 

디버거로 분석해 보았다.

패킹의 유무를 확인했는데 패킹이 되어있는거 같지는 않다 

그래서 바로 디버거로 열어보았다.

실행을 해보면 

0040101D에서 DialogBoxParamA에서 프로그램이 실행되고 끝나는것 같다 

일단 어느 부분에서 실행이 되는지 보기위해서 실행해 보았다.

예상대로 메세지박스를 해당 부분에서 실행이 되었는데

알맞은 키값을 입력하면 정답 메세지 박스를 띄어 줄 것이다 

그래서 문자열을 검색 해보았다.

0040108B에서 성공 메세지를 띄어준다 그래서 해당 메세지 까지의 어셈블리 코드를 확인 해보면 

여러가지가 보이는데 결국 0040107D에서 보면  CMP로 EAX와 7A2896BF를 비교해서 맞으면 

성공메세지를 띄어준다 

그래서 키는 7A2896BF 인데 10진수값인 2049480383

문제에서 메세지 창에 뜨도록 하라고 되어있어서 HXD로 수정을 해야되는것 같다.

열어보니 윈도우 PE파일의 구조가 보인다 

즉,  윈도우 실행 파일이라는건데, 

쭉 확인을 해보니 마지막에 성공메세지를 출력해주는 부분이 보인다

이부분을 우리가 알고있는 키 값으로 바꿔버리면? 

데이터 영역을 확인해보면 3D5~4D5 (NULL문자 포함)

을 바꿧다

먼저 해당 파일을 다운로드 해준다

PUSHAD가 보이는데 당연히 실행하다 보면 POPAD가 있을것이다 

그래서 POPAD를 찾았다

POPAD 다음에 PUSH로 특정한 값을 스택에 적재하는것을 볼 수 있는데 계속 실행해보면

반복되는 부분이 있어서 그 부분은 브레이크 포인트를 걸지 않고 나머지는 전부 다 브레이크 포인트를 걸고 실행을 시켰더니 안보이던 문자열이 보였다.

문자열 검색을 통해서 해당 함수로 이동 해보았다 

계속 실행해보니 00407387에서 JMP 구문으로 이동한다 그래서 실행을 했더니 해당 주소로 점프를 하고 난 뒤에 해당 주소에서 실행이 되었다.

그래서 아까전에 확인했던 문자열은 StolenByte인거 같고, OEP는 0040100C 인것 같았지만 위의 주소에 NOP가 있어서 

맨 처음 주소인 00401000이 OEP이다 

-> 0040100068002040006812204000

파일을 다운로드해서 실행을 해보면 다른것들과 비슷하게 암호를 입력하는 창이 나온다

문제의 답은 OEP를 구한 후 '등록성공' 으로 가는 분기점의 OPCODE를 구하시오.
정답인증은 OEP + OPCODE

패킹의 유무를 확인해보았는데 UPX 패킹이 아니라 ASPack 패킹인것 같다 그래서 ASPack이 무엇인지 검색을 해보니

UPX와 같은 패커이다. 새로운 패커가 나왔는데 계속 자동화 패커만 의존할 수 없으니 패킹의 원리가 어떻게 되는지 알아보기로 했다.

저번에 9에서도 비슷한것을 보았지만 PUSHAD로 레지스터 값을 스택에 저장하고 나중에 원본코드가 다 복구되면 메모리에 POPAD 명령을 통해서 다시 레지스터 값을 참조하게 될것이다. 그래서 PUSHAD를 수행한후의 ESP 값에 BP를 설정해주면 쉽게 OEP로 분기가 가능하지 않을까 생각을 해보았다.

레지스터 상태에서도 볼수있듯이 PUSHAD명령을 수행하고 나서 레지스터의 모든 값을 스택에 넣고 시작한다.

???? : 아무리 찾아도 안나온다 -> 오류가 있는지 확인해보자 

에러의 내용을 확인해보니 entry point가 다른곳에 있다고하는데 원인을 분석해보면  

1. 패킹이 잘되어 있다.

2. ollydbg가 64bit와 호환이 되지 않는다. -> 둘중에 하나 

패킹은 한마디로 실행 압축을 말한다.

일반 압축파일과 차이점은 일반 파일은 zip으로 확장자가 바뀌지만 패킹은 확장자가 바뀌지 않는다.

Search for ->Find All commands  

POPAD를 검색해주면 사용된 모든 POPAD가 나오는데 제일먼저 나온 POPAD안으로 들어가 보았다.

BP를 걸고 실행을 해보니 바로 실행이 되버려서 (패킹이 여기서 안풀린거 같음)

다시 두번째 POPAD로 들어가보았다.

POPAD 이후로도 실행을 해보았지만 레지스터 값이 변하지 않았다

아마도 지금보는 POPAD이후로 패킹이 풀린듯 하다.

위에서 볼 수 있지만 실행하기전에는 PUSH 0이었다가 실행을 해보면 00445834라고 뜬다.

계속 실행을 시켜보았다.

return이 나오게 되는데 RETN함수가 실행되면 그 후에 프로그램이 실행된다.

그러면 최근에 적재된 00445834가 OEP 주소인것을 알 수 있다.

그래서 해당 OEP로 이동을 했다. 

->Follow immediate constant

그럼 이제 성공메세지 확인을 위해서 text string으로 검색을 해보았다.

well done 이라는 문자열이 성공메세지를 출력해준다는것을 알수있다.

문제에서 말한 OEP는 찾았는데 OPCODE는 무엇인가

컴퓨터 과학에서 명령 코드(opcode←operation code, instruction syllable, instruction parcel, opstring[1][2][3][4][5][6][7])는 기계어의 일부이며 수행할 명령어를 나타내는 부호를 말한다. -> Wiki pedia

수행할 명령어를 나타내는 부호를 말하는 말한다고 하는데 이 프로그램에서는 조건에 따라서

성공과 실패를 구분하는 지점이 아닌가 생각해보았다.

JNZ SHORT 0044552B이가 OPCODE인것을 볼 수 있는데 JNZ는 조건 점프라서 zero flag

즉, 두개의 값을 비교했을때 값이 같으면 1이고 다르면 0을 반환 해준다 .

하지만 지금은 zero flag가 0을 반환할것이기 때문에 well done이라는 문자열을 출력하지 않고, 점프도 하지않을것이다.

값이 1이면 0044552B로 점프를해서 well done 이라는 문자열을 보여준다.

OEP + OPCODE 이므로 00445834 와 JNZ의 분기점인 75 55가 된다.

클릭하면 키 파일을 체크한다고 한다.

그냥 확인을 해보면 에러메세지를 출력을 하는데 ollydbg로 확인을 해보았다.

PUSHAD라는 명령어를 통해서 레지스터 값을 모두 스택에 적재함을 알 수있다.

패킹의 가능성이 보이기 때문에 패킹의 유무를 확인하고 언패킹을 진행하였다.

첫번째 MessageBoxA의 인자 값이 잘못된것을 볼 수 있다.

함수에 전달할 인자가 부족한거 같다. 문제에서 말한 StolenByte와 연관성이 있어보인다.

StolenByte

▶ 패킹된 바이너리를 언패킹할때,  이러한 과정을 방해하기위한 방법으로 프로그램의 일부 바이트를 별도의 영역에서 실행시킴으로써 OEP를 다른 위치로 가장하고 덤프를 쉽게 하지 못하도록 구현한 기법이다. 

올바른 프로그램을 얻기위해서는 StolenByte도 같이 복원해줘야 덤프가 성공적으로 이루어진다.

언패킹을 하기전으로 돌아가서 다시 열어보았다.

PUSHAD가 레지스터 값을 모두 스택에 적재하는 명령어인데 반대로 스택에서 값을 가져오는 명령어는 POPAD가 아닐까 추측을 해보았다 그리고 POPAD에서 PUSHAD로 스택에 적재된 값들이 PUSH되고 있는것을 확인했다.

upx패킹은 코드의 마지막에 있는 JMP명령어를 통해서 원래의 OEP로 가야하는데 원래의 OEP는 0040100C는 OEP가 아니다 원래의 OEP는 00401000이 되어야 한다. 왜냐하면 언패킹을 하고나서 열었을때의 시작주소였기 때문이다.

NOP로 되어있는것으로 해당 부분이 다른 특정 영역에서 실행되고 있음을 알 수 있다.

그래서 StolenByte는 POPAD다음에 오는 PUSH 명령어이다.

그리하여 StolenByte는 0040736E의 6A00 과 00407370의 6800204000이다 

따라서 StolenByte는 6A006800204000

노트북이 맛이가서 PC방에서 풀어서 그런가 가독성이 좀 안좋은것 같다.

기본적인 계산기 프로그램인것 같다.

하지만 문제에서 OEP를 찾으라고 했다.

그래서 일단 OllyDBG로 열기 전에 패킹의 유무를 확인해보았다.

UPX로 패킹이 되어있는것을 확인하고 언패킹을 진행해보았다.

용량이 늘어난것으로 보아 언패킹이 진행된것을 알 수 있다.

그 다음 Olly DBG로 열어보았다.

01012475의 주소가 OEP이다 

OEP : 패킹된 파일의 실제 프로그램 시작 부분 

첫번째로 패킹의 유무를 확인 해보았다.

보아하니 패킹이 되어있지는 않은것 같다. 

문제에서 하드디스크의 이름을 CodeEngn으로 바꾸면 나오는 시리얼값을 입력하라고 하였다.

그래서 하드디스크의 이름을 관리자 권한으로 변경해주었다.

그리고 나서 Olly DBG로 실행을 해보았다.

패킹이 되어 있지 않아서 시리얼 값을 비교하는 함수가 있을것이라고 추측을 해보았다

IstrcmpiA 함수가 있었다. 이 함수가 서로서로 시리얼 값을 비교해서 성공과 에러 메세지를 띄어주는 곳으로 점프 시키는것 같다. 

함수의 위치로 이동해보았다.

4562-ABEX가 아직 무엇인지는 모르겠으나, 밑의 주소에 CodeEngn이라는 문자열을 PUSH하고 있다.

아마도 하드디스크의 이름을 바꿨을때 이곳으로 PUSH 되는것 같다.

계속 실행을 해보았다.

기존의 CodeEngn 문자열에 4562-ABEX 문자열이 뒤에 추가되었다. 아마 이런식으로 시리얼 값이 정해지는것 같다.

게속 실행해보았다.

Code라는 문자가 1글자씩 뒤로 밀리는것을 볼수있는데, 분기가 2번도는것을 보아 2글자씩 뒤로 밀리는것 같다 

그래서 CodeEngn -> EqfgEngn으로 2글자가 밀려서 시리얼값이 생성된다.

L2C-5781이라는 새로운 문자열이 또 보인다 아직은 잘모르겠지만 게속 실행해보았다.

새로 시리얼 값이 생성된것을 볼 수 있다. 

아까 2글자씩 밀렸던 EqfgEngn4562-ABEX의 앞에 L2C-5781이라는 문자열이 추가되었다 

따라서 07.exe의 Serial 값은 L2C-5781EqfgEngn4562-ABEX인것을 알 수있다.

그래서 입력을 해보았다.

성공 메세지가 출력되는것을 확인할 수 있다.

그리고 하드디스크 이름은 원래대로 해주었다.

프로그램을 실행시켜 보면 Serial 값을 입력하라고 한다 

아마 값을 입력하면 비교후에 일치 불일치 메세지를 띄어주는것 같다.

그래서 OllyDBG로 열어보았다.

현재 사용되고 있는 함수를 검색하기 위해 Search for에 Intermodularcalls를 들어가서 확인 해보았으나 무언가 이상하다. 패킹이 되어있는거 같아서 PEID로 패킹의 유무를 확인한 후 UPX로 언패킹을 진행하였다.

언패킹을 진행한 후에 문자열을 비교하는곳을 찾아보기 위해서 Text String을 검색해보았다.

성공 문자열과 실패 문자열이 눈에 보인다.

그래서 해당 문자열이 실행되는 함수 내부로 들어가 보았다.

0040106E 주소를 보면  "AD46DFS547" 이라는 문자열을 PUSH하고 있다.

EDX에 AD46DF547라는 문자열이 들어간다.

따라서 한번 실행시키고 난 후에 AD46DF5S47를 넣어보았다.

성공문자열을 보여준다.

하지만 문제에서 OEP + 시리얼 값이라고 했으니까

OEP를 찾아줘야 한다. 

OEP는 언패킹을하고 나서의 시작주소를 의미한다.

시리얼 키를 맟춰야 되는것 같다. 그냥 Resister now 를 클릭하니까 에러 메세지가 나온다

메세지 내용을 보아 시리얼 키를 찾는것이 목적인거 같다.

Olly DBG로 열고난 후에, Search for > All intermodular calls을 이용해서 사용되는 API를 검색을 해보았지만

뭔가가 이상함을 알 수 있었다.

아무것도 없다. 그래서 에러 메세지를 기반으로 검색을 해보았지만

뭔가 이상하다.

패킹으로 실행 압축이 되어있는거 같다 그래서 PEID를 이용해서 패킹의 여부를 확인 해보았다.

패킹이란?

실행압축이라는 의미를 가지며 그 의미인 즉슨 파일 내부에 압축해제코드를 포함하고 있어서

실행될 때 메모리단에서 압축해제 후 실행시키는 기술을 의미한다.

패킹을 사용하는 이유는 코드분석으로 인한 악의적인 용도로 사용하는것을 방지하는 것에 목적을 둔다.

UPX를 이용해서 패킹이 되어있다. 따라서 UPX를 이용해서 언패킹을 진행해 보았다.

UPX를 다운로드 한 뒤에 (반드시 UPX가 설치된 경로로 이동한 다음 확인해야 한다.)

Cmd 에서 UPX에 대한 정보를 확인 할 수 있다.

그럼 여기서 -d 와 -k를 이용해서 언패킹을 해보았다.

해당 파일의 용량이 증가한걸로 봐서 언패킹이 진행된거 같다. 

Olly DBG로 열어보았다.

메세지 창의 내용을 기반으로 검색을 하기 위해서 Search for -> reference text strings를 보았더니 이제는 아까전과 달리 아스키 코드의 값을 확인 할 수 있었다. 그리고 에러 메세지와 성공메세지를 띄우는 문자열을 확인 할 수 있었다.

인증로직이 눈에 보인다. 

1. 이름을 입력하지 않았을 경우 Enter a Name이라는 메세지를 보여준다. 

2. 시리얼 값을 입력하지 않았을 경우 Enter a Serial이라는 메세지를 보여준다.

3. 이름과 시리얼 값이 모두 일치하는지 비교한다.

- 일치할 경우 Congrates! You cracked this CrakMe라는 메세지를 보여준다.

- 불일치의 경우  Worng Serial, try again이라는 메세지를 보여준다.

해당 프로그램의 이름과 시리얼 값은 이미 인증로직에서 확인 할 수 있듯이

Name = Registered User

Serial = GFX-754-IER-954이다.

성공했다는 메세지 창을 보여준다.

다운로드 후 실행 시켜 보면 정상이라는 문구가 계속 나온다.

문제에서 디버깅을 감지하는 함수는 무엇인가를 보아 디버깅을 감지한 후에 정상 여부를 출력하는것 같다.

OllyDBG로 열고나서 디버깅을 진행해 보았다.

디버거로 디버깅을 진행해본결과 디버깅을 감지하고 디버깅 당함이라는 문자를 보여준다.

00408454의 주소의 CALL 명령어를 통해서 실행이 된다 Break Point를 걸고 함수 내부로 진입 해보았다.

함수 내부에서 디버깅을 탐지한후 탐지 여부에 따라서 정상과 디버깅당함이라는 문자열을 무한 반복한다.

계속해서 디버깅을 진행해보았다.

0040105E주소에서 KERNEL32.lsDebbugerPresnt 라는 함수이름이 보인다. 

IsDebuggerPresent() 함수는 kernel32.dll에 export되는 함수이며 디버깅을 체크하는 MS에서 공식적으로 지원하는 안티리버싱 API이다. 해당 프로세스가 디버깅을 당하고 있는지에 대한 여부를 PEB구조체의 디버깅 상태값을 확인하며 디버깅을 당하고 있다면 1을 아닐 경우 0을 리턴한다.

IsDebuggerPresent() 함수는 내부적으로 TEB(Thread Environment Block)와 PEB(Process Environment Block)을 이용하며 PEB내의 Begin Debugger라는 멤버의 값을 기준으로 유저모드 디버거에 의해 디버깅을 판단한다

- TEB(Thread Enviorment Block) 프로세스에서 실행되는 스레드의 정보를 담고있는 구조체이다

- OS 환경마다 다르다. (Windows7의 경우 Windows XP SP3 보다 확장)

- 시작 주소 : FS:[0x00], FS:[0x18](User mode)

- PEB(Process Enviorment Block) 프로세스의 정보를 담고있는 구조체

- PEB 구조체는 OS마다 달라진다 (Windows7의 경우 Windows XP SP3 보다 확장)

-시작주소는 OS마다 다르다 (SP2미만 = 0x7FFDF000, SP2이상 = fs:[0x30], Windows7  User mode = fs:[0x30], fs:[0x18])

IsDebuggerPresent() 함수 부분을 지나고 EAX의 값이 1로 변경되었다.

따라서 IsDebuggerPresent()는 내부에 1의 값을 가진다.

결국 디버깅을 당하고 있다는 뜻이되는데, 그럼 EAX의 값을 0으로 변경해주면 된다.

0으로 변경해준뒤에 디버깅을 해보면?

정상이라는 문자가 출력이된다. 이것으로 설명을 마친다.

문제를 다운받아서 실행 시켜보면 이러한 창이 나온다 

확인을 눌러보면

RegCode 를 입력해야 한다. 

일단 아무거나 입력해보았다.

Regcode가 일치하지 않아서 에러메세지가 뜬다.

OllyDBG로 열어보았다.

문제에서 물어보는 비주얼 베이직 스트링 비교함수를 찾아야 한다. 

그래서 such for -> All intermodular calls로 현재 사용하고 있는 함수들을 보여주는 기능을 사용했다.

문자열(스트링)을 비교하는 함수인 vbaStrCmp 함수가 보인다.

vbaStrCmp 함수로 들어가서 디버깅을 해보면 

해당 Password 즉,  앞에서 보았던 RegCode는 2G83G35Hs2를 PUSH하고 있다.

004028BA : EBP - 50에서 DWORD double word 를 읽고 난 다음 PUSH

004028BD : 2G83G35Hs2를 PUSH

004028C2 : CALL vbaStrCmp -> 두개의 문자열을 비교 

따라서 2G83G35Hs2 를 입력해보았다. 

성공메세지가 뜬다.