Владимир Дубровин

Нет, вы поняли неправильно. Во-первых, эксплуатация переполнения буфера зависит от того, где расположен буфер. Скорей всего вы имеете ввиду переполнение стекового буфера aka stack overrun.
При "классической" прямой эксплуатации переполнения буфера в стеке "по aleph1" в буфере размещается шел-код, затем сохраненный в стеке адрес возврата перезаписывается адресом, указывающим внутрь буфера (на шелкод), при возврате из функции выполняется шелкод.

Однако, такие приемы работали до того, как появились технологии защиты стека, неисполняемой памяти и рандомизации размещения в адресном пространстве. Сейчас для эксплуатации переполнений стека на практике обычно требуются приемы ROP (return oriented programming), т.е. ваши знания очень сильно устарели.

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

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

Цели публикации проекта в исходных кодах могут быть разные:
1. Личные убеждения
2. Юридическая необходимость (например проект основан на GPL-коде)
3. Простота дистрибуции (нет необходимости самостоятельно мейнтейнить порты для разных ОС/дистрибутивов)
4. Наработка портфолио/репутации
5. Бизнес модель (продукт поставляется бесплатно, но есть донат или поддержка оказывается за деньги - выгодно чтобы продукт использовался как можно более широко). Это особенно актуально если разработчик ПО зарегистрирован как благотворительный фонд, т.к. в США, например, компании могут донатить в такие фонды часть налогов а фонд имеет возможность платить разработчикам зарплаты. Фонды, например, имеют Linux, Apache, NetBSD. nginx зарабатывает на коммерческой поддержке.
6. Как ни странно, если код открыт - нет необходимости заботиться о том, чтобы его не украли конкуренты и проще доказывается авторство.
7. Если продукт изначально разрабатывается не для продажи, а для внутреннего использования - возможность привлечь внешние ресурсы к разработке и меньше тратить свои.
8. Реклама бренда - очень часто небольшие компании делают бесплатный продукт, в т.ч. с открытым кодом, чтобы продвигать платные продукты.
...

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

Смотря как вы инжектите DLL, при обычной загрузке выполняется DllMain().

При правильной прокладке витой пары правильно выбранной категории (для 100BASE-T достаточно cat5) на расстояние до 100 метров потерь не будет.

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

Это значит, что у писем, которые вы отправляете нет SPF/DKIM авторизации домена из поля From но есть SPF или DKIM домена domain.com.
Необходимо:
1. Использовать адрес SMTP-конверта того же домена, который используется в From письма
2. Настроить для этого домена SPF
3. Подписывать письма DKIM с доменом DKIM (d=) совпадающим с доменом из From.
Для проверки этих и прочих настроек, можно воскользоваться, например, этим сервисом.

У вас ссылка
https://telemed.medlinesoft.ru:8447/drclinics//sta...
не используйте нестандартные порты, доступ к ним часто запрещен.

Сама по себе SITE является частью протокола FTP, но команды, доступные через нее стандартом не определены.

Исторически, протокол FTP это расширение протокола telnet (доступа к шелу) для передачи файлов. Команда SITE дает возможность выполнить на удаленном сайте какую-то команду, которая не является частью спецификации FTP, поэтому то, что вызывается через SITE по определению является нестандартным. Раньше это обычно реализовывалось путем размещения бинарников в какой-нибудь специальной папке, типа /var/ftp/bin (т.е SITE cpfr запускал /var/ftp/bin/cpfr), и таким образом можно было дать доступ через FTP к каким-то определенным командам или скриптам, сейчас таким образом обычно реализуются нестандартные расширения.

Заведите на DNS-серверах в AD отдельную зону name.test.com.

PTR должен совпадать с HELO/EHLO, в соответствии с RFC 5321

o The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4.

в EHLO должен быть использован основной hostname (primary hostname).

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

P.S.
в соответствии с RFC 1035

- Gateways will often have two names in separate domains, only
one of which can be primary.

т.е. primary name может быть один и по определению зоны in-addr.arpa

Host addresses are represented by domain names that have all four labels
specified. Thus data for Internet address 10.2.0.52 is located at
domain name 52.0.2.10.IN-ADDR.ARPA. The reversal, though awkward to
read, allows zones to be delegated which are exactly one network of
address space. For example, 10.IN-ADDR.ARPA can be a zone containing
data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
MILNET. Address nodes are used to hold pointers to primary host names
in the normal domain space.

т.е. и HELO и PTR тоже смотрят на primary host name, который у хостов имеющих имена во многих доменах может быть только один (даже если у них несколько IP-адресов).