How to protect source code?

Asked

Viewed 20,768 times

156

I am thinking of making an application to sell, I would like to know how to protect my source code to keep my software safe.

I saw the Java bytecodes, stored in the file .class are easily converted back to .java using the tool Java Decompiler

The .class can be easily found within a .jar for the case of desktops, or even in a .apk, as shown in that post.

How do millions of apps in Google Play protect their source code? Because leaving them exposed seems to me a little insecure, or is not it? If yes (if it is insecure), has how I develop applications that keep hidden the source code in Java for desktop and Android?

EDITION

The @mgibsonbr response convinced me not to be paranoid and want to protect all the source code, however there are some points of the application that cannot be disclosed for reasons of data security, for example:

try {
    String url = "jdbc:mysql://mysql01.meudominio.com/bd";
    Class.forName("com.mysql.jdbc.Driver");
    conn = DriverManager.getConnection(url,"usuario","senha");
    System.out.println("Remote database connection established");
}

Imagine the damage if someone has the address, user and password of your database.

In the comments @mgibsonbr tried to answer this my question, but I did not understand, or maybe I have not made the doubt clear, anyway.

On the obfuscator, through tests I could see that it works. However I have doubts if it is really the solution I am looking for or if the solution is actually to remodel my software in a way that does not store in the source code any kind of information that require secrecy such as user, passwords and BD addresses.

If the solution is to remodel the software, please explain to me how to maintain a file external to the source code in a way that is not possible the hacker copy the part of my source code that reads that external file, having then the code that can read the file, the same way my software does.

java android security-guard decompilation obfuscation
  • 4

    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.

  • 5

    @mgibsonbr é vdd, I will change the term in my question

  • 1

    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).

  • 2

    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.

  • 1

    @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 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 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?

  • @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?

  • @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.

Show 4 more comments

7 answers

164


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).

  • 1

    apenas a "chave" (ou equivalente) seja secreta what key are you talking about? and how to keep something secret if everything is exposed?

  • 5

    @Math I’m talking about cases where the system uses encryption or something like that. See 2nd principle of Kerckhoff. But if your system has none of that, then that doesn’t apply. And about keeping something secret when the source code is exposed, think of a "password" field for example: you know the field is there, you know how it works, but from that you can find the password of a particular user? No. The code is not secret, but the data sane.

  • 1

    But if my system uses encryption however much my key is secret my program will still use it, correct? For example, the password is 123, then I use hash and turn it to xyz, the person will not know that the password is 123 but you can from the source (which is exposed) know how to use the key xyz instead of the password to, say, access a comic book. Or was there something I didn’t understand? Forgetting the competitors part, piracy, etc.. You already convinced me of all this, rsrs.. I only have left the doubt of data security.

  • 2

    @Math In this case the key must be in a data file (configuration, for example), and not in the sources. In the installation, the program creates this file (preferably different for each client). In case of suspected intrusion/break/leak, only this file is replaced, not the entire program - which would have to be done if the secret was in the sources. Naturally, the customer must protect this file against unauthorized access (at case of Android for example it’s quiet - one app can’t access other’s private data).

45

I believe that the point is not to protect the source code itself, as many have said.

However, I want to highlight this issue of protecting sensitive data. Robust applications and systems should not use such mechanisms, i.e., encrypt login and password data.

First because the application access would be better done via a web service, for example a Rest API.

The best applicable concept would be to authenticate the user in this API using a registration that he must do before accessing the system, for example, using the email and a password or key that he receives when registering.

The application is then configured with the user’s account and sends the e-mail and the key to each request it makes to the server, which then checks if it has access to the requested function, performs the necessary action and returns the data to the application, for example, via Json, HTML or XML.

Thinking of another scenario, for example, where you make an app for ordering in restaurants. Each app connects directly to the restaurant’s bank. In this case, the access data could be defined via configuration and not fixed in the code.

Not only in apps for mobile, but in any system, I would consider it a bad practice to leave access data hard-coded in the code.

  • 1

    I liked the answer. I think that was the missing piece to complete the answer to my question.

  • I had focused more on the part where you talked about the webservice, where the comic is remote. But in the case of a local comic as in the example of the restaurant I did not understand very well. You said to set access via configuration, would it be basically the user and password stored in a file apart? What would be the advantage of this?

  • @Math The advantage is that access data can be changed when needed. If you sell the app, you could, for example, require periodic password changes to avoid security issues. Also, you could establish a different password for each client and it wouldn’t do anyone any good to decompile the code, since it would only break the code itself and not from other clients. Anyway, this question is very complex because it depends a lot on the architecture of your application, the form of distribution and the type of control you intend to exercise.

17

There is a native tool on Android called proguard. Very simple to use, does the same java code obfuscation process as the other tools.

Basically you enable by adding to project properties. the line:

proguard.config=proguard.cfg

Done that, every time you generate one. APK by right-clicking the project, going to Android Tools and then Export Signed Application Package, the code will be obfuscated. Same goes for Export Unsigned Application Package.

you can use a proguard.cfg template that sits in the SDK installation folder tools/proguard/. in this folder there are two files proguard-android.txt and proguard-android-optimize.txt

Source and more information at https://github.com/exmo/equizmo-android/wiki/Ofuscando-aplicativos-Android

15

Solution for Source Code Protection

The only alternative I’ve found for this is known as Ofuscamento of .JAR, with it you will difficulty reverse engineering in your application follows below some links that explain about the subject in great detail.

Links related to Obfuscation:

  1. Related doubt
  2. Protecting your code
  3. Java - Frog
  4. Download PDF About Obfuscation
  5. Obfuscate code

Program for Obfuscation

I use the proguard to do this ofuscamento hindering reverse engineering in .JAR

Links related to Proguard

Observing: The links are to help in understanding the subject.

  • 1

    There are paid tools that add more sophisticated protections, such as Arxan, but the cost is 5 to 6 figures in dollar. It can be interesting for really critical cases like a banking application etc.

  • A license of Dexguard costs 480 euros. Already less than the 5 to 6 digits in dollar. :)

11

Having read the various answers, I want to say that I agree with the majority, but having debated myself not so long ago with the same problem I would like to raise a few points that I think are important to mention.

  1. Java code is totally dependent on JVM binaries, so to run and take advantage of all its features, it will always be dependent on the JVM, so dependent on someone or something. It is no coincidence that multinationals invest millions in programming languages and platforms.

  2. The motivation to violate a source code of any software is dependent on the value that the market attributed to the solution and its usage license cost, that is, more successful more investment by those who protect as by those who "attack"

  3. To protect a multiple proprietary solution may be the solutions but clearly not by code.

Today a software solution is much more than a product... The trend is increasingly to be a product with services or set of services.

In my opinion a licensing system is essential because today a software is much more than its source code, it is also a specific market... and because everything costs money even what is free has a cost, it is important to know the market that our final software product conquers, so that decisions are made.

In many systems it is also important to deliver some level of security and data control and a licensing system helps and much.

Having a licensing system does not mean having the inviolable code, it puts only a control over who uses when and how... The technological solutions are there...be it encryption, webservices that put the secret of the business on the server side, etc.

Of course we must make life harder for those who try to violate the source code and for that, resort to what best suits your solution.

A user is always a potential customer and with that in mind the sky is the limit.

9

Well I already download apk and have applied reverse engineering in the program of others to see how they were made. In my case as a programmer of Games I wanted to get some ideas, but I never got a source code in the whole, just saw what was good and optimized my own code. I found a lot of class that came in the java itself and didn’t know, putting it in my project and speeding up the service. The most they will do is take ideas of the good part of your code, only you remove the comments already disturbs enough, because the comments can be recovered, already the variables no, they saw as var1, var2, var3... Dai it has to be deduced what was done there.

  • 1

    I didn’t know bytecode had comments. I have for myself that they are removed during compilation, since they have no utility in executable code.

  • Test there: http://www.javadecompilers.com/apk and this : http://www.javadecompilers.com/ you load the.jar file and it returns the code to you in a zip file

  • 1

    I also use reverse engineering for that purpose, I remember a moment I did a game as a college activity, I compiled the project and then I don’t know how I lost all the sources kkkk the luck was that I didn’t use any obfuscator and with Java Decompiler I recovered everything, exactly the way I created it...

6

The best way for you to protect your source code is not to make it available to the user. Host the source code on the server and provide access to resources only to authenticated users, a webservice.

You can make an application with the Java Enterprise Edition (JEE) platform in the backend, which has several technologies:

  • Servlets - Are Java components run on the server that aims to generate dynamic content (HTML and XML) for the web.

  • Java Server Pages (JSP) - Specialization of Servlets that allows Java applications to be more robust and easy to develop.

  • Java Server Faces (JSF) - It is a web framework with the Java-based MVC (Model, View and Controller) standard that helps simplify interface development (system screens) through a UI model.

  • Java Persistence API (JPA) - It is a standard Java API that uses the concept of relational object mapping and is used for data persistence. This tool brings a lot of productivity, because it can develop applications that work with databases without writing any SQL line.

  • Enterprise Java Beans (EJB) - Components that run in an application container and provide ease and productivity in developing distributed, transactional, secure, and portable components.

  • JDBC (Java Database Connectivity), used in database access and connection.

Sources:

http://respostas.guj.com.br/51696-tecnologias-mais-utilizadas-no-desenvolvimento-de-sites-em-java

https://www.devmedia.com.br/jee-um-caminho-prazeroso-e-interessante/3747

  • the best answer of all, and apparently the only one that works: "The best way for you to protect your source code is to not make it available to the user."

Browser other questions tagged java android security-guard decompilation obfuscation

You are not signed in. Login or sign up in order to post.