Ramblings++

Just wanted to give a heads up to anyone who utilizes API hooking heavily and wants their code to be compatible with Windows 7. Assuming things stay the way they are (which they probably will, this is the first time I’ve seen this before, so its not standard ‘beta build’ practice — checked with Vista and XP) then you will need to modify some of your API hooks.

Kernel32.dll now just ‘wraps’ a lot of APIs and the implementation is actually stored in KernelBase.dll.  This means if you want your code to work properly you’ll have to do this (example given with CreateProcessInternalW — unrelated code removed):

// Hook CreateProcessInternalW in KernelBase if it exists, or in Kernel32 otherwise.
// Needed because API moved to KernelBase in Windows 7.
// TODO: Implement alternative using NTDLL hooks. Priority: 2
FARPROC pCreateProcessInternalW = (hKernelBase) ? (GetProcAddress(hKernelBase,
“CreateProcessInternalW”)) : (GetProcAddress(hKernel32,”CreateProcessInternalW”));
CreateProcessInternalW_Trampoline = reinterpret_cast<tCreateProcessInternalW>(pCreateProcessInternalW);

// Perform the actual API hooking if the pointers are valid
if (pCreateProcessInternalW)
Patcher::Get()->AddPatch(&reinterpret_cast<PVOID&>(CreateProcessInternalW_Trampoline),
reinterpret_cast<PBYTE>(CreateProcessInternalW_Hook),”CreateProcessInternalW”);

So basically, most of your code can stay the same, it’s just the retrieval of the API pointer that needs to be updated. Whether you’re using GPA, EAT, whatever, you’ll need to check for KernelBase.dll first. Tested and working on XP through Windows 7. Please note I have NOT verified that IAT hooking will work without modifications, but I’m assuming it should.

If you end up testing IAT hooking in Windows 7 please let me know how you go. Also, I haven’t compiled a list yet of all redirected functions, I will if I get the time, otherwise just test your code with CreateProcessInternalW.

Programming, Reverse Engineering, Windows api hooking, beta, detour, eat, iat, windows 7

SRI have done a very comprehensive and indepth analysis of Conficker including the latest variant boasting fun new features.

Great read, I highly recommend it if stuff like this interests you (malware development, windows internals, reversing malware, etc):

Click here for epix (and the analysis)

Programming, Reverse Engineering, Security, Windows conficker, malware, reversing, Security, Windows

This seems to be something that confuses a lot of newbies so I’m going to take the time to explain it properly here.

‘Inspiration’: Example

First off. PE Files. Although we can ignore most of the details of the PE file format for the purposes of this there are still some basics that are important. A PE file has ’sections’. One of those sections is ‘.text’, this is typically where code is stored. Another we need to know about is ‘.data’, this is typically where global variables are stored. The last we need to know about is ‘.rdata’, this is typically where global constants, hardcoded strings, floating point constants, etc are stored.

Nitpicker’s Corner: I said “typically” because packers often abuse intricacies of the PE file format which are irrelevant for this discussion in order to avoid the use of these standard sections and confuses disassemblers and debuggers. I am dealing ONLY with regular PE files created by regular compilers such as MSVC++, Intel, etc.

Second. The stack and the heap. The stack is a LIFO (Last In First Out) data structure typically used for things like passing parameters to functions, temporarily saving or “pushing” values stored in registers to be restored or “popped” back later, storing local variables, saving function return addresses, etc. All threads typically have their own ’stack’ to manage. The heap is a ‘pool’ of dynamically allocated memory typically used to store objects which are dynamically allocated at runtime because there size or other details cannot be known at run time. For more info on either of these subjects please consult any book on computer science, or wikipedia.

Nitpicker’s Corner: I am referring only to the stack/heap structures/concepts in terms of their relevance to this discussion and only the implementations which I have outlined. I am aware that the “stack” is also a common data type.

The following is a “typical” C++ application.

Nitpicker’s Corner: Typical in the sense in which objects are created  in multiple fashions ane the application uses fairly standard C++ concepts.

Nitpicker’s Corner: Application is obviously not thread-safe due to lack of serialization on global objects.

#include <iostream>
#include <string>

std::string MyGlobalString(”Foobar”);
std::string* pMyOtherGlobalString = new std::string(”Foobar2″);

std::string& GetStaticString()
{
static std::string MyStaticString(”Foobar3″);
return MyStaticString;
}

void MyStringSub()
{
std::string MyStackString(”Foobar4″):
std::string* pMyHeapString(”Foobar5″);
// Do something here
}

int main()
{
std::cout << MyGlobalString << *pMyOtherGlobalString
<< GetStaticString() << std::endl;
return 0;
}

Now the question is, which objects are stored where?

MyGlobalString will typically be stored in the ‘.data’ section becaues it is a global object.

pMyGlobalString will typically be stored in the heap, but a pointer to it will be kept in the ‘.data’ section, again because it is a global object.

MyStaticString will typically be stored in the ‘.data’ section because it is also a ‘global’ object. Whats that you say? Its not a global? Well by defining it ’static’ we technically are defining it as ‘global’. Static objects are created when the program first runs and not destroyed until the program quits, they are effectively globals as far as the compiler is concerned, the only differences are at the higher language level. The differences at the lower level are negligible.

MyStackString will be stored on the stack because it is local to a function.

pMyHeapString will be stored in the heap but the pointer to it will be stored in the stack because it is local to a function.

What is interesting though is where all the strings like “Foobar1″, “Foobar2″ etc are stored. They are NOT stored in the ‘.data’ section with our string objects. Hardcoded C-style strings will typically be stored and referenced through the ‘.rdata’ section. This is because std::string objects are created at runtime but the underlying c-style string needs to be stored somewhere. This “somewhere” is usually ‘.rdata’ because the section is designed for constants and will typically be paged as read-only when in memory. Our hard-coded strings never need to be changed so this is the perfect spot to put them.

Programming, Reverse Engineering, Windows c++, Programming, reversing, Windows

Slight delay on the WoW related post I’m sorry (personal reasons). But in the meantime I figured I may as well post something else which I had already finished.

This is the source code to my module cloaker. The idea is to attempt to hide the presence of a DLL in an exe. My implementation is designed for use in a usermode rootkit (which is my current project) but it is half-way to being complete for use in anti-anti-cheat code (you will need to fix the weaknesses described in the comments along with a bunch of other stuff — also, by complete I mean ‘complete as possible’, there are some things you just can’t disguise at this level).

Documentation, credits, etc. is all in the source code (sorry but I’m too lazy to copy/paste it here :p):

Download

32-bit only, but a 64-bit version will most likely be coming in the not-too-distant future when I port my usermode rootkit code to x64.

Would love to hear suggestions/criticisms/etc.

Update: Sorry. Fixed link. I forgot to include a header the first time.

Update 2: Just wanted to point out, sorry for the retarded namespace name, its just to avoid collisions.

Reverse Engineering, Windows cloaker, reversing, Windows

I’ve just implemented the first beta of the file hiding feature for my rootkit. As usual, I’ve attached a screenshot:

As you can see, any files with the prefix “__PJB_F” are hidden from view. I’ve implemented it by hooking NtQueryDirectoryFile. Tested and working on both Vista and XP with only minor bugs (which should be smoothed out soon). Once I’ve smoothed out most of the bugs in the project I’m hoping to release portions of the source so if you’re waiting on that then stay tuned, I’ll have more information in the near future.

P.S. WoW related post incoming in the next few days probably.

Reverse Engineering, Windows reversing, rootkit, Windows

Hey, thought I’d post another progress update on my usermode rootkit project. Mostly it’s bug fixes and stability fixes (no more crashes! yay!). But I’ve also added three new things.

1. Process hiding by name. If the process name starts with “__PJB_H_” it will be cloaked.

2. Selective infection. If the process name starts with “__PJB_S_” it will not be infected and hence will be able to see the system in an uncloaked state.

3. Module stealth. Rather than hook APIs to hide my modules in the processes I inject into I’m manually unlinking it from the linked lists, then nulling out the entire LDR_MODULE structure, and also nulling out the entire PE header.

I’ve attached a screenshot to show off the latest features. To make it easier I’ve put colour coded boxes around what I want to draw attention to.

Purple: My test applications to hide from the system. Just CMD and Wordpad. (I blocked out my username on CMD because I used my full name, whoops. :P)

Blue: The rootkit bootstrapper and the DLL that is injected into processes to do all the dirty work.

Yellow: Process Explorer. Kinda like Task Manager on crack. I used that rather than taskmgr for two reasons. First and foremost is that it’s a lot more powerful and so much more useful when testing my code. Second is that taskmgr won’t open multiple windows unless you hack it to do so. The copy on the left is the ‘clean’ one, the one on the right is the ‘regular’ (infected) one. Sorry, they’re backwards to the placement on the desktop, didn’t notice until now and I’m too lazy to take a new screenshot. You will see that the clean process can see the two test apps yet the infected process can not.

Red: As stated above, the copy of Process Explorer with the window on the left can see our test processes because it has been ignored by the rootkit, the regular copy on the other hand is unaware of the presence of the two processes.

Orange: Both copies of Process Explorer have Explorer.exe highlighted. Because API hooks are not being used and the module is cloaking itself upon being injected the module is invisible even to the ‘clean’ copy of Process Explorer. If I were to disable module cloaking __PJB_x86.dll would appear at the top of both those lists. If I were to modify the cloaking to a less stealthy variant (ie using API hooks), although it would normally mean the clean process would be able to see the module and the infected one wouldn’t it isn’t hard to manually traverse the list and look for the module manually so I decided to go for a more ‘permanent’ but also more stealthy approach.

Whats next? A few extra hooks to increase the security of the process hiding, then I’m moving on to hiding files. I’ve decided rather than doing x64 support incrementally I’ll just finish 80-95% of the x86 code first so I can port most of it across at once.

Update: Whoops, forgot the screenshot. Fixed!

Reverse Engineering, Windows reversing, rootkit, Windows

Hey, just wanted to post a screenshot from the usermode rootkit I’m working on showing off the first ‘proper’ feature of the x86 build. Hiding processes.

Sorry about the low quality screenshot (JPEGs suck but PNGs are huge). If you want a higher res screenshot please this link.

Hoping to get the code ported to x64 builds of Windows when the x86 builds are stable. All the code is in usermode so it shouldn’t be too difficult.

Reverse Engineering, Windows reversing, rootkit, Windows

Hey, as requested I’m gonna post the info needed to use WoW’s console in a hack. Because I’m a little short on time I’m just going to post the bare minimum, but at the end of the post I’ll point out some of the other functions that may be of interest in case you want to go hunting for them.

Note: I’m assuming you already know how to enable and use WoW’s console. (Hint: ‘WoW.exe -console’, then use the ‘`’ key to bring it down. Just like in most other games.)

First off, registering console commands. The easiest way to find the function needed to do this is look for a known command in the binary. I chose ‘worldport’ because I’ve used it before, and found this:

.text:004073B3                 push    0               ; int
.text:004073B5                 push    0               ; int
.text:004073B7                 push    offset sub_406D70 ; int
.text:004073BC                 push    offset aWorldport ; “worldport”
.text:004073C1                 call    sub_6A0BD0

Now, from that we can easily see that sub_6A0BD0 is the function we are interested in because it takes both the command name and the associated function pointer (which you can verify by looking inside). Based on that the callback registration function prototype will be the following:

void __cdecl RegisterConsoleCommand(unsigned int Unk1 = 0, unsigned int Unk2 = 0, void* pCallback, const char* Command);

What you will notice though is that if you try to use your new command WoW will exit. Why is that? Well, if you go to the trouble of debugging it (Hint: start at ConsoleExec, called by the Lua subroutine by the same name) you will come across the following function:

.text:007CB3A0 sub_7CB3A0      proc near               ; CODE XREF: sub_69F470+B9p
.text:007CB3A0                                         ; sub_6A11A0+1Ap …
.text:007CB3A0
.text:007CB3A0 var_40          = byte ptr -40h
.text:007CB3A0 arg_0           = dword ptr  8
.text:007CB3A0
.text:007CB3A0                 push    ebp
.text:007CB3A1                 mov     ebp, esp
.text:007CB3A3                 mov     eax, dword_12EA640
.text:007CB3A8                 mov     ecx, dword_12EA644
.text:007CB3AE                 sub     esp, 40h
.text:007CB3B1                 test    eax, eax
.text:007CB3B3                 jz      short loc_7CB3B9
.text:007CB3B5                 test    ecx, ecx
.text:007CB3B7                 jnz     short loc_7CB3C9
.text:007CB3B9
.text:007CB3B9 loc_7CB3B9:                             ; CODE XREF: sub_7CB3A0+13j
.text:007CB3B9                 call    sub_7CB310      ; <”Unable to find .text section”, “.text”>
.text:007CB3BE                 mov     eax, dword_12EA640
.text:007CB3C3                 mov     ecx, dword_12EA644
.text:007CB3C9
.text:007CB3C9 loc_7CB3C9:                             ; CODE XREF: sub_7CB3A0+17j
.text:007CB3C9                 mov     edx, [ebp+arg_0]
.text:007CB3CC                 cmp     edx, eax
.text:007CB3CE                 jb      short loc_7CB3D4
.text:007CB3D0                 cmp     edx, ecx
.text:007CB3D2                 jb      short loc_7CB3F1
.text:007CB3D4
.text:007CB3D4 loc_7CB3D4:                             ; CODE XREF: sub_7CB3A0+2Ej
.text:007CB3D4                 push    edx
.text:007CB3D5                 push    offset aInvalidFunctio ; “Invalid function pointer: %p”
.text:007CB3DA                 lea     eax, [ebp+var_40]
.text:007CB3DD                 push    40h
.text:007CB3DF                 push    eax             ; char
.text:007CB3E0                 call    sub_6A6920
.text:007CB3E5                 lea     ecx, [ebp+var_40]
.text:007CB3E8                 push    ecx             ; char *
.text:007CB3E9                 call    sub_6A9E60
.text:007CB3EE ; —————————————————————————
.text:007CB3EE                 add     esp, 14h
.text:007CB3F1
.text:007CB3F1 loc_7CB3F1:                             ; CODE XREF: sub_7CB3A0+32j
.text:007CB3F1                 mov     esp, ebp
.text:007CB3F3                 pop     ebp
.text:007CB3F4                 retn
.text:007CB3F4 sub_7CB3A0      endp

Again, if you go to the trouble of reversing this function (which I’m not going to explain in detail because its beside the point of this post) you will see that it is looking at WoWs PE header, getting the start and end of WoW’s ‘.text’ segment (which is where all code is kept) and ensuring no function pointers are being registered outside that range. If a function pointer outside the valid range is found then WoW will quit.

What is the easiest way to get around this? Hook the function to just do a “return” at the start. If you want to just write a single byte to do the same (even easier), simply write ‘0xC3′ to the top of the function. Please keep in mind this is ignoring the presence of Warden. If you want to ensure you don’t get detected by Warden you will need to breakpoint whatever you’re hooking to ensure it’s not being scanned, or use a generic Warden bypass.

Now with that out of the way we move to printing output. Funnily enough we can backtrack to the exact same starting position as before:

.text:004073B3                 push    0               ; int
.text:004073B5                 push    0               ; int
.text:004073B7                 push    offset sub_406D70 ; int
.text:004073BC                 push    offset aWorldport ; “worldport”
.text:004073C1                 call    sub_6A0BD0

I checked worldport and happen to know that if you pass it invalid params it will print usage information to the console. Knowing that we can dive into worldport’s callback and we find this:

.text:00406DED                 push    4
.text:00406DEF                 push    offset aUsageWorldport ; “Usage: worldport <continentID> [x y z] “…
.text:00406DF4                 call    sub_69D850      ; <”.\ConsoleClient.cpp”, “[email protected]@”>
.text:00406DF9                 add     esp, 8

Again, very obvious what’s going on there.

void __cdecl ConsolePrint(unsigned int Unk1 = 0, const char* Output);

Using that you can easily write output to the console.

Well, that pretty much sums up the pure basics. If people are interested in some of the other console related stuff (changing the print colour, registering cvars, modifying/retrieving cvar values, what the parameters we’re ignoring are for, etc.) let me know. If you’d rather see something different like packet-based stuff, or even something non WoW related like my new usermode rootkit project or something else related to Windows reversing and internals feel free to suggest that too.

Extra Credit:

See if you can work out what the extra parameters I’ve marked as “Unk” (unknown) in each function are for. I’ll let you know if you’re right or wrong.

Games, Reverse Engineering, Windows, World of Warcaft Games, reversing, world of warcraft

I recently installed the Windows 7 x64 public beta and was having a look for API changes. I have gone through ntdll.dll, kernel32.dll, and user32.dll from the syswow64 folder (I know IA-32 ASM better than AMD64) and compared all the exports to those from Windows Server 2008 in order to pull out any changes. I figured this would be of use to curious people (like me) who are also lazy (like me). The results are posted below.

The lists include both new and new apis, and ones that  have been modified slightly (ie the kernel32.dll calls that are forwarded). 

Kernel32:

AddIntegrityLabelToBoundaryDescriptor

BaseCheckAppcompatCacheEx

BaseDllReadWriteIniFile

BaseFormatObjectAttributes

BaseFormatTimeOut

BaseGetNamedObjectDirectory

BaseSetLastNTError

BaseVerifyUnicodeString

Basep8BitStringToDynamicUnicodeString

BasepAllocateActivationContextActivationBlock

BasepAnsiStringToDynamicUnicodeString

BasepFreeActivationContextActivationBlock

BasepIsRealtimeAllowed

BasepMapModuleHandle

CallbackMayRunLong

CallbackMayRunLong (forwarded to NTDLL.TpCallbackMayRunLong)

CopyExtendedContext

CreateRemoteThreadEx (forwarded to Microsoft-Windows-System-Process-ProcessThreads-L1-1-0.CreateRemoteThreadEx)

DeleteProcThreadAttributeList

DeleteProcThreadAttributeList (forwarded to Microsoft-Windows-System-Process-ProcessThreads-L1-1-0.DeleteProcThreadAttributeList)

FindStringOrdinal

GetActiveProcessorCount

GetActiveProcessorGroupCount

GetCPFileNameFromRegistry

GetCurrentProcessorNumber (forwarded to NTDLL.NtGetCurrentProcessorNumber)

GetCurrentProcessorNumber (forwarded to NTDLL.RtlGetCurrentProcessorNumber)

GetCurrentProcessorNumberEx (forwarded to NTDLL.RtlGetCurrentProcessorNumberEx)

GetEnabledExtendedFeatures (forwarded to MICROSOFT-WINDOWS-SYSTEM-XSTATE-L1-1-0.RtlGetEnabledExtendedFeatures)

GetEraNameCountedString

GetExtendedContextLength (forwarded to MICROSOFT-WINDOWS-SYSTEM-XSTATE-L1-1-0.RtlGetExtendedContextLength)

GetExtendedFeaturesMask (forwarded to MICROSOFT-WINDOWS-SYSTEM-XSTATE-L1-1-0.RtlGetExtendedFeaturesMask)

GetLogicalProcessorInformationEx (forwarded to Microsoft-Windows-System-SysInfo-L1-1-0.GetLogicalProcessorInformationEx)

GetMaximumProcessorCount

GetMaximumProcessorGroupCount

GetNumaAvailableMemoryNodeEx

GetNumaNodeNumberFromHandle

GetNumaNodeProcessorMaskEx

GetNumaProcessorNodeEx

GetNumaProximityNodeEx

GetProcessGroupAffinity

GetProcessPreferredUILanguages

GetProcessorSystemCycleTime

GetSystemInfoInternal

GetThreadErrorMode

GetThreadGroupAffinity

GetThreadIdealProcessorEx

InitializeExtendedContext

InitializeProcThreadAttributeList

InitializeProcThreadAttributeList (forwarded to Microsoft-Windows-System-Process-ProcessThreads-L1-1-0.InitializeProcThreadAttributeList)

K32EmptyWorkingSet

K32EnumDeviceDrivers

K32EnumPageFilesA

K32EnumPageFilesW

K32EnumProcessModules

K32EnumProcessModulesEx

K32EnumProcesses

K32GetDeviceDriverBaseNameA

K32GetDeviceDriverBaseNameW

K32GetDeviceDriverFileNameA

K32GetDeviceDriverFileNameW

K32GetMappedFileNameA

K32GetMappedFileNameW

K32GetModuleBaseNameA

K32GetModuleBaseNameW

K32GetModuleFileNameExA

K32GetModuleFileNameExW

K32GetModuleInformation

K32GetPerformanceInfo

K32GetProcessImageFileNameA

K32GetProcessImageFileNameW

K32GetProcessMemoryInfo

K32GetWsChanges

K32GetWsChangesEx

K32InitializeProcessForWsWatch

K32QueryWorkingSet

K32QueryWorkingSetEx

LoadAppInitDlls

LocateExtendedFeature (forwarded to MICROSOFT-WINDOWS-SYSTEM-XSTATE-L1-1-0.RtlLocateExtendedFeature)

LocateLegacyContext (forwarded to MICROSOFT-WINDOWS-SYSTEM-XSTATE-L1-1-0.RtlLocateLegacyContext)

NlsConvertIntegerToString

NotifyMountMgr

PowerClearRequest

PowerCreateRequest

PowerSetRequest

QueryIdleProcessorCycleTimeEx

QueryThreadpoolStackInformation

QueryUnbiasedInterruptTime

RaiseFailFastException

ResolveLocaleName

RtlCaptureContext

RtlCaptureContext (forwarded to NTDLL.RtlCaptureContext)

RtlCaptureStackBackTrace

RtlCaptureStackBackTrace (forwarded to NTDLL.RtlCaptureStackBackTrace)

RtlFillMemory

RtlFillMemory (forwarded to NTDLL.RtlFillMemory)

RtlUnwind

RtlUnwind (forwarded to NTDLL.RtlUnwind)

SetExtendedFeaturesMask (forwarded to MICROSOFT-WINDOWS-SYSTEM-XSTATE-L1-1-0.RtlSetExtendedFeaturesMask)

SetProcessPreferredUILanguages

SetSearchPathMode

SetThreadErrorMode

SetThreadGroupAffinity

SetThreadIdealProcessorEx

SetThreadpoolStackInformation

SetWaitableTimerEx (forwarded to Microsoft-Windows-System-ThreadPool-L1-1-0.SetWaitableTimerEx)

SortCloseHandle

SortGetHandle

TryAcquireSRWLockExclusive (forwarded to NTDLL.RtlTryAcquireSRWLockExclusive)

TryAcquireSRWLockShared (forwarded to NTDLL.RtlTryAcquireSRWLockShared)

UpdateProcThreadAttribute

UpdateProcThreadAttribute (forwarded to Microsoft-Windows-System-Process-ProcessThreads-L1-1-0.UpdateProcThreadAttribute)

WerRegisterRuntimeExceptionModule

WerUnregisterRuntimeExceptionModule

User32:

CalculatePopupWindowPosition

ChangeWindowMessageFilterEx

CheckImeHotKey

CloseGestureInfoHandle

CloseTouchInputHandle

ConsoleControl

ControlMagnification

DisplayConfigGetDeviceInfo

DisplayConfigSetDeviceInfo

DwmGetDxRgn

DwmGetDxSharedSurface

DwmHintDxUpdate

GestureCommand

GetDisplayConfigBufferSizes

GetGestureCommandInfo

GetGestureConfig

GetGestureExtraArgs

GetGestureInfo

GetImeHotKey

GetInputLocaleInfo

GetMagnificationDesktopColorEffect

GetMagnificationDesktopMagnification

GetMagnificationLensCtxInformation

GetServicesProcess

GetTopLevelWindow

GetTouchInputInfo

GetWindowCompositionAttribute

GetWindowCompositionInfo

GetWindowDisplayAffinity

IsTopLevelWindow

IsTouchWindow

NotifyOverlayWindow

QueryDisplayConfig

RegisterGestureHandlerWindow

RegisterTouchWindow

SetConsoleReserveKeys

SetDisplayConfig

SetGestureConfig

SetMagnificationDesktopColorEffect

SetMagnificationDesktopMagnification

SetMagnificationLensCtxInformation

SetWindowCompositionAttribute

SetWindowDisplayAffinity

SfmDxBindSwapChain

SfmDxGetSwapChainStats

SfmDxOpenSwapChain

SfmDxQuerySwapChainBindingStatus

SfmDxReleaseSwapChain

SfmDxSetSwapChainStats

UnregisterGestureHandlerWindow

UnregisterTouchWindow

VRipOutput

VTagOutput

Win32PoolAllocationStats

gSharedInfo

gapfnScSendMessage

Ntdll:

AlpcRundownCompletionList

EtwEventWriteEx

EtwEventWriteNoRegistration

EvtIntReportAuthzEventAndSourceAsync

EvtIntReportEventAndSourceAsync

LdrGetDllHandleByMapping

LdrGetDllHandleByName

LdrResGetRCConfig

LdrRscIsTypeExist

LdrpResGetRCConfig

NtAllocateReserveObject

NtCancelDeviceWakeupRequest

NtCreateProfileEx

NtDisableLastKnownGood

NtDrawText

NtEnableLastKnownGood

NtNotifyChangeSession

NtOpenKeyEx

NtOpenKeyTransactedEx

NtQuerySecurityAttributesToken

NtQuerySystemInformationEx

NtQueueApcThreadEx

NtRequestDeviceWakeup

NtRequestWakeupLatency

NtSerializeBoot

NtSetIoCompletionEx

NtSetTimerEx

NtUmsThreadYield

NtWow64GetCurrentProcessorNumberEx

NtWow64InterlockedPopEntrySList

RtlAcquireReleaseSRWLockExclusive

RtlAddIntegrityLabelToBoundaryDescriptor

RtlContractHashTable

RtlCopyExtendedContext

RtlCreateHashTable

RtlCreateProcessReflection

RtlCreateVirtualAccountSid

RtlDeleteHashTable

RtlDetectHeapLeaks

RtlDisableThreadProfiling

RtlEnableThreadProfiling

RtlEndEnumerationHashTable

RtlEndWeakEnumerationHashTable

RtlEnumerateEntryHashTable

RtlEthernetAddressToStringA

RtlEthernetAddressToStringW

RtlEthernetStringToAddressA

RtlEthernetStringToAddressW

RtlExpandHashTable

RtlFillMemoryUlonglong

RtlGetCurrentProcessorNumberEx

RtlGetEnabledExtendedFeatures

RtlGetExtendedContextLength

RtlGetExtendedFeaturesMask

RtlGetFullPathName_UEx

RtlGetLocaleFileMappingAddress

RtlGetNextEntryHashTable

RtlGetProcessPreferredUILanguages

RtlInitEnumerationHashTable

RtlInitWeakEnumerationHashTable

RtlInitializeExtendedContext

RtlInsertEntryHashTable

RtlInterlockedClearBitRun

RtlInterlockedSetBitRun

RtlIsNameInExpression

RtlKnownExceptionFilter

RtlLoadString

RtlLocateExtendedFeature

RtlLocateLegacyContext

RtlLookupEntryHashTable

RtlQueryPerformanceCounter

RtlQueryPerformanceFrequency

RtlQueryThreadProfiling

RtlReadThreadProfilingData

RtlRemoveEntryHashTable

RtlReplaceSidInSd

RtlReportSilentProcessExit

RtlReportSqmEscalation

RtlSetExtendedFeaturesMask

RtlSetProcessPreferredUILanguages

RtlTryAcquireSRWLockExclusive

RtlTryAcquireSRWLockShared

RtlUTF8ToUnicodeN

RtlUnicodeToUTF8N

RtlWeaklyEnumerateEntryHashTable

SbExecuteProcedure

SbSelectProcedure

TpAllocAlpcCompletionEx

TpAlpcRegisterCompletionList

TpAlpcUnregisterCompletionList

TpCallbackIndependent

TpDbgGetFreeInfo

TpDisablePoolCallbackChecks

TpPoolFreeUnusedNodes

TpQueryPoolStackInformation

TpSetDefaultPoolMaxThreads

TpSetDefaultPoolStackInformation

TpSetPoolStackInformation

WerCheckEventEscalation

WerReportWatsonEvent

WinSqmAddToAverageDWORD

WinSqmAddToStreamEx

WinSqmCheckEscalationAddToStreamEx

WinSqmCheckEscalationSetDWORD

WinSqmCheckEscalationSetDWORD64

WinSqmCheckEscalationSetString

WinSqmCommonDatapointDelete

WinSqmCommonDatapointSetDWORD

WinSqmCommonDatapointSetDWORD64

WinSqmCommonDatapointSetStreamEx

WinSqmCommonDatapointSetString

WinSqmGetEscalationRuleStatus

WinSqmGetInstrumentationProperty

WinSqmIncrementDWORD

WinSqmIsOptedInEx

WinSqmSetDWORD

WinSqmSetDWORD64

WinSqmSetEscalationInfo

WinSqmSetIfMaxDWORD

WinSqmSetIfMinDWORD

ZwAllocateReserveObject

ZwCancelDeviceWakeupRequest

ZwCreateProfileEx

ZwDisableLastKnownGood

ZwDrawText

ZwEnableLastKnownGood

ZwNotifyChangeSession

ZwOpenKeyEx

ZwOpenKeyTransactedEx

ZwQuerySecurityAttributesToken

ZwQuerySystemInformationEx

ZwQueueApcThreadEx

ZwRequestDeviceWakeup

ZwRequestWakeupLatency

ZwSerializeBoot

ZwSetIoCompletionEx

ZwSetTimerEx

ZwUmsThreadYield

ZwWow64GetCurrentProcessorNumberEx

ZwWow64InterlockedPopEntrySList

Reverse Engineering, Windows reversing, Windows