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?

etw tracing handles in kernel

let's continue to dissect ETW (part 1 & 2). This time consider how tracing is implemented in the kernel itself. I made PoC to find all tracing handles in arm64 kernel and now give short explanation of what each of them is used for

EtwpEventTracingProvRegHandle

GUID B675EC37-BDB6-4648-BC92-F3FDC74D3CA2 (EventTracingProvGuid). Used in lots of internal etw related functions like EtwpTraceStackWalk, EtwpWriteUserEvent, EtwpFailLogging, NtTraceEvent, WmiTraceMessage, EtwWriteEx, EtwWrite etc

EtwKernelProvRegHandle

GUID A68CA8B7-004F-D7B6-A698-07E2DE0F1F5D (KernelProvGuid). Used for kernel tracing in functions like SeLogAccessFailure, CmpReorganizeHive, SepSetTokenUserAndGroups, EtwTraceSystemTimeChange, EtwTraceTimeZoneInformationRefresh etc

EtwpPsProvRegHandle

GUID 22FB2CD6-0E7B-422B-A0C7-2FAD1FD0E716 (PsProvGuid). Used for tracing processes subsystem activity in functions like PsImpersonateContainerOfThread, PspRevertContainerImpersonation, PspSetJobIoRateControl, PspSetJobIoAttribution, EtwTraceFreezeThawProcess etc

EtwpNetProvRegHandle

GUID 7DD42A49-5329-4832-8DFD-43D979153A88 (NetProvGuid). Used only in function EtwpTraceNetwork which assigning as callback in WmiSetNetworkNotify

_TlgProvider_t

let's continue to dissect ETW and consider one of the many usermode tracing structures - _TlgProvider_t. It is even officially documented in platform sdk in header TraceLoggingProvider.h (sample of using):
struct _TlgProvider_t
{
    UINT32 LevelPlus1;
    UINT16 const UNALIGNED* ProviderMetadataPtr; // Points to the RemainingSize member of provider metadata.
    ULONGLONG KeywordAny;
    ULONGLONG KeywordAll;
    REGHANDLE RegHandle;
    TLG_PENABLECALLBACK EnableCallback;
    PVOID CallbackContext;
};

purpose of the fields is pretty obvious except RegHandle - it's not real HANDLE but some structure with address to ETW_REGISTRATION_ENTRY.

How we can find it? Field ProviderMetadataPtr is pointer to _TlgProviderMetadata_t:
struct _TlgProviderMetadata_t
{
    UINT8 Type; // = _TlgBlobProvider3
    GUID ProviderId;
#define _TLG_PROVIDER_METADATA_PREAMBLE 16 // = sizeof(ProviderId)
    UINT16 RemainingSize; // = sizeof(RemainingSize + ProviderName)
    /*
    char ProviderName[sizeof("providerName")]; // UTF-8 nul-terminated provider name
    for each additional chunk of metadata {
        UINT16 ChunkSize;
        UINT8 ChunkType;
        UINT8 ChunkData[ChunkSize - 3];
    }
    */
};
actually it points to _TlgProviderMetadata_t.RemainingSize. Algo is simple - if you know provider GUID you can locate _TlgProviderMetadata_t.ProviderId by signature (usually located in .text or .rdata sections) and then find in .data section _TlgProvider_t whose ProviderMetadataPtr points to _TlgProviderMetadata_t.RemainingSize. I made simple PoC for arm64

How we can abuse it? Let`s see how this structures used for example in combase.dll:

what`s wrong with Etw

Disclaimer: as I am aware that the given code examples can be dangerous for Etw-based EDR products - all code was made for least popular version of windows - for arm64

Let's assume that we have some application that wants to hide its activity from trace logs - not necessary evil or malicious, for example just to hide used algos or bit paranoid like crypto-wallet. Lets see how can it achieve this (I have no desire to consider trivial cases like removing records from eventlog)

Semiofficial ways

1. Sure all you readed about COMPlus_ETWEnabled but there is also promising COMPlus_ETWFlags 
2. You can switch off etw tracing for services.exe with registry key TracingDisabled in Software\Microsoft\Windows NT\CurrentVersion\Tracing\SCM\Regular
3. And the same for rpcrt4.dll with registry key ExtErrorInformation in HKLM\Software\Policies\Microsoft\Windows NT\Rpc

Actually there are virtually countless ways to do it. And many perhaps not documented bcs was written in Ms by some poor intern who was kicked out in the cold after another review 10+ years ago. I struggled with temptation to make clickbait caption like "99% of windows dlls can disable etw logs" but it`s close to the truth

Patching

search references in arm64 code

Let's assume that you want to find address of non-exported CrashdmpCallTable in kernel. Usual old school way is to find unicode string "\SystemRoot\System32\Drivers\crashdmp.sys" and then to find reference to in .text section - if you are lucky enough this will be somewhere in middle of function IopLoadCrashdumpDriver. But on arm64 loading of address splitted in pair of instructions and even worse - values depends from address of instruction. Let`s see how it looks:

.text:00000001401AF700 6A 01 00 90     ADRP  X10, #aSystemrootSy_0@PAGE ; "\\SystemRoot\\System32\\Drivers\\crashd"...
.text:00000001401AF704 48 C1 09 91     ADD   X8, X10, #aSystemrootSy_0@PAGEOFF ; "\\SystemRoot\\System32\\Drivers\\crashd"...

Output from cmdline disasm for each of opcodes:
armpatched.exe 6A010090
Disassembled: adrp x10, 2c000
        This instruction is AD_INSTR_ADRP and is part of group AD_G_DataProcessingImmediate
        This instruction has 4 decode fields (from left to right):
                0x1, 0, 0xb, 0xa
        This instruction has 2 operands (from left to right):
                This operand is of type AD_OP_REG
                        Register: x10 size 40
                This operand is of type AD_OP_IMM
                        Immediate type: AD_IMM_ULONG
                        Value: 0x2c000
and
armpatched.exe 48C10991
Disassembled: add x8, x10, #0x270
        This instruction is AD_INSTR_ADD and is part of group AD_G_DataProcessingImmediate
        This instruction has 7 decode fields (from left to right):
                0x1, 0, 0, 0, 0x270, 0xa, 0x8
        This instruction has 3 operands (from left to right):
                This operand is of type AD_OP_REG
                        Register: x8 size 40
                This operand is of type AD_OP_REG
                        Register: x10 size 40
                This operand is of type AD_OP_IMM
                        Immediate type: AD_IMM_ULONG
                        Value: 0x270

What are the options?

sve/sve2 instructions for arm64

Today I finished adding of sve/sve2 instructions to my pet-project armpatched
I used as reference ISA_A64_xml_futureA-2019-09_OPT.pdf
Sure code is full of bugs, incomplete and has terrible style - all what you can expect from 7KLOC on plain C
Known problems:

• since my main goal was code analysis disasm strings looks not very good - for example I totally emit register size suffixes (although size storing in op_reg.sz)
• I don`t know for what used "fields" so they filled in voluntary random order

Zx registers marked as floating point with op_reg.fp == 2 and Px registers with op_reg.fp == 3
Code was tested on all possible instructions and looks like it does not crash. Bcs it seems that some instructions use floating point you must use KeSaveFloatingPointState/KeRestoreFloatingPointState in case of kernel mode

arm64 pc-relative literals

Lets see for example non-exported function function SepInitializeCodeIntegrity from arm64 kernel:
  STP             X19, X20, [SP,#-0x20+var_10]!
  STP             X21, X22, [SP,#0x10+var_s0]
  STR             X23, [SP,#0x10+var_s10]
  STP             X29, X30, [SP,#0x10+var_20]!
  MOV             X29, SP
  ADRP            X8, #SeCiCallbacks@PAGE
  ADD             X20, X8, #SeCiCallbacks@PAGEOFF
  ADD             X8, X20, #4
  MOV             W21, #6
  ADD             X9, X8, #0xC0
loc_1406A9C90                           ; CODE XREF: SepInitializeCodeIntegrity+30 j
  STP             XZR, XZR, [X8],#0x10
  CMP             X8, X9
  B.NE            loc_1406A9C90
  STR             WZR, [X8]
  MOV             W9, #0xD0
  LDR             X8, =0xA000007
…
qword_1406A9D30 DCQ 0xA000007

As you can see all DWORD constants under arm64 stored in some place after function, so you sure can find address 1406A9D30 but how to find function which using this constant? Instruction ldr can be located in range of 1Mb from this address

undocumented env vars in mscorwks.dll

There are lots of env vars with prefix COMPlus_
So lets see only not presented in this document

Main function constructing name of env var is ?EnvGetString@REGUTIL@@SAPEAGPEBGH@Z called from:

• ?UnsafeGetConfigDWORD@@YAKPEBGK@Z
• ?GetConfigDWORD@EEConfig@@SAKPEBGKKHW4ConfigSearch@1@@Z
• ?GetConfigString@EEConfig@@SAJPEBGPEAPEAGHW4ConfigSearch@1@@Z
• ?init@ConfigDWORD@@AEAAXPEAGK@Z
• ?GetConfigString@REGUTIL@@SAPEAGPEBGHW4CORConfigLevel@1@@Z
• ?GetConfigDWORD@REGUTIL@@SAKPEBGKW4CORConfigLevel@1@H@Z

and perhaps from several thousand more places so I wrote some script to collect names and filter out known. Final list is:

• AllowStrongNameBypass - DWORD
• AssemblyUsageLogImpersonateUser - DWORD
• BBSweep - DWORD
• BreakOnAV - DWORD
• bypassTrustedAppStrongNames - DWORD
• Cor_Enable_Profiling - DWORD
• DbgJITDebugLaunchSetting - DWORD
• DbgManagedDebugger - string
• DbgThreadCreateOption - DWORD
• DisableDoubleMapping - DWORD
• DisableSecurityTransparency - DWORD
• EagerWatsonBuckets - DWORD
• EHGolden - DWORD
• JumpStubReserve - DWORD
• legacyAssemblyProvidedEvidence - DWORD
• legacyHMACWarning - DWORD
• legacyMyComputerZone - DWORD
• legacyV1CASPolicy - DWORD
• LOPFriendlyFrames - DWORD
• MD_TrackColDesMisses - DWORD
• MemoryReport - DWORD
• MemoryReportBreakOnContext - string
• MemoryReportOutput - string
• MemoryReportStackFrames - DWORD
• MemoryReportSweepInterval - DWORD
• MultiDomainHostGAC - DWORD
• NGenAllowMsiInstall - DWORD
• PrecodeInCodeHeap - DWORD
• ReaderWriterLock_UseFixedIdGeneration - DWORD
• ShowMetaDataAccess - DWORD
• StressLoadThreadCount - DWORD
• useEnUSLcidWithComInvoke - DWORD
• UseFileMappingForByteArrays - DWORD
• UseMethodDataCacheInFindDispatchImpl - DWORD
• UsePcRel32Calls - DWORD
  

COMPlus_ETWEnabled

There is nice trick to hide that your .NET assemblies does not have ETW logging
Lets see if we can detect this not from environment vars
ETW logging inited in mscorwks.dll!CEtwTracer::Register:

kernel pte in windows 10 64bit

Quarantine is a good time to re-read some old but useful papers and check if you can catch trick with making KUSER_SHARED_DATA writable again So lets see what we need:

• some logic to extract PTE base from MiGetPteAddress
• primitive to check if some address is valid - I used MmIsAddressValid
• primitive to read page from kernel memory

Start with some system info:

pSystemRangeStart: FFFF800000000000

PTE base address: FFFF880000000000

PTE mask: 7FFFFFFFF8

PTE shift: 9

Do some calculation

function to get offset to PTE looks like:

return (address >> 9) & 0x7FFFFFFFF8;

for pSystemRangeStart PTE will be
4000000000 + pte_base = FFFF884000000000

You may notice that this address located above pte_base

for last available address in system FFFFFFFFFFFFFFFF PTE will be
7FFFFFFFF8 + pte_base = FFFF887FFFFFFFF8

Also we need some inverse function to convert from PTE to page address. First we need sub pte_base, then divide on sizeof(MMPTE_HARDWARE) and then multiply to size of page. And add some base address. Try to calculate this base for example for PTE of pSystemRangeStart FFFF884000000000:
(FFFF884000000000 - FFFF880000000000) / sizeof(MMPTE_HARDWARE) * 0x1000 = 800000000000

Our base is FFFF800000000000 (value of pSystemRangeStart) - 800000000000 = FFFF000000000000

Notice that this base does not match with pSystemRangeStart
So our inverse function may looks like:
return 0xFFFF000000000000 + (ptr_addr - pte_base) / sizeof(MMPTE_HARDWARE) * 0x1000;

Ok, it seems that we have all puzzle pieces and can scan all PTE from FFFF884000000000 to FFFF887FFFFFFFF8. Yes, all 0x4000000000 bytes - 256Gb. Sure, we can wait for results before retirement

afd endpoints owner

Alex and Yarden as usually made perfect work to bypass even paranoid EDRs
The main problem is detection of duplicated sockets. There is a hint however:

all ownership of the socket still belongs to the original creator – even when the creator exists (and actually, because Netio.sys is still referencing the original EPROCESS, the creator and the PID become “zombies” and leak resources).

o`k, reason is true, but reference holds by afd.sys. Lets see why
We need disasm 2 functions to write simple script. First - we need back offset from afd!AfdEndpointListHead to read endpoint. It can be extracted from AfdIsAddressInUse:
  mov     [rsp+arg_0], rbx
  mov     [rsp+arg_8], rbp
  mov     [rsp+arg_10], rsi
  push    rdi
  sub     rsp, 30h
  mov     rsi, rcx
  xor     ebx, ebx
  mov     rcx, cs:AfdGlobalData
  call    cs:__imp_ExEnterCriticalRegionAndAcquireResourceShared
  nop     dword ptr [rax+rax+00h]
  mov     rdi, cs:AfdEndpointListHead
  lea     rbp, AfdEndpointListHead
  jmp     short loc_1C003C0D3
; ---------------------------------------------------------------------------
loc_1C003C054:                          ; CODE XREF: AfdIsAddressInUse+BE

  lea     rdx, [rdi-120h]

...

loc_1C003C0D3
  cmp     rdi, rbp
  jnz     loc_1C003C054

Then we need offset to EPROCESS - it can be extracted for example from AfdFreeEndpointResources:

  mov     rcx, [rbx+28h]
  mov     edx, 200h
  call    cs:__imp_PsReturnPoolQuota
  nop     dword ptr [rax+rax+00h]
  mov     rcx, [rbx+28h]  ; Object
  call    cs:__imp_ObfDereferenceObject

Now we have all parts of this puzzle. Let`s see what we can do in windbg

PsKernelRangeList on arm64 kernel

can be found using the same old trick
Sure constants are now different, so now KUSER_SHARED_DATA.SystemCall is 0xFFFFF78000000308 and KUSER_SHARED_DATA.ProcessorFeatures is 0xFFFFF78000000274

Commited today simple logic to find and parse it in my armpatched

IDA Pro plugin for arm64 switch tables processing

IDA Pro supports arm64 very poorly - it also cannot parse switch tables. Let`s see how they looks on arm64 - for example in function NtQueryInformationThread:
 CMP             W1, #0x2D           ; check index
 B.HI            loc_140673294
 ADR             X9, dword_14066E9EC ; switch tab address
 LDRSW           X8, [X9,W1,UXTW#2]  ; index in W1 << 2
 ADR             X9, loc_14066E358   ; base address
 ADD             X8, X9, X8,LSL#2    ; base address + offset << 2
 BR              X8
What happens here? first "ADR x9, addr" loads address of switch table
Next LDRSW is like "mov x8, [x9 + 4 * w1]" on Intel - load DWORD at x9 + index w1 left shifted by 2
Then second ADR loads address of base for this switch table
ADD x8, x9, x8 << 2 sets in x8 address of actual jumps
and finally BR go to this address

So I just wrote quick and dirty plugin arm64sw.p64 based on armpatched for switch tables processing

KiTpExcludedRoutines

As you can guess from name this is array of functions for which you can`t set kernel tracepoint. Curious that this lists differs in x64 and arm64
x64

bug in ida pro arm64 module

Lets see in ida pro some arm64 windows kernel, for example good old function PspSetCreateThreadNotifyRoutine:
 ADRP            X8, #PspNotifyEnableMask@PAGE
 ADD             X11, X8, #PspNotifyEnableMask@PAGEOFF
 TBNZ            W20, #0, loc_140690960
 ADD             X10, X11, #0x33C

register x11 contains address of PspNotifyEnableMask - in my case this is 0x1408AE6B0 and then x10 loading address of PspNotifyEnableMask + 0x33c = 0x1408AE9EC - this is actually PspCreateThreadNotifyRoutineCount. And no - you cannot fix last instruction with pressing O or Ctrl + O
Given that cross-refs in arm64 is highly dependent from correct code analysis - this is very annoing
Tested in ida pro 6.9 and 7.2

armpatched

Several days ago I started my new pet project on GitHub, bcs

• quarantine is boring
• reading a book "ARM 64-Bit Assembly Language" without practice is useless

So I just forked arm64 disasm called armadillo, ported it on windows, added naïve pe loader (btw attempt to use MapViewOfFile function was unsuccessful with GetLastError 1132) and today add some practical usage of static code analysis to extract lists and lock of lookaside lists from arm64 windows kernel

Main magic happens in ntoskrnl_hack::find_lock_list function

static code analysis

This cool article is good case to show how you can employ static code analysis for extracting some unexported symbols from binary code - in this case we need ExNPagedLookasideLock & ExNPagedLookasideListHead

Sure the first thing you need is disassembler. If you search at GitHub "x86 disasm" you will get something about 20 repositories, but we need one that satisfies some requirements:

• disasm to some intermediate code and not in string output
• can be used in kernel mode (just in case if you want to do it) which means that it must be written in C

So just choose the one with the most comprehensible code - bcs they all contains bugs and you anyway will fix them and/or add missed instructions

Lets start with exported function ExInitializeNPagedLookasideList. Simplest cases - xp 64bit:

VfDifThunks

It seems that in w10 build 19569 new verifier table has appeared - VfDifThunks along with new exported function DifRegisterPlugin (which is used only in VerifierExt.sys for now). List of intercepted functions:

fltmgr.GLOBALS!PerfTraceRoutines

In windows 8 in fltmgr was introduced feature for filter operation Etw logging - structure WMI_FLTIO_NOTIFY_ROUTINES in GLOBALS:
 void  (TimeStampRoutine*)(struct _ETW_KERNEL_TRACE_TIMESTAMP*, unsigned long);
 void  (FailureNotifyRoutine*)(void*, unsigned long, unsigned long, unsigned short);
 void  (InitiationNotifyRoutine*)(void*, unsigned long, unsigned long, unsigned short);
 void  (CompletionNotifyRoutine*)(void*, unsigned long, unsigned long, unsigned short, struct _ETW_KERNEL_TRACE_TIMESTAMP*);

 void  (FastCompletionNotifyRoutine*)(void*, unsigned long, unsigned long, unsigned short, struct _ETW_KERNEL_TRACE_TIMESTAMP*);

in windows 10 new entry was added:
void  (IoRedirectionNotifyRoutine*)(struct _IRP*, struct _FILE_OBJECT*);

This structure initialized in DriverEntry - PerfTraceRoutines assigned address of GLOBALS.DummyPerfTraceRoutines and then called function WmiQueryTraceInformation with class FltIoNotifyRoutinesClass (where this structure filled with content of EtwpFltIoNotifyRoutines)
So patching this functions pointers you can have real-time info about operations in file filters (or perhaps disable Etw logging for them)

On freshly installed system only two pfns are initialized:

W32pServiceTable from windows 10 build 19577 64bit

W32pServiceLimit .eq. 0x5AD
Btw what does prefix NtModerncore mean?

PiPnpRtlCtx

since w8 Microsoft introduced for PnP devices management new structure with lots of function pointers - PiPnpRtlCtx

It`s called from lots of exported functions, but I think most comfortable for RE are IoOpenDeviceRegistryKey & IoOpenDeviceInterfaceRegistryKey. You can gather address of PiPnpRtlCtx with one pass of disassembling - it will be first loaded address in .data section after call to ExAcquireResourceExclusiveLite

This structure allocating and partially initializing in function PnpCtxOpenMachine. There are at least 3 version with different size:

• 0xac for 32 bit/0x158 for x64 - used in w8, w8.1 and in w10 up to est.build 14279
• 0xb0 for 32 bit/0x160 for x64 - used in w10 up to est. build 16299
• 0x10c for 32 bit/0x210 for x64 - used in w10 since est. build 17134

This struct has lots of pointer to functions (see also PiPnpRtlInit):

using devm_kcalloc unchecked result in linux kernel

Part I
This time I add references to linux kernel github - although I ran my naive code analyzer on version 4.18 - all found bugs have long and happy life in current source tree

gb_generate_enum_strings in drivers/staging/greybus/audio_topology.c:
strings = devm_kcalloc(gb->dev, items, sizeof(char *), GFP_KERNEL);
data = gbenum->names;

for (i = 0; i < items; i++) {
  strings[i] = (const char *)data;

rt2880_pinmux_pins in drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c:  
p->func[i]->pins = devm_kcalloc(p->dev,
                p->func[i]->pin_count,
                sizeof(int),
                GFP_KERNEL);
for (j = 0; j < p->func[i]->pin_count; j++)
  p->func[i]->pins[j] = p->func[i]->pin_first + j;

Using unchecked result from devm_kmalloc_array:
ti_sci_scan_clocks_from_fw in drivers/clk/keystone/sci-clk.c:
tmp_clks = devm_kmalloc_array(dev, max_clks + 64,
                  sizeof(sci_clk),
                  GFP_KERNEL);
memcpy(tmp_clks, clks, max_clks * sizeof(sci_clk));

Doubtful case (I think is has delayed effects bcs no checks for ports field) - function mscc_ocelot_probe in drivers/net/ethernet/mscc/ocelot_board.c
ocelot->ports = devm_kcalloc(&pdev->dev, ocelot->num_phys_ports,
                     sizeof(struct ocelot_port *), GFP_KERNEL);

using devm_kzalloc unchecked result in linux kernel 4.18

Managed Device Resource (described in Documentation/driver-model/devres.txt) is witty technique for lazy developers. Unfortunately it does not exempt from the need to check results. I decided to see if there are such places in linux kernel (which can lead to null address dereference). Right way to do it is use Static Analyzer like clang, coverity or PVS Studio. But I am too lazy so I wrote simple and naive perl script and run it on linux kernel 4.18 source tree. It found 56 cases (from total 4173 where devm_kzalloc was used) - not too much for manual checking. So lets see what we have

impd1_probe in arch/arm/mach-integrator/impd1.c:
            lookup = devm_kzalloc(&dev->dev,
                          sizeof(*lookup) + 3 * sizeof(struct gpiod_lookup),
                          GFP_KERNEL);
            chipname = devm_kstrdup(&dev->dev, devname, GFP_KERNEL);
            mmciname = kasprintf(GFP_KERNEL, "lm%x:00700", dev->id);
            lookup->dev_id = mmciname;


st_sensors_of_probe in drivers/iio/common/st_sensors/st_sensors_core.c (still not fixed):
    pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
    if (!of_property_read_u32(np, "st,drdy-int-pin", &val) && (val <= 2))
        pdata->drdy_int_pin = (u8) val;
    else
        pdata->drdy_int_pin = defdata ? defdata->drdy_int_pin : 0;

    pdata->open_drain = of_property_read_bool(np, "drive-open-drain");


sm501_register_gpio_i2c_instance in drivers/mfd/sm501.c:
    lookup = devm_kzalloc(&pdev->dev,
                  sizeof(*lookup) + 3 * sizeof(struct gpiod_lookup),
                  GFP_KERNEL);
    lookup->dev_id = "i2c-gpio";
    if (iic->pin_sda < 32)
        lookup->table[0].chip_label = "SM501-LOW";
    else
        lookup->table[0].chip_label = "SM501-HIGH";
    lookup->table[0].chip_hwnum = iic->pin_sda % 32;
    lookup->table[0].con_id = NULL;
    lookup->table[0].idx = 0;
    lookup->table[0].flags = GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN;

rt2880_pinmux_index in drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c (still not fixed):
            f[c]->groups = devm_kzalloc(p->dev, sizeof(int), GFP_KERNEL);
            f[c]->groups[0] = i;

rt2880_pinmux_probe in drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c: 

        range = devm_kzalloc(p->dev, sizeof(struct pinctrl_gpio_range) + 4, GFP_KERNEL);
        range->name = name = (char *) &range[1];
        sprintf(name, "pio");
        range->npins = __be32_to_cpu(*ngpio);
        range->base = __be32_to_cpu(*gpiobase);
        range->pin_base = range->base;




rt5514_spi_pcm_probe in sound/soc/codecs/rt5514-spi.c:
    rt5514_dsp = devm_kzalloc(component->dev, sizeof(*rt5514_dsp),
            GFP_KERNEL);

    rt5514_dsp->dev = &rt5514_spi->dev;
    mutex_init(&rt5514_dsp->dma_lock);


rt5663_parse_dp in sound/soc/codecs/rt5663.c (still not fixed):
        rt5663->imp_table = devm_kzalloc(dev, table_size, GFP_KERNEL);
        device_property_read_u32_array(dev,
            "realtek,impedance_sensing_table",
            (u32 *)rt5663->imp_table, table_size);


perl script used to find this bugs:

typos in "Linux Device Drivers Development"

I decided in retirement to fill the gaps in my education, so now I reading book "Linux Device Drivers Development" and noticed lots of annoying typos in code samples

page 65:
/* some where */
spinlock_t my_spinlock;
spin_lock_init(my_spinlock);
static irqreturn_t my_irq_handler(int irq, void *data)
{
 unsigned long status, flags;
 spin_lock_irqsave(&my_spinlock, flags);
 status = access_shared_resources();
 spin_unlock_irqrestore(&gpio->slock, flags); // wut? &my_spinlock
 return IRQ_HANDLED;
}

page 103-104:
struct my_data {
 int my_int_var;
 struct tasklet_struct the_tasklet;
 int dma_request;
};

static irqreturn_t my_irq_handler(int irq, void *dev_id)
{
  struct my_data *md = dev_id;
  /* Let's schedule our tasklet */
  tasklet_schedule(&md.dma_tasklet); // wut? &md->the_tasklet
  return IRQ_HANDLED;
}
 
page 127:
/* Move the cursor ten time, relative from the beginning of the file */
if (lseek(fd, 7, SEEK_SET) < 0)
return 1;

An so on. Seems that code samples looks like Frankenstein ripped from some random kernel places