NTFS Documents (15)

Overcast Happy

Authoreric   Category Related Resource   Comments0   Post Time 2007-09-26 21:11:38 -0400

Absolute, security descriptor doesn’t contain the owner and group SIDs, nor the sacl and dacl.

ACL's inside the security descriptor. Instead, it contains pointers to these structures in memory.

Obviously, absolute security descriptors are only useful for in memory representations of security descriptors. On disk, a self-relative security descriptor is used.  Attribute: Security descriptor (0x50). A standard self-relative is security descriptor.  

NOTE: Always resident.  

NOTE: Not used in NTFS 3.0+, as security descriptors are stored centrally in FILE_$Secure and the correct descriptor is found using the security_id from the standard information attribute.  

On NTFS 3.0+, all security descriptors are stored in FILE_$Secure. Only one referenced instance of each unique security descriptor is stored.  

FILE_$Secure contains no unnamed data attribute, i.e. it has zero length. It does, however, contain two indexes ($SDH and $SII) as well as a named data stream ($SDS).  Every unique security descriptor is assigned a unique security identifier (security_id, not to be confused with a SID).

The security_id is unique for the NTFS volume and is used as an index into the $SII index, which maps security_ids to the security descriptor's storage location within the $SDS data attribute. The $SII index is sorted by ascending security_id.  

A simple hash is computed from each security descriptor. This hash is used as an index into the $SDH index, which maps security descriptor hashes to the security descriptor's storage location within the $SDS data attribute.  

The $SDH index is sorted by security descriptor hash and is stored in a B+ tree. When searching $SDH (with the intent of determining whether or not a new security descriptor is already present in the $SDS data stream), if a matching hash is found, but the security descriptors do not match, the search in the $SDH index is continued, searching for a next matching hash.  

When a precise match is found, the security_id corresponding to the security descriptor in the $SDS attribute is read from the found $SDH index entry and is stored in the $STANDARD_INFORMATION attribute of the file/directory to which the security descriptor is being applied. The $STANDARD_INFORMATION attribute is present in all base MFT records (i.e. in all files and directories).  

If a match is not found, the security descriptor is assigned a new unique security_id and is added to the $SDS data attribute. Then, entries referencing the security descriptor in the $SDS data attribute are added to the $SDH and $SII indexes.

Note: Entries are never deleted from FILE_$Secure, even if nothing references an entry any more.  The $SDS data stream contains the security descriptors, aligned on 16-byte boundaries, sorted by security_id in a B+ tree. Security descriptors cannot cross 256kib boundaries (this restriction is imposed by the Windows cache manager). Each security descriptor is contained in a SDS_ENTRY structure.  

Also, each security descriptor is stored twice in the $SDS stream with a fixed offset of 0x40000 bytes (256kib, the Windows cache manager's max size) between them; i.e. if a SDS_ENTRY specifies an offset of 0x51d0, then the first copy of the security descriptor will be at offset 0x51d0 in the $SDS data stream and the second copy will be at offset 0x451d0.  

$SII index. The collation type is COLLATION_NTOFS_ULONG.  

$SDH index. The collation rule is COLLATION_NTOFS_SECURITY_HASH.

We believed that we had researched the most Seurue_id in NTFS. But there might be some varieties we didn’t find. Such as some indexes varieties etc.

In data recovery field, the varieties are so hard to find. These varieties take more difficulties in data recovery. However, this is the fascination of the data recovery.

Trackback URL Trackback: http://blog.easeus.com/action.php?action=tb&id=58

Tags Tags: windows,NTFS,xp,ntfs,filesystem

Comments List

Post a Comment

  • Name:
  • Email:
  • HomePage:
  • Comment:
  • Question:

Home | Solution | About Company | Contacts | Resource | Blog | Forum | Directory | Links | Sitemap

Copyright © 2005-2008 CHENGDU YIWO Tech Development Co., Ltd. ALL RIGHTS RESERVED.

Privacy Policy | License | Legal Counsel