[HN Gopher] Binary obfuscation that doesn't kill LTO
___________________________________________________________________
Binary obfuscation that doesn't kill LTO
https://farzon.org/files/presentations/Thotcon_talk_may_2025...
Author : noztol
Score : 132 points
Date : 2026-04-05 20:37 UTC (3 days ago)
(HTM) web link (blog.farzon.org)
(TXT) w3m dump (blog.farzon.org)
| brcmthrowaway wrote:
| What is the fps hit?
| bartvk wrote:
| The reduction of Frames Per Second.
| saghm wrote:
| Yes, I think they're asking how big it is
| bartvk wrote:
| Oh, of course... thanks for clarifying.
| djmips wrote:
| why bother?
| LunicLynx wrote:
| 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
| NooneAtAll3 wrote:
| > 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
| hsbauauvhabzb wrote:
| It's not about security, it's about wasting a crackers time.
|
| Some people find cracking them interesting and fun.
| corysama wrote:
| 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.
| zer0zzz wrote:
| 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?
| lm411 wrote:
| I disagree, obscurity wastes attacker resources and easily
| fools a lot of simple vulnerability scanners.
|
| Obscurity is totally underrated. Attacker resources are
| limited.
| dahcryn wrote:
| 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.
| fsflover wrote:
| The problem with this is, you spend a lot of effort for low
| benefit. You should spend it on actual security instead.
| literalAardvark wrote:
| Changing a port and enabling aslr are not "a lot of
| effort".
| nithril wrote:
| Changing the port is not the kind of security measure
| that will consume a lot of the attacker resources
| literalAardvark wrote:
| 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.
| Sohcahtoa82 wrote:
| 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.
|
| [0] https://en.wikipedia.org/wiki/Swiss_cheese_model
| alkonaut wrote:
| 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.
| fsflover wrote:
| The one not described as "security through obscurity".
| alkonaut wrote:
| 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.
| fsflover wrote:
| Somehow your approach was not chosen by Intel ME or AMD
| PSP, and they remain unbreakable.
| otikik wrote:
| It's kind of having a line of cardboard tanks. Can be helpful
| in some circumstances, but it can't always replace actual
| tanks
| fluoridation wrote:
| 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.
| otikik wrote:
| 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.
| Geof25 wrote:
| 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.
| fortyseven wrote:
| I'm going to assume whatever efficacy obscurity brings will
| take increasing hits as AI tooling becomes more commonplace.
| dagmx wrote:
| Security through obscurity is bad only if the obscurity is the
| only measure
| landr0id wrote:
| 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?
| Starlevel004 wrote:
| Security through obscurity is an excellent first-line defense,
| as long as you have other real defenses at the next layer.
| m-schuetz wrote:
| 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.
| Geof25 wrote:
| 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.
| jayd16 wrote:
| 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.
| p1necone wrote:
| Echoing the other comments here - why? What is the threat model
| here and how does this protect you from it?
| john_strinlai wrote:
| 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
| zer0zzz wrote:
| 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.
| lunar_rover wrote:
| 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.
| cyberrock wrote:
| 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.
| wincy wrote:
| 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...
| userbinator wrote:
| _disabling secure boot_
|
| ...making it even more clear what "secure" boot actually
| secures: the control others have over your own computer.
| 7bit wrote:
| Cheap take
| chii wrote:
| 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.
| bitwize wrote:
| 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.
| charcircuit wrote:
| 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.
| ndriscoll wrote:
| 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.
| josephcsible wrote:
| 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.
| ndriscoll wrote:
| 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.
| bitwize wrote:
| 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.
| friedtofu wrote:
| 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.
| Vogtinator wrote:
| > 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.
| josephcsible wrote:
| 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.
| dwattttt wrote:
| 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.
| saidnooneever wrote:
| 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.
| maccard wrote:
| 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
| butlike wrote:
| pwned at the bios level means the pwnage can survive a
| complete OS reinstall
| bandrami wrote:
| As always in security, It Depends(tm); there are
| vulnerabilities that only impact systems with secure boot
| (and result in a situation worse than not having secure
| boot to begin with).
| walletdrainer wrote:
| > 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.
| Geof25 wrote:
| 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.
| charcircuit wrote:
| 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.
| josephcsible wrote:
| 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.
| charcircuit wrote:
| 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.
| josephcsible wrote:
| The "integrity" you speak of is a bad thing. Microsoft
| should be making that harder to obtain, not easier.
| charcircuit wrote:
| 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.
| tossit444 wrote:
| The main site to get these hypervisor cracks thoroughly vets
| them, requiring the devs to publish the source code to it all.
| sneusse wrote:
| 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?
| meinersbur wrote:
| 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.
| sneusse wrote:
| That makes a lot of sense, thanks for clarifying!
| wincy wrote:
| 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.
| RunningDroid wrote:
| > * 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.
| seany wrote:
| Secure boot is the first thing that gets disabled on any
| machine of mine. Why is this a bad thing?
| maxwg wrote:
| 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
| dang wrote:
| Belatedly added to toptext above. Thanks!
| mahmoudimus wrote:
| oh fascinating. i just finished reverse engineering Aegis and now
| working on their newest Eidolon. pretty cool technology.
| Fokamul wrote:
| and this is insight from "other" side :)
| https://www.unknowncheats.me/forum/overwatch/639855-overwatc...
| khalic wrote:
| 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
| john_strinlai wrote:
| > _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"
| khalic wrote:
| Security through obscurity is not a good strategy
| john_strinlai wrote:
| 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.
| khalic wrote:
| 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.
| john_strinlai wrote:
| > _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.
| Zironic wrote:
| 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.
| RobotToaster wrote:
| Between this and rootkits masquerading as anticheat, video games
| are starting to look indistinguishable from malware
| john_strinlai wrote:
| 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.
| zer0zzz wrote:
| They do employ former malware writers to work on some of this
| stuff from what i hear.
| superxpro12 wrote:
| 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.
| bgirard wrote:
| 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.
___________________________________________________________________
(page generated 2026-04-08 23:01 UTC)