Greedun's archieve

1_heap 청크, bin들의 구조 및 원리

Greedun (lr-x-dl) — Thu, 28 Aug 2025 01:03:42 +0900

1. 청크의 구조

- prev_size : 바로 앞에 해제된 청크의 크기
<앞에 해제가 없을경우엔 별다른 의미없는 공간이다.>
- size : 요청한 크기 + 헤더크기(+flag포함)
- data : 입력된 값들이 저장되는 공간

- fd : linkedlist로 앞에 연결된 해제된 청크 주소
- bk : linkedlist로 뒤에 연결된 해제된 청크 주소
- fd_nextsize : 같은 largebin크기의 앞에 해제된 청크의 주소
- bk_nextsize : 같은 largebin크기의 뒤에 해제된 청크의 주소
⇒ 위에 4개영역은 해제될때 data영역에 덮어서 사용된다.

(flag비트)
⇒ 0x08 → 0000 0000 0000 1<span style="color:red">000</span>
- PREV_INUSE(0x1) : 인접한 이전 청크가 사용중일 경우 1
- IS_MMAPPED(0x2) : 해당 청크가 mmap()으로부터 할당된 경우 1
- NON_MAIN_ARENA(0x4) : 해당 청크가 main_arena에서 관리 안 할 경우
⇒ 32bit경우 8byte를 이용하므로 하위 3비트를 flag로 사용한다.

2. bin의 종류

bin이란 청크가 해제시 담기는 통이다.

(bin종류)	(크기 제한)
fastbin	(32bit) 16 - 64byte / (64bit) 32 - 128byte
smallbin	fastbin보다는 크고 1024byte보다는 작은 크기
large bin	1024byte이상 크기
Unsorted bin	제한 없음
tcache(2.26버전 이상)	(32bit) 12 - 516byte / (64bit) 24 - 1032byte

fastbin, tcache크기범위가 겹치는데 2.26버전에서는 tcache가 효율적이기에 먼저 쓰고
만약 tcache가 관리할 범위를 넘어서면 그때부터 fastbin을 사용하게 된다.

2-1. fastbin 관리

2-1-1. 원리 요약

LIFO구조를 사용하여 같은 크기의 해제된 청크를 단일 linked list로 관리되는 bin이
할당 요청이 있을때 “요청크기+헤더”크기의 청크가 bin에 있다면 해당 청크를 연결해제후 재할당해준다.

(특징)
1. 검증루틴이 적어서 할당, 해제속도가 빠르다.
2. 할당, 해제시 LIFO방식으로 처리한다.
3. 인접해서 해제되어도 병합되지 않는다.

2-1-2. free함수에서 해제 원리

// free(fastbin)
if ((unsigned long)(size) <= (unsigned long)(get_max_fast ())
#if TRIM_FASTBINS
      /*
	If TRIM_FASTBINS set, don't place chunks
	bordering top into fastbins
      */
      && (chunk_at_offset(p, size) != av->top)
#endif
      ) {
    if (__builtin_expect (chunk_at_offset (p, size)->size <= 2 * SIZE_SZ, 0)
	|| __builtin_expect (chunksize (chunk_at_offset (p, size))
			     >= av->system_mem, 0))
      {
	/* We might not have a lock at this point and concurrent modifications
	   of system_mem might have let to a false positive.  Redo the test
	   after getting the lock.  */
	if (have_lock
	    || ({ assert (locked == 0);
		  mutex_lock(&av->mutex);
		  locked = 1;
		  chunk_at_offset (p, size)->size <= 2 * SIZE_SZ
		    || chunksize (chunk_at_offset (p, size)) >= av->system_mem;
	      }))
	  {
	    errstr = "free(): invalid next size (fast)";
	    goto errout;
	  }
	if (! have_lock)
	  {
	    (void)mutex_unlock(&av->mutex);
	    locked = 0;
	  }
      }
    free_perturb (chunk2mem(p), size - 2 * SIZE_SZ);
    set_fastchunks(av);
    unsigned int idx = fastbin_index(size);
    fb = &fastbin (av, idx);
    /* Atomically link P to its fastbin: P->FD = *FB; *FB = P;  */
    mchunkptr old = *fb, old2;
    unsigned int old_idx = ~0u;
    do
      {
	/* Check that the top of the bin is not the record we are going to add
	   (i.e., double free).  */
	if (__builtin_expect (old == p, 0))
	  {
	    errstr = "double free or corruption (fasttop)";
	    goto errout;
	  }
	/* Check that size of fastbin chunk at the top is the same as
	   size of the chunk that we are adding.  We can dereference OLD
	   only if we have the lock, otherwise it might have already been
	   deallocated.  See use of OLD_IDX below for the actual check.  */
	if (have_lock && old != NULL)
	  old_idx = fastbin_index(chunksize(old));
	p->fd = old2 = old;
      }
    while ((old = catomic_compare_and_exchange_val_rel (fb, p, old2)) != old2);
    if (have_lock && old != NULL && __builtin_expect (old_idx != idx, 0))
      {
	errstr = "invalid fastbin entry (free)";
	goto errout;
      }
  }

1. 해제된 청크의 범위가 fastbin의 범위이다.
2. “fb = &fastbin (av, idx);” ⇒ 현재 청크의 크기에 해당하는 리스트를 가져온다.
3. “p->fd = old2 = old;” ⇒ 받아온 리스트에 해제할 청크의 주소를연결해준다.

2-1-3. fastbin에서 재할당 원리

// malloc(fastbin)
if ((unsigned long) (nb) <= (unsigned long) (get_max_fast ()))
    {
      idx = fastbin_index (nb);
      mfastbinptr *fb = &fastbin (av, idx);
      mchunkptr pp = *fb;
      do
        {
          victim = pp;
          if (victim == NULL)
            break;
        }
      while ((pp = catomic_compare_and_exchange_val_acq (fb, victim->fd, victim))
             != victim);
      if (victim != 0)
        {
          if (__builtin_expect (fastbin_index (chunksize (victim)) != idx, 0))
            {
              errstr = "malloc(): memory corruption (fast)";
            errout:
              malloc_printerr (check_action, errstr, chunk2mem (victim), av);
              return NULL;
            }
          check_remalloced_chunk (av, victim, nb);
          void *p = chunk2mem (victim); //return chunk ptr
          alloc_perturb (p, bytes); //init
          return p;
        }
    }

1. “mfastbinptr *fb = &fastbin (av, idx);” ⇒ 요청한 fastbin크기에 맞는 인덱스를 찾는다.
2. while ((pp = catomic_compare_and_exchange_val_acq (fb, victim->fd, victim))!= victim); ⇒ 찾은 청크의 fd의 값을 첫번째 값으로 업데이트하여 LIFO구조를 유지한다.
3. return p; ⇒ 할당의 결과로 청크의 주소가 반환 된다.

2-2. top청크

힙 영역에서 할당된 청크를 뺀 나머지 영역으로서 smallbin, largebin크기의 청크가 top청크 근처에서 해제시 병합되어 진다.

2-3. unsorted bin관리

- smallbin, largebin크기의 청크가 해제될 경우 바로 bin으로 들어가는게 아닌 unsorted bin에 할당요청이 들어오기 전까지 머물게 된다.
- unsorted bin은 FIFO구조로 원형 linkedlist로 관리된다.
- 이후 요청이 들어오게 된다면 해당 bin을 먼저 확인하여 같거나 큰 청크를 쪼개거나 그대로 재할당을 해주게 된다.
- 하지만 해당 bin에 원하는 큰 청크가 없을 수도 있는데 그때는 내부에 있던 청크들은 smallbin, largebin으로 보내고 top청크에서 잘라서 할당해주게 된다.
(0번과 2번청크를 해제한 이유는 인접한 청크가 해제되었다면 병합되기 때문)

2-3-2. 재할당

⇒ smallbin, largebin에서도 작은 크기의 경우 자른 후 할당해준다.

이때 자르고 남은 청크는 fastbin크기면 fastbin으로 들어가고 보다 크면 unsorted bin으로 들어가게 된다.

2-4. small bin관리

- unsorted bin에서 넘어온 청크들은 fastbin처럼 크기별로 관리하게 된다.
- fd, bk영역에 주소를 담아서 원형 linkedlist로 가리켜서 관리하게 된다.

if (in_smallbin_range (nb))
{
  idx = smallbin_index (nb);
  bin = bin_at (av, idx);
  if ((victim = last (bin)) != bin)
    {
      if (victim == 0) /* initialization check */
        malloc_consolidate (av);
      else
        {
          bck = victim->bk;
if (__glibc_unlikely (bck->fd != victim))
            {
              errstr = "malloc(): smallbin double linked list corrupted";
              goto errout;
            }
          set_inuse_bit_at_offset (victim, nb);
          bin->bk = bck;
          bck->fd = bin;
          if (av != &main_arena)
            victim->size |= NON_MAIN_ARENA;
          check_malloced_chunk (av, victim, nb);
          void *p = chunk2mem (victim);
          alloc_perturb (p, bytes);
          return p;
        }
    }
}

1. 해제한 크기가 smallbin크기에 부합할때 해제한 크기에 맞는 인덱스를 찾는다.
2. (1)만약 비어있다면 fastbin이 있는지 확인하고 있다면 병합한다. (2)비어있지않다면 smallbin에 있는 청크를 재할당해준다.
3. 재할당할 청크의 prev_size비트를 설정하고 fd,bk를 FIFO구조가 유지되게 업데이트해준다.
4. 업데이트가 완료되면 청크의 주소가 반환된다.

2-5. large bin관리

small bin처럼 FIFO구조 원형 linkedlist로 관리되지만 차이점은 크기 범위별로 관리가 된다는 점이다.

(1) fd, bk 관리

- fd, bk영역은 small bin에서 처럼 연결되지만 크기가 자동 정렬되어 연결이 된다.

(2) fd_nextsize, bk_nextsize관리

- fd_nextsize, bk_nextsize영역은 크기별 첫번째 청크를 가리키기 위해 사용된다.
- 따라서 제일 작은 크기의 청크를 main_arena를 가리키는 대신 젤 큰 청크를 가리킨다.

if (!in_smallbin_range (nb))
        {
          bin = bin_at (av, idx);
          /* skip scan if empty or largest chunk is too small */
          if ((victim = first (bin)) != bin &&
              (unsigned long) (victim->size) >= (unsigned long) (nb))
            {
              victim = victim->bk_nextsize;
              while (((unsigned long) (size = chunksize (victim)) <
                      (unsigned long) (nb)))
                victim = victim->bk_nextsize;
              /* Avoid removing the first entry for a size so that the skip
                 list does not have to be rerouted.  */
              if (victim != last (bin) && victim->size == victim->fd->size)
                victim = victim->fd;
              remainder_size = size - nb;
              unlink (av, victim, bck, fwd);
              /* Exhaust */
              if (remainder_size < MINSIZE)
                {
                  set_inuse_bit_at_offset (victim, size);
                  if (av != &main_arena)
                    victim->size |= NON_MAIN_ARENA;
                }
              /* Split */
              else
                {
                  remainder = chunk_at_offset (victim, nb);
                  /* We cannot assume the unsorted list is empty and therefore
                     have to perform a complete insert here.  */
                  bck = unsorted_chunks (av);
                  fwd = bck->fd;
	  if (__glibc_unlikely (fwd->bk != bck))
                    {
                      errstr = "malloc(): corrupted unsorted chunks";
                      goto errout;
                    }
                  remainder->bk = bck;
                  remainder->fd = fwd;
                  bck->fd = remainder;
                  fwd->bk = remainder;
                  if (!in_smallbin_range (remainder_size))
                    {
                      remainder->fd_nextsize = NULL;
                      remainder->bk_nextsize = NULL;
                    }
                  set_head (victim, nb | PREV_INUSE |
                            (av != &main_arena ? NON_MAIN_ARENA : 0));
                  set_head (remainder, remainder_size | PREV_INUSE);
                  set_foot (remainder, remainder_size);
                }
              check_malloced_chunk (av, victim, nb);
              void *p = chunk2mem (victim);
              alloc_perturb (p, bytes);
              return p;
            }
        }

1. 요청한 크기가 largebin이라면 largebin과 내부에 bk_nextsize로 순회하며 부합하는 청크가 있는지 찾는다.
2. 만약 반환될 청크가 있다면 fd,bk,fd_nextsize,bk_nextsize의 업데이트로 연결리스트를 유지한다.
3. smallbin과 마찬가지로 연결리스트의 업데이트가 완료되었다면 청크의 주소를 반환한다.

3. main_arena

bkr시스템 콜을 사용하여 할당된 힙을 효율적으로 관리하게 위한 malloc_state구조체이다.
(하지만 top청크보다 큰 크기의 요청이 들어올 경우 mmap시스템콜을 사용하여 새로운 페이지를 할당후 main_arena에서는 관리를 안한다.)

(구조)

// main_arena
static struct malloc_state main_arena =
{
  .mutex = _LIBC_LOCK_INITIALIZER,
  .next = &main_arena,
  .attached_threads = 1
};

// malloc_state
struct malloc_state
{
  /* Serialize access.  */
  __libc_lock_define (, mutex);
  /* Flags (formerly in max_fast).  */
  int flags;
  /* Fastbins */
  mfastbinptr fastbinsY[NFASTBINS];
  /* Base of the topmost chunk -- not otherwise kept in a bin */
  mchunkptr top;
  /* The remainder from the most recent split of a small request */
  mchunkptr last_remainder;
  /* Normal bins packed as described above */
  mchunkptr bins[NBINS * 2 - 2];
  /* Bitmap of bins */
  unsigned int binmap[BINMAPSIZE];
  /* Linked list */
  struct malloc_state *next;
  /* Linked list for free arenas.  Access to this field is serialized
     by free_list_lock in arena.c.  */
  struct malloc_state *next_free;
  /* Number of threads attached to this arena.  0 if the arena is on
     the free list.  Access to this field is serialized by
     free_list_lock in arena.c.  */
  INTERNAL_SIZE_T attached_threads;
  /* Memory allocated from the system in this arena.  */
  INTERNAL_SIZE_T system_mem;
  INTERNAL_SIZE_T max_system_mem;
};

참고링크

- https://m.blog.naver.com/yjw_sz/221547262765
- https://jjeongsu.tistory.com/68

[crypto] Block - TEA 알고리즘

Greedun (lr-x-dl) — Sat, 19 Jul 2025 00:11:12 +0900

1. TEA 알고리즘이란?

1.1 기본 정보

TEA(Tiny Encryption Algorithm)는 1994년 David Wheeler와 Roger Needham에 의해 개발된 블록 암호 알고리즘입니다.

(주요 특징)
- 블록 크기: 64비트
- 키 길이: 128비트
- 라운드 수: 32라운드
- 구조: Feistel 네트워크 기반

장점
- 구현이 매우 간단하고 빠름
- 메모리 사용량이 적음
- 복잡한 S-Box나 치환 테이블이 불필요

단점
- 보안상 취약점이 발견되어 현재는 실용적으로 사용되지 않음
- 관련키 공격(Related-key attack)에 취약

2. Feistel 구조

2.1 Feistel 네트워크란?

1973년 IBM의 Horst Feistel이 개발한 블록 암호 설계 방법론으로, DES 알고리즘에서 처음 사용되었습니다.

(핵심 원리)
1. 블록 분할 : 평문을 두 개의 동일한 크기 부분으로 나눔 (L, R)
2. 라운드 함수 : 각 라운드에서 한쪽 부분만 변형하고 다른 쪽과 XOR 연산
3. 교환 : 두 부분의 역할을 교환하며 여러 라운드 반복

(Feistel 구조의 특징)
- 가역성 보장 : 라운드 함수가 가역적이지 않아도 전체 구조는 가역적
- 구현 효율성 : 암복호화에 같은 알고리즘 사용, 메모리 효율적
- 분석 용이성 : 수학적 분석이 상대적으로 쉬움

2.2. TEA의 Feistel 구조

(일반적인 Feistel과의 차이점)
- 전통적인 Feistel에서는 라운드마다 L, R이 단순 교환
- TEA는 각 라운드에서 양쪽 블록을 모두 업데이트
- 라운드 함수

L[i+1] = R[i]
R[i+1] = L[i] ⊕ F(R[i], K[i])

3. 보안메커니즘

3.1. sum값의 역할

(기본 기능)
1. 라운드 카운터 역할
2. 키 스케줄링 메커니즘

(보안적 역할)
1. 키 다양성 제공
- 같은 128비트 키를 사용하더라도 각 라운드에서 다른 서브키 사용
- `sum & 3`과 `(sum >> 11) & 3`로 4개의 32비트 키 워드를 순환 사용
2. 슬라이딩 공격 방지
- 각 라운드가 고유한 sum값을 가짐으로써 라운드 간 구별이 가능
- 단순한 반복 패턴을 방지한다.
3. 대칭성 파괴
- 암복호화에서 sum의 진행방향이 반대
- 이로 인해 구조적 대칭성이 파괴된다.

(한계점)
- 단순한 키 스케줄링으로 인한 관련키 공격 취약성
- 예측 가능한 선형 증가 패턴

=> sum값은 TEA의 핵심 구성 요소로, 간단하면서도 효과적인 키 스케줄링을 제공하지만 동시에 알고리즘의 주요 취약점 중 하나이다.

3.2. 매직 상수

=> 값 : 0x9e3779b9

(수학적 의미)
- 황금비와의 관계: `(√5 - 1) / 2 × 2³²`
- 황금비의 역수에 2³²를 곱한 값
- 수학적으로 좋은 분포 특성을 제공

(암호학적 효과)
- 의사난수 생성에서 좋은 확산 특성
- 해시 함수에서 균등한 분포 제공
- 암호화 과정에서 예측 불가능성 향상

황금비의 수학적 특성을 활용하여 암호화 과정에서 좋은 확산 특성과 예측 불가능성을 제공하지만,
동시에 TEA의 단순함으로 인한 보안 취약점도 가지고 있습니다.

4. Tea알고리즘 동작 과정

4.1. 기본 구성

- 블록 크기 : 64bit(8byte)
- 키 길이 : 128bit(16byte)
- 라운드 수 : 32 (각 라운드마다 연산 2번 수행)
- 연산 구조 : Feistel 구조

=> 복잡한 S-Box나 치환 테이블없이 기본적인 산술 연산만을 이용하여 구현된다.

4.2. 초기 단계

- 데이터 분할 : P = (L₀, R₀) (64비트를 32비트씩 분할)
- 키 분할 : K = (K₀, K₁, K₂, K₃) (128비트를 32비트씩 분할)
- 델타 상수 설정 : δ = 0x9E3779B9δ(황금비율 상수)
- 라운드 카운터 초기화 : n = 0(최종 라운드 수 32)

4.3. 암호화 단계

총 32라운드에 걸쳐 다음과 같은 과정을 반복한다.

1. 초기 sum: 0
2. 각 라운드마다:
   - 델타 누적: sum = sum + δ
   - v0 업데이트: v0 += ((v1 << 4) + k0) ^ (v1 + sum) ^ ((v1 >> 5) + k1)
   - v1 업데이트: v1 += ((v0 << 4) + k2) ^ (v0 + sum) ^ ((v0 >> 5) + k3)

4.4. 복호화 단계

총 32라운드에 걸쳐 암호화의 역순 수행:

1. 초기 sum: 32 × δ
2. 각 라운드마다:
   - v1 업데이트: v1 -= ((v0 << 4) + k2) ^ (v0 + sum) ^ ((v0 >> 5) + k3)
   - v0 업데이트: v0 -= ((v1 << 4) + k0) ^ (v1 + sum) ^ ((v1 >> 5) + k1)
   - 델타 감소: sum = sum - δ

5. 보안 분석

- 확산(Diffusion)
    - 평문의 작은 변화가 암호문 전체에 영향
    - Feistel 구조의 반복을 통해 달성

- 혼돈(Confusion)
    - 평문과 암호문, 키 간의 관계를 복잡하게 만듦
    - 라운드 함수의 비선형 연산으로 달성

(알려진 취약점)
- 관련키 공격(Related-key attack)에 취약
- 슬라이드 공격(Slide attack)에 일부 취약성
- 단순한 키 스케줄링으로 인한 패턴 분석 가능

=> 이후 XTEA나 다른 현대 암호 알고리즘이 사용된다.

(참고링크)

- https://ko.wikipedia.org/wiki/%ED%8C%8C%EC%9D%B4%EC%8A%A4%ED%85%94_%EC%95%94%ED%98%B8
- https://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm
- https://en.wikipedia.org/wiki/C_(programming_language)
- https://berom.tistory.com/171

[Know] tar에 다양한 옵션이 있는 이유

Greedun (lr-x-dl) — Sun, 6 Jul 2025 23:41:11 +0900

1. tar의 기본 사용법

(종류)

기본 tar, gzip, bzip2, xz

(압축하기)

# 기본 tar 압축 (압축 없음)
tar -cf archive.tar files/

# gzip 압축 (.tar.gz)
tar -czf archive.tar.gz files/

# bzip2 압축 (.tar.bz2)
tar -cjf archive.tar.bz2 files/

# xz 압축 (.tar.xz)
tar -cJf archive.tar.xz files/

(압축해제)

# tar 해제
tar -xf archive.tar

# gzip 해제
tar -xzf archive.tar.gz

# bzip2 해제
tar -xjf archive.tar.bz2

# xz 해제
tar -xJf archive.tar.xz

# 특정 디렉토리에 해제
tar -xzf archive.tar.gz -C /path/to/directory

2. 기타 활용법

(1) 압축률 비교

# 속도 우선 (빠름, 큰 용량)
tar -czf fast.tar.gz files/

# 압축률 우선 (느림, 작은 용량)
tar -cjf small.tar.bz2 files/

# 최고 압축률 (가장 느림, 가장 작음)
tar -cJf smallest.tar.xz files/

(2) 진행률 표시

# pv 사용 (설치 필요: sudo apt install pv)
tar -czf - files/ | pv > backup.tar.gz

# 파일 개수 표시
tar -czf backup.tar.gz files/ --checkpoint=1000 --checkpoint-action=dot

3. 각 압축의 차이점

(1970년대 - tar의 탄생)

# 원래 tar는 "Tape ARchive"
# 테이프 백업용으로 만들어짐 - 압축 기능 없음
tar -cf backup.tar files/

(압축의 진화)

1. 1970년대 - tar
2. 1980년대 - compress(.Z)
3. 1990년대 - gzip(.gz)
4. 2000년대 - bzip2(.bz2)
5. 2010년대 - xz(.xz)

(각 압축방식의 특징)

- 하드웨어 환경
    # 저성능 시스템 → gzip
    # 고성능 시스템 → xz
    # 네트워크 대역폭 제한 → bzip2/xz
- 호환성 요구사항
    # 오래된 시스템 지원 → gzip
    # 최신 시스템만 → xz
    # 범용성 → gzip

(1) gzip(-z)

tar -czf archive.tar.gz files/

장점 : 빠른 속도, 널리 지원
단점 : 상대적으로 낮은 압축률
용도 : 일반적인 압축, 웹서버등

(2) bzip2(-j)

tar -cjf archive.tar.bz2 files/

장점 : gzip보다 높은 압축률
단점 : 더 느린 속도
용도 : 저장 공간이 중요할 떄

(3) xz(-J)

tar -cJf archive.tar.xz files/

장점 : 최고 압축률, 병렬 처리 지원
단점 : 가장 느림, 메모리 사용량 높음
용도 : 배포용 패키지, 장기 보관

(성능 비교)

# 같은 1GB 디렉토리를 압축했을 때:

# gzip: 2분, 300MB
time tar -czf test.tar.gz large_dir/

# bzip2: 8분, 250MB  
time tar -cjf test.tar.bz2 large_dir/

# xz: 15분, 200MB
time tar -cJf test.tar.xz large_dir/

4. 새로운 압축 알고리즘

# 새로운 압축 알고리즘들
# zstd (Facebook 개발) - 속도와 압축률의 균형
tar --zstd -cf archive.tar.zst files/

# lz4 - 초고속 압축
# brotli - 웹 최적화

[Python] pip설치시 externally-managed-environment 오류

Greedun (lr-x-dl) — Sun, 15 Dec 2024 10:24:01 +0900

greedun@lr-x-dl:~/RD/auto_ctfd$ sudo pip3 install virtualenv
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.
    
    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.
    
    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.
    
    See /usr/share/doc/python3.12/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

(해결방법)

python3 -m pip config set global.break-system-packages true

greedun@lr-x-dl:~/RD/auto_ctfd$ python3 -m pip config set global.break-system-packages true
Writing to /home/greedun/.config/pip/pip.conf

(+) sudo를 사용한 pip의 설치의 경우 위 과정에서도 sudo로 진행해야한다.

참고링크

(1) - https://blog.naver.com/kim1417/223493704161

ICCP 프로토콜

Greedun (lr-x-dl) — Tue, 10 Dec 2024 00:53:18 +0900

1. ICCP 프로토콜

ICCP(Inter Control-Centre Communication Protocol)

: 여러 프로토콜을 사용하는 전력 제어센터들 사이에서 실시간 데이터 교환에 사용되는 프로토콜

미국 전력연구소에서 전력 제어센터간 통신을 담당하는 프로토콜로 발표한 통신 규약
제어센터
- 전력망과 관련된 정보를 받고 상황에 따라 적절한 명령을 내려서 시스템이 안전한 상태로 유지시키는 역할
- 여러 프로토콜을 사용하는데 자동화용 통신 규약인 MMS를 응용계층 하부 규약으로 지정하여 서로 다른 기종간의 원활한 통신을 지원
- 지원 내역으로는 장치제어, 일반적인 메세지(report), 원격제어 센터의 프로그램 제어등이 존재

2. ICCP 프로토콜의 표준

전기 공학 및 전력 시스템 자동화 애플리케이션에서 원격제어(감독 제어 및 데이터 수집)에 사용되는 시스템을 정의 (IEC 60870)
전기 공학 및 전력 시스템 자동화 분야의 IEC 60870 6부
IEC 60870-6-503 : 서비스 및 프로토콜
IEC 60870-6-602 : 전송 프로토콜
IEC 60870-6-702 : 프로파일
IEC 60870-6-802 : 객체 모델

3. ICCP 프로토콜의 구조

3-1. 전체적인 구조

ICCP프로토콜은 OSI 7 Layer의 애플리케이션 계층에서 동작
응용계층의 하부 계층으로 MMS, ACSE를 이용하여 MMS의 장점을 상속
(상호 운용성, 통합의 편리성)
서버-클라이언트 모델을 사용하여 통신하며 구조화된 데이터 블록인 PDU를 이용하여 통신

3-2. 응용계층

3-2-1. MMS

(Manufacturing Message Specification)

서로 다른 제조회사의 서로 다른 단위제어기기 간에 메세지 교환을 위해 사용하는 프로토콜
제정된 표준
- ISO/IEC 9506-1
  : 가상제조기기(VMD), 네트워크 상에서 교환되는 메세지, VMD에 관련된 속성과 파라미터에 대해 기술
- ISO/IEC 9506-2
  : 프로토콜의 사양을 표현계층의 추상구문표현 ASN.1로 기술되어있다.
MMS가 서버-클라이언트 모델을 사용하여 통신

(MMS의 이점)

다른 제조사 기기간 서로 다른 프로토콜을 사용하는 기기들 간 통신을 가능하게 하는 "상호운용성"이 크다.
이외에도 통합의 편리성, 설치비용과 유지보수 비용감소, 응용프로그램 이식등 이점이 존재
가상제조기기(VMD)로서 각각의 디바이스를 표현하여 통일된 통신을 할 수 있는 환경을 제공

3-2-2. ACSE

(Association Control Service Element)

하나의 애플리케이션 프로그램 간에 호출을 설정하기 위한 OSI방법
2개의 사용자 응용 프로세스(AP)간에 통신을 위해서 데이터 교환 전에 하나의 논리적인 통신 채널을 설정하는데 이를 "결합"이라 명칭
ACSE는 이 결합을 설정하고 해제하는 기능을 수행하는 ASE(응용 서비스 요소)
ACSE를 통해 엔티티의 ID와 컨텍스트를 확인하고 인증 보안 검사를 적용 가능

3-2-3. ICCP와 MMS의 관계

실제 데이터 센터를 나타내기 위해 가상제어센터(VCC)라는 추상적인 개념을 사용
MMS의 가상제조기기(VMD)개념의 확대로 실제 계통운영센터의 모든 데이터들을 추상화하여 표현

MMS의 객체와 서비스들 중 일부분이 매핑되어서 사용
ICCP의 서비스
- 제어센터 응용어플리케이션으로 서비스를 제공
- MMS의 서비스와 프로토콜, 그리고 기능을 이용하는 표준화된 응용프로토콜
- MMS객체에 매핑되어있는 구조화된 데이터를 표현

(MMS와 ICCP의 차이점)
=> 둘다 사용자에게 서비스를 제공한다는 점은 같지만
ICCP는 제어센터간에 메세지 교환을 위해 최적화 되었다는 점에서 다르다.

3-3. 전송계층

=> OSI 7계층 구조에서 ICCP를 사용하기 위해 COTP, TPKT 프로토콜이 필요하다.

COTP
- TCP와 기능이 거의 유사하지만
- TCP는 스트림 기반의 통신을 제공 / COTP는 패킷 기반의 통신을 제공
TPKT
- TCP/IP 스택 위에서 COTP를 사용하기 위해 제공

4. ICCP 프로토콜의 특징

4-1. ICCP의 사용모델

ICCP를 사용시 서로 다른 여러 프로세스간의 통신을 진행
각 시스템 통신시 각자의 통신규약 대신 ICCP 하나의 통신을 이용하여 통신 가능
시스템 통합시 비교적 적은 비용으로 통합을 이룰 수 있다.

4-1-1. 제어센터 구분

(제어센터)

하나 또는 그 이상의 가상제어센터로 모델링

(가상제어센터)

제조환경의 실제 디바이스의 기능을 매핑한 것으로 서버기능의 집결체
응용프로그램과 실제 디바이스 사이에 위치하여
기계의 실제 기능과 동작을 MMS의 추상적인 객체로 매핑하는 수단

=> ICCP 가상제어센터(VCC)를 MMS 가상제조기기(VMD)로 매핑하여
ICCP VCC는 MMS VMD가 실제 디바이스를 위해 행하는 것처럼 제어센터를 위해 같은 기능을 수행

4-1-2. 클라이언트, 서버 모델

가상제어센터의 의미와 관련지어 클라이언트와 서버를 정의
클라이언트
- ICCP 서비스 요청을 위해서 가상제어센터를 이용하는 통신 개체
- Method : Operation (클라이언트의 요청에 응답)
서버
- 서비스 요청에 대해 가상제어센터로서 행동하는 통신 개체
- Method : Action (서버에서 설정된 매커니즘에 따라 보내는 report)

4-2. Conformance Block

표준에서 서버의 역할에 따라 객체를 그룹핑한 것

Block 1
: 기본적인 통신에 대한 부분으로써 모든 ICCP서버가 필수적으로 가져야하는 항목
나머지 블록
: 서버가 수행하는 역할에 따라 선택 가능

4-3. Biteral Table

서버에서 요청유형에 따라 접근제어하기 위한 테이블
서버에 존재하는 정보에 대해 4가지 종류의 설정이 가능
("실행", "읽기와 쓰기", "읽기", "접근불가")
VCC에 정의된 command, 가상변수를 table에 지정하여 지정된 정보나 동작만 수행할 수 있게 해준다.

5. ICCP 프로토콜 통신

=> iccp2.pcap에 대한 패킷 흐름 쫒아감

구현 언어 : C
사용한 라이브러리 : libtase2
동작 플랫폼 : Ubuntu

client.c, server.c 코드는 비공개

(1) server.c

(코드)

- VCC구성
	- buffer, IndicatePoint(내부 변수 및 state), Command등 등록
	- DS Transfer
	  => report할 때 어떤 정보를 내보낼 것인가?
- Biteral tables
	- 접근하는 ap에 따라서 어떤 IndicatePoint나 command에 접근하게 할껀지 정의

- 일정시간이 지날때마다 정의된 코드 수행

(2) client.c

(코드)

(setting)
- AP Setting
- handler 함수

(initial)
- server ip, apTitle을 통해 연결시도
- 연결된 서버의 내부 정보 인식
- IM TransferSet
  => Report 정보
- 기존에 있던 DataSet삭제 후 재정의

(Read Value)
- domain에서 얻은 DataSet에서 얻은 데이터들을 출력

(3) 동작 패킷 확인

=> client, server의 통신내역 캡쳐(pcap)

1. TCP SYN, ACK
2. COTP SYN,ACK
3. ASCE 
4. MMS
	- TASE.Version, Support Feature 값에 대한 요청
	- identify(MZ automation, TASE.2, 2.3.0) 값 요청
	- IM_Transfer_Set설정(report용)
	- read동작전 이전 DataSet 및 재정의
	- domain요청후 내부 가상변수가 무엇인지 반환
	- 각 가상변수에 해당하는 값 반환
5. TCP FIN, ACK

6. ICCP의 보안요소

6-1. 기존의 ICCP

Biteral Table을 이용한 데이터 접근 제어만을 보안요소로 가지고 있다.
그래서 데이터 위/변조, 데이터 유출과 같은 문제에 대한 대응책이 없음
보안에 취약하기 때문에 일부 Secure ICCP를 제공(암호화, 인증)

6-2. Secure ICCP

SSL/TLS가 데이터 위/변조 혹은 데이터 유출과 같은 보안 위협에 대응책으로 사용됨
하지만 복호화하는 과정에서 키를 알고 있어야하기 때문에 "키 교환에 대한 문제점"이 존재
그래서 "키 교환 과정"에서 공개키-개인키가 쓰인다.
정상적인 제어센터인지 파악을 위해서 X.509를 적용한 인증서 기반의 인증을 제공

6-3. 추가 고려해야할 보안요소

ICCP 통신과정에서 "하위계층" 보안 취약점
- ex) 2006년 퍼징으로 COTP, TPKT의 보안 취약점
키관리의 어려움
실제 출시되는 ICCP제품의 경우 Secure ICCP가 지원하지 않거나, 일부만 지원하여 다른 보안 요소가 정상적으로 동작하여도 안전성을 보장받을 수 없다.
적용되는 보안 기술이 구 버전의 보안기술일 경우 문제점이 있을 수 있다.

6-4. 대응책

ICCP의 보안에 관련된 표준 IEC 62531이 존재하지만 Secure ICCP 제품마다 조금씩 다른 보안기술이 적용되고 있다.
(보안기술)
- SSL/TLS, 인증서, 공개키-개인키
(인증)
- 일부 장치가 ICCP 프로토콜을 지원해도 인프라 부재시 사용할 수 없기 때문에 인프라가 필요하다
(하위계층 보안고려)
- 2006년 이후 COTP, TPKT에서 새로 발혀진 취약점은 존재하지 않지만
- 하위 게층에서 이용되는 프로토콜의 취약점 여부는 지속적인 확인이 필요하다.

Ubuntu에서 바이너리 작게 만드는 musl-gcc 컴파일러 설치

Greedun (lr-x-dl) — Sat, 19 Oct 2024 21:03:00 +0900

1. musl이란?

리눅스 커널 기반의 운영체제용으로 고안된 표준 라이브러리이다.
표준을 준수하는 libc 구현체를 개발하는 것을 목적으로 개발했다.

(특징)
- 가볍고 빠르며 간단하고 무료이다.
- 표준 준수하고 안정성 측면에서 정확성을 추구

2. musl-gcc 설치

ex)

// test.c
#include <stdio.h>

int main(){
	printf("Hello World\n");
	return 0;
}

컴파일할 코드는 c언어를 접했다면 한번쯤은 봤을 hello코드이다.

musl.cc 바이너리들이 모여있는 아래 링크에서 원하는 아키텍처에 따라 다운 받으면 된다.

(http://musl.cc/#binaries)
- x86_64 : "x86_64-linux-musl-native.tgz"
- arm : "aarch64-linux-musl-cross.tgz"

ex) x86_64환경

$ wget http://musl.cc/x86_64-linux-musl-native.tgz
$ tar -xvf x86_64-linux-musl-native.tgz

$ ls x86_64-linux-musl-native
bin  include  lib  libexec  share  usr  x86_64-linux-musl

$ x86_64-linux-musl-native/bin/gcc -o test test.c
$ ls 
test  test.c  x86_64-linux-musl-native  x86_64-linux-musl-native.tgz

위 과정을 거치면 musl을 이용하는 gcc로 test.c를 컴파일하여 test바이너리가 만들어기게 된다.

$ ./test
bash: ./test: No such file or directory

$ file test
test: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, not stripped
$ ldd test
./test: error while loading shared libraries: /lib/x86_64-linux-gnu/libc.so: invalid ELF header

test바이너리를 실행했을때 분명 파일이 있지만 없는 바이너리라고 표시된다.

그래서 추가적으로 file, ldd명령어를 확인했는데 다음과 같이 에러가 발생했다.
일단 이유로는 dynamic 바이너리 이기 때문에 libc파일을 시스템에서 자동으로 찾게 되는데 그 과정에서 glibc를 가르켜서 생긴 문제라고 ldd명령어로 추측했다.

3. 에러사항 해결

그래서 여러 실험으로 해결한 방법은 다음과 같다.

1 - 다운받은 폴더의 bin폴더까지 들어가서 gcc바이너리 이용
2 - dynamic 방식이 아닌 static 옵션으로 staic바이너리로 컴파일 하기

3-1. 내부에 bin폴더로 들어간뒤 gcc바이너리 이용

(2)번링크 블로그를 참조하면 내부에 bin폴더를 들어가서 gcc컴파일을 하는 것을 보고 처음에는 확실하게 그 바이너리를 쓸려고 저렇게 하는거나 생각했다.

$ cd x86_64-linux-musl-native/bin 
$ ./gcc -o test test.c

$ ./test
Hello World

하지만 방법을 찾기 위해 여러가지 시도해 보던 중 설마하고 해봤는데 dynamic방식, static방식으로 컴파일한 바이너리가 둘다 정상적으로 실행되는거 보면서 이유가 있었구나라는 것을 깨달았다.

$ file test
test: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=7bd8ff67bf97268f97ddde0a9fe1162f67b07bb9, for GNU/Linux 3.2.0, not stripped

$ ldd test
        linux-vdso.so.1 (0x00007ffce7b65000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4807a00000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4807c68000)

저런 방식으로 했을때 왜 실행이 되는지를 한번 생각해봤다.
이전에 외부에서 musl-gcc를 실행했을때는 없던 BuildID가 생기고 ldd명령어도 정상적으로 확인이 가능하다.

신기한 일이다...

x86_64-linux-musl-native/bin$ ls ../
bin  include  lib  libexec  share  test  usr  x86_64-linux-musl

추가적인 이유로 x86_64-linux-musl-native란 폴더가 기존 우분투 시스템 안에 또다른 작은 시스템을 필요한 파일들만 갖추고 형성한 것이라고 추측한다.

그래서 "/usr/bin/musl-gcc"로 바이너리를 카피해서 쓰거나 내부의 bin폴더를 외부에서 접근해서 컴파일 시도하면 필요한 파일들을 찾지 못하여 링킹과정이 불완전해지고 실행이 안되지 않을까 한다.

3-2. static 옵션으로 staic바이너리로 컴파일 하기

두번째 방법은 원래 이 방식으로 컴파일하던 목적이 커널 익스를 위한 바이너리를 만들기 위해서 였기 때문에 static방식으로 컴파일 했어야 했다.

ldd명령어로 라이브러리 링킹과정에서 문제가 발생했다는 것을 확인했기 때문에 static방식으로 컴파일하면 이 문제를 피할 수 있다고 판단했다.

$ x86_64-linux-musl-native/bin/gcc -o test test.c --static
$ ./test
Hello World

static바이너리로 컴파일 시도후 실행을 해봤고 다행히 잘 실행되는 것을 확인할 수 있었다.

3-3. 우분투 시스템으로 바이너리 복제시 에러사항

매번 musl-gcc의 폴더안에 gcc바이너리를 찾고 실행구문이 길어지는 것은 비효율적이라 생각해서 "/usr/bin/musl-gcc"경로로 gcc 바이너리를 복사하고 컴파일 시도를 해봤다.

$ sudo cp x86_64-linux-musl-native/bin/gcc /usr/bin/musl-gcc

$ musl-gcc -o test2 test.c
musl-gcc: fatal error: cannot execute ‘cc1’: execvp: No such file or directory
compilation terminated.

컴파일 시도를 하자마자 한번도 보지 못한 에러가 발생했다.
여태껏 gcc컴파일하면 한번도 본적이 없는 에러라 뭔가 싶었고 이대로 그냥 매번 컴파일 할때마다 경로를 찾아야하나 싶었다.

$ cp -r x86_64-linux-musl-native ~/
$ sudo ln -s /home/greedun/x86_64-linux-musl-native/bin/x86_64-linux-musl-gcc /usr/bin/musl-gcc

$ musl-gcc -o test2 test.c --static
$ ./test2
Hello World

그러다 마지막으로 시도해보자 한 방법은 심볼릭 링크를 이용한 방법이다.
임베디드 시스템이나 다른 시스템을 들어가서 확인해보면 은근 심볼릭 링크된 처리가 많다는 것이 생각났다.
home폴더로 다운받은 내용들을 옮기고 거기로 "/usr/bin/musl-gcc"란 심볼릭링크를 생성하고 내부에 gcc바이너리를 가르키게 했다.

4. glibc, musl방식의 용량 차이

musl-gcc(static)보다 musl-gcc(dynamic)가 크기가 크게 나왔는데.....
(2)번 참조한 블로그에서도 그렇고 내 지식으로도 static의 크기가 적게 나오는게 맞는데....

greedun@lr-x-dl:~/RD/kernel/musl_test$ file musl_sta
musl_sta: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, not stripped

greedun@lr-x-dl:~/RD/kernel/musl_test$ file musl_dyn 
musl_dyn: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=7bd8ff67bf97268f97ddde0a9fe1162f67b07bb9, for GNU/Linux 3.2.0, not stripped

greedun@lr-x-dl:~/RD/kernel/musl_test$ file glibc_sta
glibc_sta: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=8c75dfa1d4c5c748220f2b4cbcb54bbcf3270af1, for GNU/Linux 3.2.0, not stripped

greedun@lr-x-dl:~/RD/kernel/musl_test$ file glibc_dyn
glibc_dyn: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=7bd8ff67bf97268f97ddde0a9fe1162f67b07bb9, for GNU/Linux 3.2.0, not stripped

그래서 추가적으로 file로 실수로 dynamic으로 컴파일을 시도했나 했지만 file명령어로 봤을때는 static으로 컴파일 한거 같았다.

(+) 해결은 아니지만 달라진점

위에서 다운받은 폴더 밖에서 수행하면 glibc가 링킹 시도하여 바이너리 실행시 파일이 없다고 하는 문제가 있었다는 생각에 혹시나해서 내부에서 static컴파일 시도를 해봤다.

그랬더니 static컴파일 하는 과정에서 glibc가 가져와서 컴파일되어 용량이 dynamic과 비슷하진것이었다.

내부에서 컴파일을 시도해보니 용량이 오히려 더 작아졌다.
의문점이 해결된 것은 아니지만 나중에 해결의 실마리가 될 수 있기 때문에 적어놓겠다.

참고링크

(1) https://musl.libc.org/
=> 공식 사이트

(2) https://zshchun.github.io/posts/musl-gcc%EB%A1%9C-%EB%B9%8C%EB%93%9C%ED%95%98%EA%B8%B0/

(3) https://www.freecodecamp.org/korean/news/rinugseu-symlink-tyutorieol-simbolrig-ringkeu-symbolic-link-reul-saengseonghago-sagjehaneun-bangbeob/
=> 심볼릭 링크 생성

(4) https://ko.wikipedia.org/wiki/Musl
=> musl에 대한 위키백과

(5) http://musl.cc/#binaries
=> musl.cc 바이너리들 모여있는 곳

[Tip] 맥북에서 usb시리얼 통신하는 법

Greedun (lr-x-dl) — Wed, 9 Oct 2024 18:54:38 +0900

1. serial통신 터미널 연결

1 - usb연결 수 /dev에서 찾기
2 - screen명령어를 통해 터미널로 접속

(1) usb연결 후 /dev에서 찾기

/dev 폴더에 "ls /dev/*usb*"를 했을 때 처음에는 아무것도 표시가 안된다.

하지만 usb를 연결한 이후에 다시 확인하면 (사진1)과 같이 새로운 표시된다.

(사진1) serial포트 연결

- cu : 시리얼 통신에 사용되는 컨트롤러를 의미

- tty : 시리얼 장치의 터미널을 의미

(2) screen명령어를 통해 터미널로 접속

"screen [tty.로 시작하는 파일명] [시리얼 통신 속도]"

를 통해 터미널에 접속할 수 있다.
<윈도우의 경우 putty프로그램을 쓰면 쉽게 접속할 수 있다.>

screen /dev/tty.usbserial-0001 115200

[시리얼 통신 속도]
- 데이터가 전송되는 속도를 비트 단위로 나타낸다.
- 초당 전송되는 비트의 수를 나타내는데 장비마다 지원하는 속도가 다르다.
- 따라서 통신할 장비의 사양에 고려한 적절한 속도를 찾아야한다.

2. screen 명령어

앞으로도 이 작업을 할 떄 유용한 명령어에 관해서 정리해두려고 한다.

# 스크린 생성
screen -S {지정할 이름} /dev/tty.usbserial-0001 115200

# 스크린 나열
screen -ls

# 스크린 삭제
screen -X -S {스크린 이름} Kill

# 스크린을 계속 돌리는 상태에서 원래 터미널로 돌아가는 명령어(deattach)
control + a + d

# 스크린 재진입
screen -r {스크린 이름}

참고링크

1 - https://seaotter.tistory.com/106
=> 맥북에서 usb2시리얼 통신
2 - https://daje0601.tistory.com/325
=> screen 명령어 사용법

Shellcoding

Greedun (lr-x-dl) — Tue, 6 Aug 2024 15:14:30 +0900

1. Shellcoding란?

1-1. 개요

(Shellcode란?)
익스플로잇을 위해 제작된 어셈블리 코드 조각이다.
어셈블리어와 기계어 코드는 일대일 대응이기 때문에 공격자가 rip를 주입한 shellcode로 옮긴다면 cpu에게 원하는 명령을 하도록 유도할 수 있게 된다.

[shellcode작성법을 알아야하는 이유]
수행할 대상의 아키텍처와 운영체제 그리고 수행 목적에 따라 어셈블리어는 다르게 작성되어야 한다.

아키텍처별로 자주 사용하는 쉘코드를 공유하는 사이트가 있지만
해당 쉘코드들은 범용적으로 작성되었기 때문에 제대로 작동이 안 될 가능성이 있다.

따라서 타겟 시스템에 맞는 최적의 쉘코드를 상황에 따라서 언제든지 작성할 수 있어야한다.

=> 쉘코드 모음 사이트 : http://shell-storm.org/shellcode/index.html

(기계어 변환 과정)

현재 사용중인 프로그램은 고수준의 언어가 컴파일 과정을 거쳐서 Assembly, Machine code같은 저수준 언어로 변경된 것이다.
이렇게 변환된 Machine code는 실행시 메모리에 올라가서 코드를 실행하게 된다.
어셈블리어와 기계어코드는 일대일대응이다.

1-2. Syscall

[필요한 사전지식]
- 레지스터 bit별 표현단위
- 어셈블리어
- 함수호출규약

assembly code에서 시스템 함수를 호출하기 위해 "int 0x80"(32), "syscall"(32,64)명령어를 사용할 수 있다.

(system call 번호 확인)

32bit - /usr/include/x86_64-linux-gnu/asm/unistd_32.h
64bit - /usr/include/x86_64-linux-gnu/asm/unistd_64.h

system call 정보는 운영체제, 프로세서의 아키텍처마다 다르기 때문에 맞춰서 작성해야한다.

(system call 인자 전달)

1-3. asm파일의 바이너리 변환 과정

[32bit - ASM32.asm]

section .data                           ; 데이터 세그먼트
    msg db  "Hello, world!",0x0a, 0x0d  ; 문자열과 새 줄 문자, 개행 문자 바이트
  
section .text                           ; 텍스트 세그먼트
    global  _start                      ; ELF 링킹을 위한 초기 엔트리 포인트
  
_start:
    ; SYSCALL: write(1,msg,14)
    mov eax, 4      ; 쓰기 시스템 콜의 번호 '4' 를 eax 에 저장합니다.
    mov ebx, 1      ; 표준 출력를 나타내는 번호 '1'을 ebx에 저장합니다.
    mov ecx, msg    ; 문자열 주소를 ecx에 저장니다.
    mov edx, 14     ; 문자열의 길이 '14'를 edx에 저장합니다.
    int 0x80        ; 시스템 콜을 합니다.
  
    ; SYSCALL: exit(0)
    mov eax, 1      ; exit 시스템 콜의 번호 '1'을 eax 에 저장합니다.
    mov ebx, 0      ; 정상 종료를 의미하는 '0'을 ebx에 저장 합니다.
    int 0x80        ; 시스템 콜을 합니다.

=> 32, 64bit asm의 차이점은 인자전달에 사용되는 레지스터와 시스템 콜 번호이기 때문에
asm코드는 32bit만 작성해두겠다.

(Build)

(32bit)
$ nasm -f elf ASM32.asm
$ ld -m elf_i386 -o hello ASM32.o

$ ./hello
Hello, world!

$ file ./hello
`./hello: ELF` `32``-bit LSB executable, Intel` `80386``, version` `1` `(SYSV), statically linked, not stripped`


(64bit)
$ nasm -f elf64 ASM64.asm
$ ld -o hello64 ASM64.o

$ ./hello64
hello, world!

$ file ./hello64
./hello64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped

f인자 : nasm으로 어셈블하여 ELF바이너리로 링크할 수 있는 목적(object)파일로 만든 것
ld명령어 : 어셈블된 목적 파일에서 실행가능한 바이너리로 변환

2. Shellcoding 방법

(목적파일(.o)이 쉘코드가 안되는 이유)
- 메모리 세그먼트를 사용
- 목적파일은 독립적으로 실행 가능한 프로그램이 아니라
- 링커에 의해 연결되어야 하는 프로그램의 일부이기 때문

2-1. 바이트 형태로 전달

(독자적으로 동작 가능하게끔 변경)
- 텍스트, 데이터 세그먼트를 사용하지 않음
- 함수의 호출을 call명령어를 사용
- 함수에서 사용될 문자를 해당 명령어 뒤에 작성후 스택포인터 조절로 사용

[32bit - ASM32.s]

BITS 32                         ; nasm에게 32비트 코드임을 알린다
  
call helloworld                 ; 아래 mark_below의 명령을 call한다.
db "Hello, world!", 0x0a, 0x0d  ; 새 줄 바이트와 개행 문자 바이트
  
helloworld:
    ; ssize_t write(int fd, const void *buf, size_t count);
    pop ecx         ; 리턴 주소를 팝해서 exc에 저장합니다.
    mov eax, 4      ; 시스템 콜 번호를 씁니다.
    mov ebx, 1      ; STDOUT 파일 서술자
    mov edx, 15     ; 문자열 길이
    int 0x80        ; 시스템 콜: write(1,string, 14)
  
    ; void _exit(int status);
    mov eax,1       ;exit 시스템 콜 번호
    mov ebx,0       ;Status = 0
    int 0x80        ;시스템 콜: exit(0)

(build)

$ nasm ASM32.s
$ ndisasm -b32 ASM32

(Test)

=> python3에 쉘코드 바이트값 전달하여 수행

# print bytecode
f = open('ASM32','r')
data = f.read()
print(data) # 바이트 값 출력

// shellcode.c
#include<stdio.h>
#include<string.h>
 
unsigned char shellcode [] = "\xe8\x0f\x00\x00\x00Hello, world!\n\rY\
\xb8\x04\x00\x00\x00\xbb\x01\x00\x00\x00\xba\x0f\x00\x00\x00\xcd\x80\
\xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80";
unsigned char code[];
 
void main(){
    int len = strlen(shellcode);
    printf("Shellcode len : %d\n",len);
    strcpy(code,shellcode);
    (*(void(*)()) code)();
}

(Build & Run)

$ gcc -o shellcode -fno-stack-protector -z execstack --no-pie -m32 shellcode.c
$ ./shellcode
Shellcode len : 2
Segmentation fault (core dumped)

=> 에러 발생????
-> 문제의 원인 및 해결 방식은 아래 3번에서 서술

(\x00이 제거된 asm코드)

BITS 32         ; nasm에게 32비트 코드임을 알린다
 
jmp short last  ; 맨 끝으로 점프한다.
helloworld:
    ; ssize_t write(int fd, const void *buf, size_t count);
    pop ecx     ; 리턴 주소를 팝해서 exc에 저장합니다.
    xor eax,eax ; eax 레지스터의 값을 0으로 초기화합니다.
    mov al, 4   ; 시스템 콜 번호를 씁니다.
    xor ebx,ebx ; ebx 레지스터의 값을 0으로 초기화합니다.
    mov bl, 1   ; STDOUT 파일 서술자
    xor edx,edx ; edx 레지스터의 값을 0으로 초기화합니다.
    mov dl, 15  ; 문자열 길지
    int 0x80    ; 시스템 콜: write(1,string, 14)
 
    ; void _exit(int status);
    mov al,1    ;exit 시스템 콜 번호
    xor ebx,ebx ;Status = 0
    int 0x80    ;시스템 콜: exit(0)
  
last:
    call helloworld ; 널 바이트를 해결하기 위해 위로 돌아간다.
    db "Hello, world!", 0x0a, 0x0d  ; 새 줄 바이트와 개행 문자 바이트

(Test)

#include<stdio.h>
#include<string.h>
 
unsigned char shellcode [] = "\xeb\x15\x59\x31\xc0\xb0\x04\x31\xdb\xb3\
\x01\x31\xd2\xb2\x0f\xcd\x80\xb0\x01\x31\xdb\xcd\x80\xe8\xe6\xff\xff\xff\
Hello, world!\n\r";
unsigned char code[] = "";
 
void main()
{
    int len = strlen(shellcode);
    printf("Shellcode len : %d\n",len);
    strcpy(code,shellcode);
    (*(void(*)()) code)();

$ gcc -o shellcode2 -fno-stack-protector -z execstack --no-pie -m32 shellcode2.c
$ ./shellcode2
Shellcode len : 43
Hello, world!

2-2. 인라인 어셈

[순서]
1. 실행할 어셈블리어
2. 테스트할 c코드 작성

(asm코드)

; write(1,"Hello world!",12)
mov rax, 0x646c72
push rax
mov rax, 0x6f57206f6c6c6548
push rax
xor rdi, rdi
inc 0x1
mov rsi, rsp
xor rdx rdx
add rdx 0xc
xor rax, rax
int 1
syscall

(c코드)

// write(1, "Hello world", 12);
// exit(0);
__asm__(
    ".global run_sh\n"
    "run_sh:\n"

    "mov rax, 0x646c72\n"
    "push rax\n"
    "mov rax, 0x6f57206f6c6c6548\n"
    "push rax\n"
    "xor rdi, rdi\n"
    "inc rdi\n"
    "mov rsi, rsp\n"
    "xor rdx, rdx\n"
    "add rdx, 0xc\n"
    "xor rax, rax\n"
    "inc rax\n"
    "syscall\n"
    "\n"
    "xor rdi, rdi      # rdi = 0\n"
    "mov rax, 0x3c	   # rax = sys_exit\n"
    "syscall		   # exit(0)");

void run_sh();

int main() { run_sh(); }

(컴파일)

$ gcc -o test test.c -masm=intel
$ ./test
Hello World

3. Shellcode 작성시 주의사항

(쉘코드에 0x00바이트가 들어가면 생기는 문제)
-> 에러가 발생한 이유 : 쉘코드에 포함되어있는 0x00값 때문
(문자열을 다루는 함수들은 문자열의 끝을 0x00으로 판단한다.)
-> 따라서 쉘코드상에서 0x00을 제거하는 작업을 해야한다.

[\x00 바이트 제거방법]
1. jmp "다른 함수"
2. mov 명령어

(\x00 바이트 제거방법)

(1) jmp "다른 함수"

[null byte가 들어간 이유]
call명령어의 피연산자에서 사용 가능한 값의 크기는 dword(32bits)이기 때문에
작은 값을 사용 될 경우 남는 부분에 null byte가 포함되게 된다.

(해결법)

하단의 새로운 함수(a)를 생성
jmp명령어를 사용해 해당 함수로 점프
그리고 해당 함수에서는 원래 사용하려던 함수를 재호출한다.

(디스어셈블 확인)

$ nasm ASM32-2.s
$ ndisasm -b32 ASM32-2
00000000  EB1E              jmp short 0x20
00000002  59                pop ecx
00000003  B804000000        mov eax,0x4
00000008  BB01000000        mov ebx,0x1
0000000D  BA0F000000        mov edx,0xf
00000012  CD80              int 0x80
00000014  B801000000        mov eax,0x1
00000019  BB00000000        mov ebx,0x0
0000001E  CD80              int 0x80
00000020  E8DDFFFFFF        call dword 0x2
00000025  48                dec eax
00000026  656C              gs insb
00000028  6C                insb
00000029  6F                outsd
0000002A  2C20              sub al,0x20
0000002C  776F              ja 0x9d
0000002E  726C              jc 0x9c
00000030  64210A            and [fs:edx],ecx
00000033  0D                db 0x0d

=> 컴파일된 어셈블리어를 보면 call명령어가 들어가 있음에도 null byte가 제거된 것을 볼 수 있다.
-> 제거된 이유는 음수이기 때문이다.

jmp short 0x20로 주소 0x20으로 이동
(jmp명령어의 피연산자에서 사용 가능한 값의 크기 dword(32bits))
=> 사용 가능한 값의 크기 -128 ~ 127
call명령어 helloworld함수를 호출하기 위해 -0x20으로(0x2-0x24)로 이동
-0x22를 표현하기 위해 2의 보수로 값을 표현하게 된다.
이 과정에서 null byte가 제거되게 된다.

(2) mov 명령어

(레지스터의 범위)
64bit - 8bit

(레지스터 값을 초기화하는 방법)

[레지스터 영역을 사용하기 전 초기화하는 이유]
=> 쉘코드가 실행되기 이전의 레지스터의 값을 그대로 사용하기 때문
- 그럼 하위비트의 값만 변경한다면?
-> 명령어마다 어떤 단위의 레지스터를 사용할지 다 알 수 없고.
그전에 존재하는 값들이 무엇인지 알 수도 없기때문에 0x00으로 초기화하는 것이 좋다.

(해결법)

1. sub명령어를 이용한 초기화
2. xor명령어를 이용한 초기화

(어셈)

section .text
    global _start

_start:
    ; XOR을 사용하여 eax를 0으로 만들기
    mov eax, 5          ; eax = 5
    xor eax, eax        ; eax = eax ^ eax = 0

    ; SUB을 사용하여 ebx를 0으로 만들기
    mov ebx, 5          ; ebx = 5
    sub ebx, ebx        ; ebx = ebx - ebx = 0

    ; 프로그램 종료
    mov eax, 1          ; 시스템 호출 번호 (exit)
    xor ebx, ebx        ; 반환 값 0
    int 0x80            ; 시스템 호출

(결론)
=> sub명령어는 플래그 레지스터에 영향을 주어 이후 분기 명령어에 영향을 줄 수 있기 때문에 xor명령어로 레지스터 값을 초기화하는 것이 효율적이다.

참고링크

(1) https://www.lazenca.net/display/TEC/01.The+basics+technic+of+Shellcode
(2) System V ABI" Calling Convention

1 - 시간복잡도와 빅오 표기법

Greedun (lr-x-dl) — Fri, 12 Jul 2024 15:08:34 +0900

1. 알고리즘

1-1. 알고리즘이란?

[Fig1. ]

입력 정수에서 출력 정수를 구하기 위한 일반화된 작업을 정리하여 의사코드나 소스코드의 형태로 구현한 것이다.
문제를 해결하는 방법 그 자체를 말한다.

(알고리즘 충족 조건)
ex) 요리 레시피

타당성 : 구현할 수 있고 실용적이어야 한다.
=> 알고리즘의 성능 담당
정밀성 : 변하지 않는 명확한 작업 단계를 가져야 한다.
유일성 : 각 단계마다 명확한 다음 단계를 가져야 한다.
유한성 : 특정 수의 작업 이후에 정지해야한다.
입력 : 정의된 입력을 받아들일 수 있어야 한다.
출력 : 답으로 출력을 내보낼 수 있어야 한다.
일반성 : 정의된 입력들에 일반적으로 적용할 수 있어야 한다.

1-2. 알고리즘 성능 기준

[Fig2. ]

시간 기준 - 알고리즘이 적은 시간이 사용될 수록 빠르게 동작했다는 것을 의미한다.
공간 기준 - 알고리즘이 적은 공간을 사용 할수록 적은 용량의 메모리를 사용했다는 것을 의미한다.

(어떤 것을 기준으로 하는 것이 중요한가?)

주어진 상황에 따라서 필요한 속도, 메모리의 기준이 다르기 때문에 명확하게 정할 수 없다.
하지만 코딩테스트에서는 제한 시간 및 사용가능한 메모리가 주어지기 때문에 명확하다.
따라서 알고리즘의 수행속도와 특성을 분석하는 능력을 키우는게 필요하다.

2. 시간 복잡도 분석

: 동일한 입력값으로부터 출력값까지의 시간을 측정하는 방법으로
좀 더 빠른 알고리즘을 만들기 위해는 "알고리즘의 속도를 어떻게 측정할지"를 정해야 한다.

(알고리즘 속도 측정을 해야하는 이유는?)

알고리즘을 바뀌었을때 어떤 알고리즘이 더 빠른지 알 수 없지 때문에
문제에서 해결할 입력의 크기가 매우 작을 경우 시간복잡도는 큰 의미를 갖지 못할 수 있다.
-> 따라서 입력값이 매우 크다고 보통 가정한다.

(1) 절대시간 측정

: 알고리즘이 동작이 완료 할때까지 걸리는 시간 측정

(절대시간 측정시 문제점)

여러가지 변수에 따라 결과가 다르게 나올 수 있기 때문에 환경에 제약받지 않는 기준이 있어야 한다.
ex) 언어, 하드웨어, 운영체제, 컴파일러등
수행시간이 다양한 입력에 대한 실행시간을 반영하지 못한다.

(2) 연산횟수 측정

: 알고리즘의 동작이 완료될 때까지 연산횟수가 몇번인지 계산

코딩테스트에서는 제한시간 내에 수행 할 수 있을지가 중요하기 때문에,
최악의 경우를 기준으로 연산 횟수를 정하는게 합리적
알고리즘의 수행시간을 지배하는 것은 반복문이다.
=> 입력의 크기에 따라 수행횟수가 정해질 수 있기 때문

ex)
- (입력의 크기가 작을때) 반복문보다 다른 부분이 갖는 비중이 클 수 있음
- (입력의 크기가 클 때) 반복문이 알고리즘 수행시간을 지배함

3. 함수에 따른 시간복잡도

(함수에 따른 시간복잡도 크기)

[Fig3. ]

=> (1)부터 (7)까지 우선순위이면 높은 순위일수록 복잡한 함수라고 볼 수 있다.

(시간 복잡도에 영향을 미치는 것)
ex) 다항(지수) vs 선형 vs 선형이하(로그)

[Fig4. ]

=> 주로 입력되는 값에 따라서 알고리즘을 다르게 써야할 수도 있다.

ex) 간단하게 밑값이 2인 식들을 기준으로 예시로 잡았다.

그래프를 보면(root 2 ~ 4) 범위를 기준으로 값의 대소관계가 바뀐다.
만약에 주로 쓰이는 입력값이 해당 범위 내부에 속한다면 오히려 지수함수를 쓰는게 더 효율적일수 있다.
따라서 시간복잡도로 알고리즘의 성능을 파악할 수도 있지만
주로 쓰이는 입력값의 분포나 특징도 파악하는 것도 알고리즘을 선택시 반영하는게 좋다.

3-1. 선형시간 알고리즘

=> 다항함수, 로그함수와 다항함수의 조합

ex) 배열 내부의 최대값을 찾는 코드

#include <stdio.h>

int findMax(int arr[], int n) {
    int max = arr[0];
    for (int i = 1; i < n; i++) {
        if (arr[i] > max) {
            max = arr[i];
        }
    }
    return max;
}

int main() {
    int arr[] = {1, 2, 3, 4, 5, 6, 7, 8, 9};
    int n = sizeof(arr) / sizeof(arr[0]);
    int max = findMax(arr, n);
    printf("The maximum value in the array is: %d\n", max);
    return 0;
}

findmax함수 내부에서 배열의 크기 N 만큼만 실행되기 때문에 시간복잡도는 N이다.
입력값을 넣으면 직선의 형태를 띠고 있기 때문에 선형 시간 알고리즘이라고 부른다.
선형 시간에 실행되는 알고리즘을 대개 우리가 찾을 수 있는 알고리즘 중 가장 좋은 알고리즘이다.

3-2. 선형이하 시간 알고리즘

=> 로그함수, 상수함수

ex) 배열내에 값 검색

#include <stdio.h>

int binarySearch(int arr[], int l, int r, int x) {
    while (l <= r) {
        int m = l + (r - l) / 2;

        // 값이 중간 값과 같은 경우
        if (arr[m] == x)
            return m;

        // 값이 중간 값보다 작은 경우
        if (arr[m] < x)
            l = m + 1;

        // 값이 중간 값보다 큰 경우
        else
            r = m - 1;
    }

    // 값이 배열에 없는 경우
    return -1;
}

int main() {
    int arr[] = {2, 3, 4, 10, 40};
    int n = sizeof(arr) / sizeof(arr[0]);
    int x = 10;
    int result = binarySearch(arr, 0, n - 1, x);
    if (result != -1)
        printf("Element is present at index %d\n", result);
    else
        printf("Element is not present in array\n");
    return 0;
}

binarysearch함수는 내부에서 이미 정렬된 배열에서 원하는 값을 함수이다.
매 반복마다 탐색 범위를 절반으로 줄이기 때문에 배열의 크기가 n이라고 할 때 시간복잡도는 log_2(n)이다.

(증명 - 왜 시간복잡도가 지수함수인가?)

"1 + 2^1 + 2^2 + ... + 2^k = N " 식에 대한 등비수열의 합

$$ N = \frac{a(1 - r^n)}{1 - r} (r=2) $$

[Fig5. ]

r=2이고 a=1이기 때문에 식을 전개했을 때 "N = 2^k"가 나온다.
지수로그 변환으로 k = log_2(N)이 된다.
따라서 이분탐색알고리즘의 시간복잡도는 로그함수이다.

3-3. 지수시간 알고리즘

=> 지수 함수

ex) 재귀함수 형식의 피보니치 수열

#include <stdio.h>

// 재귀적으로 피보나치 수를 계산하는 함수
int fibonacci(int n) {
    if (n <= 1)
        return n;
    return fibonacci(n - 1) + fibonacci(n - 2);
}

int main() {
    int n = 10; // 계산할 피보나치 수의 위치
    printf("Fibonacci number at position %d is: %d\n", n, fibonacci(n));
    return 0;
}

n이 1이 될때까지 2개의 재귀함수를 호출하여 진행된다.
반복횟수는 "func(n) = func(n-1) + func(n-2)"로 계속 중복되는 하위 함수들이 반복되기 때문에 2^n이다.

3-4. 재귀적 팩토리얼 함수

=> 가장 비효율적인 수식

ex) 재귀적 팩토리얼 계산

#include <stdio.h>

// 재귀적으로 팩토리얼을 계산하는 함수
int factorial(int n) {
    if (n == 0 || n == 1)
        return 1;
    return n * factorial(n - 1);
}

int main() {
    int n = 5; // 계산할 팩토리얼의 값
    printf("Factorial of %d is: %d\n", n, factorial(n));
    return 0;
}

"팩토리얼 계산"이란 n!이라고 표기될 때 n부터 1사이에 모든 정수를 곱한 값을 의미한다.
해당 값을 계산하기 위해 매번 값을 나열 할 수 없기 때문에 반복문이나 재귀함수로 자동으로 처리한다.
재귀함수로 이루어진 알고리즘의 경우 계속되는 함수 호출로 인한 메모리 오버헤드 발생으로 인해 스택 오버플로우가 발생할 수 있다.

[가장 비효율적인 알고리즘]
1. 지수 시간 알고리즘
2. 재귀적 팩토리얼 시간 알고리즘
3. 다항 시간 안에 해결할 수 없는 NP-완전 문제

3-5. 재귀적 알고리즘 vs 반복적 알고리즘

[요약]
- 재귀적 알고리즘 : 문제의 자연스러운 표현을 제공하고 코드를 간결하게 만들어준다.
- 반복적 알고리즘 : 효율적인 실행속도와 메모리 관리를 제공한다.

=> 재귀함수로 피보나치 수열, 팩토리얼 함수를 위에 예시로 들었다.
위에 함수들은 연산횟수면에서 비효율적이기 때문에 반복적 알고리즘으로 바꿀 필요가 있다.

ex) 반복적 팩토리얼을 계산하는 함수

#include <stdio.h>

// 반복적으로 팩토리얼을 계산하는 함수
int factorial_iterative(int n) {
    int result = 1;
    for (int i = 1; i <= n; i++) {
        result *= i;
    }
    return result;
}

int main() {
    int n = 5;
    printf("Factorial of %d is: %d\n", n, factorial_iterative(n));
    return 0;
}

ex) 반복적 피보나치 수열을 계산하는 함수

#include <stdio.h>

// 반복적으로 피보나치 수열을 계산하는 함수
int fibonacci_iterative(int n) {
    if (n <= 1)
        return n;
    
    int a = 0, b = 1, temp;
    for (int i = 2; i <= n; i++) {
        temp = a + b;
        a = b;
        b = temp;
    }
    return b;
}

int main() {
    int n = 5;
    printf("Fibonacci number at position %d is: %d\n", n, fibonacci_iterative(n));
    return 0;
}

팩토리얼의 경우 반복문으로 변경했어도 큰 차이가 없어 보이지만
피보나치 수열의 경우 반복문으로 변경했을 경우 내부 연산이 추가된 것을 확인할 수 있다.

[Fig6. ]

코드를 비교해봤을때 재귀적, 반복적 알고리즘마다 장단점이 존재하며 위와 같이 정리할 수 있다.

(재귀적 알고리즘을 사용해야하는 경우)

[고려야해할점]
1. 문제의 특성과 해결 방법에 대한 직관적 이해 - (1), (4)
2. 코드의 가독성 - (2)
3. 재귀호출의 안정성 - (3)

하지만 반복적 알고리즘이라고 다 좋은 것은 아니다.
상황에 따라서 재귀적 알고리즘이 더 좋은 경우가 있다.

(1) 문제의 재귀적 정의가 명확할 경우

문제 정의 자체가 재귀적으로 되어있어서 재귀적 알고리즘이 자연스럽고 직관적으로 표현될 수 있는 경우

ex) 트리구조탐색, 그래프 순회등

(2) 코드의 가독성이 중요한 경우

- 코드의 가독성을 높이고 유지보수를 용이하게 만들 수 있는 경우
- 문제의 본질을 더 잘 반영할 수 있어서 코드 이해하기 쉽게 만듦

(3) 재귀 호출의 깊이가 제한적인 경우

깊이를 제한하거나 입력크기를 제한할 경우 재귀적 알고리즘을 코드의 가독성을 높이고 보다 효율적으로 사용할 수 있다.

(4) 동적계획법에서의 재귀적 접근

문제를 재귀적으로 정의하고 하향식(top-down) 접근할 때가 있습니다.
이때 동적 계획법을 이용하여 부분적으로 해결가능합니다.

(재귀적 알고리즘의 사용 사례)

트리구조의 순회
분할정복 알고리즘(병합정렬)
백트래킹 알고리즘(N-Queens 문제해결)
etc

=> 따라서 특정 문제에 대한 해결방식을 선택할 때 그 문제의 특성과 실행환경을 고려해야한다.

4. 점근적 표긱법: O표기

4-1. 정의를 알기 전 알아야할 사항

[Fig7. ]

매번 시간복잡도를 상세히 정의하면 좋지만 코드가 클수록 오래걸린다.
또한 "N^2+3N+5"이 경우 N이 커질수록 N^2의 영향력이 커져서 3N,5의 값이 의미없게 된다.
코딩테스트는 연산회수를 측정하는 시험이 아니기에 대략적으로만 알면 된다.
N^2+3N+5 ≈ N^2 이라고 생각해도 된다.

4-2. 점근적 표기법이란?

정확한 연산횟수가 아닌, <b>연산횟수의 추이</b>를 활용해 시간 복잡도를 표기
표시할 때 빅요 표기를 사용하는데
빅오 표기란 최악의 경우를 고려해서 점근적 표기법으로 나타내는 것을 말한다.
시간 복잡도를 통해서 내가 작성한 알고리즘의 성능을 유추할 수 있다.
ex) N^2 + 3N + 5 => O(N^2)

빅오 표기법의 시간 복잡도

[Fig8. ]

함수의 따른 시간 복잡도를 빅오표기법으로 표현한 그래프이다.
입력값이 커질 수록 각 함수의 영향력 차이가 어느정도인지 유추할 수 있다.

[코딩테스트에서의 활용법]
=> 입력값을 기준으로 가용한 자료구조 및 알고리즘을 고려가능하다.

ex) 입력값이 100만까지 가능
-> 만약 연산횟수가 N^M이라면 시간초과 / 연산횟수가 log N이면 Pass 로 예상할 수 있다.

4-3. 메서드의 시간 복잡도 파악

저장되는 메모리 공간의 특징이나 메서드에 따라서 시간 복잡도가 달라질 수 있다.
따라서 이 부분은 알고리즘의 성능을 좌지우지 할 수 있기 때문에 직접 코딩을 수행하고 분석하여 파악해두는게 좋다

ex)
- std::set vs std::unordered_set
- set::vector vs std::set
- std::map vs std::unordered_map
=> c++의 경우 일부 예시를 아래 링크에서 확인할 수 있다.
(https://github.com/dremdeveloper/codingtest_cpp/tree/main/performance)

참고링크

(1) https://www.desmos.com/calculator/ifg3mwmqun?lang=ko

=> 그래프 그려주는 사이트

(2) https://inf.run/t92e1

=> 참고한 인프런 강의

(3) Book - 알고리즘 문제해결전략

(4) https://chatgpt.com/share/923ae9ae-3032-4814-a7cc-751e149a935a

=> 알고리즘 예시 chatgpt

(5) https://velog.io/@jacob3015/2022.04.13-BIG-O-표기법

=> 빅오표기법 비교 그래프

CTF - Pwnable_문제 환경 구성

Greedun (lr-x-dl) — Tue, 2 Jul 2024 01:43:48 +0900

1. socat을 이용한 문제 구성

[필요한 파일]
1 - 문제파일(바이너리, *.py등)
2 - Dockerfile, docker-compose.yml
3 - README.md

1-1. socat이란?

:다목적 소켓 터널링을 위한 유명한 유닉스 소켓 프로그램

(socat 설치)

apt-get install socat

1-2. 문제파일 준비

(1) 입출력이 가능한 문제파일을 작성

ex) test.c

# test.c
#include <stdio.h>
#include <string.h>

#define FLAG "RD{welldone_you_found_the_flag}"

void check_input(char *input) {
    if (strcmp(input, "1234") == 0) {
	    printf("%s", FLAG);
        printf("Correct!\n");
    } else {
        printf("Wrong!\n");
    }
}

int main() {
    char input[100];

    printf("Enter the flag: ");
    fgets(input, sizeof(input), stdin);

    // Remove newline character from input
    input[strcspn(input, "\n")] = 0;

    check_input(input);

    return 0;
}

1-3. Dockerfile, docker-compose.yml 작성

(바이너리만 제공하는 경우)

FROM ubuntu:22.04@sha256:b6b83d3c331794420340093eb706a6f152d9c1fa51b262d9bf34594887c2c7ac

ENV PROB test
ENV PORT 8888

RUN apt-get update -y
RUN apt-get install -y socat

RUN adduser $PROB

WORKDIR /home/$PROB

COPY ./flag ./flag
COPY ./deploy/prob ./prob

RUN chmod 644 ./flag
RUN chmod 755 ./prob

USER $PROB

EXPOSE 8888
CMD socat TCP-LISTEN:$PORT,reuseaddr,fork EXEC:./prob,stderr

ex) docker-compose.yml

version: '3'
services:
  socat:
    image: socat_test
    ports:
      - "38888:8888"

=> docker-compose는 관리용으로써 문제제공시 compose파일은 제공하지 않는다.

실행 : docker-compose up -d
종료 : docker-compose down

1-4. README.md 작성

[나만의 README 작성 프레임]
# Title : 
# Author : 
# Desc
asdf

---

(flag)
RD{test}

(익스 원리)

(익스플로잇 코드)

1-5. 환경 구축 테스트

(폴더구성)
> tree
.
├── Dockerfile
├── deploy
│   └── prob
├── docker-compose.yml
└── flag

docker build -t {이미지 이름} .
docker run --rm -it -p {외부포트}:{내부포트} {이미지 이름}
nc localhost {외부포트}

주의사항

(1) - 권한 에러

(base)  Greedun    > ~/Downloads/test
> docker run --rm -p 38888:8888 socat_test
2024/06/30 07:28:43 socat[9] E execvp("./prob", "./prob"): Permission denied
2024/06/30 07:28:43 socat[8] E waitpid(): child 9 exited with status 1

=> 해당 에러는 flag, prob파일에 작업하려는데 올바른 권한이 없어서 생기는 에러이다.

-> 이 에러를 해결하기 위해서는 dockerfile에서 권한을 부여하는 명령어를 작성해야한다.

(2) - docker run시 취소 불가 상황

(문제 원인)

[chatgpt왈]
- 컨테이너가 포그라운드 프로세스로 실행되지 않거나
- 신호를 적절하게 처리하지 않는 경우

=> chatgpt왈 이런 문제로 종료가 안되는거라고 답변이 왔다.

그래서 다음와 같은 방법을 나열해봤다.

1 - Docker 컨테이너 종료 명령 사용
2 - SIGINT 신호 전달
3 - Docker compose 사용(V)
4 - 직접 SIGINT 신호 보내기

이제 하나씩 방법을 알아보고 그중 적당히 간편한 것으로 방법을 찾고자 한다.

(1) Docker 컨테이너 종료 명령 사용

docker ps
docker stop {container_id}

(2) SIGINT 신호 전달

docker run 명령어로 실행할때 -it옵션으로 TTY를 할당하여 표준 입력이 연결됨
-> Ctrl+C신호를 전달하여 컨테이너 종료가 가능

(3) Docker compose 사용 - 채택

=> compose로 컨테이너를 관리시 더 쉽게 종료할 수 있음

ex) docker-compose.yml

version: '3'
services:
  socat:
    image: socat_test
    ports:
      - "38888:8888"

ex) docker 실행

실행 : docker-compose up -d
=> -d옵션 : 백그라운드으로 실행 
종료 : docker-compose down

(4) 직접 SIGINT 신호 보내기

docker kill --signal=SIGINT {container_id}

참고링크

(socat)

(1) https://minpeter.xyz/blog/use-socat-nc-ctf-challenge
(2) https://dhna.tistory.com/334
=> socat명령어와 관련된 옛날자료