NTFS Links: Hard Links, Junctions, Symbolic Links

There are three types of file links supported in the NTFS file system:

  1. hard links
  2. junctions
  3. symbolic links.


Hard Links

A hard link is the file system representation of a file by which more than one path references a single file in the same volume. A hard link directly points to the file, and acts to the operating system as if it is the file itself. You’ll want to use this option the majority of the time if you are trying to fake an application’s directory.


NTFS Junctions (or) Soft Links

A soft link on filesystems is not a link to a file itself, but to a file name; this also creates aliasing, but in a different way. A soft link is essentially a shortcut to a file or folder – if you are using Windows explorer, you’ll be redirected to the directory if you double-click on a shortcut, it won’t pretend its part of the filesystem. You can still directly reference or open a file with the symlinked path, and it mostly works.

A junction (also called a soft link) differs from a hard link in that the storage objects it references are separate directories, and a junction can link directories located on different local volumes on the same computer. Otherwise, junctions operate identically to hard links. Junctions are implemented through reparse points.

An NTFS junction point is a feature of the NTFS file system that provides the ability to create a symbolic link to a directory which then functions as an alias of that directory. This has many benefits over a Windows shell shortcut (.lnk) file, such as allowing access to files within the directory via Windows Explorer, the Command Prompt, etc.


Symbolic Link

A NTFS symbolic link (symlink) is a filesystem object in the NTFS filesystem that points to another filesystem object. The object being pointed to is called the target. Symbolic links should be transparent to users; the links appear as normal files or directories, and can be acted upon by the user or application in exactly the same manner. Symbolic links are designed to aid in migration and application compatibility with POSIX operating systems, and were introduced with the modifications made to the NTFS file system with Windows Vista.

Unlike an NTFS junction point (available since Windows 2000), a symbolic link can also point to a file or remote SMB network path. While NTFS junction points support only absolute paths on local drives, the NTFS symbolic links allow linking using relative paths. Additionally, the NTFS symbolic link implementation provides full support for cross-filesystem links. However, the functionality enabling cross-host symbolic links requires that the remote system also support them, which effectively limits their support to Windows Vista and later Windows operating systems.

In Unix Terminology,

Hard Link => 2 different files pointing to the same Inode. Parent & Child can exist on their own. Delete Parent but child can still survive.

Symbolic Link => 2 different files pointing to 2 different Inodes. Child refers to the parent path. Deleting the Parent has cascading effect(by deleting the Child too) !

File System Filter Drivers vs Device Drivers

The following subsections describe some of the differences between file system filter drivers and device drivers.

No Power Management

Because file system filter drivers are not device drivers and thus do not control hardware devices directly, they do not receive IRP_MJ_POWER requests. Instead, power IRPs are sent directly to the storage device stack. In rare circumstances, however, file system filter drivers might interfere with power management. For this reason, file system filter drivers should not register dispatch routines for IRP_MJ_POWER in theDriverEntry routine, and they should not call PoXxx routines.

No WDM

File system filter drivers cannot be Windows Driver Model (WDM) drivers. The Microsoft Windows Driver Model is only for device drivers. For more information about file system driver development in Windows Me, Windows 98, and Windows 95, see the Windows Me Driver Development Kit (DDK).

No AddDevice or StartIo

Because file system filter drivers are not device drivers and thus do not control hardware devices directly, they should not have AddDevice or StartIo routines.

Different Device Objects Created

Although file system filter drivers and device drivers both create device objects, they differ in the number and kinds of device objects that they create.

Device drivers create physical and functional device objects to represent devices. The Plug and Play (PnP) Manager builds and maintains a global device tree that contains all device objects that are created by device drivers. The device objects that file system filter drivers create are not contained in this device tree.

File system filter drivers do not create physical or functional device objects. Instead, they create control device objects and filter device objects. The control device object represents the filter driver to the system and to user-mode applications. The filter device object performs the actual work of filtering a specific file system or volume. A file system filter driver normally creates one control device object and one or more filter device objects.

Other Differences

Because file system filter drivers are not device drivers, they do not perform direct memory access (DMA).

Unlike device filter drivers, which can attach above or below a target device's function driver, file system filter drivers can attach only above a target file system driver. Thus, in device-driver terms, a file system filter driver can be only an upper filter, never a lower filter.

ref:

http://msdn.microsoft.com/en-us/library/ff548075(v=vs.85).aspx

Sample Filter Driver code -

http://read.pudn.com/downloads2/sourcecode/windows/system/4397/WinntInternalFS/filesys/src/sfsdinit.c__.htm




Full Virtualization vs Para Virtualization

There are several ways to implement virtualization. Two leading approaches are full virtualization and para-virtualization.

Full virtualization is designed to provide total abstraction of the underlying physical system and creates a complete virtual system in which the guest operating systems can execute. No modification is required in the guest OS or application; the guest OS or application is not aware of the virtualized environment so they have the capability to execute on the VM just as they would on a physical system. This approach can be advantageous because it enables complete decoupling of the software from the hardware. As a result, full virtualization can streamline the migration of applications and workloads between different physical systems. Full virtualization also helps provide complete isolation of different applications, which helps make this approach highly secure. Microsoft® Virtual Server and VMware® ESX Server™ software are examples of full virtualization.

Para-virtualization presents each VM with an abstraction of the hardware that is similar but not identical to the underlying physical hardware. Para-virtualization techniques require modifications to the guest operating systems that are running on the VMs. As a result, the guest operating systems are aware that they are executing on a VM—allowing for near-native performance. Para-virtualization methods are still being developed and thus have limitations, including several insecurities such as the guest OS cache data, unauthenticated connections, and so forth. Xen is an open source virtualization software based on paravirtualization technology.

Xen 3.0 Aerchitecture: The Intel x86 architecture provides four levels of privilege modes. These modes, or rings, are numbered 0 to 3, with 0 being the most privileged. In a non-virtualized system, the OS executes at ring 0 and the applications at ring 3. Rings 1 and 2 are typically not used. In Xen para-virtualization, the VMM executes at ring 0, the guest OS at ring 1, and the applications at ring 3. This approach helps to ensure that the VMM possesses the highest privilege, while the guest OS executes in a higher privileged mode than the applications and is isolated from the applications. Privileged instructions issued by the guest OS are verified and executed by the VMM.

Compare Vmware Esx, Microsoft Hyper-V & Citrix Xen - http://www.vmware.com/technical-resources/advantages/robust-foundation.html

Misc -

Windows Minifilter Driver - User mode to Kernel mode Communication


The filter manager supports communication between user mode and kernel mode through "communication ports". The minifilter driver controls security on the port by specifying a security descriptor to be applied to the communication port object. Communication through a communication port is not buffered, so it is faster and more efficient. A user-mode application or service can reply to messages from a minifilter driver for bidirectional communication.

ref:

User mode to Kernel mode communication (Communication Ports) - http://msdn.microsoft.com/en-us/library/ff539277(v=vs.85).aspx

User-Mode Interactions: Guidelines for Kernel-Mode Drivers(KM-UMGuide.doc) -

User to Kernel Communication Model - http://muglin.ru/messagesupport.ppt


Windows FileSystem Mini Filter Driver Development

A File system filter driver intercepts requests targeted at a file system or another file system filter driver. By intercepting the request before it reaches its intended target, the filter driver can extend or replace functionality provided by the original target of the request. Examples of file system filter drivers include anti-virus filters, backup agents, and encryption products. To develop file systems and file system filter drivers, use the IFS (Installable File System) Kit, which is provided with the Windows Driver Kit (WDK).
Filter Manager and Minifilters Basics:
The Filter Manager is a file system filter driver provided by Microsoft that simplifies the development of third-party filter drivers and solves many of the problems with the existing legacy filter driver model, such as the ability to control load order through an assigned altitude. A filter driver developed to the Filter Manager model is called a minifilter. Every minifilter driver has an assigned altitude, which is a unique identifier that determines where the minifilter is loaded.

A minifilter driver can be loaded at any time while the system is running. If a minifilter driver's INF file specifies a driver start type of SERVICE_BOOT_START, SERVICE_SYSTEM_START, or SERVICE_AUTO_START, the minifilter driver is loaded according to existing load order group definitions for file system filter drivers, to support interoperability with legacy filter drivers. While the system is running, a minifilter driver can be loaded through a service start request (sc start, net start, or the service APIs), or through an explicit load request (fltmc load, FltLoadFilter, orFilterLoad).

A minifilter driver's DriverEntry routine is called when the minifilter driver is loaded, so the minifilter driver can perform initialization that will apply to all instances of the minifilter driver. Within its DriverEntry routine, the minifilter driver calls FltRegisterFilter to register callback routines with the filter manager and FltStartFiltering to notify the filter manager that the minifilter driver is ready to start attaching to volumes and filtering I/O requests.

Minifilter driver instances are defined in the INF file used to install the minifilter driver. A minifilter driver's INF file must define a default instance, and it can define additional instances. These definitions apply across all volumes. Each instance definition includes the instance name, its altitude, and flags that indicate whether the instance can be attached automatically, manually, or both. The default instance is used to order minifilter drivers so that the filter manager calls the minifilter driver's mount and instance setup callback routines in the correct order. The default instance is also used with explicit attachment requests when the caller doesn't specify an instance name.

Excerpts:
1. CreateService() API loads FilterDriver …. It’s equivalent of FilterLoad() API
2. StartService() API calls DriverEntry() API
3. StopService() API calls the DriverUnloadCallback() registered with FltRegisterFilter() API … This is not a real DriverUnload ; it’s kind of stopping the driver to work !
4. DeleteService() API calls the FilterUnload() API & which really unloads the driver.
i.e
FilterLoad() => CreateService() + StartService()
FilterUnload() => DeleteService()
StartService() => DriverEntry()

ref:

An Introduction To Writing TDI Filter Drivers - http://www.iseclab.org/papers/Writing_TDI_Drivers.pdf

Sample TDI Driver Firewall Opensource code - http://sourceforge.net/projects/tdifw/




Developing FileSystem Mini filter drivers - http://www.osr.com/filters.pdf

Filter Driver Development Kit - http://www.osr.com/fddk.html


Writing a FileSystem Filter Driver (VC++ sample code) - http://www.codeproject.com/KB/system/fs-filter-driver-tutorial.aspx?msg=3369734&display=Mobile

Loading & Unloading TDI Device drivers - http://www.codeproject.com/KB/system/tdriver.aspx

FileSystem Mini Filter driver (which makes use of IFS kit) - http://www.microsoft.com/whdc/DevTools/IFSKit/IFSKit_About.mspx

IFSK sample code - http://msdn.microsoft.com/en-us/library/ff548099(v=VS.85).aspx

Filter Driver - http://www.microsoft.com/whdc/driver/filterdrv/default.mspx

Handling file Rename - http://read.pudn.com/downloads126/ebook/535717/OSR_docs/Rename.pdf

IRP_MJ_SET_INFORMATION irp - http://ddk.h16.ru/index.php?BID=4&PID=490

File Screening Minifilter Driver - http://technet.microsoft.com/en-us/library/dd364850(WS.10).aspx

I/O System Filter Driver - http://www.calsoftlabs.com/whitepapers/filter-driver.html

File System Filter Driver Tutorial(CodeProject) - http://www.codeproject.com/KB/system/fs-filter-driver-tutorial.asp

Usermode to Kernel mode communication (Communication Ports) - http://msdn.microsoft.com/en-us/library/ff539277(v=vs.85).aspx

Kernel Sockets(TDI Driver) - http://msdn.microsoft.com/en-us/library/ff565094(v=vs.85).aspx

Windows Driver Kit Sample code - http://msdn.microsoft.com/en-us/library/ff554118(v=VS.85).aspx

Windows Driver Kit - http://msdn.microsoft.com/en-us/library/ff557573(v=VS.85).aspx

Alternate Data Streams (ADS)

One popular method used in Windows Systems is the use of Alternate Data Streams (ADS). A relatively unknown compatibility feature of NTFS, ADS is the ability to fork file data into existing files without affecting their functionality, size, or display to traditional file browsing utilities like dir or Windows Explorer. Found in all version of NTFS, ADS capabilities where originally conceived to allow for compatibility with the Macintosh Hierarchical File System, HFS; where file information is sometimes forked into separate resources. Alternate Data Streams have come to be used legitimately by a variety of programs, including native Windows operating system to store file information such as attributes and temporary storage.

Common DOS commands like "type","echo" are used to create an ADS. These commands are used in conjunction with a redirect [>] and colon [:] to fork one file into another.

Example:

“type c:\anyfile.exe > c:\winnt\system32\calc.exe:anyfile.exe”
(or)
echo "ads stream" > calc.exe:mystream

will fork the common windows calculator program with an ADS “anyfile.exe.”

Alarmingly files with an ADS are almost impossible to detect using native file browsing techniques like command line or windows explorer. In our example, the file size of calc.exe will show as the original size of 90k regardless of the size of the ADS anyfile.exe. The only indication that the file was changed is the modification time stamp, which can be relatively innocuous.

Once injected, the ADS can be executed by using traditional commands like type, more or start or be scripted inside typical scripting languages like VB or Perl. When launched, the ADS executable will appear to run as the original file - looking undetectable to process viewers like Windows Task Manager. Using this method, it is not only possible to hide a file, but to also hide the execution of an illegitimate process.

Unfortunately, it is virtually impossible to natively protect your system against ADS hidden files if you use NTFS. The use of Alternate Data Streams is not a feature that can be disabled and currently there is no way to limit this capability against files that the user already has access to.

Creating an Alternate Data Stream:

C:\>echo Hidden text > test.txt:hidden
The file appears to be empty, though as detailed below, the metadata is intact and associated with the file:

C:\test>dir test.txt

06/01/2011 01:33 PM 0 test.txt

Viewing an Alternate Data Stream:

The metadata can be viewed by redirecting from it to more:

C:\test>more < test.txt:hidden
Hidden text

The name and content of the ADS can be anything :

C:\test>echo Arbitrary string > test.txt:arbitraryName

C:\test>more < test.txt:arbitraryName
Arbitrary string

Listing Files With Alternate Data Streams:

On Windows Vista and later, a list of alternate data streams can be obtained using 'DIR /R' :

C:\test>dir test.txt /R

06/01/2011 01:33 PM 0 test.txt
38 test.txt:arbitraryName:$DATA
28 test.txt:hidden:$DATA

On earlier operating systems, the SysInternals utility Streams can be used:

C:\test>c:\tools\SysInternals\streams.exe test.txt

Streams v1.56 - Enumerate alternate NTFS data streams
Copyright (C) 1999-2007 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\test\test.txt:
:arbitraryName:$DATA 38
:hidden:$DATA 28

ref: