【转】内核无HOOK文件防删除,可以过冰刃,xuetr,easydelete

本来是打算写暴力删除文件的程序的,结果意外发现,只需要在内核发送irp打开一个文件,之后不关闭Object,就拒绝其他程序访问了,easydelete这个工具还是比较强的,不过也不能删除,关键是不挂钩任何函数,不修该系统内核,看属性的时候只能看到一个常规,其它的什么都看不到,当然了360(7.0)版本的文件粉碎机也是搞不定的,其它工具没试 ,大家可以自己试试玩玩,打开文件使用炉子的代码:

代码:

NTSTATUS
IoCompletionRoutine(
      IN PDEVICE_OBJECT DeviceObject,
      IN PIRP Irp,
      IN PVOID Context)
{
*Irp->UserIosb = Irp->IoStatus;
if (Irp->UserEvent)
   KeSetEvent(Irp->UserEvent, IO_NO_INCREMENT, 0);
if (Irp->MdlAddress)
{
   IoFreeMdl(Irp->MdlAddress);
   Irp->MdlAddress = NULL;
}
IoFreeIrp(Irp);
return STATUS_MORE_PROCESSING_REQUIRED;
}

NTSTATUS
IrpCreateFile(
     OUT PFILE_OBJECT *FileObject,
     IN ACCESS_MASK DesiredAccess,
     IN PUNICODE_STRING FilePath,
     OUT PIO_STATUS_BLOCK IoStatusBlock,
     IN PLARGE_INTEGER AllocationSize OPTIONAL,
     IN ULONG FileAttributes,
     IN ULONG ShareAccess,
     IN ULONG CreateDisposition,
     IN ULONG CreateOptions,
     IN PVOID EaBuffer OPTIONAL,
     IN ULONG EaLength)
{
NTSTATUS ntStatus;

HANDLE hFile;
PFILE_OBJECT pFile, _FileObject;
UNICODE_STRING UniDeviceNameString;
OBJECT_ATTRIBUTES ObjectAttributes;
PDEVICE_OBJECT DeviceObject, RealDevice;

PIRP Irp;
KEVENT kEvent;
PIO_STACK_LOCATION IrpSp;
ACCESS_STATE AccessState;
AUX_ACCESS_DATA AuxData;
IO_SECURITY_CONTEXT SecurityContext;

WCHAR DeviceNameString[]=L"\\DosDevices\\*:\\";

if(FilePath->Length < 6)
   return STATUS_INVALID_PARAMETER;
// \\??\c:\xxxx

DeviceNameString[12]=FilePath->Buffer[0];

RtlInitUnicodeString( &UniDeviceNameString, DeviceNameString);
InitializeObjectAttributes(&ObjectAttributes, &UniDeviceNameString, OBJ_KERNEL_HANDLE, NULL, NULL);

ntStatus = IoCreateFile(&hFile,
   GENERIC_READ|SYNCHRONIZE,
   &ObjectAttributes,
   IoStatusBlock,
   NULL,
   FILE_ATTRIBUTE_NORMAL,
   FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE,
   FILE_OPEN,
   FILE_SYNCHRONOUS_IO_NONALERT,
   NULL,
   0,
   CreateFileTypeNone,
   NULL,
   IO_NO_PARAMETER_CHECKING);

if(!NT_SUCCESS(ntStatus))
{
   KdPrint(("IrpCreateFile: IoCreateFile 0x%X.\n",ntStatus));
   return ntStatus;
}
        RecoverOneKernelRoutine("ObReferenceObjectByHandle");
ntStatus = ObReferenceObjectByHandle(hFile,
   FILE_READ_ACCESS, // ACCESS_MASK
   *IoFileObjectType,
   KernelMode,
   (PVOID*)&pFile,
   0);

NtClose(hFile);

if(!NT_SUCCESS(ntStatus))
{
   KdPrint(("IrpCreateFile: ObReferenceObjectByHandle 0x%X.\n",ntStatus));
   return ntStatus;
}

DeviceObject = pFile->Vpb->DeviceObject;
RealDevice = pFile->Vpb->RealDevice;
ObDereferenceObject(pFile);

InitializeObjectAttributes(&ObjectAttributes, NULL, OBJ_CASE_INSENSITIVE, 0, NULL);

ntStatus = ObCreateObject(KernelMode,
   *IoFileObjectType,
   &ObjectAttributes,
   KernelMode,
   NULL,
   sizeof(FILE_OBJECT),
   0,
   0,
   (PVOID*)&_FileObject);

if(!NT_SUCCESS(ntStatus))
{
   KdPrint(("IrpCreateFile: ObCreateObject 0x%X.\n",ntStatus));
   return ntStatus;
}

Irp = IoAllocateIrp(DeviceObject->StackSize, FALSE);
if(Irp == NULL)
{
   KdPrint(("IrpCreateFile: IoAllocateIrp 0x%X.\n",ntStatus));
   ObDereferenceObject(_FileObject);
   return STATUS_INSUFFICIENT_RESOURCES;
}

KeInitializeEvent(&kEvent, SynchronizationEvent, FALSE);

RtlZeroMemory(_FileObject, sizeof(FILE_OBJECT));
_FileObject->Type = IO_TYPE_FILE;
_FileObject->Size = sizeof(FILE_OBJECT);
_FileObject->DeviceObject = RealDevice;
_FileObject->Flags = FO_SYNCHRONOUS_IO;
////////\\??\c:\xxxxx
RtlInitUnicodeString( &_FileObject->FileName, &FilePath->Buffer[2]);
KdPrint(("准备打开文件:%ws\n",_FileObject->FileName.Buffer));
KeInitializeEvent(&_FileObject->Lock, SynchronizationEvent, FALSE);
KeInitializeEvent(&_FileObject->Event, NotificationEvent, FALSE);

RtlZeroMemory(&AuxData, sizeof(AUX_ACCESS_DATA));
ntStatus = SeCreateAccessState( &AccessState,
   &AuxData,
   DesiredAccess,
   IoGetFileObjectGenericMapping());

if (!NT_SUCCESS(ntStatus))
{
   KdPrint((" IrpCreateFile: SeCreateAccessState 0x%X.\n",ntStatus));
   IoFreeIrp(Irp);
   ObDereferenceObject(_FileObject);
   return ntStatus;
}

SecurityContext.SecurityQos = NULL;
SecurityContext.AccessState = &AccessState;
SecurityContext.DesiredAccess = DesiredAccess;
SecurityContext.FullCreateOptions = 0;

Irp->MdlAddress = NULL;
Irp->AssociatedIrp.SystemBuffer = EaBuffer;
Irp->Flags = IRP_CREATE_OPERATION|IRP_SYNCHRONOUS_API;
Irp->RequestorMode = KernelMode;
Irp->UserIosb = IoStatusBlock;
Irp->UserEvent = &kEvent;
Irp->PendingReturned = FALSE;
Irp->Cancel = FALSE;
Irp->CancelRoutine = NULL;
Irp->Tail.Overlay.Thread = PsGetCurrentThread();
Irp->Tail.Overlay.AuxiliaryBuffer = NULL;
Irp->Tail.Overlay.OriginalFileObject = _FileObject;

IrpSp = IoGetNextIrpStackLocation(Irp);
IrpSp->MajorFunction = IRP_MJ_CREATE;
IrpSp->DeviceObject = DeviceObject;
IrpSp->FileObject = _FileObject;
IrpSp->Parameters.Create.SecurityContext = &SecurityContext;
IrpSp->Parameters.Create.Options = (CreateDisposition << 24) | CreateOptions;
IrpSp->Parameters.Create.FileAttributes = (USHORT)FileAttributes;
IrpSp->Parameters.Create.ShareAccess = (USHORT)ShareAccess;
IrpSp->Parameters.Create.EaLength = EaLength;

IoSetCompletionRoutine(Irp, IoCompletionRoutine, 0, TRUE, TRUE, TRUE);
//add
RecoverIopfCompleteRequest();
ntStatus = IofCallDriverEx(DeviceObject, Irp);
if(ntStatus == STATUS_PENDING)
   KeWaitForSingleObject(&kEvent, Executive, KernelMode, TRUE, 0);

ntStatus = IoStatusBlock->Status;

if(!NT_SUCCESS(ntStatus))
{
   KdPrint(("IrpCreateFile: IoCallDriver 0x%X.\n",ntStatus));
   _FileObject->DeviceObject = NULL;
   ObDereferenceObject(_FileObject);
}
else
{
   InterlockedIncrement((volatile LONG *)&_FileObject->DeviceObject->ReferenceCount);
   if (_FileObject->Vpb)
    InterlockedIncrement((volatile LONG *)&_FileObject->Vpb->ReferenceCount);
   *FileObject = _FileObject;
}

return ntStatus;
}
//UNICODE_STRING Name;
//IO_STATUS_BLOCK IoBlock;
//RtlInitUnicodeString(&Name,L"C:\\test1.exe");
//Status=IrpCreateFile(&FileObj,GENERIC_READ|DELETE,&Name,&IoBlock,0,FILE_ATTRIBUTE_NORMAL,FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE,FILE_OPEN,0,0,0);

上面是测试代码,打开之后不ObDereferenceObject,直接返回,之后文件就被保护起来了

时间: 2024-08-12 18:50:00

【转】内核无HOOK文件防删除,可以过冰刃,xuetr,easydelete的相关文章

Rsync+inotify实现文件防篡改

Rsync+inotify实现文件防篡改 设计思路 A服务器作为防篡改源服务器,也就是正常的文件服务器 B服务器作为对外开放,也就是WEB目录服务器 同时将A服务器作为网站后台更新内容的服务器 在B服务器上配置好rsync + inotify 触发式实时同步 图例如下: 配置服务器A防篡改系统 安装rsync yum install rsync 配置rsync文件rsyncd.conf 服务器A(防篡改系统rsync配置) vi /etc/rsyncd.conf [test] uid = roo

关于在服务器上删除文件及删除数据库时的操作问题

1.在服务器上C盘以外的右击delete相当于点击Shift+delete,会将文件彻底删除,无法通过回收站找回:可直接点键盘上的Delete进行删除操作,可通过回收站找回 2.在SQL Server Management Studio上,右击数据库名称Delete会将数据库文件彻底删除,很难恢复 正确操作为: 右击数据库名称,选Tasks,选Take offonline,将数据库离线:如果过一天后无客户投诉,说明该数据库基本处于不使用状态:若有人投诉,该数据库还在使用,赶紧将数据库恢复在线状态

boot目录下文件被删除的简单还原方法

实验环境为boot文件被破坏,所以我先将boot下的文件全部删除 2.删除后我们重启可以看一下出现无法启动的错误,因为开机所用的 文件与boot下的文件都不存在,所以无法正常开机 3.要使得机器可以正常运行,则需要将最基本的开机所需选项恢复,其中包括内核系统,initmafs,与grub文件,首先进入救援模式,利用makeinitrd修复ininmafs 4.这时候我们进入根下的boot查看可以看见init文件已经修复 5.然后就需要修复所需要的vmlinuz,这里有两种方法,第一种是直接可以从

纯 PHP 代码最好在文件末尾删除 PHP 结束标记

如果文件内容是纯 PHP 代码,最好在文件末尾删除 PHP 结束标记.这可以避免在 PHP 结束标记之后万一意外加入了空格或者换行符,会导致 PHP 开始输出这些空白,而脚本中此时并无输出的意图. <?php echo "Hello world"; // ... more code echo "Last statement"; // 脚本至此结束,并无 PHP 结束标记 http://php.net/manual/zh/language.basic-synta

Git学习笔记(3)——撤销修改和文件的删除

本文主要记录了git中,错误的撤销和文件的删除. 撤销修改 这里有3中情况 改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令git checkout -- file. 不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令git reset HEAD file,就回到了1,第二步,按照1操作. 已经提交了不合适的修改到版本库时,想要撤销本次提交,可以版本回退,不过前提是没有推送到远程库. //第一种撤销:工作区撤销 [email protected]:~

WCF无.SVC文件服务激活,及不添加服务引用调用WCF

一,新建WCF服务引用程序 1,删除.svc文件,全部删除. 2,新建 IService 类 namespace TestWcf { [ServiceContract] public interface IService { [OperationContract] string DoWork(); } } 3,实现接口类 Service类 namespace TestWcf { public class Service : IService { public string DoWork() {

Asp.Net 无刷新文件上传并显示进度条的实现方法及思路

相信通过Asp.Net的服务器控件上传文件在简单不过了,通过AjaxToolkit控件实现上传进度也不是什么难事,为什么还要自己辛辛苦苦来 实现呢?我并不否认"拿来主义",只是我个人更喜欢凡是求个所以然.本篇将阐述通过Html,IHttpHandler和 IHttpAsyncHandler实现文件上传和上传进度的原理,希望对你有多帮助. 效果图: 本文涉及到的知识点:1.前台用到Html,Ajax,JQuery,JQuery UI 2.后台用到一般处理程序(IHttpHandler)和

运维实战案例之文件已删除但空间不释放问题解析

1.错误现象 运维的监控系统发来通知,报告一台服务器空间满了,登陆服务器查看,根分区确实没有空间了,如下图所示: 这里首先说明一下服务器的一些删除策略,由于Linux没有回收站功能,我们的线上服务器所有要删除的文件都会首先移动到系统/tmp目录下,然后定期清除/tmp目录下的数据.这个策略本身没有问题,但是通过检查发现这台服务器的系统分区中并没有单独划分/tmp分区,这样/tmp下的数据其实是占用了根分区的空间.既然找到了问题,那么删除/tmp目录下一些大数据即可,执行如下命令,检查/tmp下最

Mac下关于——你不能拷贝项目“”,因为它的名称太长或包括的字符在目的宗卷上无效。文件的删除

内容是google的,测试有效,因为用revel打包的东西删除以后有这个循环bug Mac下关于——你不能拷贝项目“”,因为它的名称太长或包括的字符在目的宗卷上无效.文件的删除 关于这个问题我找到的一些资料, 可以通过如下方法删除 1.打开 终端 应用程序. 2.键入: sudo rm -rf 注意:在“-rf”后键入一个空格.没有空格该命令将不能执行.在步骤 6 之前请都不要按下 Return 键. 3.打开您的“废纸篓”. 4.从“编辑”菜单中选择“全选”. 5.将“废纸篓”中的所有内容都拖