Могут ли выражения Java break/label действовать как "goto" в обфускации байт-кода?
Я пытаюсь deobfuscate некоторые файлы Java.class после их декомпиляции, и я сталкивался с частью кода, где он использовал ярлыки таким образом, что я не думаю, что они могут быть использованы. Я не знаю, является ли это ошибкой декомпилятора в недоразумении над метками или если код был намеренно запутан таким образом. Другими словами, метки меток могут использоваться таким образом в байт-коде Java?
Обратите внимание, что метки появляются ПОСЛЕ связанных с этим инструкциями break, а не раньше. Похоже, что они используют их как goto, а не метку, используемую для выхода из цикла. Также нет петель, поэтому я немного смущен тем, как они должны использоваться здесь.
Что здесь происходит? Я отметил 3 метки в комментариях (###)
if (i != 96)
{
if ((i ^ 0xFFFFFFFF) != -98)
{
if (i == 98)
break label417; // ### Here are the three breaks... The relevant labels appear later in the code
if (i != 99)
break label540;
if (!bool)
break label461;
}
}
else
{
if (localwb == this.localWB5)
{
if (this.localWB4 != null) {
this.localWB4.a((byte)-92, this);
if (!bool);
}
else
{
this.localWB6.a((byte)-9, this);
}
return true;
}
if (localwb == this.localWB4)
{
this.localWB6.a((byte)-59, this);
return true;
}
if (this.localWB3 != localwb)
break label540;
this.localWB2.a((byte)-38, this);
return true;
}
if (this.localWB6 == localwb)
{
if (this.localWB4 != null) {
this.localWB4.a((byte)-122, this);
if (!bool);
}
else {
this.localWB5.a((byte)-63, this);
}
return true;
}
if (this.localWB4 == localwb)
{
this.localWB5.a((byte)-22, this);
return true;
}
if ((this.localWB2 == localwb) && (this.localWB3.M))
{
this.localWB3.a((byte)-84, this);
return true;
label417: // ### The first label. Note how this next if-statement has inaccessible code... if the above if-statement is true, it would have already returned true; However, the label appears after the return statement, almost as if the label is being used as a goto.
if (localwb == this.localWB2)
{
this.localWB6.a((byte)-86, this);
return true;
}
if (this.localWB3 == localwb)
{
this.localWB5.a((byte)-31, this);
return true;
label461: // ### The second label
if ((this.localWB6 == localwb) || (this.localWB4 == localwb))
{
this.localWB2.a((byte)-60, this);
return true;
}
if (localwb == this.localWB5)
{
if (this.localWB3.M)
{
this.localWB3.a((byte)-44, this);
if (!bool);
}
else {
this.localWB2.a((byte)-9, this);
}
return true;
}
}
}
label540: // ### The final label.
Ответы
Ответ 1
goto
инструкция по байт-коду (да, она фактически называется "goto" ) используется для реализации break
и других конструкций.
Спецификация самого goto
ограничивает цель только тем же методом, что и команда goto
.
Есть много других ограничений, которые определены в 4.10. Проверка файлов class
, в частности Код проверки, в котором описывается, как должен быть проверен фактический байт-код метода.
Я подозреваю, что вы не можете создавать противоречивую интерпретацию локальных переменных и стеков операндов с помощью goto
, например, требуя, чтобы целевая команда была совместима с исходной инструкцией, но я фактическая спецификация написана в Prolog и Я был бы благодарен, если бы кто-нибудь получил соответствующий момент, где это было обеспечено.
Ответ 2
break <label>
можно использовать для выхода из блоков кода, например:
public static boolean is_answer(int arg) {
boolean ret = false;
label: {
if (arg != 42)
break label;
ret = true;
}
return ret;
}
Однако декомпилированный код, который вы показываете, недействителен Java из-за следующего требования JLS:
Оператор A break
передает управление из закрывающего оператора.
Ответ 3
Проблема связана с несоответствием между Java и байт-кодом. Java накладывает множество ограничений, которые отсутствуют на уровне байт-кода. Если все, что вы делаете, это декомпиляция нормального скомпилированного Java файла, это не будет проблемой. Тем не менее, обфускаторы обычно перестраивают поток управления метода в эквивалентную версию, которая больше не соответствует действительной Java. Наивный декомпилятор запутается и просто испустит неверную Java, как вы видели.
Если вы заинтересованы в декомпиляции obfuscated classfiles, вы можете попробовать open source Krakatau Decompiler Я написал. Гораздо умнее пытаться преобразовать запутанный байт-код обратно в действительную Java, поэтому он часто может декомпилировать классы, которые не могут использовать другие декомпиляторы. Однако результирующий код, вероятно, будет не очень хорош, даже если он действителен, и декомпилятор все еще может выйти из строя.
Ответ 4
Всякий раз, когда у меня возникает вопрос о языке Java и как он написан, я имею в виду удобную спецификацию языка Java, которая является очень тщательной документацией.
От 14.15. Оператор break
:
Оператор break должен ссылаться на метку внутри метода непосредственного размещения, конструктора или инициализатора. Нет нелокальных прыжков. Если никакой маркированный оператор с идентификатором в качестве его метки в методе непосредственного вложения, конструкторе или инициализаторе содержит оператор break, возникает ошибка времени компиляции.
Я ничего не вижу там, где написано ярлык метки разрыва; должен быть перед или "окружающим" перерывом.