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

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

Добавлено в [time]1346367998[/time]
Хотя бы понаблюдать,если позволите.Может чего то и предложу.На этом флейм закончен.
 
Left4Dead, про генерацию доменов и подпись, я сразу написал.

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

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

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

а то в один прекрасный день, смахнул пыль с ноута, регнул доменов три дня вперед ( домены генерятся от даты ), купил белый серв, поставил на него софт ( контролеры, админка ) с приват ключем ( для эцп ) и через какое то время твой ботнет начинает возвращаться на него.
 
Если тебе принципиально поспорить, мне проще с тобой согласиться. Но так же можно смахнуть пыль с ноута, взять хрумер, проспамить паблик базу нужным значением и через сутки наблюдать как все возвращается. Я не настаиваю ни на чем - мне все равно как это будет.
 
Чтобы не загонять, друг друга в тупик (а я об этом заранее предупреждал!)
Предлагаю начинать с децентрализации.
Админки и CC не будет, пока в этом не появится адекватная необходимость.
На начальной стадии разработки - лоадер будет качать (просто тупо качать) с расшареного ресурса нужный файл, если возникает необходимость получить стату, делаем прогруз стукача через лоадер, а стукач уже будет соответственно собирать инфу о пробитом компе, отсылать на временный СС и сразу же умирать...
Таким образом, мы разбиваем одну задачу на две
Создаем базовую систему команд лоадера DOWNLOAD и UPDATE
Стукач также являться будет одним из важных элементов, так как его код (когда это потребуется) может быть перенесен в лоадер для интерфейса с СС
Не буду вдаваться в подробности, но это должно упростить нам всем кодинг... ИМХО
Предлагаю каждому создать несколько отдельных тем (каждый создает свою, со своим направлением), где каждый предложит свои идеи с базовой инфой и кодом (если это того требовать будет сабж)
И далее будем смотреть на виток развития событий, где будет лучше всего получаться - то и возьмем за базовую основу, пока не появицца что-то лучше...
Я через некоторое время создам тему о децентрализации и выложу туда базовую инфу - там, скорее всего, потребуются те, кто кодит на Delphi, сильно напряжного ничего не будет, я бы даже сказал, будет полезным для простого совместного кодинга, как раз увидим, что нас в "будущем" ждет...
Сейчас же нужно подождать Ar3s с его "модифицированным" ТЗ и доступом новых мемберов...
паук пишет:
Я не настаиваю ни на чем - мне все равно как это будет.
Каждый (если есть такая возможность и желание) должен пытаться делится инфой (не важно - за или протифф), так как это при любом раскладе принесет пользу...
ЗЫ: Уверен в своей правоте - зафакай тему оппонента.. уверен в своей теме - покажи все профит ;)
 
Ну по поводу серваков крути не крути дохнут они часто. Написать файл который непонятно куда стучит тоже невозможно - мы люди взрослые, давайте небудем фантазировать на тему того что нас спасет привязка к железу или суперпупер анти-методика. После запуска дропера файл попадет в облако так или иначе. Когда таких файлов попадет туда скажем 5к за 1 день, к роботу анализатору, который там ничего не нашел, подключится индус с отладчиком. Все - детект. А возможно и не тольок детект но и бан серваков. Надо менять все.

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

Нерезидент не имеет смысла писать помоему совсем. Шелкод с метасплойта и пару апи на антиэмуль и вот вам непаленый нерезидент. Мы ж тут разрабатываем мозг после летних каникул , а не добиваемся результата я верно понимаю :)

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

КЛАСИЧЕСКЙИ РЕЗИДЕНТНЫЙ ЛОАДЕР С ЕДИНСТВЕННЫМ КОМАНДНЫМ ЦЕНТРОМ

Верно?!
 
el
Left4Dead, про генерацию доменов и подпись, я сразу написал.
я не так понял словосочетание "от балды" :)

паук
просто пару-тройку доменов зарегать проще, чем играться с хрумером, индексацией. Еще у гугла месячные бывают и его сильно колбасит :D
 
Зато в случае использования поисковиков вообще нет необходимости тратиться на сервер. Нет постоянно необходимых доменов, нет абуз, нет херовых хостеров, нет псевдо-антиабузных серверов...

Хорошо, делаем с выделенным сераком, или с p2p (я так ине понял как, я себе потом перепишу под поисковики :))
 
паук
Если исключить из схемы сервер, то не будет обратной связи с ботами. Куда они будут слать отстук об успешной инсталляции, логи формграббера, ФТПшки? А нафиг нужен бот без обратной связи? Тогда со связки сразу грузить нужные несколько ЕХЕ и не париться. Либо же ботов надо научить быть Хрумерами и постить отчёты по всему интернету, что есть нетривиальная задача.

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

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

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

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

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

вплане расширений, все пишут как то так
if cmd = 'load'
elsif cmd = 'update'
и теперь что бы сделать какое то расширение надо пересобирать лоадер, править кучу файлов. можно же сделать xml конфиг в котором передаются заведомо неизвестные данные, каждый плагин сам получает нужные для него данные, плагины же могут добавлять в цмд хандлер свои команды, надо собрать куки пожалуйста, небольшой бинарник который это сделает и скрипт файл, контролера на сервере, который получит данные и обработает их.

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

while ((c_node = c_xml->enum('main', 'plugins')))
c_plug_tree->get_instance()->load(c_node);

плагин куков стартует и добавляет в коммандый обработчик новую команду

cmd_handle->get_instance()->add('cookie');

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

while ((c_plug = c_plug_tree->get_instance()->enum()))
c_plug->get_data();

они сами знают какие данные им должны быть переданы и как их от туда достать, это может быть любая статичная инфа, типа порта для сокса

допустим передали команду cookie ядро, тупо обходит секцию комманд и запускает их, передавая скажем в виде параметра объект ноды

while ((c_node = c_xml->enum('main', 'commands')))
cmd_handle->get_instance()->start(c_node);

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

plugin_cookie_cmd(CNODE c_node)
{
s_arg = c_node->get_param('mask');
... дальше идет работа по поиску с этой маской, каких то куков
далее он просто передает их в протокол, который отправит все это дело в следующем запросе на сервер, который будет тогда когда будет а не сию же секунду
c_proto->add('cookie_section', s_data);
}

в общем в моем понимание, классный расширяемый лоадер ( бот ) состоит примерно из столько необходимых модулей/классов которые надо бы написать

https - для связи
xml - конфиг
fs - модули, конфиг, собранные данные да и набор инфы которую надо передать, надо же где то хранить
loader - это не то что качает и запускает, а вообще все возможные моменты которые могут понадобится, будь то запуск экзе, запуск длл в номом процессе или подьем какого то своего формата
plugin_handler - хранилище плагинов в памяти
cmd_handler - хранилище и запуск команд
message - скорее всего придется передавать какие то сообщения в ядро или между плагинами. например есть хукер который ставит хуки в каком то там процессе получает, там какие то данные и передает их в общий пайм сервер ( лучше сделать один на все случаи жизни ) и вот этот пайа сервер уже будет рассылать мессаги плагину, а плагин реагируя на них обратно ему дабы он что то передал ... в общем стек сообщений нужен какой то.

там же понадобиться описать оснастку системы, универсальная работа с файлами, реестром сетью и т.д. которая будет предоставлять в виде апи для работы внутри, дабы не городить что попало в коде, типа у одного память выделяется LocalAlloc у другого VirtualAlloc третий вообще в файл пишет ;D

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

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

* вообщем... схема EXE Dropper -> Dll иньекция в свчост.ехе
тут сразу всплывают "псевдокосяки" и следствия одного из другого... обширный поток мыслей улавливаю, трудно удерживать и выстраивать в правильный порядок, но...
вы писали про собственный криптор, а для дропа длл он ой как нужен будет, но тут всплывает такая весч как чистки... т.е. уже нужнен(ны) люди кто будут заниматься чистками\поддержкой крипта для длл\ехе дропера. При условии что крипт будет паленым, а такие случаи бывают, что не всегда можно быстро детект выпилить и приходится сидеть не один час или даже день. Суть в том, что чтобы не растерять ботнет чел обратится к стороннему криптору, который может криптонуть без учета спецификаций, с ошибками, которые могут всплыть уже на стадии иньекта в свчест и такую ошибку будет ой как не просто обнаружить сразу... етц... Я к тому, что использование ДЛЛ это серъезный шаг и если аццептим его, то нужно продумать все шаги до мелочей.

* единый дропер без длл, который будет содержать в себе ШК маленького бинаря (об этом тут https://xss.pro/index.php?act=ST&f=12...=20#entry131367 , #22)
это гуд для крипта, но и палевно. можно также иньектить ШК в свчост.ехе, но опять же нужно где то жить чтобы после рестарта снова внедряться...

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

з.ы. уже писал, но
есть мысль использовать https://cryptobin.org с генерируемым паролем чтобы брать линки на скачку а также другие параметры, которые там будут в зашифрованном виде. пока нет, но пишут, что скоро должен появиться апи. Знаю что пасс будет все равно виден на выходе, как например серийный номер при генерации и сравнивании внутри какой-нить шараварной софтины. Но... такой сервис не так то просто закрыть на основании того, что там будут храниться ссылки на файлы. Теоретически способен выносить большие нагрузки.

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

1 базонезависимый пе лоадер

пасс: %@#%@#%@#%@#%!@$
http://www.sendspace.com/file/pkb6z6

2 криптор по типу который описывал Left4Dead, а именно берем образ того что криптовать, присобачиваем к нему пе лоадер и этот буфер размазывается на 100500 всяких операций, которые в итоге соберут его в кучу и передадут управление, сделать это проще всего скриптом, создав сорец а потом собрав его.

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


3 ну и лоадер, тут уже конечно надо бы думать что да как лучше, но раз у нас есть уже есть ( будет вернее, пункт 2 ) скрипт который размазывает стаб на черт пойми что, то лучше всего имхо сделать дропер такого плана:

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

все же тут можно разбить еще на подзадачи и подпункты...

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

p.s. пока у нас тут междуусобные войны вышел power loader... если заявленное соответствует действительности, то это достойный продукт, и нам нужно стремиться превзойти его уровень. как мне кажется, наш акцент будет сделать на сложность реверса сэмпла и дольшую недетектируемость, что позволит жить дольше, в то время как в том продукте обходы... и теоретически жевучесть vs обходы эквиваленты... не?
 
живучесть и р3 вещи несовместимые
 
имело ввиду взаимозаменяемы.. т.е. пробив осуществляется или за счет качества или за счет кол-ва. вообщем думаю кому надо поняли

ну так... это все что можно сказать по теме?
ребят...!
 
Ragnar, да ладно, скажи это новой версии zeroaccess. вообще дело в подходе, чем больше семплы друг от друга отличаются ( в плане установки в систему ) тем меньше шансов добавить их все. на нескольких пп отлично живут простые юзермодные боты без всяких руткитов и т.д.

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

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

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

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

мне например было интересно по обсуждать + некоторые моменты за которые я потихоньку сел, а именно в данный момент заделал класс обертку над cryptoapi для осуществления коварного плана по передачи данных от бота до сервера и обратно:

как я уже говорил в предыдущих постах ( а мб и не говорил ) я все же настаиваю на использование https, внутри него же передавать свои данные xml пожаты gzip и пошифованный следущим образом:

- запрос

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

на сервере ( в моем примере, я все декриптую там же на криптоапи ) скажем с помощью вот этого http://phpseclib.sourceforge.net/, во всяком случае я обязательно с этим потестирую в ближайшее время, или на чем там будет написана серверная часть будет делать следующие. с помощью приватного ключа расшифровывается сессионный ключ, им расшифровывается сообщение от него считается хеш, который сравнивается с переданным дабы убедиться что все ок.

- ответ

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

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

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

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

openssl genrsa -out 1024.priv 1024
openssl rsa -in 1024.priv -pubout -out 1024.publ

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

Код:
	//////////////////////////////////////////////////////////////////////////
	// client side
	//////////////////////////////////////////////////////////////////////////
	// import public key
	// generate session key
	// encrypt message by session key
	// hash it
	// export session key with encrypt by public
	// assembly packet

	cfile c_file;
	std::string cl_pem = c_file.to_mem(L"K:\\1024.publ");

	cprov cl_prov(cprov::prov_pair(MS_ENHANCED_PROV, PROV_RSA_FULL));

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

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

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

	std::string s_sess = cl_ses_key.export_blob(SIMPLEBLOB, cl_key.get_key());
	std::string s_hash = cl_hash.hash_val();

	std::string cl_packet;
	cl_packet.resize(sizeof(_packet_header));
	_packet_header* cl_pack = (_packet_header*)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);

	//////////////////////////////////////////////////////////////////////////
	// server side
	//////////////////////////////////////////////////////////////////////////
	// parse packet
	// import private key
	// import session key with decrypt by private key
	// decode message by session key
	// check hash

	std::string sv_packet(cl_packet);
	_packet_header* sv_pack = (_packet_header*)sv_packet.c_str();
	std::string sv_s_sess, sv_s_hash, sv_s_mess;
	sv_s_sess.assign(sv_packet, sizeof(_packet_header), sv_pack->dw_sess);
	sv_s_hash.assign(sv_packet, sizeof(_packet_header) + sv_pack->dw_sess, sv_pack->dw_hash);
	sv_s_mess.assign(sv_packet, sizeof(_packet_header) + sv_pack->dw_sess + sv_pack->dw_hash, sv_pack->dw_mess);

	std::string sv_pem = c_file.to_mem(L"K:\\1024.priv");

	cprov sv_prov(cprov::prov_pair(MS_ENHANCED_PROV, PROV_RSA_FULL));

	ckey sv_key(sv_prov);
	sv_key.import_private_pem(sv_pem);

	ckey sv_sess_key(sv_prov);
	sv_sess_key.import_blob(sv_s_sess, sv_key.get_key());

	chash sv_hash(sv_prov, CALG_MD5);
	capi::decrypt(sv_sess_key, sv_s_mess, sv_hash.get_hash());

	if (sv_s_hash.compare(sv_hash.hash_val()) == 0)
  _DBG("all ok");
	else
  _DBG("bad hash");
 
как уже говорили в большинстве случае коллективный проект на форуме заканчивается неудачей

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

p.s. эль на основании чего решается, что машина которая стучит на серв реверсера или аверлаба или обычного пользователя, т.е. зараженная?

вся эта защита делается с целью усложнить сниф и анализ, т.е. рса, сжатие, да еще и через https...?

как каркас, для чего-то, вроде цитадель\зевсов это да, обломает всякие трекеры етц, но в рамках лоадера уж слишком усложненно;)

Я полагаю что воровство это не лучший способ наживы.
Как модули для монетизации вполне можно:
0. сам лоадер - резидентный и нерезидентный (для сервисом инсталла)
1. сокс модуль. в идеале поднять сокс4\5 сервис
2. ну ддос под вопросом.. их ща как грибов, так что не думаю
3. спам... тоже не факт, хотя задуматься можно
4. кликер - вполне себе реальная тема
5. и самое реальное сейчас - ПОДМЕНА выдачи!
6. етц...

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


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

p.s.s. кто то знает почему кразз ушел?
 
Единственное мое объяснение - психи. Я отписал ему в асю. Молчание.

И второе. Давайте решим. Продолжать или нет? Я согласен на 100% с el-. Я должен признаться в том, что изначально хотел кразу утереть нос. У него было миллион тонн позитива. Я даже начал верить в него. В то что он разбудит форум. Но когда увидел результат - решил написать ему об этом. Остался плохим. Тогда я создал ему все условия. Все что он просил. Итог?

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


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