Могут ли выражения 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, возникает ошибка времени компиляции.

Я ничего не вижу там, где написано ярлык метки разрыва; должен быть перед или "окружающим" перерывом.