android - gratis - ¿Cómo puedo ofuscar mi sdk codificado con kotlin(y deshacerme de los metadatos)?

descargar kotlin gratis

Question

Estoy desarrollando un SDK (biblioteca de Android), y tengo que ofuscar una gran parte de mi código para que el cliente no intente jugar con el código interno. Mi lib está codificada en kotlin, y utilicé proguard para ofuscar el código. El problema es que todavía hay anotaciones @ kotlin.Metadata (tiempo de ejecución) dentro del código después de la compilación y la ofuscación. Con esas anotaciones, es realmente fácil recuperar el código java que originó este bytecode "(no tan) confuso".

Primero pensé que era mi culpa, y mi proyecto tenía demasiadas fuentes de entropía que podrían haber inducido este comportamiento, así que hice un proyecto de muestra para demostrar que el problema no proviene de mi implementación de SDK. Creé un nuevo proyecto con AS, luego un módulo lib con 2 archivos:

• fachada.kt es mi clase de fachada, la que no deseo ofuscar, por lo que el cliente puede usarla:

  package com.example.mylibrary
  class MyFacade(val internalClass:InternalClass) {
  fun doSomething() {
  internalClass.doSomething(
  firstArgument=1,
  secondArgument=2
  )
  }
  }

• y en este ejemplo, internal.kt contiene las clases que quiero ofuscar:

  package com.example.mylibrary
  class InternalClass {
  fun doSomething(firstArgument: Int, secondArgument: Int) {
  System.out.println("Arguments are : $firstArgument, $secondArgument")
  }
  }

Las reglas de progreso se inyectan en el proyecto gradle con este cierre de versión:

buildTypes {
release {
minifyEnabled true
proguardFiles ''proguard-rules.pro''
}
}

Y aquí está proguard-rules.pro (solo una línea, nada más):

-keep class com.example.mylibrary.MyFacade {*;}

El resultado: cuando ./gradlew clean myLib:assembleRelease , obtengo un área en la que se conserva mi fachada, y mi clase interna ha sido renombrada en ''a'', con un método ''a'', excepto que la clase sigue siendo anotado con kotlin @Metadata, que contiene toda la información que ayuda al descompilador a recuperar el nombre de la clase original, el método, los atributos y los nombres de los argumentos, etc. Así que mi código no está tan confuso en absoluto ...

@Metadata(
mv = {1, 1, 7},
bv = {1, 0, 2},
k = 1,
d1 = {"/u0000/u001a/n/u0002/u0018/u0002/n/u0002/u0010/u0000/n/u0002/b/u0002/n/u0002/u0010/u0002/n/u0000/n/u0002/u0010/b/n/u0002/b/u0002/u0018/u00002/u00020/u0001B/u0005¢/u0006/u0002/u0010/u0002J/u0016/u0010/u0003/u001a/u00020/u00042/u0006/u0010/u0005/u001a/u00020/u00062/u0006/u0010/u0007/u001a/u00020/u0006¨/u0006/b"},
d2 = {"Lcom/example/mylibrary/InternalClass;", "", "()V", "doSomething", "", "firstArgument", "", "secondArgument", "mylibrary_release"}
)
public final class a {
...
}

Entonces, mi pregunta: ¿es posible deshacerse de esas anotaciones, soy el único que enfrenta este problema o me he perdido algo?

Answer 1

Si está creando un proyecto de biblioteca destinado a ser utilizado por otros, no ofusque y reduzca el proyecto , sino que proporcione un archivo ProGuard para el consumidor para sus usuarios implementando las siguientes líneas:

android {
defaultConfig {
consumerProguardFiles ''consumer-proguard-rules.pro''
}
}

Source

En este consumer-proguard-rules.pro que envía con su biblioteca, recuerde actualizarlo en consecuencia, pero recuerde siempre declarar al menos los enumerados y las anotaciones que deben conservarse; de ​​lo contrario, deje que los consumidores getDefaultProguardFile(''proguard-android.txt'') el getDefaultProguardFile(''proguard-android.txt'') Cuidar el resto.

Lo mismo ocurre con la reducción: solo debe preocuparse por garantizar que todos los recursos necesarios (en tiempo de ejecución) se mantengan mediante la implementación de reglas de mantenimiento para ellos.