Binary obfuscation that doesn't kill LTO
blog.farzon.orghttps://farzon.org/files/presentations/Thotcon_talk_may_2025... This is decidedly not what I’d expect to be discussed at Thotcon. That said, super interesting! As an avid pirate, I’ll say these days even the Denuvo game which were going years without cracks now have “cracks”, although they rely on hypervisor fixes and disabling secure boot and giving the hypervisor cracks unfettered access to your system to intercept the Denuvo checks. [0] It’s a dangerous game we’re playing to keep these AAA games bottom lines fat. [0] https://www.thefpsreview.com/2026/04/03/denuvo-has-been-brok... The main site to get these hypervisor cracks thoroughly vets them, requiring the devs to publish the source code to it all. disabling secure boot ...making it even more clear what "secure" boot actually secures: the control others have over your own computer. It has their uses. If, for example, a company wants to issue fleet computers to workers or school to students, you want to have secure boot on those devices to prevent tampering. Secure boot makes it so that physical access is not the end all of security. If you own the computer yourself, you "ought" to be able to turn off these measures in a way that is undetectable. Being unable to do so would be the red line imho - and looking at those hypervisor cracks available, it's not quite being crossed. The pessimistic, but realistic future prediction is that various media companies would want and lobby for machines to have unbreakable enclaves for which they can "trust" to DRM your machine, and it's just boiling the frog right now. Windows 11's new TPM requirement is testament to that. Switch to linux asap - that's about the only thing a consumer is capable of doing. This is coming. In particular, without a Secure-Boot-enforced allowlist of operating systems, it will be near impossible to verify that an OS connecting to the internet complies with your locality's age verification laws, so it will soon be illegal to run a computer that does not make Secure Boot mandatory and connect it to the network. If you're starting to think "huh, maybe that's why these age verification laws suddenly became all the rage", you're onto something. Whatever the case, "general purpose computing" is definitely cooked. The laws in my locality place requirements on the service provider (e.g. the adult website operator), not on random computer owners or manufacturers or software vendors. Newsom signed a law that places those requirements on every operating system in California, and in practice, organizations tend to comply with California's terrible laws no matter where you are, rather than stopping doing business there or making two variants of their products. With software it's trivial to have a switch for "California compliant" mode, but in any case, that makes it clear that such criticisms should be directed at California. Other (generally "red") states already had a more reasonable solution: make the sites offering the restricted service liable for their actions just like other businesses. The problem is that you could face liability if you do business in the United States and permit a minor in California to use an OS in non-California-compliant mode. If you're an "OS provider" in Wichita, KS, California will find that its jurisdiction still applies because the minor was in California and sue you in its courts. If you fail to turn up that's a judgement for the state by default. (And if you do turn up, it's a judgement for the state as soon as they prove a kid ran your non-age-checking OS.) And, thanks to the "full faith and credit" clause of the Constitution, California will be able to collect on its judgement against you in Wichita. Hardware vendors are not going to want that kind of liability, in California, Colorado, New York, or anywhere else. So they will switch to selling hardware with locked bootloaders and only allowing approved operating systems within that locality (which for end-user PCs will mean pretty much just Windows). There is still foreign hardware, but those chinesium PCs are going to be confiscated by ICE unless the Chinese manufacturers also play ball. Besides all this... federal legislation is coming. If you'd humor me, or just read the last paragraph for a tldr... So let's say a PC builder(an individual; not a company) were to donate a PC to charity. Let's say it's built with a fairly recent MSI motherboard(https://www.amazon.com/dp/B0BRQSWSFQ/) 'MSI PRO B760-P' if you'd prefer to avoid amazon. I remove all my internal SSDs and NVME drives but buy a new 1tb SSD for whoever receives the PC. I also install a Linux OS, as well as sign the secure boot keys via sbctl myself, setup ukify, efibootmgr, etc. Everything the recipient would need to switch over to another OS if they so choose. But oh no, the donated PC landed in the hands of Johnny, a 17-year old in California. So who's at fault here, MSI for creating a BIOS that allows for non-windows EFI images to be installed? The PC Builder(donator) for knowingly installing Linux(though not knowing where it would end up)? This is kind of what confuses me and I'm curious what this means for future hardware sold in the US and those who build PCs for their own use or others. Most modern motherboards are "locked down" by default, but can easily be unlocked by the end-user, it may take a few extra steps or be a bit harder to find but still pretty simple for someone moderately tech-savvy. The full faith and credit clause does not apply if the court lacks jurisdiction, which California clearly would. There's a reason "California compliant" already exists as a phrase; you can buy and sell things that break California law outside of California. If you bring it in that's on you. General purpose computing as it was done in the 1900s is cooked for the average user because there is no market incentive for it to exist. The actual market incentive revolves around apps as they provide user value along with the ability to deploy custom apps. > If, for example, a company wants to issue fleet computers to workers or school to students, you want to have secure boot on those devices to prevent tampering. Secure boot makes it so that physical access is not the end all of security. Measured boot is actually better for that: You can still boot whatever you want however you want, but hashes are different which can be used for e.g. remote attestation. Secure boot has to prevent that "unauthorized" code (whatever that means for each setup) can ever run. If it does, game over. That means less freedom and flexibility. Measured boot isn't any better. Look at Android phones, where it's technically possible to unlock your bootloader, but a ton of apps (e.g., McDonald's and most banking apps) use remote attestation to see whether you did so and will refuse to work if you did. Yep. Exactly why i said > turn off these measures in a way that is undetectable. If you own the device, you ought to have the means to make such configuration/changes in undetectable ways. Otherwise, you don't truly own the device. Some apps want to run on devices that you don't "own", because they are doing something the owner would not want done (in secret or what not). it is stupid to turn it off. It is incredibly easy to infect your system components without your knowning. that being said, it does assume a certain trust in firmware vendors / oems. If you dont trust those, then dont buy from them. i think for most ppl trusting OEM or trusting rando from interwebz with a custom hypervisor and requirement to cripple my system security are totally different things .. u know they could actually make theyr HV support secure boot etc. to do it properly and have ur system run the cracks but not have gaping holes left by them -_-. lazy. If you’re downloading torrents and running code with elevated privileges that infects your PC, 99% of people are absolutely hosed at that point anyway. I don’t see th real distinction between being owned at an elevated system level and owned by disabling system secure boot for a home user pwned at the bios level means the pwnage can survive a complete OS reinstall Secure boot is an attempt to make covert persistence of an infection harder, that's all. It doesn't make it more or less likely for you to be compromised in the first place (and in general compromise of your user account is enough to be a big problem: most malware doesn't even need admin access let alone the ability to modify the parts of the system protected by secure boot) As always in security, It Depends™; there are vulnerabilities that only impact systems with secure boot (and result in a situation worse than not having secure boot to begin with). > there are vulnerabilities that only impact systems with secure boot Boring claim, obviously true. > and result in a situation worse than not having secure boot to begin with A very big claim that requires evidence. If your system gets locked (I.e. ransomware) and you have secure boot active, then you are out of luck. See Apple M chips which if they get locked you will never unlock them again. It would work just as well if the instructions instead told you to enrol your own key and sign the cracks. Those instructions just aren't as popular. Having an operating system purposefully allow support to installing rootkits should clearly be a bad idea. It shouldn't be surprising you have to turn off security features to install a rootkit. Anti-cheat drivers are just as much of rootkits, and in practice, they have vulnerabilities that get a lot more hosts pwned than cheats do. Let's get Microsoft to stop loading their drivers. I agree. Microsoft should provide proper integrity APIs to apps so they don't need such drivers. The fact that the PC ecosystem is so far behind XBox's for platform integrity is a big failure on Microsoft's part towards the PC gaming market. The "integrity" you speak of is a bad thing. Microsoft should be making that harder to obtain, not easier. Integrity is needed for a fair playing field. Their is consumer demand for such a fair playing field so it is a good thing for an operating system to respond to customer demand. Cheap take What I'm wondering for a while now: How do the game streaming services run the Denuvo titles? Do they get special builds? They will not run on bare metal hardware but in some kind of VM right? Wouldn't Denuvo detect that and stop working? They get their own build. E.g. * GeForce NOW SDK: https://developer.geforcenow.com/learn/guides/offerings-sdk * Stadia SDK: developer.stadia.com (offline) * Xbox Cloud Gaming: https://learn.microsoft.com/en-us/gaming/gdk/docs/features/c... * ... Just like every Game Store requires its own build: Steamworks SDK, even GOG: https://docs.gog.com/sdk/ Some games allow browsing files locally for savegames, music libray, ... . Imagine if you could do that on the cloud VM. To add to this, almost every time a Denuvo game was “cracked” before the hypervisor methods it was because the dev accidentally published a demo with none of the Denuvo stuff. Happened to Lies of P a couple months after release. > * Stadia SDK: developer.stadia.com (offline) Stadia is completely shutdown and Archive.org has no captures of that subdomain so any content there is likely lost. That makes a lot of sense, thanks for clarifying! Secure boot is the first thing that gets disabled on any machine of mine. Why is this a bad thing? Essentially secure boot is supposed to validate that only properly signed drivers are loaded on system startup. That allows you to block malicious/cheat drivers from being loaded because a signed AV/anticheat driver was loaded before and now it can properly control drivers that are being loaded after it. Without it you are risking that the malicious driver will be loaded first and then make itself invisible to the later drivers. Of course there are ways to bypass this too, but it adds a whole other layer of complexity. Tldr Secure boot is there so drivers loaded at boot time can trust that nothing was tampered with before they were loaded. > While security researchers love the entropy of randomized function layouts I don't think any competent security researcher has anything positive to say about "security through obscurity" at best this is lawyer position I disagree, obscurity wastes attacker resources and easily fools a lot of simple vulnerability scanners. Obscurity is totally underrated. Attacker resources are limited. It’s kind of having a line of cardboard tanks. Can be helpful in some circumstances, but it can’t always replace actual tanks Actually decoys are very useful in Ukraine Russian war. It is usually decoys of air defense or long range precision fires like Himars and target is to waste resources of opponents long range fires which are limited and/or expensive. Further more you can also reveal position of the attacker and counterfire. If you have 500 tanks and 500 cardboard tanks, someone with only as many real tanks as you have may not bother attacking. Thus, having the cardboard tanks saved you a battle. If someone with 1000 tanks attacks, it's a battle you would not have won anyway. And yet, cardboard tanks have been useful only a handful of times during wartime. Tanks on the other hand have proven their usefulness many times. thank you, I had this debate at work so many times. Sure it's not a security measure as such, but it's still a worthwile component to the overall defense system. The problem with this is, you spend a lot of effort for low benefit. You should spend it on actual security instead. Changing a port and enabling aslr are not "a lot of effort". Changing the port is not the kind of security measure that will consume a lot of the attacker resources Sure, it'll do nothing to stop a determined attacker, but it does wonders to stop the noise from passive scanners. Are you familiar with the Swiss cheese model of risk management[0]? Obscurity is just another slice of Swiss cheese. It's not your only security measure. You still use all the other measures. It will conserve a lot of defender resources, it will completely bypass all mass scans, and it will make "determined attackers" much more visible as they will have to find the port first which will show up in logs and potentially land them in a tarpit. What would be "actual security" in this context? This isn't about security of the same kind as authentication/encryption etc where security by obscurity is a bad idea. This is an effort where obscurity is almost the only idea there is, and where even a marginal increase in difficulty for tampering/inspecting/exploiting is well worth it. The one not described as "security through obscurity". My point is: the "security through obscurity is bad" and "security through obscurity isn't real security" are both incorrect. They apply to different threats and different contexts. When you have code running in the attackers' system, in normal privilege so they can pick it apart, then obscurity is basically all you have. So the only question to answer is: do you want a quick form of security through obscurity, or do you not? If it delivers tangible benefits that outweigh the costs, then why would you not? What one is aiming for here is just slowing an annoying down an attacker. Because it's the best you can do. Somehow your approach was not chosen by Intel ME or AMD PSP, and they remain unbreakable. That's orthogonal to this. That requires special hardware and using those doesn't really rule this out as an additional measure. I'm going to assume whatever efficacy obscurity brings will take increasing hits as AI tooling becomes more commonplace. Security through obscurity is bad only if the obscurity is the only measure You would think but in my experience, if you ask to just open something up they'll start talking about "defense in depth" and it suddenly matters a lot. It's not something to over-index on, but it's not a strong protection measure. It simply raises the overall cost to attack and analyze a system. Take the PS5 for example. It has execute-only memory. Even if you find a bug, how do you exploit it if you can't read the executable text of your ROP/JOP target? Security through obscurity is an excellent first-line defense, as long as you have other real defenses at the next layer. You can consider obscurity as concealment. You can't be attacked if you are not seen. And to be seen attacker needs much more resources to see you. Security through obscurity is like a bike lock. It can be cracked with the right tools and effort, but massively improves security compared to leaving it out unlocked. It’s not about security, it’s about wasting a crackers time. Some people find cracking them interesting and fun. Agreed. I’ve done trivial obfuscation for games. In my observation, if you make it trivial to hack your game, huge numbers will trivially hack it. If you make it even slightly non-trivial, the numbers decrease exponentially. The more you waste their time, put up hurdles, the lower the number of successful hackers goes. The goal is not perfect security in all situations for all products. The goal is to make the effort required for your particular product excessive compared to the payoff. ASLR (for example) is a pretty standard technique, I thought all commercial OSes enabled this generally. What's the purpose of picking at this portion? Between this and rootkits masquerading as anticheat, video games are starting to look indistinguishable from malware When hacks exist that use FPGA's to MITM PCI-e level data, I'm not sure what else you can do. The problem contradicts itself: You want a secure, unhackable game, but without essentially root/kernel access? Heuristic-based anticheat seems to have fallen out of favor. I honestly believe we should return to dedicated servers + admins. This hacker/anti-cheat arms race is never going to end. there is an immense difference between obfuscating the binary you ship for your game and requiring rootkit-level anti-cheat systems to play your game. it is wild to imply they are remotely the same in their effect on the user. one is literal malware, and the other shares 0 of the capabilities or effects of malware. They do employ former malware writers to work on some of this stuff from what i hear. Link to the slides (almost missed it when i was reading): https://farzon.org/files/presentations/Thotcon_talk_may_2025... Which provides way more information than the article Belatedly added to toptext above. Thanks! I’ve noticed that LLMs can effortlessly read minified JS. How does it do with obfuscated binary code? I wonder if the days of obfuscation are numbered when the tedious job of de-obfuscation can be automated. I'm a bit perplexed by the choice of Nintendo Switch as the example hardware. I was under the impression that the switch was locked down and you can't run offset based cheat software like cheatengine on it. The early Switches had an exploit in the Nvidia graphics processor that was so low level that the operating system can't be patched to get rid of it, so there are a lot of hackable Switches around. Echoing the other comments here - why? What is the threat model here and how does this protect you from it? the threat is people who cheat in games. obfuscation slows them down, but incurs a performance cost. this work is focused on reducing the performance cost. - from the slides Exactly. That and in game currencies. You like competing in games, or for game-bucks? Well you need some level of obfuscation and hardening to make that viable. From my understanding the goal is to prevent pirates and hackers from modifying the game's binary. I have no idea why would anyone want to do that on Nintendo Switch though, Switch 1 doesn't have any headroom and Switch 2 OS security hasn't been defeated yet. It also frustrates datamining of secret client-side game mechanics, story spoilers, and unreleased content (good branch management is not priority for some devs). Yeah this wouldn't stand up to the best of the best, but not all game communities have a George Hotz, so this suffices for most cases. oh fascinating. i just finished reverse engineering Aegis and now working on their newest Eidolon. pretty cool technology. why bother? I guess it’s mainly to sell the technology and the illusion that comes with that. So, money, for supposed control. Which is not true of course and this is insight from "other" side :)
https://www.unknowncheats.me/forum/overwatch/639855-overwatc... What is the fps hit? The reduction of Frames Per Second. Yes, I think they're asking how big it is Oh, of course… thanks for clarifying. The amount of work that goes into moats, for stuff that nobody will care about in 6 months, is kind of insane. I understand it for security reasons, but in video games? Just more bloat for nothing >Just more bloat for nothing playing an online game, especially if it is competitive, alongside a bunch of cheaters is not fun. reducing the number of cheaters is not "nothing" Security through obscurity is not a good strategy people love repeating this little line without a single thought of their own. security through obscurity is an effective defensive layer with a relatively low implementation effort. it raises the minimum effort required for bypass. the quote you have parroted is only applicable when obscurity is the only defense layer. when obscurity is used in addition to other defensive layers, it is a great first line of defense. Ah yes closed source software has such a great track record compared to open source security… lol You are wrong, if you need to hide your code for it to be secured, then it was never secure to begin with. But it’s a great way to give a false sense of security through half baked metaphors. >Ah yes closed source software has such a great track record compared to open source security… lol what does this have to do with anything i said or the contents of article? >You are wrong, if you need to hide your code for it to be secured, then it was never secure to begin with. did you just ignore the entirety of my last comment? obscurity is a first layer, solely to raise the barrier of entry and slow the game-crackers down. it is not the entire security model. it is effective at what it is designed to do, and it is low effort to implement. >But it’s a great way to give a false sense of security through half baked metaphors. my comments dont have any metaphors. what are you talking about? i think you may be out of your depth here. your entire comment is based on the premise of obscurity being the only security. i can only say the same thing so many times, but here it is one more time: your original comment is only applicable if obscurity is the sole line of defense. it is not the sole line of defense here.