It is neither possible nor necessary to take extreme measures to protect the source code. Focus your energies on what adds value to your business, instead of wasting it "treating customers like thieves and thieves like customers".
It is possible to protect the source code?
Can’t make impossible the others of doing reverse engineering in their program, at most it gives to hinder. Code obfuscators are a good option if it’s simple enough to deploy it next to your product. But this won’t stop a dedicated attacker from figuring out how their software works or, even simpler, simply copying their binary code.
It should be remembered that:
In the same way that you can overshadow your code, the attacker can overshadow it again and/or employ other techniques to make it look like the copied code is different from yours. How to prove that it is the same code after? (in the case of a lawsuit, for example)
You may need to perform diagnostic actions on your program, debug troublesome parts, etc. This becomes much more complicated if your code is overshadowed, increasing your cost of servicing customers. That is if the obfuscator himself did not introduce a bug, which would make the "unoccupied" version work, but the obfuscated version did not.
It is necessary to protect against...
Piracy?
Whoever wants to copy your system will copy it anyway regardless of "understand how it works" or not. Crack tools in general act on binary itself, so there is no interest on the part of the attackers in the sources.
Contestants?
If the hardest part of marketing a product was to build it, then maybe that measure would be justified (in the case of mobile apps, it’s not far off, but I don’t have enough experience to comment). But there’s a lot more involved: marketing, support, continually improving the product from customer feedback, etc. It’s already a pretty big job, and that without having to worry about getting sued at any time for copyright violations. A serious competitor won’t copy your code, even if you rub it in his face.
As for "figure out what your code does," I ask you, is that really relevant? Are there trade secrets in it, or technologies not yet disclosed to the general public, things that only you and your company know? If the answer is yes, then go ahead and protect. Otherwise, don’t worry too much about it, probably your competitors already know everything they need to know about your system, what prevents them from copying it right now is the opportunity cost (i.e. you arrived first, and have already won a certain clientele, whoever comes after you will have to make extra effort to steal it from you).
Hackers?
If your system uses "security for obscurantism", then stop and review your design. Ideally, systems should remain secure even though all details about the algorithm are public, only the "key" (or equivalent) is secret. If you can’t avoid this, make it harder to read the sources will stop casual attackers (script kiddies) but not the most dedicated, so take that into account when weighing the risks.
Customers as thieves and thieves as customers
If your app is in an "App Store", 95% of people will simply buy it, not try to steal it from you (lie, 20% will buy and 75% won’t use your application). And the other 5% will not simply say "oh, it’s harder to copy, I think I only have to buy..." - they will either give up altogether, or they will try a little harder (remember that just 1 person cracks and distributes to everyone else). One way or another they are not your customers, you won’t get any money from them, so what difference does it make if they copied your app or not?
On the other hand, trying to apply DRM (or any other anti-piracy measure) to a system can make it slower, full of bugs, complicated to install/use/debug, etc. This harms your clients in fact, those who paid for their product and wait for a quality experience.
In conclusion, take simple measures to protect your program when appropriate, but don’t worry too much about it. Don’t depend on the secrecy of sources for security. And focus on creating a better product than the competition, instead of being worried about the competition copying your product as it is now (and not as it will be in 6 months, for example).
Note: "decompile" is different from "decrypt". A theoretically encrypted application would be indecipherable - so much so that even the client’s computer/device could run it... Only if you send together the encryption key, but oops, now the attacker has it, and can decipher the program.
– mgibsonbr
@mgibsonbr é vdd, I will change the term in my question
– Math
blz. I will keep the comment, because it illustrates an important point, which for not everyone is obvious: all the information that the computer needs to run the program is also available to the person who receives a copy of the program. If you omit information for the person, the computer does not receive it either. This only stops being true when specialized hardware is involved (i.e. the secret is in hardware, not software).
– mgibsonbr
The code that connects using JDBC is just an example to illustrate the problem, right? Because in reality the mobile app should not connect directly to the database but rather obtain the data indirectly through webservices.
– Piovezan
@Piovezan yes, he is an example of code that cannot be exposed, the solution is the one you quoted and the utluiz said. However, despite being just an example, I am not remembering another case that I could mention where the code cannot be revealed in any way, because I believe that all these cases that require secrecy could be transferred by webservice after user authentication. So if you have any example to quote and/or solution please do so, because at the moment I am almost convinced that my question has been answered.
– Math
@Math You may want to go beyond the protection offered by the operating system and encrypt local data like Whatsapp ended up doing with users' message history (this requires a locally stored key, which is far from impossible to discover but hides the data of curious people owning devices rooting for example), or, depending on how much you want to make the work of hackers may want to obfuscate web service access data (URL, request parameters) with obfuscators like Dexguard that change literal strings in the code. Obs.: Hinders != prevents.
– Piovezan
@Piovezan understood, these are good questions you raised. That’s basically what I asked in the last paragraph of my question and the webservice solution showed me an alternative to not storing such information on the computer. However, I had forgotten that there are cases that it is not possible to depend on a webservice, as the case of the local history of Whatsapp. This has not really been answered so far. I believe that this would be the last piece left to end the doubt altogether. You would have something to add on that subject?
– Math
@Piovezan I wrote my comment without reading your review. Your excerpt
Dificulta != impede
basically then reinforces an excerpt of the mgibsonbr response, correct? Therefore, there is no way make impossible the access to such information. Then in the case would enter the answer of Eduardobrj, which shows the options of obfuscation. Correct?– Math
@Correct Math. A solution that targets prevent access to sensitive data requires user authentication based on a strong password and using a good encryption algorithm. But there are two different points: preventing someone from hacking their source code and protecting sensitive information stored locally. The first case cannot be stopped, in the case of the second there is this possibility of the way I just spoke.
– Piovezan