Fork bomb windows 10

У моих друзей непрограммистов нередко возникают необычные идеи, которые приходится воплощать мне. Одна из них: как сделать, чтобы компьютер завис. Или как сделать, чтобы на нем нельзя было работать? Хотя бы до перезагрузки?

Одним из решений данной задачи является создание так называемой fork-бомбы – программы, которая будет создавать свои копии, которые, в свою очередь, также начнут бесконечно копироваться. Написать эту программу может любой человек за две минуты. Для Windows:

1. Открываем блокнот.
2. Пишем в нем «start %0 %0» (без кавычек).
3. Сохраняем файл как “up.bat” (это например, на самом деле название может быть любым, главное – это указать расширение “.bat” – пакетный файл для Windows).
4. Запускаем его.

Видим такую картину:

Простой вызов диспетчера задач вам не поможет – процессов за несколько секунд будет уже больше сотни, и их число будет постоянно увеличиваться! Так что придется только перезагружать. А если вы поставите программу в автозагрузку, например, то товарищу, над которым вы хотите подшутить, будет совсем не до шуток. Как это сделать?

1. Откройте пуск – выполнить – regedit – откроется встроенный редактор реестра.
2. Открываем в реестре ветку HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run и добавляем в неё новый строковой параметр. Назвать его можно как угодно, а вот значение должно содержать путь к нашей fork-бомбе, то бишь файлу up.bat.

Теперь при загрузке компьютера сразу будет запускаться программа, мешающая работе компьютера. Если пользователь на вы с системой, то убрать её будет не так уж просто.

Вот так можно создать простейшую fork-бомбу.

Автор этого материала — я — Пахолков Юрий. Я оказываю услуги по написанию программ на языках Java, C++, C# (а также консультирую по ним) и созданию сайтов. Работаю с сайтами на CMS OpenCart, WordPress, ModX и самописными. Кроме этого, работаю напрямую с JavaScript, PHP, CSS, HTML — то есть могу доработать ваш сайт или помочь с веб-программированием. Пишите сюда.

программы, розыгрыши, шутки, программы шутки

fork-бомба

Рекурсивное порождение процессов, ведущее к отказу в обслуживании, или падению системы

fork-бомба — вредоносная или ошибочно написанная программа, бесконечно создающая свои копии (системным вызовом fork()), которые обычно также начинают создавать свои копии и т. д.

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

Программа классической fork-бомбы (написанная на языке Си) выглядит так:

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

Содержание

Описание [ править | править код ]

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

Кроме заполнения списка процессов, возможны также стратегии заполнения виртуальной памяти, процессорного времени, сокетов и других системных ресурсов. Результатом исчерпания этих ресурсов становится замедление работы или практический останов операционной системы и/или полезных программ (зависание компьютера).

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

Примеры fork-бомб на разных языках программирования [ править | править код ]

Более элегантный вариант:

Трудность ликвидации [ править | править код ]

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

Однако, на практике некоторые fork бомбы не требуют таких радикальных мер и могут быть уничтожены без необходимости перезагрузки. Рассмотрим, например, случай бомбы из примера выше:

Особенность этого кода в том, что он не зацикливается после неуспешного порождения своих копий, а завершает работу. В результате список процессов постоянно находится на грани заполнения: одна из копий fork бомбы завершается, и освобождающееся место тут же занимается новосозданным процессом из другой копии fork бомбы. Становится возможным конкурировать с fork бомбой за захват места в списке процессов. Тогда возможно рано или поздно запустить команду для одновременного уничтожения всех копий fork бомбы или запустить безопасную программу, которая будет постепенно «отвоёвывать» место в списке процессов до завершения работы последнего процесса fork бомбы. Пример такой безопасной программы на zsh:

Предотвращение [ править | править код ]

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

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

Другое решение проблемы — интеллектуальное распознавание fork бомбы средствами самой операционной системы, но это решение не нашло широкого применения.

Существует и такая трудность, что если fork бомба занимает всё доступное процессорное время, то результаты её работы могут быть катастрофическими не только на однопроцессорной, но и на многопроцессорной системе, даже при ограничении числа процессов. Например, если число процессоров 16, а максимум количества запущенных процессов 100, то на каждый процессор будет приходиться в среднем 6-7 работающих экземпляров fork бомбы, пожирающих процессорное время. Для решения этой проблемы применяется ограничение по привязке к процессорам.

Несколько подробностей о шаблонах или форк-бомба этапа компиляции

Ресурсы

Один ноутбук c 4Гб памяти,
процессором «Intel® Core(TM) i3-2330M CPU @ 2.20GHz»,
ОС Linux 3.7.3-101.fc17.x86_64
и отключеным swap разделом.
Отключить своп пришлось по тойже причине, по которой в названии поста появилась форк-бомба. При достаточно большом объеме задачи компилятор выедал всю память и начинал активно обмениваться с диском, что намертво и надолго вешало машину.

Версии компиляторов:

• g++ (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)
• Intel® C++ Intel® 64 Compiler XE for applications running on Intel® 64, Version 13.1.1.163 Build 20130313
• clang version 3.3 (trunk 179304)

Длинные массивы

Самый простой способ — организовать массив этапа комиляции и нанизать на него функций. Вот так:

В итоге должена получиться функция main() заполненная пустыми бесполезными операциям nop.

Размер последовательности nop теоретически определяется глубиной рекурсии. В мане g++ утверждается, что максимальная глубина 17 и 1024 для с++11.

В стандартах конкретных чисел я не нашел. Обнаружился лишь пункт, что максимальная глубина рекурсии определяется реализацией:
4.7.1.14 для с++03
4.7.1.15 для c++11
Что и подтвердилось на опыте. Для достаточно большого LVL компиляторы вылетали. Удивил clang++ который вылетал на 2 13 , в отличие от g++ и icpc достигающих 2 17 .

Сборка осуществлялась командами:
в рамках

Сравнение разных уровней оптимизации для одинаковых компиляторов

Потребление памяти во время компиляции	Размер исполняемого файла	Количество символов в исполняемом файле	Количество операций nop

Сравнение разных компиляторов при различных уровнях оптимизации

Потребление памяти во время компиляции	Размер исполняемого файла	Количество символов в исполняемом файле	Количество операций nop

Файл максимального размера получился 14МБ для 2 17 компилятора icpc. Для g++ — 12 МБ. Оба при O0. Уровен оптимизации O0 не выполняет inline подстановку, поэтому количество nop символов совпадает с количеством nop операций.

Высокие деревья

Для линейной структуры данных размер генерируемого файла ограничивается, как минимум максимальной глубиной рекурсии принятой по умолчанию(256 для clang++, 900 для g++). Чтобы обойти его можно попробовать создать дерево. Максимальная теоритическая глубина дерева этапа компиляции — (sizeof(long)-1) == 63. А 2 64 байт переполнит любой диск. Практический предел много меньше.
Используя дерево, мы не выходим за пределы максимальной глубины рекурсии.
Исходный код занимает 19 строк и выглядит так:
В итоге получается дерево, каждый узел которого имеет собственный тип. Каждый тип характеризуется парой чисел:

• N — номер уровня;
• I — номер узла на уровне.

Каждый узел внутри одного уровня пронумерован от 0 до N.

Баловаться с nop-ами тут я не стал, использовал сложение. Глобальная long x — использвалась для контроля правильности сборки. В результате возвращается 2 LVL+1 .

Сборка осуществлялась командами:
в том же сценарии что приведен выше.
Максимальный LVL получился равным 18 для clang++. Для g++ и icpc — 16, причем не зависимо от того была ли указана опция —std=c++11 или нет. Компиляторам не хватало памяти.

Похоже изображения правильно масштабируются только в хроме.
Для других браузеров

Потребление памяти во время компиляции	Размер исполняемого файла	Количество символов в исполняемом файле

Потребление памяти во время компиляции	Размер исполняемого файла	Количество символов в исполняемом файле

Максимальный размер файла:

• 43МБ для icpc -O0 -DLVL=17;
• 42МБ для clang++ -O0 -DLVL=17;
• 22MB для g++ -O0 -DLVL=16.

Явное инстанцирование

Линковка заняла меньше минуты. В результате получился файл размером 53МБ. Это файл собирался с -O2. -O0 дало бы больший размер, но пересобирать это несколько раз я не стал из-за времени и бессмысленности результата.

Самое большое отношение объем/количество строк = 2.3Мб/cтроку получилось для массива из первой части (icpc -O0 list.cc)
Метрика конечно шутошная, но забавная. 2.3 — максимум что получилось. Буду рад узнать если кто-нибудь получит большее отношение.

Upd: Strip не делал, а надо было бы. Думал там пара килобайт — а оказалось процент от размера, причем достаточно большой. После strip максимальный размер снизился до 37MB(с 53). и 8.6MB(с 14). Соответственно отношение — 1.43МБ/строку.