Quote:
|
It should prevent of decoding our code by disassemblers.
|
Commercial software people are always good for a laugh.
Note that everything below assumes you're not using a TCM system. But if you knew that you wouldn't be asking here for advice on obfuscating code.
Once your code is 'compiled' it is just translated into another language. Hopefully it will be translated into something that is easier for the computer to use. To anyone that can program in your target format, will consider the shipped software to be in source code format. If I can read and program in x86 assembler, Microsoft has shipped me the source code to Windows everyday since 1990. It may not look like source to you, but the decompiler and the assembler programmer don't care.
I have worked on many projects that used obfuscated code. The best you can get away with (and not significantly impact your sales and potential market) is stripping out meaningful names. However, to the non-English speaker, functionCall338() is no more meaningful than setApplicationTitle() so this technique is rather silly from the realist's point of view. In the end, the strings utility will defeat you. The tools from smart assembly are cute, but free tools exist to re-patch those function calls into something less ugly. The computer doesn't care that you used non-printing characters for function names nor will the disassembler.
Now, if you are trying to hide your algorithms, you can use an interpreter. One of the 'encrypted shell' tools used to ship games on Linux is a good example. But to 'protect' your intellectual property (oxymoron not withstanding) it will have to completely wrap your code. Even your most efficient work will become much slower when the shell has to dynamically re-translate your software. This is not something you do for performance demanding or interactive applications. Ever complain about the speed of Java? Well Java VMs have received far more attention than any encrypted shell.
Either way, you will lose support for most debugging tools. With the encryption tool between you and your program, developers can no longer trust that problems with your code is not the fault of the protection tool. After all, if you don't take all the possible protective measures available it will be trivial to strip your unencrypted and compiled code from the shell program, then decompile it. With the obsfucator you may have to pay the original company a lot of money for a simple tool to remap obsfucated functions to their original form. Also, any error reporting risks being mightly corrupted if it tried to print out the function name or object ID that failed. Some GUI's (Windows) don't like non-printable characters and have had bugs that crashed the OS trying to use them.
Remember that all it takes is one disgruntled employee to leak the original source code.
And yes, non-technical management never has a clue about this. People have been mystified by the 'magic computing box' since the first PhD proposed one.
Linear Mode
