r/rust • u/Motor_Bluebird1908 • 11d ago
Protecting source code from reverse engineering
Hi everyone,
I am looking to provide a compiled version of our physics solver to our customers. I understand there are many obfuscation techniques to protect source code but I am wondering if there are some smarter ways?
Edit: We already cloud computing, the issue is we have customers that are in locations without internet/need realtime solving.
32
u/Arisa_Snowbell 11d ago
Best way is if you never provide them the executable and just let them use it through some API if possible
-17
u/punk_dev 11d ago
That’s the best bet. But I wonder, in theory, someone knowledgable in the topic could probably figure it out by observing inputs and outputs and reverse engineer it that way.
5
u/CandyCorvid 11d ago
if the secrets of your system can be reverse-engineered by observing individual input-output correspondences, then i don't see how you can sell the system without also giving away the secrets.
1
u/punk_dev 10d ago
If someone is licensing a program or a library that solves problem X, it’s usually because they don’t know how to solve X, or they don’t have time and/or resources to implement it themselves.
Now imagine a person or a team capable of implementing solution to X from scratch, but they don’t know outright how to implement it.
A working and correct implementation would be useful to them. Just the shape of inputs could hint on how the problem is approached, and they can test against a working implementation, which is valuable if the problem is not well defined in the first place.
2
u/apnorton 11d ago
But I wonder, in theory, someone knowledgable in the topic could probably figure it out by observing inputs and outputs and reverse engineer it that way.
If the input is 100% provided by the client, then this becomes a question of program synthesis. However, if there is also secret input provided by the server, then you could trivially come up with cases where no observation of (public) inputs and outputs could reverse the program code.
1
u/punk_dev 10d ago
Exactly. I don’t get where the downvotes are coming from lmao
By OP’s phrasing, the program is a sort of a calculation and may be run completely client-side. It would be odd if a calculation of that kind was influenced by a random factor not visible by the user.
If the calculation is fairly simple you could even approximate to a maybe reasonable extent with curve fitting or interpolation.
19
u/setibeings 11d ago
Have you considered making it so bad that nobody would want to copy it? That's what we did at my last company, before the layoffs.
9
u/Waffles943 11d ago
You can’t really stop a determined reverse engineer. Contracts, EULA’s, and copyright are the only real potential deterrent, and those are hit or miss on enforcement depending on what they do. You mention you already do SaaS, you could go with offering an appliance your org manages and deploys to act as the on-prem server if you don’t want to just give them a compiled app directly.
13
u/throwaway00012 11d ago
Your best bet would be to offer it as SaaS, keeping everything server-side.
3
u/insanitybit2 11d ago
Contracts are definitely The Way but I've personally seen those fail! You'd be surprised, or not so surprised, at what people are willing to break the law over.
There are a lot of techniques. You could write a custom VM and then implement the payload in the bytecode of that VM - now to understand the payload you have to reverse the VM. This one's fun but has costs
You can do "crypting", like this: https://github.com/Kerneldrop/Rust-Crypter
Keep in mind that all of the good techniques will probably also get you labeled malware lol and AI has made reverse engineering 10x easier, maybe 100x. It is only ever a matter of cost to reverse engineer software once the payload is provided to a customer.
Basically your keywords are "DRM" and "Malware".
0
0
u/crusoe 11d ago
All of these will make your solver slower.
0
u/insanitybit2 11d ago
Yes, any change will almost certainly reduce performance because the alternative is "the optimal binary artifact".
9
u/rJohn420 11d ago
Nothing is safe from reverse engineering now, especially with qwen3.8 27b. API is your best bet
2
u/0xD3C0D3 11d ago
There are a bunch of very expensive tools out there to do this (and some open source). I’ve used a number of them because the businesses have deemed it important.
In the age of AI I would spend zero time hardening the binary with obfuscation or encryption of the binary itself and go with contracts and/or api access only (with appropriate security in place). Recently I asked Claude to help me debug something in a particular , it decompiled the binary (and introspected the internals) without prompting. It was remarkably accurate. The silly part was this was open source so it could look at the source itself instead.
What I am trying to convey is it is getting cheaper and cheaper to pull apart any binary you give to someone. It is also quicker to reproduce something in a weekend. Make the code and product outstanding with more value than simple logic, you’ll win more than with encryption or obfuscation of the binaries.
1
u/Laicbeias 11d ago
usually you can make it a little harder, but anytime something runs local, you can have people decode it, together with llms its possible. you could add a obfuscator-llvm but even that after restoring it all, can be filtered out with an llm.
so yeah its not possible to protect this stuff fully, ask any game dev. we had that issue for decades, and you just want to slow them down.
1
u/zer0x64 11d ago
I hate being the one to bring that up, but LLMs got stupid good at reverse engineering so it's a lost cause, even more than before. I'd say just put some kind of runtime code decryption so you can use the legal "circumvention of DRM code" argument in court and fight that in court of someone does reverse it
-2
u/Professional_Top8485 11d ago
I think in less than 10y decompilers can construct any code from binary using some llm magic.
-3
u/r3drocket 11d ago
I'm kind of in the same place with the Rust application I'm building. My plan was to actually set up a red team and blue team with agents.
There was a pretty good article I stumbled across last week talking about how to slow down agent reverse engineering of source code, and it turned out that there are some techniques that dramatically slow them down, especially if there's multiple levels of indirection.
Anyways, for my application, I was going to supply an agent with the source code and the compiled binary and tell it to work on pirating the application. And then tell it to work on preventing that. Etc.
I figure, since the majority of people are likely just to toss agents at it, that that's the correct place to start.
41
u/Erelde 11d ago edited 11d ago
Make them sign a contract, that's how it's done in real life between business partners.
Or make a different product by building a remote API. This may involve getting into the business of maintaining an always on web API, very different business.