Search the Community
Showing results for tags 'Undocumented'.
Found 2 results
Process + Thread + DLL Functions UDFs Fully tested on O/S's from Windows 2000 -> Windows 7, in both 32-bit and 64-bit modes. *Note: the dropdown box in the GUI has issues in Windows 2000 - workaround - type 1st letter of process. Also, RemoteThreads may not start if Terminal Services is not installed on Win2000. This is a compilation of all my Process, Thread, and DLL functions (and now Driver functions) into a number of UDF modules. Most every and anything useful can be done with these functions. The best part is the GUI interfaces (ProcessFunctionsTest, ThreadFunctionsTest) which let you experiment with what functions do without even touching a line of code. And whats that? Oh yes - it creates Threads. Even 'Wow64' threads, which requires a new way of thinking =) Bundled with the core Process, Thread, and DLL UDF's are numerous support functions, examples, and even a DLL Injection module. A comparison program 'ProcessListPropertiesTest' is also included for comparison against PsaltyDS's _ProcessListProperties UDF). The GUI's pictured above are the best way to explore the possible uses of the Process + Thread functions included, but the functionality extends beyond those default function calls. For example, there are more filters for the 'List' functions, plus other functionality that is not exposed in the GUI examples. There's also the DLL Functions which aren't even touched on (but are made use of nonetheless). *For another example use of the Process Functions UDF see the ProcessGetWinPEImportExports UDF. Below is a list of all the functions available (check the function headers for more info): ProcessFunctions UDF's Thread Functions UDF's DLL Functions UDF's DriverList.au3 UDF: ; _DriverList() ; Returns a list of Drivers that were loaded by the O/S This is now a very comprehensive suite. Most everything a programmer or user would find useful is included. If by chance you can think of *any* other (useful) functions to add to this project, however, let me know. For those that need to measure a Process's CPU Usage, please see my PDH Performance Counters UDF, another comprehensive UDF suite. Special note: For most all _Process* functions that require a 'QUERY' info handle, use the constant $PROCESS_QUERY_LIMITED_INFO, which is set based on O/S. There's only one exception to this that I can think of: _ProcessMemoryVirtualQuery() which requires full Query access no matter what O/S (0x400). Thread* functions can make use of 2 constants which are set based on O/S - $THREAD_QUERY_LIMITED_INFO and $THREAD_SET_LIMITED_INFO. Experiment with the GUI's on Vista+ O/S's to see what's the minimum req's. Download the Source and/or GUI Exe's from my site Optional addition: Special NomadMemory UDF designed to work with ProcessFunctions: NomadMemoryPF.au3 Ascend4nt's AutoIT Code License agreement: While I provide this source code freely, if you do use the code in your projects, all I ask is that: If you provide source, keep the header as I have put it, OR, if you expand it, then at least acknowledge me as the original author, and any other authors I creditIf the program is released, acknowledge me in your credits (it doesn't have to state which functions came from me, though again if the source is provided - see #1)The source on it's own (as opposed to part of a project) can not be posted unless a link to the page(s) where the code were retrieved from is provided and a message stating that the latest updates will be available on the page(s) linked to.Pieces of the code can however be discussed on the threads where Ascend4nt has posted the code without worrying about further linking.UPDATES:
Kernel Objects Information Sample output of Object Handles probing _ I've assembled a number of UDF's which use "undocumented" features of the O/S over the years. And this here would be the latest, and possibly the last (I hope?). The purpose of this UDF is to query kernel objects in the system. It's actually a pretty big UDF that ties together a lot of functionality, and hopefully makes it more accessible. With the UDF you can: Query a Kernel Object for 'hidden' information using its handle: Object Type and stats (_ObjectGetTypeInfoUD), Attributes and Access (_ObjectGetBasicInfoUD), Kernel Object Name (_ObjectGetNameUD), etc Query certain Kernel Event Objects for current states:Event, IoCompletion and Mutex ("Mutant") signal states (and more), Semaphore counts, Timer's remaining time, etc Get a list of opened File handles and filenames (there's already a few UDF's dedicated to that, though) Collect all the current handles held by the O/S and its processes, using specific filters, and get information on what the object is and its current state Kernel Objects Inspector script _ What's an Object you say? Whats a Kernel? Whats an NT? Gosh, maybe you shouldn't be here - go read Youtube. As Windows programmers, we make use of these Kernel Objects all the time... Object Types List Some of the most common System Objects: Token, Process, Thread, Event, Mutant (Mutex), Semaphore, Timer, File (includes NamedPipe and Mailslot), Key (Registry Key) Anytime you work with these objects, you are generating new objects at the kernel level. Luckily, the O/S allows above 16 million handles per process (see Pushing the Limits of Windows: Handles by Mark Russinovich), so this isn't a concern. However, if an individual process has in excess of 16K handles, there will be some trunacted values returned from the NT API call as it only returns 16-bit values for handles. See >this post where I try to describe this in better detail. However, this is no longer a problem with the latest update, which restores the upper bits of handles through a simple wraparound detection technique. There's more to say, but perhaps its best to show what functions are available. From the NTKernelObjectsInfo UDF Header: Querying time issues: Note that any call to query handles (_NTObjGetHandlesUD, _NTObjGetHandlesInfoEx) relies on a call to NtQuerySystemInformation, which gathers information on EVERY handle held by the system and it's processes. This can take a few seconds! Be patient. (Also, _NTObjBuildTypesIndexMap calls it indirectly) IMPORTANT: Be a little careful with looking for 'File' objects on Vista and Win7.. on XP there's already some safeguards which unfortunately prevent detecting certain objects. Newer versions of the O/S don't seem to have problems with threaded probing of File objects, but there may be some cases.. The Console output is still a bit noisy, but its good for analyzing where there's problems in reading handles, or analyzing "File" handles which can cause major problems, especially in the case of NamedPipes. Some example UDFs are included: NTSystemObjectsList: displays a list of System Object Types NTKernelObjectsCollectExample: A collection query at its simplest (see below for this example) NTKernelObjectsSelfExamine: creates a number of different Objects before listing everything NTKernelObjectsInspect: Inspect Kernel Objects with Filtering options from a GUI This GUI needs work! Notice that with the ArrayDisplay function, there is a 'Run User Func' option which will display any extra info retrieved for the object (see ExInfo column). NTKernelObjectsSpam: Creates a crapload of Kernel Objects. This is mostly useless, but its here to demonstrate how NTKernelObjectsInspect now is able to report correct handle values beyond 65,536 NTKernelObjectsCollectExample In this example I query only 2 processes for handles, and use exclusion criteria to remove "File" and "EtwRegistration" from the resultant list. ; =========================================================================================================== ; <NTKernelObjectsCollectExample.au3> ; ; Pretty barebones example of NTKernelObjectsInfo, showing the ease with which objects can be collected ; Uses multipe query types, multiple processes, and multiple Object Types with exclusion rules ; ; Author: Ascend4nt ; =========================================================================================================== #include "NTKernelObjectsInfo.au3" #include <Array.au3> ; -= FLAGS to Tweak Object Querying =- ; Force Win2000/XP Attribute skipping (must appear AFTER #include): ;$g_NTKO_bNamedPipeProtect = True ; Alternatively set own: ;$g_NTKO_sFileAttribSkipList = "0x0012019F|" ; Additionally, can force BadMask Skipping to OFF (not recommended): ;$g_NTKO_bSkipBadMasks = False ; Other queries available, although less often used: ; $NTOBJ_QUERYBY_PID (example: @AuotItPID), $NTOBJ_QUERYBY_OBJTYPE (ex: 28), and $NTOBJ_QUERYBY_HANDLE (actual object handle) $aRet = _NTObjGetHandlesInfoEx($NTOBJ_QUERYBY_PROCESSNAME, "firefox.exe|autoit3.exe", _ $NTOBJ_QUERYBY_OBJTYPENAME + $NTOBJ_QUERY_EXCLUDE, "File|EtwRegistration") ConsoleWrite("Errors: " & @error & ", @extended = " & @extended & @CRLF) _ArrayDisplay($aRet, "_NTObjGetHandlesInfoEx") Thanks for testing this out! Change History: NTKernelObjects.zip ~prev Downloads: 55