Фейковый BLOCKCHAIN API

  • Автор темы Admin

Admin

#1
Администратор
Регистрация
31.12.2019
Сообщения
6,871
Реакции
24
В данном опусе мы с вами рассмотрим концепт получения закрытых ключей, открывающих двери в мир дорогого алкоголя, элитных женщин и ранней смерти. Статья сырая, графоманская, теоретическая, с минимум технических подробностей, написанная на коленке.

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

Воплощать в жизнь свои затеи мы будем по следующим шагам:

Выбор легитимного REST API. Мы же хотим, чтобы наш сервис был рабочим, т.е. выполняющим свои функции;
Закладки в библиотеках для отправки приватного ключа;
Написание серверной части по ретрансляции запросов;
Позиционирование и продвижение в массы;
Сбор сливок.



1. Выбор REST API.

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

https://bitcore.io/

https://www.blockchain.com/

https://www.coinbase.com/

https://infura.io/

https://docs.nomics.com/

https://tierion.com

https://www.factom.com/

Для примера можно взять infura.io – api для Ethereum и монеток, написанных на его основе. Простыми регистрациям посредством электронной почты можно получить безграничное количество бесплатных аккаунтов с ограничениями 100к запросов в день. Для более серьёзных ребят есть и платное api – 5 миллионов запросов в день за 1к$ в месяц. Создаем новый проект и получаем ключи для обращений к сервису. Они нам понадобятся далее.



2. Прячем закладки

Самый важный и нетривиальный пункт. Чем извращённей мы запрячем приват кей, тем больше шансов будет на успех всей операции. Для того, чтобы разработчикам были интересны наши библиотеки они должны быть, простыми и понятными в использовании, а также прозрачными с точки зрения безопасности. Список ЯП большой, способы для каждого ЯП надо продумывать. Реальные сервисы в части работы с закрытыми ключами работают следующим образом:

- Транзакция формируется и подписывается локально

- Подписанная транзакция транслируется в сеть

Посмотрим исходники на питоне и документацию на примере web3py:

https://github.com/ethereum/web3.py

https://web3py.readthedocs.io/en/stable/web3.eth.html

Код:
signed_txn = w3.eth.account.sign_transaction(dict(
    nonce=w3.eth.get_transaction_count(public_address_of_senders_account),
    gasPrice=w3.eth.gas_price,
    gas=100000,
    to='0xd3CdA913deB6f67967B99D67aCDFa1712C293601',
    value=12345,
    data=b'',
  ),
  private_key_for_senders_account,
)

Самым простым решением будет спрятать приватный ключ либо в signed_txn либо в объекте w3.eth. Естественно, он должен быть не в открытом виде, так как его быстро спалят через любой анализатор трафика. Его нужно будет:

а) зашифровать;

б) замаскировать под сервисные данные.

Если с пунктом А возникнуть проблем не должно, то пункт Б будет основной головной болью.

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

Ну это же REST-API, скажете вы, можно же отправить ручками post/get запрос и проверить. Мы можем оставить REST-API работающим без закладок, а их добавить только в dll. Можем даже исходники выложить без закладок или с ошибками в сборке. Да, часть пользователей будет использовать наш сервис без закладок, но далеко не все, разработчики – люди ленивые и они скорее возьмут готовую dll, чем будут собирать её из исходников.



3. Серверная часть

Тут все просто.

- Получаем запрос от клиента.

- Делаем запрос к infura или подобным

- Получаем, обрабатываем, отправляем клиенту ответ

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

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



4. Позиционирование и продвижение

Нужно заинтересовать разработчиков. Тут у нас несколько путей:

- бесплатность;

- простота;

- узкая специализация;

- анонимность;

- функционал, отсутствующих у других

Отпустите фантазию на волю. Можно написать cms для .onion магазина, можно написать библиотеку для проектов на RUBY. Написать документацию и примеры. Придумать подписки на события с кошельком, например, на изменение баланса. Фишки сервиса можно подчерпнуть из тем с вопросами на форумах, из комментариев на гитхабе. Проблем и неудобств хватает, выбор удобного или универсального API для платежей – это существующая и вечная проблема. Можно сначала нарастить комьюнити, а затем уже выпустить вторую версию api с закладками. Наращивать сообщество лучше на подконтрольной себе площадке, чтобы оперативно реагировать на реакцию пользователей. Делаем рекламу как белый сервис, конкуренция в данном сегменте минимальная.

5. Чистим нычки

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

Код:
response = requests.post("https://api.etherscan.io/api?module=account&action=balance&address=" + adress_senders + "&tag=latest&apikey=" + settings.etherscan_API).json()                                                               
balanceETH = int(response["result"])
gasPrice = w3.eth.gasPrice
if balanceETH> gas * gasPrice:
    signed_txn = w3.eth.account.signTransaction({
        "nonce": w3.eth.getTransactionCount(adress_senders),
        "gasPrice": gasPrice,
        "gas": gas * gasPrice,
        "to": adress_recipient,
        "value": (balanceETH- gas * gasPrice)
        }, private_key_for_senders_account)                   
    w3.eth.sendRawTransaction(signed_txn.rawTransaction)

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

Резюмируя: объем средств, проходящий ежедневно даже через скромные криптоапи внушительный, поймать в свои сети какие-нибудь крупные хайп проекты вполне реально, технические моменты умеренно сложные. ИМХО, я искренне думаю, что идею реально реализовать умелыми руками.

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

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

Профит.

====



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

И даже годами. Софт будет проверятся, пока все не привыкнут к его надежности. И очередной апдейт -big fail..



Ксттаи.Так кто-то из разрабов/овнеров Leger-a в FAQ отвечал на вопрос о доверии к софту (аппаратные кошельки).

По его словам легальная прибыль компании на растущем рынке намного больше сумм балансов их кошельков.

По сути:


Делаем ханипот
Ждём крупную рыбу
Уходим с профитом.

Риски:

Тратим время на разработку (обфускация и т.п. - время, а значит - деньги)
Продвижение: благо - не 2000-й на дворе, а 2021 - надо или рекламой лить, или поведенческие накручивать... или крауд-маркетингом продвигать
Раз есть привратник: "Самым простым решением будет спрятать приватный ключ либо в signed_txn либо в объекте w3.eth. Естественно, он должен быть не в открытом виде, так как его быстро спалят через любой анализатор трафика", - то есть вариант и того, что кто-то сделает на наш Хоней - свой да ещё с тысячью неизведанных тоней.

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

Автор: poltorashka
 

Members, viewing this thread

Сейчас на форуме нет ни одного пользователя.