holinder4S

## 34C3 CTF_2017(readme_revenge, pwn)

[Summary]

1. printf()함수의 소스코드를 보고 동작 방식을 간략하게 이해해야 한다.

2. __parse_one_specmb() 소스코드를 보고 일반적이지 않은 루틴이 실행되도록 조작해야한다.

3. libc_argv가 조작 가능할 때 이를 이용하는 함수를 찾아본다.

=> __fortify_fails()함수, malloc_printerr()함수, do_dlopen()함수 etc..

4. overflow 시켜 libc_argv, __printf_function_table, __printf_modifier_table, 

__printf_arginfo_table을 조작해 eip를 control 하고 위 함수를 이용해 메모리에 있는 flag를 

출력시킨다.

[Analysys]

 우선 문제를 받아보면 static compile되어 있는 것을 확인할 수 있고, IDA를 통해 디컴파일 해보면

아래 [그림 1]과 같이 정말 간단한 바이너리라는 것을 알 수 있다.

[Exploit Code]  - readmerevenge_exploit.py

끝~!

## 34C3 CTF_2017(simpleGC, pwn)

[Summary]

1. C로 Garbage Collection을 구현한 프로그램에서 UAF취약점을 이용하는 문제이다.

2. user Add를 하는 과정에서 group을 변경해도 group의 reference Count가 줄어들지 않는다.

=> 이를 이용하여 byte형 refcount를 0x00으로 만든 후

=> Garbage Collection 스레드에 의해 free된다.

3. user3의 구조체와 과 user1의 group_name 구조체가 공유되도록 만든다.

=> group_name에 strlen got로 변조하면 

=> user3의 group_name_ptr이 strlen got로 변하게 되고

=> leak과 got overwrite가 가능해짐

4. 원래는 libc 2.26버젼에 새롭게 추가된 t-cache를 우회해야 리모트 exploit이 가능.

=> 관련 내용은 차후 추가 예정..

[Exploit Code]  - sgc_exploit.py

[Reference]

1. https://github.com/epadctf/34c3/blob/master/SimpleGC/win.py

2. https://github.com/bkth/34c3ctf/tree/master/SimpleGC

2. http://tukan.farm/2017/07/08/tcache/

## HITCON CTF_2017(start, pwn)

[Summary]

1. python 모듈인 pwntool과 같은 역할을 하는 ruby모듈 pwntool을 사용하는 문제

=> https://github.com/peter50216/pwntools-ruby

2. server.rb가 실행되는데 eval()함수로 루비 코드를 실행시킨다.

3. start 바이너리는 간단한 bof 취약점이 있고, static compile되어 있다.

=> syscall을 이용한 rop를 하면 된다.

4. canary가 있으므로 0x18바이트만큼 덮어 씌우고 출력하면 canary leak 가능.

[Exploit Code]  - start_exploit.rb

## CSAW CTF_2017(prophecy, rev)

[Summary]

1. LLVM으로 난독화된 문제이다.

2. 베이직 블록만 잘찾고 브포걸고 실행하면 된다.

3. 그래프 모드로 봤을 때 젤 아래에 있던 블럭들의 첫 번째만 브포걸고 실행하고

4. 베이직 블락이라고 생각되는 곳에서 디컴파일하면서 분석하면 된다.

5. 페이로드 중간에 비교하지 않는 부분은 \x00을 넣어서 뒤에 페이로드가 깨지지 않게 한다.

[Analysis] 

 이 문제는 간단하게 요약하면 LLVM으로 난독화되어 있는 아주 간단한 프로그램이다. 프로그램을 실행하여

전반적인 프로그램 흐름을 설명하면 우선 아래 [그림 1]과 같이 실행된다.

[그림 1] 프로그램 실행

 위 그림을 보면 secret name을 받고 unlock할 key를 입력받는데 아무거나 입력했더니 그냥 

프로그램이 종료가 된다. 그래서 IDA로 까보았다. 처음에는 LLVM 난독화는 리버싱해본적이 전혀 없어서 

그냥 진자 IDA로 동적디버깅 F10계속 눌러가면서 내가 이해할 수 있는 코드 나오면 분석하고 다시 반복하는

형태로 진행했다. 그런데 이렇게 하다보니 정말 답도 없을거 같아서 LLVM 관련된 롸업을 쭉보다보니까 

어떤 변수에 값을 집어넣고 계속 상태변화하는 것으로 다음 베이직 블럭을 가리킨다는 것을 알게되었고

그것을 알고나니까 쓸데없는건 다 생략하고 필요한 부분만 브포를 걸면 되겠구나라고 생각이 되었다.

 우선 디컴파일을 한 소스코드를 보면 아래 [그림 2]와 같다.

[그림 2] 디컴파일 소스

[그림 2]를 보면 알겠지만 뭔가 의미 있는 코드 같으면서도 위에 if문 같은곳에서 v534랑 비교하고 점프하고 

이런 루틴이 굉장히 많다. 진짜로 시간이 넘쳐나면 그냥 이런곳에다가 하나하나 다 브포 걸고 차례대로

F10만 연타하면 언젠가는 풀릴거지만 대회니까 좀 빠른 방법을 생각하던 도중 아래 [그림 3]의  그래프 뷰를 

보게 되었다.

[그림 3] IDA 그래프 뷰

 뭔가 젤 아래만 보면 전체 프로그램을 다 보는 것 같았다. 그래서 젤 아래 블럭들만 전부 브포를 걸었다.

그리고 IDA로 동적디버깅을 하니까 전부 basic블락은 아니었지만 대부분이 의미있는 코드 부분이었고 이제

이걸 기반으로 하나하나 분석해보도록 하겠다.

 우선 첫 번재 루틴인 secret name을 입력받는 루틴은 [그림 4]와 같다.

[그림 4] 첫 번째 Basic Block

 위 [그림 4]의 코드를 분석해보면 그냥 간단하게 출력할 것 출력하고 read()함수로 secret name을 입력 받는다.

이제 두 번재 루틴을 보면 아래 [그림 5]와 같다.

[그림 5] 두 번재 Basic Block

 여기서는 secret name으로 입력 받은 것의 길이를 구한 후 -1부분에 \x00을 넣는다. 

 이제 세 번째 루틴을 보면 아래 [그림 6]과 같다.

[그림 6] 세 번째 Basic Block

 여기서는 unlock할 key값을 입력하라고 하고 실제로 read()함수로 사용자 입력을 받는다. 그게 다다.

그럼 이제 네 번째 루틴을 볼 차례다. 아래 [그림 7]을 보자.

[그림 7] 네 번째 Basic Block

 여기서는 unlock_key 값의 길이를 구한 다음 \x00을 마지막에 집어넣는다. [그림 5]와 비슷한 행위를 한다.

여기서 이 부분은 나중에 꽤 중요해지는데 이걸 제대로 몰랐다가 나중에 삽질을 엄청나게 했다.

 이제 다섯 번째 루틴을 볼 텐데 코드는 아래 [그림 8]과 같다.

[그림 8] 다섯 번째 Basic Block

 여기서는 secret name에 ".starcraft"라는 문자열이 있는지 검증하는 루틴이다. 여기서 만약

".starcraft"라는 문자열이 포함되어 있지 않으면 그냥 종료된다.(v33 != 0에서 확인)

 이제 여섯 번째 루틴을 볼텐데 코드는 아래 [그림 9]와 같다.

[그림 9] 여섯 번째 Basic Block

여기서는 그냥 "[*] Interprting the secret...."이라는 문자열을 출력하고 끝이다.

일곱 번째 루틴을 보자. 코드는 아래 [그림 10]과 같다.

[그림 10] 일곱 번째 Basic Block

여기서는 그냥 /tmp경로를 얻어와서 "/tmp/" + [secret name]을 파일로 하나 만든 다음 key값을 그 파일에다가

쓰는 역할을 수행한다. 그리고 그 파일을 읽어들여와서 file handle을 저장하고 있다.

여덟 번째 루틴을 보자. 코드는 아래 [그림 11]과 같다.

[그림 11] 여덟 번째 Basic Block

여기서는 keyfile을 읽어들여와서 4바이트만큼 읽어들이고 0x17202508과 비교를 하는데 아마

의미적으로 생각하자면 20170825와 비교를 하는 것같다.(년월일)

여기서 비교 검증에 실패하면 프로그램은 또 종료되므로 key 값은 첫 4바이트는 "\x08\x25\x20\x17"

이어야 한다.

아홉 번재 루틴을 보자. 코드는 아래 [그림 12]와 같다.

[그림 12] 아홉 번째 Basic Block

여기서는 또 다시 키 파일에서 8바이트를 읽어들여와 저장하고 또 1바이트를 읽어들여와 저장한다.

이번 루틴에서는 비교하는 루틴은 없으므로 나중에 이를 다른 Basic Block에서 비교할 것이라고 

생각할 수 있다. 우선은 8바이트 1바이트를 읽어들였다는 것만 기억하면 된다.

열 번째 루틴을 보자. 코드는 아래 [그림 13]과 같다.

[그림 13] 열 변째 Basic Block

 여기서는 아까 [그림 12]에서 1바이트 읽어들여온 키값이랑 79라는 숫자랑 비교를 한다. 

키값 비교가 있는 것이다. 여기서는 2가지 경우가 있는데 나는 79보다 작으면 왠지 프로그램 종료할 것 같았고 

예상이 맞았다. 따라서 비교를 할때 79이상이어야 한다.

열한 번째 루틴을 보자. 코드는 아래 [그림 14]와 같다.

[그림 14] 열한 번째 Basic Block

 여기서는 아까 [그림 13]에서 비교한 키 값과 이제 90과 비교를 한다. 아마 키 값의 조건은 

79이상 90미만 이어야 하는 것 같다.

 열두 번째 루틴을 보자. 코드는 아래 [그림 15]와 같다.

[그림 15] 열두 번째 Basic Block

 여기서는 [그림 13, 14]에서 비교한 키 값이랑 또비교를 한다. 그런데 이번엔 부등호가 아니라

equal로 비교를 한다. 아마 키 값의 조건은 79(0x4f, 'O')인 것 같다. 따라서 두 번재로 비교하는 키 값은 

0x4F이어야 한다.

열세 번째 루틴을 보자. 코드는 아래 [그림 16]과 같다.

[그림 16] 열세 번째 Basic Block

 여기서는 그냥 이상한 문구를 출력하고 끝낸다. 아마 키 값 검증을 성공해서 다음 스테이지로 넘어가는 것 같다.

열네 번째 루틴을 보자. 코드는 아래 [그림 17]과 같다.

[그림 17] 열네 번째 Basic Block

 여기서는 또 다시 키 파일에서 키 값을 1바이트 읽어들여온다. 아마 또 키검증을 하는 루틴이 있을 것 같다.

열다섯 번째 루틴을 보자. 코드는 아래 [그림 18]과 같다.

[그림 18] 열다섯 번째 Basic Block

 여기서는 [그림 17]에서 읽어온 key값이랑 2랑 비교를 한다. 아마 아까와 비슷하게 2이상이어야 하는 

조건인거 같다고 생각을 하면 된다.(물론 2가지경우가 있으므로 둘다 해봐야 한다.)

열여섯 번째 루틴을 보자. 코드는 아래 [그림 19]와 같다.

[그림 19] 열여섯 번째 Basic Block

 여기서는 아까 그 키값과 3이랑 비교를 한다. 아마 2<= key <3이 이번 검증의 조건인 듯하다. 

이 조건에 만족하는 건 2밖에 없으므로 세번째로 검증하는 key값의 조건은 0x02이다.

열일곱 번째 루틴을 보자. 코드는 아래 [그림 20]과 같다.

[그림 20] 열일곱 번째 Basic Block

 여기서는 [그림 16]과 비슷하게 이상한 문구를 출력하는 역할만 한다. 아마 아까와 마찬가지로

키 값 검증이 끝났으니 다음 스테이지로 넘어간다는 뜻으로 이해하면 된다.

열여덟 번째 루틴을 보자. 코드는 아래 [그림 21]과 같다.

[그림 21] 열여덟 번째 Basic Block

여기서는 키 파일에서 4바이트만큼 key값을 읽어들여와서 813라인에서 0xE4EA93과 비교를 한다.

아마 네번째로 비교하는 키 값의 조건은 0xE4EA93인 것 같다.

열아홉 번째 루틴을 보자. 코드는 아래 [그림 22]와 같다.

[그림 22] 열아홉 번째 Basic Block

여기서는 여태까지의 키 값 검증이 끝난 후와 마찬가지로 이상한 문구를 출력하고 끝난다.

스물 번째 루틴을 보자. 코드는 아래 [그림 23]과 같다.

[그림 23] 스물 번째 Basic Block

여기서는 또 키 파일에서 7바이트만큼 읽어들여와 그 키 값과 0x4C55544152455A와 비교 검증을 한다.

아마 다섯 번째로 비교하는 key값의 조건은 "\x5A\x45\x52\x41\x54\x55\x4C"인 것 같다.

스물한 번째 루틴을 보자. 코드는 아래 [그림 24]와 같다.

[그림 24] 스물한 번째 Basic Block

 후.. 끝이었다고 생각했는데 끝이 아니어따... F9누르면서 그냥 디버깅하면 빠르게 하니까 걱정하지 않아도된다...

여기서도 그냥 이상한 문구를 출력하고 끝이다.

스물두 번째 루틴을 보자. 코드는 아래 [그림 25]와 같다.

[그림 25] 스물두 번째 Basic Block

후.. 마지막 키값 검증이라고 생각하면서 침착하게 보면 fread()로 키 파일에서 6바이트만큼

키값을 읽어들여와 0x444556415300과 비교한다. 여섯 번째 키 값의조건은 "\x00\x53\x41\x56\x45\x44"이다.

스물세 번째 루틴을 보자. 코드는 아래 [그림 26]과 같다.

[그림 26] 스물세 번째 Basic Block

ㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎ.... 끝이 아니었다. 키 값 검증이 아직 더 남았나보다.

스물네 번째 루틴을 보자. 코드는 아래 [그림 27]과 같다.

[그림 27] 스물네 번째 Basic Block

 여기서 또 키 값 검증을 하는데 키 파일에서 4바이트만큼 읽어들여와서 0x4C4C4100과 비교를한다.

7번째 키값의 조건의 "\x00\x41\x4c\x4c"이다.

스물다섯 번째 루틴을 보자. 코드는 아래 [그림 28]과 같다.

[그림 28] 스물다섯 번째 Basic Block

ㅇㅇ. ㅇㅋ? ㅇㅋㅇㅋ. ㅇㅇㅇ. ㄱㄱ

스물여섯 번째 루틴을 보자. 코드는 아래 [그림 29]와 같다.

[그림 29] 스물여섯 번째 루틴

오오오오오오오오오오오오민ㅇ롬ㄴ아ㅓ로마더로미ㅏㅈㄷ로!!!!!!!!!

드디어.. 

system("cat flag");가 눈에 보였다!

이제 여기까지 분석한 걸 정리하면 아래 [그림 30]과 같다.

[그림 30] key 값 조건

????????는 8바이트고 검증을 안한다.

이제 이렇게 페이로드를 파이썬 코드를 짜서 보내면 되는데 여기서 나는 문제가 생겼었다. [그림 7]의 설명 중에

삽질을 했다라는 빨간 줄이 있는데 키 값을 읽어들여서 마지막 바이트에 "\x00"을 넣는데 이게 

"\x08\x25\x20\x17" + "AAAAAAAA" + "\x4F" + "\x02" + "\x93\xEA\xE4\x00" + "\x5A~~~" + ~~

이렇게 페이로드를 보내면 100% 실패한다. 

 왜냐하면 strlen(key)-1부분에 "\x00"을 넣기 때문에 "\xE4"부분에 "\x00"이 채워져서 페이로드가 망가진다.

그러면 어떻게 해야하냐면 ????????부분에 그냥 중간에 "\x00"을 넣어주면 된다. 그럼 strlen()-1을 해도 

????????부분에 "\x00"이 들어가고 ????????부분은 검증을 안하므로 페이로드도 안깨지고 정상적으로

플래그를 얻을 수 있다.

근데 이 글 적다보니 사망 플래그 각이나온다...

긴 글 읽어주셔서 감사합니다. ㅠㅠ

 [Exploit Code] - prophecy_exploit.py

[Get Flag~~!!!!]

[그림 31] flag

끝~!!!!

## HDCON_2017(Fabuary, rev)

[Summary]

1. Android APK 리버싱 & native library 리버싱 문제이다.

2. 가위바위보를 하는 어플리케이션이 있는데 17916점을 넘기면 이기는 어플이다.

3. 한번 이길 때마다 1점씩오르며 각 가위,바위,보를 34999번이상 시도할 수 없다.(수동 방지인듯..)

4. rpc_calc()함수에서 score가 17916점을 넘기면 하드코딩된 값과 xor연산을 하여 키값을 생성해냄.

5. CallMe에서 해당 키값을 이용하여 하드코딩된 encrypt된 flag를 ck()를 호출하여 decrypt함.

[Analysis] 

 이 문제는 간단하게 요약하면 가위바위보를 하는 어플리케이션이 있는데 이기면 Score가 1점 올라가는 시스템이다. 

해당 어플리케이션은 아래 [그림 1]과 같다.

[그림 1] HDcon 어플리케이션 UI

 이제 이 apk를 jadx로 분석해보면 크게 2개의 중요한 루틴이 있다. 첫 번째는 가위, 바위, 보 버튼을 눌렀을 때 동작하는 

ClickListener인데 코드는 아래 [그림 2]와 같다. 

[그림 2] Paper button ClickListener 코드

 위 [그림 2]에 나온 코드는 보를 클릭했을 때의 동작을 나타내는 코드인데 나머지도 코드가 비슷하므로 이것만 

분석하면 된다.

 우선 qq라는 변수에 시스템이 랜덤으로 생성해 낸 가위, 바위, 보 중 하나를 넣고 '보'를 의미하는 3을 첫번째 인자로

qq를 2번째 인자로 rps_calc라는 함수를 호출하는데 이는 native library에 있으므로 해당 라이브러리를 IDA로

분석해야한다. 일단은 코드를 쭉 보면 rps_calc()함수의 리턴 값을 setText()로 어플리케이션에 출력하는데 

2017일 경우는 특별한 동작을 한다. "mm"에다가 rps_calc()함수의 리턴 값을 넣고 send broadcast를 한다.

 대충 딱 봐도 이게 문제를 풀었을 때 동작하는 루틴이겠구나라고 알 수 있는 부분이다.

이제 그럼 rps_calc()를 분석해보도록 하겠다. IDA로 library를 열어서 rps_calc()함수를 들여다보면 아래 [그림 3]

과 같다.

[그림 3] rps_calc() 함수 디컴파일

 다른 부분은 볼필요가 거의 없다. 그냥 이겼을 때 "You Win"을 출력하고 졌을 때 "You Lose"를 출력하고 뭔가 이상한 

걸 탐지하면 이상하다고 출력하는 부분이다. [그림 3]의 코드를 보면 score > 17916인 분기문을 볼 수 있는데 딱봐도

score가 17916이상이면 뭔가를 하고 아까 분석했던 것처럼 2017이 들어있는 문자열이 나오겠구나 생각할 수 있다.

 그럼 그안에를 보면 하드코딩된 값과 0x58을 xor하는 것을 볼 수 있는데 이걸 그냥 직접 해보면 "HD-C-O-N-2-0-1-7"

이 나온다. 이제 이걸로 아까 [그림 2]에서 분석했던 걸 참조하면 mm변수에 해당 키값을 넣고 send한다는 것을 

알 수 있다.

 그럼 이제 apk에서 봐야한다고 했던 2번째 부분을 보면 되는데 바로 CallMe이다. 코드는 아래 [그림 4]와 같다.

[그림 4] CallMe 코드

 이 코드를 보면 mmm 변수에 mm으로 받은 값을 집어넣고 하드코딩된 encrypted flag와 뭔가 

쿵짝쿵짝을 하는걸 알 수 있는데 키 값이 16자이므로 16자넘어가면 첨부터 key값 사용하는 루틴이 보이고

핵심 decrypt하는 루틴은 ck()함수에서 하는 것이라고 생각할 수 있다. ck()함수는 index를 첫 번째 인자로,

key값dmf 2번째 인자로, decrypted flag를 3번째 인자로 받고 호출된다. 그럼 이제 IDA로 ck()함수를 

분석하면 되는데 디컴파일된 결과는 아래 [그림 5]와 같다.

[그림 5] ck() 함수 디컴파일

 위 [그림 5]의 코드도 굉장히 간단한데 index값을 기준 삼아 case문으로 분기를 나누고 그냥 시프트 연산

xor연산으로 쿵짝쿵짝하고 리턴하는 간단한 함수이다. 따라서 이건 파이썬으로 똑같이 짜주면 decrypt가 

가능하다. 그렇게 나온 결과는 "[*] flag is : W@tching_7th_Sunse7_in_B@li" 이었다.

[Exploit Code] - rock_exploit.py

[Get Flag~~!!!!]

[그림 6] flag

끝~!

## ASIS CTF_2017(mrs. hudson, pwn)

[Summary]

1. rop를 이용해 scanf("%s",bss); 호출

=> pop_rdi, pop_rsi_r15 가젯 이용

=> 취약점이 터지는 함수가 scanf()여서 scanf_plt주소의 0x20부분이 null처리됨.

=> 따라서 got로 점프하는 주소 바로 다음 명령어 즉, got에 주소가 없을 경우 plt+0x6으로 다시 돌아오는데

그 주소를 이용.

=> 쉘코드 입력하고 exploit!

[Exploit Code]  - mrshudson_exploit.py

[Get Flag~~!!!!]

[그림 1] flag확인

끝~!

## Tokyo Westerns CTF_2017(swap, pwn)

[Summary]

1. memcpy <=> read : swap기능을 이용해 바꿔치면 memcpy()만 read로 변경된다.(arbitrary mem write 가능해짐)

2. oneshot gadget을 얻기 위해 libc leak을 해야한다.

=> setvbuf_got를 puts_plt로 덮어씌운다.

=> exit_got를 start의 주소로 덮어씌워 setvbuf를 실행시킨다.(결과적으로 puts(stderr))

=> stderr를 stdin의 주소로 바꾼다.(for puts(_IO_2__1_stdin's addr))

3. exit_got를 oneshot_gadget으로 덮어씌운다.

[Exploit Code]  - swap_exploit.py

[Get Flag~~!!!!]

[그림 1] flag 확인

끝~!

## Samsung CTF_2017(Easyhaskell, rev)

[Summary]

1. Custom Base 64를 이용한 문제이다.

2. 파일의 이름인 argv[0]을 input으로 Custom Base64 인코딩한 값을 출력하는 프로그램이다.

3. 2가지 풀이법이 존재한다.

=> 파일명 브루트포싱

=> Base 64 테이블을 알아내어 바로 디코딩(하지만 이것도 브루트포싱하였다.)

[Analysis] 

[그림 1] Easyhaskell 문제

 이 문제는 간단하게 요약하면 argv[0]을 인자 값으로 커스텀 Base64를 해 결과 값으로 출력하는 프로그램이다.

이 문제를 처음에는 IDA로 열어서 분석하려고 했으나 haskell이라 그런지 조금 분석하기 모호했다. 그래서 우선

처음 IDA로 분석했을 때는 이 프로그램은 프로그램 인자 값을 받아서 무언가를 한다는 것 정도만 확인하였다.

 이제 이 프로그램을 알기 위해서 실행을 해보았는데 인자 값(argv[1])을 주고 프로그램을 실행하든 안주고 실행하든

아래 [그림 2]와 같이 똑같은 결과를 리턴했다.

[그림 2] argv[1]의 영향

 뭔가 이상해서 argv[0], 즉 파일 이름을 변경하고 실행해보았더니 아래 [그림 3]과 같이 프로그램의 결과 값이 

다른 것을 확인할 수 잇었다.

[그림 3] argv[0](파일이름)의 영향

 위 [그림 3]의 결과를 보고 딱 base64가 떠올랐다. 그래서 base64 인코딩 형태가 맞는지 아래 [그림 4]와 같이 

몇 가지 실험을 했다. 먼저 "1"의 결과가 "CH55"가 나왔고, "11"의 결과는 "C)Q5", "111"의 결과는 "C)Q]", "1111"의

결과는 "C)Q]CH55"가 나왔다.

[그림 4] Base64의 특성을 확인하는 실험

 우선 위 [그림 14]의 결과를 보면 패딩 값이 "5"이고 3글자를 주기로 해시 값에 4글자씩 Output으로 나오는 

것을 확인할 수 있다. base64의 원리에 대해 간단하게 그림으로 설명한 블로그가 있다. 해당 블로그를 확인하고

따라오면 된다. 말로 설명하면 3글자 각 8비트 씩을 쭉 나열하여 6비트씩 쪼개어 4글자로 만드는데 각 6비트의 

값은 base64테이블의 index를 가리킨다. 이 때 base64의 테이블이 통상적으로 사용하는 것이 흔히 말하는 

base64 이고, 이 테이블을 사용자가 원하는대로 바꾼 것이 custom base64이다.

 참고 블로그 주소 : http://bbolmin.tistory.com/46

 이제 이 문제가 Custom Base64 라는 것을 눈치챘고 테이블을 알아내야 하는데 테이블의 경우 바이너리에 

하드코딩되어 있을 수도 있고 어떠한 알고리즘으로 만들어낼 수도 있지만 그렇게 문제를 해결하지 않았다.

 이 테이블을 직접 000000~111111 까지 64개의 테이블을 직접 만들었는데 만든 방식은 아래와 같다.

1) 앞의 6 * 3 비트는 아무 값으로 채운다. (Plain Text가 printable 하도록) => 마지막 비트는 1로 

   세팅해서 2번의 결과ㅏ가 printable 한 문자가 나오도록 조작한다.

2) 마지막 6bit 를 000000 부터 111111 까지 만들어 프로그램을 실행한 후 마지막 바이트를 확인후

   테이블에 추가한다.

3) 2번의 방법에서 printable 하지 않은 경우 3번째 6비트 값을 조작하여 2번과 비슷한 방법으로 

   알아낸다.

 위 과정을 통해 테이블을 구해보면 아래 [그림 5]와 같은 테이블을 얻을 수 있다.

[그림 5] 테이블 구하기

  이제 이렇게 구해진 테이블을 이용하여 base64 디코딩하는 루틴을 파이썬으로 작성해서 돌리면 문제에서

주어진 Flag - "“=ze=/<fQCGSNVzfDnlk$&?N3oxQp)K/CVzpznK?NeYPx0sz5"가 아래 [그림 6]과

같이 복호화되어 나타나게 된다.

[Exploit Code] - easyhaskell_exploit.py

[Get Flag~~!!!!]

[그림 6] flag 확인

끝~!

## Samsung CTF_2017(Buildingblocks, Coding)

[Summary]

1. 어셈블리 블럭들의 조각을 던져줌.

2. 이 어셈블리 블럭들의 조각을 Segmentation Fault가 나지 않도록 순서만 맞춰주면 됨.

3. 각 블럭별로 eax레지스터가 비교값과, 연산을 끝낸 값을 구할 수 있음.

4. 구한 eax값과 다음 블럭의 비교값과 비교해 같으면 이어붙이면 됨.(이 조건일 때 seg fault가 안남.)

[Analysis] 

[그림 1] Buildingblocks 문제

 이 문제는 코딩을 해서 어셈블리 블럭을 완성시키면 플래그를 주는 문제였다. 위 문제서버로 접속하면 아래

[그림 2]와 같이 주어지는 Base64로 인코딩된 문자열들은 x64머신에서 돌아가는 코드이며 각각의 블럭들을

잘 이어붙여 실행했을 때 Segmentation Fault가 뜨지 않도록 하는 가장 긴 코드를 만든 후 바이트 코드를 

sha256 hexsum을 서버에 보내달라고 한다.(총 10개의 스테이지가 있다.)

[그림 2] 문제 서비스 분석

 그래서 위 base64로 인코딩된 문자열들을 하나하나 디코딩해 바이트 코드로 만든 후 pwntool 모듈을 이용해

어셈블리어로 변환하면 아래 [그림 3]과 같이 여러 개의 코드 뭉치로 나타난다.

[그림 3] 11개의 코드 뭉치 중 일부

 위 [그림 3]을 보면 여러 개의 코드 뭉치들 중 일부를 나타낸 것인데 11개의 코드 뭉치가 위 [그림 3]의 

아래와 같이 cmp문으로 시작하지 않고 eax에 값을 지정하는 유형의 코드뭉치 하나가 있고, 나머지는 전부

위 코드뭉치와 같은 유형이다.

 이제 이 코드뭉치들이 Segmentation Fault 가 나지 않도록 이어 붙이기 위해서는 cmp문 바로 아래 je로

절대로 점프해서는 안된다. 따라서 각각의 코드 뭉치들의 비교 값과 각각의 코드뭉치에서 최종적으로 나오는 

eax의 값을 비교하여 같은 것을 이어 붙여야 한다. 따라서 아래 [그림 4]와 같이 각 코드뭉치에 대해

[비교값, 최종 eax 값]만 나타내어 보면 아래 [그림 4]와 같다.

[그림 4] 코드뭉치 단순화

  위 리스트를 보고 eax값과 cmp 비교 값이 같은 것끼리 이어 붙이는데 앞서 설명한 cmp문으로 시작하지 

않는 유형은 무조건 코드뭉치의 제일 앞이므로 여기서부터 eax값과 비교문이 같은 0번째가 바로 뒤를 잇고

그 다음이 4번째... 이렇게 쭉 가면 [그림 4]의 아래에 나오는 리스트처럼 코드블럭의 순번을 알 수 있고

이를 바이트 코드로 이어붙여 sha256한 값을 서버에 보내는 과정을 stage10까지 반복하면 아래 [그림 5]와 

같이 플래그를 확인할 수 있다.

[Exploit Code] - buildingblocks_exploit.py

[Get Flag~~!!!!]

[그림 5] flag 확인

끝~!

## Samsung CTF_2017(dfa, defense)

[Summary]

1. Integer overflow 취약점을 패치하는 문제

2. read에서 bof 취약점이 터지도록 유도하는 취약점을 패치하면 됨.

[Analysis] 

[그림 1] dfa 문제

 
 이 문제는 Defense 문제로 소스코드가 주어지고 거기에 있는 하나의 취약점을 찾아 패치를 한 후 서버에 보내면

되는 문제였다. dfa.zip파일을 다운로드 받으면 4개의 소스파일이 주어지는데 그 중 취약점이 존재하는 소스코드는

"auto.c"였다. 이 소스 코드 중 취약점이 존재하는 부분은 아래 [그림 2]와 같다.

[그림 2] "auto.c" 중 취약한 소스코드 일부

 위 [그림 2]의 if 문 내부에 namelen + 1 > 0x100에서 overflow가 발생하여 조건문을 우회할 수 있는 

integer overflow 취약점이 존재한다. 조금 자세히 풀어쓰자면 namelen에 0xffffffff라는 값이 들어갔다고

쳤을 경우 namelen + 1의 값은 0이 되고 0과 0x100과 비교했을 때 조건문을 우회할 수 있게 된다.

 이 때 아래 빨간 네모박스의 코드에서 read()함수를 실행하여 namelen(0xffffffff)만큼 linebuf 배열에 

사용자 입력을 받으면서 최종적으로 버퍼 오버플로우 취약점을 유발시키게 된다.

 따라서 위 취약점은 아래 [그림 3]과 같이 패치할 수 있다.

[그림 3] 취약한 소스코드 패치

  이렇게 취약한 소스코드를 패치한 후 해당 파일을 base64하여 서버에 전송하면 아래 [그림 4]와 같이

플래그를 확인할 수 있다. 소스코드를 base64로 인코딩하여 전송하는 스크립트는 아래와 같다.

[Exploit Code] - dfa_exploit.py

[Get Flag~~!!!!]

[그림 4] flag 확인

끝~!