using of auto-derived state machines

Let`s see what we can do with our auto-derived state-machines. All source code in my github repo

Simple case: KdLocalDebugEnabled

Assume that we want to find address of KdLocalDebugEnabled. On kernel 18345 RVA is 37CC18 and it located in section .data. Run

ldr.exe -se -t 8 -der D:\work\kernel\w10\18346\arm\ntoskrnl.exe 37CC18

to build rules. Option -t sets number of threads. Results:

found at 0076D850 - KdSystemDebugControl

 ldrb exorted KdDebuggerEnabled

 ldrb

apply return 37CC18, must_be 37CC18

This rule say that we must find exported function KdSystemDebugControl, wait for loading of exported symbol KdDebuggerEnabled and next loading operation will give us address of KdLocalDebugEnabled
Now apply this rule for kernel RTM 2004 (with option -T you can specify files on which to test rules):
ldr.exe -se -t 8 -der D:\work\kernel\w10\18346\arm\ntoskrnl.exe 37CC18 -T d:\work\kernel\w10\rtm\2004\arm\ntoskrnl.exe

 ldrb exorted KdDebuggerEnabled

 ldrb

Test[0]: C3F639

Lets check this address
// pubsym <rva 0xc3f639> KdLocalDebugEnabled

Second case: CmpTraceRoutine

IDA Pro shows 106 xrefs on kernel 18345, RVA is 8A8008. Lets see if rule for finding this address can be derived automatically:

efficiency of auto-derived state machines

It`s time to measure how effective this state-machines. I made today simple perl script to measure how much symbols (located in sections .data, ALMOSTRO and PAGEDATA) can be found for arm64 windows kernel. The conditions for success are

• found function is exported
• or found function use some unique constant which is used no more than 3 times

Result on kernel build 18346:

total: 3493 symbols, found 1466

Simple state machine with states containing only loading/storing, call import/export and loading of some constant is able to retrieve almost 42% of symbols

PS: for adf.sys (which has no exported functions at all) results even better:

total: 164 symbols, found 73

44.5%

(semi)auto building of state machine

Several days ago I made PoC to extract addresses of WSK data from windows 10 arm64 afd.sys - specifically AfdWskClientListHead and lock AfdWskClientSpinLock. Nothing special except fact that afd.sys has no exported functions. So you must find some rare constant, then find functions which use it and only then do some disasm applying state machine to each code block (see lambda passed to traverse_simple_state_graph)

While I was writing this code, I was not left with a question whether it is possible to employ computer to build such state machines. And now I know that this is possible (at least for code on plain C for RISC-like asm with predictable addresses of instructions etc etc)

Lets see how such algo can be arranged:

1) you must find all cross-refs to desired variable and collect list of functions which use it (exactly what deriv_hack::find_xrefs method does)

2) then you must disasm each such function and try to get some primitives - like loading of constants, calling imported/exported functions etc - see deriv_hack::make_path method. Sure set of this primitives will be different for each processor and perhaps will depends from your tasks

Results for afd.sys!AfdWskClientListHead:

IDCFuncs in ida pro 7.x

Let's assume what we want to have some normal programming language inside ida pro (not strange looking pile of spaces). Or just to made RPC interface so you can use several instances of ida from external processeses. In previous versions (since 4.x - I can be wrong) we had IDCFuncs which I used for example to embed perl. But since 7.x this symbol is no longer exported (obviously to make users' lives even more unbearable). Sure this small problem can`t stop me. So there are at least two ways to find IDCFuncs in any ida pro 7.x

signature search

strictly speaking this method allows you to find IDCFuncs->funcs. Name of first function in this array of ext_idcfunc_t always is "____" (yes, some undocumented function with name of four underscores). So you first must search for it in .text section (in ida.dll/ida64.dll) and then find address in .data - this will be first ext_idcfunc_t:

struct ext_idcfunc_t

{  const char *name;             ///< Name of function  

   idc_func_t *fptr;             ///< Pointer to the Function

   const char *args;             ///< Type of arguments. Terminated with 0.        

   const idc_value_t *defvals;   ///< Default argument values.

   int ndefvals;                 ///< Number of default values.     

   int flags;                    ///< \ref EXTFUN_

};

some disasm magic

It`s very ironic that in the disassembler you have to use another disassembler to find what you want. Lets see which exported functions use IDCFuncs

etw part 4½: MCGEN_TRACE_CONTEXT

let's continue to dissect ETW (parts 1,2, 3 & 4)

Now consider structures generated with mc.exe (Windows Message Compiler). It seems that this is very old technology - some .mc files in official Microsoft github repository have copyrights from 1992! Despite this they are still supported for example in MSBuild - see rule for MessageCompile

This generated with mc structure has name MCGEN_TRACE_CONTEXT and looks like:

typedef struct _MCGEN_TRACE_CONTEXT

{

    HANDLE                 RegistrationHandle;

    HANDLE                 Logger;

    ULONGLONG              MatchAnyKeyword;

    ULONGLONG              MatchAllKeyword;

    ULONG                  Flags;

    ULONG                  IsEnabled;

    UCHAR                  Level; 

    UCHAR                  Reserve;

    USHORT                 EnableBitsCount;

    PULONG                 EnableBitMask;

    const ULONGLONG*       EnableKeyWords;

    const UCHAR*           EnableLevel;

} MCGEN_TRACE_CONTEXT, *PMCGEN_TRACE_CONTEXT;

Looks very similar to _TlgProvider_t. Unfortunately they cannot be found with some simple signatures scan - you need to use some disasm magic. I wrote simple PoC to find them in arm64 windows kernel

Let`s see where you can encounter this ancient variant of ETW

IMAGE_LOAD_CONFIG_DIRECTORY from sdk 20190

just as illustration to paper about XFG
size is 0xB8 for 32 bit and 0x130 for 64 bit

etw part 4: _TlgProvider_t in kernel

let's continue to dissect ETW (parts 1,2 & 3)
Basically structure _TlgProvider_t in kernel almost the same as in user mode but field RegHandle points to ETW_REG_ENTRY. You can easily find them using simple search for known guids - I made PoC for arm64 (and for ndis.sys too)

kernel contains following tlg providers:

• Microsoft.Windows.TlgAggregateInternal, GUID 703FCC13-B66F-5868-DDD9-E2DB7F381FFB
• KernelExecutive, GUID 8944A53C-A561-4E53-A0C6-D565414745FC
• Microsoft.Windows.Kernel.BootEnvironment, GUID 23B76A75-CE4F-56EF-F903-C3A2D6AE3F6B
• MSTelCov, GUID 1DD9B8C9-E078-4075-B9DE-4E5125071A18
• KernelProcess, GUID 2839FF94-8F12-4E1B-82E3-AF7AF77A450F
• KernelGeneral, GUID 7614521C-4D0B-4341-BFC9-873082C0F1D3
• Microsoft-Windows-Kernel-Vm, GUID B7FBD4E0-FA8F-4C58-B0FB-3CC227B86ED6. Located in section ALMOSTRO
• Microsoft.Windows.Kernel.Security, GUID 09A69A38-2680-4BFA-AD01-792AD63A4FF2
• Microsoft.Windows.Security.Capabilities, GUID 27A8FDF4-9B77-575B-BE3B-E7163EF159BB
• Microsoft.Windows.Kernel.ProcessSubsystem, GUID C59673D8-B796-58DF-FBF8-A70BAD656DCA
• Microsoft.Windows.Kernel.Ttm, GUID 5E753E4D-2B0D-4451-B8F9-0F1253CA0B44. Located in section PAGEDATA
• Microsoft.Windows.Kernel.Power.PowerTransitions, GUID 050BF899-DA06-4852-A63A-81E6B9A1C74F
• Microsoft.Windows.Kernel.Power.DirectedDrips, GUID 0D2ED727-38A0-4B2B-9F7E-EC79B5EC4AA5. Located in section PAGEDATA
• Microsoft.Windows.Kernel.Power, GUID 63BCA7A1-77EC-4EA7-95D0-98D3F0C0EBF7
• Microsoft.Windows.Kernel.Power.DiagFxAccounting, GUID 57D04B7B-550A-49A2-ABCC-A7FA15598A30
• Microsoft.Windows.Kernel.ObjectManager, GUID F39412D1-C9FD-5E79-8A82-9C9CBD8CA809
• Microsoft-Windows-Kernel-Mm, GUID 7E9E8B9C-406C-5D73-E566-0F50EA3ADE3E
• Microsoft.Windows.Kernel.Kernel, GUID 061C37C3-1363-5C1B-B8ED-F3D8F74633CE
• Microsoft.Windows.Kernel.PnP, GUID 6C0EBBBB-C292-457D-9675-DFCC1C0D58B0
• Microsoft.Windows.Kernel.DeviceConfig, GUID C8BDE9FF-F31F-59DC-6C27-CA37C516ADA5
• Microsoft.Windows.Kernel.SysEnv, GUID A9FDF37B-D72D-4051-A3CD-D422103CE079
• Microsoft.Windows.Kernel.LiveDump, GUID A4D16FC5-D1CF-4D72-A055-25F3EB02A70E
• Microsoft.Windows.Kernel.Dump, GUID A51EE86B-8EA5-454C-9A7D-37B6655A535D
• IumTelemetryProvider, GUID 73A33AB2-1966-4999-8ADD-868C41415269
• Microsoft.Windows.Containers.RegistryVirtualization, GUID 252D9ECC-1C9F-4917-8760-F872A83BF018
• Microsoft.Windows.Kernel.FeatureConfigurationManager, GUID F7E83426-2B81-58F9-C5D4-F2DB6D0AD473
• Microsoft.Windows.Kernel.Registry, GUID E9EAF418-0C07-464C-AD14-A7F353349A00
• Microsoft.Windows.FileSystem.Cache, GUID 74093E1D-DBE3-4019-B97D-54EDCB02CFED
• Microsoft.Windows.Kernel.HAL, GUID 0F51C5A7-0E76-47A5-BEDE-7CF62C5822F6

So what bad guys can do knowing addresses of this _TlgProvider_t?