커널 격리는 지능형 공격에 대해 추가 보호 계층을 제공하는 가상화 기반 보안 기술입니다. 메모리 무결성은 매우 안전한 프로세스에 악성 코드가 삽입되는 것을 방지하도록 설계된 기능인 커널 격리 기술의 일부입니다. 무결성 검사를 성공적으로 통과한 후에만 커널 가상 메모리 페이지가 실행되기 시작한다는 사실로 인해 보호가 제공됩니다.
Windows 10 2018년 4월 업데이트에서 메모리 무결성 기능을 활성화하여 컴퓨터 보안을 강화하는 방법을 살펴보겠습니다.
메모리 무결성 활성화
- Windows Defender 보안 센터를 엽니다.
- "장치 보안"섹션을 선택하십시오.
- "커널 격리" 섹션에서 "커널 격리 세부 정보" 링크를 클릭합니다.
- "메모리 무결성" 스위치를 활성 위치로 이동합니다.
이 단계를 완료한 후 변경 사항을 적용하려면 컴퓨터를 다시 시작해야 합니다.
메모: 이 기능이 작동하려면 프로세서가 가상화 기술을 지원해야 합니다. 또한 BIOS 또는 UEFI에서 가상화를 활성화해야 합니다. 그렇지 않으면 해당 기능을 사용할 수 없습니다.
커널 격리 문제 해결
경우에 따라 커널 격리가 활성화된 경우 일부 응용 프로그램에서 호환성 문제가 발생할 수 있습니다. 문제를 해결하려면 해당 기능을 비활성화해야 합니다.
Windows Defender 보안 센터에서 메모리 무결성을 비활성화하려고 했지만 옵션이 회색으로 표시되고 "이 설정은 관리자가 제어합니다"라는 메시지가 표시되는 경우에도 레지스트리를 사용하여 기능을 비활성화할 수 있습니다.
메모: 레지스트리를 잘못 변경하면 심각한 문제가 발생할 수 있습니다. 이 단계를 수행하기 전에 Windows 레지스트리를 백업하는 것이 좋습니다. 레지스트리 편집기 메뉴에서 파일 > 내보내기를 선택하여 백업을 저장합니다.
- Windows 키 조합 + R을 눌러 실행 창을 엽니다.
- regedit를 입력하고 확인을 클릭하여 레지스트리 편집기를 시작합니다.
- 다음 경로로 이동하세요.
- 항목을 두 번 클릭하세요. 활성화됨.
- 값을 1에서 0으로 변경합니다.
- 확인을 클릭하세요.
비활성화하려면 기성품을 사용할 수도 있습니다.
전원 관리자는 시스템 전체의 에너지 사용량을 감시합니다. 역사적으로 전원 관리는 모니터를 끄고 디스크 드라이브의 회전을 중지하는 것으로 구성되었습니다. 그러나 이 문제는 랩톱의 배터리 수명 연장에 대한 요구, 항상 켜져 있는 데스크톱 컴퓨터의 에너지 절약 고려 사항, 서버 팜에서 소비하는 높은 전력 비용으로 인해 점점 더 복잡해지고 있습니다.
새로운 전원 관리 기능에는 개별 장치를 중복 상태로 전환하거나 완전히 꺼서(전원 스위치를 사용하여) 시스템을 사용하지 않을 때 구성 요소 전력 소비를 줄이는 것이 포함됩니다. 다중 프로세서 시스템은 필요하지 않은 개별 프로세서를 비활성화하고 프로세서의 클럭 속도를 줄여 전력 소비를 줄일 수도 있습니다. 프로세서가 유휴 상태일 때 인터럽트가 발생할 때까지 기다리는 것 외에는 아무 것도 할 필요가 없기 때문에 전력 소비도 줄어듭니다.
Windows는 최대 절전 모드라는 특수 종료 모드를 지원합니다. 이 모드는 모든 물리적 메모리를 디스크에 복사한 다음 배터리 소모를 최소화하면서 전력 소비를 최소로 줄입니다(노트북은 최대 절전 모드에서 몇 주 동안 실행 가능). 전체 메모리 상태가 디스크에 기록되므로 노트북의 배터리를 교체할 수도 있습니다(최대 절전 모드에 있는 동안). 시스템이 최대 절전 모드에서 다시 시작되면 저장된 메모리 상태를 복원하고 장치를 다시 초기화합니다. 이렇게 하면 컴퓨터가 최대 절전 모드 이전과 동일한 상태가 됩니다(실행 중이던 모든 응용 프로그램과 서비스를 다시 등록하고 시작할 필요가 없습니다. Windows는 수정되지 않은 페이지(디스크에 백업된 페이지)를 무시하여 이 프로세스를 최적화하려고 시도합니다). 나머지 메모리 페이지를 압축하여 필요한 I/O 볼륨을 줄입니다. 최대 절전 모드 알고리즘은 시스템 I/O와 프로세서 대역폭의 균형을 자동으로 조정하여 시스템 I/O 대역폭의 필요성을 줄이면서 동시에 데이터 압축이 더 효율적입니다. I/O 대역폭을 사용하면 최대 절전 모드로 들어갈 때 압축을 피할 수 있습니다. 최신 세대의 멀티프로세서에서는 시스템에 대용량 RAM이 있어도 최대 절전 모드로 들어가고 나가는 데 몇 초밖에 걸리지 않습니다.
최대 절전 모드의 대안은 전원 관리자가 전체 시스템을 더 낮은 전력 소비 상태(동적 메모리 상태를 재생성하는 데 충분한 에너지만 사용)로 전환하는 대기 모드입니다. 메모리를 디스크에 복사할 필요가 없기 때문에 이 상태로 들어가는 것이 일부 시스템에서는 최대 절전 모드보다 빠릅니다.
최대 절전 모드 및 대기 상태가 가능함에도 불구하고 많은 사용자는 작업을 마친 후 개인용 컴퓨터를 끄는 습관을 없애지 못했습니다.
최대 절전 모드는 Windows에서 HiberBoot라는 의사 시작 종료를 수행하는 데 사용됩니다. 이는 일반적인 종료 및 시작보다 훨씬 빠릅니다. 사용자가 시스템을 종료하라고 명령하면 HiberBoot는 사용자를 시스템에서 로그아웃한 다음 시스템이 정상적으로 다시 로그인될 수 있는 지점에서 시스템을 최대 절전 모드로 전환합니다. 나중에 사용자가 시스템을 다시 켜면 HiberBoot는 사용자의 로그인 지점에서 시스템을 다시 시작합니다. 사용자에게는 대부분의 시스템 초기화 단계를 건너뛰기 때문에 이 모든 것이 매우 빠른 종료처럼 느껴집니다. 물론 문제를 해결하거나 커널 업데이트를 설치하기 위해 실제로 시스템을 종료해야 하는 경우도 있습니다. 시스템이 종료되지 않고 다시 시작하라는 명령을 받으면 시스템은 실제 종료를 견디고 정상적인 부팅을 수행합니다.
휴대폰과 태블릿의 컴퓨팅 장치는 물론 차세대 노트북도 항상 소량의 전력을 소비할 것으로 예상됩니다. 이 모드를 제공하기 위해 최신 Windows에서는 CS(연결 대기)라는 특수 버전의 전원 관리를 구현합니다. CS는 CPU를 실행하는 것보다 훨씬 적은 전력을 사용하여 소규모 연결 집합의 트래픽을 모니터링할 수 있는 전용 네트워크 연결 하드웨어가 있는 시스템에서 가능합니다. CS 시스템은 항상 켜져 있고, 사용자가 화면을 켜자마자 CS가 즉시 종료되는 것으로 나타났습니다. 연결 모드 절전은 CS 시스템이 모니터링되는 연결에서 패킷을 수신할 때 깨어난다는 점에서 일반 절전 모드와 다릅니다. 배터리가 부족해지기 시작하면 CS 시스템은 배터리가 완전히 소모되고 사용자 데이터가 손실될 가능성을 방지하기 위해 최대 절전 모드로 전환됩니다.
배터리 수명을 늘리려면 프로세서를 최대한 자주 끄는 것 이상이 필요합니다. 가능한 한 오랫동안 프로세서를 꺼두는 것도 중요합니다. CS 시스템의 네트워킹 하드웨어를 사용하면 데이터가 도착할 때까지 프로세서를 꺼진 상태로 유지할 수 있지만 다른 이벤트로 인해 프로세서가 다시 켜질 수도 있습니다. NT 기반 Windows 장치 드라이버, 시스템 서비스 및 응용 프로그램 자체는 사물의 상태를 확인하기 위해 특별한 이유 없이 시작되는 경우가 많습니다. 이 폴링 활동은 일반적으로 시스템 또는 애플리케이션에서 코드를 주기적으로 실행하도록 타이머 설정을 기반으로 합니다. 타이머 신호를 기반으로 한 폴링은 프로세서 관련 이벤트를 혼란스럽게 할 수 있습니다. 이를 방지하기 위해 최신 Windows에서는 운영 체제가 타이머 이벤트를 집계하고 프로세서에 대한 별도의 트리거 시간 수를 줄일 수 있도록 오류 한계를 지정하는 타이머가 필요합니다. Windows는 또한 활발하게 실행되고 있지 않은 응용 프로그램이 백그라운드에서 코드를 실행할 수 있는 조건을 정의합니다. 업데이트 확인, 콘텐츠 새로 고침 등의 작업은 타이머가 만료된 후 실행하라는 메시지가 표시되는 경우에만 수행할 수 없습니다. 애플리케이션은 이러한 백그라운드 활동과 관련하여 운영 체제를 따라야 합니다. 예를 들어, 업데이트 확인은 하루에 한 번 또는 다음 번에 기기의 배터리가 충전될 때만 이루어져야 합니다. 시스템 프록시 세트는 백그라운드 활동을 제한하는 데 사용할 수 있는 다양한 조건을 제공합니다. 백그라운드 작업에 저렴한 네트워크 액세스 또는 사용자 권한이 필요한 경우 프록시는 필요한 조건이 존재할 때까지 작업을 실행하지 않습니다.
오늘날 많은 애플리케이션은 로컬 코드와 클라우드에 있는 서비스를 모두 사용하여 구현됩니다. Windows는 타사 서버의 패킷을 특별히 수신 대기하기 위해 CS 네트워크 하드웨어를 요구하지 않고도 타사 서비스가 CS의 Windows 장치에 알림을 푸시할 수 있도록 하는 WNS(Windows 알림 서비스)를 제공합니다. WNS 알림은 문자 메시지 또는 VoIP 통화 도착과 같이 시간이 중요한 이벤트에 대해 경고할 수 있습니다. WNS 패킷이 도착하면 이를 처리하기 위해 프로세서를 켜야 하지만 CS 네트워킹 하드웨어에는 여러 연결의 트래픽을 구별하는 기능이 있습니다. 즉, 프로세서가 모든 무작위 패킷에 응답하여 켜지지 않아도 됩니다. 네트워크 인터페이스에서 옵니다.
커널 모드 드라이버: 1부: 기본 개념 - 아카이브 WASM.RU
아키텍처 개요
Windows 2000의 내부 세계는 주소 공간 측면과 해당 주소 공간에서 실행되는 코드의 권한 및 책임 측면에서 경계가 명확하게 정의된 두 부분으로 나뉩니다.
주소 공간 분할을 사용하면 모든 것이 놀라울 정도로 간단합니다. 32비트 아키텍처에서 사용할 수 있는 4GB는 모두 두 개의 동일한 부분으로 나뉩니다(4GT RAM 튜닝 및 물리적 주소 확장은 특이하므로 생략합니다). 아래쪽 절반은 사용자 모드 프로세스 전용이고, 위쪽 절반은 커널에 속합니다.
권리와 책임의 구분은 좀 더 복잡합니다.
다음 프로세스는 사용자 프로세스로 간주됩니다.
- 시스템 지원 프로세스 - 예: Winlogon 로그온 프로세스(\%SystemRoot%\System32\Winlogon.exe에서 구현됨)
- 서비스 프로세스(예: 인쇄 스풀러)
- 사용자 응용 프로그램 - Win32, Windows 3.1, MS-DOS, POSIX 및 OS/2의 다섯 가지 유형이 있습니다.
- 환경 하위 시스템 - Win32(\%SystemRoot%\System32\Csrss.exe에서 구현), POSIX(\%SystemRoot%\System32\Psxss.exe에서 구현), OS/2(\%SystemRoot에서 구현)의 세 가지 환경 하위 시스템이 지원됩니다. %\System32\os2ss.exe).
핵심은 다음 구성 요소로 구성됩니다.
실행 시스템 - 메모리 관리, 프로세스 및 스레드 등
- 커널 - 스레드 예약, 중단 및 예외 처리 등(\%SystemRoot%\System32\Ntoskrnl.exe에서 구현됨)
- 장치 드라이버 - 하드웨어 장치 드라이버, 네트워크 드라이버, 파일 시스템 드라이버;
- HAL(하드웨어 추상화 계층) - 하드웨어 아키텍처 간의 차이점으로부터 위의 세 가지 구성 요소를 분리합니다(\%SystemRoot%\System32\Hal.dll에서 구현됨).
- 윈도우화 및 그래픽 시스템 - 그래픽 사용자 인터페이스(GUI) 기능(\%SystemRoot%\System32\Win32k.sys에서 구현됨)
쌀. 1-1. Windows 2000 아키텍처의 단순화된 다이어그램
사용자 모드와 커널 모드
Intel x86 프로세서 제품군은 네 가지 권한 수준(보호 링이라고 함)을 지원하지만 Windows에서는 커널 모드에 0, 사용자 모드에 3이라는 두 가지 권한만 사용합니다. 이는 두 가지 수준의 권한만 구현되는 다른 프로세서(alpha, mips)의 지원 때문입니다. Windows NT의 이전 릴리스에서는 이러한 아키텍처를 지원했지만 Windows 2000은 x86 전용으로 남아 있었습니다.
사용자 모드 구성 요소에는 고유한 보호된 주소 공간이 있습니다. 이러한 프로세스의 스레드는 권한이 없는 프로세서 모드(사용자 모드라고 함)에서 실행되고 권한이 있는 프로세서 명령을 실행할 수 없으며 시스템 데이터 및 시스템 주소 공간에 대한 제한적이고 간접적인 액세스를 가지며 직접 액세스할 수 없습니다. 하드웨어에 대한 액세스. 사실, 작업 중에 시스템 서비스를 호출하는 이러한 프로세스의 스레드는 커널 모드로 전환되지만 이 경우 사용자 모드로 돌아갈 때까지 실행에 대한 제어권을 완전히 잃습니다.
사용자 모드 프로세스는 시스템 안정성 관점에서 볼 때 잠재적으로 위험한 것으로 간주됩니다. 그들의 권리는 제한되어 있습니다. 그리고 이러한 제한을 넘어서려는 모든 시도는 가혹하게 억압됩니다.
커널 구성요소는 단일 주소 공간을 공유하고, 권한 있는 프로세서 모드(커널 모드라고 함)에서 실행하고, 권한 있는 명령을 포함한 모든 프로세서 명령어를 실행할 수 있으며, 시스템 데이터 및 코드에 제한 없이 직접 액세스할 수 있고, 직접 또는 HAL을 통해 다음에 대한 액세스 권한을 갖습니다. 장비.
커널 코드(사실 이는 시스템 자체)는 완전히 신뢰할 수 있는 것으로 간주됩니다. 따라서 일단 시스템 주소 공간에 로드되면 드라이버는 시스템의 일부가 되며 어떠한 제한도 받지 않습니다.
따라서 사용자 응용 프로그램은 운영 체제 자체와 분리됩니다. 시스템의 내부 기능이나 데이터 구조에 액세스해야 하는 심각한 애플리케이션을 작성하려고 하면 코드를 시스템 주소 공간에 배치해야만 극복할 수 있는 많은 제한 사항에 직면하게 됩니다. 문서화된 방법은 장치 드라이버를 설치하는 것뿐입니다. 이 방법은 상대적으로 간단하고 안정적이며 가장 중요한 것은 운영 체제 자체에서 완벽하게 지원된다는 것입니다.
윈도우 2000 드라이버
Windows 2000은 다양한 유형의 장치 드라이버를 지원합니다.
대표자를 갖는 두 가지 기본 사항이 있습니다.
- 사용자 모드 드라이버:
- VDD(가상 장치 드라이버) - MS-DOS 프로그램을 지원하는 데 사용됩니다(Windows 95/98의 VxD 드라이버와 혼동하지 마십시오. 이름은 같지만 완전히 다릅니다).
- 프린터 드라이버.
- 커널 모드 드라이버:
- 파일 시스템 드라이버 - 로컬 및 네트워크 드라이브에 I/O를 구현합니다.
- 레거시 드라이버 - 이전 버전의 Windows NT용으로 작성되었습니다.
- 비디오 어댑터 드라이버(비디오 드라이버) - 그래픽 작업을 구현합니다.
- 스트리밍 드라이버 - 비디오 및 오디오 입력/출력을 구현합니다.
- WDM 드라이버(Windows 드라이버 모델, WDM) - 플러그 앤 플레이 기술과 전원 관리를 지원합니다. 이들의 특징은 Windows 98, Windows ME 및 Windows 2000 간의 소스 코드 수준 호환성입니다.
여러 소스에서 위에 제공된 분류와 약간 다른 분류를 접할 수 있지만 이는 중요하지 않습니다. 중요한 것은 우리가 작성할 드라이버가 이 분류의 어떤 항목에도 속하지 않는다는 것입니다. 이는 파일 시스템 드라이버, 레거시 드라이버, 비디오 어댑터, 사운드 카드 드라이버, WDM 드라이버가 아닙니다. Plag"n"Play 및 전원 관리를 지원하지 않습니다. 이것은 사용자 모드 드라이버가 아닙니다(전혀 흥미롭지 않습니다). 사실, 악마는 그것이 무엇인지 알고 있을 뿐입니다. 왜냐하면... 시스템 자체를 사용하면 알 수 없는 장치에 대한 코드를 쉽고 간단하게 추가하고 원하는 작업을 수행할 수 있습니다! 그것은 마치 전혀 모르는 사람이 밤에 당신의 집 문을 두드렸을 때, 당신이 아무 말도 없이 그를 하룻밤 동안 들여보내고 심지어 그를 당신의 침대에 눕히는 것과 같습니다! 그러나 이는 일종의 버그나 보안 허점이 아닙니다. 시스템은 원래대로 작동합니다. 그렇지 않을 수는 없으니까... 환경과 상호 작용하면서 시스템은 강제로 자체 액세스를 제공해야 합니다. 그렇지 않다면 완전히 폐쇄된 시스템이 되어 쓸모가 없는 시스템이 될 것입니다.
이름 자체에서 알 수 있듯이 장치 드라이버는 일부 장치를 제어하도록 설계된 프로그램이며 이 장치가 반드시 물리적일 필요는 없습니다. 이는 논리적일 수도 있고 우리의 경우처럼 가상일 수도 있습니다.
구조상 장치 드라이버는 PE 형식 파일(Portable Executable, PE)에 지나지 않습니다. 일반 exe, dll과 동일합니다. 단지 다른 규칙에 따라 로드되고 작동합니다. 드라이버는 사용자 모드에서 수행할 수 없는 작업을 수행하도록 설계된 커널 모드 DLL로 생각할 수 있습니다. 여기서 근본적인 차이점(권한 수준을 계산하지 않음)은 드라이버나 코드나 데이터에 직접 액세스할 수 없지만 입력/출력 관리자가 제공하는 특수 메커니즘을 사용한다는 것입니다. I/O 관리자는 드라이버가 작동할 수 있는 환경을 제공하고 드라이버 로드, 언로드 및 관리를 위한 메커니즘도 제공합니다.
커널 모드 드라이버 개발을 시작하면 완전한 초보자처럼 느껴질 것입니다. API를 사용한 이전의 모든 경험은 여기서는 도움이 되지 않습니다. 커널은 완전히 다른 기능 세트를 제공합니다. 또한 제대로 문서화되지 않았거나(헤더 파일에만 정의됨) 완전히 문서화되지 않은 함수 및 데이터 구조를 사용해야 합니다.
단일 및 다중 레벨 드라이버
물리적 장치를 제어하는 대부분의 드라이버는 계층화된 드라이버입니다. I/O 요청 처리는 여러 드라이버에서 공유됩니다. 모두가 자신의 역할을 수행합니다. 예를 들어, 파일 읽기 요청은 파일 시스템 드라이버로 전송되며, 이는 일부 작업(예: 요청을 여러 부분으로 분할)을 수행한 후 이를 디스크 드라이버로 "다운스트림"으로 전달합니다. 버스 운전사에게 요청을 보냅니다. 또한 이러한 드라이버 사이에 필터 드라이버(예: 데이터 암호화)를 원하는 만큼 추가할 수 있습니다. 요청을 실행한 후 하위 수준 드라이버는 해당 결과를 상위 수준 드라이버에 "위로" 전달합니다. 그러나 다행스럽게도 모든 것이 훨씬 더 간단해질 것입니다. 우리 드라이버는 항상 모놀리식 드라이버이므로 작성 및 디버깅의 전체 프로세스가 크게 단순화됩니다.
스레드 컨텍스트
대부분의 경우 프로세서가 하나 뿐이고 실행해야 할 응용 프로그램이 많기 때문에 동시 실행이라는 환상을 만들기 위해서는 이러한 응용 프로그램을 프로세서에 순차적으로 연결해야 하며 매우 빠르게. 이 절차를 스레드 컨텍스트 전환이라고 합니다. 시스템이 동일한 프로세스에 속한 스레드의 컨텍스트를 전환하는 경우 연결이 끊긴 스레드의 프로세서 레지스터 값을 저장하고 연결된 스레드의 프로세서 레지스터에서 이전에 저장된 값을 로드해야 합니다. 그리고 일부 데이터 구조를 업데이트하세요. 연결된 스레드가 다른 프로세스에 속해 있으면 프로세스의 페이지 디렉터리에 대한 포인터를 프로세서의 CR3 레지스터에 로드해야 합니다. 각 사용자 프로세스에는 닫힌 주소 공간이 제공되므로 프로세스마다 주소 공간의 예측이 다르므로 프로세서가 가상 주소를 물리적 주소로 변환하는 페이지 디렉터리와 페이지 테이블 세트가 다릅니다. 이 모든 것은 드라이버 프로그래밍과 직접적인 관련이 없습니다. 그러나 나는 이것과 관련하여 이것을 상기시켜줍니다. 컨텍스트 전환은 가장 빠른 작업이 아니기 때문에 드라이버는 성능 향상을 위해 일반적으로 자체 스레드를 생성하지 않습니다. 그러나 드라이버 코드는 여전히 실행되어야 합니다. 따라서 컨텍스트 전환 시간을 절약하기 위해 드라이버는 다음 세 가지 컨텍스트 중 하나에서 커널 모드로 실행됩니다.
- I/O 요청을 시작한 사용자 스레드의 컨텍스트에서;
- 커널 모드 시스템 스레드의 컨텍스트에서(이 스레드는 시스템 프로세스에 속함)
- 중단의 결과로 발생합니다(따라서 중단 당시 실행 중이던 프로세스나 스레드의 컨텍스트에서는 발생하지 않음).
"프로세스나 스레드의 맥락이 아닌" 이 글을 작성한 사람들(D. Solomon 및 M. Russinovich)의 권위와 우리가 그렇게 하지 않는다는 사실을 고려할 때 어떻게 작업을 수행할 수 있는지 잘 모르겠습니다. 이건 필요없어 왜냐하면 . 우리는 소프트웨어, 특히 하드웨어 인터럽트를 처리하지 않을 것이며 세 번째 경우는 즉시 잊어버릴 수 있습니다. 처음 두 가지 옵션이 남아 있습니다. I/O 요청이 시작되면 우리는 이 요청을 시작한 스레드의 컨텍스트에 있으므로 이 스레드가 속한 프로세스의 주소 공간에 직접 액세스할 수 있습니다. 시스템 스레드의 컨텍스트에 있는 경우 사용자 프로세스에 직접 액세스할 수 없지만 항상 시스템 스레드에 액세스할 수 있습니다. 드라이버에서 일부 프로세스가 이러한 주소에 있는 것을 확인해야 하는 경우 컨텍스트를 직접 전환하거나 페이지 테이블을 사용하여 주소를 변환해야 합니다.
인터럽트 요청 수준
중단은 모든 운영 체제에서 필수적인 부분입니다. 인터럽트에는 처리가 필요하므로 현재 코드의 실행이 중지되고 제어가 인터럽트 핸들러로 전달됩니다. 하드웨어 인터럽트와 소프트웨어 인터럽트가 모두 있습니다. 인터럽트는 우선순위에 따라 서비스됩니다. Windows 2000은 IRQL(인터럽트 요청 수준)이라는 인터럽트 우선 순위 체계를 사용합니다. 우선순위가 가장 낮은 0(수동)부터 우선순위가 가장 높은 31(높음)까지 총 32개 레벨이 있습니다. 또한 IRQL=0(수동)에서 IRQL=2(DPC\dispatch)까지의 인터럽트는 소프트웨어이고, IRQL=3(장치 1)부터 IRQL=31(높음)까지의 인터럽트는 하드웨어입니다. 인터럽트 우선 순위 수준과 스레드 우선 순위 수준을 혼동하지 마십시오. 완전히 다른 것입니다. 엄밀히 말하면 IRQL=0 수준의 인터럽트는 인터럽트가 아닙니다. 이는 어떤 코드의 작업도 중단할 수 없습니다(결국 이를 수행하려면 이 코드를 훨씬 더 낮은 인터럽트 수준에서 실행해야 하지만 그러한 수준은 없습니다). 사용자 모드 스레드는 이 IRQL에서 실행됩니다. 그리고 우리의 드라이버 코드도 이 IRQL에서 실행됩니다. 이는 드라이버 코드가 항상 "수동" 수준에서 실행된다는 의미는 아닙니다. 단지 우리는 소프트웨어나 특히 하드웨어 인터럽트를 처리하지 않을 것입니다. 그리고 이것으로부터 적어도 두 가지 매우 중요한 결론이 도출됩니다.
첫째: 드라이버의 작업은 더 높은 우선순위의 인터럽트를 처리하기 위해 언제든지 중단될 수 있습니다. 나머지). 따라서 이러한 의미에서 우리 드라이버의 코드는 모든 사용자 스레드의 코드와 마찬가지로 중단 가능하고 선점 가능합니다(프로세서는 다른 스레드에 제공됨). 현재 인터럽트 수준을 확인하고 이를 높이거나 낮출 수 있는 커널 함수가 있습니다.
두 번째 중요한 점: 수동 인터럽트 수준에서는 모든 커널 함수를 호출할 수 있으며(DDK에서는 각 함수에 대한 설명이 호출할 수 있는 인터럽트 수준을 나타내야 함) 스왑 파일에 플러시된 메모리 페이지에 액세스할 수도 있습니다. 더 높은 인터럽트 수준(DPC/dispath 이상)에서 물리적 메모리에 없는 페이지에 액세스하려고 하면 시스템 충돌이 발생합니다. 메모리 관리자가 페이지 부재를 처리할 수 없습니다.
"죽음의 블루스크린"
누구나 한번쯤은 '죽음의 블루스크린'(BSOD)이라는 흥미진진한 그림을 본 적이 있을 것입니다. 그것이 무엇인지, 왜 발생하는지 설명할 필요가 없을 것입니다. 여기서 중요한 것은 커널 모드 드라이버 개발을 시작할 때 BSOD가 모니터 화면에 자주 나타날 것이라는 사실에 대비해야 한다는 것입니다.
세 번째 링에서는 모든 것이 간단했습니다. 대략적인 코드를 스케치하고 필요한 곳에 int3을 배치하고 실행한 다음... 디버거에서 무엇이 무엇인지 이미 이해했습니다. 뭔가 잘못된 경우 코드가 제대로 작동할 때까지 수정하고, 오류를 수정하고, 다시 컴파일하는 등의 작업을 수행했습니다. 드라이버를 프로그래밍할 때 이 기술을 잊어버릴 수 있습니다. 여기서 "공병"은 한 번 실수를 합니다. 한 번만 잘못 움직이면... 잠시 편안히 앉아 휴식을 취하실 수 있습니다.
BSOD를 가능한 한 드물게 보려면 "7번 측정 - 한 번 자르기"... "7번 확인 - 한 번 실행"이라는 의미에서 매우 간단한 규칙을 준수해야 합니다. 물론 이것은 말하기는 쉽지만 실행하기는 훨씬 더 어렵습니다. 그러나 일반적으로 (이 기사를 읽은 후) 작성할 드라이버의 구조가 상대적으로 간단하다는 점을 고려하면 BSOD가 나타나기 전에 오류를 처리할 수 있습니다. 문제가 지속적으로 눈앞에 나타나고 이유를 이해할 수 없는 경우 상황을 명확히 할 수 있는 방법은 크래시 덤프를 분석하는 것입니다. Mark Russinovich의 "크래시 메모리 덤프 분석"(http://www.osp.ru/win2000/2001/03/025.htm)의 기사에서 그것이 무엇인지, 어떻게 만들고 분석하는지 읽을 수 있습니다. 이 문제(분석)가 굉장히 어려운데 그렇게까지는 안 될 것 같아요.
나는 끔찍한 이론가이므로 위의 모든 내용을 이해하는 데 절대적으로 필요한 원리에 대한 매우 기본적인 정보로 간주할 수 있습니다. 스레드 컨텍스트, 인터럽트 수준 및 스레드 우선 순위, 커널/사용자 모드 등을 이해하지 않고는 커널 모드 드라이버 개발을 시작할 수 없습니다. 등등. 어떤 문제에 대해 확신이 없다면 참조 목록은 아래에 있습니다.
이제 좀 더 실용적인 것(다음 기사에서 매우 실용적이 될 것입니다), 즉 이 모든 이론을 실제로 적용하는 데 필요한 사항을 다루겠습니다.
드라이버 개발 키트
첫 번째는 물론 Microsoft 웹사이트에서 무료로 다운로드할 수 있는 장치 드라이버 개발 키트(Windows 2000 드라이버 개발 키트, 2KDDK)입니다(어쨌든 저는 여기에서 완전히 무료로 다운로드했습니다: http:// www.microsoft.com/ddk/). 이 패키지에는 장치 드라이버에서 사용하는 내부 데이터 구조 및 시스템 전체 기능에 대한 풍부한 정보 소스인 문서가 포함되어 있습니다.
문서화 외에도 DDK에는 링크할 때 반드시 필요한 라이브러리 파일 세트(*.lib)가 포함되어 있습니다. DDK에는 다음과 같은 두 가지 파일 세트가 포함되어 있습니다. Windows 최종 버전(무료 빌드라고 함)용; 개발용(체크 빌드라고 함). 이러한 파일은 각각 %ddk%\libfre\i386 및 %ddk%\libchk\i386 디렉터리에 있습니다. 디버그 버전에는 더 엄격한 오류 검사 기능이 있습니다. 시스템 버전에 해당하는 파일을 \masm32\lib\w2k 디렉터리에 배치하여 사용해야 합니다.
포함된 파일
함수 프로토타입 정의가 포함된 포함(*.inc) 파일도 필요합니다. 우리(더 정확하게는 나)도 스스로 해야 할 것이다. 나는 *.lib -> *.inc를 변환하는 다양한 유틸리티를 사용해 보았습니다. 두 유틸리티 모두 허치 패키지의 masm32에 포함되어 있고 인터넷의 광대한 범위에서 서로 다른 시간에 유출된 유틸리티도 있었습니다. 내가 가지고 있는 모든 것 중에서 f0dder의 protoize.exe만이 작업에 대처했으며 실제로는 아무것도 직접 편집할 필요가 없었습니다. 이 훌륭한 도구는 \tools\protoize 디렉터리에 있습니다. 저자 웹사이트: http://f0dder.didjitalyphrozen.com/. 하지만 거기에서는 찾을 수 없습니다. f0dder는 http://board.win32asmcommunity.net/ 컨퍼런스에서 이 유틸리티를 여러 번 게시했습니다. 포함은 \include\w2k 디렉토리에 위치합니다. 이는 \masm32\include\w2k 디렉토리에 위치해야 합니다. 변환을 위해 우리는 Windows 2000의 무료 릴리스에 대해 *.lib를 사용했습니다. 왜냐하면 이것이 제가 갖고 있는 버전이기 때문입니다(아마 여러분도 마찬가지일 것입니다).
다음 문제는 더 심각하다. 이는 필요한 구조, 기호 상수 및 매크로 정의가 포함된 포함 파일이 거의 없다는 것입니다. 인터넷에서 유용한 것을 찾을 수 없을 것 같습니다. 이것은 너무 이색적인 활동입니다. 어셈블러에서 커널 모드 드라이버를 작성하는 것입니다. 일부는 EliCZ http://www.anticracking.sk/EliCZ/에서 찾을 수 있습니다. Y0da http://mitglied.lycos.de/yoda2k/index.htm의 내용(부분적으로는 그에 의해 만들어졌고 부분적으로는 동일한 EliCZ에서 가져옴) 그러나 이것은 매우 형편없게 수행되었습니다(슬로바키아와 독일 동료들에 대한 깊은 존경심을 가지고): 많은 구조의 멤버 이름은 DDK의 원본 헤더 파일에 정의된 이름과 다릅니다. 중첩된 구조와 공용체에는 이름이 없습니다. 원본에서는 이름이 지정되어 있습니다. 그리고 일반적으로 모든 것이 다소 혼란스럽고 보면 우울한 인상을줍니다. ntstatus.inc만 잘 완료되었습니다. 이는 부분적으로 EliCZ가 DDK 없이도 포함을 생성하기 시작했기 때문입니다(그 자신이 말했듯이). 어쨌든, 적어도 주의 깊게 테스트하지 않고는 사용하지 말 것을 권합니다. 한때 http://board.win32asmcommunity.net/ 컨퍼런스에서 뭔가가 번쩍였지만 품질도 특별히 인상적이지는 않았습니다. 간단히 말해서, 이 상황에서 유일한 올바른 해결책은 모든 것을 직접 수동으로 수행하는 것입니다. 왜냐하면 저는 이 프로세스를 자동화할 수 있는 도구를 모르기 때문입니다. 갑자기 가치 있는 일을 발견했는데 별 문제가 아니라고 생각된다면 알려주세요.
드라이버 디버깅
디버거도 필요하고, 커널 모드 코드를 디버깅해야 하므로 적절한 디버거가 필요합니다. 최선의 선택은 SoftICE가 될 것입니다. 또는 DDK에 포함된 커널 디버거를 사용할 수 있습니다. 이 디버거에는 마스터와 슬레이브라는 두 대의 컴퓨터가 필요하지만 모든 사람이 감당할 수는 없습니다. Mark Russinovich(http://www.sysinternals.com/)는 LiveKd라는 유틸리티를 작성했는데, 이를 통해 두 번째 컴퓨터를 연결하지 않고도 커널 디버거를 사용할 수 있습니다. 웹사이트에 있는지는 모르겠지만(확인하지 않음) 책 "Microsoft Windows 2000의 내부 장치" 디스크에 있습니다. 이 디버거는 또한 Microsoft 웹 사이트에서 무료로 다운로드할 수 있는 디버깅 기호가 설치되어 있는 경우 시스템 내부를 검사하는 데 매우 유용합니다.
David Solomon, Mark Russinovich, "Microsoft Windows 2000의 내부", ed. "피터", 2001. 이 책에는 소스 코드가 한 줄도 포함되어 있지 않지만 주로 프로그래머를 위한 것입니다.
Sven Schreiber, "Windows 2000의 문서화되지 않은 기능", ed. "피터", 2002. Windows 2000의 많은 비밀을 밝혀주는 순전히 실용적인 책입니다.
Walter Oney, "Microsoft 드라이버 모델 프로그래밍", Microsoft Press, 1999 이 책에서는 Plag"n"Play 드라이버에 중점을 두고 있지만 이것이 그 장점을 결코 감소시키지는 않습니다. 드라이버 개발의 기본 원칙은 보편적입니다.
Jeffrey Richter, "전문가를 위한 Windows: 64비트 Windows의 특성을 사용하여 강력한 Win32 응용 프로그램 구축" ed. "피터", 2000. 이 책은 드라이버 프로그래밍과 직접적인 관련은 없지만 매우 흥미롭습니다 ;-)
이 목록은 결코 완전한 것이 아닙니다. 특히 영어로 된 많은 책을 인터넷에서 찾을 수 있습니다(Schreiber를 제외한 모든 책은 전자 형식으로 제공됩니다). 책에 관해서도 모두 '꼭 가지고 있어야 할 것'이라고 말씀드리고 싶습니다. 보시다시피 - 보지 않고 구매하세요. Walter Oney를 제외한 모든 것은 우리의 "위대하고 강력한"으로 번역됩니다.
그리고 마지막으로 한 가지. 나는 드라이버 개발 분야의 전문가가 아니기 때문에 이 기사와 이후의 모든 기사에서 오류나 부정확성이 있을 가능성이 매우 높습니다. 찾으면 마음껏 코를 찌르세요. 고맙다고 말할게요.
Microsoft는 Windows 10 운영 체제의 보안에 큰 관심을 기울이고 있습니다. 시스템의 중요한 요소 중 하나는 Windows Defender이지만 모든 위협에 대처할 수는 없습니다. 특히 랜섬웨어 바이러스는 최근 특히 널리 확산되었으며, 그 중 가장 유명한 환생은 Petya 및 . Microsoft는 랜섬웨어 바이러스 퇴치를 목표로 Windows 10에 커널 격리 및 메모리 무결성 기능을 도입했습니다. 기본적으로 비활성화되어 있습니다.
목차:커널 격리 및 메모리 무결성이란 무엇입니까?
커널 격리컴퓨터 프로세스를 운영 체제 및 장치로부터 격리하는 방법으로 제공되는 추가 보호 프로세스입니다. 이러한 조치로 인해 바이러스가 컴퓨터에 침입할 때 운영 체제의 작동이 저하되는 것을 방지할 수 있습니다.
메모리 무결성- 커널 격리에 수반되는 보호 기능으로, 잠재적으로 위험할 수 있는 알려지지 않은 프로그램의 접근을 보안 수준이 높은 프로세스로 제한하는 것을 목표로 합니다.
중요: 커널 격리 기능은 컴퓨터 하드웨어에서 이에 대한 충분한 조건이 있는 경우에만 작동할 수 있습니다. BIOS 설정에서 가상화 기술이 활성화되어 있어야 합니다. 이로 인해 Windows 10을 실행하는 컴퓨터는 가상 컨테이너에서 다양한 응용 프로그램을 실행하여 주요 시스템 구성 요소에 대한 액세스를 제한할 수 있습니다.
커널 격리 및 메모리 무결성을 활성화하는 방법
Windows 10 운영 체제 설정을 사용하면 컴퓨터의 보안 기능을 완전히 제어할 수 있습니다. Windows 10 설정을 통해 다음과 같이 커널 격리 및 메모리 무결성을 활성화할 수 있습니다.
위에서 설명한 것처럼 컴퓨터 하드웨어가 가상화를 지원하지 않으면 이 기능이 작동하지 않습니다. 켜면 사용자는 오른쪽 하단에 "메모리 무결성을 보장할 수 없습니다."라는 메시지가 표시됩니다. 비호환 가능성이 있습니다." 이 메시지가 나타나면 BIOS로 이동하여 보안 부팅(부팅 모드) 기능이 활성화되어 있는지 확인하는 것이 좋습니다.
커널 격리 및 메모리 무결성을 비활성화하는 방법
운영 체제의 작동에 심각한 영향을 미치는 운영 체제의 새로운 기능은 항상 컴퓨터 작동에 문제를 일으킬 위험이 있습니다. 커널 격리 기능도 예외는 아닙니다. 이미 이 기능을 사용해 본 사용자는 여러 게임과 프로그램을 시작할 때 문제가 발생한다고 Microsoft 포럼에 언급했습니다. 이 문제를 해결하는 유일한 방법은 커널 격리와 메모리 무결성을 비활성화하는 것입니다. 아마도 응용 프로그램 개발자나 Microsoft는 향후 업데이트에서 이러한 비호환성을 수정할 것입니다.
커널 격리 및 메모리 무결성을 비활성화하는 방법에는 세 가지가 있습니다.
내 메인 노트북에서는 다양한 전원 공급 장치 문제가 자주 발생하는데, 이는 내부 빌드에서 작업하면 설명할 수 있습니다. 그러나 안정 버전 1803에서도 시스템이 절전 모드로 들어가는 것을 멈췄습니다. 이 경우 지정된 시간이 지나면 모니터가 꺼지는데, 이는 시스템이 비활성 상태를 올바르게 결정했음을 암시합니다.
1~2분 정도의 짧은 수면 전환 시간을 설정하고 진단을 시작했습니다.
애플리케이션 및 드라이버의 전원 하위 시스템에 대한 요청 확인
가장 먼저 해야 할 일은 살펴보는 것이다. powercfg, 이는 OS가 절전 모드로 전환되는 것을 방지합니다. 전원 하위 시스템에 액세스하는 프로세스 및 드라이버는 명령 프롬프트에서 관리자로 볼 수 있습니다.
Powercfg 요청
SYSTEM에 대한 요청이 DRIVER에서 온다는 것이 즉시 분명해집니다. 이 경우 Realtek은 오디오 스트림을 사용합니다.
Chrome의 WebRTC도 목록에 있을 수 있으며 시스템을 다시 시작한 직후 다운로드 최적화 요청과 검색 색인을 볼 수 있지만 빠르게 사라집니다. 예외 목록에 프로세스나 드라이버를 추가할 수 있으며, 이로 인해 해당 프로세스가 절전 모드로 전환되는 것을 방지할 수 없습니다.
Powercfg -requestsoverride 드라이버 "Realtek High Definition Audio(HDAUDIO\FUNC_01&VEN_10EC&DEV_0269&SUBSYS_17AA2204&REV_1002\4&d00657&0&0001)" 시스템
명령은 "DRIVER [전체 드라이버 이름]에서 SYSTEM으로의 요청을 무시합니다."라고 읽습니다.
예외 목록은 레지스트리 키에 저장됩니다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerRequestOverride
명령에 의해 출력됩니다
Powercfg -요청 재정의
확실하게 재부팅했지만 시스템이 절전 모드로 전환되지 않았습니다. 예외 및 쿼리 목록을 확인한 결과 Realtek 드라이버는 예외에 포함되어 있음에도 불구하고 오디오 스트림을 계속 사용하는 것으로 나타났습니다.
나는 예외를 피해 약간 춤을 추었지만 성공하지 못했습니다. 빠른 Google은 어떤 경우에는 작동하지 않는다는 것을 확인했습니다. 이는 레거시 요청의 경우 일반적이지만 또 다른 경우가 있었는데, 제가 이 문제를 처음 접한 것은 아닙니다.
결국 목록에서 Realtek을 제거했습니다. 레지스트리 편집기나 콘솔에서 항목을 삭제할 수 있습니다. 명령은 추가할 때와 거의 동일하지만 요청이 어디로 가는지 나타내지 않습니다. 이 경우 명령 끝에 SYSTEM이 없습니다.
Powercfg -requestsoverride DRIVER "Realtek HD 오디오(HDAUDIO\FUNC_01&VEN_10EC&DEV_0269&SUBSYS_17AA2204&REV_1002\4&d00657&0&0001)"
우린 다른 길로 갈 거야
오디오 하위 시스템을 사용하는 프로세스 계산
Realtek 드라이버가 더러운 작업을 수행하는 것으로 알려져 있습니다. 당연히 시스템 시작 시 로드되므로 Autoruns를 사용하면 파일 이름을 쉽게 찾을 수 있습니다.
세 개의 항목은 두 개의 파일을 참조하며 그 중 하나는 이름으로 판단되는 제어판입니다. 그래서 관심의 대상이 된 ravbg64.exe.