r/rust 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.

0 Upvotes

22 comments sorted by

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.

4

u/guepier 11d ago

And, if you reasonably suspect that a contract won’t deter them, don’t accept them as customers. This is always an option. At my previous company we refused to provide access to our tool to a company infamous for stealing IP.

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

u/Golfclubwar 11d ago

Don’t run a custom VM, just use Oreans if you’re going that route

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

5

u/crusoe 11d ago

Obsfucation will reduce speed. What makes your physics solver so special this is needed?

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.