Microsoft Windows/커널
덤프버전 :
상위 문서: Microsoft Windows 
1. 개요
2. 상세
3. 기술적 설명
3.1. 부팅/종료 과정
3.2. 부트로더
3.3. ntoskrnl.exe
3.3.1. 구성 요소
3.4. ntdll.dll
3.5. 핸들
3.6. PEB (Process Environment Block) / TEB (Thread Environment Block)
3.7. win32k.sys
3.8. System Idle Process (유휴 프로세스)
3.9. WOW64 (Windows 32-Bit on Windows 64-Bit)
3.10. x86-64 에뮬레이터
3.11. 커널 패치 보호 (Kernel Patch Protection)
3.12. smss.exe
3.13. 기본 탑재 드라이버
3.14. 서브시스템
3.15. services.exe
3.17. lsass.exe
3.18. conhost.exe
4. NT 커널 사용 운영체제
1. 개요[편집]
마이크로소프트에서 개발한 운영체제용 커널.
초창기 윈도우 및 일부 개인용 윈도우는 DOS 커널을 사용하므로 해당 문서 참조, 아래는 현용 NT 커널에 관한 내용만을 서술한다.
현재 안정화 버전은 10.0이고 개발중인 버전은 11.0이다.[1]
제작에 사용된 언어는 C언어이다. 하지만 2000년대 중반부터 드라이버 부분 같은 일부 소스코드는 C++로 제작되었다. 다만 C++은 문서에서 보이듯 태생적인 보안 이슈가 있었다. 그래서 2020년대부터 C++로 작성된 3만6천 라인의 소스코드 부분을 Rust로 재작성하는 중이다.#
2. 상세[편집]
위 사진은 Windows NT 계열 커널의 구조도이며, 혼합형 커널이다.
초창기 윈도우는 MS-DOS 위에서 작동하는 형태라 안정적이지 못했고 도스가 없으면 작동하지 않았다. 그래서 만든 도스에 의존하지 않는 커널을 사용하는 윈도우가 바로 Windows NT이다.
Windows NT는 본래 가정용이 아니라 기업 및 서버용으로 개발됐다. Windows 9x(Windows 95, 98, Me)는 DOS 기반이다. 하지만 DOS 기반 윈도우는 불안정하여 블루스크린 발생 빈도가 높았다.
가정용으로 개발된 Windows XP부터 NT 커널을 사용하기 시작했다. DOS 기반보다 나은 성능와 안정성으로 사용자들에게 큰 인기를 받으면서 Windows 11까지 사용하는 대중적인 커널이 됐다.
새로 설계한 커널이므로 DOS/9x 프로그램와의 호환성은 없다. 물론 호환성을 보장하기 위해 NTVDM(NT Virtual DOS Machine)와 WoW(Windows on Windows)가 있었으나 완전하지 않았으며 그마저도 64비트에서는 AMD64의 특성[2] 때문에 NTVDM와 WOW는 제거됐다. 64비트만 존재하는 Windows 11부터는 사실상 완전히 사라졌다.
일반 윈도우와 서버 윈도우, 게이밍 콘솔(엑스박스 시리즈) 윈도우, 모바일 윈도우의 커널은 차이가 없다. 서버 윈도우는 그냥 서버 관리를 위한 기능들이 추가됐을 뿐이고 각각의 다른 윈도우들도 쓸모없는 기능을 끄고 필요한 기능이 추가됐을 뿐이다.
다만 하드웨어 제약이 심한 구형 게이밍 콘솔 2종(엑스박스 1, 엑스박스 360)은 기존 NT 커널을 크게 축약시켰기 때문에 NT 커널 계열이지만 윈도우 커널이라고는 부를 수 없다고 한다. 이후 나온 엑스박스 원 부터는 이런 제약이 완화돼서 그냥 윈도우 커널이 통째로 들어간다.
3. 기술적 설명[편집]
3.1. 부팅/종료 과정[편집]
컴퓨터를 키면 BIOS/UEFI 과정을 거친 후 부팅 드라이브를 찾아 그 드라이브의 MBR/GPT 부트로더를 실행한다.
이후 MBR/GPT 부트로더는 시스템 폴더에 있는 winload.exe를 실행하고 winload.exe는 ntoskrnl.exe 파일을 실행한다. ntoskrnl.exe의 EP(Entry Point)는 KiSystemStartup 함수이다.
실행된 ntoskrnl.exe는 CPU를 초기화하고 HAL(Hardward Abstraction Layer, 하드웨어 추상화 레이어)와 여러 시스템(객체 관리자, I/O 관리자 등)을 초기화하고 윈도우 환경을 구성한다. 이후 사용자 모드에서 smss.exe 프로세스가 첫번째로 실행되고 나머지 부팅 작업을 한 뒤 로그온 화면을 띄운다.
시스템 종료를 하는 경우 커널 모드의 PopGracefulShutdown이 실행되는데, 중요 프로세스 외의 다른 프로세스를 종료시키고 HAL, 모든 핸들 닫기 등의 절차를 거친 뒤 하드웨어 종료 명령어를 실행한다. ATX(규격) 1.0 이상의 컴퓨터 파워부터는 APM이나 ACPI를 지원하여 운영체제의 통제를 받을 수 있으므로[3] 하드웨어 종료 명령어를 받은 컴퓨터는 자동으로 꺼진다.
이를 지원하지 않는 구형 파워(AT 규격)와 구형 NT 커널에서는 단순히 HDD 헤드 파킹만 하고 사용자가 직접 컴퓨터 전원을 내려야 꺼진다.[4]
3.2. 부트로더[편집]
윈도우의 부트로더는 NTLDR와 Windows Boot Manager가 있다. NTLDR는 Windows NT 3.1부터 Windows XP까지 사용하고 Windows Vista부터는 Windows Boot Manager를 사용한다.
NTLDR는 루트 디렉터리에 들어가 있으며 boot.ini 파일을 불려와서 부팅 메뉴를 구성한다. 또한 ntdetect.com 파일을 통해 하드웨어 정보를 가져온다. 사용자가 부팅 메뉴에서 부팅할 항목을 고르면 해당 항목에서 설정한 정보를 바탕으로 윈도우를 실행하고 ntdetect.com가 수집한 하드웨어 정보를 커널에 넘겨준다. Windows Boot Manager의 경우 boot.ini 대신 BCD를 사용한다.
Windows XP까지는 부트로더가 어떠한 이유로 꼬이면 NTLDR is missing라는 메시지를 볼 수 있다. Windows Vista부터는 bootmgr is missing 또는 "Windows failed to start." 라는 메시지가 나온다.
3.3. ntoskrnl.exe[편집]
ntoskrnl.exe은 윈도우의 커널 프로그램으로 윈도우 부팅 전부터 실행된다.[5] 파일 위치는 시스템 폴더에 있다.
커널 프로그램인 만큼 네이티브 API(Windows API)를 전혀 사용하지 않는다. ntoskrnl.exe의 프로세스 이름은 System이다. 커널 모드에서 실행되므로 관리자 권한으로도 종료시킬 수 없다.
ntoskrnl.exe 외에는 3개의 커널 이미지 파일이 있다. 그게 바로 ntkrnlmp.exe, ntkrnlpa.exe, ntkrpamp.exe으로 멀티 프로세서 사용 여부[6], PAE 지원 여부에 따라 결정된다. ntoskrnl.exe는 멀티 프로세서와 PAE를 전부 지원하지 않는다.
ntoskrnl.exe는 커널 그 자체이므로 이 파일이 손상되거나 없어지면, 말 그대로 윈도우 부팅이 불가능하다. 또한 ntoskrnl.exe에 디지털 서명이 되어 있으며, 윈도우 부팅 과정에서 ntoskrnl.exe를 비롯한 중요 시스템 파일의 디지털 서명을 검증하며 유효하지 않을 경우 윈도우 부팅 관리자는 0xc0000428[7] 오류를 표시하고 더 이상 부팅이 진행되지 않는다.
커널 패닉인 블루스크린도 커널에서 발생하며, 관련 커널 함수는
KeBugCheckKeBugCheckEx3.3.1. 구성 요소[편집]
ntoskrnl.exe는 다양한 서비스를 제공하는데 다음과 같다. 함수가 워낙 많다보니 맨 앞에 접두사를 붙여서 구분하고 있다. 아래에 있는 것들이 다는 아니고 더 있다!
- Cm - 윈도우 레지스트리를 관리한다. 콜백(CmRegisterCallbackEx) 등 일부 함수만 제외하면 나머지는 외부로 노출되지 않는다. 따라서 시스템 서비스 함수(Nt*, Zw*)를 통해 레지스트리에 접근해야 한다.
- Ke - 핵심 커널 서비스를 제공한다.
- Ki - 외부로 노출되지 않는 내부 커널 함수들이다. 커널 초기화, 시스템 콜 테이블 등이 이렇게 되어 있다.
- Ex - 익스큐티브
- Exp - 외부로 노출되지 않는 익스큐티브
- Io - I/O(입출력) 관리자, 장치 생성 / 제거, 장치 드라이버와 사용자 프로세스 간의 통신(IOCTL), 파일 시스템, 드라이버 로드 및 언로드[8] 등 다양한 입출력을 관리한다.
- Ob - 객체 관리자, 프로세스, 스레드 등의 객체를 만들거나 제거하며 각 객체마다 가지는 핸들 테이블을 관리하고 핸들을 생성하거나 핸들을 통해 객체에 간접적으로 접근할 수 있는 기능을 제공한다.
- Se - 보안 참조 모니터 (Security Reference Monitor), 윈도우에 생성되어 있는 각 객체의 DACL (임의 액세스 제어 목록)과 SACL (시스템 액세스 제어 목록)을 관리하며 접근 권한을 확인하여 거부하거나 승인할 수 있는 기능을 제공한다.
- Ps - 프로세스 및 스레드 관리자, 프로세스 또는 스레드를 생성하거나 종료하는 등 프로세스 / 스레드 관련 기능을 제공한다. 커널 및 드라이버는 시스템 스레드를 생성할 수 있다.
- Po - 전원 관리자
- Dbg - 커널 디버거
- Mm - 메모리 관리자, 페이징 파일, 가상 메모리 등을 관리한다.
- Nt - 시스템 서비스, ntdll.dll를 통해 사용자 모드로 노출되는 함수들이다. ntdll.dll의 시스템 서비스 함수가 호출되면 시스템 콜을 통해 커널 모드에서 실제 서비스 함수가 호출된다.
- Zw - 커널 모드 전용 시스템 서비스, Nt는 인수 검증을 수행하지만 Zw는 검증을 수행하지 않는다.[9]
3.4. ntdll.dll[편집]
Windows API의 모든 함수는 ntoskrnl.exe에서 구현되고 ntdll.dll라는 라이브러리 파일을 통해 사용자 모드에 노출된다. 일반 프로그램들은 사용자 모드에서 실행되므로 커널에 직접적으로 접근할 수 없다. 그래서 ntdll.dll의 시스템 콜로 커널에 요청하는 방법을 사용한다. 파일 생성/삭제 등의 변경, 프로세스 생성, 그래픽 출력, 네트워크 사용 등, 거의 모든 행위는 시스템 콜이 필요하다.
윈도우의 시스템 콜 과정은 시스템 콜 문서 참고.
ntdll.dll의 함수들은 문서화되어 있지 않다.[10] 즉 일반적인 방법으로는 사용할 수 없고 LoadLibrary와 GetProcAddress를 사용해서 ntdll.dll를 로드하고 함수의 주소를 가져와서 실행해야 한다. 아니면 ntdll.lib를 사용해서 ntdll.dll의 함수를 정의하여 사용하는 방법도 있는데, Windows SDK에는 없고 DDK(드라이버 개발 킷)에만 있으므로 DDK가 설치되어 있지 않았다면 설치하거나 인터넷에서 ntdll.lib를 다운로드 받아 사용해야 한다.
3.5. 핸들[편집]
프로세스는 윈도우 객체(프로세스, 스레드, 이벤트 등)에 직접 접근할 수 없다. 대신 핸들(Handle)을 통해 간접적으로 객체에 접근할 수 있다. 이 핸들들을 모아 관리하는 구조체는 핸들 테이블(Handle Table)이라 부른다. 객체마다 핸들 테이블을 가지고 있다. 핸들 테이블에는 핸들 번호와 객체의 실제 주소, 액세스 권한, 참조 횟수 등이 포함되어 있다.
프로세스가 OpenProcess 등으로 객체에 대한 핸들을 생성하고 핸들을 통해 윈도우 객체에 접근하려고 하면 윈도우는 해당 객체의 핸들 테이블을 참조하여 핸들이 있는지, 무슨 권한으로 접근하려는지 등을 체크하여 문제가 없을 경우 프로세스의 요구에 따라 객체를 다루게 된다.
Windows API의 객체를 다루는 함수들은 모두 핸들을 요구하고 있다. 그리고 함수마다 요구하는 권한이 다르다. 예를 들어 객체의 정보를 수정하는 함수(SetProcessInformation 등)들은 수정 권한을 요구하며 반대로 객체의 정보를 쿼리하는 함수(NtQueryProcessInformation 등)는 쿼리 권한이 필요하는 식이다. 윈도우는 핸들을 통해 객체에 접근하려는 권한이 해당 핸들이 가지고 있지 않다면 바로 액세스 거부를 때린다.
핸들을 더 이상 사용하지 않을 때에는 CloseHandle로 직접 핸들을 닫아줘야 한다. 그렇게 하지 않으면 핸들은 프로세스가 종료될 때까지 그대로 남겨지게 된다. 물론 프로세스가 종료되면 윈도우는 해당 프로세스의 열려 있는 핸들을 모두 닫아주긴 하다.
핸들 중에서 '의사 핸들'(Pseudo Handle)이라는 것도 존재한다. GetCurrentProcess이나 GetCurrentThread로 반환받은 핸들이 바로 의사 핸들이다. 의사 핸들은 해당 프로세스에서만 사용할 수 있으며 모든 액세스 권한을 가지고 있다. 의사 핸들은 CloseHandle로 닫을 수 없다.
3.6. PEB (Process Environment Block) / TEB (Thread Environment Block)[편집]
사용자 메모리에 존재하는 특정 객체의 정보(식별자 등)가 담긴 구조체다. PEB는 프로세스의 정보, TEB는 스레드의 정보가 담겨있는 구조체를 말한다.
일반적인 프로그램은 사용자 모드에서 실행되므로 커널 메모리에 직접적으로 접근할 수 없고 시스템 콜을 사용하는 간접적인 방법으로만 접근할 수 있다. 하지만 그렇게 되면 프로그램이 자신의 프로세스 ID만 가져오는 것도 시스템 콜을 사용해야 한다. 이런 식으로 시스템 콜이 반북적으로 호출되어 오버헤드가 발생하여 전체적으로 성능이 저하될 수 있다.
그래서 이를 해결하기 위해 나오게된 것이 바로 PEB이다. 커널 메모리에 있는 프로세스의 정보 중 일부를 사용자 메모리로 복사하여 프로세스가 시스템 콜 없이 즉시 프로세스의 정보를 가져올 수 있게 해준다. 이 개념은 스레드에도 존재하며 TEB라고 부른다.
커널 정보가 사용자 메모리의 특정 주소에 존재한다는 점 때문에 특정 방법을 사용하여 커널 정보를 유출시킬 수 있는 취약점이 발생하기도 했다. 그게 바로 CPU 게이트.
3.7. win32k.sys[편집]
ntoskrnl.exe에는 GUI이나 메시지 처리 기능이 없다. 이 기능들은 win32k.sys라는 별도의 커널 드라이버에서 제공한다. 이 파일 역시 시스템 폴더에 위치한다.
이 드라이버는 윈도우 부팅 시부터 실행하며 GDI, 윈도우(창), 메시지 처리 등을 관리한다. 역시 win32k.sys의 API도 시스템 콜로 구현되어 있다. 이들 함수는 NtGdi, NtUser 집두사가 붙어있고 gdi32.dll와 user32.dll에서 정의된다. 여기서 이 2개 DLL는 win32u.dll의 함수를 호출하게 되는데 win32u.dll는 win32k.sys의 시스템 콜을 실행하게 된다.
Windows 7까지는 win32k.sys 하나 뿐이었지만 Windows 8부터 4개의 드라이버 파일로 분할됐다. (win32k.sys, win32kbase.sys, win32kfull.sys, win32kns.sys)
3.8. System Idle Process (유휴 프로세스)[편집]
작업 관리자 등에서 보면 유독 CPU 점유율을 많이 먹는 'System Idle Process'라는 프로세스를 찾아 볼 수 있다.
이 프로세스는 파일로 존재하지 않으며 커널의 시작 단계에서 생성되는 프로세스이다. 그래서 PID가 0이다. 이 프로세스는 남은 CPU 사용량을 계산하고 있어 CPU 점유율이 높은 것이다. 물론 그렇다고 컴퓨터 성능에는 영향을 미치지 않는다. 만약에 한 프로세스가 CPU 사용량을 많이 차지하고 있으면 반대로 System Idle Process 프로세스의 CPU 점유율이 낮아진다.
그 외에 Windows 10에는 Memory Compression, Interrupts, Registry 프로세스가 있다. Windows 11부터에는 Secure System 프로세스도 생겼는데, 이는 가상 보안 모드(VSM)와 관련되어 있다. 이후 Windows 10도 업데이트로 생겨났다.
3.9. WOW64 (Windows 32-Bit on Windows 64-Bit)[편집]
WOW64는 64비트에서 있는 기능으로 32비트 윈도우 실행 파일 및 DLL 파일과 호환할 수 있도록 만들어진 에뮬레이트 기능이다.
64비트 버전에서 시스템 파일들이 있는 System32 폴더 외에 SysWOW64라는 폴더가 있는데 이게 바로 32비트 시스템 파일들이 들어있다.[11] 32비트 프로그램이 System32 폴더에 접근하려고 하면 실제로 SysWOW64 폴더로 접근하게 된다. 따라서 32비트 프로그램이 System32 (64비트) 폴더에 접근하고자 한다면 특정한 선언을 정의해야 한다.
WOW64 기능 관련 파일은 System32 폴더에 있는 wow64.dll, wow64cpu.dll, wow64win.dll이다. 32비트 프로그램이 실행될 때 이 세 파일이 로드되고 32비트 시스템 DLL들와 32비트와 64비트 ntdll.dll이 로딩된다. WOW64는 32비트 프로그램의 Windows API 호출을 가로채서 인자 등을 64비트에 맞게 변경한 뒤 64비트 함수로 호출한다.
따라서 32비트 프로그램은 64비트 프로그램와 동일하게 작동하지만 API 호출 단계가 추가됐기에 따라 성능 하락이 있을수도 있고 32비트의 한계로 최대 2GB의 메모리를 사용할 수 있다.
다만 라이브러리의 경우 DLL의 비트가 프로세스의 비트와 맞아야 한다. 예를 들어 64비트 프로세스에서 32비트 DLL 파일을 사용할 수 없다. 그 반대도 마찬가지로 32비트 프로세스에서 64비트 DLL를 사용할 수 없다. 따라서 64비트만 지원하는 프로그램이 아니면 32비트와 64비트용 DLL를 따로 두어야 한다.
그리고 드라이버는 WOW64가 적용되지 않으므로 반드시 비트에 맞게 로드해야 한다. 즉 32비트 드라이버를 64비트 윈도우에서 사용할 수 없다. 그 반대도 마찬가지다.
3.10. x86-64 에뮬레이터[편집]
Windows on ARM에서만 있는 에뮬레이터 기능.
ARM는 x86-64(AMD64)와는 구조가 완전히 다르기 때문에 x86-64로 컴파일된 프로그램을 ARM에서 사용할 수 없다. 그래서 이 기능은 x86 명령어를 ARM로 번역시키는 것으로 x86 프로그램을 실행할 수 있도록 해준다. x64는 특허 문제로 지원되지 않았다가 해결되어 Windows 11부터 x64 에뮬레이팅(ARM64EC)도 지원한다.
이 기능으로 ARM Windows에서 x86-64 프로그램을 사용할 수 있지만 ARM와 x86-64 성능 차이가 큰 편이라 WOW64보다 성능이 떨어진다.
3.11. 커널 패치 보호 (Kernel Patch Protection)[편집]
Windows XP Professional x64 Edition와 이를 기반으로 한 Windows Server 2003 x64[12]부터 적용된 보안 기능이다. 비공식적으로는 패치가드(PatchGuard)라고 부른다.
KPP는 커널 모드에서 동작하는 드라이버가 커널의 주요 부분을 수정하면 이를 감지하고 블루스크린을 일으킨다. 오류 코드는 CRITICAL_STRUCTURE_CORRUPTION(0x00000109)이다. KPP가 검사하는 대표적인 항목들은 다음과 같다.
- SSDT(시스템 서비스 서술자 테이블)
- IDT(인터럽트 서술자 테이블)
- GDT(전역 서술자 테이블)
- 커널 자신(ntoskrnl.exe) 또는 HAL(Hardward Abstraction Layer), win32k.sys 수정 등등...
위와 같이 KPP는 많은 검사를 수행한다. 즉 커널의 내부 코드는 전부 KPP의 보호에 들어간다고 보면 된다. 물론 드라이버도 커널 모드에서 작동하므로 KPP를 무력화시킬수도 있다. 하지만 마이크로소프트는 보안 패치를 통해 KPP 무력화나 우회 수단을 지속적으로 막는 중이다. 실제로 디어셈블리를 해보면 KPP의 기능이 매우 복잡하게 설계되어 있는 것을 볼 수 있다. 이는 KPP 분석을 어렵게 만드는 요인으로 작용하고 있다.
32비트 Windows에는 KPP가 없어서 드라이버가 커널의 내부 코드를 패치할 수 있었다. 하지만 Windows 11부터는 64비트만 지원되기에 사실상 KPP를 비활성화시킬 수 있는 방법은 사라졌다.
KPP로 인해 윈도우 64비트에서는 몇몇 기능을 사용할 수 없게 됐다. 대표적으로는 시스템 콜 후킹으로 안티 바이러스 제작사들은 시스템 콜 테이블을 수정하는 방법으로 실시간 감시 기능을 구현했었는데 KPP로 인해 불가능해졌다. 대신 마이크로소프트 DDK 문서에서 제공하는 콜백 API를 이용하여 실시간 감시를 구현하고 있다. (ObRegisterCallbacks)
3.12. smss.exe[편집]
smss.exe는 세션 관리자 하위 시스템(Session Manager Subsystem)으로 윈도우 시작 과정에서 제일 먼저 실행되는 프로그램이다.
초기 실행때부터 환경 변수를 생성하고 사용자 환경 및 GDI 기능을 담당하는 win32k.sys 드라이버를 로드하며 csrss.exe 등 다른 하위 시스템도 실행시킨다. 그리고 마지막으로 로그온 프로그램(LogonUI.exe)을 실행하여 윈도우 로그인 창을 띄우게 만든다.
3.13. 기본 탑재 드라이버[편집]
윈도우는 다른 운영체제와 마찬가지로 사용자가 직접 설치하는 서드파티 드라이버 외에는 기본적으로 탑재되어 있는 드라이버가 있으며 그 수가 많다. BIOS, UEFI 드라이버부터 USB, 시리얼 포트 등의 데이터 입출력 단자 드라이버, NTFS, FAT32 등의 파일 시스템 드라이버, TCP/IP, 소켓, TLS 등의 네트워크 드라이버, 그래픽 드라이버나 마우스, 키보드, 사운드카드 등의 휴먼 인터페이스 드라이버 등이 있다.
- tcpip.sys - TCP/IP 드라이버로 컴퓨터 IP 주소를 할당하고 다른 컴퓨터와 통신하는 역할을 한다. 참고로 블루스크린이 이 드라이버에서 발생하기도 하는데 오류코드가 IRQL_NOT_LESS_OR_EQUAL인 경우가 많다. 그럴 경우 파일 시스템 손상일수도 있으므로 DISM와 SFC를 이용하면 해결될 수 있다.
- http.sys - 이름에서 알 수 있듯이 HTTP 드라이버다.
- netio.sys - 네트워크 입출력을 담당하는 드라이버로 위의 tcpip.sys와 http.sys가 이 드라이버의 API를 사용한다.
- fltMgr.sys - 드라이버 중 한 종류인 미니필터 드라이버들을 관리하는 역할을 한다. I/O 관리자로 거치기 전 혹은 거친 후의 발생하는 미니필터를 설치하거나 제거하는 등의 미니필터 드라이버용 API를 제공한다.
- i8042prt.sys - PS/2 포트를 사용하는 키보드를 위한 드라이버. 이름의 유래는 AT 시절 인텔의 키보드 컨트롤러 8042 칩셋이다.
- ntfs.sys - NTFS 파일 시스템 드라이버로 NTFS 드라이브를 관리한다.
- vga.sys - 그래픽 드라이버가 설치되어 있지 않을 때 이 드라이버가 사용된다. 다만 Windows 8부터는 BasicDisplay.sys가 사용된다.
3.14. 서브시스템[편집]
서브시스템은 프로세스의 운영체제 API 호출을 관장하는 프로그램을 말한다. 사용자 모드에서 실행하면서 프로세스가 시스템 함수를 호출하면 서브시스템이 이를 커널에 요청(시스템 콜)하여 커널 모드에서 처리하도록 한 뒤 결과를 받아 해당 프로그램에 전달한다.
또한 서브시스템은 프로세스와 통신할 때 빠른 정보 송신을 위해 IPC 대신 LPC(Local Inter-Process Communication, 로컬 컴퓨터 프로세스간 통신)를 이용한다. LPC는 Windows API에서 문서화되지 않는 요소이며, 오직 커널에서만 사용할 수 있다.
Windows NT 시절에는 Win32 외에는 POSIX, OS/2 서브시스템도 있었으나[13] Windows XP부터 가정용으로 변모되면서 Win32 외의 서브시스템은 전부 사라졌다. 그래도 Windows Server 2003 R2부터 POSIX에 준하는 서브시스템(SUA, Subsystem for UNIX-based Applications)이 탑재됐으나 리눅스와의 호환성이 부족한데다 기본적으로 켜져있지 않는다.[14] 하지만 이마저도 Windows Server 2012 R2부터 탑재되지 않게되면서 윈도우의 서브시스템은 Win32만 남았었다.
Windows 10부터 리눅스 서브시스템으로 우분투를 탑재했다. 다만 기본적으로 탑재되지 않고 Microsoft Store에서 직접 설치해야 한다. 윈도우 11부터 리눅스 서브시스템에 안드로이드 운영체제가 추가됐다.
3.14.1. Native[편집]
특수한 서브시스템으로 윈도우 부팅 때 처음으로 먼저 진입하는 부분이기도 하다. ntoskrnl.exe, csrss.exe, smss.exe, 각종 드라이버 등이 Native 프로그램이다. Native 프로그램은 오직 ntdll.dll의 함수만(드라이버의 경우 ntoskrnl.exe의 함수나 기타 타 드라이버의 함수)을 사용하여 동작하도록 되어 있다.
윈도우 부팅 후에는 Win32 모드로 진입하기에 Native 프로그램을 실행할 수 없다. 실행하려고 하면 Win32 모드에서 실행할 수 없다는 메시지가 뜬다.
3.14.2. csrss.exe[편집]
Win32 서브시스템을 말하면 이 프로그램을 의미한다. Win32 프로세스와 LPC 통신하며 시스템 콜을 수행하며 Win32 프로세스 및 스레드 생성 및 삭제 등도 수행한다.
Windows Vista부터 csrss.exe는 두개로 실행된다.
csrss.exe는 실행 시부터 크리티컬 프로세스로 지정되기 때문에 강제로 종료시키면 블루스크린이 발생한다. 다만 '일시 정지'시키는 경우는 블루스크린이 발생하지 않은데 모든 csrss.exe를 일시정지시키면 커서만 움직이고 아무것도 못한다(...) 시작 메뉴도 열 수도 없는 등 완전히 기능이 마비되므로 강제 재부팅 외에는 방법이 없다.
3.15. services.exe[편집]
백그라운드에서 실행되는 드라이버와 서비스들을 관리하는 프로그램. Service Control Manager라고 부른다. 윈도우 부팅 중에 실행된다.
서비스 데이터베이스을 관리하며 서비스를 실행하거나 정지, 생성, 삭제 등을 수행한다. CreateService 등의 서비스 관련 함수들은 내부적으로 services.exe에 요청하고 결과 값을 받는다. 서비스 핸들(SC_HANDLE)도 관리하며 그래서 서비스 핸들을 닫으려면 CloseHandle가 아닌 CloseServiceHandle를 사용해야 한다.
커널 모드 드라이버 서비스의 경우 ntdll.dll의 함수들 중 하나인 NtLoadDriver를 호출하여 드라이버를 커널에 로드한다. 드라이버 서비스를 정지시킬 때는 NtUnloadDriver 함수를 사용하여 드라이버를 커널에서 해제시킨다.
3.16. svchost.exe[편집]
Win32 서비스들을 처리하는 프로그램으로 별도의 실행파일로 분리되지 않는 기능은 svchost.exe가 맡는다. 그러다보니 그 수가 많다. 모든 svchost.exe 프로세스들은 services.exe에 의해 관리된다.
자세한 내용은 해당 문서를 참조.
3.17. lsass.exe[편집]
lsass는 로컬 보안 인증 하위 시스템(Local Security Authority Subsystem Service)의 약자로 윈도우의 보안 시스템을 관리한다. 컴퓨터에 접속하려는 사용자의 인증을 검증하며 로그인 중인 사용자들을 관리한다. 윈도우 부팅 중에 실행된다.
윈도우 계정을 관리하는 프로세스다보니 lsass.exe의 메모리를 덤프해서 컴퓨터에 로그온 중인 계정의 정보를 빼내는 해킹 기법도 있다. 물론 MS도 이를 알고 있기에 일반적으로 방법으로 lsass.exe의 메모리를 덤프할 수 없다. lsass.exe의 핸들을 얻으려고 하면 바로 액세스 거부가 발생한다. 또한 덤프하더라도 덤프된 메모리 파일을 백신이 악성 코드로 판단하여 바로 삭제해버린다. 진단명은 대개 lsassDump가 들어가 있다.
3.18. conhost.exe[편집]
일반적인 콘솔 프로그램은 자체적으로 창을 가지고 있지 않는다. 그 대신 conhost.exe에게 I/O 통신 방식으로 화면 출력을 위임하여 창을 표시하는 구조로 되어 있다. 기본적으로 콘솔 프로그램에서만 실행된다. 창 프로그램이라면 창이 표시되지 않더라도 conhost.exe가 같이 실행되지 않는다.
conhost.exe는 자식 프로세스로써 부모 프로그램(콘솔 프로그램)에 붙여있기 때문에 conhost.exe를 종료하면 그 부모 프로세스도 함께 종료하게 된다.
Windows 7부터 존재하며 Vista까지는 csrss.exe가 담당한다. XP 및 비스타 베이직 테마에서 도스창이 고전 테마로 나오는 것도 이 때문이다.
4. NT 커널 사용 운영체제[편집]
- Microsoft Windows 중 Windows NT 네이밍을 달고 있는 버전[2000]과 Windows XP 이후의 모든 버전[15]
- Xbox 및 Xbox 360 시리즈의 자체 운영체제 (Xbox One부터 NT 기반 Windows를 사용한다)
이 문서의 내용 중 전체 또는 일부는 2023-10-31 02:25:08에 나무위키 Microsoft Windows/커널 문서에서 가져왔습니다.[1] 그래서 윈도우 11도 커널은 NT 10.0이다.[2] NTVDM와 WOW는 가상 8086를 사용하는데 AMD64의 롱 모드(64비트 모드)에서는 사용할 수 없다.[3] 최신규격 파워와 최신 버전 NT 커널로 갈수록 운영체제가 파워서플라이에 대한 권한이 강해진다. ATX 2.5 규격, NT 10.0 이상부터는 운영체제가 파워를 저전력 모드로 제어할 수도 있다.[4] 이때 등장하는 문구가 "이제 컴퓨터를 끄셔도 좋습니다.(It's now safe to turn off your computer.)"[5] 부트로더가 winload.exe를 실행하고 winload.exe는 ntoskrnl.exe를 로드한다.[6] 멀티코어가 아닌 CPU 2개 이상을 사용하는 것이 멀티 프로세서다. 보통 가정용에서는 사용하지 않으며 서버에서 대량의 데이터 처리를 위해 사용한다.[7] 파일에 대한 디지털 서명 검증할 수 없음[8] 즉 커널 모드 드라이버는 I/O 관리자에 의해 로드되고 언로드된다.[9] 참고로 Zw는 ntdll.dll (유저 모드)에서도 존재하지만 호출하면 Nt 함수로 호출된다.[10] ntdll.dll 함수들은 Windows.h에도 없다![11] System32는 오랫동안 쓰인 폴더다보니 무작정 바꿨다가 호환성 문제가 일어날 수 있다.[12] 사실 Windows XP 64비트 에디션은 Windows Server 2003 x64의 커널을 갖다 썼다. 그래서 커널 버전이 Windows Server 2003와 동일하게 나온 이유도 이것 때문이다.[13] Windows NT 4.0에서 확인해보면 POSIX 서브 시스템인 psxss.exe와 OS/2 서브시스템인 os2.exe(OS/2 클라이언트), os2srv.exe(OS/2 서버)를 시스템 폴더에서 찾을 수 있다.[14] Windows Vista와 7도 얼티밋 에디션 또는 엔터프라이즈 에디션일 경우 제어판에서 SUA를 활성화할 수 있다.[2000] Windows 2000도 NT 5.0이라 포함된다[15] 1.X, 2.X, 3.X는 MS-DOS 커널에 의존하고 있으며 Windows 95부터 MS-DOS를 부트로더 및 16비트 프로그램 호환성 계층으로 활용한다.