개체 핸들은 특정한 프로세스 의존적인 핸들 테일블의 인덱스이며, 실행부 프로세스(EPROCESS) 블록이 가르킨다. 첫번째 핸들 인덱스는 4, 두번째 핸들 인덱스는 8등의 순인데, 프로세스의 핸들 테이블은 프로세스가 핸들을 열었던 모든 개체들에 대한 포인터들을 포함한다. 핸들 테이블들은 세 가지 수준 스키마로 구현되는데, 프로세스 당 16,000,000개 이상의 핸들을 제공하는 x86 메모리 관리 유닛이 가상 주소를 물리 주소로 변환하는 방법과 유사하다. (이를 테면 페이지 디렉토리 페이지 테이블 실제 주소로 이여지는 주소 변환 방법)

Windows 2000에서 프로세스가 생설될 때 개체 관리자는 핸들 테이블의 상위 수준을 할당하는데, 여기에는 중간 수준 테이블들에 대한 포인터들을 포함하고 있다. 중간 수준은 서브 핸들 테이블에 대한 첫 번째 포인터 배열을 포함하고, 낮은 수준은 첫 번째 서브 핸들 테이블을 담고 있다.

Windows 2000에서 개체 관리자는 하위 24 비트를 3개의 8비트 필드로 나눠 사용한다. Windows 2000에서 서브핸들 테이블은 255개의 사용 가능한 항목들로 구성된다. Windows XP와 Windows Server 2003에서 서브 핸들 테이블은 핸들 감사를 위해 사용된 한 항목을 한 페이지에서 빼서 꼭 맞게 되는 항목들로 구성된다. 예를 들어 x86 시스템 들에 대한 한 페이지는 4096 바이트이고, 핸들 테이블 항목의 크기 (8byte)로 나눈 512에서 1을 빼면 최하위 수준 핸들 테이블에서 전체 511개 항목들이 있다. Windows XP 와 Windows Server 2003에서 중간 수준 핸들 테이블은 서브핸들 테이블들에 대한 포인터들의 전체 페이지를 가지고 있어 서브핸들 테이블의 수는 페이지의 크기와 플랫폼에 대한 포인터의 크기에 의존한다.

위 그림에서 나타낸 것 처럼, x86 시스템들에서 각 핸들 항목은 두 개의 32 비트 메버 들인 개체에 대한 포인터와 승인된 엑세스 마스크를 가지는 구조체들로 구성된다. 64비트 시스템들에서, 핸들 테이블 항목은 12 바이트 long 이다. 개체 헤더에 대한 64비트 포인터와 32비트 액세스 마스크가 해당한다.

Windows 2000에서 첫 번째 32 비트 멤버는 개체에 대한 포인터와 4개의 플래그를 가지고 있다. 개체 헤더들이 항상 8 바이트로 맞추어져 있기 때문에, 이 필드의 가장 낮은 3개 비트가 플래그로서 사용되기 위해 해제 되어 있다. 항목의 가장 높은 비트는 잠금으로 사용된다. 개체 관리자가 핸들을 개체 포인터로 변활 할때 변환이 진행되는 동안 핸들 항목을 잠그는데, 모든 개체들이 시스템 주소 공간에 위치하기 때문에 개체 포인터의 높은 비트가 설정된다. 따라서 개체 관리자는 핸들 테이블 항목의 잠금이 해제될 때 높은 비트를 지우고, 프로세스의 항목 잠금에서 비트를 설정하여 개체의 정확한 포인트 값을 얻는다. 프로세스가 새로운 핸들을 생성하거나 존재하는 핸들을 닫을 때만 각 프로세스와 연결된 핸들 테이블 잠금을 사용하여, 개체 관리자는 폴세스의 전체 핸들 테이블의 잠금을 필요로한다.

첫번째는 호출자가 핸들을 닫는것을 허용할지 여부를 두번째는 상속을 (이 프로세스에 의해 생성된 프로세스들이 그들의 핸들 테이블들에서 이 핸들의 복사본을 얻을 것인지)를 가르킨다. 세번째는 개체가 닫는것이 감사 메세지를 생성해야 하는지 가르킨다.

시스템 구성요소 및 장치 드라이버들은 종종 사용자 모드 응용 프로그램이 액세스하지 못하는 개체에 대한 핸들을 열기 위해 필요하다. 이것은 커널 핸들 테이블 (Kernel handle table)에서 핸들들을 생성하여 완료한다. (내부적으로 ObpKernelHandleTable 이름으로 참조된다.) 이 테이블에서 핸들들은 오직 커널 모드에서 그리고 어떤 프로세스 컨텍스트에서도 엑세스가 가능한데, 이 말은 커널 모드 함수가 성능 영향 없이 어떤 프로세스 컨텍스트에서도 핸들을 참조 할 수 있다는 것을 의미한다. 개체 관리자는 핸들의 상위 비트가 설정될 때 커널 핸들 테이블에서 핸들들에 대한 참조를 인식한다. 즉 커널 핸들 테이블 핸들들에 대한 참조가 0x80000000 보다 더 높은 값을 가질때 그렇게 된다.

아래 그림은 V3 프로세스가 참조하는 핸들 들이다. 이렇게 핸들을 참조함으로써 빠른 엑세스가 가능하고, 또한 프로세스 생성 시 핸들을 상속 혹은 복제하여 해당 시간을 단축할 수도 있고 일관된 인터페이스를 제공받을 수 있다.

이와 더불어 개체 관리자는 개체에 대한 관리를 하고 핸들만 다른 프로세스에게 참조하게 함으로써 개체에 접근하는 모든 호출자들의 보안 프로필을 확인하고, 요청된 작업이 가능한지 등의 보안을 강화 시킬 수 있다.

먼저 !process 를 이용하여 커널 디버거에서 프로세스 개체 형식 데이터 구조체를 볼 수 있다.

 
해당 칼럼의 의미

!object의 매개 변수로 프로세스 개체 주소를 지정하여 실행한다.

개체 해더는 0x18 이후에 위치한다는 것을 볼 수 있다. (ObjectHeader: 85f93790 (old version) )

이제 해더를 보도록 하자.

해더로 부터 타입의 주소를 얻어 해당 개체 형식을 보도록 하자.

개체 형식 구조는 개체 형식 이름을 포함하고, 그 형식의 전체 활성 개체 수를 추적하며, 핸들의 최대 수와 그 형식의 개체를 추적하는 부분이 출력에서 보인다. TypeInfo 필드는 개체형식의 모든 개체들에 공통인 속성을 저장하는 데이터 구조에 대한 포인터뿐만 아니라 개체 형식의 메소드들을 저장한다.

개체는 이전 포스트(http://maystyle.tistory.com/132)에서 살펴 본 것처럼 해더와 바디로 이루어 져있다.

개체관리자는 개체의 헤더를 이용하여 개체를 관리한다.
그리고 개체에는 바디가 있는데, 이 바디의 형식은 개체 형식의 형식 개체를 참조하여 만들어진다. 즉 같은 형식의 모든 개체들은 동일 개체 바디 형식을 공유한다. 개체 형식을 생성하고 그 형식에 대해 서비스를 제공 하여, 실행부 구성 요소는 그 형식의 모든 개체 바디에서 데이터 조작을 제어 할 수 있다.

형식 개체 -> 개체 형식 -> 개체 바디의 형식 (실행부 구성요소가 해당 개체 바디에서 데이터 조작을 제어)

형식 개체에는 close, duplicate, query object, query security, set security, wait for a single object, wait for multiple objects 개체 서비스가 있다.그리고 이는 개체의 형식에 따라 구현이 각자 다르다.

winobj를 통해 형식 개체들을 보도록 하자.

개체 = 해더 + 바디
개체관리자 : 개체 헤더 제어
소유하는 실행부 구성요소 : 개체 바디 제어

각 객체 헤더는 개체를 열고 있는 프로세스들의 목록과 개체의 각인스턴스에 대한 공통 정보를 가지고 있는 형식 개체 (type object)를 가르킨다.

(출처 : Windows internals)
Each Windows environment subsystem projects to its applications a different image of the operating system. The executive objects and object services are primitives that the environment subsystems use to construct their own versions of objects and other resources.

Executive objects are typically created either by an environment subsystem on behalf of a user application or by various components of the operating system as part of their normal operation. For example, to create a file, a Windows application calls the Windows CreateFile function, implemented in the Windows subsystem DLL Kernel32.dll. After some validation and initialization, CreateFile in turn calls the native Windows service NtCreateFile to create an executive file object.

The set of objects an environment subsystem supplies to its applications might be larger or smaller than the set the executive provides. The Windows subsystem uses executive objects to export its own set of objects, many of which correspond directly to executive objects. For example, the Windows mutexes and semaphores are directly based on executive objects (which are in turn based on corresponding kernel objects). In addition, the Windows subsystem supplies named pipes and mailslots, resources that are based on executive file objects. Some subsystems, such as POSIX, don't support objects as objects at all. The POSIX subsystem uses executive objects and services as the basis for presenting POSIX-style processes, pipes, and other resources to its applications.

개체는 실행부 개체 (executive object) 와 커널 개체 (kernel object) 의 두 종류로 분류 된다.

실행부 개체 : 프로세스 관리자, 메모리 관리자, I/O 시스템 등...
커널 개체 : Windows 커널에 의해 구현된 개체 집합으로 실행부 내에서만 생성되고 사용된다. 커널 개체들은 실행부 개체들이 만드는 동기화와 같은 기본적인 기능들을 제공하기때문에 실제 커널 개체들은 실행부 개체 안에 포함된다.

Windows 는 개체 모델을 통해 실행부에서 구현된 다양한 내부 서비스들에 일관성과 보안 액세스를 제공한다.

개체 관리자 : 개체의 생성, 삭제, 보호, 추적 을 담당한다.

 
WinObj을 통한 개체 관리자 탐색

- 시스템 리소스 사용에 대한 공통의 통일 된 메카니즘 제공
- C2 보안 컴플라이언스를 획득하도록 운영체제에서 한 위치로 개체 보안을 격리
(Isolate object protection to one location in the operating system so that C2 security compliance can be achieved)
- 프로세스들이 이 개체를 사용하는 데 대한 책임 처리 메카니즘을 제공하여 시스템 리소스의 사용을 제한할 수 있게함
(Provide a mechanism to charge processes for their use of objects so that limits can be placed on the usage of system resources)
- 장치, 파일, 파일 시스템의 디렉터리, 독립적인 개체들의 집합과 같이 존제하는 개체들을 쉽게 통합할 수 있는 개체 이름 부여 스키마 구축
(Establish an object-naming scheme that can readily incorporate existing objects, such as the devices, files, and directories of a file system, or other independent collections of objects)
- 부모 프로세스로 부터 리소스들을 상속하기 위한 프로세스의 기능 및 대소문자 구분 파일 이름 생성과 같은 다양한 운영체제 환경 지원
- 개체 보존에 대한 일관된 규칙 수립
(that is, for keeping an object available until all processes have finished using it)