Ch4nh33

시리얼 키를 맟춰야 되는것 같다. 그냥 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 를 입력해보았다. 

성공메세지가 뜬다.

문제를 다운받아서 실행을 시켜보면 그냥 실행은 안된다.

그래서 Olly DBG로 열어보았다.

역시나 안된다 그래서 마지막으로 HXD Editor를 사용해서 열어보았다.

안의 내용을 확인해보니 MZ -> DOS Header 시그니처

즉, 윈도우 PE파일 인것 같다.

그뒤로 계속해서 쭉 내려보니 실패한 문자열과 성공한 문자열의 메세지들을 확인 할 수 있었다.

숫자랑 섞어서 사용한거 보니 브루트포스를 방지 하기 위한 것 같다.

Password는 JK3FJZh이다. 

abex crack me 

현재 HD를 CD-Rom으로 인식을 하게 만들어야 한다.

그래서 OllyDBG로 실행을 하여 분석해 보았다.

현재 00401000의 이 프로그램의  EP(Entry Point)인것을 알 수 있다. (Message Box)를 출력하는 것으로 보아 여기가 main함수 인것을 알 수 있다.

디버깅을 계속 진행해보면 아까 봤었던 메세지 박스가 실행된다 

따라서 0040100E에서 Make me think your HD is a CD-Rom 이라는 메세지 박스를 실행시키는 주소이다.

HD를 CD-Rom으로 인식을 하게 해야하는데 인식의 여부에 따라서 성공과 에러창이 실행되는 주소로 이동한다.

- CD-Rom으로 인식을 못했을 경우 에러창이 실행된다.

0040100E 주소에서 Msagge BoxA를 실행시키고 계속 디버깅을 해보면 00401018의 CALL 명령어를 실행하여 

아래의 주소로 이동한다.

어셈블리 명령어들을 살펴보면 JMP를 통해서 00401021주소로 이동하고 ESI값을 2 감소시킨 다음 EAX를 1증가시킨 후 

CMP EAX, ESI를 통해 비교를 한다.  그리고 JE라는 구문을 통해서 EAX와 ESI의 값이 일치하면 0040130D 주소로 이동하여 성공이라는 Message Box를 실행한다.

처음부터 다시 디버깅을 해보았다.

0040100E까지 실행한 결과 리턴값이 1이되었다.(EAX는 리턴 값을 저장한다.)

00401018에서 처음보는 함수가 등장했다. GetDriveTypeA라는 함수인데 WIN32 API에서 사용하는것 같다.

그래서 구글링을 해보았다. https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getdrivetypea

CD-ROM으로 인식되게 하려면 리턴 값이 3이되어야 한다.

그럼 다시 돌아가서 디버깅을 진행해보자.

아까 0040100E까지 실행한 결과 리턴값이 1이되었다.

004010D에서 EAX값은 3으로 변경되었다.

0040101E에서 ESI의 값은 1 증가하였다.

결국 어셈블리 명령어에 따라서 증감을 한다 

JE라는 명령어를 통해서 Z가 1이면 해당 주소(성공메세지가 실행되는 곳으로 이동한다.)

EAX는 2번 감소 그래서 3-2 = 1 EAX의 값은 1이다.

0040101E 에서 DEC  

00401023 에서 DEC 

ESI는 3번 증가 그래서 0 + 3 = 3이다.

0040101D에서 INC

00401021에서 INC

00401022에서 INC

이렇게 되면 CMP로 비교를 할때 ESI 와 EAX가 값이 일치하지 않아서 에러창이 실행되는 곳으로 이동할 것이다.

(1과 3은 다르기 때문에 Z(ZeroFlag)가 0이되기 때문에 JE 구문이 실행되지 않는다.)

아까 보았던 GetDriveTypeA함수가 CD-Rom으로 인식되기 위해서는 리턴값이 3이되야 한다고 했다.

그래서 EAX값을 5로 바꿔주면 EAX는 2번 감소하기 때문에 3이될것이고, ESI는 원래 3이 되기때문에 비교를 했을때 

일치하게 된다. 따라서 성공메세지를 실행하는곳으로 이동할것이다.

EAX 값을 5로 변경해주고 디버깅을 계속 진행해보면 에러창이 실행되는 곳으로 이동하는데

이것은 CMP를 할때 Z의 값이 0이기 때문에 JE 구문이 실행되지 않는다.

따라서 JE 구문이 실행이되게 하려면 Z의 값을 1 증가 시키면 된다.

성공!

따라서 문제의 답은 5

gcd 즉, 최대공약수를 구하는 문제이다. 

A = 66528

B = 52928 

이 두 숫자의 최대공약수를 구하면된다. 

pwntools 와 telnet_example.py 파일을 이용해서

nc socket.cryptohack.org 연결 한다.

crypto{3ncod3-d3c0d3_3nc0d3}

아래의 문자열을 바이트 단위로 디코딩 후 Base 64로 인코딩

crypto/Base+64+Encodng+is+Web+Safe/

아래의 16진수 hex 값을 바이트로 디코딩 

crypto{You_will_be_working_with_hex_strings_a_lot}

배열안에 있는 정수 값들을 아스키 코드 값으로 변환 시켜주면 된다.

crypto{ASCII_pr1nt4bl3}