Hi, I have a social media management startup formerly written in javascript which i’m currently entirely rewriting in go because i am really really tired of nodejs’s single thread nonblocking io thing (everything has to be async so instead of thinking the algorithm you should first thing how to node i hated this ).
Well , sometimes i share binaries with outsource workers for front-end or design while building i am already striping the binary using ldflags but anyway go seems pretty easy to reverse-engineer . Is there any tool that can obfuscate the source and makes symbols unreadable?(this is to send binaries to untrusted people only so i dont care about panic messages readibility or similer issues )
Is code obfuscation really worth the effort?
- Reverse-engineering takes time and resources and knowlege even without code obfuscation, so there must be a sufficient advantage from reverse-engineering your code, in order to even consider this step.
- Obfuscation only makes it more difficult to reverse-engineer the code. It does not prevent reverse-engineering. So if your binaries contain any secrets, be sure they will be discovered thorugh reverse engineering. Obfuscation leads to a false sense of security.
- There are companies that make a business model from code that is completely open source, accessible to anyone. Often enough, code is not a valuable asset by itself. Rather, it’s the ecosystem that is built around that code that provides value.
- Obfuscation absolutely cannot prevent someone from examining the behavior of your binaries and start programming the same functionality from scratch.
My $0.02: If you think your code is worth protecting, and if you cannot trust someone, don’t give them your binaries.
4 Likes
Even if you send binaries, simple reversal is surprisingly easy.
In a previous life, long ago, I used to disassemble binaries to code like
a = *hl
hl++
a == 0?
if so goto L25
else
push a # as arg 1
call L93
You can guess that a quick edit or two would give back C,and that obfuscating names of the variables and labels was pretty useless.
do you have any advise on securely distributing binaries which is actual code not a thin client for something coming from the server?
This basically explains why trying to secure a binary on the client’s end does not work.
Then finally, there is that question of code privacy. This is a lost cause. There is no transformation that will keep a determined hacker from understanding your program. This turns out to be true for all programs in all languages (…) The privacy benefit provided by obfuscation is an illusion. If you don’t want people to see your programs, unplug your server.
Change the universe of discouse (;-))
Let’s assume as an example that you have a new approximation for FFT in a measurement program. You write it in Go and another measurent/monitoring company disassembles a copy.
The programmer is going to understand what you said, but not why. They’d need to know to switch to the domain of mathematics and drag in a mathie to tell that it’s the FFT code that’s wonderous, and then reverse engineer again to get the algorithm.
If you’re just doing monitoring in the example code, and there’s no special sauce, then reverse-engineering your program isn’t going to happen. The competition is going to say “not invented here, not interesting” about anything you do. In thnis case the universe of discourse is a business one.
1 Like
What I’ve done is to put the server in the cloud and let the front-end developers access its APIs remotely.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.