Небезопасный android: эксперименты с sun.misc.Unsafe. Часть 1

Java очень глубоко интегрирована в android и имеет в данной ОС свою нестандартную виртуальную машину — Dalvik VM, поэтому многие детали реализации отличаются от привычных. А что насчёт внутреннего API sun.misc.Unsafe? В этом цикле статей с его помощью мы попытаемся максимально сломать виртуальную машину андроида.

Введение

Начать стоит с того, что данный класс из себя представляет и для чего обычно используется. sun.misc.Unsafe существует с очень ранних версий java и необходим для выполнения действий, которые не предусмотрены языком, а их реализация в нативном коде по каким-то причинам нежелательна. Какие же возможности он предоставляет?

• Object allocateInstance(Class<?> cls) — создание объекта, без вызова конструктора. Все поля заполняются стандартными значениями (0, 0.0, null и т.п.)

• XXX getXXX(Object obj, long offset) — чтение памяти, используя объект как указатель. Если он равен null, то смещение выступает в качестве нативного адреса

• void setXXX(Object obj, long offset, XXX value) — запись в память по тем же правилам, что и при чтении

• int arrayBaseOffset(Class<?> cls), int arrayIndexScale(Class<?> cls) — определение параметров массива (смещение от начала массива до первого элемента и размер элементов соответственно)

• long allocateMemory(long bytes), void freeMemory(long address) — обёртки над malloc и free из Си — выделение и освобождение памяти вне кучи

• void throwException(Throwable th) — «скрытное» бросание исключений (без их объявления в throws). Увы, но данный метод отсутствует в Unsafe андроида, поэтому придётся создавать его самостоятельно

• А так же куча других полезных вещей, особенно для многопоточного программирования, которые в данный момент нам не нужны

Подготовка

Как получить доступ ко всему этому инструментарию? Класс Unsafe содержит публичный метод getUnsafe, только вот незадача — в нём есть проверка безопасности:

public final class Unsafe {
    <...>
    private static final Unsafe theUnsafe = new Unsafe();
    <...>
    @CallerSensitive
    public static Unsafe getUnsafe() {
        Class<?> caller = Reflection.getCallerClass();
        // Этот код не даёт получить экземпляр ползовательским классам
        if (!VM.isSystemDomainLoader(caller.getClassLoader()))
            throw new SecurityException("Unsafe");
        return theUnsafe;
    }
    <...>
}

Один из способов обойти её — прямой доступ к статическому полю theUnsafe через рефлексию

public static Unsafe getUnsafe() {
    try {
        // получаем поле
        Field field = Unsafe.class.getDeclaredField("theUnsafe");
  
        // делаем его доступным для использования
        field.setAccessible(true);

        // получаем экземпляр sun.misc.Unsafe
        return (Unsafe) field.get(null);
    } catch (Exception e) {
        throw new RuntimeException(e);
    }
}

Этот код настолько часто используется в разнообразных библиотеках, что его можно назвать классическим. Он даже не вызывает предупреждений во время выполнения (а вот доступ к конструктору вместо поля — ещё как).

Теперь нужно восполнить отсутствие метода throwException с помощью сломанного класса Thrower — мы создадим в нём метод с нужной сигнатурой, и насильно удалим throws Throwable:

.class public Lcom/v7878/Thrower;
.super Ljava/lang/Object;

.method public constructor <init>()V
    .registers 1
    invoke-direct { p0 }, Ljava/lang/Object;-><init>()V
    return-void
.end method

.method public static throwException(Ljava/lang/Throwable;)V
    .registers 1
    throw p0
.end method

// Не скомпилируется,так как нет throws Throwable
public class Thrower {

  public static void throwException(Throwable th) {
    throw th;
  }
}

Эксперименты

Время перейти к самому интересному, тому, ради чего затевалась статья — экспериментам.

arrayCast

Что произойдёт если мы попробуем обратиться к объекту класса A как к объекту класса B, например попытаемся вызвать метод или получить поле, которого у него нет? Язык защищает от таких поступков ещё на этапе компиляции, и не даёт нам творить беспредел, но ведь теперь мы можем это игнорировать, да? Обмануть компилятор (а заодно и верификатор байт-кода) можно положив объект в поле неправильного типа и обращаясь уже к нему:

// Смещение от начала массива до первого элемента
// int ARRAY_OBJECT_BASE_OFFSET = arrayBaseOffset(Object[].class);

class A {
    public int a;
}

class B {
    public int b;
}

A obj = new A();
obj.a = 100;

B[] array = new B[1];

// array[0] = obj;
putObject(array, ARRAY_OBJECT_BASE_OFFSET, obj);

System.out.println(array[0].b);

// System.out: 100

В данном примере мы положили объект типа A (со значением 100 в поле a) как первый элемент массива B и получили значение 100 из поля b. Как это произошло?

public class Object {
    <...>
    private transient Class<?> shadow$_klass_;
    private transient int shadow$_monitor_;
    <...>
}

Теперь можно обобщить полученный опыт и сделать отдельный метод, выполняющий функцию оператора reinterpret_cast из C++

// Смещение от начала массива до первого элемента
// int ARRAY_OBJECT_BASE_OFFSET = arrayBaseOffset(Object[].class);

// размер элемента массива объектов (на андроиде всегда должен быть 4)
// int ARRAY_OBJECT_INDEX_SCALE = arrayIndexScale(Object[].class);

public <T> T[] arrayCast(Class<T> clazz, Object... data) {

    // нам нужен массив объектов, а не чего-то ещё
    if(clazz.isPrimitive()) {
        throw new IllegalArgumentException();
    }

    // создаём массив типа T
    T[] out = (T[]) Array.newInstance(clazz, data.length);

    // переносим все объекты в массив
    for (int i = 0; i < data.length; i++) {
        putObject(out, ARRAY_OBJECT_BASE_OFFSET + i * ARRAY_OBJECT_INDEX_SCALE, data[i]);
    }

    return out;
}

Свежеиспечённый метод принимает класс, к которому мы хотим привести группу объектов, и сами объекты, кладёт их в массив нужного типа и возвращает. Удивительно, но андроид ни разу не проверяет, что именно лежит в массиве, поэтому всё проходит гладко.

Теперь давайте применим arrayCast для изменения private final поля, чего нельзя сделать с помощью обычной рефлексии:

class A {
    private final int value;

    public A(int value) {
        this.value = value;
    }

    @Override
    public String toString() {
        return Integer.toString(value);
    }
}

class B {
    public int value;
}

A obj = new A(100);

// приводим obj к типу B
B[] array = arrayCast(B.class, obj);

// меняем значение
array[0].value = -1;

// выводим в консоль
System.out.println(obj);

// System.out: -1

Получается, что при известном строении объекта с его полями можно творить что угодно, но как насчёт методов?

class A {
    private final int value;

    public A(int value) {
        this.value = value;
    }

    @Override
    public String toString() {
        return Integer.toString(value);
    }
}

class B {
    public int value;

    public void set(int x) {
        value = x;
    }
}

A obj = new A(100);

// приводим obj к типу B
B[] array = arrayCast(B.class, obj);

// меняем значение
array[0].set(-1);

// выводим в консоль
System.out.println(obj);

// ожидаем получить: System.out: -1
// получаем: zygote A [runtime.cc:492] Runtime aborting...
// и огромный столб текста с аварийным дампом

Что произошло? Почему такие ужасные последствия у, казалось бы, маленьких изменений? Причина кроется в способе вызова методов — по индексу в списке внутри класса объекта. Мы вызываем метод B.set(int), допустим он имеет индекс 1, но вызываем то мы его на объекте типа A! У него другой список, и под индексом 1, может быть, идёт конструктор. Это несоответствие и вызывает ошибку.

Но почему такого не происходит при доступе к полям? Ответ прост — они всегда имеют постоянное смещение и его нет нужды вычислять каждый раз по индексу поля в классе, а значит, для оптимизации всегда идёт прямой доступ по заранее просчитанному смещению.

В будущем мы периодически будем обращаться к arrayCast для достижения своих целей. На этом вводная часть подходит к концу.

*Продолжение следует*

Весь исходный код можно найти здесь.