반응형

boost 라이브러리를 vcpkg로 설치하게 되면 아래와 같은 에러가 발생한다.


'mt' not recognized ~~~


위의 에러는 SDK의 mt.exe를 찾지 못하여 발생하는 것으로, 먼저 SDK가 설치되어 있는지 확인해본다.


visual studio 버전에 맞는 SDK를 설치하게 되면 windows 10 기준으로


C:\Program Files (x86)\Windows Kits\10


에 SDK가 설치되는데 운영체제에 따라서 폴더들이 나눠져있다.



SDK 경로내에 bin\10.0.15063.0\x86을 들어가면 mt.exe, mt.exe.config이 존재하는데,


해당 파일을 vcpkg 경로의 installed\{TARGET_TRIPLET}\tools\boost-build에 복사한다.


그 다음 boost-modular-build.cmake에 


    ######################

    # Perform build + Package

    ######################


부터 if 문이 존재하는데 해당 if문 안에 


file(COPY ${BOOST_BUILD_PATH}/mt.exe ${BOOST_BUILD_PATH}/mt.exe.config DESTINATION ${_bm_SOURCE_PATH})


를 추가하면 빌드가 슥슥 잘된다.


근데, zlib이나 bzip2같이 dependency들은 CMakeTmp 폴더에 복사해주면 되겠다.

'자료' 카테고리의 다른 글

[Pwntools] pyserial uninstall fail시  (0) 2018.07.17
[Python] Mutation Fuzzer  (0) 2018.05.16
Abusing File Structure  (0) 2018.01.04
[C++] Python format 구현  (0) 2017.12.03
[Ubuntu] upgrade시 용량부족으로 인한 문제 해결  (0) 2017.10.12
블로그 이미지

KuroNeko_

KuroNeko

,

Abusing File Structure

자료 2018. 1. 4. 16:38
반응형

Link


호옹

'자료' 카테고리의 다른 글

[Python] Mutation Fuzzer  (0) 2018.05.16
[Library] vcpkg boost 1.66 설치에러 해결방법  (0) 2018.02.01
[C++] Python format 구현  (0) 2017.12.03
[Ubuntu] upgrade시 용량부족으로 인한 문제 해결  (0) 2017.10.12
[Library] vcpkg  (0) 2017.07.26
블로그 이미지

KuroNeko_

KuroNeko

,

[C++] Python format 구현

자료 2017. 12. 3. 02:39
반응형

Python 사용하다가 format이 편해져서 C++에도 있으면 좋겠다 싶어서 만들었습니다.


아래는 소스코드들이예요.




github : https://github.com/Kur0N3k0/util

'자료' 카테고리의 다른 글

[Library] vcpkg boost 1.66 설치에러 해결방법  (0) 2018.02.01
Abusing File Structure  (0) 2018.01.04
[Ubuntu] upgrade시 용량부족으로 인한 문제 해결  (0) 2017.10.12
[Library] vcpkg  (0) 2017.07.26
Windbg 명령어  (0) 2017.01.31
블로그 이미지

KuroNeko_

KuroNeko

,
반응형

dpkg -l linux-* | awk '/^ii/{ print $2}' | grep -v -e `uname -r | cut -f1,2 -d"-"` | grep -e [0-9] | grep -E "(image|headers)" | xargs sudo apt-get -y purge

'자료' 카테고리의 다른 글

Abusing File Structure  (0) 2018.01.04
[C++] Python format 구현  (0) 2017.12.03
[Library] vcpkg  (0) 2017.07.26
Windbg 명령어  (0) 2017.01.31
[펌] 동적 메모리 관리  (0) 2016.12.26
블로그 이미지

KuroNeko_

KuroNeko

,

[Library] vcpkg

자료 2017. 7. 26. 02:40
반응형

vcpkg 설치

  1. 소스코드 가져오기

     C:\>git clone https://github.com/Microsoft/vcpkg.git c:\work.vcpkg
     Cloning into 'c:\work.vcpkg'...
     ...
    
  2. 빌드

     C:\work.vcpkg>c:\work.vcpkg\bootstrap-vcpkg.bat
     Microsoft (R) Build Engine version 14.0.25420.1
     ...
    
  3. Visual Studio 연동

     C:\work.vcpkg>vcpkg integrate install
     Applied user-wide integration for this vcpkg root.
    
     All MSBuild C++ projects can now #include any installed libraries.
     Linking will be handled automatically.
     Installing new libraries will make them instantly available.
    
     CMake projects should use -DCMAKE_TOOLCHAIN_FILE=C:/work.vcpkg/scripts/buildsystems/vcpkg.cmake
    
     C:\work.vcpkg>
    
  4. 패키지 설치

     C:\work.vcpkg>vcpkg install boost:x86-windows boost:x86-windows-static boost:x64-windows boost:x64-windows-static
     C:\work.vcpkg>vcpkg install curl:x86-windows curl:x86-windows-static curl:x64-windows curl:x64-windows-static
     C:\work.vcpkg>vcpkg install sqlite3:x86-windows sqlite3:x86-windows-static sqlite3:x64-windows sqlite3:x64-windows-static
     C:\work.vcpkg>vcpkg install jsoncpp:x86-windows jsoncpp:x86-windows-static jsoncpp:x64-windows jsoncpp:x64-windows-static
     C:\work.vcpkg>vcpkg install gtest:x86-windows gtest:x86-windows-static gtest:x64-windows gtest:x64-windows-static


'자료' 카테고리의 다른 글

[C++] Python format 구현  (0) 2017.12.03
[Ubuntu] upgrade시 용량부족으로 인한 문제 해결  (0) 2017.10.12
Windbg 명령어  (0) 2017.01.31
[펌] 동적 메모리 관리  (0) 2016.12.26
[Heap] how2heap (shellpish)  (0) 2016.12.25
블로그 이미지

KuroNeko_

KuroNeko

,

Windbg 명령어

자료 2017. 1. 31. 22:33
반응형

WinDbg 명령어정리


Command

option

Desc

종료

q

디버깅 종료

qd

디버깅 종료;연결해제

– User-mode : Target Application은 종료되지 않는다.

– Kernel-mode : Debugee OS는 Pending되지 않고 계속해서 동작한다.

디버깅 환경정보

vertarget

타겟 컴퓨터 정보 표시

version

디버그 환경 정보 표시

.lastevent

마지막 디버그 이벤트 정보 표시

||

디버깅 세션 정보 표시

symble & sorurce

.symfix

MS 심볼경로 설정

.sympath

심볼경로 확인/설정

!sym noisy

심볼파일 검색 과정을 출력

!sym quiet

심볼파일 검색 과정을 출력하지 않음

.srcpath

.srcpath+ d:\project

소스경로 설정

.srcnoisy

.srcnoisy 1

소스경로 검색 과정을 출력

모듈

lm

로드된 모듈 표시

lm m nt*

패턴과 일치되는 모듈 표시

v

모듈 상세정보 표시

!lmi

!lmi ntdll.dll

모듈 상세정보 표시

.reload

/f test.sys

심볼을 즉시 로드

/i test.sys

TimeStamp가 맞지 않아도 강제로 심볼 로드

/user

[kd] User symbol load

x

x nt!*

x *!*abc*

x /v nt!NtCreateFile

x /t nt!NtCreateFile

x /n nt!ntCreate*

심볼 타입을 표시.

데이터 타입을 표시

이름순으로 정렬

ln

ln [address]

해당 주소에 근접한 심볼의 정보 표시

!dh

!dh [Option] Address

-f  Display file headers

-s  Display Section Headers

-a  Display all header nformation

displays the headers for the specified image

레지스터

r

레지스터 정보 표시

r $proc

현재 프로세스의 PEB주소( user-mode)

현재 프로세스의 EPROCESS주소( kernel-mode)

r $thread

현재 스레드의 TEB주소( user-mode)

현재 스레드의 ETHREAD주소( kernel-mode)

r $tpid

현재 프로세스 ID(PID)

r $tid

현재 스레드 ID(TID)

언어셈블

u


f

b

언어셈블

언어셈블(함수전체)

언어셈블(ip이전의 8개 명령어)

콜스택

k

[n]

p

b

n

v

f

콜스택 정보표시

함수정보 출력

인자표시

프레임번호

FPO정보 표시

스택 사용량 표시

break point

bp

bp 0x123456

bp 설정

bl

bp 리스트 출력

bc

bc * | [frame_no]

bp 삭제

bd,be

bd * | [frame_no]

bp disable/enable

bm

bm notepad!*Win*

패턴과 일치하는 모든심볼에 bp설정

bu

bu aaa!bbb

로드되지 않은 심볼에 대한 bp설정

ba

특정 주소에 access시 bp

지역변수

dv

dv modulr!test*

/i

/V

심볼유형과 인자유형 표시

변수저장 위치 표시( register or address )

데이터유형

dt

df _EPROCESS 0xaddr

dt _PEB @$peb

주소를 특정 데이터 형으로 변환해서 표시

Current Process PEB정보 디스플레이

du

dpu



Unicode string 표시

da

dpa

Ansi string 표시

dc

db

dy

!address

!address

!address [address]

dds

dds [Options] [Range]


dds esp esp+100

Display Words and Symbols

esp 부터 esp+100까지의 값을 출력

- callstack이 깨진경우, stack확인의 용도로 사용할 수 있다

프로세스 & 스레드 정보

!peb

PEB(Process Environment Block)표시

!teb

TEB(Thread Environment Block) 표시

~*kb

모든 thread의 콜스택 표시

!gle

API의 마지막 에러코드 표시

실행 제어

t

Trace

~.t

다른 스레드를 중지시킨 상태에서 하나의 statementt 실행

g

p

Step Over

gu

gu


~0 gu

현재함수가 복귀할 때 까지 실행

스레드 0을 제외한 모든 스레드를 freeze함

wt

-oR

내부에서 호출된 함수와 함수호출 횟수등의 정보 표시

(특정 API 내부에서 호출되는 함수와 결과를 한눈에 확인 할 수 있다.)

.cxr

컨텍스트 변경

!ready

.thread

!thread

.trap

.process

!process

ed

eb

eb .-6 90 90 90 90 90 90

6byte를 NOP(0x90)으로 변경

!error

!error [error code]

에러코드 정보표시

 

 

 

 

 

 

Set Exceptions

sxe

 

sxe av(0xc0000005)


sxe ld:[moduleName]


sxe ud:[moduleName]

Set Exceptions

Break when access violation

Break when [module] load

Break when [module] unlod

sxd

sxd av

Disable Break when av(first chance)

Create Dump

.dump

/f  full user-mode dump

/m  minidump

/u  Append date,time,PID

Create Dump File

.writemem

.writemem FileName Range

 

: Range – BaseAddr L”DumpSize”

 

.writemem c:\a.dll 0x00030000 L28000

writes a section of memory to a file

WinDBG 설정

.lines -e

라인정보 표시

.enable_unicode 1

Watch, local변수 창에 유니코드 표시

ed Kd_DEFAULT_MASK 8

Vista이상: DbgPrint출력 활성화

 


펌 : http://thepassion.tistory.com/114

'자료' 카테고리의 다른 글

[Ubuntu] upgrade시 용량부족으로 인한 문제 해결  (0) 2017.10.12
[Library] vcpkg  (0) 2017.07.26
[펌] 동적 메모리 관리  (0) 2016.12.26
[Heap] how2heap (shellpish)  (0) 2016.12.25
[Linux] rootkit 자료 (펌)  (0) 2016.11.30
블로그 이미지

KuroNeko_

KuroNeko

,
반응형

원본 : link


[glibc] 동적 메모리 관리 (1)

http://studyfoss.egloos.com/5206220

glibc: 2.10.1
arch: x86


이번에는 GNU C library (이하 glibc)에서 동적 메모리를 관리하는 방식에 대해서 살펴볼 것이다.
(여기서 설명하는 내용은 32비트 머신 환경에 해당하며 64비트 환경의 경우 차이가 있을 수 있다.)

glibc 내에 포함된 동적 메모리 할당자 (malloc) 모듈은
Doug Lea가 최초로 작성한 구현(이름의 앞자를 따서 dlmalloc이라고 부른다)을
Wolfram Gloger가 UNIX multi-thread 환경을 고려하여 수정한 ptmalloc2를 기반으로 작성되었다.

동적 메모리로 할당되는 영역(chunk)은 내부적으로 해당 chunk에 대한 metadata를 저장하기 위한
공간을 포함하는데 가장 중요한 정보는 해당 chunk의 크기이다.
malloc() 호출 시에는 원하는 영역의 크기를 지정하지만 free() 호출 시에는 단순히 포인터 만을 넘기는 것에서 알 수 있듯이
malloc()으로 (물론 calloc/realloc 등도 동일하다) 할당된 영역 어딘가에는 크기 정보가 포함되어 있다.

실제로 malloc() 호출 시에는 실제로 필요한 영역 + 크기를 저장하기 위한 헤더까지 포함한 크기의
chunk가 할당되며 따라서 (32bit) x86 아키텍처에서는 (최소) 4 바이트 만큼의 공간이 더 필요하다.
각 chunk는 8바이트 단위로 정렬(align)되기 때문에 실제 크기는 좀 더 커질 수 있다.

또한 free memory에 해당하는 chunk를 관리하기 위한 doubly linked list와
물리적으로 인접한 이전(prev) chunk를 병합할 때 사용하는 필드까지 포함하면
할당될 수 있는 최소 chunk의 크기는 16바이트이다.
(이 경우 user가 사용 가능한 영역의 최대 크기는 12바이트가 된다.)

실제로 사용되는 malloc_chunk 구조체는 다음과 같이 정의되어 있다.

struct malloc_chunk {
  INTERNAL_SIZE_T      prev_size;  /* Size of previous chunk (if free).  */
  INTERNAL_SIZE_T      size;       /* Size in bytes, including overhead. */

  struct malloc_chunk* fd;         /* double links -- used only if free. */
  struct malloc_chunk* bk;

  /* Only used for large blocks: pointer to next larger size.  */
  struct malloc_chunk* fd_nextsize; /* double links -- used only if free. */
  struct malloc_chunk* bk_nextsize;
};

malloc_chunk 자료 구조가 사용되는 방식은 약간 혼동스럽기 때문에 아래의 그림을 참조하면 좋을 것이다.
malloc_chunk가 사용자에게 할당되면 오직 size 필드 만의 의미있는 값을 가진다. (할당된 chunk의 크기)
다른 영역은 무시되며 해당 메모리 영역이 free() 되었을 때 의미있는 정보가 기록된다.


제일 처음에 나오는 prev_size 필드는 해당 chunk 바로 앞에 위치한 이전 chunk의 크기이다.
(당연한 얘기이지만 여기서 말하는 이전 chunk란 list로 연결된 chunk가 아니라
물리적으로 연속된 주소에 위치한 chunk를 말한다.)
이 필드는 이전 chunk가 free() 되었을 때 설정되며
이를 통해 이전 chunk의 헤더 위치를 손쉽게 찾을 수 있기 때문에
chunk를 통합하는 경우에 유용하게 사용될 수 있다.

다음은 size 필드로 현재 chunk의 크기를 나타내며 malloc() 시에 설정된다.
앞서 말한대로 각 chunk는 8바이트 단위로 정렬되므로 하위 3비트는 특별한 용도로 사용한다.
따라서 실제 chunk의 크기를 구하려면 하위 3비트를 무시해야 한다.

그림에서 P 플래그는 이전 chunk가 사용 중인지 여부를 나타내는 것이다. (PREV_INUSE)
즉 이 플래그가 지워져 있으면 이전 chunk는 free chunk라는 의미가 된다.
M 플래그는 해당 필드가 mmap() 시스템 콜을 통해 할당된 것인지를 나타낸다. (IS_MMAPPED)
나중에 살펴보겠지만 mmap()으로 할당된 chunk는 약간 다른 방식으로 관리된다.
N 플래그는 multi-thread application에서 각 thread마다 다른 heap 영역을 사용하는 경우
현재 chunk가 main heap (arena)에 속하는지 여부를 나타낸다. (NON_MAIN_ARENA)

#define PREV_INUSE       0x1
#define IS_MMAPPED       0x2
#define NON_MAIN_ARENA   0x4

#define SIZE_BITS        (PREV_INUSE|IS_MMAPPED|NON_MAIN_ARENA)
#define chunksize(p)     ((p)->size & ~(SIZE_BITS))

다음에 나오는 필드들은 모두 free chunk에서 사용하는 것이며
malloc()으로 할당되었을 때는 단순히 무시되고 사용자 데이터를 위한 공간으로 사용된다.
fd와 bk는 각각 forward, backward pointer를 의미하는 것이며
fd_nextsize와 bk_nextsize도 동일하지만 상대적으로 큰 크기의 chunk에서만 사용된다.

특이한 것은 다음 chunk의 prev_size 필드도 현재 chunk의 데이터 영역으로 사용된다는 것이다.
사실 개념적으로는 이 부분도 현재 chunk에 속하며, (그림에서 <actual chunk> 부분)
free() 시에는 현재 chunk의 크기를 (중복하여) 저장하는 용도로 사용된다. (단 플래그는 제외)
(이를 boundary tag 기법이라고 한다.)
또한 free() 시에는 다음 chunk의 PREV_INUSE 비트 (P 플래그)를 지워야 하며
prev_size 필드는 오직 P 플래그가 지워진 경우에만 사용되어야 한다.

이렇게 할당된 chunk들은 이후에 free()를 통해 해지되면 bin이라는 구조를 통해 관리된다.
bin은 사실 각 chunk의 fd, bk 필드로 연결된 doubly-linked list일 뿐이며
chunk의 크기에 따라 총 126개로 분리된다. (첫 번째 bin은 특별한 용도로 사용된다.)

이는 또 small bin과 large bin으로 나누어 지는데
small bin은 chunk 크기 기준으로 512 바이트 미만인 것들이 8 바이트 단위로 구분되는데
최소 크기인 16 바이트부터, 24, 32, 48, ..., 504 바이트 까지 총 62개의 bin으로 구성된다.

개념적으로 bin의 구성은 다음과 같다. (코드 내의 주석에서 발췌)
총 127 개 중에서 제일 처음 bin은 특별한 용도로 사용되므로 126개 만 사용된다.
또한 small bin에 속하는 8 바이트 단위의 bin이 64개라고 표현되어 있으나
실제로는 (chunk의 최소 크기 제한으로 인해) 0과 8에 해당하는 첫 2개가 존재하지 않으므로
위에서 말한대로 62개만 사용된다. 아래의 데이터는 단지 개념적으로 구조를 이해하기 위한 것이다. 

    64 bins of size       8
    32 bins of size      64
    16 bins of size     512
     8 bins of size    4096
     4 bins of size   32768
     2 bins of size  262144
     1 bin  of size what's left

512 바이트 이상의 크기를 가지는 chunk를 위한 large bin은
small bin처럼 동일한 크기의 chunk만을 포함하는 것이 아니라
해당 index가 나타내는 크기보다 작은 크기의 chunk들은 모두 포함한다.
즉, 4KB를 위한 bin이 있다면 이는 정확히 4096 바이트 크기의 chunk 만을 포함하는 것이 아니라
4088, 4000, 3968 등의 크기를 가지는 chunk들도 포함한다는 것을 뜻한다.
다만 이들은 할당의 효율성을 위해 해당 bin 내에서 크기 별로 정렬(sort)된다.

이 때 fd_nextsize와 bk_nextsize 필드가 이용되며
이들은 현재 bin 내에서 크기가 다른 첫 번째 chunk에 대한 포인터를 저장한다.

이러한 bin들은 해당 bin 내에 이용 가능한 free chunk가 있는지 빨리 조사하기 위해
별도의 bitmap을 유지하여 관리한다. 해당 bin 내에 free chunk가 없다면
그 보다 큰 bin 내의 가장 작은 chunk를 빨리 찾기 위해 이를 이용할 수 있다.

위에서 말한대로 첫 번째 bin은 unsorted chunk의 list로 사용된다.
이는 일종의 cache와 같은 것으로 일단 free() 된 chunk는 곧바로 해당 bin으로 들어가지 않고
먼저 unsorted chunk list에 들어가며 이 후의 메모리 할당 시
동일한 크기의 영역을 다시 요청하는 경우에는 이를 바로 재사용하도록 한다.
이는 FIFO (queue)와 같은 방식으로 동작하며, 일단 검색된 chunk는 바로 할당(재사용)되거나
아니면 원래의 bin으로 돌아가게 된다. 즉, 단 한 번의 재사용 기회 만이 주어진다.

또한 small bin에 속하는 chunk 중에서 (기본값) 72 바이트 이하의 크기를 가지는 chunk는
fast bin이라고하는 또 다른 cache를 통해 관리되는데,
이는 malloc() 및 free() 시에 가장 먼저 조사하는 bin으로써
속도를 높이기 위해 single-linked list로 구성되며 LIFO (stack)와 같은 방식으로 동작한다.
fast bin 내의 chunk들은 unsorted bin과 달리 (특정한 조건에 의해) 병합(consolidation)이 일어나지 않는 한
계속 bin 내에 남아서 요청을 수행할 수 있다.

이상의 여러 자료 구조들을 그림을 나타내면 대략 다음과 같다.
(그림에는 편의를 위해 약간의 오류가 숨어있다. 대강 의미만 파악하자..;;)


그 밖에 (기본값) 128KB 이상의 큰 메모리를 요청하는 경우에는
heap을 이용하지 않고 mmap() 시스템 콜을 통해 별도의 메모리 영역을 할당하여
chunk를 만들고 이를 사용자에게 반환하며, 이러한 chunk들은 bin 내에 속하지 않는다.
이러한 chunk들은 IS_MMAPPED 플래그로 쉽게 확인할 수 있기 때문에
free() 시에 단순히 munmap()을 호출하여 메모리 영역을 해지한다.

또한 모든 chunk의 맨 마지막에는 top chunk가 존재하는데
top chunk는 어떠한 bin에도 속하지 않으며 heap 영역의 마지막에 위치한다.
다른 free chunk들이 메모리 할당 요청을 만족하지 못하는 경우에만
top chunk를 분할하여 요청을 처리하며, 현재 top chunk 크기로도 처리할 수 없는 경우에는
sbrk() 함수를 통해 heap 영역을 확장하여 top chunk의 크기를 늘린후 요청을 처리한다.

=== 참고 문헌 ===


'자료' 카테고리의 다른 글

[Library] vcpkg  (0) 2017.07.26
Windbg 명령어  (0) 2017.01.31
[Heap] how2heap (shellpish)  (0) 2016.12.25
[Linux] rootkit 자료 (펌)  (0) 2016.11.30
[C++] 브루트 포싱(Brute Forcing)  (0) 2016.07.30
블로그 이미지

KuroNeko_

KuroNeko

,

[Heap] how2heap (shellpish)

자료 2016. 12. 25. 02:04
반응형
link

'자료' 카테고리의 다른 글

Windbg 명령어  (0) 2017.01.31
[펌] 동적 메모리 관리  (0) 2016.12.26
[Linux] rootkit 자료 (펌)  (0) 2016.11.30
[C++] 브루트 포싱(Brute Forcing)  (0) 2016.07.30
주로 사용하는 헤더들  (0) 2016.05.18
블로그 이미지

KuroNeko_

KuroNeko

,