Фейковый BLOCKCHAIN API

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

Суть идеи заключается в создании сервиса-прослойки между ленивым разработчиком и реальным криптовалютным 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. Или вообще разбиваем и прячем в разных местах. Любой код, написанный в паблик статье сразу потеряет свою ценность, поэтому даже не буду запариваться с примерами.

Читайте также:  Cvv forum

Ну это же 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)

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

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