时间:2008-05-10 22:50:37   来源:论坛整理  作者:  编辑:chinaitzhe

在winnt内核的系统，在ring3情况，如何不用createfile等函数读写磁盘，使用int13我只调出在dos下读写磁盘
提供思路，参考资料或核心代码都可以
先谢谢各位
网友回复:自己写个 createfile 函数 被
网友回复:操作系统提供的底层服务不用.难道想自己写代码控制硬件.
网友回复:用native api啊
网友回复:反正int 13你就不要指望了。
网友回复:你的原始需求是什么，为什么会有这种要求呢？
网友回复:转个文章

CreateFile, NtCtreateFile,... 这些API都是使用了INT 2E中断...

Logging Kernel System Calls
We also wanted to log kernel system calls; that is, system calls made via a transition from user mode to kernel mode. Our approach comes from the Regmon application, available from the SysInternals Web site. The idea is to find the service table list (an in-memory array of system call function pointers indexed by system call number), and replace the function pointers with pointers to special logging functions. The trickiest part is determining which system call number corresponds to each system call.
User-level code makes a kernel system call by putting the system call number in EAX, putting parameters in other registers, then executing the INT 2E instruction. An application usually does this indirectly. For example, a call to WaitForSingleObject in KERNEL32.DLL will eventually call NtWaitForSingleObject in NTDLL.DLL, which performs the register manipulation and the call to INT 2E. Kernel-mode code usually does it a little differently, by calling routines with the prefix Zw exported by NTOSKRNL.EXE. Each Zw routine, such as ZwWaitForSingleObject, handles the register manipulation and the call to INT 2E.
Regmon's authors noted that the first thing these Zw functions do is load the system call number into EAX. Thus kernel-mode code can find the system call number in bytes 2-5 of each Zw function. One caveat is that in a debug version of the driver, each Zw function is only a wrapper that calls the "real" Zw function. It turned out that we didn't have to worry about this because, for reasons we'll now explain, we wound up not reading the Zw functions from the memory image of our running driver.
We found that, unfortunately, NTOSKRNL.EXE doesn't export all the system calls we wanted to log. Some, such as ZwSignalAndWaitForSingleObject, are only exported by NTDLL.DLL, but we couldn't link our driver with NTDLL.DLL. (Regmon doesn't have this problem since it only hooks calls exported by NTOSKRNL.EXE.) So we had our tracer find the Zw function bodies by reading and parsing the NTDLL.DLL disk file. Our technique is based on an understanding of the well-documented portable executable (PE) file format.
An important part of parsing a PE format file is translating virtual addresses into file positions. Many structures in the file refer to other structures in the file using their relative virtual addresses (RVAs). A structure's RVA describes where it will be in memory when the file is mapped. Its virtual address will be its RVA plus the base address where the file is mapped in memory. The problem is that we need to know where in the file those structures are. To translate from RVAs to file positions, we need the section header information. This is an array of IMAGE_SECTION_HEADER structures, each of which has the absolute file position, length, and RVA of a section. Using this information, we can figure out which section contains a given RVA, and from that we can determine the file position for that address. Figure 10 shows how to find these section header structures in the file.


Figure 10 PE File Format for Executable Files

Once we can translate from RVAs to file positions, we can find the names and bodies of all the exported functions using the information in Figure 10. This lets us find where the Zw function bodies are and the contents of their first few bytes.
As mentioned earlier, we hook the system calls for opening files so our file system filter driver can attach a device to each file system. Unfortunately, the DDK doesn't document one of these system calls, ZwOpenFile. The book Windows NT File System Internals, by Rajeev Nagar (O'Reilly & Associates, 1997) does document this function, so we were able to use its parameters to determine which file system to filter.
网友回复:to Chiyer
win的主要的文件系统有fat32,ntfs。这些文件系统都研究了一下。现在的需求是通过直接对磁盘写01的方式实现fat32和ntfs的类似功能,createfile这些函数有些地方有限制
网友回复:欢迎更多的人讨论这个问题，先谢谢
网友回复:CreateFile基本上可以算是Windows一切IO操作必须调用的函数。

不过你可以直接用CreateFile打开\\.\C: ...
网友回复: 不懂你想满足什么需求？？通过正常途径的话，应用程序和驱动交互只能通过CreateFile，绕过这一个似乎也没有非凡的意义。。。
网友回复:不懂 路过
网友回复:这问题应该发到VC/MFC板块。
LZ应该把问题描述为：“应用程序如何读写磁盘扇区”，因为NT内核的操作系统中所有设备都是File，所有I/O都必须打开File。
读写扇区的方法是：先用CreateFile打开你要读写的设备，一般要完全共享，然后用ReadFile来读，WriteFile来写，每次读写必须是整扇区，最后CloseHandle关闭设备。CreateFile中的文件名称参数要给设备路径，例如D:盘为"\\\\.\\D:"，物理硬盘0为"\\\\.\\PhysicalDrive0"。
网友回复:to :cnzdgs
quote cnzdgs:
读写扇区的方法是：先用CreateFile打开你要读写的设备，一般要完全共享，然后用ReadFile来读，WriteFile来写，每次读写必须是整扇区，最后CloseHandle关闭设备。CreateFile中的文件名称参数要给设备路径，例如D:盘为"\\\\.\\D:"，物理硬盘0为"\\\\.\\PhysicalDrive0"。

用createfile的方法已经实现了，现在问题是它不能满足需求，比如进入系统后，无法使用WriteFile改写mbr，还有其他的类似的问题

网友回复:改写MBR需要打开物理硬盘，另外，程序要打开设备需要具有治理员权限。你碰到的具体错误是什么？
网友回复:

引用 14 楼 cnzdgs 的回复:

改写MBR需要打开物理硬盘，另外，程序要打开设备需要具有治理员权限。你碰到的具体错误是什么？

打开物理硬盘，administrator权限，修改0扇区没有返回错误，修改后和原来一样，根本没有修改到
但修改其他的扇区是可以的，还有类似的问题
网友回复:什么操作系统？是不是有保护类的软件？
网友回复:

引用 16 楼 cnzdgs 的回复:

什么操作系统？是不是有保护类的软件？

win2003，没有保护软件

其实这些细节是没有关系的，最终还是要用native api

谢谢cnzdgs,欢迎更多的人讨论

网友回复:你写完之后立即读回来，看看是不是写进去了。我估计是你写完之后系统又重新写了一次，把你写入的数据覆盖了。假如有保护类软件，它可以禁止你写MBR或者自动还原MBR。