Kotlin got a boost last year when Google made it the official recommended development language for Android. Many teams/products have joined Kotlin’s support, dACHang’s apps are numerous, and the community is rave about Kotlin. Those of you reading this also believe that you’re either using Kotlin, or you’re going to use Kotlin.

Here, I would like to give you a warning: the introduction of Kotlin in old projects, if not properly configured, can lead to source leakage! . This means that all of our protective operations like obfuscation and reinforcement have been wasted! This is a serious security issue!

As shown in figure. While I was wandering around the Internet, I came across an application package that contained Kotlin’s source file!

No problem such as authentic source files, code, comments are complete.

Cause analysis,

When I found out about this, I thought to myself: Did I accidentally dig up a big story about Kotlin? As long as I use Kotlin, it will be open source?

I tried to reproduce this scenario locally, but unfortunately, neither the new version of the Kotlin Plugin nor the old version of the Kotlin Plugin came out with a.kt file. Later, the author tried to apply the Top50 apps of treasure scraping, and found that although there were many apps using Kotlin, there was no code leakage as shown in the picture. How can we locate the cause of the problem if we can’t reproduce it? There was an impasse.

Later, when I looked at my own app, I saw the same problem with The introduction of Kotlin. Then this is a big deal.

The process of investigation and positioning is not tabled, and the intuitive result is that the APK package printed out is mixed with the. Kt source file under the source directory.

As we know, in the packaging process, there is a step called Jar bundle resource merge, this step will merge the Jar bundle resources together, package into APK. Since APK contains.kt files, it is most likely that there is a problem with merging resources.

Gradle is the same gradle, Kotlin Plugin, and Build Tools with the same configuration. Gradle is the same gradle, Kotlin Plugin, and Build Tools with the same configuration.

In other words, Gradle’s Jar resource merge task is not the cause of the problem. If Gradle had a problem, the community would have known about it.

But the problem still has to be solved, since it is the resources are merged package, then find a way to do the exclusion of specified resources.

This part of The work is done by The Java Plugin, so go to The documentation: The Java Plugin.

First look at this task:

From the description, this task is what we are looking for, copy resources into the jar package resource directory.

Looking further down, the default directory structure for your project:

The resources directory is placed in SRC /main/resources, or the corresponding SRC /< code set >/resources directory.

To customize the configuration of the resource directory, look at this:

That is, this configuration specifies the location of the resource directory for the code set. It will exclude.java files in the directory, and other plug-ins may also remove additional file types from there.

Okay, so you get the idea, right?

Reasonably, the directory structure of the default generated project is separated from the resource directory and the code directory. Since APK contains the.kt source code, it must be the case that the resource directory and the code directory are the same.

Since the Java Plugin removes.java files from the resource directory by default, the source code can be safely removed from the previous packaging without causing leakage.

Now, when we introduce Kotlin, we will keep the original code directory structure, and the.kt files in the code directory will be packaged into APK as resource files because they are not included in the resource culling scope.

I also found.aidl files, the interface files defined for IPC communication, in the apps where the source code was leaked. The same is true for leaks of such documents.

At this point, the source code leakage case, also solved.

Of course, it’s a little early to say that it’s all speculation, and even truth needs to be tested.

Go back to build.gradle for your own project:

android {
    sourceSets {
        main {
            manifest.srcFile 'AndroidManifest.xml'
            java.srcDirs = ['src']
            resources.srcDirs = ['src']}}}Copy the code

Sure enough, the directory where the resource files reside and the directory where the source code resides are configured in the same way.

As for the cause of this problem, the author reflected. This project is a relatively early project, the code directory structure follows the Eclipse era specification, later embrace changes to Android Studio, Gradle default project layout specification and Eclipse are quite different, in order to avoid major changes to the project, so we adopt the custom directory configuration. Migration is accomplished at a low cost. Things change, and when it comes time to embrace Kotlin’s change, something goes wrong.

Repair plan

It’s easy to understand the problem and decide on a solution:

  1. Plan 1: Remove it directlyresources.srcDirs = ['src']Configuration.
  2. Option 2: Add a new proposal type to the resource catalog.kt.
  3. Plan 3: Separate the resource and code directories from each other.

Of these plans, plan one is a little rough and ready. For Android projects, this is not bad, because many of the resources are stored in assets, and projects rarely put such resources in assets.

Scheme two applies to those cases where there are other resource files in the resource file besides the.kt file, as might be the case with traditional Java development.

Option three is the safest, most normative recommendation. Separating resources from code keeps related files physically isolated, making the overall structure of the project clearer.

In my case, it would be better to modify the project structure to conform to Gradle’s specifications.

But ultimately, the problem is technical debt. Most of the time, in the process of development, we will be for convenience, in line with the idea of reducing the impact as far as possible, take a compromise approach, spent a while, but often buried the root of the disaster.

In the short run, you can do that, but in the long run, you have to pay off the debt. It’s just a matter of time.

The last

The last of the last, suggest that everyone self-check, avoid the occurrence and the author of the unified situation. Especially those Android projects that have moved on from the Eclipse era!

Thanks for reading to the end and I hope you found this article helpful. If you find my article helpful, please give me a like/thank you/like. If there are mistakes, please also feel free to comment. Welcome to leave a message to discuss. : -)

Afterword.

After this article was issued, some friends left comments, pointing out that this article has the title party suspicion. I beg to differ. Indeed, as some of my friends have said, it’s just that he made a mistake in his configuration, and Kotlin is innocent of anything.

This is not a programming language pot, but it is the Kotlin Plugin on the Kotlin tool chain that fails to take into account the security vulnerabilities caused by such scenarios. The Java Plugin, on the other hand, handles this scenario much better.

Although I eventually attributed the problem to the project configuration, I still believe that the Kotlin Plugin is partly responsible for this situation. The Kotlin Plugin is no exception to the complete tool chain, which can bring great convenience for development and use. The author in the Kotlin access configuration tutorial, see many people in promoting the introduction of Kotlin is very convenient, convenient behind, but may accidentally bring such a big security risks, I think, it is necessary to remind the use of Kotlin everyone.

In addition, security problems are often caused by mistakes in small details, and mistakes often come from people. Einstein said, “Only two things are infinite — the universe and human stupidity.”

Projects that meet this problem are basically from the Eclipse era, and the value of such projects is expected to be self-evident. I see, some students think that the source code leakage leakage, love who see who see. Personally, this is a kind of irresponsibility to the project.

The above.

To update the

The previous headline “Using Kotlin could cause Source Leaks!” “Improper configuration, or lead to Kotlin source leakage!” , more intuitive and straight to the point. : -)