Programming thread

It's important to understand that most people are absolute niggercattle who think installing an ad blocker on their browser is a bigger inconvenience than wasting thousands of hours of their time on ads over the years.

Windows definitely had a decline in quality internally, post Windows 8.1.

8.1 kernel wise was pretty solid, they introduced some nice new cache aware locking primitives, introduced NonPagedPoolNx. It might have also been the last version of windows to offer a completely checked build, can't remember. Also maybe it was before 8.1 but they added the minifilter driver type which solved the issue of 3000 nested filesystem filters blowing the kernel stack

Since 10 though there has been a huge decline.
The 20000 new UI frameworks they add end up breaking legacy programs. case and point balloon tip notifications used to show an ico properly sized. If you enable bitlocker on win11 you'll see a pixelated toast notification whereas in 10 it's fine.

Also... Enabling info level logging in windbg, why the fuck do windows drivers spit out verbose logging in their release builds.

Rant over lol
 
the funny thing about windows nt is that it seems it was initially designed incredibly well by incredibly smart people
then of course since it's microsoft they get armies of slavedriver phbs in to herd millions of pajeets into making the most godawful clusterfuck known to man
microsoft actually made several kernels with even more ambitious design than nt but they went nowhere because (my guess based on absolutely nothing: they just can't port that shit)

that's how many soydev megacorps work: they get a team of incredibly smart people to build something amazing then they decide to use the least sustainable streetshitter methodologies to do the other 99%
and that's why the kernel is nice and solid, but nobody cares since the operating system built on top is so shitty, people just use a certain monolithic unix clone for everything

side note: what if we had an operating system design thread (not to be confused with the i&t threads where people argue endlessly about which combination of apt repo and de is best) (we can be the i&t thread where people argue endlessly about whether tanenbaum or linus were right or something)
 
the funny thing about windows nt is that it seems it was initially designed incredibly well by incredibly smart people
NT kernel isn't bad... It has the obvious cruft from having to be backwards compatible for old ME and 98 drivers. You'll see a lot of EX and EX2 suffixed structs and functions which began obviously as a way to introduce new shit which required ABI breaks to work. A hidden constraint is that APIs are also expected to BEHAVE the same, likely because people relied on their specific wacky behaviour

On linux are they forced to be under the same constraints? someone more knowledgeable than me can probably answer

I lament that Windows was never able to implement SMEP and SMAP into the kernel.

As such pajeet-coded drivers that use user mode supplied pointers! in their ioctl buffers are super vulnerable to kernel mode RCE, believe me this practice is scarily common in third party drivers.

side note: what if we had an operating system design thread (not to be confused with the i&t threads where people argue endlessly about which combination of apt repo and de is best) (we can be the i&t thread where people argue endlessly about whether tanenbaum or linus were right or something)
Are you referring to the microkernel vs monokernel debacle. There are basically two schools of thought. Monokernels have obviously emerged as the victor in terms of what systems have been widely adopted.

There is another school of thought where ultimately you get the fence sitter answer of "it depends on your workload".
 
On linux are they forced to be under the same constraints? someone more knowledgeable than me can probably answer
Ironically linux tended to be a bit more forward looking, and tended to forgo short term convenience for some relative philosophical purity in the design

Windows was always quick and dirty, and to be honest they always had the capacity and the skill to do the heavy duty refactors needed to keep their kernel viable while still doing new things, and had a good system for maintaining backward compatibility while doing so to boot.

What allowed linux to catch up in terms of normie usability and features was replacing all the white people with indians.
 
On linux are they forced to be under the same constraints? someone more knowledgeable than me can probably answer
iirc breaking kernelspace api compatibility is/was a proud tradition of the linux niggers, don't quote me on this though
and i'm reasonably sure that abis aren't sacred at all, because if they weren't then why would dkms exist
fortunately for userspace breaking api or abi compatibility is a felonious act and you will enjoy prison for felony low-quality code. wait for the patch rejection mail, stalker
As such pajeet-coded drivers that use user mode supplied pointers! in their ioctl buffers are super vulnerable to kernel mode RCE, believe me this practice is scarily common in third party drivers.
does this mean that random unprivileged programs have many ways to start exploit chains as long as you're using some no-name chinese niggeripheral with really sloppy programming and were stupid enough to install the driver from the website?
 
does this mean that random unprivileged programs have many ways to start exploit chains as long as you're using some no-name chinese niggeripheral with really sloppy programming and were stupid enough to install the driver from the website?
In short yes lol. Sometimes you might have have to send a user mode pointer nested in a driver ioctl struct, why? Not sure. Stupidity most likely. You can do METHOD_DIRECT for large buffers.

The way you are SUPPOSED to handle this is by validating the pointer's address and ensure it belongs to usermode address space which is where the kernel mode RCE stuff comes in.

All of THAT needs to also be wrapped in a exception handler because the user mode address can be at any point dereferenced because of a cleanup or whatever and on top of that there's the potential the pointer could get mutated into a different address asynchronously defeating our first probe.

Here's the ugly solution...

C:
typedef struct _USER_DATA {
    PULONG_PTR Data1;
    PULONG_PTR Data2;
} USER_DATA, *PUSER_DATA;
NTSTATUS
Foo(
    PUSER_DATA Data
    )
{
    PULONG_PTR CapturedData1;
    ULONG_PTR Data1Value;
    PULONG_PTR CapturedData2;
    ULONG_PTR Data2Value;
 
    //
    // See if this is user mode - in a driver PreviousMode
    // would normally be read from a field in the IRP and the
    // pointer would come from the Type3InputBuffer field, but
    // for simplicity's sake we will just use parameters directly
    //
    if (ExGetPreviousMode() != KernelMode) {
 
        try {
            //
            // Probe the passed in structure
            //
            ProbeForRead(Data,
                         sizeof(USER_DATA),
                         __alignof(USER_DATA));
            //
            // Capture the embedded pointers
            //
            CapturedData1 = Data->Data1;
            CapturedData2 = Data->Data2;
            //
            // Probe the first captured pointer
            //
        
            ProbeForRead(CapturedData1,
                         sizeof(ULONG_PTR),
                         __alignof(ULONG_PTR));
        
            //
            // Probe the second captured pointer
            //
        
            ProbeForRead(CapturedData2,
                         sizeof(ULONG_PTR),
                         __alignof(ULONG_PTR));
            //
            // Read the first embedded pointer
            //
            Data1Value = *CapturedData1;
            //
            // Read the second embedded pointer
            //
            Data2Value = *CapturedData2;
            //
            // More of your code here that does really cool stuff...
            //
        } except (EXCEPTION_EXECUTE_HANDLER){
            return GetExceptionCode();
        }
    }
    return STATUS_SUCCESS;
}
But wait... There's actually a problem here... The compiler might just optimise away our local copying of the capturedData pointers. Which is bad because as mentioned those supplied pointers might get mutated even after first probe... The solution is to assign our local copies by casting the user supplied pointers as volatile.

C:
NTSTATUS
Foo(
    volatile USER_DATA * Data
    );
C:
     //
     // Read the first embedded pointer
     //

     Data1Value = *(volatile ULONG_PTR*)CapturedData1;


     //
     // Read the second embedded pointer
     //

     Data2Value = *(volatile ULONG_PTR*)CapturedData2;
This ensures no funny compiler business.

As you'd expect it's rare to see this kind of thing implemented correctly and because of that there's a good chance your anticheat, antivirus, even web filtering software on windows have effectively made you hugely compromised. It doesn't get much worse than kernel mode RCE.
 
From what I know pretty much every kernel has to validate pointers from usermode and make sure they don't get randomly mutated. I'd expect a lot of kernels have an abstraction for things like this, though. This is Windows, of course, so it's part of their standard practice of always exposing massive security holes, unless you know exactly what you're doing and have deep, intricate knowledge of the Windows/NT system; or, as I have come to refer to it, Reskinned Chromium+UWP+.NET+Win32+NT+cthulhu3&knuckles.
As you'd expect it's rare to see this kind of thing implemented correctly and because of that there's a good chance your anticheat, antivirus, even web filtering software on windows have effectively made you hugely compromised. It doesn't get much worse than kernel mode RCE.
anyway lmao imagine installing random kernel modules so you can play vidya or "protect" your computer against windows swiss cheese security or block connections to whichever domains

quick question: why are you casting the pointers to volatile instead of declaring some of the variables volatile?
 
From what I know pretty much every kernel has to validate pointers from usermode and make sure they don't get randomly mutated. I'd expect a lot of kernels have an abstraction for things like this, though. This is Windows, of course, so it's part of their standard practice of always exposing massive security holes, unless you know exactly what you're doing and have deep, intricate knowledge of the Windows/NT system; or, as I have come to refer to it, Reskinned Chromium+UWP+.NET+Win32+NT+cthulhu3&knuckles.
True, but on windows there is no SMAP/SMEP which is hardware level protection which will cause a page fault. Linux and the BSDs have completely eliminated the kernel mode RCE shit while Windows is still plagued by it, to add insult to injury Windows still allows ancient drivers with dubious security practices to load on it.

At worst on linux or the BSDs depending on how they handle the aforementioned SMAP violation you'll maybe at worst get a DoS CVE.

As such it's so much more critical to get user mode pointer validation right, the stakes are extremely high.
quick question: why are you casting the pointers to volatile instead of declaring some of the variables volatile?
Intent was I wanted to mark the captured pointers themselves as being subject to change outside of the compiler's knowledge and ask it to please not change the memory ordering, do not make any optimisation assumptions and also please do this at the "capture site"
C:
     //
     // Capture the embedded pointers
     //

     CapturedData1 = ((volatile USER_DATA*)Data)->Data1;
     CapturedData2 = ((volatile USER_DATA*)Data)->Data2;
I've changed my original snip a little bit to make it a bit more clear we're capturing a value from the user mode supplied pointers and the "capture site" (deref) is what needs the special casting. But maybe the way you are perhaps thinking may produce the intended behaviour too, would need to experiment lol

Side note: I wonder if any knowledgeable Rustfags could show me how this would work with their language, only curious as I am a crusty old Cnile who is learning bits of Rust.
 
Last edited:
  • Informative
Reactions: Creative Username
True, but on windows there is no SMAP/SMEP which is hardware level protection which will cause a page fault. Linux and the BSDs have completely eliminated the kernel mode RCE shit while Windows is still plagued by it, to add insult to injury Windows still allows ancient drivers with dubious security practices to load on it.

At worst on linux or the BSDs you'll manage depending on how they handle the aforementioned SMAP violation you'll maybe at worst get a DoS CVE.
Nice to know that they have actual layers of defense instead of just hoping pajeet driver writers get it right (they don't)
Intent was I wanted to mark the captured pointers themselves as being subject to change outside of the compiler's knowledge and ask it to please not change the memory ordering, do not make any optimisation assumptions and also please do this at the "capture site"
this magic is too deep for me and i should probably not write any nt drivers today (if i did i would try to declare things as volatile at first and after taking a look at the assembly or something i could try casting if that doesn't work, because i generally feel like it's a good idea to avoid casts)
 
Nice to know that they have actual layers of defense instead of just hoping pajeet driver writers get it right (they don't)
For some reason which I've never quite fathomed a lot of windows driver developers are indian, chink or slavic. It's more or less a dying art now though.

Funny thing actually, Microsoft themselves ended up asking our company what Microsoft can do to prevent the crowdstrike thing from happening again.

Most sensible thing I could suggest was adopting more notification events for things like filter drivers to subscribe to and perhaps proxying some kernel mode drivers out to third party user mode services. Ala FUSE but for more shit. Obviously the caveat would be performance degradation with those extra context swaps.
this magic is too deep for me and i should probably not write any nt drivers today (if i did i would try to declare things as volatile at first and after taking a look at the assembly or something i could try casting if that doesn't work, because i generally feel like it's a good idea to avoid casts)
Ah. Define a "cast" 🙂. Strictly speaking a PVOID -> PDATA is a (implicit) cast and is super widespread. I'll stop be facetious though and agree, pointer aliasing is to be avoided if possible.
 
  • Like
Reactions: y a t s
Does anybody know if Codester and Code Canyon are profitable?

Im not getting call backs on my applications but I found those websites and I got some stuff I've made that I could clean up and sell as templates.
 
perhaps proxying some kernel mode drivers out to third party user mode services. Ala FUSE but for more shit. Obviously the caveat would be performance degradation with those extra context swaps.
micromaxxing gigachads understand that everything living in ring 0 causes crowdstrike bullshit, so they gladly take the performance hits
Ah. Define a "cast" 🙂. Strictly speaking a PVOID -> PDATA is a (implicit) cast and is super widespread. I'll stop be facetious though and agree, pointer aliasing is to be avoided if possible.
c is a very double-edged language, and as your pointer lunacy starts to look like perl, you should get careful
it can be moderately readable (and consequently, more safe) if you try to follow along with c's limited type system as much as you can and only break it using the most standard idioms possible
prospective c programmers in the thread, never forget the scariest horror story you can tell in 3 words: "creative pointer arithmetic"
 
Side note: I wonder if any knowledgeable Rustfags could show me how this would work with their language, only curious as I am a crusty old Cnile who is learning bits of Rust.
i assume if the same pajeets who write horribly unsafe c start using rust for this kind of thing, it will involve a lot of this:
C-like:
unsafe {
...
 
I think that honor should go to the unholy beast that is JSFuck.

Here's the JSFuck version of alert(1):
JavaScript:
[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]][([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((!![]+[])[+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+([][[]]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+!+[]]+(+[![]]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+!+[]]]+(!![]+[])[!+[]+!+[]+!+[]]+(+(!+[]+!+[]+!+[]+[+!+[]]))[(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([]+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]][([][[]]+[])[+!+[]]+(![]+[])[+!+[]]+((+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[+!+[]+[+!+[]]]+(!![]+[])[!+[]+!+[]+!+[]]]](!+[]+!+[]+!+[]+[!+[]+!+[]])+(![]+[])[+!+[]]+(![]+[])[!+[]+!+[]])()((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[+!+[]+[!+[]+!+[]+!+[]]]+[+!+[]]+([+[]]+![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[!+[]+!+[]+[+[]]])
Throw it in the browser dev tools console and give it a try. Make sure you're on a site that doesn't restrict the function calls due to CSP, such as duckduckgo. It won't work on the forums here.
 
people chastise c++ for having extensive, complicated, and weird turing complete macros bolted on over c's barely-enough-to-work text substitution macros, but javascript wins the fucked language competition yet again by accidentally having a turing-complete esoteric language erupting out of its heavily retarded type system

nobody had to make this horror it was simply discovered within the treacherous insanity of javascript
 
Back