Obfuscation in Elixir/Erlang

Yeah, but encrypting my local drive does not help here

And to be honest, we sell our software accompanied by long term maintanance contracts, so we do get our money, independently of anything the client does

I was assuming you wouldn’t want to provide access to your files

However if you wanted to protect your code in that case, such as for instance if you were selling a license to use your software but not the software itself, then what about encoding?

In PHP you can use IonCube or Zend Guard to encode parts of your application. Is there anything like that for Erlang/Elixir?

Nope, I might hand out a release tarball to the client who paid me to create a certain piece of software, but in the same moment I hand it over I want to save my job by making it as hard as possible for the client to continue to develop that software (or take some extra charge and hand source over as well).

You said the BEAM file was reverse engineerable, and I would guess the only way to get access to those files would be with direct access to your hardware? (Unless using Nerves of course )

Re debug levels - don’t these automacitlly change in environment? So info only in production and debug in development? (I believe Rails does that.)

How does that help protect running software on someone ‘elses’ machine?

I’m not sure why you’d even want to obfuscate on your own hardware, that would just make manual debugging an utter pain… o.O

I’m no criminal enterprise… >.>
I’ve just, made a lot of, hmmm how to word this, cracks back in the day… >.>
/me really really hates bad programming, whether closed or not, and quite often will fix it in one way or another

Really though, it is not all that hard, just a lot of knowledge in a lot of areas working together, and the overall process is often time consuming, but it is not really hard by any stretch.

What about encrypting the entire hard drive on the OS level?

An encrypted filesystem will protect against bare-metal attacks against a hard drive. Anyone getting their hands on the drive would have to use brute force to guess the encryption key, a substantial hindrance to getting at your data.

You can also encrypt the debug information. This means that if you have the key you can still have access to ilve debugging which is useful.

I agree but there are degrees in hell While obfuscation is not security and can never be made secure it can raise the level of skill required to access it. For example you might block out script kiddies but fail at criminal enterprise. Obfuscation is the only thing you can use if you run on an open platform.

Removing debug info is the way to do that, however the BEAM file is reverse engineerable, if you want something obfuscated then I’d say first of all you are using the entirely WRONG kind of ‘security’ (Security through obfuscation is not security), second that you are using the wrong language, and third, if you really need to, move the parts you need to protect to a native language over a port or something, but know that even machine code is pretty decompileable nowadays (I know very well, I used to do it a lot).

Obfuscation is NOT security and should NEVER be used for anything related to security. At best it might be a consequence of minimization in languages where that matters, but again Elixir is not one of those either.

Again, do NOT use obfuscation as protection, it is one of the stupidest things to do in any language (again, I have a LOT of personal experience in breaking those in native machine code, Java, even machine code secure VM’s that are common in, say, modern game copy protection are breakable and those are the top tier in that research right now).

In essence, if code needs to run, there is no amount of protection you can apply to it other that hardwiring it in a read-only chip that breaks apart if attempted to be taken apart while being scanner resistant. Running it on an operating system like Windows or Linux or Mac will NEVER EVER EVER be secure. All it takes is one person to decompile it and release the secrets.

However yes, removing debug info makes it change from ‘trivially decompileable’ to ‘it takes a lot more work’, but you also lose a whole host of functionality as well (mostly related to tracing/debugging/etc…/etc… of which different parts become more difficult and others become impossible) and you need to be fully aware what you are doing before you change those defaults.

The better questions are “Why?” “What are you actually trying to accomplish overall?”