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.