conti/Conti Documentation Leak/docs/modules/ТЗ криптолокер.txt

КРИПТОЛОКЕР И АДМИНКА
ТЕХНИЧЕСКОЕ ЗАДАНИЕ


ЦЕЛЬ

Написать криптолокер и backend/админку к нему с учетом текущих рыночных реалий.


РОЛИ В СИСТЕМЕ

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


БИЗНЕС-МОДЕЛЬ И ВЫПЛАТЫ

Все выплаты адвертам идут транзитом через наши кошельки.
Жертва платит на bitcoin-адрес, привязанный к кошельку владельца системы.
С этого кошелька деньги отправляются адвертам; в кошельке оседают наши комиссионные.
Таким образом, адверт НЕ КОНТРОЛИРУЕТ bitcoin-адреса, которые указываются на лендинг-страницах,
и НЕ МОЖЕТ указывать свои адреса И КОНТАКТЫ на лендинге.
Вообще, лендинг-страница должна проходить жесткий ценз системой.

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

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

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

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


БОТ-ЛОКЕР

0. Бот должен пробивать свой IP по онлайн-базам гео-данных.
ПРИСУТСТВИЕ IP-АДРЕСА В ЗОНЕ СНГ ПРИВОДИТ К НЕМЕДЛЕННОМУ ПРЕКРАЩЕНИЮ РАБОТЫ И УДАЛЕНИЮ С ДИСКА!
Как получить свой внешний адрес см.п.7.

1. Бот должен обеспечить свою персистентность в системе (сохраняться между перезагрузками).
https://habr.com/ru/post/425177/

2. Бот должен получать максимально возможные привилегии в системе:

3. Бот должен обходить UAC:
https://github.com/hfiref0x/UACME
(рабочие методы где-то примерно с середины 30..)
Не пробовать на личной машине! может повредить ОС.

4. При установке в систему бот должен генерировать ID.
ID бота - это строка, состоящая из двух компонентов разделённых точкой.
Первая часть имеет формат %MACHINE%-%USER%_XYYYYYYY, где
MACHINE - имя компьютера
USER - имя юзера
X - символ обозначающий тип системы на которой работает клиент
(W - windows, L - linux, A - андроид, M - Mac OS),
YYYYYYY - 3-7 цифр содержащих major-version, minor-version и build операционной системы если таковые имеются у систем
(например, длЯ 6.1 build 7600 это будет 617600).
Вторая часть содержит 32 случайных символов 0-9, A-F.
Пример id клиента - HOSTNAME-USER_W617600.11223344556677889900AABBCCDDEEFF.
Параметр не чувствителен к регистру.

5. В боте захардкожено название его группы - строка из шести символов, первые три символа - латиница нижний регистр, остальное - цифры.

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

Предлагается следующая схема:
- билдеру на вход подаются .obj-файлы
- содержащий изменяемые ресурсы (группу итд) .obj-файл компилируется из исходника (либо обрабатывается некой утилитой)

7. Бот должен собирать следующую информацию об окружении:
- версия и билд ОС
- список сетевых интерфейсов с IP-адресами
- внешний IP-адрес
https://habr.com/ru/company/emercoin/blog/335458/
https://github.com/emercoin/emercoin/blob/master/src/stun.cpp
// список установленных программ

Эти данные передаются на командный сервер.
Бот получает адрес командного сервера через резолв домена Emercoin DNS.

8. После установки и закрепления в системе, бот начинает шифровать файлы в системе по следующему алгоритму:
8.1. Алгоритм шифрования - как вариант ChaCha или другой потоковый асимметричный шифр.
Требования к криптоалгоритму:
- потоковый (разработан для быстрой обработки потока)
- быстрый
- асимметричный (есть приватный и публичный ключи)
- есть открытая реализация на Си.
Не пытаемся самостоятельно реализовать криптоалгоритмы, берем только готовые варианты!
8.2. Программа шифрует файлы вшитым в нее публичным ключом.
После обработки файла, рядом создается файл с таким же именем и двойным расширением .txt.crypted,
содержащий лендинг-текст.
8.2.1. Учитываем, что расширение файла - это сигнатура №1 для антивирусов.
Возможно, нужно по максимуму использовать стандартные расширения (.txt) вместо нестандартных (.crypted, .crypt итд).
8.3. Программа работает в одном из двух режимов: быстрый или полный.
В быстром режиме шифруется только первый мегабайт файла. Это нужно, чтобы быстро накрыть систему.
В полном режиме шифруется весь файл.
8.4. Перед началом работы программа убивает процессы из списка, и останавливает сервисы из списка.
При ошибках, программа пытается повторить действие трижды с интервалом в 2 минуты.
Дальнешая работа не зависит от результата данного шага.
8.5. Программа сперва обрабатывает каталоги из особого "быстрого" списка - списка каталогов,
которые необходимо пройти первыми.
8.6. Программа НЕ ТРОГАЕТ файлы и каталоги из особого стоп-списка - списка файлов, которые нельзя трогать.

При этом сочетания быстрого списка и стоп-списка обрабатываются так:
8.6.1. Мы накрываем все пути из быстрого списка, не указанные в стоп-списке
8.6.2. Если в стоп-списке весь диск, на этом диске накрываем только пути из быстрого списка, не трогая остальной диск
8.6.3. Если стоп-список пуст, накрываем папки из быстрого списка первыми; остальные файлы потом.

8.7. Программа шифрует только файлы с расширениями из списка рабочих расширений; остальные игнорируются.
8.8. Программа удаляет файлы из особого списка, трижды перезаписывая их содержимое:
- первый раз константой 0
- второй раз константой FF
- третий раз случайным мусором
- на четвертый раз файл удаляется
8.9. Программа обрабатывает таким образом все диски.
Все ошибки при работе игнорируются.

Таким образом, есть следующие списки:

9. Список изменяемых настроек в программе:
9.1. Группа
9.2. Ключ шифрования
9.3. список процессов и сервисов
9.4. быстрый список
9.5. стоп-список
9.6. список рабочих расширений
9.7. список на удаление
9.8. текст лендинг-страницы
9.9. адрес командного сервера
Все эти данные (кроме 9.1, 9.9) программа пытается запросить с командного сервера по сети ТОР, десять попыток, интервал 1 минута.
При неудаче программа использует зашитые в нее значения, периодически возобновляя попытки обновить настройки.

API BACKEND'A

POST /HELLO HTTP/1.1

Запрос выполняется при старте программы (как первоначальном, так и повторном после перезагрузки).
Содержимое тела HTTP-запроса - контейнер application/x-www-form-urlencoded со следующими полями:
cid   - ID клиента
group - группа клиента
ip1   - адрес первого сетевого интерфейса
ip2   - адрес второго сетевого интерфейса
...
ipN   - внешний IP-адрес

Если в ответ на это бот получает ответ код 406 и ответ Not allowed, бот немедленно прекращает работу и удаляется с диска.
В свою очередь, backend должен выдать этот код и ответ, если обнаружит, что любой из предоставленных в запросе IP-адресов
находится в зоне СНГ.

GET /<cid>/<group>/<setting> HTTP/1.1

Запрос настройки. Здесь
<cid>       - ID клиента
<group>     - группа клиента
<setting>   - настройка, енум из
key       (публичный ключ шифрования)
services  (список процессов и сервисов - разделяемый точкой с запятой. Если в поле есть подстрока .exe - это имя процесса. Если нет - это имя сервиса.)
priority  (быстрый список)
stoplist  (стоп-список)
ext       (список расширений)
wipe      (список на удаление)
landing   (лендинг-страница)
Формат списков - разделяемый точкой с запятой.
Лендинг-страница отдается как есть, кодировка UTF8.
Ключ - удобный для работы через WinCrypt формат (если необходимо, обернутый base64).

POST /<cid>/<group>/stat

Отправка статистики
Содержимое тела HTTP-запроса - контейнер application/x-www-form-urlencoded со следующими полями:
total   - всего файлов обработано
crypted - всего файлов зашифровано
wiped   - всего файлов удалено
ignored - всего файлов пропущено

Статистика отправляется каждые 15 минут, время задается константой в программе.


ЛЕНДИНГ-СТРАНИЦА

Всего лендинг-страниц две:
- на компьютере
- в Интернете.

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

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

К лендинг-странице предъявляется жесткое требование по запрету прямого контакта с жертвой, кроме как через наш чат:
- все, что хоть немного похоже на bitcoin-адрес, должно жесточайше отвергаться при загрузке текста страниц в админку,
и удаляться при сохранении текста страницы.
- вместо этого, адрес для выплат должен заменяться макросом. Ну скажем, %PAYMENT_ADDRESS%
- в текст не должны попасть контакты адверта (емайл, jabber и все возможные телефоны, мессенджеры, IRC итд).
При обновлении текста страницы в админке нужно автоматически проверять и отклонять страницы с попытками
прописать на них контакты и кошельки.
Вероятно, можно также сделать некую пред-модерацию, с одобрением изменений на страницах нашими операторами системы.

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

Макросы:
%PAYMENT_ADDRESS% - bitcoin-кошелек для выплаты (берется из профиля цели)
%DOUBLE_DATE% - дата удвоения выплаты
%LANDING_URL% - ссылка для лендинг-файла - базовый URL, к которому бот сам приклеит свой ид, чтобы получить полную ссылку на лендинг-страницу в интернете


Внешний вид страниц примерно следующий (образцы конкурентов):
http://aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd.onion/837F964AF6B77803#info
http://aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd.onion/F32917DB2AA982C9#info

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

Тестовой расшифровкой файла можно воспользоваться только один раз и только для файлов изображений,
т.к. они как правило не несут важной инфы.
При отдаче расшированного результата, нужно проверять содержимое файла по сигнатурам.
Если сигнатура ни одного из разрешенных типов не совпадает, содержимое не отдавать и писать атата.
Разрешенные типы: jpg, png, gif, bmp.

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

ВАЖНО: сумма к выплате на лендинг-странице ВСЕГДА отображается без учета скидки!
ВАЖНО: видимость линка на анлокер ВСЕГДА управляется соотв.флагом из свойств цели (см.ниже - у цели есть отдельный флаг
"анлокер доступен"), А НЕ ФЛАГОМ ОПЛАТЫ!

ВАЖНО: вид лендинг-страниц может управляться командами из чата после ФИКСАЦИИ ФАКТА ОПЛАТЫ на наш bitcoin-адрес
(нужно именно наличие транзакции с нужной суммой на назначенный нами адрес из профиля цели).
Меняться могут две вещи:
- переключение страницы между видом "не оплачено" и "оплачено" и соотв. доступность линка на анлокер
- bitcoin-адрес для выплаты.
Все эти действия делает рекавери, только после того как заплатил нам и мы это зафиксировали.
ДО ОПЛАТЫ эти действия НЕДОСТУПНЫ!


АДМИНКА

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


РАЗДЕЛ АДМИНИСТРАТОРА

Здесь описан список страниц, видимых только админу (название страницы и список свойств или инфы на ней):

* Dashboard со статистикой:
- всего адвертов
- всего ботов
- активных за последние сутки ботов
- всего выплат

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

* Управление учетными записями (профили адвертов)
На этой странице список адвертов (учеток) со следующими столбцами таблицы:
- имя
- комиссия (в процентах)
- (за/раз)блокировать адверта
- редактировать адверта
А также кнопка
- создать нового адверта

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

При создании нового адверта, ему присваивается системой ПРОКСИ bitcoin-адрес, на который идут выплаты от жертв.
Этот адрес самому адверту никак не виден.

В редактировании профиля адверта, можно изменить поля:
- имя
- комиссия
- личный bitcoin-адрес адверта (ЭТО НЕ ТОТ АДРЕС, который назначем цели МЫ!)
Это ВТОРОЙ адрес, который доступен для редактирования и админу, и самому адверту.
Назначение адресов см. в разделе "ВЫПЛАТЫ".
- вывод через миксер
- bitcoin-адрес миксера
- время миксирования
- комиссия миксирования
Данные поля требуют уточнения - зависит от того, какие возможности предоставляет API bitmix.
Возможно, время и комиссия миксирования не управляются с нашей стороны, а назначаются миксером автоматически.

По каждому адверту также должна быть видна расширенная статистика
- всего прибыли
- всего ботов
Эта стата не должна генерироваться при открытии страницы, а должна подгружаться по отдельной кнопке/линку
(так делаем потому, что стата скорей всего делает тяжелые запросы к БД).


РАЗДЕЛ АДВЕРТА

Здесь описан список страниц, видимых адверту.

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

Удалить можно только цель, по которой отстучало 0 ботов.
Цель, по которой были отстуки (т.е. в БД есть инфа о ботах с указанной группой) можно только отправить в архив.
Архив - это отдельный раздел с целями, в которых все то же самое и только на просмотр.

При создании/редактировании цели есть следующие поля:
** общие
- название
- краткое название группы, валидируемое по следующему правилу:
строка из 6 символов, первые три - латиница в нижнем регистре, остальные - цифры.
Группа является уникальным полем, и является идентификатором цели в системе. Поле "название" используется внутри админки
для удобства отображения; поле "группа" используется в разного рода запросах и взаимодействиях частей системы между собой.
- статус: оплатил/не оплатил (выставляется как вручную, так и автоматически скриптами оплаты)
Если была оплата, нужно вывести список платежей из сети bitcoin со ссылками на транзакцию
в любом блокчейн-эксплорере.
Т.е. оператор должен знать, был ли факт оплаты, либо же флаг оплаты поставлен вручную.
- ник для чата (по умолчанию operator)
** платежное
- bitcoin-адрес для выплаты (личный)
- bitcoin-адрес рекавери (необязательно); его назначение - см.раздел ЧАТЫ
- сумма выплаты
- крайний срок выплаты, после чего стартует удвоение (отсюда и далее поля необязательные)
- интервал удвоения выплат, в днях
- доступная скидка (для рекавери-компаний), в процентах (по умолчанию отсутствует, т.е. значение 0)
По умолчанию выключена. См.также в разделе "ЧАТЫ" про отключение этой опции из чата.
** лендинг
- тор-домен (необязательно)
- лендинг-текст на сайте (возможно это сделать доп.опцией, а по умолчанию использовать типовой текст)
- лендинг-текст в файле
- "анлокер доступен" - флаг (чекбокс), доступен ли для скачивания анлокер на лендинг-странице
- флаг "доступна тестовая расшифровка" (сбрасывается при использовании тестовой расшифровки)
** настройки локера
- тип ключа (личный/групповой)
Тут разница видимо только в том, сколько ботов может пользоваться одним ключом.
- приватный и публичный ключи в человеко-понятной форме
ВНИМАНИЕ! СМ.ПРО ВАЛИДАЦИЮ ЛЕНДИНГ-ТЕКСТОВ В СООТВ.РАЗДЕЛЕ!!!
- список останавливаемых сервисов и процессов
- список приоритетных каталогов
- список игнорируемых путей и масок
- список рабочих расширений
- список к удалению
Все списки - это разделяемые символом ; (точка с запятой) валидные маски путей и файлов ОС Windows.
Кроме того, в свойствах цели хранится приватный ключ шифрования, программа-локер и программа-анлокер.
Эти свойства генерируются системой при создании цели и доступны только на просмотр/скачивание.

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

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


* Боты
Это информационная страничка со списком ботов по конкретной выбранной цели, отсортированных по дате последней активности и полями:
- CID
- group
- target
- last activity
- chat
При заходе на страничку бота, кроме этой инфы также должна быть доступна инфа о системе, собранная ботом.


ЧАТЫ

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

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

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

Адверты могут видеть только свои чаты, админы могут видеть всё.

При входе в чат жертве выдается приглашение (наподобие как в IRC-каналах) и
сообщение о том, что можно ввести /help для просмотра доступных команд.

В чате есть следующие команды:
/help
выводит текст о командах private и clear с их описанием.
Команда unpaid из подсказки исключена

/private
Делает чат невидимым для других участников чата со стороны жертвы (т.е. если больше одного человека
сидит в чате со стороны жертвы).
Со стороны админа/адверта ни на что не влияет - история чата видна полная.

/clear
Очистка истории чата со стороны жертвы.
Со стороны админа/адверта ни на что не влияет - история чата видна полная.

/unpaid
Выключает флаг "доступен линк на анлокер".
Эту и последующие команды сообщает в чате адверт, для рекавери-компании, после достижения договоренности по оплате и скидке.
больше нет // -Доступна ТОЛЬКО после получения оплаты на bitcoin-адрес цели.- зачеркнуто
КОМАНДА НЕДОСТУПНА при установке флага "оплачено" вручную из админки!
Команда выключает флаг "доступен анлокер" в профиле цели, соответственно меняет вид лендинга.

/bitcoin <адрес bitcoin>
Меняет на лендинг-странице адрес кошелька для выплаты.
Доступна ТОЛЬКО после получения оплаты на bitcoin-адрес цели.
КОМАНДА НЕДОСТУПНА при установке флага "оплачено" вручную из админки!

/paid
Проставляет флаг "оплачено".
ДОСТУПНА ТОЛЬКО после получения оплаты на bitcoin-адрес цели.
КОМАНДА НЕДОСТУПНА при установке флага "оплачено" вручную из админки!
Команда включает флаг "доступен анлокер" в профиле цели, соответственно меняет вид лендинга.

Команды предназначены исключительно для действий рекавери.
Общий сценарий при этом такой:
- рекавери открывает приватный чат
- рекавери представляется и договаривается о скидке/условиях оплаты
- в ответ оператор с нашей стороны сообщает ему команду для скрытия факта оплаты - /unpaid
- рекавери задействует команду /unpaid для выключения линка на анлокер и /bitcoin ддя смены bitcoin-адреса выплаты на лендинг-странице
Это нужно сделать ДО оплаты!
- после подтверждения факта оплаты, оператор в приватном чате отдает рекавери линк на анлокер
- после получения оплаты с жертвы на свой адрес, рекавери может переключить вид страницы, чтобы дать доступ жертве на анлокер.

КРИПТОВАЛЮТЫ

Мы хотим поддерживать другие криптовалюты, кроме bitcoin'а - еще
* dash
* zcash
* monero
Все, что написано в данном ТЗ касательно bitcoin, должно быть реализовано также и для этих криптовалют.
Например, если в свойствах записи в базе данных требуется указать адрес bitcoin, то нужно указать также и адреса
для остальных валют.


КЛИРИНГ И СКРИПТЫ ОПЛАТЫ

Клиринг - это расчет с адвертами, выплата им того, что причитается.

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

Ручной клиринг:
+ полностью защищен от кражи кошелька персоналом и конкурентами
- требует дополнительной ежедневной работы по рассылке средств
- требует дополнительной ручной работы по обслуживанию системы (генерация адресов)

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

Назначение скриптов оплаты:
1) отслеживание платежей bitcoin на наши адреса
2) клиринг (автоматическая отправка денег на адреса адвертов)
3) генерация пула bitcoin-адресов для назначения целям.

Первый скрипт будет в любом варианте клиринга; второй и третий - только в автоматическом.

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


АВТОМАТИЧЕСКИЙ КЛИРИНГ

Если делать автоматический клиринг, то по всей видимости без поднятия полной ноды bitcoin не обойтись.

На платежном сервере находится кошелек, к которому привязаны генерируемые bitcoin-адреса,
и поднята полная нода bitcoin.

Клиринг может осуществляться как напрямую на кошельки адвертов, так и через миксеры.
В случае работы через миксеры, в общих настройках системы нужно указать:
- опцию "клиринг через миксер"
- bitcoin-адрес миксера
- время миксирования
- комиссию миксирования
ЛИБО
эти же опции могут быть в профиле адверта (доступном для редактирования админу).

Работают три крон-задачи:

1) проверяет входящие платежи на каждый из bitcoin-адресов, назначенных нами целям,
и маркирует цели как оплаченные, если сумма достаточная.

2) для оплаченных целей, автоматически формирует исходящие платежи на адреса адвертов
(входящая сумма минус комиссия).

3) проверяет запас свободных адресов в БД, при необходимости генерирует новые адреса и складывает в БД.

Все это можно делать кучей способов:
- у полной ноды bitcoin есть утилита bitcoin-cli, умеющая все что нужно
- через JSON-RPC (поднять на полной ноде)

РУЧНОЙ КЛИРИНГ

В этом случае можно обойтись без полной ноды bitcoin.

1) Для проверки статуса оплаты по адресу биткоин, можно использовать несколько подходов:
- использовать нативное API Bitcoin RPC, подключаясь к определенному серверу/серверам bitcoin.
Для PHP уже есть решение из коробки:
https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%29#PHP
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
- использовать API блокчейн-эксплореров. Этот вариант хуже, т.к. блокчейн-эксплореры часто меняют
адреса, АПИ и вообще подвержены частым изменениям.
Например:
https://blockchain.info/q

2) платежи адвертам нужно обрабатывать вручную.
Для этого в админке нужен будет отчет "К выплате", в котором должен идти
список адресов с суммами.
Хозяин системы ежедневно качает этот отчет и вручную делает выплаты.

3) Точно так же вручную нужно генерировать новые bitcoin-адреса и загружать их в админку,
на отдельной страничке в настройках системы.

*************************
ВТОРАЯ ВЕРСИЯ
Нужно предусмотреть следующее:
1. нужен новый загрузчик, который будет грузить и запускать нагрузку пачками (несколько .exe сразу)
2. стилер pwgrab нужно адаптировать на сброс данных в хранилище:
- заменить протокол DPOST протоколом передачи файлов.
- адрес командного сервера получать через Emercoin DNS
- отстук с CID бота
- CID бота должен генерироваться единообразно и однозначно, независимо от юзера,
чтобы можно было повторить его генерацию в стилере.

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

3. В админке должен быть раздел для просмотра слитых паролей.
Привязка к адверту; обязательно запоминаем ИД бота/машины.
4. Получение ботом адреса командного сервера через Emercoin DNS.