有了下面这个Windows7操作系统文件夹的奥妙教程,不懂Windows7操作系统文件夹的奥妙的也能装懂了,赶紧get起来装逼一下吧!
【 tulaoshi.com - windows 7 】
如果你安装了时下最流行的微软Windows 7操作系统,是否会觉得微软Windows 7操作系统下的winsxs文件夹庞大的吓人,有些人就装X说Windows 7操作系统占空间了,本文为你详解。
步骤/方法
关于最近的新的微软安全,稳定着称的操作系统
我们知道,查看一个目录有多大的最快捷的方法就是看看资源管理器文件夹的属性,但是我今天要说的是:如果你用这个方法去看 Windows Viswww.Tulaoshi.comta / Windows 7 系统的目录,你会被你的眼睛所欺骗,因为,Microsoft 同学在 Windows Vista/ Windows 7 里面大量使用了NTFS文件系统的特性之一的:硬连接(Hard Link)来实现WinSxS机制!
用过的人都知道,要安装 Windows Vista / Windows 7系统,那么系统分区必须是NTFS文件系统。原因有以下一些:
系统文件保护所需
各种安全保护机制,如MIC所需
WinSxS 所需
关于最后一点的 WinSxS 所需,所以NTFS这是Windows Vista / Windows 7 系统需要的一个条件,因为只有在 NTFS 文件系统上面,才能实现硬连接机制,也才能达到优化Windows目录占用磁盘空间的目的。
关于微软系统的硬链接
硬链接是什么呢?简单的说,就是一种针对文件的特殊快捷方式,只不过这种快捷方式的实现和一般的快捷方式不一样。
硬连接是NTFS文件系统特有的属性之一,在Linux下面,也有类似的机制。硬连接适用于在同一个卷的文件级别,硬连接是不能跨卷的。
硬链接,系统属性测试
(本文来源于图老师网站,更多请访问http://www.tulaoshi.com)Windows Vista / Windows 7自带了创建硬连接的命令:mklink.exe,利用这个命令,我们可以给指定的文件创建硬连接:
下面的命令将在link.txt和source.txt之间建立硬连接关系
C:UsershoiiDesktop》mklink /h link.txt gb.txt
为 link.txt 《《===》》 gb.txt 创建了硬链接
注意上面的例子:link.txt本是一个不存在的文件,但是当执行完mklink命令以后,link.txt文件也就被创建了。其实,link.txt是一个虚假的文件,它是在文件系统层面上对gb.txt文件的一个映射,而link.txt是不占硬盘空间的。
关于硬盘空间的占用问题,可以这样测试:
1、给硬盘划分一个新分区,空间只有2GB
2、在这个分区的test目录里面新建了一个1.9GB大小的文件,此时剩余空间是0.1GB
3、用mklink命令给这个1.9GB大小的文件建立了一个硬连接
4、检查这个分区的剩余空间,还是0.1GB,但是如果用资源管理器看test目录的属性,会发现有2个文件,总大小是3.8GB(整个分区才2GB,能够容纳3.8GB大小的文件吗?显然不可能了)
还是针对上述的例子,如果我们把原始的文件 gb.txt 删除以后,link.txt文件还是会继续存在的,且内容就是source.txt的文件内容。也就是说,我们删除gb.txt,实际上删除的仅仅是这种连接关系,文件本身还是没有被操作的。
关于硬连接,最后一个需要介绍的内容是:当硬连接建立以后,硬连接双方任何一个对象被修改,都会造成对应的连接对象被修改。例如上面的例子:如果修改了 link.txt,那么gb.txt文件也会同步被修改,反之亦然。这一点和SHELL层面的快捷方式不同,SHELL层面的快捷方式文件LNK仅仅是一个指示关系,修改LNK文件并不影响LNK文件指向的对象,修改LNK文件指向的对象也不会影响LNK文件。
WIN新系统下的硬链接情况和使用这种技术的原因
好了,基本知识介绍完了,我们来实际看看Windows目录里面对于硬连接的使用情况吧。
经常看到有人抱怨,WindowsWinSxS目录占用了太多的空间,里面经常发现有同名的文件,而且这些同名的文件在 WindowsSystem32 目录下面也有存在,这是为啥呢?其实这就是硬连接导致的。
Microsoft为啥这么麻烦搞这个呢?其实这样对系统的稳定性的增加非常有好处
同样的文件,只需要维护硬连接关系,不需要进行多重的拷贝,这样可以节省硬盘空间
如果涉及文件更新,只需要先在WinSxS 目录里面下载好一个新版本,然后修改 WindowsSystem32 下面同名文件的硬连接关系,从旧版本的硬连接指向新版本的硬连接,这样就能够快速的完成文件的更新工作,而不需要进行文件的复制,速度也会快不少
补丁卸载也是一样的,只需要把硬连接指向改为旧版本就可以了,没有文件替换的问题。而且建立了硬连接关系的文件之间的修改是同步的,因此只要有一方被修改了,另一方也会得到修改
真相大白
说了这么多,那么如何知道 Windows 目录的真实大小呢?有很多小工具可以使用,也可以在DOS下的第三方工具来测试,有兴趣的童鞋就自己测试吧,我的测试结果如下:
对于纯净的系统测试结果如下,共有文件65088个,其中,真实的文件有48022个,其他17066个文件都是硬连接文件。真实的文件占用了 14981682 KB的硬盘空间,而如果你用资源管理器看的话,那么会提示说占用了 18244902 KB的硬盘空间。其实呢?, Windowssystem32 目录下的大多数文件都和 WinSxS 目录建立了硬连接关系~~都多算了一次。
Windows 7操作系统winsxs那么多空间占着。其实没那么多。那不过是文件同步映射导致的结果。
基本原理
Windows7 以后 Winlogon 进程是动态的,有用户登录就会创建一个 Winlogon 进程,因此系统中完全 可能存在多个登录进程,注销后 Winlogon 进程也会随之结束。
Windbg 断点 NtCreateUserProcess 观察 Windows7 启动流程:
我整理的基本进程树如下:
smss.exe autochk.exe
smss.exe 00000000 0000003c //session 0
Csrss.exe
Wininit.exe
Services.exe
开机自启动服务进程
Lsass.exe
Lsm.exe
smss.exe 00000001 0000003c //session 1
Csrss.exe
Winlogon.exe
LogonUI.exe
LogonUI.exe 负责用户认证界面,Windows7 以后不再使用 msgina.dll,而是使用多个进程配合,完成用户 认证过程,大致过程为 1、Winlogon 启动 LogonUI 等待用户输入凭证 2、Winlogon 通过 ALPC 通知 Lsass用户登录 3、Lsass 依次查询认证模块4、Lsass 返回认证结果。框图如下
调试过程
必须要吐槽下,windows7 下 windbg 内核调试应用程序经常断不下了,害我浪费了很多功夫~~现总结 了一个稳当可靠的办法:
1、!process 0 0 查看目标进程的基本情况,主要是 Cid。
2、bp nt!KiFastCallEntry "j poi(@$teb+20) = 0x1a0'';'gc'" 把 1a0 替换成实际的 Cid 即可。
3、等断点命中后,bp winlogon!XXXXX
4、.reload /user 下,bl 看一下,确保函数解析成地址。
首先看 Winlogon 和 LogonUI 之间的交互,LogonUI.exe 就是一个壳,类似 svchost,真正的功能是通 过 authui.dll模块完成的,从《Windows Internals5》介绍,winlogon 是通过 ALPC 的东西同 Lsass 通信的,但是 LogonUI 没怎么讲,我估计八成也是一样的,应该就是 RPC 调用。
RPC 调用分服务端和客户端,客户端最终 RPCRT4!NdrClientCall2 执行调用,而服务端最终会执行
RPCRT4!Invoke执行具体的函数。
我们断点 winlogon!NdrClientCall2观察下,随便输入个密码,命中:
这里我们发现 winlogon 的确使用了 RPC 调用来执行进程交互,注意这个函数名是 WluiDisplayStatus,其 实很明确的告诉我们 winlogonUIDisplayStatus,那么该 RPC 最终在哪里被执行呢?很显然是在 authui.dll 下断点 RPCRT4!Invoke 命中,而后单步跑一下,如图:
直接从 IDA 里面翻了下 authui.dll注册 RPC 服务
从
直接把所有的 RPC 接口函数 DUMP 出来,如下:
其中 WluirRequestCredentials很惹人关注,对应的 winlogon!WluirRequestCredentials函数如下:
Winlogon 同 logonUI 的 authui.dll 中通过一一对应的 RPC 函数完成接口调用,下面是一次错误密码测 试过程时,依次命中的调用情况:
序号函数名描述
1
winlogon!WluiRequestCredentials请求用户输入凭证,注:该函数是阻塞函数,会一直等待直到用户确认登录才返回。
2
winlogon!WluiDisplayStatus显示状态?未细究。
3
winlogon!WluiReportResult通报结果。
4
winlogon!WluiDisplayRequestCredentialsError显示登录错误提示。
我们发现基本上 LogonUI 进程没干啥活,所以的动作都是 winlogon 的 WluiXXXXXX 接口消息驱动的,
IDA 里面会发现大量的 DirectUI 界面代码。
Winlogon 使用状态机来维护整个登录过程中的各种情况处理,通过 Winlogon!StateMachineSetSignal
来完成状态切换,整个状态定义 DUMP 如下:
例如:断点 Winlogon!StateMachineSetSignal点击登录界面残障人士按钮,命中如下:
注意其中的参数二对应的是状态,查下状态 9 对应的正是 g_xWinsrv_AccessNotify_Signal,winlogon
和 LogonUI 的交互基本上流程基本比较清晰了,下面我们重点研究下 winlogon 同 lsass 进程完成密码认证
的一些细节。
Winlogon 同样使用 RPC 调用完成同 lsass 的交互,不同的是 windows 把这几个 RPC 调用封装成了 DLL
形式,分别是 SspiCli 客户端和 SspiSrv 服务端,最终还是调用了 RPCRT4 函数,证据如下:
直接从 IDA 中 DUMP 出 SSPISRV 的 RPC 调用接口如下:
根据《windows internals 5》一文,Winlogon 调用 SspiCli!LsaLogonUser完成登录,该函数最终通过
RPC 调用 Lsass::SspiSrv!SspirLogonUser
其中 AuthenticationInformation 参数里面包含了登录所需的信息,具体结构如下:
Windbg 显示这里密码被加密了,哈哈,下内存写断点,命中堆栈如下:
Winlogon!WLGeneric_Request_Logon_Credz_Execute 对应的代码如下:
该函数首先通过 RequestCredentials 函数请求登录凭证,如果是本地登录模式,该函数最终会调用 WluiRequestCredentials函数执行 LogonUI 进程的 RPC 服务函数 authui!WluiRequestCredentials,请求用户输入登录凭证。
最终 authui!CRequestCredentialsCallbackData::GetCredential获取用户登录凭证,数据结构为
_CRED_PROV_CREDENTIAL* 可惜没有数据结构定义。
输入qqqqqqqq调试显示 DUMP 如下:
下内存断点:Ba w1 0027e5c8+3e,命中堆栈如下:
这里 windbg 函数显示的函数 CRequestCredentialsCallbackData::GetShutdownChoice+0x63是错误的,实际 是 sub_7483CBE7 函数:
查看一下内存数据,如下:
源地址是 0027e510,长度是 000000b0 :
Ba w1 0027e510+3e,命中 查看源地址 238df78: 继续跟踪内存 Ba w1 238df78+3e
查看内存如下:
函数 KerbInteractiveUnlockLogonPack是一个可以 google 到的函数,很好。
02 024df8fc 024df924 024df928 authui!KerbInteractiveUnlockLogonPack+0x90
断点 ba w1 023888b8 命中堆栈
CredProtect 函数 MSDN 如下:
查看堆栈第二个参数,果然是明文密码:
对应的解密函数 CredUnprotect
这些内容实际在 lsass 进程里面解密,断点 ADVAPI32!CredUnprotectW命中堆栈如下:
最终的密码认证还是通过群众喜闻乐见的 msv1_0!LsaApLogonUserEx2来完成,如下:
win7的集成度和智能化很高,多数USB设置甚至打印机等外设,一接入电脑进入WIN7就能自动为你安装好驱动,便某些情况下我们需要卸载驱动,卸载驱动后敪是重启,这里不需要WIN7自动安装驱动了该怎么办了呢?
工具/原料
Windows7 or more
外设
方法/步骤
先右击桌面上的计算机图标,再选择属性:
在打开的窗口中单击高级系统设置:
接着在打开的系统属性对话框中,切换到硬件选项卡,并单击设备安装设置按钮:
在弹出的设备安装设置对话框中选择第二项,即否,让我选择要执行的操作:
或者通过控制面板也能打开设备安装设置对话框。单击开始按钮,选择控制面板:
在控制面板窗口中单击设备和打印机项:
在打开的设备和打印机窗口中,从设备中找到计算机,并右击之,从弹出的快捷菜单中选择设备安装设置命令:
最后再单击保存更改保存设置(www.tulaoshi.com)即可,卸载驱动后重启了就不会再自动安装驱动了。
windows7右键无法新建快捷方式的问题,问题描述如题,下面记录下解决办法,查看跟.lnk相关的注册表信息,保存以下代码到a.bat运行。
问题描述如题,下面记录下解决办法:
1、查看跟.lnk相关的注册表信息,保存以下代码到a.bat运行:
C#代码
Reg Query HKCR.lnk /S "%Userprofile%DesktopRegQuery.txt"&Start Notepad "%Userprofile%DesktopRegQuery.txt"
这段代码会查找注册表里有关.lnk(快捷方式)的设置,并且把查找结果保存到桌面的RegQuery.txt文件里,然后打开这个文件。
2、查看搜索到的信息,我的信息如下:
RegQuery.txt
HKEY_CLASSES_ROOT.lnk
(Default) REG_SZ lnkfile
HKEY_CLASSES_ROOT.lnkShellEx
HKEY_CLASSES_ROOT.lnkShellEx
(Default) REG_SZ
(本文来源于图老师网站,更多请访问http://www.tulaoshi.com)HKEY_CLASSES_ROOT.lnkShellEx
(Default) REG_SZ
(本文来源于图老师网站,更多请访问http://www.tulaoshi.com)HKEY_CLASSES_ROOT.lnkShellEx
(Default) REG_SZ
(本文来源于图老师网站,更多请访问http://www.tulaoshi.com)HKEY_CLASSES_ROOT.lnkShellEx
(Default) REG_SZ
(本文来源于图老师网站,更多请访问http://www.tulaoshi.com)HKEY_CLASSES_ROOT.lnkShellNew
Handler REG_SZ
IconPath REG_EXPAND_SZ %SystemRoot%system32shell32.dll,-16769
ItemName REG_SZ @shell32.dll,-30397
MenuText REG_SZ @shell32.dll,-30318
NullFile REG_SZ
Command REG_SZ rundll32.exe appwiz.cpl,NewLinkHere %1 -------加粗~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
HKEY_CLASSES_ROOT.lnkShellNewConfig
DontRename REG_SZ
加粗的一行即为问题所在,ShellNew的Command如果以上的情况,那么就需要修改了。(上面的注册表情况是适用于XP)
3、修复问题(只需要删除掉Command这一行就好),保存以下代码到b.bat,运行:
C#代码
reg delete HKCR.lnkShellNew /V Command /F
这行代码会删除掉ShellNew里的Command这行,完成之后再右键-新建-快捷方式。我已经能顺利新建快捷方式了。
4、修复问题后的lnk相关注册表信息如下:
RegQuery.txt 写道
HKEY_CLASSES_ROOT.lnk
(默认) REG_SZ lnkfile
HKEY_CLASSES_ROOT.lnkShellEx
HKEY_CLASSES_ROOT.lnkShellEx
(默认) REG_SZ
HKEY_CLASSES_ROOT.lnkShellEx
(默认) REG_SZ
HKEY_CLASSES_ROOT.lnkShellEx
(默认) REG_SZ
HKEY_CLASSES_ROOT.lnkShellEx
(默认) REG_SZ
HKEY_CLASSES_ROOT.lnkShellNew
Handler REG_SZ
IconPath REG_EXPAND_SZ %SystemRoot%system32shell32.dll,-16769
ItemName REG_SZ @shell32.dll,-30397
MenuText REG_SZ @shell32.dll,-30318
NullFile REG_SZ
HKEY_CLASSES_ROOT.lnkShellNewConfig
DontRename REG_SZ
----EOF----
来源:http://www.tulaoshi.com/n/20160401/2075625.html
看过《Windows7操作系统文件夹的奥妙》的人还看了以下文章 更多>>