就找找国内的书看吧，国外的会计书籍对国内也不适用，会计准则不一样，水土不服。

@lun10439547 毕竟都是蚊子肉，小钱没必要太计较。都是差不多的。货币基金之间能有多少差别？为了表面利率来回折腾并不划算，不想存余额宝随便找家其他的货币基金就行了。

那么点利率差别还不够你来回折腾的。
锱铢必较是会吃亏的。

@EterNalReality 后台各种迅雷，P2P 视频软件，或者人家根本就是在挂 PT

为什么不用真实姓名？

@acess
file system filter drivers 有好几种。
微软的文档表示，legacy file system filter drivers can ’ t attach to direct access (DAX) volumes。
我仔细翻阅了一下文档看来是我有点想当然了，File ​ System ​ Filter ​ Drivers 里面要看你把驱动 attach 到什么地方。
如果只把 Filter Device Object Attach 到 File System，那么就只能拦截 IRP_MJ_CREATE 之类的不能拦截 IRP_MJ_WRITE。
如果 Filter Device Object Attach 到 Volume 上，那么就可以拦截 IRP_MJ_CREATE。
File System Minifilter Driver 也是类似的情况，看开发者怎么使用了
我表示没有调试过，IRP_MJ_WRITE 的具体拦截情况，看文档应该是有办法拦的，但是实际上我会觉得拦截 IRP_MJ_CREATE 这样的请求意义不是很大，绝大多数的程序不需要直接进行底层磁盘写入，如果要驱动来判断直接写入扇区是不是应该允许未免是个巨大的工程。一般不需要在这一步进行拦截，如果只是为了防止写入，拦截 IRP_MJ_CREATE 就足够了。

@acess
调用链方面中间有些省略，不过大致上是这样的。
在 ntdll.dll 中 Nt*函数和 Zw*函数功能是相同的, Nt*函数是 Zw*函数的别名.
ntoskrnl.exe 中 ZwCreateFile 会最终调用到 NtCreateFile
在你看到的调用栈里
NtCreateFile 这里使用 IopCreateFile，ObOpenObjectByNameEx 从名字上就能看出来，目的是把名字转换成 Object 对象，在这转换过程中触发了 IRP_MJ_CREATE

只能自己设置小一点的 TTL 减少缓存的时间。
不过依然得等缓存失效才行。

接楼上，做个更正 NtCreateFile 是调用 IoCreateFile，由 IoCreateFile 来发起 IRP 的。这个是我疏忽了。

@acess
应该是可以拦截到的
从调用链就可以看出来。
CreateFileW （\\.\PhysicalDrive0 ）—》 ZwCreateFile->NtCreateFile
NtCreateFile 会向驱动层的最上级驱动发起 IRP_MJ_CREATE，然后 IRP_MJ_CREATE 这个 IRP 会依次按照顺序发送到下级驱动中，直到最后发送到磁盘驱动。
File System Filter Drivers 想拦截拦截文件的打开就一定会在这个调用链中，所以 File System Filter Drivers 有能力拒绝这样的行为。
而对于直接向磁盘写入这种行为来说。
WriteFile-》 ZwWriteFile-》 NtWriteFile
NtWriteFile 产生的 IRP_MJ_WRITE 不会交给 File System Filter Drivers，因为要写入的并不是一个文件系统的对象，所以 File System Filter Drivers 并不会接收到这个 IRP_MJ_WRITE。

@acess
这完全取决于开发者希望产生什么样的效果，比如我要开发一个文件透明加密的驱动，那么我就没有必要防程序直接读取或者写入磁盘的这种行为，因为不会影响到我的程序功能。
一般安全产品在这方面的处理方法也是简单粗暴的，可能有些 HIPS 会直接弹个窗，警告一下，如果允许了剩下的事情 HIPS 也不管。
这个是开发难度与产品功能之间做出的妥协，安全产品当然也可以直接接管更加底层的 IRP 请求，但是那又会面对一堆乱七八糟的问题，比如稳定性方面的问题。

@acess
@ahhui
我解释一下 open \\.\PhysicalDrive0 这种行为。
对于 File System Filter Drivers 来说，open \\.\PhysicalDrive0 这样的行为 Filter Drivers 会收到一个 IRP_MJ_CREATE 的请求，如果 Filter Driver 在针对这个请求直接拒绝，那么直接打开设备的操作明显会失败。这里不存在所谓绕过这么一说。只是取决于驱动怎么处理直接访问设备的请求，如果驱动对此没有拒绝，后续的操作因为直接是针对设备块的读写（其实就是直接向磁盘驱动发起了 IRP ）并不涉及文件系统，所以 File System Filter Drivers 无法拦截后续的读写操作，这看起来就像是，绕过了，但是实际上只是驱动不想粗暴的拒绝而已。
如果要拦截底层的磁盘访问的 IRP 请求当然也是有办法的，不过这又是另外一个话题了。

@RE 不会

@acess 吊销的问题是微软实现方面的问题。这一点我了解的不多，不过微软完全有能力随时发布更新来解决这些问题。
DSE 确实带来了很多问题，也是无可否认的，个人几乎很难在独立开发驱动。不过微软这方面的要求也不是不能理解，因为大多数蓝屏的问题并不是 Windows 自身的问题导致的，几乎都是第三方驱动形成的。在驱动层面开发是很麻烦的事情，普通的 app 如果犯了一个除 0 的错误，也就只是收到一个程序崩溃的提醒，可是驱动层面上那就直接蓝屏了。（其实某种层面上蓝屏是相当好的保护措施）通过 DSE 这样的手段来限制一些开发者这大概才是微软的目的所在。至于未来版本的支持。。内核上很多地方是未公开的，每一个版本都可能会有些许不同，而驱动们为了达到各种各样的目的可能又必须依赖于这些未公开的地方，所以驱动上兼容各种版本是相对比较困难的。微软其实就不想让开发者动内核，什么 hook SSDT 这种事情根本就不是什么正规手段，所以才有了 PatchGuard 这种东西来阻止对内核的修改。

@hx1997 JOB 和 AppContainer 可能后续会加入。有这方面的计划，不过嘛级别可能比较靠后。

@acess 这种都是互相权衡的，毕竟还是要以正常使用为第一前提。数字证书有有效期，但是数字证书签出来的签名不能说因为数字证书有效期过了就不认。一张数字证书的有效期少则 1 年多则 3 年 5 年，如果因为数字证书过期就拒绝那么也就意味着你系统中的所有驱动必须每隔几个月就更新一次，否则可能会无法启动。至于签名出来的时间戳，纯粹只是用来表示发布时间的，并没有什么特别的意义。
这个过程和签名一样，一个人签署的合同，不能说因为签署人挂了这份合同就是无效的。
获取数字证书始终是有成本的，这一点也是毋庸置疑的。

namesilo +1

@acess 微软为什么要阻止天翼客户端加载驱动？微软不是神，不能包办一切。。。不管一个驱动是好还是坏，如果符合要求就允许加载是没有问题的，这方面不要指望太多。

@acess
微软一直都有做根证书更新这件事情，从未停止过。
进入了 RING0 层，在驱动级别的对抗是永无止境的，事实上也没办法阻止驱动干点什么事情，最根本的还是阻止加载驱动。

@hx1997
权限始终是用来保障控制的一种手段，对于无法覆盖到的地方自然是没有办法，但是也不应该用脆弱来形容。
对于窗口确实没有太多办法，毕竟权限不是主要用于处理窗口方面的问题的。
至于其他的攻击面，其实是和使用方法有关系。如果能做到更为细化的权限控制，那么这些问题其实并非不能解决，比如勒索软件，如果创建一个用户拒绝访问文档有关的目录，并且使用该权限来运行勒索软件的话，那么很显然勒索软件尝试加密的操作将会直接失败。（当然如果你一定要谈使用不支持 ACL 的其他磁盘格式那也是没办法的）
注册表的问题也是一样。

我开发 wesuex 这个产品的目的就是希望能更加细化一些权限方面的管理，通过这个产品我们可以让不同的程序运行在不同的权限或者用户下，这样我们就可以拒绝不必要的权限加以限制。比如创建一个拒绝访问 D 盘的用户，那么用这个用户来运行一个程序，这个程序就不能扫描到 D 盘的隐私内容了。这个是我理想中的用法，当然虽然现在做的不好，但是还是可以努力一下。