4.Advanced Debigging

고급 안티 디버깅(Advanced Anti-Debugging)

고급 안티 디버깅 기법

• 안티 디버깅은 우회가 모두 가능하다! 하지만 오랜 시간이 소요되며, 리버서를 지치게 만든다.

가비지 코드(Gabage Code)

• 의미 없는 코드를 대량으로 추가하는 기법
• jmp문을 통해 한줄로 쓸 수 있는 내용인데, jmp문 앞에 쓰레기 값들을 넣어서 많은 시간을 소요하게 된다.

Breaking Code Alignment

• OPcode에 있는 Instruction과 다른 해석을 이용한 기법

암호화(Encryption) / 복호화(Decruption)

• 프로그램의 코드와 데이터를 숨기기 위해 패커/프로텍터에서 자주 사용되는 기법
• Encoding : 정상적인 코드를 암호화 시키는 행위
• Decoging : 암호화된 코드를 복호화 시키는 행위

간단한 디코딩 코드의 경우

• loop안에 xor을 통해 복호화 과정을 갖는다.

복잡한 디코딩 코드의 경우

• 가비지 코드와 핵심코드(xor 복호화 루틴)를 섞는 방식

특수한 경우 - 코드 재조합

• 코드를 변경 시키는 기법으로, 사용자가 만약 디코딩되는 코드 위치에 software BP(0xcc)를 설치했을 때 실행 에러를 발생시킨다.

Stolen Bytes(Remove OEP)

• 원본 코드의 일부(주로 OEP 코드)를 패커/프로텍터가 생성한 메모리 영역으로 옮겨 실행시키는 기법
• 장점 : 프로세스 메모리를 정상적으로 덤프시켰을 때 OEP 코드의 일부분이 제거되었기 때문에 덤프된 파일은 정상적으로 실행되지 않는다.(Anti Dump기법)
• 장점 : Stolen Bytes가 적용된 파일을 다른 패커/프로텍터로 다시 압축했을 때 리버서에게 혼란을 줄 수 있다.(언팩 후 눈에 익숙한 OEP코드를 보여줌으로 계속 진행 해야하는지 혼란을 줌)
• ‘Remote OEP’옵션으로 ‘Protect’시키면 OEP근처로 갈 수 있다.

API 리다이렉션(Redirection)

• 디버깅할 때 코드에 흐름을 빨리 파악하는 방법 중 좋은 방법은 Win32 API에 bp를 걸어서 확인하는 것이다.

Debug Blocker(Self Debugging)

• 자기 자신을 디버깅 모드로 실행시키는 기법
• 장점
  1. 디버깅 방지 : 실제 원본 코드를 실행하는 자식 프로세스는 이미 디버깅 중이므로 원칙적으로 다른 디버거를 이용해서 Attach할 수 없다.
  2. 자식)(Debuggee)프로세스를 제어(Control)할 수 있다. : 디버거 - 디버기 관계에서 디버거는 막강한 권한을 가지고 있다. 즉, 디버기 프로세스의 예외를 처리하고 실행 흐름을 제어하는 등의 작업을 수행할 수 있다.

3.Dynamic_Debugging

Dynamic 안티 디버깅

• 프로그램의 코드를 트레이시아하지 못하도록 지속적으로 방해하는 기법이다. Static에 비해 난이도가 높으며 회피 방법 또한 어렵다.

Dynamic 안티 디버깅의 목적

• 내부 코드와 데이터를 리버싱으로부터 감추고 보호하는 것
• 보통 PE 프로텍터들에게 많이 사용되며, 핵심 알고리즘을 보호하기 위하여 사용된다.
• 디버거로 해당 프로그램이 실행될 수는 있을지언정 원본 프로그램의 핵심 코드(OEP)로 트레이싱하여 찾아갈 수 없도록 방해한다.

예외(Exception)

• 보통 예외가 발생하면 SEH(Structured Exception Handling)메커니즘에 의해 OS에서 예외를 받아서 프로세스에 득록된 SEH를 호출해준다. 그러나 디버기(Debuggee)에서 예외가 발생하면 디버거(Debugger)에서 예외처리를 담당한다. 바로 이러한 특징을 이용하여 정상 실행되는 경우와 디버깅 당하는 경우를 판별해서 서로 다른 동작을 수행할 수 있는 안티 디버깅 기법이다.

SEH(Structured Exception Handling)

• Windows OS의 예외
  • EXCEPTION DATATYPE MISALIGNMENT
  • EXCEPTION BREAKPOINT
  • EXCEPTION SINGLE STEP
  • EXCEPTION ACCESS VIOLATION
  • EXCEPTION IN PAGE ERROR
  • EXCEPTION ILLEGAL INSTRUCTION
  • EXCEPTION NONCONTINUABLE EXCEPTION
  • EXCEPTION INVALID DISPOSITION
  • EXCEPTION ARRAY BOUNDS EXCEEDED
  • EXCEPTION FLT DENORMAL OPERAND
  • EXCEPTION FLT DIVIDE BY ZERO
  • EXCEPTION FLT INEXACT RESULT
  • EXCEPTION FLT INVALUD OPERATION
  • EXCEPTION FLT STACK CHECK
  • EXCEPTION FLT UNDERFLOW
  • EXCEPTION INT DIVIDE BY ZERO
  • EXCEPTION INT OVERFLOW
  • EXCEPTION PRIV INSTUCTION
  • EXCEPTION STACK OVERFLOW

EXCEPTION BREAKPOINT

• BreakPoint 명령어를 이용하여 예외를 발생시키면 일반 실행인 경우 등록된 SEH가 자동 실행되겠지만, 디버깅 실행의 경우 즉시 실행이 멈춰지고 제어권은 디버거로 넘어온다.
• 디버깅 중이라도 관련 예외를 OS에게 넘겨 SEH가 자동 실행되도록 만들 수 있다.
  • 예외 처리기 내부에서 static 안티 디버깅 기법을 적절히 사용한다면 디버깅 여부를 쉽게 판별이 가능해 진다.
  • 예외 처리기 내부에 EIP값이 어떻게 변경될지 모른다.
• 곧 디버깅을 계속 진행하기 위에 결국 예외처리기를 따라 들어가야한다
• 회피방법 : Ollydbg옵션 수정하면 해결 가능하다.
  • Debugging options -> Exceptions(tab) -> INT3 breaks(check!)

SetUnhandledExceptionFilter()

• kernel32!UnhandledExceptionFilter() API의 내부에서 static 안티 디버깅 기법인 ntdll!NtQueryInformationProcess(ProcessDebugPort) API를 호출하여 프로세스의 디버깅 여부를 판별한다.
• 디버깅 중이라면 예외를 디버거에게 넘겨주며, Kernel32!SetUnhandledExceptionFilter() API를 이용하면 시스템의 마지막예외 처리기(Top Level Exception Filter)를 변경시킬 수 있다.
• 회피방법 : static & Dynamic을 혼합한 기법으로, 먼저 Static 기법인 Kernel32!UnhandledExceptionFilter()내부에서 호출되는 ntdll!NtQueryInfomationProcess() API를(API 후킹 등의 방법으로)무력화한다.
  그 후 SetUnhandledExceptionFilter() API 호출에 의해 등록된 Exception Filter를 따라가서 정상 실행인 경우 어느 주소로 분기하는지 확인하면 된다.

Timing Check

• 트레이싱하는 경우 시간이 걸릴 수 바께 없다는 점을 이용한 안티 디버깅 기법.

시간 간격 측정 방법

• Counter based method
  • RDTSC(cpu의 카운터(counter)를 이용)
    kernel32!QueryPerformanceCounter()/ntdll!NtQueryPerformanceCounter()
    kernel32!GerTickCount()
  • Time based method(실제 시간이용한 방법)
    timeGerTime()
    ftime()

RDTSC(Read Time Stamp counter)

• EDX:EAX 형식으로 읽어오는 어셈블리 명령어
• 회피방법
  1. 트레이싱을 하지 말고 RUN으로 해당 코드를 넘어간다.
  2. 두 번째 RDTSC 결과 값(EDX:EAX)을 조작한다.
     첫 번째 결과 값과 비슷하도록 조작하면 cmp문을 통과할 수 있다.
  3. 조건 분기 명령어(cmp/jcc)실행을 조작한다.
     Jcc멸령어는 CF(Carry Flag)또는 ZF(Zero Flag)의 영향을 받는다.
  4. 커널 드라비어를 이용하여 RDTSC 명령을 무력화시킬 수 있다.
     Plugin 중에 있으니까 알아보자.

Trap Flag

• Trap Flag(TF)는 EFLAGS 레지스터의 9번째(index 8) 비트이다.

Single Step

• TF 값을 1로 세팅하면 CPU는 single step 모드로 변경된다. 변경 후 CPU는 Single Step 모드에서 하나의 명령어를 실행시킨 후 EXCEPTION SINGLE STEP 예외를 발생시킨다. 이후 Trap Flag는 자동으로 치기화(0)이 된다.
• EXCEPTION SINGLE STEP예외는 SEH 결합하여 디버거를 탐지하기 위한 안티 디버깅 기법에 사용된다.
• 회피방법 : Ollydbg옵션을 통해 가능.
  Debugging options -> Exceptions(tab) -> Single step break(check)

INT 2D

• 커널모드에서 작동하는 Break Point 예외를 발생시키는 명령어.
• 유저모드에서도 예외를 발생시킨다.(디버깅 실행의 경우네는 예외를 방생시키지 않는다)
• 특징
  1. 1바이트 무시
     Obfuscated Code 효과를 보여줌(Obfuscated Code : Code Byte Ordering을 변경해서 프로그램의 코드를 혼란스럽게 만드는 것)
  2. BP까지 그대로 실행 ( Ollydbg경우, 디버거 마다 다르다,)
• 회피방법 : 코드패치

0xCC 탐지(Detection)

• BP(Break Point)의 x86 Instuction은 0xCC 이다.
  • 0xCC는 Opcode로 사용될 수도 있지만, Displacement, Immediate, 데이터 주소 등으로 사용될 수도 있다.

API Break Point

• API에 설치된 BP를 확인해서 현재 디버깅을 당하는지 판단하는 방법
• 일반적으로 API코드 시작 부분에 BP를 설치하므로 첫 바이트가 CC인지 검사해서 디버깅 중이라고 판단할 수 있다.
• Serach for -> Name in all modules를 사용하여 All names 다이얼로 간단히 BP를 설치할 수 있다.
• 회피방법 : API에 BP를 설치할 때 되도록 코드의 첫바이트를 피해서 중간쯤에 설치한다. 또는 Hardware BP를 설치하는 것도 하나의 방법이다.

Checksum 비교

• 회피방법 : CRC계산 영역에 BP를 걸지 않거나 패치를 하지 않으면 Checksum anti debugging을 무력화 시킬 수 있다.
  • 가장 좋은 방법 : CRC 비교 구문을 패치하는 것,

2.Static_Debugging

Static anti debugging

Static 안티 디버깅

Static 안티 디버깅의 목적

• 디버깅 당하는지 여부 파악하는 기법으로, 만약 디버깅 중이라고 판단되면 일반 실행과는 다른 코드(주로 종료 코드)를 실행하는 것이 핵심.

PEB

• 디버깅 여부 판단하기 위해 PEB(Process Enviroment Block)구조체 정보를 이용할 수 있다.
• 가장 널리 사용되는 안티 디버깅 기법이다.
• window xp sp3의 peb 구조체에서 안티디버깅 기법에 사용되는 멤버
  • +0x002 BeingDebugged : UChar : 디버깅 여부를 표시하는 Flag로 사용
  • +0x00c Ldr : Ptr32 PEB LDR DATA : Heap 메모리 특성과 관련
  • +0x018 ProcessHeap : Ptr32 Void : Heap 메모리 특성과 관련
  • +0x068 NtglobalFlah : Uint4B : Heap 메모리 특성과 관련
• 참고
  • PEB 주소 구하는 방법 : MOV EAX, DWORD PTR FS:[0x30] ;FS[0x30] = address of PEB
  • TEB(Thread Environment Block)을 구하고 ProcessEnvironmentBlock 멤버(+0x30 옵셋)를 이용하는 방법)
    • MOV EAX, DWORD PTR FS:[0x18] ;FS[0x18] = addressof TEB
    • MOV EAX, DWORD PTR DS:[EAX+0x30] ; DS[EAX+0x30]=address of PEB

BeingDebugged(+0x2)

• PEB.BeingDebugged 멤버(+0x2)의 값은 디버깅 중일 때 1(True)로 세팅되고, 일반 실행인 경우 0(False)으로 세팅

IsDebuggerPresent()

• 회피 방법 : OllyDbg의 Edit 명령을 이용하여 PEB.BeingDebugged 값을 0(False)으로 변경하면 된다.

Ldr (+0xC)

• 디버깅 프로세스는 힙(heap)메모리 영역에 자신이 디버깅 당하는 프로세스라는 표시를 한다.
• 메모리에 사용되지 않는 영역에 0xfeeefeee 값으로 채워 버린다. (프로세스가 디버깅을 당할 때 나타아는 흔적)
• PEB.Ldr 멤버는 PEB LDR DATA 구조체를 가리키는 포인터이다. PEB LDR DATA 구조체는 힙 메모리 영역에 생성되기 때문에 이 영역을 scan해보면 쉽게 알 수 있다.
• 회피방법 : 0xfeeefeee로 채워진 영역을 NULL로 덮어쓰면 된다. 0xfeeefeee영역에 메뉴 ‘Binary - Fill with 00’s’를 누르면 0으로 채워진다.

Process Heap(+0x18)

• HEAP 구조체를 가리키는 포인터

  GetProcessHeap()

• IsDebuggerPresent()와 비슷하다. TEB -> PEB -> PEB.Processheap 순서
• 회피방법 : Heap.Flags = 2, Heap.ForceFlags = 0으로 세팅하면 된다.

NtGlobalFlag(+0x68)

• 디버깅 중일 때 PEB.NtGlobalFlag 멤버(+0x68)의 값은 0x70으로 세팅된다.
• 회피방법 : PEB.NtglobalFlag = 0으로 세팅하면 된다.

_

NtQueryInformationProcess()

• ntdll!NtQueryInfomationProcess() API를 이용하면 프로세스의 디버깅 관련 정보를 비롯하여 다양한 정보를 얻을 수 있다.
• 구조체 변수 중 디버거 탐지에 사용되는 것 : PROCESSINFOCLASS ProcessInformationClass 변수에서 ProcessDebugPort(0x7),ProcessDebugObjecthandle(0x1E), ProcessDebugFlags(0x1F)
• 회피방법 : 특정입력(ProcessInfomationClass)값들에 대하여 출력(리턴 - Process Infomation) 값을 조작하는 것.
  • 특정입력 : ProcessDebugPort(0x7), ProcessDebugObjectHandle(0x1E), ProcessDebugFlags(0x1F)
  • API가 한두 번 정도 호출되는 거라면 디버거에서 수동으로 조작을 하고, 반복적으로 호출된다면 API 후킹을 시켜버리면 된다.
  • 보통 plugin(Advanced)를 이용하여 자동으로 API를 후킹한다.
    • jmp를 통한 후킹은 보통 함수 시작부분에 넣는다.
    • PE프로텍트의 API 후킹 탐지 기법이 있으면, 뒤에 하는게 좋다.
      • NtQueryInfomationProcess() API시작 주소의 첫 바이트를 읽어서 후킹 여부를 확인한다.

ProcessDebugPort(0x7)

• 디버깅 중이 아니면, dwDebugPort 변수에 0이 세팅된다.
• 디버깅 중이라면 0xffffffff 이 세팅 된다.

CheckRemoteDebuggerPresent()

• IsDebuggerPresent() API와 비슷하게 디버깅 여부를 판별해 주는 함수
• 차이 : CheckRemoteDebuggerPresent()는 다를 프로세스의 디버깅 여부까지 판단할 수 있다.
• 내부 코드를 보면 NtQueryInfomationProcess(ProcessDebugPort) API를 이용한다.

ProcessDebugObjectHandle(0x1E)

• 프로세스가 디버깅 중이면 Debug Object Handle은 값이 존재하며, 디버깅 중이 아니라면 Debug Object Handle은 NULL이 된다.

ProcessDebugFlags(0x1F)

• ProcessDebugFlags(0x1F)를 입력하여 Debug flag를 구하며, 값이 0이면 디버깅 상태이고, 1이면 디버깅이 아니다.

NtQuerySystemInfomation()

• 현재 OS가 Debug mode로 부팅되었는지를 판단하는 안티 디버깅 기법이다.
  • Debug mode는 windbg를 이용한 커널 디버깅하는 경우를 의미한다.

SystemKernelDebuggerInfomation(0x23)

회피방법 : windows xp 의 경우 boot.ini를 편집하고 ‘/debugport=com1 /baudrate=115200 /Debug’ 값을 제거한다. windows 7 인 경우 cmd에서 ‘bcdedit /debug off’ 명령을 내리면 된다. 그리고 재부팅하면, 일반모드(normal mode)로 부팅된다.

NtQueryObject()

• 시스템에서 어떤 디버거가 다른 프로세스를 디버깅 중이라면 그 때 DebugObject 타입의 커널 객체가 생성되는데, 그 DebugObject의 존재를 확인하는 것이다.
• NtQueryObject() API는 시스템의 다양한 종류의 커널 객체 정보를 구해오는 함수이다.

ZwSetInfomationThread()

• 디버깅 당하는 쪽(디버기)에서 강제로 디버거를 떼어내는(Detech) 기법에 대한 설명이다. ZwSetInformationThread() API를 사용하면 자신을 디버깅하고 있는 디버거를 떼어낼 수 있다.
• 스레드에게 정보를 세팅하는 System Native API입니다.
• 회피방법 : ZwSetInfomationThread() API가 호출되기 직전에 스택에 저장된 두 번째 파라미터 ThreadInfomationClass 값을 살펴보고 ThreadHideFromDebugger(0x11) 값이 입력된 경우라면 0으로 변경해주면 된다.
  ZWSetInformationThread() API를 후킹하여 같은 방식으로 파라미터를 조작하면 된다.

TLS 콜백 함수

• Entry Point 코드보다 먼저 실행되는 특징 때문에 안티 디버깅에 많이 활용된다.TLS 콜백 함수 내에서 IsDebuggingPresent() 등의 함수로 간단히 디버깅 여부를 판별하여 프로그램을 계속 실행할지 말지 결정할 수 있다.

1.Anti_Debugging

안티디버깅

안티디버깅 기술을 알아야 하는 이유

1. 각종 안티 디버깅 기법들의 동작 원리를 파악한 후 회피하기 위해
2. 안티 디버깅 기법을 공부하는 과정에서 저절로 고급 리버싱을 배울 수 있기 때문에

안티 디버깅 기법

안티 안티 디버깅 기법

• Anti-Anti-Debugging기법 : 안티 디버깅을 위한 덫을 피하는 방법
• 안티안티디버깅은 너무 길어서, ‘해제기법’ , ‘회피기법’이라는 용어를 사용한다.

  안티 디버깅 분류

• Static 기법 , Dynamic 기법 두가지로 분류

  • Static : 디버깅 시작할 때 한번만 해제를 해주면 해결되는 기법.
  • Dynamic : 디버깅을 진행하면서(해당 Anti기법을)만날 때마다 해결하는 기법

    	static	Dynamic
    난이도	Low, Medium	High
    구현원리	다양한 시스템 정보 활용	디버거의 동작 원리를 역이용
    목적	디버거 탐지	내부 코드와 데이터를 숨김
    해체 시점	디버깅 시작할 때	디버깅 도중
    해체 획수	1회	수시
    해체 방법	API Hooking, Debugger Plugin	API Hooking, Debugger Plugin, Utilities

• 대표적 기법(static)

  • PEB
    • BeingDebugged(IsDebuggerPresent())
    • Ldr
    • Heap(Flag,Force Flags)
    • NtGlobalFlag
  • TEB
    • StaticUnicodeString
  • Using Native API
    • NtQueryInfomationProcess()
      • ProcessDebugPort(0x7)
      • (CheckRemoteDebuggerPresent())
      • ProcessDebugPbjectHandel(0x1E)
      • ProcessDebugFlag(0x1F)
    • NtQuerySystemInfomation()
      • SystemKernelDebuggerInfomation(0x23)
  • Attack Debugger
    • Detatch Debugger
      • NtSetInfomationThread()
        • ThreadHideFromDebugger(0x11)
    • BlockInput()
  • OpenProcess
    • SetDebugPrvilege
  • TLS Callback Function
  • Using Normal API
    • Parent Process
    • Window Name
    • Process Name
    • File Name
    • Register
    • Resource
    • String in Process Vitual Memory
    • Kernel Mode Driver
    • System Environmnet
  • Targeting
    • OutputDebugString()
    • Memory Break Point()
    • Filename Format String
    • ESI Value
    • (Guard Page - Memory Break Point)

• 대표적 기법(Dynamic)

  • Using SEH
    • Exceptions
      • CloseHandle()
    • Break Ponits
      • INT3(CC)
      • INT 3(CD 03)
      • INT1(F1)
      • INT 2D(CD 2D)
  • Timing Check
    • RDTSC
    • QueryPerfomanceCount()
    • GetTickCount()
    • timeGetTime()
      • ftime()
  • Single Step
    • Trap Flag
      • PUSHFD/POPFD
      • INT 2D
  • Patching Detection
    • 0xCC Scanning
    • Calc Checksum (Hash)
  • Stack Segment Register
  • Anti-Disassembly
  • PE Image Switching
  • Self-Execution
  • Debug Blocker(Self-Debugging)
  • Nanomite
  • Obfuscated Code
  • Code Permutation
  • Encryption/Decryption
  • Stolen Bytes
  • API Redirection
  • Guard Page
  • Virtual Machine(자체구현)

    Static 안티 디버깅

• 디버거에 올리면 재대로 실행(Run)되지 않는다. 적용된 static기법을 해제하면, 그제서야 디버거에서도 제대로 실행 가능하다.

Dynamic 안티 디버깅

• 프로그램의 동작 원리를 이해하려면 디버거에서 트레싱(Tracing)하여 원본 프로그램의 코드와 데이터를 확인해야 한다. 문제는 Dynamic 기법이 트레이싱을 방해하여 원본 프로그램의 코드와 데이터를 확인할 수 없게 만드는 것이다.

->Trace는 한줄한줄 디버깅 하는 것을 의미

쉘코드로 점프하는 방법

쉘코드를 실행시키거나 점프할 수 있는 몇 가지 다른 방법에 대해 다루고, 또한 버퍼의 크기가 작을 때 적용할 수 있는 최선책에 대해 알아보자

쉘코드를 실행시킬 수 있는 몇가지 방법

1. JMP or  CALL
• 공격자는 쉘코드의 주소를 가진 레지스터를 기본적으로 사용하며, 그 주소를 IP에 넣어 공격을 하게 된다. 그렇기 때문에 공격자는 애플리케이션이 실행될 떄 로딩되는 DLL들 중 하나의 레지스터로 점프 하거나 Call 하는 기계어를 찾아야 한다. 또한 특정 메모리 주소로 EIP를 덮어쓰는 대신 특정 레지스터로 점프하는 주소를 EIP에 주입할 필요가 있다
2. pop/return
• 만약 스택의 꼭대기에 있는 값이 공격자가 생성한 버퍼 내에 있는 주소를 가리키지 않지만, 쉘코드를 가리키는 주소가 스택 안에 존재하는 것을 본다면, pop/ret 또는 pop/pop/ret(해당 명령이 스택의 어느 위치에 존재하느냐에 따라 pop의 개수가 달라진다.)와 같은 명령을 EIP로 주입함으로써 쉘코드를 로드할 수 있께 된다.
3. PUSH return
4. JMP [reg+offset]
5. blind return
6. 만약 공격자가 이용할 수 있는 버퍼 용량이
7. SEH

리눅스 kernel _리눅스 커널 내부구조

리눅스 커널 내부구조 _ 2010년도에 나온 책인데 찬찬히 정리하면서 포스팅 해볼까 한다! 그럼 항상 처음 부분만 단단하듯이 목차에 1번!! 리눅스에 대한 간략한 소개 부터 차근차근 읽어 보자!




하 역사다 그냥...계속 다 뒤에서 자세히 설명한다고한다.. 걍 2장부터 봐야겠다..

( 아 난 리눅스에서도 Ubuntu에서 할 생각이다.. 또는 MAC이랑 같이 하면서 비교를 해볼까?! 오호 비교를 하면서 공부를 해야겠다!! 히히)



리눅스에 장점

• 사용자 임의대로 재구성이 가능하다
• 열악한 환경에서도 H/W 자원을 적헐히 활용하여 동작한다.
• 커널의 크기가 작다
• 완벽한 멀티 유저, 멀티 테스킹 시스템
• 뛰어난 안정성
• 빠른 업그레이드
• 강력한 네트워크 지원
• 풍부한 소프트웨어
• 사용자를 위한 여러 가지 공개 문서들

shell 사용해보기

shell을 통해 리눅스와 대화를 하며, shell은 명령어를 해석해주는 해석기라고 정의하면 된다. 

옆에 있는 화면은 terminal이라는 shell을 이용하여 리눅스와 대화를 하는 대화창이라고 생각하면 쉽다.

사용법은 , 공부를 하면서 자연스럽게 익숙해 질거다.. 물론 나도..
(일단 ls , cp , mv , rm , vi , gcc , ps 정도는 뭔지 맛보고 해보자!)







2. 리눅스 커널 구조

커널 : 운영체제의 핵심을 이루는 부분 , cpu나 메모리 그리고 기타 디바이스등의 시스템 리소스를 등의 시스템 리소스를 관리하고,  사용자 프로그램이 이를 사용할 수 있도록 한다.





운영체제 : 자원을 관리해주는 자원관리자(resouce manager)
자원 : 물리적 자원(pysical resource) . 추상적 자원(abstract resource)

물리적 자원 : cpu , 메모리 , 디스크, 터미널, 네트워크 등

추상적 자원 : (물리적 자원을 운영체제가 관리하기 위해 추상화 시킨 객체)
- cpu를 추상화 시킨 task
- 메로리를 추상화 시킨 세그먼트 , 페이지
- 디스크를 추상화 한 파일
- 네트워크를 추상화 시킨 통신 프로토콜 , 패킷  등

usr/src/kernel

본인은 리눅스에서 Ubuntu를 이요하는 중이다.

usr/src에는 여러가지 디렉토리가 있었다. 이건 추후에 어떤건지 알게 될거 같아 일단 패스 하자!





arch 디렉토리(architecture에 arch를 땀)
 - 하드웨어 종속적인 부분들이 구현된 디렉토리

fs 디렉토리
- 리눅스에서 지원하는 다양한 파일시스템과 open(), read(), write() 등의 시스템 호출이 구현된 디렉토리,

mm 디렉토리
- 메모리 관리자가 구현된 디렉토리이다.물리 메모리 관리 , 가상 메모리 관리 , 태스크마다 할당되는 메모리 객체 관리 등의 기능이 구현되어 있다.

driver 디렉토리
- 리눅스에서 지원하는 디바이스 드라이버가 구현된 디렉토리이다.

net 디렉토리
- 리눅스 커널 소스 중 상당히 많은 양을 차지하는 이 디렉토리는 리눅스를 지원하는 통신 프로토콜이 구현된 디렉토리 이다.

ipc 디렉토리
- 리눅스 커널이 지원하는 프로세스간 통신 기능이 구현된 디렉토리이다.


init 디렉토리
- 커널초기화 부분, 즉 커널의 메인 시작 함수가 구현된 디렉토리

include 디렉토리
- 리눅스 커널이 사용하는 해더 파일들이 구현된 디렉토리이다.

other 디렉토리
 - 리눅스 커널의 주요기능이 구현된 디렉토리 외에도 리눅스 커널 소스에는 여러 다른 디렉토리가 존재하며, 대표적으로 리눅스 커널 및 명령어들에 대한 자세한 문서 파일들이 존재하는 Documentation 디렉토리, 커널 라이브러리 함수들이 구현된 lib 디렉토리 , 등등





리눅스 커널 컴파일
리눅스는 윈도우와는 다르게 vista -> 7 으로 올릴 경우 새로 설치하는 것과는 다르게 커널은 컴파일 하고 재부팅하는 것만으로도 업데이트가 가능하다.