透过windows 8 应用程序分析OS API 之Kernel32.dll

    Metro UI 已经出来很久了，看了很多metro UI 的应用程序，不知道是不是MS借助托管又下的一盘棋，主要分析三个问题。1. 是不是托管？ 2.是不是win32 上进行了直接包装？

1. 用visual studio 建立一个metro UI 的程序，编译完毕，然后看看exe 到底张什么样子，首先看看exe 到底依赖那模块库，如果是托管，那么一定依赖托管运行期，

从上图我们可以直接看到，这个exe 似乎不是依赖 托管运行期，但是有导出函数，

熟悉COM的话对这几个导出函数一定不会陌生，至少样子上看起来想，那也就是说Ms之前说的基于COM 技术看来是真的。看来不但可以进程外，还可以进程内。

2.运行了一个cmd.exe 程序，我们可以用process xp 看到如下，

可以看到cmd.exe 已经再是原来的cmd.exe ，但是下面还是挂着一个conhost.exe , 这个exe 的功能是什么？，这个conhost.exe  这个exe 使用了Com 进程外服务器的方式，并没有提供导出函数。可以分析进程通信上下断点。（这个部分放在下一篇中。。呵呵）。

  用windbg 将conhost.exe  挂起，我们在kernel32.dll 中的createprocess 上下断点，因为这个函数根据以前的MSDN在kernel32.dll 中，

我们透过cmd.exe 创建一个进程，看看怎么样，居然没有拦截到， 看来问题不是那么简单，然后 KERNEL32!ReadFile 上下断点，这次果然断点有效果，如下图，

直接走kernelbasse！createProcessW,  怎么突然多了一个dll 出来，这个应该是Win 8 新引入的对kernel 的封装，然后专门为metro UI 提供底层支持吧，不过这些都是猜想，但是从上图已经很明显了，这个调用已经不再走kernel32了。 为了验证kernel base 是新提供的功能封装，我们用Window32程序测试一下。

3. Win32 程序kernel 调用

HMODULE hMod = LoadLibrary(_T("Kernel32.dll"));
	if ( hMod != NULL )
	{
		FARPROC thisProc = GetProcAddress(hMod, "CreateProcessW");
		if ( thisProc )
		{
			printf("Address of CreateProcessW is 0x%x\n", thisProc);
			STARTUPINFO startinfo={sizeof(startinfo)};
			PROCESS_INFORMATION pi;
			PCreateProcess CreateProcessF = (PCreateProcess)(thisProc);
			BOOL bRet = CreateProcessF(
				NULL,
				_T("notepad.exe"),
				NULL,
				NULL,
				FALSE,
				0,
				NULL,
				NULL,
				&startinfo,
				&pi);


		}

		FreeLibrary( hMod );

第一个，我们就是要验证kernel32.dll 还导出这个函数不，第二个我们看看kernel32.dll 是不是以后直接系统调用看下图：

可以看到stack 现在在kernel32.dll 中，但是到了地址0x771243B1的jmp 语句，就出现了kernelbase.dll ,  那么这个就是dll 中的函数导出，kernel32.dll仅仅是使用了dll 函数bind 技术，这样看起来仅仅是MS 为了兼容以前的Windows 程序不得不做的bind.

其实我们在windbg 上一可以看到，看下图

可以看到上图中，明显是调用到kernelbase的readfile ，看来MS用kernelbase 来统一天下了。

要给老婆做饭了，不得瑟了。下次见。

kernelbase!会不会到nt层也许就是下次的主要内容了。