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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.