Запутывающий Android API - PullRequest
Новая
       7

Запутывающий Android API

0 голосов
/ 05 января 2019

Я читал статью о различных способах запутывания приложений для Android с точки зрения защиты их от обратного инжиниринга. Одна вещь, которая пришла мне в голову, состояла в том, можно ли запутать API Android? Предположим, у меня есть код Android: 

import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import android.util.Base64;
import android.util.Log;

public class MainActivity extends AppCompatActivity {
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Log.d("Hello", "World");
    }
}

Есть ли способ запутать код, чтобы получить что-то вроде этого: 

import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import x.y.z;

public class MainActivity extends AppCompatActivity {
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        z.w("Hello", "World");
    }
}

Я придумал два пути:

  1. Создание пакета x, имеющего подпакет y, имеющего класс z. Класс z должен иметь метод с именем w, который вызывает Log.d. На самом деле здесь используется слой косвенности, и обратное проектирование становится немного сложнее.
  2. Создание пакета x, имеющего подпакет y, имеющего класс z. Получение исходного кода android.util.Log из здесь и вставка всего кода в класс z (не забудьте переименовать метод d в w). Это определенно увеличит размер кода, но значительно усложнит реверс-инжиниринг.

Являются ли эти способы правильными? Есть ли более простой способ?

UPDATE:

Статья, в которой упоминается Android API, может быть запутана:

ViewDroid: Обнаружение переупаковки устойчивых к запутыванию мобильных приложений , раздел 5.2.1

1 Ответ

0 голосов
/ 05 января 2019

Создание пакета x, имеющего подпакет y, имеющего класс z. Класс z должен иметь метод с именем w, который вызывает Log.d. На самом деле здесь используется слой косвенности, и реверс-инжиниринг становится немного сложнее.

Создание инструмента для отмены этой косвенности не составит особого труда.

Создание пакета x, имеющего подпакет y, имеющего класс z. Получение исходного кода android.util.Log отсюда и вставка всего кода в класс z (не забудьте переименовать метод d в w). Это определенно увеличит размер кода, но значительно усложнит реверс-инжиниринг.

Он также не будет компилироваться, так как ваше приложение не имеет доступа к com.android.internal.* символам, различным native методам и т. Д.

Являются ли эти способы правильными?

Если под «правильным» вы подразумеваете «скомпилировать и запустить», первый из них будет.

...