• XSS.stack #1 – первый литературный журнал от юзеров форума

Communication.

Chococream

Старожил форума
Легенда
Регистрация
31.10.2009
Сообщения
347
Реакции
42
Обзор о методах коммуникации ботнетов.

План:
1)Права, защищающие этот документ.

2)Пролог.

3)Сервер-клиент.

4)FastFlux.

5)P2P сеть.

6)Генератор доменов.

7)Cкан ip диапазона.

8)Метод солнышка.

9)Технология 4-C.

10)Jabber vCard.

11)Метод "Bitcoin".

12)Tor network.

13)Эпилог.

Текст:
1)
Во-первых данный документ носит лишь исследовательский характер и не является призывом к совершению
неправомерных поступков, нарушающих законодательство вашей страны!
Во-вторых незаконное копирование частей текста и любых других его составляющих карается законом
по защите авторских прав собственности!
Разрешено копирование на ваш ресурс, только с указанием автора текста, а также гиперссылки на
оригинальную тему.


2)Существует достаточное количество способов для поддержания связи с ботнетом.
У каждого способа
имеются свои плюсы и минусы. Конечно же, нет универсального. Рано или поздно, исследователи
доберутся до вашего url/командного центра и начнут "ломиться"(писать абузы и т.д) на сервер.

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


3)Технология "сервер-клиент".
В теле бота размещается url командного центра, в последствии с которым он связывается.
Для защищённости используется:
- Шифрование url.
- Шифрование траффика между сервером и клиентом.
- Работа с https протоколом.

Плюсы:
- Невозможно анализировать траффик.
- URL зашифрован.

Минусы:
- URL легко можно узнать, отреверсив сэмпл(зависит от навыков исследователя).

Usability: 80% public ботов используют данную технологию.


4)Технология "FastFlux".
FastFlux используется в основном для скрытия основных управляющих серверов. Основная идея данного
метода заключается в том, что множество IP-адресов может быть связано лишь с одним доменом. Это
достигается за счёт смены DNS записей у домена.

Более подробно: http://www.honeynet.org/node/132
http://www.honeynet.org/node/138

Плюсы:
- Очень сложно отключить и выявить fastflux сеть.
- В качестве командного центра может выступать обычный белый сервер.

Usability: используется в основном в проектах с большим бюджетом(и соотв. окупаемостью), а также
техническими возможностями.
Proof: securelist.com/ru/analysis/208050533/Ekonomika_botnetov


5)Технология "P2P".
P2P - децентрализованная сеть. В ней отсутствуют серверы, т.е каждый бот является одновременно и
клиентом и сервером.

Более подробно: http://ru.wikipedia.org/wiki/Одноранговая_сеть

Плюсы:
- В случае если, источник выдаёт лишь часть ip-адресов, то выявить весь ботнет исследователям
не предоставляется возможным.

Минусы:
- Требуются источники для получения списков ip-адресов.

Usability: из ранее встречавшихся, запомнились - Bredolab, TDL, Palevo.


6)Технология "генератор доменов".
В качестве отправной точки используется, к примеру, текущая дата и на её основе генерируется
доменное имя, к которому и подключается бот.

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

Минусы:
- Большая активность запросов может быть обнаружена всякими эвристическими анализаторами.

Usability: из ранее встречавшихся, запомнились - TDL, Sinowal, Kido, Zeus, Storm.


7)Технология "скан ip диапазона".
Ботом сканируется заданная часть ip диапазона для нахождения командного центра.

Минусы:
- При обнаружении определённой активности, ip адрес сервера может быть легко выявлен.


8)Технология "солнышко".
Придумал я сам, возможно кто-то до меня уже дошёл до подобного, не суть! ;)
Основной замысел данного метода заключается в том, что в боте изначально содержится список из
100~200 url, по которым он в случайном порядке отправляет/принимает информацию и только 1~N сайтов из этого списка явл-ся командными центрами.

url - в данном контексте, - это действующие/фейковые веб-сайты.

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

Если же связь с сервером двусторонняя, командный центр обнаружить также сложно.

Продемонстрирую это на примере:
- Сервер хочет выдать задание боту, т.е один url из списка начинает что-то выдавать(картинка,
html код, просто файл, либо список с новыми url адресами). Как вы уже успели понять, иссле-
дователь, благодаря мониторингу содержимого, выдаваемого списком URL может вычислить истин-
ный адрес, да не тут-то было!
А что, если в списке будут новостные порталы, блоги, с тоннами ротирующейся рекламы, счётч-
иков, баннерами, кто знает, возможно в этой рекламе находится зашифрованное сообщение,
легко идентифицируемое ботом.
Также небольшая иллюстрация на картинке:
14744fec2aea.jpg


Плюсы:
- Данная идея применительна не только к http протоколу, но и к jabber/icq/mra/etc.
- Практически стопроцентная недетектируемость, в комбинации с вышеперечисленными методами
даёт неубиваемый ботнет.
- Отпадают всяческие эвристические анализаторы: бот имитирует заходы на настоящие сайты, соб-
людая между заходами на сайт паузы.
- В списке можно запрятать несколько адресов командных центров.

Минусы:
- Метод требует обфускации алгоритма работы кода, чтобы исследователи не поняли с содержимым
какого url ведётся работа.

9)Технология "4-C"
Итак, опишу основные этапы данного метода:

- Бот парсит социальные сети(facebook, twitter, ...) на наличие в сообщениях изначально зада-
нных(зашитых) выражений(на английском или русском языках. не стоит использовать часто встреча-
емые предложения. достаточно 100-200 ключевых слов). Для того, чтобы сделать текст неприме-
чательным, желательно применить стеганографию или шифрование.

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

- Расшифровав сообщение от владельца, бот получает в своё распоряжение список из 100-200 URL
адресов и secure-строку(2-4 из них - это командные центры, остальные - просто ложные.
см. метод "солнышко"). Парсинг сообщений социальной сети - времязатратное занятие, поэтому
нам выгоднее перейти к непосредственной коммуникации C&C и бота.

- Бот определяет у себя наличие прямого ip. Далее отправляет подряд каждому URL информацию(system
version, ip, nat/no_nat, open_port, ...). C&C ждёт пока "прогрузится" вся сеть
(кол-во установок опустится ниже опр. значения).

- Теперь самое главное:
Боты с прямым ip при отправке информации открывают порт с socks5(авторизация с использованием
ЭП). C&C после замедления "прогрузки" составляет TRUSTED список ботов, через кот-
орых он распространяет остальным нужные данные.
НО, остаются ещё боты, не имеющие прямого ip. Для них C&C создаёт ещё одно сообщение в социа-
льной сети с secure-строкой(редковстречаемой, для быстрого нахождения) в котором содержится
список ботов в виде: IP:PORT. Боты подключаются к случайному и получают данные.
Для большей стабильности, боты с прямым IP иногда должны выдавать списки с другими ботами(это
нецелесообразно, т.к по сути раскрывает кол-во заражённых машин). В случае же если, все IP
окажутся недоступными, NAT бот лезет в социальную сеть за новой порцией URL адресов.

- Почему "4-c" ?
Это обьединение СС(социальная сеть) и C&C(command center).

- Зачем нам социальная сеть ?
Все мы прекрасно знаем как происходит падение/взлом/перехват C&C. Данный способ позволяет избе-
жать этого. К тому же, в любой момент времени ты сможешь создать сообщение в соц. сети и "реани-
мировать" старый ботнет.

- К чему нам метод "солнышко" ?
Регистрация доменов и покупка серверов - затратное дело. Данный способ гарантирует скрытность ваш-
его C&C.

- Открытый порт, списки ботов. По-моему, чем-то напоминает P2P ?
Да, действительно технологии схожи. Одно лишь их отличает: изначально в боте не содержится источ-
ник(C&C) для получения IP адресов.

- Сложновато, можно и попроще.
Нисколько, воплощение данного способа в жизнь - вопрос времени. А коль у вас есть идеи или крити-
ка - прошу к обсуждению.

Плюсы:
- Вместо социальной сети можно использовать: поисковую систему, блоги, форумы, порталы и т.п.

Минусы:
- Атакующий, узнав строку для поиска(зашитое выражение в боте), сможет создать множество записей, тем самым замедлив распространение ботнета.

10)Jabber vCard (author: waahoo)

11)Метод "Bitcoin".
Метод - медленный, может использоваться только для восстановления доступа к ботнет-сети.
Создаём два bitcoin кошелька и пополняем один из них на небольшую сумму.
I)Делаем bitcoin бота, который обрабатывает(не майнинг ;) ) новые блоки на предмет транзакций от 1/2-го кошелька.
Вспомним, что можно отправлять сразу несколько переводов одной транзакцией, а само значение output дробится до восьмого знака после запятой.
Если транзакция есть, то бот берёт дробную часть output значения(сумма, которую мы посылаем 1/2-му кошельку) и декодирует её.
- Чтобы дело не было убыточным - созданы два кошелька.
- Почему именно URL шифруется в сумме транкзации?
Потому что сама система bitcoin не поддерживает создание комментариев к платежу.

II)Использовать сторонние сайты для поиска транзакций. Пример: blockexplorer.com

Плюсы:
- Кошельки не заблокировать(значит командный центр - вечный).
- Доступ к bitcoin узлам не заблокировать - их множество в мире.
- Не требуется проверка зашифрованной команды - доступ к кошелькам имеется только у хозяина.

Минусы:
- Медленная схема. Каждая транзакция(на момент написания слов) проходит в течение ~10минут.

Исследование bitcoin протокола: https://xss.pro/index.php?topic=24896

12)Tor network.
Используется сеть tor(open source) для скрытия адреса C&C.
Более подробно: https://www.torproject.org/docs/tor-hidden-service.html.en

Плюсы:
- Нет платы за доступ к сети.
- Вычислить настоящий адрес C&C сложно.

13)Это скорее не статья, а небольшой обзор.
Как всегда жду от вас конструктивных идей, предложений, критики.
"As always, respect goes 2 all dlab mem`s. Thanks 4 ur support." ©Choco
 
солнышко безусловно интересный концепт, но не замедлит ли это работы ботнета?

всё же видится переспективным п2п решение, что-то типа своя "торрент" сеть.

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

Предложенный мной алго эффективен только при условии безоговорочного превосходства вычислительной мощности нашей бот-сети, над мощностями аверов.
1) зашиваем в бота хеш от известной нам строки ((части)домена админки, по-совместительству). Строку выбираем такой длинны, чтобы при текущей вычислительной мощности ботнета, ее восстановление из хеша заняло "число дней, через которое бот связывается с админкой", например ~1 сутки.
2) а теперь фокус... Пытаемся всем ботнетом сбрутить хеш, который зашит в билд.
Это будет админка "на сегодня".
3) стучим в админку, и забираем "хеш на завтра", теперь весь ботнет брутит его. Новый хеш мы генерим ручками, сами, такой "сложности", чтобы подкорректировать время его "решения" с учетом изменения численности нашей сети.

Перед нами сразу встают следующие проблемы:

1) Без взаимодействия между ботами, никто из них не сможет узнать результат брута.
Это значит нам необходима еще и p2p-сеть между ботами, для распространения "домена связи на сегодня".
Однако, у нас нет проблемы проверки подлинности сбрученного домена - каждый бот это легко проверит, т.к. он брутит этот же хеш.

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

3) А что если у АВ будет б0льшая вычислительная мощность?
Тогда все накроется тазом. Нашей бот-сети лучше бы быть незамеченной до тех пор, пока она не перерастет среднюю ферму по ресурсам. Чтобы удорожить процесс сбрута хеша, можно увеличить интервал перебора с суток до, например, недели.
То есть, если арендовать облако в 30к ядер на сутки еще реально по финансам (ну можно представить), то арендовать такую ферму на неделю, ради сраного хеша - такое ни 1 человек в здравом уме не одобрит.

4) Если домен коротковат (т.к. на длинный пока не хватает мощности сети), и/или уже зарегистрирован?
Элементарно, можно к доменам добавлять префикс, или этот самый хеш+домен+.com

5)6) Задачи построения p2p-сети и распределения диапазонов брута я здесь не рассматриваю, т.к. это совсем не моя ниша.


Что мы решаем таким алгоритмом:
- Проблему реверса, и перехвата предстоящих доменов - их никто не знает, и не узнает, пока не сбрутит.
- Проблему угона через ложные сообщения в p2p-сети. Каждый ее участник всегда легко проверит подлинность "админки на сегодня", т.к "вчера" он получил ее хеш.

Какие проблемы получаем:
- Централизованность. Весь наш зверинец придется снабжать новым хешем с одного домена, и очень быстро. Да и боты еще должны успеть отчитаться\получить прочие задания.
Однако, отказаться от ручной генерации хеша мы не можем (т.к. нам самим заранее нужно зарегистрировать этот домен).
Так же, мы не можем отказаться от админки как источник получения новых хешей, т.к. тогда мы становимся уязвимы для реверса - вынут ключи, и будут рулить сетью как хотят.


Критикуйте)


ps.
гугл говорит что NVIDIA GeForce 8600 GTS, 675 MHz делает по 100 мего-хешей/сек (речь о md5).
В сутки это 864*10e10. Бот-сеть из 50к машин соответственно, делает ~432*10е15 хешей в сутки (на средненьких видюшках)
Это значит что можно за пару часов подбирать 10-символьные [a-z0-9] домены.
 
а может есть такой способ,который предполагает разбиение адреса админки сгенерированного командным центром,и боты по частям склеивают его (то есть например,дали мы команду ботам что на след день админка будет на porno.com/trololo/wahwahwah/enter.php,выдаем ее ботам,и даём команду разбить на составляющие этот адрес,а потом склеивать его и получить адрес).
Как-то так его применить к вышеописанным...
 
Как насчет варианта подмены IP при хттп-запросе к домену?

Тобишь бот может стучаться на тот-же yandex.ru, и в заголовках будет типичный запрос к этому сайту, вот только IP будет другим, который указывается на этапе заполнения sockaddr_in.

А на стороне хостинга создавать правило для домена и обрабатывать запросы как надо.
 
гугл говорит что NVIDIA GeForce 8600 GTS, 675 MHz делает по 100 мего-хешей/сек (речь о md5).
В сутки это 864*10e10. Бот-сеть из 50к машин соответственно, делает ~432*10е15 хешей в сутки (на средненьких видюшках)
Это значит что можно за пару часов подбирать 10-символьные [a-z0-9] домены.
Соберите сначала статистику по наличию видеокарты у заражённых ПК. Я думаю не у всех она стоит. 20-30% из общего числа max(!).

Какова вычислительная мощность нормальной бот-сети, в сравнении с мощностью фермы у ав-лабы?
Дано:
Alphabet: [a-zA-Z0-9]
Letters in alphabet: 64
Number of bots(~): 10.000
MD5 brute speed on CPU(~): 7.000.000(ps)
Botnet speed(~): 70.000.000.000(ps)

Size of domain name(~): 7-10(letters)
Total number of combinations:
- 7 letters: 4.398.046.511.104
- 10 letters: 1.152.921.504.606.846.976
Brute time(~):
- 7 letters: 62 (sec).
- 10 letters: 190 (days).
Т.е эффективнее брутить домены с размером меньше 8 символов.

Aels
Предложенный тобой способ - неэффективен. Исследователи могут просто тупо переждать пока кто-нибудь из ботнет-сети сбрутит хэш и тогда хозяевам снова придётся менять его.
 
Если у АВ есть сэмпл работоспособный, зачем уему что-то брутить - он дождется когда это сделаете вы и просто получит ответ от вашего центра управления. Если это п2п, то ваш бот должен хранить списки ближайших, и при отключении части этих серваков, получить от центра свежий список - попеременно закрывая по одному сайту через неделю получаем весь список нодов.
Так-что "МИША, все ХУ..Я"(С)
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Chococream
Замечания:
алфавит у нас не 64, а 36-37 (с дефисом, или без), потому что A-Z в доменных именах бесполезны.
Того, реально в аккурат получается 9-10 символов в сутки.

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

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

В моей схеме факт реверса не меняет ровным счетом ничего. Ресечер максимум что успеет сделать - написать абузу на "сегодняшний" домен. За время, пока она пройдет - все боты успеют отстучаться, и забрать новых хеш. Аверы всегда будут догоняющими.
Исследователи могут просто тупо переждать пока кто-нибудь из ботнет-сети сбрутит хэш и тогда хозяевам снова придётся менять его.
он и будет меняться каждый день. Сеть сбрутила хеш, раздала его членам, все отстучались и забрали новый. С этого момента старый хеш (и старая админка) - кусок хлама.

паук
и при отключении части этих серваков, получить от центра свежий список - попеременно закрывая по одному сайту через неделю получаем весь список нодов.
только не серваков... обычных машин юзеров (с прямыми адресами). Пусть бот хранит по 2-3 узла (бота с белым адресом), и запрашивает новый (не из админки, а от соседней ноды), при исчезновении одного. Тогда на сколько растянется процедура связи с провайдером, уведомлении каждого юзера, и его отключение?
 
Пожалуйста, обратите внимание, что пользователь заблокирован
- URL легко можно узнать, отреверсив сэмпл(зависит от навыков исследователя)
Имхо, 1 урл в боте - это по любому провальный вариант. Хоть как он там будет зашифрован, хоть рса с 2048битным ключом. Есть же снифферы - запустил и смотришь, куда стучит. Поэтому бот должен делать фейковые запросы, чтобы неясно было, где настоящая админка.
 
говорит уже, повторю еще, можно концепты выдумывать пачками, !но всё познаётся в бою.
в идеале нужно концепт тестить в миру и судить о пригодности на основании результатов..
 
Пожалуйста, обратите внимание, что пользователь заблокирован
demien
потому и выложил мысль. мне не меньше твоего интересно как оно себя поведет.
Кто согласится "все это" сделать в коде? =]
 
Aels
в твоей идее лично я вижу больше недостатков, чем приемуществ.

1) Скажем не включил я сегодня свой ноут, зараженный ботом, или не вышел на работу на выходных и не включал 2 дня свой зараженный рабочий комп => боты не получили хешей на "сегодня" и "потерялись" навсегда.

2) скорость брута очень разная на разном оборудовании. Будь уверен, у аверов она будет over 9000.

3) не вижу проблем для аверов получать хеши и сбручивать их раньше всех ботов.
 
"Солнышко" - мне понравилась идея, вот только:

1) годится она только для отсылки данных, но не для получения.

2) очень много запросов генерится(((

3) домен палит свежая дата создания в WHOIS. Если же затерять его среди таких же свежерегов, то боюсь заабузят и снесут все домены без всяких траблов.
 
Замечания:
алфавит у нас не 64, а 36-37 (с дефисом, или без), потому что A-Z в доменных именах бесполезны.
Того, реально в аккурат получается 9-10 символов в сутки.
Мне не сложно пересчитать :)

Дано:
Alphabet: [a-z0-9-]
Letters in alphabet: 37
Number of bots(~): 10.000
MD5 brute speed on CPU(~): 7.000.000(ps)
Botnet speed(~): 70.000.000.000(ps)

Size of domain name(~): 9-10(letters)
Total number of combinations:
- 9 letters: 129.961.739.795.077
- 10 letters: 4.808.584.372.417.849
Brute time(~):
- 9 letters: 30 (min).
- 10 letters: 19 (hours).

Неэффективен почему?
Исследователь переждет, пока боты сбрутят адрес админки и? что он будет с ним делать?
Пойдет, и максимум что узнает - задание для подконтрольного бота, и хеш следующей админки.
1)Заблокируют текущий адрес админки, тем самым предотвратив распространение.
2)Брут грузит CPU(делать задержки как вариант, но это замедлит брут в разы). Т.е выполнять своей функциональной задачи бот не сможет и будет мешать юзеру.
3)Сбрутят следующий url.
4)Зависимость от p2p, мой же способ не испытывает нужду в децентрализованной сети.

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

2) очень много запросов генерится(((
Мы же не ддос-бота пишем, можно задать интервал определённый, собирать результаты выдачи веб-сайтов в кучу, затем прозводить парсинг этой "кучи".

3) домен палит свежая дата создания в WHOIS. Если же затерять его среди таких же свежерегов, то боюсь заабузят и снесут все домены без всяких траблов.
Не обязательно использовать "свежереги", как альтернатива: взломанные. Суть в том, что административных центров - всего 2-4(по вашему усмотрению), а сайтов-фейков - куча, к тому же они могут и не принадлежать вам(новостные порталы, софт-порталы и т.д).
Ваша задача - "скрыться" среди них.
 
Стенографию не хочется сюда лепить, т.к. всё это быстро отреверсится авшниками, там же не начинающие сидят...

Взломанные очень не надёжно...

p2p надо мутить короче...
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Left4Dead
так "вам реверс или ехать"?
До реверса у чоко отличная схема. Тем более, ни кто же не сказал, что дергать надо именно разные домены. Можно разные профили в fb, например. Позле элементарнейшей стенографии, без реверса будет не понять что хотели от бота.

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

Что касается голого p2p... снова хорошо до реверса. Потом вынут ключи, прикинутся доверенным ботом, и или уведут, или заглушат.
 
Aels
Что касается моего варианта... ну так не честно, такие аргументы приводить против, как "забыл, не зарегал, забил".
И хеш будет браться из админки (которая не юзер зараженный, а сервер). А значит их генерацию, и регистрацию предстоящих доменов, есть смысл автоматизировать.

Вы о чем вообще? Вы опираетесь на то, что юзер каждый день будет включать комп и бот будет скачивать актуальный хеш. Но это ошибочное предположение, потому что компы не каждый день включаются.

А "у аверов ферма мощнее"... я ж специально написал, что затея имеет смысл, если наша ферма больше. Да, сейчас выпускается много специализированного железа для брута. Но оно заточено на специфичные алгосы, значит возьмем экзотичные хеш-функции.
Проц (или видео) грузит - тут ничего не поделаешь...
"если наша ферма больше" это то же что и if (1 == 0)
Вы пробовали вообще когда-нибудь брутить хеш на видеокарте? Вы знаете, что есть разные производители видеокарт с разной архитектурой, драйверами, SDK? У Nvidia cuda, у ATI OCL. А какие тормоза начинаются при бруте видели? Похоже что нет, иначе бы вы понимали что на видеокарте вы брутить не будете, да и не на всех ботах она есть. Следовательно, брутить будете на CPU. Так вот аверам достаточно иметь 1 GPU и он будет работать быстрее тысячи ваших CPU.

Что касается голого p2p... снова хорошо до реверса. Потом вынут ключи, прикинутся доверенным ботом, и или уведут, или заглушат.

Уже страшно представить, что такое "голый р2р" в вашем представлении. Но в моём представлении никакие ключи на ботах не хранятся, кроме публичного ключа оператора ботнета для проверки ЭЦП его команд.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Left4Dead
пожалуйста-пожалуйста-пожалуйста, давай смотреть чуть дальше букв.
В чем проблема пошарить между ботами сегодняшний хеш (для тех, кто не успел в админку)?

Да, я пробовал брутить на видео, и в курсе, что проблем с дровами немерено.
Разница в топ видео, и cpu, все же, не 3 а 2 порядка (n00 раз). То есть сеть из 10к эквивалентна кластеру с сотней топовых видеокарт. Это уже не дешево, и является серьезным препятствием к перехвату.

"голый 2p2" в моем понимании "только p2p".

В случае передачи информации оператор->бот, у бота хранится закрытый ключ, оператор подписывает команду открытым, передает боту. Бот проверяет ее подлинность закрытым ключом. Или я заблуждаюсь?
http://ru.wikipedia.org/wiki/Криптосистема_с_открытым_ключом
 
Ethernet создавался открытым, соответственно, все эти мутки с сетевыми технологиями профита не принесут (или до определенного момента, потом на помойку). Проще грузить на машины без ав, или без свежих баз. Ну или если очень хочется побыть первопроходцем, то пытаться бороться с ав (искать дыры в нем, писать сплоиты и юзать).
А все попытки сделать закрытый/хитроделанный протокол успешны до первого попадания на десктоп реверсера.
 


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх