Well, technically both WaitOnAddress and SRWLOCK use the same "wait/wake by thread ID" primitive. WaitOnAddress uses a hash table to store the thread ID to wake for an address, whereas SRWLOCK can just store that in the SRWLOCK itself (well, in an object on the waiter's stack, pointed to by the SRWLOCK).
The anti-tamper codes, if any tampering is detected will crash on undefined/unallocated regions. Meaning that if Windows ever were to overwrite that region for whatever reason, will trigger the crash.
Such was the case for SecuROM in early days. It featured the CRC checks mentioned, if any single byte was changed, including an INT (breakpoint) instruction, it would crash. Here it's unlikely that it wont crash. Rendering the game inoperable.
> 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.
In that case the "unused" stack was overwritten by a function called on that thread. But I'd assume that Denuvo is careful to not call any third party code while it expects the "unused" stack data to remain unmodified, so this shouldn't happen here.
So this code can only break if the data is overwritten from code outside the control of that thread. On Unix, certain signals could cause that. Or the OS could decide to zero out the unused thread while the thread isn't running. Zeroing the thread could the helpful to wipe secrets spilled there (forward secrecy related), or if whole pages can be zeroed (via something like MADV_ZERO), it could reduce the memory consumption by allowing threads to shrink.
While I would like that thread zeroing feature, I think it's unlikely that MS will implement something like it. So the code should be unlikely to break in practice.
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.
IIRC Denuvo costs a fortune to keep in a game, since it’s a subscription model. Once sales sufficiently taper off there’s not much sense in paying for it anymore.
Some games have had it for an extremely long time. and some publishers never remove it (Eg. Sega). In some cases I guess they got a lifetime deal with an older version of Denuvo, but other cases are sus. I wonder is it for money laundering purposes.
> 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.
Yeah so like, every time I ran AV software it was quite obvious where the paranoia settings were, and how to tone down the aggressive "scan everything everywhere every time" settings.
For 98% of systems, there is probably no reason to scan every file on opening it. If people have enabled that setting, or left that default on, then that's their problem; it's not Windows Defender's fault.
My current AV dashboards are screaming at me that I'm only 35% protected. That's because I've exercised a lot of prudence in enabling paranoid settings, based on my rather limited and simplistic threat modeling. Installing AV software comes with the understanding that it can steal resources, but they nearly always have plenty of settings that can be disabled and win back your system responsiveness.
I am beginning to believe that commenters giving bingo-card winnings are not the brightest bulbs in the Windows MCSE pool, honestly. I can relate: Linux and Unix admin in general is far more intuitive and comfortable for me, so I have generally stayed on that side of things, but knowing how to properly set up Windows is an indispensable life skill for anyone.
> 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.
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.
> 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.
Man, this is gonna reveal some ignorance. But here goes. Please correct me where I'm wrong
.so/.dylib/.dll's typically get linked at load time, right? Like we aren't all manually loading dylibs in our source code. I guess I'm surprised on a platform as locked down as ios that they even allow you to link anything at run time.
chatgpt gives me this snippet but I have no way of knowing if this is roughly how it would look.
Class SBApplication = objc_getClass("SBApplication");
SEL launchSel = sel_registerName("launch");
id app = [SBApplication getAppWithBundleID:@"com.example.app"];
You can put in an autoload section and the runtime linker will load it for you, but you absolutely can load a DLL and its symbol names at runtime. Usually this is done for boring reasons like compatibility with multiple versions of an external library.
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".
There seems to be some weird beef in the background here with the TrollStore developers and Verichains, but Verichains come out looking much better here by naming the exploit what it actually is rather than misleading puffery around “sandbox escape 0days!!!111”
I think app enumeration info leaks generically might be eligible for that bounty, though, so mentioning it doesn’t seem too wild.
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.
5 GB/s per core would still be 40 Gbps per core, so only ~15% of their time would be spent in encryption. They spend 5x longer doing the non-encryption stuff.
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. In addition, the benchmarking RFC explicitly allows for the null encryption case in benchmarking for exactly that reason.
> 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.
Yeah, the AV thing was what gave me pause. The only thing I miss about Windows is ESET's Nod32. Best AV I've ever used. I know they have a Mac version now but I don't see the point in getting it.
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.
