musjleman

Why is this AI slop here? The "author" deleted his twitter account and added the disclaimer at the top of this post that it's all written by AI and he's not an actual "programmer or reverse engineer".

The fact that nonsense like this gets likes amazes me. You take an emulator, you know a thing whose entire purpose is to evaluate instructions without actually executing them, "bypass" something with overcomplicated and unnecessary hardware breakpoints usage (what exactly is the point of not just catching the access violation instead? Or why do you need to cause an exception at all to emulate the instructions?) and release it with some awful POC that's also AI generated.

An interpreter for a machine language is usually just called an emulator.

I'm pretty sure it's just a small mistake in the article on the exact syscall used to query the token information.

Checked a kernel from November 2024 vs a current one and from I can tell, this used to be the actual mechanism the exploit worked:

  Thread #1 looping
    NtQueryInformationToken(TokenAccessInformation, InfoBuffer);
  
  Thread #2 looping
    Ptr = *(InfoBuffer + SidHashOffset);
    if (IsValidCanonicalKernelPtr(Ptr))
      done

SRW lock uses the WaitOnAddress primitives nowadays, not keyed events.

Yes and no.

The GTA SA bug was reading of an uninitialized variable. The value it contained was correct simply by chance as it was placed there by the previous invocation of the function and never overwritten by something else intermittently. Any changes to functions that happened to be called in between these 2 could have changed the value of the stack memory.

The aforementioned check on the other hand is placing random value below the stack pointer. This means that by design it cannot call any external/os/game functions and is basically isolated/"pure" from any interactions with third party code.

> The anti-tamper codes, if any tampering is detected will crash on undefined/unallocated regions.

That's basically the whole point of any anti-tamper product. I just think you picked a terrible example of a feature that could break due to OS changes specifically.

> Meaning that if Windows ever were to overwrite that region for whatever reason, will trigger the crash.

We're talking about random stack memory inside of a virtual machine that likely doesn't call any external code whatsoever. There should be no real way for Microsoft to accidentally corrupt this memory.

> As Windows matures, behaviour can change, breaking certain stuff.

How do you expect the aforementioned tech to break the games it's on? If anything it "breaking" will just make the anti-tamper feature ineffective.

> If people have enabled that setting, or left that default on, then that's their problem; it's not Windows Defender's fault.

There is no such setting for Defender. The file scanning is either on or defender is completely off. To even access some of the better stuff like ASR rules (that are disabled by default) you need third-party software or pay for their enterprise offering.

Consumer Defender literally has like 4 toggles in total. It's a dumbed down and extremely permissive AV because it runs on every Windows machine.

> Let’s cut the bullshit, Defender is basically unchanged as a concept since Windows Vista or maybe even Windows XP. It runs completely fine on 15 year old hardware.

Exactly. It's the same legacy scan every fucking thing you open AV architecture.

Back in the day of spinning disks it probably wouldn't have been too noticeable for the AV to marshal scanning to its usermode service and the filesystem to pull the data from cache for the original request afterwards. However now that we have 10GB/s+ capable SSDs the factor of slowdown is exponentially larger.

I can run ripgrep on a massive directory, make myself a cup of tea and return to it still searching for matches versus being done in < 10 seconds with defender disabled.

By "actual code" I meant the assembly that the application logic compiles down to, not the entire executable. But as far as the entire package goes, compiling it using clang with some flags I can get down to 19.5k without any effort. If I wanted to waste time on this, ripping out the CRT entirely and getting it to 16k would probably take less than an hour.

> those global variables...

What about them? In a 500 loc app there is no practical difference and there's only ~20 of them with clear purpose.

> Use std::string <...> or std::list <...> remove all the malloc, etc

> still compile to the same assembly language without the bugs.

I see you have no clue what those things actually compile down to.

The actual code in the repo definitely compiles to less than 10k. The rest is bloat from linking CRT statically.

> Are they able to load a .so/dylib file during runtime and just call a method on it as long as they know the name of the method?

Yes, usually that's the entire point of an .so/.dylib/.dll - to load it and call it's functions by name?

> How does iOS even allow that? How does an iOS even get to load those files? Seems like that would be locked down.

Because it's something that higher level apple interfaces might rely on. It's not a security issue in the first place - if you submit an app obviously using them the message you get is:

> The use of non-public APIs is not permitted on the App Store because it can lead to a poor user experience should these APIs change.

Showing a 5000$ bounty example of "enumerating all apps" sounds a bit disingenuous when this is more of a "check if this exact app by bundle name was installed not through store.

I also don't think that this deserves to be called anything as scary as an "zero day exploit", "sandbox escape".

> Also, it would be silly to bottleneck your protocol implementation benchmark on encryption that would be shared amongst implementations because that does not highlight your overhead advantages

It would be great if benchmarks with no encryption were a thing.

There's massive overheads, and I explicitly avoided saying whether it's "fast" or not because to a lot of people serving 1000req/s seems "fast" and TLS is basically the main algorithmic complexity you'd expect from a data transfer protocol.

> what is presumably a single core

I would guess that it's not a single core benchmark and that's the speed of the overall multi-threaded system.

> Is that considered fast?

You can squeeze out around 5GB/s/core with current fastest standard tls1.3 algorithm (AES128GCM). 10+GB/s is possible with aegis variants that are somewhat popular as an extension to TLS libs.

You're missing the fact that there is basically no bug here.

All this does is:

* Store data in a database.

* Kill AV software provided you have admin privileges.

The latter might be remediated by MS down the line, but they don't generally give bounties.

Because this has no actual value for anyone and MS would (did?) ignore him.

There is nothing inherently wrong with throwing an exception from an APC. Windows supports it and will unwind the stack correctly. If you wrote all the code absolutely nothing will go wrong.

The issue is more about the actual code that calls alertable waits not expecting exceptions that will unwind which will most likely be all of winapi code because in it exception == crash.

> WDYM? The root cause is "you passed ownership to stack-based memory to the kernel and didn't ensure it's valid when it called you back", why would "consent of lower frames" matter here?

There is no "called back" in this case. The APC was executed by the sleep and corrupted the stack by unwinding across the C winsock code without any cleanup. It never returned.

The user-mode enters an "alertable" wait which allows an asynchronous procedure (APC) to interrupt it and execute code. Instead of returning the APC causes an exception, unwinds the stack across the APC delivery and ends up executing some random code instead of returning to the winapi code that called wait(alertable: true) in a loop. So the code that was supposed to be synchronous because of while(!completed) wait(); suddenly is broken out of the loop without actually being completed.

> Exceptions (where lower frames matter) hid the control flow here, but that's one way to reach this situation (early return is another way, as shown by Raymond Chen's post).

This isn't just hiding the control flow here. It's control flow that shouldn't have existed in the first place. It walks across the boundary of the windows APC dispatcher. Unity folks needed to go out of their way to make this "work" in the first place because using c++ exceptions and standard library threads this wouldn't work.

> The problem boils down to usage of stack memory after the memory is given to somebody else.

While this isn't incorrect in this case the problem seems to be caused by stack unwinding without the consent of lower frames rather than a willful bug where the callee forgets about the ownership.

> You can do DMA cheating if that’s a non-negotiable for you but it is far more expensive.

Cheap DMA cards go for couple hundred dollars which isn't all that much. Although unlike what most people tend to believe, the DMA cards do end up getting detected quite often.

> Pretty sure there’s hardware to blend both monitor outputs, though most people do two monitors I believe.

It's called a "fuser".

> That seems like something that would be solvable with location-style differential privacy. Report a number of plausible locations to the client small enough that it can efficiently anticipate them all, but large enough to prevent being able to auto-aim or wall hack. Run some bots or actual player movements recorded from other matches, originating from roughly the same point where you last saw the real opponent.

Has already been done in COD: Warzone. Varying levels of success, cheat developers end up heuristically eliminating fake players.

> Even small violations of continuity seem like they'd be observable server-side, no? I've not studied this, but presumably clients must be constantly phoning home with their position.

This issue usually is game/game-engine dependent and is achieved either by exploiting bugs or manipulating lag compensation. Not exactly a very common thing.

> I said it because I think other kernel level anticheat don't do it.

It is done by FACEIT and ESEA.

> If I remember correctly I can just enable/disable the easy anticheat service, sane with the EA thing, I don't need to reboot the machine like with Vanguard.

You can disable Vanguard as well, you'll only need to re-enable it and restart if you want to play the games.

> With the way that computer vision and AI continue to improve, I imagine that we will soon have completely external and undetectable cheating peripherals, simply capture the screen direct from the display output, and pass inputs via mimicking a usb human input device.

This already exists. You can stream your screen to another machine running image recognition and pass your mouse input through a controller that injects auxiliary input (there are off-the-shelf products like kmbox, you can make your own as well).

However, it is very important to understand that only a tiny percentage of cheaters in games end up being determined enough to go through hoops to purchase hardware for it (it's much more expensive and not as simple as getting instant gratification by double clicking on an executable). It's basically considered a win to push people into needing go to such lengths to cheat without getting banned.

If you dig a little more about what this is talking about, Microsoft did not actually make any kernel related changes.

This was just Symantec and McAffee ranting about PatchGuard and MS did not remove it.

> Maybe because everyone else in "security" and DRM does it, so they figured this is how it's done and they should do it too?

What DRM uses kernel drivers? And how do you plan to prevent malware from usermode?

it was the game itself that got exploited, not the anti-cheat that is a "rootkit".

> In x64 compilers

The default is omission. If you have a Windows machine, in all likelihood almost no 64 bit code running on it has frame pointers.

> OR is there some magic in the pdata section that makes it work even if you omit the frame-pointer

You haven't ever needed frame pointers to unwind using ... unwind information. The same thing exists for linux as `.eh_frame` section.

If you're talking about the blog, it's an open source Zola theme https://github.com/not-matthias/apollo (the original site https://secret.club which it's based on/inspired by is closed source though)