1.debugview怎么样
2.如何让XP里面的“搜索”搜不出东西来？
3.APT案例分析：一个基于Meterpreter和Windows代理的攻击事件
debugview怎么样
debugview能够给你提供简单的vc调试方案，在这里你能够运行数据将进程服务显示在软件商，那你时刻的了解当前的进程状态，编辑故障信息，对启动方案很有帮助，快下载试试吧
dllhost.exe介绍：
1、夜聊源码DebugView提供了一个简单的VC调试解决方案，通过DebugView软件。
2、用户可以实时监视计算机上运行的程序，在软件中显示进程和管理。
3、在列表中查看调试的当前运行状态，DebugView允许您检查过程错误。
dllhost.exe特点：
1、这是一款非常好用的VC调试工具，可以帮助用户进行在线进程管理。
2、提取数据作为日志文本并编辑日志信息，帮助您调整VC连接和VC启动器。
3、界面非常清爽，源码怎样看没有任何花里胡哨的功能，方便选择实用工具。
dllhost.exe功能：
1、DebugView支持windows x psp2，DebugView现在可以捕获windows x psp2上内核模式的调试输出。
2、更突出、更突出的过滤器过滤器。
3、日志文件打包：新的日志文件选项DebugView中文版本的日志文件达到指定的大小限制后，开始包围。
4、更多亮点过滤器：DebugView现在有个亮点过滤器。
5、插入注释：可以插入注释输出的新菜单项。
6、在DebugView中查看特殊调试输出字符串dbgviewclear清除输出时。
dllhost.exe特色：
1、DebugView通过兼容的计算机系统获取VC数据。
2、可以执行服务器运行错误数据提取。onlyoffice源码分析
3、支持将排除的问题记录在日志中。
4、也可以单独导出错误数据。
5、支持win系统监控，切换到监控界面。
6、监视事件定制支持，查看监视的项目。
7、列表中还可以显示VC启动时间。
8、支持向VC添加附加注释。
9、debugview提供的监控程序非常简单。
、启动时必须单击agree才能开始监视。
dllhost.exe使用技巧：
用debugview，打开debugview，运行你的源码交付流程debug版本程序，可以定位到源文件的某一行。
在vc源码中需要输出的地方用OutputDebugString就可以在这个工具中查看啦，对VC调试代码非常实用，
不用你用Messagebox一步步的调试。而且易于操作，查找错误更方便。
DbgView界面和监控方法
点击“Connect Local”
打开软件后，顶部工具栏中选择监控主机。先看连接本地机调试，点击“Connect Local”即可。
工具栏
在这个工具栏上，主要看几个图标
工具栏 在这个工具栏上，主要看几个图标
此按钮，表示是否开启捕获服务
此按钮，表示是否捕获系统内核的Debug信息
此按钮，表示是否捕获一般Win应用，也就相当于我们的应用的Debug信息
注意：只有调用了WinDebug中方法的地方的输出Debug信息才能被DebugView捕获。
再来看看捕获的应用信息：
将打开
两个按钮的叉叉去掉，就会看到DebugView可能输出一些信息。
如下图：
这些都是系统中的应用调用WinAPI所输出的Debug信息。但是ios源码目录只有红色部分是我们的Demo所输出的信息。
此时我们可以新建过滤器，只查看我们自己想看到的信息
如何让XP里面的“搜索”搜不出东西来？
最简单的办法下载一个加密隐藏文件夹的软件
文件夹隐藏大师
.com/soft/.html 天空软件的连接很安全
如果你喜欢编程 交流一下 给你个源代码
设置之后，选则工具——文件夹选项——显示所有文件和文件夹都不能显示
只有你自己知道文件夹的具体路径再浏览器里输入全部路径才会进入其他方法都不能进 所有软件都找不到
编写驱动拦截NT的API实现隐藏文件目录
目前NT下有很多种隐藏文件和目录的方法，其中最简单的一种是给文件和文件夹加上系统属性和隐藏属性，操作系统就会不在显示了，而且查找也找不到了，但是这种方法一点都不彻底，没有可用性！下面我们来介绍用NT驱动程序来拦截NTAPI来实现彻底隐藏文件和目录的目的。NT下有一个文件NTDLL.DLL，大部分NTAPI都是在这个库中封装的。其中实现查找文件和目录的API接口是ZwQueryDirectoryFile，所以我们只要拦截这个API的话，文件和目录就可以完全隐藏了！下面来一步不实现（准备工作：到NTDDK中找一个WDM驱动程序模型，也就是最简单的驱动程序了）：
1.定义FILE_INFORMATION_CLASS的第3号结构：_FILE_BOTH_DIR_INFORMATION，这个结构是ZwQueryDirectoryFile必须参数。
typedef struct _FILE_BOTH_DIR_INFORMATION {
ULONG NextEntryOffset;
ULONG FileIndex;
LARGE_INTEGER CreationTime;
LARGE_INTEGER LastAccessTime;
LARGE_INTEGER LastWriteTime;
LARGE_INTEGER ChangeTime;
LARGE_INTEGER EndOfFile;
LARGE_INTEGER AllocationSize;
ULONG FileAttributes;
ULONG FileNameLength;
ULONG EaSize;
CCHAR ShortNameLength;
WCHAR ShortName[];
WCHAR FileName[1];
} FILE_BOTH_DIR_INFORMATION, *PFILE_BOTH_DIR_INFORMATION;
2.先申明ZwQueryDirectoryFile，然后定义ZwQueryDirectoryFile的原型：
extern NTSYSAPI NTSTATUS NTAPI ZwQueryDirectoryFile(
IN HANDLE hFile,
IN HANDLE hEvent OPTIONAL,
IN PIO_APC_ROUTINE IoApcRoutine OPTIONAL,
IN PVOID IoApcContext OPTIONAL,
OUT PIO_STATUS_BLOCK pIoStatusBlock,
OUT PVOID FileInformationBuffer,
IN ULONG FileInformationBufferLength,
IN FILE_INFORMATION_CLASS FileInfoClass,
IN BOOLEAN bReturnOnlyOneEntry,
IN PUNICODE_STRING PathMask OPTIONAL,
IN BOOLEAN bRestartQuery);
//定义ZwQueryDirectoryFile的原型
typedef NTSTATUS (*REALZWQUERYDIRECTORYFILE)(IN HANDLE hFile,
IN HANDLE hEvent OPTIONAL,
IN PIO_APC_ROUTINE IoApcRoutine OPTIONAL,
IN PVOID IoApcContext OPTIONAL,
OUT PIO_STATUS_BLOCK pIoStatusBlock,
OUT PVOID FileInformationBuffer,
IN ULONG FileInformationBufferLength,
IN FILE_INFORMATION_CLASS FileInfoClass,
IN BOOLEAN bReturnOnlyOneEntry,
IN PUNICODE_STRING PathMask OPTIONAL,
IN BOOLEAN bRestartQuery);
//定义一个原函数指针
REALZWQUERYSYSTEMINFORMATION RealZwQuerySystemInformation;
3.定义替换API函数的原型：
NTSTATUS HookZwQueryDirectoryFile(
IN HANDLE hFile,
IN HANDLE hEvent OPTIONAL,
IN PIO_APC_ROUTINE IoApcRoutine OPTIONAL,
IN PVOID IoApcContext OPTIONAL,
OUT PIO_STATUS_BLOCK pIoStatusBlock,
OUT PVOID FileInformationBuffer,
IN ULONG FileInformationBufferLength,
IN FILE_INFORMATION_CLASS FileInfoClass,
IN BOOLEAN bReturnOnlyOneEntry,
IN PUNICODE_STRING PathMask OPTIONAL,
IN BOOLEAN bRestartQuery);
4.在DriverEntry（驱动入口）函数中加入如下申明：
//保存真正的ZwQueryDirectoryFile函数地址
RealZwQueryDirectoryFile=(REALZWQUERYDIRECTORYFILE)(SYSTEMSERVICE(ZwQueryDirectoryFile));
//把自定义的替换函数指针指向真正的ZwQueryDirectoryFile函数
(REALZWQUERYDIRECTORYFILE)(SYSTEMSERVICE(ZwQueryDirectoryFile))=HookZwQueryDirectoryFile;
5.在DriverUnload（驱动卸载函数）函数中加入恢复代码：
//恢复原来的函数指针
(REALZWQUERYDIRECTORYFILE)(SYSTEMSERVICE(ZwQueryDirectoryFile))=RealZwQueryDirectoryFile;
6.现在准备工作做好了，函数指针都已经设置转向了，剩下的是实现这个我们自定义的替换函数HookZwQueryDirectoryFile，代码如下：
NTSTATUS HookZwQueryDirectoryFile(
IN HANDLE hFile,
IN HANDLE hEvent OPTIONAL,
IN PIO_APC_ROUTINE IoApcRoutine OPTIONAL,
IN PVOID IoApcContext OPTIONAL,
OUT PIO_STATUS_BLOCK pIoStatusBlock,
OUT PVOID FileInformationBuffer,
IN ULONG FileInformationBufferLength,
IN FILE_INFORMATION_CLASS FileInfoClass,
IN BOOLEAN bReturnOnlyOneEntry,
IN PUNICODE_STRING PathMask OPTIONAL,
IN BOOLEAN bRestartQuery)
{
NTSTATUS rc;
ULONG CR0VALUE;
ANSI_STRING ansiFileName,ansiDirName,HideDirFile;
UNICODE_STRING uniFileName;
//初始化要过虑的文件名这里是debug.exe
RtlInitAnsiString(&HideDirFile,"DBGVIEW.EXE");
// 执行真正的ZwQueryDirectoryFile函数
rc = ((REALZWQUERYDIRECTORYFILE)(RealZwQueryDirectoryFile))(
hFile,
hEvent,
IoApcRoutine,
IoApcContext,
pIoStatusBlock,
FileInformationBuffer,
FileInformationBufferLength,
FileInfoClass,
bReturnOnlyOneEntry,
PathMask,
bRestartQuery);
/*如果执行成功（而且FILE_INFORMATION_CLASS的值为FileBothDirectoryInformation，我们就进行处理，过滤*/
if(NT_SUCCESS(rc)&& (FileInfoClass == FileBothDirectoryInformation))
{
PFILE_BOTH_DIR_INFORMATION pFileInfo;
PFILE_BOTH_DIR_INFORMATION pLastFileInfo;
BOOL bLastOne;
//把执行结果赋给pFileInfo
pFileInfo = (PFILE_BOTH_DIR_INFORMATION)FileInformationBuffer;
pLastFileInfo = NULL;
//循环检查
do
{
bLastOne = !( pFileInfo->NextEntryOffset );
RtlInitUnicodeString(&uniFileName,pFileInfo->FileName);
RtlUnicodeStringToAnsiString(&ansiFileName,&uniFileName,TRUE);
RtlUnicodeStringToAnsiString(&ansiDirName,&uniFileName,TRUE);
RtlUpperString(&ansiFileName,&ansiDirName);
//打印结果，用debugview可以查看打印结果
DbgPrint("ansiFileName :%s\n",ansiFileName.Buffer);
DbgPrint("HideDirFile :%s\n",HideDirFile.Buffer);
// 开始进行比较，如果找到了就隐藏这个文件或者目录
if( RtlCompareMemory(ansiFileName.Buffer,HideDirFile.Buffer,HideDirFile.Length ) == HideDirFile.Length)
{
DbgPrint("This is HideDirFile!\n");
if(bLastOne)
{
if(pFileInfo == (PFILE_BOTH_DIR_INFORMATION)FileInformationBuffer )
{
rc = 0x; //隐藏文件或者目录；
}
else
{
pLastFileInfo->NextEntryOffset = 0;
}
break;
}
else //指针往后移动
{
int iPos = ((ULONG)pFileInfo) - (ULONG)FileInformationBuffer;
int iLeft = (DWORD)FileInformationBufferLength - iPos - pFileInfo->NextEntryOffset;
RtlCopyMemory( (PVOID)pFileInfo, (PVOID)( (char *)pFileInfo + pFileInfo->NextEntryOffset ), (DWORD)iLeft );
continue;
}
}
pLastFileInfo = pFileInfo;
pFileInfo = (PFILE_BOTH_DIR_INFORMATION)((char *)pFileInfo + pFileInfo->NextEntryOffset);
}while(!bLastOne);
RtlFreeAnsiString(&ansiDirName);
RtlFreeAnsiString(&ansiFileName);
}
return(rc);
APT案例分析：一个基于Meterpreter和Windows代理的攻击事件
前言
在深入研究此APT攻击案例前，需先了解测试环境。我对其进行了定制化的模拟APT攻击，发现可以上传HTTPS返回类型的Meterpreter后门至只可通过代理访问的公司Windows网络中。最初，我并未确定此情况是否存在漏洞或对APT攻击的影响。因此，我需要确保代理环境的正确性。
在详细分析后，我们使用的Meterpreter模块（windows/meterpreter/reverse_https）并未成功。以下介绍攻击过程分析：
攻击过程分析
为解决此问题，我修改了Meterpreter攻击载荷代码，并在被攻击靶机中测试。此过程需要产生HTTPS类型或使用其他Meterpreter后门源码。例如，可通过shellter或任何受信任软件如putty.exe生成简单后门，或使用powershell生成web协议模块的Meterpreter后门。
靶机中执行后门软件并监听后门程序，观察连接情况。下图展示了攻击机中在端口执行的侦听，连接后未执行命令。
攻击机已反向连接回我们的侦听机器，获得一个Meterpreter shell。然而，此shell无法执行任何命令，会话随即结束。从高层次来看，后门成功执行第一阶段，通过代理反弹至攻击者机器，但在第二阶段注入过程中可能出错，导致命令执行失败及会话中断。
我手动创建PEM证书，配置监听器，比较浏览器上观察的指纹与创建的证书指纹，确认证书传输过程未被替换。这促使我继续寻找问题所在。
嗅探网络流量以了解第二阶段发生的情况。下图展示了靶机与代理服务器间的TCP流量通信。
流量显示靶机（.x.x.）与代理服务器（.x.x.:）间的通信，包括靶机发送至攻击机（.x.x.x:）的安全连接请求。NTLM身份验证与响应表明握手成功。
在部署Meterpreter第一部分无误后，问题出在第二部分，即攻击载荷与msf侦听之间的通信。继续分析网络流量以找到答案。
下图展示了第一阶段攻击载荷与msf侦听之间的通信，以及靶机不使用代理直接与攻击机进行通信的情况。
分析显示，在使用代理时，Meterpreter会话中断，原因在于第二阶段的后门载荷无法返回到msf的侦听中。下载Meterpreter源代码，查找问题根本原因。
在Meterpreter源代码中，存在使用WinHTTP Windows API的逻辑实现。调试源代码，修改DEBUGTRACE预处理常量，以便在运行过程中提供调试信息。
通过运行后门并在靶机上运行DebugView工具，获取调试信息。信息显示，后门尝试使用AutoDetect代理设置，但未获得代理地址，请求发送失败。
分析源代码后发现，问题出在处理Windows代理设置的代码块。修改代码以考虑通过DHCP或DNS获取代理。重新运行后门，发现使用Auto detect时，Meterpreter能执行命令。
总结与建议
在某些情况下，我们可能遇到工具无法正常工作的问题。解决方法包括使用其他方法进行攻击或修复问题。修复了生成的dll代码后，我们可以在特定企业环境中进行攻击。然而，修复代码是否被msf采纳尚不可知，但此经验适用于遇到类似问题时的修复方法。
我们了解到Windows代理配置有特定顺序，一旦获取代理设置，无论其是否有效，系统都会使用它。此外，IE与火狐浏览器在系统代理设置下表现出不同行为。在某些情况下，即使代理无法工作，也不会使用其他配置。
编写代码测试代理配置是否允许进入网络，可以增加APT攻击成功的机会。然而，应考虑到特殊环境的限制，管理员通常不会在测试环境中使用此类设置。
最终结论是，确保APT攻击方案的连接成功可能性与IE相似，即可在大多数环境中成功执行攻击。如果IE能访问网络，APT攻击同样能成功。