https://bugtraq.ru/library/books/stp/chapter05/

Глава 8.3.2 в [1] содержит следующую фразу: "A MAC frame conveyng a BPDU". Это значит, что BPDU это пакет, а не фрейм. Таким образом, нет необходимости конструировать фреймы самостоятельно, поскольку они стандартны для данной физической среды - мы можем конструировать BPDU пакеты выше, чем самый нижний подуровень 2-го уровня OSI. Иначе говоря, можно отвязать программу конструктор BPDU от конструктора фреймов, оставив функцию инкапсуляции соответствующему драйверу. Однако, авторы выбрали для своих исследований создание программного модуля, конструирующего BPDU напрямую. Исходный текст модуля на языке C и сценарий на языке bash для более удобного манипулирования параметрами командной строки приведены в приложениях.

Авторы долго не могли прийти к единому мнению: стоит ли делать эти тексты общедоступными. Без понимания принципов работы STP и выбора параметров эти тексты ничем не помогут личностям с деструктивными наклонностями, а человек, который разобрался в сути уязвимости, может воспользоваться любым конструктором пакетов. В связи с этим, тексты решено было включить в открытую публикацию.

Чем хорошо создание фреймов напрямую:

1. Можно ставить произвольный MAC-адрес источника, что значительно осложняет определение реального источника атаки. До тех пор покуда не применяется насильственный line-jamming (заявка коллизий в их отсутствие в CSMA/CD сетях
2. Если конструировать фреймы самостоятельно, можно добиться ситуации при которой атака идет как бы параллельно с нормальной работой, маскируя таким образом атакующего за счет передачи пакетов с "фальшивого" MAC адреса одновременно с нормальной работой в сети со "своего" MAC адреса.
3. По мнению авторов, пока не существует стандартного (одинакового для всех систем) способа формировать BPDU иначе, чем конструируя фреймы полностью. Это говорит о том, что реализации алгоритмов таким методом для FreeBSD, OpenBSD, Linux и других OS будут существенно различны, в результате чего лучшим способом будет все же посылка BPDU в полностью самостоятельно сконструированных фреймах.

Чем плохо создание фреймов, а не пакетов Spanning Tree:

1. Поскольку Spanning Tree протокол определен для различных типов MAC.

Media Access Control (управление доступом к среде передачи данных). Например, Ethernet, Token Ring и т.п., код получится непереносимым между ними.

Ethernet был выбран авторами из-за наибольшей распространенности, по сравнению со всеми остальными типами сетей.

Помимо написания собственных программ есть возможность использовать готовые программные средства, обернув их в скрипты на любом подходящем языке, например, perl или языках shell - bash, zsh, ksh, csh (см. раздел 9), что значительно упрощает работу с параметрами Spanning Tree. Однако при этом появляется дополнительное условие - Linux с ядром, настроенным для поддержки bridging плюс соответствующий комплект утилит. Еще одним отрицательным моментом выбора такого пути будет необходимость накладывания патчей на исходный код Linux bridging project в случае, если потребуется сконструировать атаку с модификацией алгоритма работы, выходящей за рамки стандарта, например, изменить значения таймеров на меньшие или большие, чем описано в стандарте.

Стоит также сказать несколько слов на тему особенностей программирования под разные операционные системы и выбора языка:

Windows-подобные системы.

В этих системах, исключая Windows XP, нет поддержки raw sockets, что не позволяет без специального драйвера (VxD) конструировать фреймы напрямую - как обычно гибкость windows систем "из коробки" оставляет желать лучшего. Поэтому под windows системы и unix системы это будут совсем разные реализации. Ну, разве что, писать на perl, который, однако установлен не на каждой windows системе. Еще вариант - использовать java, приложения на которой можно запускать автономно при помощи jre.

Unix-подобные системы.

В качестве языка лучше всего выбрать C-компиляторы - они есть во всех unix-подобных системах практически под любую платформу. Впрочем, можно было выбрать и perl - там тоже есть raw-sockets. Возможны проблемы портирования на другие unix-подобные системы с linux, т.к. отличаются названия интерфейсов. Но это можно легко решить при помощи Makefile. А вот если различаются API -- придется потрудиться побольше.