2009年03月03日

肯定不是2^64那么多 从hardware pte里看PageFramNumber,是28bit

再看32bit的windows 普通的是20bit, pae的是26

2^28就是windows能表示的物理内存了吧, 以前还真没注意过这个。。

说错了请告诉 : p

2009年01月28日

http://uayuty.cn

http://shop37037561.taobao.com/

哈哈 还没想明白卖啥, 先卖点毛绒玩具, 进货犯了个错误, 买的都是我喜欢的…. 其他人不买账啊
就没人喜欢机器猫了吗.. 反到是uay挑的流氓兔子卖的很快, 2天就卖了19个
我品位确实有问题….

2008年12月03日

IsBadReadPtr Function

Verifies that the calling process has read access to the specified range of memory.

Important This function is obsolete and should not be used. Despite its name, it does not guarantee that the pointer is valid or that the memory pointed to is safe to use. For more information, see Remarks on this page.

Syntax

BOOL WINAPI IsBadReadPtr(
__in const VOID *lp,
__in UINT_PTR ucb
);
Parameters
lp [in]
A pointer to the first byte of the memory block.

ucb [in]
The size of the memory block, in bytes. If this parameter is zero, the return value is zero.

Return Value
If the calling process has read access to all bytes in the specified memory range, the return value is zero.

If the calling process does not have read access to all bytes in the specified memory range, the return value is nonzero.

If the application is compiled as a debugging version, and the process does not have read access to all bytes in the specified memory range, the function causes an assertion and breaks into the debugger. Leaving the debugger, the function continues as usual, and returns a nonzero value. This behavior is by design, as a debugging aid.

Remarks
This function is typically used when working with pointers returned from third-party libraries, where you cannot determine the memory management behavior in the third-party DLL.

Threads in a process are expected to cooperate in such a way that one will not free memory that the other needs. Use of this function does not negate the need to do this. If this is not done, the application may fail in an unpredictable manner.

Dereferencing potentially invalid pointers can disable stack expansion in other threads. A thread exhausting its stack, when stack expansion has been disabled, results in the immediate termination of the parent process, with no pop-up error window or diagnostic information.

If the calling process has read access to some, but not all, of the bytes in the specified memory range, the return value is nonzero.

In a preemptive multitasking environment, it is possible for some other thread to change the process’s access to the memory being tested. Even when the function indicates that the process has read access to the specified memory, you should use structured exception handling when attempting to access the memory. Use of structured exception handling enables the system to notify the process if an access violation exception occurs, giving the process an opportunity to handle the exception.

Requirements
Minimum supported client Windows 2000 Professional
Minimum supported server Windows 2000 Server
Header Winbase.h (include Windows.h)
Library Kernel32.lib
DLL Kernel32.dll

See Also
IsBadCodePtr
IsBadStringPtr
IsBadWritePtr

Send comments about this topic to Microsoft

Build date: 11/6/2008

Tags : Add a tag Add Cancel Flag as ContentBug

Community Content
Add new content Annotations

Raymond Chen (The Old New Thing) says: never ever use this function Peter Smith in Redmond | Edit | Show History
Please Wait
Via Raymond Chen’s “The Old New Thing” blog,

http://blogs.msdn.com/oldnewthing/archive/2006/09/27/773741.aspx

IsBadXxxPtr should really be called CrashProgramRandomly
Often I’ll see code that tries to “protect” against invalid pointer parameters. This is usually done by calling a function like IsBadWritePtr. But this is a bad idea. IsBadWritePtr should really be called CrashProgramRandomly.
The documentation for the IsBadXxxPtr functions presents the technical reasons why, but I’m going to dig a little deeper. For one thing, if the “bad pointer” points into a guard page, then probing the memory will raise a guard page exception. The IsBadXxxPtr function will catch the exception and return “not a valid pointer”. But guard page exceptions are raised only once. You just blew your one chance. When the code that is managing the guard page accesses the memory for what it thinks is the first time (but is really the second), it won’t get the guard page exception but will instead get a normal access violation.
Alternatively, it’s possible that your function was called by some code that intentionally passed a pointer to a guard page (or a PAGE_NOACCESS page) and was expecting to receive that guard page exception or access violation exception so that it could dynamically generate the data that should go onto that page. (Simulation of large address spaces via pointer-swizzling is one scenario where this can happen.) Swallowing the exception in IsBadXxxPtr means that the caller’s exception handler doesn’t get a chance to run, which means that your code rejected a pointer that would actually have been okay, if only you had let the exception handler do its thing.
“Yeah, but my code doesn’t use guard pages or play games with PAGE_NOACCESS pages, so I don’t care.” Well, for one thing, just because your code doesn’t use these features pages doesn’t mean that no other code in your process uses them. One of the DLLs that you link to might use guard pages, and your use of IsBadXxxPtr to test a pointer into a guard page will break that other DLL.
And second, your program does use guard pages; you just don’t realize it. The dynamic growth of the stack is performed via guard pages: Just past the last valid page on the stack is a guard page. When the stack grows into the guard page, a guard page exception is raised, which the default exception handler handles by committing a new stack page and setting the next page to be a guard page.
(I suspect this design was chosen in order to avoid having to commit the entire memory necessary for all thread stacks. Since the default thread stack size is a megabyte, this would have meant that a program with ten threads would commit ten megabytes of memory, even though each thread probably uses only 24KB of that commitment. When you have a small pagefile or are running without a pagefile entirely, you don’t want to waste 97% of your commit limit on unused stack memory.)
“But what should I do, then, if somebody passes me a bad pointer?”
You should crash.
No, really.
In the Win32 programming model, exceptions are truly exceptional. As a general rule, you shouldn’t try to catch them. And even if you decide you want to catch them, you need to be very careful that you catch exactly what you want and no more.
Trying to intercept the invalid pointer and returning an error code creates nondeterministic behavior. Where do invalid pointers come from? Typically they are caused by programming errors. Using memory after freeing it, using uninitialized memory, that sort of thing. Consequently, an invalid pointer might actually point to valid memory, if for example the heap page that used to contain the memory has not been decomitted, or if the uninitialized memory contains a value that when reinterpreted as a pointer just happens to be a pointer to memory that is valid right now. On the other hand, it might point to truly invalid memory. If you use IsBadWritePtr to “validate” your pointers before writing to them, then in the case where it happens to point to memory that is valid, you end up corrupting memory (since the pointer is “valid” and you therefore decide to write to it). And in the case where it happens to point to an invalid address, you return an error code. In both cases, the program keeps on running, and then that memory corruption manifests itself as an “impossible” crash two hours later.
In other words IsBadWritePtr is really CorruptMemoryIfPossible. It tries to corrupt memory, but if doing so raises an exception, it merely fails the operation.
Many teams at Microsoft have rediscovered that IsBadXxxPtr causes bugs rather than fixes them. It’s not fun getting a bucketful of crash dumps and finding that they are all of the “impossible” sort. You hunt through your code in search of this impossible bug. Maybe you find somebody who was using IsBadXxxPtr or equivalently an exception handler that swallows access violation exceptions and converts them to error codes. You remove the IsBadXxxPtr in order to let the exception escape unhandled and crash the program. Then you run the scenario again. And wow, look, the program crashes in that function, and when you debug it, you find the code that was, say, using a pointer after freeing it. That bug has been there for years, and it was manifesting itself as an “impossible” bug because the function was trying to be helpful by “validating” its pointers, when in fact what it was doing was taking a straightforward problem and turning it into an “impossible” bug.
There is a subtlety to this advice that you should just crash when given invalid input, which I’ll take up next time.

Tags : Add a tag Add Cancel Flag as ContentBug
| Edit

Tags : Add a tag Add Cancel Flag as ContentBug

Manage Your Profile | Legal | Contact Us | MSDN Flash Newsletter
© 2008 Microsoft Corporation. All rights reserved. Terms of Use | Trademarks | Privacy Statement

2008年10月28日

三种链表是InLoadOrderModuleList , InMemoryOrderModuleList , InInitializationOrderModuleList

lkd> !peb
PEB at 7ffd5000
    InheritedAddressSpace:    No
    ReadImageFileExecOptions: No
    BeingDebugged:            No
    ImageBaseAddress:         01000000
    Ldr                       00191e90
    Ldr.Initialized:          Yes
    Ldr.InInitializationOrderModuleList: 00191f28 . 00195a38
    Ldr.InLoadOrderModuleList:           00191ec0 . 00195a28
    Ldr.InMemoryOrderModuleList:         00191ec8 . 00195a30

lkd> dt nt!_PEB_LDR_DATA 00191e90
   +0×000 Length           : 0×28
   +0×004 Initialized      : 0×1 ”
   +0×008 SsHandle         : (null)
   +0×00c InLoadOrderModuleList : _LIST_ENTRY [ 0x191ec0 - 0x195a28 ]
   +0×014 InMemoryOrderModuleList : _LIST_ENTRY [ 0x191ec8 - 0x195a30 ]
   +0×01c InInitializationOrderModuleList : _LIST_ENTRY [ 0x191f28 - 0x195a38 ]
   +0×024 EntryInProgress  : (null)

lkd> dt nt!_LDR_DATA_TABLE_ENTRY 0×191ec0
   +0×000 InLoadOrderLinks : _LIST_ENTRY [ 0x191f18 - 0x191e9c ]
   +0×008 InMemoryOrderLinks : _LIST_ENTRY [ 0x191f20 - 0x191ea4 ]
   +0×010 InInitializationOrderLinks : _LIST_ENTRY [ 0x0 - 0x0 ]
   +0×018 DllBase          : 0×01000000
   +0×01c EntryPoint       : 0×01056217
   +0×020 SizeOfImage      : 0×93000
   +0×024 FullDllName      : _UNICODE_STRING "C:\Program Files\Debugging Tools for Windows (x86)\windbg.exe"
   +0×02c BaseDllName      : _UNICODE_STRING "windbg.exe"
   +0×034 Flags            : 0×5000
   +0×038 LoadCount        : 0xffff
   +0×03a TlsIndex         : 0
   +0×03c HashLinks        : _LIST_ENTRY [ 0x19362c - 0x7c99b310 ]
   +0×03c SectionPointer   : 0×0019362c
   +0×040 CheckSum         : 0×7c99b310
   +0×044 TimeDateStamp    : 0×47e30f97
   +0×044 LoadedImports    : 0×47e30f97
   +0×048 EntryPointActivationContext : (null)
   +0×04c PatchInformation : (null)

lkd> dt nt!_LDR_DATA_TABLE_ENTRY 0×191ec8-0×8
   +0×000 InLoadOrderLinks : _LIST_ENTRY [ 0x191f18 - 0x191e9c ]
   +0×008 InMemoryOrderLinks : _LIST_ENTRY [ 0x191f20 - 0x191ea4 ]
   +0×010 InInitializationOrderLinks : _LIST_ENTRY [ 0x0 - 0x0 ]
   +0×018 DllBase          : 0×01000000
   +0×01c EntryPoint       : 0×01056217
   +0×020 SizeOfImage      : 0×93000
   +0×024 FullDllName      : _UNICODE_STRING "C:\Program Files\Debugging Tools for Windows (x86)\windbg.exe"
   +0×02c BaseDllName      : _UNICODE_STRING "windbg.exe"
   +0×034 Flags            : 0×5000
   +0×038 LoadCount        : 0xffff
   +0×03a TlsIndex         : 0
   +0×03c HashLinks        : _LIST_ENTRY [ 0x19362c - 0x7c99b310 ]
   +0×03c SectionPointer   : 0×0019362c
   +0×040 CheckSum         : 0×7c99b310
   +0×044 TimeDateStamp    : 0×47e30f97
   +0×044 LoadedImports    : 0×47e30f97
   +0×048 EntryPointActivationContext : (null)
   +0×04c PatchInformation : (null)

lkd> dt nt!_LDR_DATA_TABLE_ENTRY 0×191f28-0×10
   +0×000 InLoadOrderLinks : _LIST_ENTRY [ 0x191fc0 - 0x191ec0 ]
   +0×008 InMemoryOrderLinks : _LIST_ENTRY [ 0x191fc8 - 0x191ec8 ]
   +0×010 InInitializationOrderLinks : _LIST_ENTRY [ 0x191fd0 - 0x191eac ]
   +0×018 DllBase          : 0×7c920000
   +0×01c EntryPoint       : 0×7c932c28
   +0×020 SizeOfImage      : 0×93000
   +0×024 FullDllName      : _UNICODE_STRING "C:\WINDOWS\system32\ntdll.dll"
   +0×02c BaseDllName      : _UNICODE_STRING "ntdll.dll"
   +0×034 Flags            : 0×80084004
   +0×038 LoadCount        : 0xffff
   +0×03a TlsIndex         : 0
   +0×03c HashLinks        : _LIST_ENTRY [ 0x1936d4 - 0x7c99b2c8 ]
   +0×03c SectionPointer   : 0×001936d4
   +0×040 CheckSum         : 0×7c99b2c8
   +0×044 TimeDateStamp    : 0×4802bdc5
   +0×044 LoadedImports    : 0×4802bdc5
   +0×048 EntryPointActivationContext : (null)
   +0×04c PatchInformation : (null)

可以看出来前2个链表InLoadOrderModuleList , InMemoryOrderModuleList 这2个表是一样的, 以进程exe为链首. InInitializationOrderModuleList 以ntdll.dll为链首.

进程exe不加入到InInitializationOrderModuleList 链表, 其他顺序3个表一致, 这也是为什么进程exe在InLoadOrderModuleList , InMemoryOrderModuleList里+0×010 InInitializationOrderLinks : _LIST_ENTRY [ 0x0 - 0x0 ]为空的原因

2008年07月22日
#ifndef _DISK_HIVE_SUBS_H_
#define _DISK_HIVE_SUBS_H_
//-----------------------------------------------------------------------------//
#define HIVE_SYSTEM	0
#define HIVE_SOFTWARE	1
//-----------------------------------------------------------------------------//
LONG
NIAPHiveOpenHive(
	IN  ULONG ulHive,
	OUT PHANDLE phFileHandle,
	OUT PHANDLE phFileMappingHandle,
	OUT PHANDLE phHiveHandle // hive file map base
	);

LONG
NIAPHiveCloseHive(
	IN HANDLE hFileHandle,
	IN HANDLE hFileMappingHandle,
	IN HANDLE hHiveHandle // hive file map base
	);

LONG
NIAPHiveOpenKey(
	IN  HANDLE  hHiveHandle,
	IN  PWCHAR  pwstrKeyPath,
	OUT PHANDLE phKeyHandle
	);

LONG
NIAPHiveQueryInfoKey(
	IN  HANDLE  hHiveHandle,
	IN  HANDLE  hKey,
	OUT PULONG  pulSubKeys OPTIONAL,
	OUT PULONG  pulValues OPTIONAL,
	OUT PULONG  pulMaxNameLen OPTIONAL,
	OUT PULONG  pulMaxClassLen OPTIONAL,
	OUT PULONG  pulMaxValueNameLen OPTIONAL,
	OUT PULONG  pulMaxValueDataLen OPTIONAL
	);

LONG
NIAPHiveEnumKey(
	IN  HANDLE hHiveHandle,
	IN  HANDLE hKey,
	IN  ULONG  ulIndex,
	OUT PWCHAR pwstrName,
	IN  ULONG  ulNameSize
	);

LONG
NIAPHiveEnumValue(
	IN  HANDLE hHiveHandle,
	IN  HANDLE hKey,
	IN  ULONG ulIndex,
	OUT PWCHAR pwstrValueName,
	IN  PULONG pulValueNameSize,
	OUT PULONG pulType OPTIONAL,
	OUT PVOID pData OPTIONAL,
	IN OUT PULONG pulDataLen OPTIONAL
	);

LONG
NIAPHiveCloseKey(
	IN HANDLE hHiveHandle,
	IN HANDLE hKey
	);
//-----------------------------------------------------------------------------//
#endif

 

Example Code:

#include <Windows.h>
#include <stdio.h>
#include "diskhivesubs.h"
//-----------------------------------------------------------------------------//
int wmain(int argc, PWCHAR argv[])
{
	LONG lResult = -1;

	HANDLE hFileHandle = INVALID_HANDLE_VALUE;
	HANDLE hFileMappingHandle = INVALID_HANDLE_VALUE;
	HANDLE hHiveHandle = NULL;
	HANDLE hKeyHandle = INVALID_HANDLE_VALUE;

	ULONG  ulSubKeys = 0;
	ULONG  ulValues = 0;
	ULONG  ulMaxNameLen = 0;
	ULONG  ulMaxClassLen = 0;
	ULONG  ulMaxValueNameLen = 0;
	ULONG  ulMaxValueDataLen = 0;

	PWCHAR pwstrSubKeyNameBuffer = NULL;
	PWCHAR pwstrValueNameBuffer = NULL;
	ULONG ulValueNameSize = 0;

	HANDLE hStdOut = INVALID_HANDLE_VALUE;

	ULONG ulBytesWritten = 0;

	PVOID pValueData = NULL;
	ULONG ulValueDataLen = 0;

	ULONG i = 0;

	hStdOut = GetStdHandle(STD_OUTPUT_HANDLE);
	if (INVALID_HANDLE_VALUE == hStdOut)
	{
		goto Exit0;
	}

	lResult = NIAPHiveOpenHive(HIVE_SYSTEM, &hFileHandle, &hFileMappingHandle, &hHiveHandle);
	if (ERROR_SUCCESS != lResult)
	{
		goto Exit0;
	}

	lResult = NIAPHiveOpenKey(hHiveHandle, argv[1], &hKeyHandle);
	if (ERROR_SUCCESS != lResult)
	{
		printf("NIAPHiveOpenKey fail!\n");
		goto Exit0;
	}
	else
	{
		printf("NIAPHiveOpenKey success, ulKeyHandle 0x%x\n", (ULONG)hKeyHandle);
	}

	lResult = NIAPHiveQueryInfoKey(hHiveHandle, hKeyHandle,
		&ulSubKeys,
		&ulValues,
		&ulMaxNameLen,
		&ulMaxClassLen,
		&ulMaxValueNameLen,
		&ulMaxValueDataLen
		);

	if (ERROR_SUCCESS != lResult)
	{
		printf("NIAPHiveQueryInfoKey fail!\n");
	}
	else
	{
		printf("NIAPHiveQueryInfoKey success\n");
		printf("ulSubKeys: %d\n", ulSubKeys);
		printf("ulValues: %d\n", ulValues);
		printf("ulMaxNameLen: %d\n", ulMaxNameLen);
		printf("ulMaxClassLen: %d\n", ulMaxClassLen);
		printf("ulMaxValueNameLen: %d\n", ulMaxValueNameLen);
		printf("ulMaxValueDataLen: %d\n", ulMaxValueDataLen);
	}

	pwstrSubKeyNameBuffer = malloc(ulMaxNameLen + sizeof(UNICODE_NULL));
	if (NULL == pwstrSubKeyNameBuffer)
	{
		lResult = -1;
		goto Exit0;
	}
	memset(pwstrSubKeyNameBuffer, 0, ulMaxNameLen + sizeof(UNICODE_NULL));

	pwstrValueNameBuffer = malloc(ulMaxValueNameLen + sizeof(UNICODE_NULL));
	if (NULL == pwstrValueNameBuffer)
	{
		lResult = -1;
		goto Exit0;
	}
	memset(pwstrValueNameBuffer, 0, ulMaxValueNameLen + sizeof(UNICODE_NULL));

	for (i = 0; i < ulSubKeys; i++)
	{
		memset(pwstrSubKeyNameBuffer, 0, ulMaxNameLen + sizeof(UNICODE_NULL));
		lResult = NIAPHiveEnumKey(hHiveHandle, hKeyHandle, i, pwstrSubKeyNameBuffer, (ulMaxNameLen + sizeof(UNICODE_NULL)) / sizeof(WCHAR));
		if (ERROR_SUCCESS != lResult)
		{
			printf("NIAPHiveEnumKey fail!\n");
			goto Exit0;
		}
		WriteConsole( hStdOut, pwstrSubKeyNameBuffer, (ulMaxNameLen + sizeof(UNICODE_NULL)) / sizeof(WCHAR), &ulBytesWritten, NULL);
		WriteConsole( hStdOut, L"\n", 1, &ulBytesWritten, NULL);
	}

	printf("Value:\n");

	ulValueDataLen = ulMaxValueDataLen;

	pValueData = malloc(ulValueDataLen);
	if (NULL == pValueData)
	{
		lResult = -1;
		goto Exit0;
	}

	for (i = 0; i < ulValues; i++)
	{
		ULONG ulType = 0;

		ulValueDataLen = ulMaxValueDataLen;
		memset(pValueData, 0, ulValueDataLen);

		ulValueNameSize = (ulMaxValueNameLen + sizeof(UNICODE_NULL)) / sizeof(WCHAR);
		memset(pwstrValueNameBuffer, 0, ulMaxValueNameLen + sizeof(UNICODE_NULL));
		lResult = NIAPHiveEnumValue(hHiveHandle, hKeyHandle, i, pwstrValueNameBuffer, &ulValueNameSize,
			                        &ulType, pValueData, &ulValueDataLen);
		if (ERROR_SUCCESS != lResult)
		{
			printf("NIAPHiveEnumValue fail, 0x%x\n", lResult);
			goto Exit0;
		}
		WriteConsole( hStdOut, pwstrValueNameBuffer, ulValueNameSize, &ulBytesWritten, NULL);

		switch(ulType)
		{
		case REG_DWORD:
			{
				printf(" Type: REG_DWORD");
				printf(" Value: %d", *(PULONG)pValueData);
			}
			break;
		case REG_SZ:
			{
				printf(" Type: REG_SZ");
				printf(" Value: ");
				WriteConsole( hStdOut, (PWCHAR)pValueData, ulValueDataLen / sizeof(WCHAR), &ulBytesWritten, NULL);
			}
			break;
		case REG_EXPAND_SZ:
			{
				printf(" Type: REG_EXPAND_SZ");
				printf(" Value: ");
				WriteConsole( hStdOut, (PWCHAR)pValueData, ulValueDataLen / sizeof(WCHAR), &ulBytesWritten, NULL);
			}
			break;
		default:
			break;
		}
		WriteConsole( hStdOut, L"\n", 1, &ulBytesWritten, NULL);
	}

	lResult = ERROR_SUCCESS;
Exit0:
	if (NULL != pValueData)
	{
		free(pValueData);
	}
	if (NULL != pwstrSubKeyNameBuffer)
	{
		free(pwstrSubKeyNameBuffer);
	}
	if (NULL != pwstrValueNameBuffer)
	{
		free(pwstrValueNameBuffer);
	}
	if (INVALID_HANDLE_VALUE != hKeyHandle)
	{
		NIAPHiveCloseKey(hHiveHandle, hKeyHandle);
	}
	if ((NULL != hHiveHandle) && (INVALID_HANDLE_VALUE != hFileMappingHandle) && (INVALID_HANDLE_VALUE != hFileHandle))
	{
		NIAPHiveCloseHive(hFileHandle, hFileMappingHandle, hHiveHandle);
	}
	return lResult;
}
//-----------------------------------------------------------------------------//
 
2008年05月11日

驱动拦截键盘输入 保护密码不被截获

拦截dll加载,对应用程序做保护

主要用于网游和im的密码输入保护

有意请联系 niapsoft@hotmail.com

2007年06月30日

直到拿在手里.
当初选择不要那么容易的得到,现在看来我还是没有后悔当初的决定. 

对电影里的正面人物,英雄们没有负出代价最后来个圆满的结局,一直都怀疑.

 

2007年05月13日

今天很高兴能和朋友们一起做事,只是这事我不会,帮不上忙,而朋友们又是来帮我的忙。一直鼓捣了一晚上。好像又回到了大二那时候,在网络中心一起讨论和做东西。马上毕业了,不知道还有多少这样的时候能和朋友们在一起。

当时突然有的感觉就是朋友们在一起就没有做不了的事。真希望将来我们这几个能在一起干些事情。

2007年04月18日

http://www.rootkit.com/vault/uty/FileExposure.rar

因为董老大说程序要到产品化,所以想还是放出来,这样估计bug就出来不少了

2007年04月12日

晚上出去的晚了点,9点半爸给我来电话,后来把电话交给了我妈,说了2句又是我爸接的,说刚做晚手术别让我妈多说话

接完电话往公司走的时候,这一刻我觉得很幸福