Sysinternals 뉴스레터 1권, 5호 - Sysinternals

아티클
08/04/2023

http://www.sysinternals.com
Copyright 1999 Mark Russinovich

1999년 10월 12일 - 이번 호의 내용:

SYSTEMS INTERNALS의 새로운 소식
- Windows 98/NTFSDOS Professional용 NTFS
- DebugView v3.21
- Filemon 및 Regmon v4.21
- Diskmon v1.1
- Systems Internals (www.microsoft.com)
- 10월 "NT Internals"
- 별로 새롭지 않은 것들
INTERNALS 뉴스
- Win2K RC2 DDK 릴리스
- 새 Win2K RC 커널 API
- 소프트웨어 개발 '99 동부
- DiskEdit 사용
향후 예정 사항
- Win2K API 폭발

스폰서: WINTERNALS 소프트웨어

Systems Internals 뉴스레터는 Winternals Software가 후원하며 웹(http://www.winternals.com.)에서 제공됩니다. Winternals Software는 Windows NT/2K용 고급 시스템 도구의 선도적인 개발업체이자 제공업체입니다. Winternals 소프트웨어 제품에는 Windows NT 4.0용 FAT32, ERD Commander(Windows NT용 부팅 디스크 기능) 및 NTRecover가 포함됩니다.

Winternals 소프트웨어의 원격 복구를 사용하면 기업 내 어디에서나 TCP/IP를 통해 부팅할 수 없는 컴퓨터의 드라이브에 액세스할 수 있습니다. NT 또는 Win9x 시스템을 오프라인 상태로 유지하는 드라이버, 파일 시스템 및 구성 문제를 원격으로 수정하여 시간을 절약하고 비용을 지원하세요. 다용도 재해 복구 도구인 원격 복구를 사용하여 원격 chkdsk 또는 분할 작업을 수행할 수도 있습니다. http://www.sysinternals.com/rrecover.htm에서 무료 읽기 전용 평가판을 다운로드하고 http://www.winternals.com.에서 읽기/쓰기 버전을 구입하세요.

여러분, 안녕하세요.

Systems Internals 뉴스레터에 오신 것을 환영합니다. 현재 뉴스레터의 구독자는 10,000명입니다.

Windows 2000(Win2K)의 출시는 임박했다가 뒤로 밀려나는 패턴을 따르는 것 같습니다. 최근 소문에 따르면 2월에 출시될 예정입니다. 그리고 Win2K 출시 날짜에 대한 유일한 정보원은 소문입니다. Microsoft에서 OEM이나 파트너에게 출시 시기를 공개하지 않기 때문입니다. 회사는 "준비가 되면 배송될 예정입니다"라고만 말합니다(여기에서 와인 판매와 관련된 진부한 표현을 쓰지는 않겠습니다).

Microsoft에 대한 짜증나는 점은 그들이 제품에 대해 생성하는 언론이 제품이 기성품일 때에도 항상 배송 직전에 있는 것처럼 보이게 한다는 것입니다. 가장 최근의 예는 Windows 98의 후속 제품인 Millennium입니다. 얼마 전까지만 해도 Microsoft는 모든 가전 제품을 지능형 장치로 변환할 준비가 된 완제품인 것처럼 언론에 대대적으로 홍보했습니다. 아이러니한 것은 얼마 지나지 않아 Microsoft가 아직 제품을 완전히 정의하지 않았으며 매장 진열대에서 보기까지 1년 이상이 걸릴 것이라는 기사가 나왔다는 것입니다.

이 패턴은 새로운 것이 아니며 이에 대해 처음으로 쓴 것도 아닙니다. 하지만 그렇다고 해서 시소잉이 얼마나 신중하게 조정된 계획인지, 그리고 소프트웨어 엔지니어링 원칙이 완전히 부족한 결과가 얼마나 되는지에 대한 추측을 멈출 수는 없습니다. 음모론자들이 하는 것처럼 전자의 각도로 구매한다면, Microsoft는 고객들이 조금만 더 기다리면 기다릴 가치가 있고 비 Microsoft 제품을 사용할 필요가 없어지는 놀라운 제품으로 고객들을 유혹함으로써 경쟁을 엄청나게 억제할 수 있습니다. 후자의 관점은 Microsoft가 소프트웨어 개발 프로세스를 결코 배우지 않을 것이며 지속적으로 엔지니어링 노력을 과소평가하고 베타 코드의 품질을 과대평가한다고 말합니다.

저는 이 입장들 중 경계에 서 있습니다. 나는 실제로 이 패턴이 둘 다 조금씩 들어맞는다고 생각합니다. Microsoft가 Active Directory가 이제 2년 동안 거의 준비가 된 것처럼 행동하는 데 도움이 되었다고 생각합니다. Win2K를 기다려야 하는 시간을 미리 알았다면 오래 전에 Novell Directory Services로 전환했을 고객이 분명 있을 것입니다. 반면 Microsoft는 제품 인도를 약속했다가 연기해 언론의 눈살을 찌푸리게 했습니다. Microsoft 경영진은 마지막 5%의 버그를 재현, 격리 및 수정하는 것이 얼마나 어려운지 이해하지 못하는 것 같습니다.

Microsoft의 개발 관행에 대해 말하자면, 시험판 명명 체계는 내가 본 것 중 가장 당혹스러운 것 중 하나입니다. 그들이 말하는 베타는 실제로는 알파이고 릴리스 후보는 실제로 베타 버전입니다. 그리고 이러한 정의를 사용하는 것조차 무리가 있습니다. Microsoft는 하나의 릴리스 후보에서 다음 릴리스 후보로 이동하거나 새 릴리스 후보를 추가할 때 소프트웨어에서 기능을 추출하는 데 아무런 문제가 없습니다. NT 4.0에서 그렇게 했고 Win2K에서도 그렇게 하고 있습니다. 이러한 관행은 확실히 릴리스 주기를 가속화하지 않습니다.

그렇다면 Win2K는 2월에 배송되나요? 저는 이 긴 터널이 거의 다 끝나간다고 생각합니다. 결국 RC2에는 소수의 새로운 API만 있습니다…

Microsoft의 두문자어 혼란에 대해 이야기한 지난 뉴스레터의 후속 조치로 George Janczuk 독자는 또 다른 예를 찾았습니다. "메인프레임 트랜잭션 처리 세계로 확장" 섹션에서 http://msdn.microsoft.com/library/backgrnd/html/msdn_windnapps.htm의 기사는 CISC - 복합 명령어 세트 컴퓨팅을 참조합니다. 메인프레임 애플리케이션을 잘 아는 사람이라면 누구나 의도된 약어가 CICS - Customer Information Control System임을 알 수 있습니다. 역순의 문자와 여러분은 완전히 다른 기술 영역에 있습니다.

여느 때처럼 관심이 있을 것 같은 친구에게 뉴스레터를 전달해 주세요.

감사합니다!

-Mark

SYSTEMS INTERNALS의 새로운 소식

WINDOWS 98/NTFSDOS 전문가용 NTFS

드디어 우리가 해냈습니다. 1996년 봄에 Bryce와 제가 NTFS DOS 1.0을 출시한 이후로 우리는 Windows 9x 및 DOS에서 NTFS를 위한 읽기/쓰기 액세스라는 Windows 파일 시스템 호환성의 성배를 찾고 있었습니다. 우리는 NTFS 형식을 리버스 엔지니어링하고 이 복잡한 저널링 파일 시스템용 드라이버를 작성하는 것이 어렵고 위험한 제안이 될 것이라고 오래 전에 결정했습니다. 형식의 모든 뉘앙스를 정확하게 결정하더라도 Win2K의 NTFS v5.0과 같은 형식 업데이트에는 완전히 새로운 리버스 엔지니어링 및 개발 노력이 필요합니다. 또한 NTFS와 같이 복잡한 형식에 대한 파일 시스템 드라이버의 정확성을 검증하는 것은 어려운 제안입니다.

그래서 우리는 꼼수를 썼습니다.

Windows 98용 NTFS는 Windows 95 또는 Windows 98에서 NTFS 드라이브에 대한 전체 읽기/쓰기 액세스를 제공하고 NTFSDOS Professional은 DOS에서 전체 NTFS 읽기/쓰기 액세스를 제공합니다. Windows 98용 NTFS도 NTFSDOS Professional도 NTFS 파일 시스템 형식에 대해 알지 못합니다. 오히려 그들은 해당 지식을 구현하기 위해 Windows NT 또는 Windows 2000 설치의 NTFS 드라이버에 의존합니다. 두 유틸리티 모두 NTFS 파일 시스템 드라이버의 환경 래퍼 역할을 하는 동일한 코드 기반을 사용합니다. Windows 98용 NTFS는 NTFS 위의 Windows 9x 파일 시스템 API와 NTFS 아래의 Windows 9x 디스크 서비스에 대한 인터페이스를 제공합니다. Windows 98용 NTFS가 NTFS에 제공하는 인터페이스는 NTFS의 기본 Windows NT/2K 환경처럼 보이며 IRP, I/O 관리자, 캐시 관리자, NT 스타일 디스크 장치 및 NTFS가 상호 작용하는 기타 NT/2K 하위 시스템을 갖추고 있습니다.

NTFSDOS Professional은 Windows 98용 NTFS와 동일한 방식으로 작동하지만 NTFS와 위의 DOS 서비스 및 아래의 BIOS 인터럽트 13 디스크 서비스를 인터페이스한다는 점이 다릅니다. NT/2K와 유사한 환경을 만들기 위해 우리는 NTOSKRNL, NT/2K 커널 파일 내의 많은 기능에 의존합니다. 두 유틸리티 모두 NTFS와 함께 NTOSKRNL을 로드하므로 NTFS는 커널의 기본 서비스를 직접 사용할 수 있습니다.

우리는 NTFS 환경을 구축하는 것이 너무 재미있어서 한 단계 더 나아갔습니다. NT의 부팅 시간 chkdsk 유틸리티인 Autochk로 동일한 작업을 수행했습니다. Windows 98용 NTFSDOS Professional 및 NTFS에는 NTFSCHK라는 NTFS chkdsk 유틸리티가 함께 제공됩니다. NTFSCHK는 NTFS 파일 시스템 래퍼와 동일한 주체에서 작동하며 Autochk 프로그램이 Windows 95/98 및 DOS에서 실행되도록 NT와 유사한 Autochk 프로그램 환경을 만듭니다. 이 꼼수의 결과는 Windows 95/98 및 DOS에 대한 완전한 NTFS 읽기/쓰기 지원입니다.

http://www.sysinternals.com/ntfs98.htm에서 Windows 98용 NTFS의 무료 읽기 전용 버전을 다운로드하고 http://www.sysinternalscom/ntfspro.htm.에서 NTFSDOS Professional의 무료 읽기 전용 버전을 다운로드할 수 있습니다. Winternals Software http://www.winternals.com.에서 두 도구의 전체 읽기/쓰기 버전을 구입할 수 있습니다.

DEBUGVIEW V3.21

DebugView는 Windows 95, Windows 98, NT 4.0 및 Windows 2000에서 커널 및 Win32 디버그 출력을 모두 캡처하는 디버그 출력 모니터입니다. 고급 필터링, 강조 표시 및 로깅 기능이 있으며 네트워크를 통해 시스템의 디버그 출력을 캡처할 수도 있습니다. 최신 릴리스인 3.21에는 Windows 95 및 Windows 98에서 16비트 OutputDebugString 출력을 모니터링하는 기능이 도입되었습니다.

http://www.sysinternals.com/dbgview.htm.에서 DebugView v3.21을 다운로드할 수 있습니다.

FILEMON 및 REGMON V4.21

Filemon 및 Regmon은 Windows 95, 98, NT 4.0 및 Win2K용 파일 시스템 및 레지스트리 감시 유틸리티입니다. 이러한 기능은 새로운 사용성 기능과 함께 계속 진화하고 있으며 릴리스 4.21(Filemon 및 Regmon에는 동기화된 버전 번호가 있음)에서는 최신 필터 목록을 통해 고급 필터링 기능, 사용자 지정 가능한 색상의 하이라이트 필터 정의 기능, 사용자 지정 가능한 글꼴, 클립보드 지원 및 더 많은 CUI 호환 단축키가 도입되었습니다. 드라이버 소스 코드도 재작업되었으며 GUI 인터페이스 기능에 보다 강력한 매개변수 유효성 검사가 포함되었습니다.

http://www.sysinternals.com/filemon.htm에서 Filemon v4.21을 다운로드하고 http://www.sysinternals.com/regmon.htm.에서 Regmon v4.21을 다운로드하세요.

DISKMON V1.1

Diskmon은 논리적 및 물리적 디스크 활동을 모니터링하고 표시하는 도구입니다. 버전 1.1은 Windows 2000과 함께 작동하도록 Diskmon을 업데이트하고 새로운 사용성 향상을 소개합니다. 또한 Diskmon은 이제 수많은 디스크 및 대용량 I/O 제어 코드를 해석하여 16진수 코드를 Diskmon 출력 창의 텍스트 표현으로 변환합니다.

Diskmon v1.1은 디스크 모니터 기능뿐만 아니라 소프트웨어 기반 디스크 라이트로도 사용할 수 있습니다. 디스크 라이트 모드로 설정하면 Diskmon은 디스크 읽기 액세스가 있을 때 녹색, 디스크 쓰기 액세스가 있을 때 빨간색 표시등으로 시스템 트레이에 최소화됩니다.

http://www.sysinternals.com/diskmon.htm.에서 Diskmon v1.1 다운로드

WWW.MICROSOFT.COM의 내부 시스템

Systems Internals(이전의 NT Internals)의 역사를 고려할 때 Microsoft가 고객을 위한 리소스로 sysinternals.com을 언급하는 것은 참으로 대단한 찬사입니다. Systems Internals 유틸리티를 가리키는 Microsoft 기술 자료 문서가 점점 늘어나고 있습니다. 최신 정보는 다음과 같습니다.

Q183060 정보: 80004005 및 기타 오류 메시지에 대한 문제 해결 가이드 http://support.microsoft.com/support/kb/articles/Q183/0/60.ASP
이 문서에서는 Filemon을 사용하여 OLE DB, ActiveX 데이터 개체 및 원격 데이터 서비스에서 데이터 액세스 오류의 원인을 확인할 수 있다고 설명합니다.
Q196453 - NTVDM 및 WOW 시작 오류 문제 해결 http://support.microsoft.com/support/kb/articles/Q196/4/53.ASP
또한 이 문서에서는 NTVDM(NT의 Win16/DOS 호환성 환경)에 대한 시작 오류를 일으키는 누락된 파일을 확인하기 위한 도구로 Filemon을 지적합니다.
Q216368 - PRB: 파일 사용 http://support.microsoft.com/support/kb/articles/Q216/3/68.ASP 시 애플리케이션 설정 중 액세스 위반
HandleEx 및 DLLView는 Visual Basic 설치 마법사 및 배포 마법사에서 생성된 설치 프로그램 실행 중 오류 원인을 확인하는 데 권장되는 도구입니다.
Q232830 - HOWTO: 파일 핸들 소유권 결정 http://support.microsoft.com/support/kb/articles/Q232/8/30.ASP
HandleEx는 파일 또는 디렉터리가 열려 있는 프로세스를 찾는 방법을 설명하는 이 기사에서 참조를 다시 얻습니다.

10월 "NT 내부"

Windows NT Magazine 10월호에 실린 "NT Internals" 칼럼은 "Inside Win2K Reliability Enhancements, Part 3"입니다. 세 부분으로 구성된 시리즈의 세 번째 부분에서는 개발자와 관리자가 버그가 있는 드라이버를 정확히 찾아내는 데 도움이 되는 두 가지 강력한 Win2K 기능인 쓰기 방지된 커널 메모리와 드라이버 확인 프로그램에 대해 설명합니다.

러시아 독자들은 이제 모국어로 제 기사를 읽을 수 있습니다. Windows NT Magazine 러시아판(http://www.osp.ru/win2000/)으로 이동하여 번역된 첫 번째 NT Internals 칼럼인 Inside the Boot Process(http://www.osp.ru/win2000/1999/10/59.htm).를 확인하세요. 이에 대해 알려준 Ivan Rouzanov에게 감사드립니다.

8월 초부터 Windows NT Magazine 기사의 온라인 버전은 구독자만 액세스할 수 있으며 기사는 새로운 호가 나올 때마다 온라인에 게시됩니다. 구독하지 않은 경우 http://www.sysinternals.com/publ.htm의 구독 링크를 통해 Systems Internals 구독 할인을 받으세요.

별로 새롭지 않은 것들

WinObj는 Windows NT/2K 개체 네임스페이스를 탐색하기 위한 강력한 도구입니다. Object 네임스페이스는 NT/2K의 세 가지 네임스페이스인 Object 네임스페이스, Registry 네임스페이스 및 파일 시스템 네임스페이스 중 하나입니다. 개체 네임스페이스의 개체를 통해 레지스트리 및 파일 시스템 네임스페이스에 액세스할 수 있습니다. 예를 들어 Win32 프로그램이 레지스트리 키 HKEY_LOCAL_MACHINE\Software\Microsoft을 열면 ADVAPI32.DLL 라이브러리는 커널 서비스 NtCreateKey을 호출하기 전에 이름을 \Registry\Machine\Software\Microsoft(으)로 변환합니다. WinObj에서 개체 네임스페이스의 루트를 보면 Registry라는 이름의 "키" 유형 개체를 볼 수 있습니다. 레지스트리 이름은 키 이름의 첫 번째 구성 요소와 일치하므로 NT/2K 개체 관리자는 이름의 나머지 \Machine\Software\Microsoft을(를) 키 개체를 정의하는 하위 시스템에 전달합니다. Configuration Manager 커널 하위 시스템은 레지스트리 및 키 개체를 유지하므로 이름의 나머지 부분을 구문 분석하여 원하는 키를 찾습니다.

개체 네임스페이스를 탐색하고 WinObj를 사용하여 개체 보안 속성을 보거나 설정할 수 있습니다. http://www.sysinternals.com/winobj.htm.에서 Winobj 다운로드 저는 1997년 10월 NT Internals 칼럼 "Inside the Object Manager"에서 Object Manager 네임스페이스와 WinObj에 대해 논의했습니다. 에서 열의 온라인 버전에 대한 링크를 따릅니다. http://www.sysinternals.com/publ.htm.

INTERNALS 뉴스

WIN2K RC2 DDK 출시

지금 http://www.microsoft.com/ddk/ddkRC2.htm.에서 Microsoft의 장치 드라이버 개발 키트(DDK)의 Win2K RC2 릴리스를 다운로드할 수 있습니다. 키트를 무료로 다운로드하거나 온라인으로 설명서를 찾아볼 수 있습니다.

새로운 WIN2K RC2 커널 API

최신 Win2K 커널에서 상황이 안정화되는 것으로 보입니다. 베타 3에서 RC1로 넘어가는 약 12개(및 사라진 6개)와 달리 RC3에는 4개의 새로운 내보낸 커널 API만 있습니다. 몇 가지 새로운 기능이 다소 흥미롭기 때문에 이를 문서화하기로 결정했습니다. 첫 번째는 MmGetSystemRoutineAddress이며 문서화되지는 않았지만 해당 프로토타입은 RC2 DDK의 ntddk.h 헤더 파일에 포함되어 있습니다.

NTKERNELAPI
PVOID
MmGetSystemRoutineAddress (
    IN PUNICODE_STRING SystemRoutineName
    );

그것의 사용은 보이는 것처럼 간단합니다. NTOSKRNL.EXE 또는 HAL.DLL에 있는 함수의 이름을 전달하면 진입점 주소를 다시 얻을 수 있습니다. 이 기능은 Win2K의 첫 번째 릴리스에서는 실제로 쓸모가 없지만 앞으로 매우 유용하게 될 수 있으며 Microsoft가 NT의 첫 번째 릴리스(3.1)에 포함했어야 하는 기능입니다. Win32 애플리케이션용 사용자 공간의 GetProcAddress과 마찬가지로 이 함수를 통해 드라이버는 API의 가용성을 동적으로 확인할 수 있습니다. Microsoft가 Win2K 서비스 팩에 새 API를 추가하면(물론 저는 그렇게 될 것이라고 확신합니다) 드라이버를 작성하여 API를 활용할 수 있지만 이전 버전의 Win2K에서 정상적으로 실패하거나 API를 사용하지 않는 모드로 실행할 수도 있습니다. 이를 수행할 수 있는 드라이버의 핵심은 로드 후 API의 존재를 확인하는 기능입니다. 이 기능이 없으면 드라이버는 자신이 사용하는 기능과 정적으로 링크해야 하며, 드라이버가 로드될 때 기능이 없으면 커널 로더는 사용자에게 못생긴 오류를 보고하고 드라이버를 로드하지 못합니다.

두 번째 새 API는 MmGetPhysicalMemoryPages입니다. 다시 말하지만, 프로토타입은 RC2 ntddk.h에 있지만 문서화되어 있지 않습니다. 프로토타입은 다음과 같습니다.

NTKERNELAPI
PPHYSICAL_MEMORY_RANGE
MmGetPhysicalMemoryRanges (
    VOID
    );

여기서 PHYSICAL_MEMORY_RANGE은:

typedef struct _PHYSICAL_MEMORY_RANGE {
    PHYSICAL_ADDRESS BaseAddress;
    LARGE_INTEGER NumberOfBytes;
} PHYSICAL_MEMORY_RANGE, *PPHYSICAL_MEMORY_RANGE;

이 함수는 BaseAddress 및 NumberOfBytes 모두에 대해 0을 갖는 항목으로 표시된 배열의 끝과 함께 PHYSICAL_MEMORY_RANGE 항목의 배열을 반환합니다. MmGetSystemRoutineAddress과(와) 마찬가지로 매우 간단한 API입니다. Win2K가 알고 있는 모든 물리적 메모리에 대한 설명을 반환합니다. Win2K는 MmAddPhysicalMemory 및 MmRemovePhysicalMemory API를 사용하여 즉시 메모리 추가 및 제거를 지원합니다. 메모리 범위를 쿼리할 수 있는 API가 존재하는 이유입니다. MmAddPhysicalMemory은(는) RC1에, MmRemovePhysicalMemory는 RC2에 추가되었습니다. 이 두 함수는 모두 ntddk.h에서 프로토타입으로 만들어집니다.

다른 새로운 RC2 API는 무엇입니까? PoShutdownBugCheck와 RtlInvertRangeList을 참조하세요. PoShutdownBugCheck을(를) 사용하면 시스템을 중단하고 일시 중지와 같은 전원 관련 작업을 수행할 수 있습니다. RC2 커널에 의해 몇 군데에서 사용됩니다. 범위는 관리, 정렬 및 반복을 위해 여러 커널 API에서 지원하고 사용자 정의되는 일반적인 시작-끝 사양입니다. Win2K 플러그 앤 플레이 리소스 중재자는 이를 사용하여 하드웨어 리소스 요구 사항을 추적하고 구성합니다. 범위 목록 API가 문서화되어 있지 않더라도 모든 프로토타입과 구조 정의가 ntddk.h에 포함되어 있으므로 API를 사용하여 자신의 시작-종료 지향 데이터를 관리할 수 있을 것입니다.

후속 뉴스레터에서 문서화되지 않은 API로 더 많은 재미를 기대해 주세요.

소프트웨어 개발 99 EAST

소프트웨어 개발의 1999년 동부 해안 에디션이 11월 8일부터 12일까지 워싱턴 D.C.에서 열립니다. 마지막 날에는 개발자를 위한 Windows 2000의 새로운 기능, Windows NT/2000 블루 스크린 내부, Windows NT/2000 네트워킹 내부 등 세 가지 강연을 할 예정입니다. 또한 Inside Windows NT 2nd Edition의 저자이자 이웃인 Dave Solomon(그는 나와 단 20분 거리인 코네티컷 주 댄버리에 거주)과 Windows NT/2K 내부 원탁 회의를 주최하고 있습니다. 우리는 Windows NT/2K 내부에 대한 가장 어려운 질문에 답하기 위해 함께 할 것입니다. 인사를 하고 뉴스레터를 언급하면 무료 Systems Internals 티셔츠를 드립니다!

http://www.sdexpo.com.에서 소프트웨어 개발 웹 사이트를 방문하세요.

DISKEDIT 사용

모르실 수도 있지만, DOS용 Norton Disk Edit 스타일의 Windows NT용 디스크 편집기 유틸리티가 있습니다. 또한 이 유틸리티는 FAT 및 NTFS를 이해하며 무료입니다. Microsoft는 Windows NT 4.0 서비스 팩 4 CD에서 파일 시스템 팀을 위한 내부 디버깅 도구여야 하는 도구인 DiskEdit를 실수로 제공한 것으로 보입니다. DiskEdit에는 문서화하는 데 작은 설명서가 필요한 독특한 인터페이스가 있지만 간단한 연습부터 시작하겠습니다. DiskEdit은 NTFS를 이해하는 공개적으로 사용할 수 있는 유일한 도구이기 때문에 DiskEdit을 사용하여 NTFS 파일 시스템 형식을 밝히는 데 집중할 것입니다.

먼저 서비스 팩 4(SP4) CD-ROM에서 DiskEdit를 가져와야 합니다. \i386 디렉터리에서 하드 디스크로 복사하기만 하면 됩니다. Win2K에서 DiskEdit를 사용하려면 전용 디렉터리를 생성하고 SP4 winnt\system32 디렉터리(또는 SP4 CD)에서 DiskEdit: IFSUTIL.DLL, ULIB.DLL, UNTFS.DLL 및 UFAT.DLL과 같은 디렉터리에 다음 DLL을 복사해야 합니다. 이제 DiskEdit을 시작할 수 있습니다.

이 연습에서는 NTFS 드라이브의 루트에 TEMP라는 디렉터리를 만들고 TEMP를 현재 디렉터리로 사용하여 명령 프롬프트 창에 다음 명령을 입력하여 해당 디렉터리에 OUT.TXT라는 파일을 만듭니다. echo hello > out.txt. File|Open 메뉴 항목을 선택하고 결과 대화 상자의 Volume Name 필드에 드라이브 문자를 입력하여 DiskEdit에서 새 OUT.TXT 파일이 있는 드라이브를 선택합니다. 예를 들어 콜론을 포함해야 합니다. "d:". 사실상 DiskEdit의 모든 기능을 사용하려면 드라이브를 열어야 합니다.

NTFS 드라이브의 루트 디렉터리에서 시작하여 OUT.TXT 파일을 찾습니다. 메뉴 항목 읽기|NTFS 파일 레코드를 선택하여 번호를 입력하기만 하면 MFT 레코드 항목을 볼 수 있는 대화 상자를 엽니다. 모든 NTFS 드라이브의 처음 16개 MFT 레코드 항목은 예약되어 있으며 미리 정의된 NTFS 메타데이터 파일에 해당합니다. 다음은 할당된 숫자입니다(DiskEdit는 모든 입력을 16진수로 해석합니다).

        0: $MFT - MFT
        1: $MFTMirr - MFT Mirror (a copy of the first 4 entries of the MFT)
        2: $LogFile - NTFS LogFile
        3: $Volume - volume information file
        4: $AttrDef - the attribute definition file
        5: . - the root directory
        6: $Bitmap - the volume allocation bitmap file
        7: $Boot - the boot sector
        8: $BadClus - the bad cluster database file
        9: $Secure - new to SP4, the security attribute database
        A: $UpCase - the lower-to-upper case mapping file
        B: $Extend - new to Win2K, the directory that contains
                             the reparse, object ID, and quota metadata files
        C-F: Unused as of NTFS v5.0 (Win2K)

계속해서 이러한 MFT 항목 중 일부를 살펴보세요. 공통 주제를 알아차리기 시작할 것입니다. 모두 $INDEX_ROOT, $FILE_NAME 및 $DATA과(와) 같은 특성으로 구성됩니다. 파일에 특정한 데이터가 저장되는 특성에 있습니다. 특성 데이터가 작은 경우 NTFS는 파일의 MFT 레코드 내의 데이터를 "상주" 데이터로 저장하고 데이터가 큰 경우 NTFS는 디스크의 클러스터에 있는 레코드 외부의 데이터를 "비상주" 데이터로 저장합니다.

이제 파일 번호로 "5"를 입력하면 루트 디렉터리의 파일이 표시됩니다. 디렉터리의 내용을 기록하는 디렉터리 고유의 특성인 디렉터리의 $INDEX_ALLOCATION 특성을 확인하여 루트 디렉터리에 있는 파일과 디렉터리를 살펴보겠습니다. 그렇게 하려면 다른 대화 상자를 여는 Read|NTFS Attribute 메뉴 항목을 선택하세요. DiskEdit은 대소문자를 구분하므로 내가 나열한 대로 정확하게 다음을 입력하세요.

        Base Frs Number: 5

Base Frs(Base File Record Segment)는 MFT 번호의 다른 이름입니다. 루트 디렉터리에서 특성을 읽도록 지정하려면 5를 입력합니다.

        Attribute Type: $INDEX_ALLOCATION

이는 디렉터리의 콘텐츠 데이터를 읽고 싶다는 것을 DiskEdit에 나타냅니다. DiskEdit는 특성 유형이 입력되는 방식에 대해 매우 까다롭기 때문에 풀다운 메뉴를 사용하여 원하는 특성을 선택하는 것이 좋습니다.

        Attribute Name: $I30

루트 디렉터리의 $INDEX_ALLOCATION 특성을 보면 "$I30"가 "Type code, name" 줄에 이름으로 나열되어 있으므로 특성 이름으로 입력한 내용입니다.

확인을 누르면 특성 내용의 16진수 덤프가 표시됩니다. 좀 더 알기 쉽게 보기를 원하므로 View|NTFS Index Buffer 메뉴 항목을 선택합니다. 디렉터리의 내용 목록이 표시됩니다. 이름이 "TEMP"인 항목이 보일 때까지 목록을 스크롤합니다. 표시되지 않으면 항목이 루트 디렉터리의 $INDEX_ROOT 특성에 있을 수 있습니다. 이 특성 유형은 디렉터리와도 연결되어 있고 해당 값은 항상 MFT 레코드에 저장되어 있습니다. 인덱스 루트 항목과 할당 항목은 함께 디렉터리의 모든 항목을 저장하는 B+ 트리 구조를 형성합니다. $INDEX_ROOT 특성을 보아야 하는 경우 $INDEX_ALLOCATION 특성을 볼 때와 동일한 단계를 따라 해당 특성을 보기만 하면 됩니다. 인덱스 버퍼를 스크롤하면 두 줄의 별표를 볼 수 있습니다. 별표는 한 인덱스 버퍼의 끝과 다음 인덱스 버퍼의 시작을 나타냅니다.

TEMP 디렉터리의 항목을 찾으면 파일 참조(FRS)를 기록해 둡니다. Read|NTFS File Record를 선택하고 TEMP의 FRS를 입력합니다. 이제 TEMP 디렉터리에 대한 MFT 레코드를 보고 있습니다. OUT.TXT 파일을 찾으려면 TEMP의 내용을 살펴봐야 합니다. TEMP 디렉터리의 $INDEX_ALLOCATION(또는 $INDEX_ROOT) 특성을 보고 데이터를 NTFS 인덱스 버퍼로 보기로 전환한 다음 OUT.TXT 파일을 찾습니다. 특성 선택 대화 상자에서 기본 FRS 번호로 TEMP의 FRS를 입력해야 합니다. 방금 TEMP를 생성했다면 $INDEX_ROOT만 있을 것입니다(뭔가를 잘못 입력하면 DiskEdit의 빈 오류 대화 상자에서 보는 즐거움을 얻게 될 것입니다).

OUT.TXT를 찾고 해당 FRS를 확인했으면 Read|NTFS File Record를 사용하여 MFT 항목을 확인합니다. $DATA 특성을 찾을 때까지 아래로 스크롤합니다. 지금 여러분은 OUT.TXT의 데이터 위치를 보고 계십니다. 작은 파일을 만들었기 때문에 데이터는 MFT 레코드에 저장됩니다. DiskEdit을 사용하여 OUT.TXT의 $DATA 특성을 보려고 하면 DiskEdit이 상주 데이터(DiskEdit의 많은 버그 중 하나)를 제대로 표시하지 않기 때문에 아무것도 표시되지 않습니다. 따라서 큰(> 2KB) 텍스트 파일을 \TEMP\ OUT.TXT에 복사합니다. 이제 두 가지 방법 중 하나로 OUT.TXT 데이터를 볼 수 있습니다. Read|NTFS 클러스터를 사용하고 첫 번째 "lcn" 값을 지정하여 데이터의 시작(또는 디스크에 연속적으로 저장된 경우 모든 데이터)을 검사할 수 있습니다. OUT.TXT의 $DATA 특성 "Extent List"를 참조하세요. 또는 Read|NTFS 특성을 사용하고 특성 유형으로 "$DATA"를 입력하고 특성 이름으로 아무것도 입력하지 마세요(해당 필드에 아무것도 입력하지 않음).

익스텐트 목록은 특성의 비상주 데이터의 위치를 설명합니다. 최대 16개의 클러스터에 대한 각 연속 데이터 블록은 하나의 익스텐트 목록 항목으로 설명됩니다. 익스텐트 목록 항목은 가상 클러스터 번호(vcn), 논리 클러스터 번호(lcn) 및 실행 길이를 지정합니다. Vcn은 항목에서 설명한 데이터가 시작되는 파일 내의 클러스터입니다. Lcn은 데이터가 디스크에 저장되는 논리 클러스터를 지정하고 runlength는 해당 위치에 있는 특성 데이터의 바이트 수입니다(DiskEdit는 16진수 값을 표시합니다).

디렉터리 콘텐츠를 검색하는 방법을 보여 줌으로써 OUT.TXT 파일의 MFT 레코드를 찾는 먼 길을 안내했습니다. 그러나 바로 가기가 있습니다. Crack|NTFS Path를 선택하고 TEMP\OUT.TXT를 입력합니다. OUT.TXT의 FRS가 제공되며 Read|NTFS File Record를 사용하여 바로 이동할 수 있습니다.

그러면 DiskEdit 입문서가 끝납니다. FAT 또는 NTFS 드라이브를 검색하여 이 멋진 도구를 사용하는 것이 좋습니다. Disk Edit을 사용하여 디스크의 막힘을 제거할 수 있는 경우는 거의 없지만 NTFS 디스크의 형식(FAT 형식은 잘 문서화되어 있음)이 궁금하다면 이 형식이 조사에 완벽한 도구입니다.

향후 예정 사항

WIN2K API 폭발

RC2에 데뷔한 새 커널 모드 API는 4개에 불과하지만 커널과 핵심 Win32 DLL 모두에서 NT 4.0 이후 Microsoft가 도입한 총 API 수는 폭발적입니다. 다음 달에는 정확히 몇 개의 새로운 API가 있고 어디에 나타났는지 알려드릴 것이며, 불행하게도 동시에 Win2K가 팽창한 괴물이라고 믿는 사람들에게 alt.advocacy.linux Usenetrants를 위한 훌륭한 근거를 제공합니다.

Systems Internals 뉴스레터를 읽어 주셔서 감사합니다.

게시일: 1999년 10월 20일 수요일 오후 7:10 작성자: ottoh

[회보 보관 ^] [< 볼륨 1, 번호 4] [볼륨 2, 번호 1 >]

다음을 통해 공유

SYSTEMS INTERNALS의 새로운 소식

WINDOWS 98/NTFSDOS 전문가용 NTFS

DEBUGVIEW V3.21

FILEMON 및 REGMON V4.21

DISKMON V1.1

WWW.MICROSOFT.COM의 내부 시스템

10월 "NT 내부"

별로 새롭지 않은 것들

INTERNALS 뉴스

WIN2K RC2 DDK 출시

새로운 WIN2K RC2 커널 API

소프트웨어 개발 99 EAST

DISKEDIT 사용

향후 예정 사항

WIN2K API 폭발

추가 리소스

다음을 통해 공유

Systems Internals 뉴스레터 1권, 5호

SYSTEMS INTERNALS의 새로운 소식

WINDOWS 98/NTFSDOS 전문가용 NTFS

DEBUGVIEW V3.21

FILEMON 및 REGMON V4.21

DISKMON V1.1

WWW.MICROSOFT.COM의 내부 시스템

10월 "NT 내부"

별로 새롭지 않은 것들

INTERNALS 뉴스

WIN2K RC2 DDK 출시

새로운 WIN2K RC2 커널 API

소프트웨어 개발 99 EAST

DISKEDIT 사용

향후 예정 사항

WIN2K API 폭발

추가 리소스