---
title: "Отравление адреса"
description: "При отравлении адреса мошенник помещает похожий адрес получателя в историю транзакций или другой интерфейс, которому пользователь склонен доверять, чтобы последующий платеж был скопирован на адрес злоумышленника; подмена эксплуатирует проверку получателя, но не изменяет настоящий адрес и не похищает его ключ."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Отравление адреса
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Отравление адреса — это мошенничество с подменой получателя. Злоумышленник создает другой адрес, видимые начало и конец которого похожи на адрес доверенного получателя, а затем помещает его в историю транзакций или другой интерфейс, выглядящий надежным. Расчет состоит в том, что отправитель позднее скопирует похожий адрес и подпишет действительный платеж на него. Атака не изменяет законный адрес, не взламывает его закрытый ключ и не заставляет консенсус направить перевод не туда.
Подброшенная запись может появиться вследствие настоящей транзакции с нативным активом, соответствующего стандарту перевода токена с нулевой стоимостью или лога, созданного другим токен-контрактом. Страницы активности кошельков и обозревателей блоков — это производные представления: строка с пометкой «отправлено» может строиться из полей события, а не из внешней транзакции, подписанной показанным адресом `from`. Отдельно проверяйте отправителя и назначение внешней транзакции, вызванный контракт, контракт-эмитент события, индексированные поля и фактические изменения балансов.
Контрольная сумма ERC-55 помогает выявить некоторые случайные опечатки, однако другой адрес злоумышленника может быть синтаксически допустимым и иметь правильную контрольную сумму. Обычный 20-байтовый адрес EVM также не указывает сам по себе предполагаемую сеть, актив, роль получателя, примечание к депозиту или вызов контракта. Безопасное платежное поручение связывает все эти параметры с полным адресом назначения.
## Как это работает
Злоумышленник наблюдает публичный шаблон платежей и ищет vanity-адрес, совпадающий по символам, которые кошелек оставляет при сокращенном отображении. Совпадение выбранных шестнадцатеричных символов не клонирует учетную запись: скрытые байты остаются иными, а новым ключом управляет злоумышленник. Небольшой перевод может поместить такой реальный адрес в историю. При этом ERC-20 требует обрабатывать переводы нулевой стоимости как обычные и создавать событие `Transfer`, поэтому запись с нулевой стоимостью сама по себе не доказывает подделку, компрометацию, авторизацию или экономический убыток.
Вредоносный токен-контракт также может создать собственный лог `Transfer(victim, lookalike, 0)`. Это реальные данные квитанции, относящиеся к испустившему их контракту, однако событие исходит не от канонического контракта актива и не доказывает, что жертва подписала внешнюю транзакцию. Тем не менее индексатор, который классифицирует активность по темам событий без достаточного контекста контракта и вызова, может показать обманчивую строку исходящего перевода.
Решающим средством контроля является окончательное платежное намерение. Оно должно связывать сеть, нативный актив или точный токен-контракт, полный адрес и тип получателя, сумму и исходные единицы, а также calldata, примечание, тег назначения или срок действия. Депозитные адреса бирж, мосты, прокси и одноразовые маршруты могут устаревать или требовать больше данных, чем один адрес. Вредоносная подмена буфера обмена и скомпрометированные QR-коды — иные атаки, но та же проверка полного назначения обнаруживает подмену до подписания.
Имена и тестовые платежи — вспомогательные меры, а не доказательства личности. Разрешайте имя ENS для нужной сети и записи непосредственно при подписании; если отображается обратное имя, выполните прямое разрешение обратно в тот же адрес. Малый тест помогает только тогда, когда получатель независимо подтверждает его, а основной платеж повторно использует то же закрепленное назначение. Повторное копирование из истории лишает тест этой защиты.
Используйте следующий порядок:
1. Зафиксируйте сеть, актив и точный токен-контракт, тип получателя, формат адреса, сумму, примечание, тег, calldata, версию или срок действия из аутентифицированного независимого источника.
2. Один раз разрешите имя или QR-код, проверьте формат и контрольную сумму и свяжите все байты назначения с нужной сетью; обратное имя подтвердите прямым разрешением, не считая метку удостоверением личности.
3. Сверьте назначение с контролируемым списком разрешений, адресной книгой или подписанным счетом, но никогда не с историей транзакций; новый или существенно измененный получатель требует независимого либо двойного одобрения.
4. Точно декодируйте неподписанную транзакцию: отличите нативное поле `to` от токен-контракта или моста и проверьте в calldata получателя, токен, исходную сумму, разрешение, крайний срок и семантику назначения.
5. Когда уместно, отправьте небольшой тест на закрепленное назначение и получите независимое подтверждение получателя; для основного платежа не копируйте адрес из истории повторно.
6. Подпишите основной перевод только из проверенной записи, сравните полные назначение и сумму на доверенном дисплее, затем проверьте квитанцию, контракт-эмитент, логи и изменения балансов в правильной сети.
7. При подозрении на отравление или ошибочную отправку остановите последующие платежи, сохраните хеши и доказательства и без промедления свяжитесь с сервисом получателя, эмитентом или правоохранительными органами, когда это уместно; заморозка, возврат и восстановление условны и никогда не гарантированы.
## Примеры
- **Сокращение скрывает различие.** Законный `0x12ab1111111111111111111111111111111189ef` и принадлежащий злоумышленнику `0x12ab9999999999999999999999999999999989ef` отображаются одинаково: `0x12ab...89ef`. У них совпадают `4 + 4 = 8` видимых шестнадцатеричных символов, но различаются все `32` символа в середине. Сравнение только показанных концов дает ложное совпадение, а сравнение всех байтов — нет.
- **Трудоемкость поиска vanity-адреса.** Для совпадения `k = 8` выбранных шестнадцатеричных символов ожидается перебор `16^8 = 4,294,967,296` кандидатов. При предполагаемой скорости `50,000,000 candidates/s` ожидаемое время равно `4,294,967,296 / 50,000,000 = 85.89934592 s`. Это иллюстрация пространства поиска, а не гарантированного времени или порога предупреждения кошелька.
- **Лог и состояние.** Токен-контракт создает событие `Transfer(victim, lookalike, 0)`. Баланс жертвы остается от `250,000.000000` до `250,000.000000`, то есть изменение равно `0.000000`, однако индексатор активности может показать строку перевода. Проверяйте контракт-эмитент и авторизацию вызова: одна строка не доказывает ни движение стоимости, ни подпись жертвы.
- **Тест должен закреплять назначение.** Казначейство намерено отправить `50,000 USDC`, переводит `1 USDC` на проверенный адрес, получает независимое подтверждение и отправляет `49,999 USDC` из той же закрепленной записи: `1 + 49,999 = 50,000 USDC`. Если сотрудник заново скопирует похожий адрес из истории для второй части, тест уже не защищает платеж `49,999 USDC`.
## Риски
- Отправитель копирует похожий адрес из отравленной истории транзакций.
- Сокращенный интерфейс скрывает отличающиеся символы в середине.
- Vanity-префикс или суффикс принимают за идентификатор получателя.
- Перевод ERC-20 с нулевой стоимостью создает обманчивую строку истории.
- Поддельный токен или его лог принимают за активность канонического актива.
- Индексатор неверно классифицирует поля события или исправляет их слишком поздно.
- Спам-токен имитирует названием, символом или значком доверенный актив.
- Вредоносная программа в буфере обмена заменяет проверенный адрес до подписания.
- Локальная или синхронизируемая адресная книга отравлена либо устарела.
- Список разрешений привязывает не ту сеть, актив, роль или версию адреса.
- Пользователь игнорирует предупреждение о неверной или отсутствующей контрольной сумме.
- Правильную контрольную сумму ошибочно считают доказательством личности получателя.
- Разрешение ENS меняется, использует неверный тип монеты или устаревает.
- Обратное имя показывается без прямого подтверждения.
- После тестового платежа адрес заново копируется из недоверенного источника.
- Депозитный адрес биржи, сеть, примечание или тег неверны либо просрочены.
- Назначение моста, прокси или контракта и необходимая calldata истолкованы неверно.
- Подписант проверяет только сокращенный текст даже на аппаратном устройстве.
- Перевод неправильному получателю становится каноническим до вмешательства.
- Жертва полагается на добровольную заморозку эмитентом или попадает в мошенничество с возвратом.
## Распространенные заблуждения
- **Отравление адреса означает взлом кошелька, ключа или блокчейна.** Обычная атака эксплуатирует выбор получателя, а исправные криптография и консенсус исполняют неверное подписанное намерение.
- **Строка с нулевой стоимостью обязательно является поддельной ончейн-транзакцией.** Соответствующие стандарту переводы и реальные логи могут иметь нулевую стоимость; проверяйте их источник и влияние на состояние.
- **Совпадающие концы и контрольная сумма доказывают получателя.** Другой допустимый адрес может совпадать по видимым символам и иметь собственную правильную контрольную сумму.
- **Один успешный тест автоматически защищает следующий перевод.** Защита теряется, если основной платеж не использует повторно закрепленное и подтвержденное назначение.
- **Кошелек, валидатор или эмитент токена всегда может отменить платеж.** Возможности восстановления и сотрудничество зависят от актива, сервиса, юрисдикции, доказательств и времени.
## Связанные темы
- [Фишинговые мошенничества](/ru/crypto/phishing-scam/)
- [Симуляция транзакции](/ru/crypto/transaction-simulation/)
- [Криптовалютный кошелек](/ru/crypto/wallet/)
## Источники
- [Address poisoning scams](https://support.metamask.io/stay-safe/protect-yourself/wallet-and-hardware/address-poisoning-scams/) - MetaMask Help Center (дата обращения: 2026-08-13)
- [Anatomy of an Address Poisoning Scam](https://www.chainalysis.com/blog/address-poisoning-scam/) - Chainalysis (дата обращения: 2026-08-13)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (дата обращения: 2026-08-13)
- [ERC-55: Mixed-case checksum address encoding](https://eips.ethereum.org/EIPS/eip-55) - Ethereum Improvement Proposals (дата обращения: 2026-08-13)
- [Transactions](https://ethereum.org/en/developers/docs/transactions/) - ethereum.org (дата обращения: 2026-08-13)
- [Resolution](https://docs.ens.domains/resolution/) - ENS Documentation (дата обращения: 2026-08-13)
- [Frequently asked questions](https://ethereum.org/en/community/support/faq/) - ethereum.org (дата обращения: 2026-08-13)
- [USDC Terms](https://www.circle.com/legal/usdc-terms) - Circle (дата обращения: 2026-08-13)
Source: https://wiki.fcontext.com/ru/crypto/address-poisoning/index.mdx