Поддельное приложение криптокошелька в 2026 году: как проверить и что делать

Поддельное приложение криптокошелька опасно тем, что просит сделать именно то, чего пользователь ждёт от настоящего wallet: создать адрес, импортировать recovery phrase, показать баланс или подтвердить транзакцию. Поэтому клон может выглядеть убедительно даже без сложного вредоносного кода.

Главный риск — передача seed-фразы или private key программе, которую контролирует злоумышленник. После этого удаление приложения не возвращает секретность. Отдельная группа рисков связана с системными permissions, удалённым доступом и вмешательством в устройство.

Практический подход строится вокруг цепочки доверия: официальный домен → официальный store или vendor release → проверяемый publisher → штатная установка → понятные permissions → тест до крупного импорта. Если один этап нельзя подтвердить, корневой секрет туда не вводят.

Что такое fake wallet app и как оно крадёт криптовалюту

Типы атак

Клон настоящего кошелька

Клон настоящего кошелька. Копирует название, иконку, create/import и показывает публичные балансы. Для self-custody пользователя принципиально, что подлинность определяется источником приложения и контролем ключей, а не внешним видом. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

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

Для сценария «Клон настоящего кошелька» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Кража seed через Import wallet

Кража seed через Import wallet. Получает recovery phrase в привычном для пользователя сценарии восстановления. Важно отдельно подтвердить, что после раскрытия seed удаление программы и смена PIN не возвращают секретность. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

Перед значимой суммой действует правило минимального доверия: после раскрытия seed удаление программы и смена PIN не возвращают секретность. После каждого шага фиксируется, что изменилось — приложение на устройстве, доступ к секрету или состояние блокчейна. Такое разделение делает расследование воспроизводимым и уменьшает риск второй ошибки.

Для сценария «Кража seed через Import wallet» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Опасность фальшивого Create wallet

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

Операционный стандарт для этого сценария: новый адрес из недоверенной программы нельзя использовать для значимого капитала. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Опасность фальшивого Create wallet» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Фишинговый wallet без сложного malware

Фишинговый wallet без сложного malware. Может украсть seed обычной формой ввода без sms и accessibility. Для self-custody пользователя принципиально, что отсутствие необычных permissions не доказывает безопасность. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

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

Для сценария «Фишинговый wallet без сложного malware» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Wallet как вредоносное ПО

Wallet как вредоносное ПО. Может стремиться к clipboard, уведомлениям, экрану и remote access. Важно отдельно подтвердить, что после чувствительных прав проверяется вся среда устройства. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

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

Для сценария «Wallet как вредоносное ПО» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Fake app и phishing website

Fake app и phishing website. Приложение устанавливается в систему и может сохранять разрешения и обновления. Максимальный возможный ущерб определяется тем, что после установки проверяют не только web-сессию, но и устройство. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: после установки проверяют не только web-сессию, но и устройство. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Fake app и phishing website» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Fake wallet и watch-only

Fake wallet и watch-only. Способен показывать реальный публичный баланс без private key. Для self-custody пользователя принципиально, что видимый баланс не доказывает владение и не оправдывает activation fee. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

Практический контроль строится от независимого источника: видимый баланс не доказывает владение и не оправдывает activation fee. Если поведение клиента невозможно подтвердить официальной документацией, операцию прекращают и проверяют приложение на другом доверенном устройстве. Удобство, срочность и знакомый дизайн не компенсируют неопределённость происхождения.

Для сценария «Fake wallet и watch-only» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Дополнительный разбор: Fake wallet и watch-only.

Как поддельное приложение попадает на устройство

Каналы

Поисковая реклама

Поисковая реклама. Ведёт на клон сайта, чужую карточку или apk. Важно отдельно подтвердить, что реклама не подтверждает принадлежность бренду; начинать лучше с официального домена. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

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

Для сценария «Поисковая реклама» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Фальшивая поддержка

Фальшивая поддержка. Присылает recovery tool или специальную версию wallet в личном сообщении. Максимальный возможный ущерб определяется тем, что проверка TxID не требует установки клиента от незнакомца. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: проверка TxID не требует установки клиента от незнакомца. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Фальшивая поддержка» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

APK под видом обхода ограничений

APK под видом обхода ограничений. Объясняет sideload региональной недоступностью или старой версией магазина. Для self-custody пользователя принципиально, что APK допустим только если vendor сам публикует его на официальном домене. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

Практический контроль строится от независимого источника: APK допустим только если vendor сам публикует его на официальном домене. Если поведение клиента невозможно подтвердить официальной документацией, операцию прекращают и проверяют приложение на другом доверенном устройстве. Удобство, срочность и знакомый дизайн не компенсируют неопределённость происхождения.

Для сценария «APK под видом обхода ограничений» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Срочное security update

Срочное security update. Угрожает блокировкой средств без немедленной установки. Важно отдельно подтвердить, что версию проверяют в официальном магазине или release page. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

Перед значимой суммой действует правило минимального доверия: версию проверяют в официальном магазине или release page. После каждого шага фиксируется, что изменилось — приложение на устройстве, доступ к секрету или состояние блокчейна. Такое разделение делает расследование воспроизводимым и уменьшает риск второй ошибки.

Для сценария «Срочное security update» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Клон в привычном магазине

Клон в привычном магазине. Использует доверие к app store или google play. Максимальный возможный ущерб определяется тем, что нужно сверять publisher и ссылку с official download page. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: нужно сверять publisher и ссылку с official download page. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Клон в привычном магазине» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Beta и ранний доступ

Beta и ранний доступ. Объясняет необычные экраны тестовой версией. Для self-custody пользователя принципиально, что официальная beta подтверждается самим разработчиком и не должна первой получать основной seed. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

Практический контроль строится от независимого источника: официальная beta подтверждается самим разработчиком и не должна первой получать основной seed. Если поведение клиента невозможно подтвердить официальной документацией, операцию прекращают и проверяют приложение на другом доверенном устройстве. Удобство, срочность и знакомый дизайн не компенсируют неопределённость происхождения.

Для сценария «Beta и ранний доступ» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Desktop installer

Desktop installer. Распространяет .exe/.dmg/package и просит повышенные права. Важно отдельно подтвердить, что не отключают Gatekeeper, SmartScreen или антивирус ради неизвестного файла. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

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

Для сценария «Desktop installer» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Как проверить криптокошелёк до установки

До установки

Официальный домен

Официальный домен. Является началом цепочки доверия. Максимальный возможный ущерб определяется тем, что проверяются полное доменное имя и download page; HTTPS само по себе не доказывает бренд. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: проверяются полное доменное имя и download page; HTTPS само по себе не доказывает бренд. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Официальный домен» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Publisher приложения

Publisher приложения. Должен согласовываться с данными официального проекта. Для self-custody пользователя принципиально, что лучший сигнал — официальный сайт ведёт именно на эту карточку. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

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

Для сценария «Publisher приложения» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Отзывы и оценки

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

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

Для сценария «Отзывы и оценки» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

История версий

История версий. Помогает заметить свежий клон многолетнего продукта. Максимальный возможный ущерб определяется тем, что версию сопоставляют с release notes vendor. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: версию сопоставляют с release notes vendor. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «История версий» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Package или bundle ID

Package или bundle ID. Может технически отличать клон от оригинала. Для self-custody пользователя принципиально, что identifier берут только из официальной документации или store card. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

Практический контроль строится от независимого источника: identifier берут только из официальной документации или store card. Если поведение клиента невозможно подтвердить официальной документацией, операцию прекращают и проверяют приложение на другом доверенном устройстве. Удобство, срочность и знакомый дизайн не компенсируют неопределённость происхождения.

Для сценария «Package или bundle ID» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Цифровая подпись

Цифровая подпись. Связывает обновления с ключом разработчика и сильнее имени файла. Важно отдельно подтвердить, что не следует ломать штатную цепочку official site → store/vendor → installer. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

Перед значимой суммой действует правило минимального доверия: не следует ломать штатную цепочку official site → store/vendor → installer. После каждого шага фиксируется, что изменилось — приложение на устройстве, доступ к секрету или состояние блокчейна. Такое разделение делает расследование воспроизводимым и уменьшает риск второй ошибки.

Для сценария «Цифровая подпись» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Официальный APK

Официальный APK. Может быть нормальным способом установки у отдельных wallet-проектов. Максимальный возможный ущерб определяется тем, что решающим остаётся подтверждённый vendor source, а не зеркало или чат. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: решающим остаётся подтверждённый vendor source, а не зеркало или чат. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Официальный APK» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Разрешения Android и iOS

Permissions

Соответствие permission функции

Соответствие permission функции. Камера для qr и биометрия могут быть логичными, а сильные права требуют объяснения. Для self-custody пользователя принципиально, что непонятный доступ проверяется по документации. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

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

Для сценария «Соответствие permission функции» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Accessibility на Android

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

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

Для сценария «Accessibility на Android» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Доступ к уведомлениям

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

Операционный стандарт для этого сценария: после выдачи такого права проверяются почта и биржи. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Доступ к уведомлениям» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Screen recording и демонстрация

Screen recording и демонстрация. Способны раскрыть seed, адреса и подтверждения. Для self-custody пользователя принципиально, что recovery phrase никогда не показывают во время remote session. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

Практический контроль строится от независимого источника: recovery phrase никогда не показывают во время remote session. Если поведение клиента невозможно подтвердить официальной документацией, операцию прекращают и проверяют приложение на другом доверенном устройстве. Удобство, срочность и знакомый дизайн не компенсируют неопределённость происхождения.

Для сценария «Screen recording и демонстрация» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Clipboard

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

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

Для сценария «Clipboard» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Privacy controls iOS

Privacy controls iOS. Позволяют пересмотреть разрешения и сетевую активность приложений. Максимальный возможный ущерб определяется тем, что это помогает оценить дополнительный ущерб, но не отменяет факт введённой seed. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: это помогает оценить дополнительный ущерб, но не отменяет факт введённой seed. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Privacy controls iOS» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Google Play Protect

Google Play Protect. Сканирует, предупреждает, блокирует или удаляет потенциально вредоносные приложения. Для self-custody пользователя принципиально, что его не отключают по инструкции продавца APK. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

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

Для сценария «Google Play Protect» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Seed-фраза и импорт

Seed

Когда ввод seed допустим

Когда ввод seed допустим. Реальное восстановление действительно может требовать recovery phrase. Важно отдельно подтвердить, что фразу вводят только в проверенный совместимый клиент, когда recovery инициировал владелец. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

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

Для сценария «Когда ввод seed допустим» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Неожиданный повторный запрос seed

Неожиданный повторный запрос seed. Может быть признаком клона, overlay или другой установки. Максимальный возможный ущерб определяется тем, что сначала проверяются source, version и официальный статус продукта. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: сначала проверяются source, version и официальный статус продукта. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Неожиданный повторный запрос seed» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Фото seed ради импорта

Фото seed ради импорта. Создаёт цифровую копию секрета и дополнительный канал утечки. Для self-custody пользователя принципиально, что для классической seed минимизируют цифровые копии. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

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

Для сценария «Фото seed ради импорта» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Seed для поддержки

Seed для поддержки. Не нужна для чтения истории blockchain и проверки txid. Важно отдельно подтвердить, что support получает публичные данные, а не корневой секрет. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

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

Для сценария «Seed для поддержки» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Hardware seed

Hardware seed. Не вводится в обычный мобильный клиент ради быстрого подключения. Максимальный возможный ущерб определяется тем, что используется официальный pairing/connect flow производителя. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: используется официальный pairing/connect flow производителя. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Hardware seed» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Другой адрес после восстановления

Другой адрес после восстановления. Может означать другую seed, passphrase, derivation или тип wallet. Для self-custody пользователя принципиально, что до перевода капитала сопоставляются ожидаемые публичные адреса. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

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

Для сценария «Другой адрес после восстановления» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Seed уже введена в сомнительный клиент

Seed уже введена в сомнительный клиент. Является достаточным основанием считать root скомпрометированным. Важно отдельно подтвердить, что создаётся новый независимый wallet на доверенном устройстве. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

Перед значимой суммой действует правило минимального доверия: создаётся новый независимый wallet на доверенном устройстве. После каждого шага фиксируется, что изменилось — приложение на устройстве, доступ к секрету или состояние блокчейна. Такое разделение делает расследование воспроизводимым и уменьшает риск второй ошибки.

Для сценария «Seed уже введена в сомнительный клиент» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Дополнительный разбор: Seed уже введена в сомнительный клиент.

Фальшивое обновление и миграция

APK

Update из доверенного канала

Update из доверенного канала. Должен приходить через store или официальный механизм разработчика. Максимальный возможный ущерб определяется тем, что ссылка в мессенджере не получает доверие автоматически. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: ссылка в мессенджере не получает доверие автоматически. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Update из доверенного канала» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Forced migration

Forced migration. Объявляет старый адрес или сеть устаревшими и просит seed или перевод. Для self-custody пользователя принципиально, что настоящая миграция публично описывается самим проектом. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

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

Для сценария «Forced migration» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Удалить старое и поставить новое

Удалить старое и поставить новое. Часто требуется мошеннику, потому что чужая подпись пакета не заменяет официальный app штатно. Важно отдельно подтвердить, что это серьёзный red flag. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

Перед значимой суммой действует правило минимального доверия: это серьёзный red flag. После каждого шага фиксируется, что изменилось — приложение на устройстве, доступ к секрету или состояние блокчейна. Такое разделение делает расследование воспроизводимым и уменьшает риск второй ошибки.

Для сценария «Удалить старое и поставить новое» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Обход системных warning

Обход системных warning. Заранее учит включить unknown sources и игнорировать security alert. Максимальный возможный ущерб определяется тем, что несколько последовательных обходов — причина прекратить установку. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: несколько последовательных обходов — причина прекратить установку. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Обход системных warning» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Новый домен загрузки

Новый домен загрузки. Не наследует доверие бренда автоматически. Для self-custody пользователя принципиально, что текущую download page открывают вручную с официального сайта. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

Практический контроль строится от независимого источника: текущую download page открывают вручную с официального сайта. Если поведение клиента невозможно подтвердить официальной документацией, операцию прекращают и проверяют приложение на другом доверенном устройстве. Удобство, срочность и знакомый дизайн не компенсируют неопределённость происхождения.

Для сценария «Новый домен загрузки» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Beta-функция

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

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

Для сценария «Beta-функция» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Граница с fake browser extension

Граница с fake browser extension. Имеет отдельные browser permissions и dapp-поверхность. Максимальный возможный ущерб определяется тем, что для extension нужен отдельный checklist publisher/store/permissions. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: для extension нужен отдельный checklist publisher/store/permissions. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Граница с fake browser extension» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Что делать, если приложение уже установлено

После установки

Не вводили секрет и не подписывали

Не вводили секрет и не подписывали. Снижает риск прямого захвата wallet, но не исключает сбор других данных. Для self-custody пользователя принципиально, что фиксируются source/version/permissions, затем app удаляется и устройство проверяется. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

Практический контроль строится от независимого источника: фиксируются source/version/permissions, затем app удаляется и устройство проверяется. Если поведение клиента невозможно подтвердить официальной документацией, операцию прекращают и проверяют приложение на другом доверенном устройстве. Удобство, срочность и знакомый дизайн не компенсируют неопределённость происхождения.

Для сценария «Не вводили секрет и не подписывали» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Seed введена

Seed введена. Означает компрометацию wallet root. Важно отдельно подтвердить, что создаётся новая recovery phrase и переносится портфель с учётом сетей и комиссий. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

Перед значимой суммой действует правило минимального доверия: создаётся новая recovery phrase и переносится портфель с учётом сетей и комиссий. После каждого шага фиксируется, что изменилось — приложение на устройстве, доступ к секрету или состояние блокчейна. Такое разделение делает расследование воспроизводимым и уменьшает риск второй ошибки.

Для сценария «Seed введена» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Дополнительный разбор: Seed введена.

Раскрыт private key

Раскрыт private key. Может ограничивать риск конкретным account, но тот же evm-key используется в нескольких сетях. Максимальный возможный ущерб определяется тем, что инвентаризируется этот публичный адрес во всех релевантных chain. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: инвентаризируется этот публичный адрес во всех релевантных chain. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Раскрыт private key» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Подписана транзакция

Подписана транзакция. Создаёт on-chain эффект, который удаление приложения не отменяет. Для self-custody пользователя принципиально, что по hash определяется transfer, approve, permit или другой вызов. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

Практический контроль строится от независимого источника: по hash определяется transfer, approve, permit или другой вызов. Если поведение клиента невозможно подтвердить официальной документацией, операцию прекращают и проверяют приложение на другом доверенном устройстве. Удобство, срочность и знакомый дизайн не компенсируют неопределённость происхождения.

Для сценария «Подписана транзакция» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Дополнительный разбор: Подписана транзакция.

Выданы сильные права

Выданы сильные права. Могут затронуть email, биржи, banking apps и password manager. Важно отдельно подтвердить, что с чистого устройства меняются критические пароли и завершаются сессии. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

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

Для сценария «Выданы сильные права» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Удаление приложения

Удаление приложения. Обязательно, но не отменяет stolen seed, approvals и изменённые системные настройки. Максимальный возможный ущерб определяется тем, что дополнительно проверяются permissions, profiles, VPN и device admin. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: дополнительно проверяются permissions, profiles, VPN и device admin. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Удаление приложения» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Вторая программа для очистки

Вторая программа для очистки. Может быть продолжением атаки под видом antivirus или recovery tool. Для self-custody пользователя принципиально, что используются только штатные и проверенные security-средства. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

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

Для сценария «Вторая программа для очистки» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

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

Если деньги уже списались

После списания

Key theft или approval

Key theft или approval. Неизвестная операция может быть прямой подписью украденного ключа или использованием старого allowance. Важно отдельно подтвердить, что проверяются method, spender, approvals и факт утечки root secret. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

Перед значимой суммой действует правило минимального доверия: проверяются method, spender, approvals и факт утечки root secret. После каждого шага фиксируется, что изменилось — приложение на устройстве, доступ к секрету или состояние блокчейна. Такое разделение делает расследование воспроизводимым и уменьшает риск второй ошибки.

Для сценария «Key theft или approval» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Дополнительный разбор: Key theft или approval.

TxID как первое доказательство

TxID как первое доказательство. Даёт проверяемые chain, sender, recipient, token и status. Максимальный возможный ущерб определяется тем, что скрин баланса не заменяет hash. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: скрин баланса не заменяет hash. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «TxID как первое доказательство» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Дополнительный разбор: TxID как первое доказательство.

Другие сети под той же seed

Другие сети под той же seed. Могут содержать активы, которые атакующий ещё не забрал. Для self-custody пользователя принципиально, что инвентаризация охватывает все derived accounts и сети. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

Практический контроль строится от независимого источника: инвентаризация охватывает все derived accounts и сети. Если поведение клиента невозможно подтвердить официальной документацией, операцию прекращают и проверяют приложение на другом доверенном устройстве. Удобство, срочность и знакомый дизайн не компенсируют неопределённость происхождения.

Для сценария «Другие сети под той же seed» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Не пополнять скомпрометированный адрес вслепую

Не пополнять скомпрометированный адрес вслепую. Gas-пополнение может быть перехвачено автоматическим drainer. Важно отдельно подтвердить, что сложный rescue планируют для конкретной сети. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

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

Для сценария «Не пополнять скомпрометированный адрес вслепую» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Официальная биржа

Официальная биржа. Может быть реальной точкой обращения, если активы попали на cex. Максимальный возможный ущерб определяется тем, что support открывают самостоятельно и сохраняют case number. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: support открывают самостоятельно и сохраняют case number. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Официальная биржа» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Recovery scam после первой кражи

Recovery scam после первой кражи. Предлагает 100% возврата за tax, aml, gas или insurance. Для self-custody пользователя принципиально, что новую seed не передают, а tracing выполняется по публичным данным. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

Практический контроль строится от независимого источника: новую seed не передают, а tracing выполняется по публичным данным. Если поведение клиента невозможно подтвердить официальной документацией, операцию прекращают и проверяют приложение на другом доверенном устройстве. Удобство, срочность и знакомый дизайн не компенсируют неопределённость происхождения.

Для сценария «Recovery scam после первой кражи» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Две временные линии

Две временные линии. Связывают события на устройстве и on-chain транзакции. Важно отдельно подтвердить, что фиксируются install time, ввод seed, permissions и hashes. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

Перед значимой суммой действует правило минимального доверия: фиксируются install time, ввод seed, permissions и hashes. После каждого шага фиксируется, что изменилось — приложение на устройстве, доступ к секрету или состояние блокчейна. Такое разделение делает расследование воспроизводимым и уменьшает риск второй ошибки.

Для сценария «Две временные линии» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Какие доказательства сохранить

Evidence

Карточка приложения

Карточка приложения. Store url, publisher, website, version и дата помогают идентифицировать клон. Максимальный возможный ущерб определяется тем, что APK сохраняют как доказательство без повторного запуска. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: APK сохраняют как доказательство без повторного запуска. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Карточка приложения» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Permissions и warnings

Permissions и warnings. Показывают, какие дополнительные возможности мог получить app. Для self-custody пользователя принципиально, что после фиксации опасные доступы отзываются. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

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

Для сценария «Permissions и warnings» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Blockchain evidence

Blockchain evidence. Txid, addresses, token contracts и networks хранят отдельно от app evidence. Важно отдельно подтвердить, что две группы связываются хронологией. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

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

Для сценария «Blockchain evidence» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Жалоба в магазин

Жалоба в магазин. Помогает takedown и защите других пользователей. Максимальный возможный ущерб определяется тем, что в репорт не включают recovery phrase или private key. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: в репорт не включают recovery phrase или private key. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Жалоба в магазин» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Security-команда бренда

Security-команда бренда. Может подтвердить неофициальный app и инициировать удаление клона. Для self-custody пользователя принципиально, что контакт берут только с официального сайта. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

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

Для сценария «Security-команда бренда» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Размер финансового ущерба

Размер финансового ущерба. Фиксируется по каждой операции в native asset и chain. Важно отдельно подтвердить, что фиатную оценку хранят отдельным расчётом на дату. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

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

Для сценария «Размер финансового ущерба» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Дополнительный разбор: Размер финансового ущерба.

Безопасный evidence pack

Безопасный evidence pack. Включает публичные идентификаторы и не раскрывает новые секреты. Максимальный возможный ущерб определяется тем, что скриншоты проверяют на backup QR и персональные данные. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: скриншоты проверяют на backup QR и персональные данные. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Безопасный evidence pack» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Стандарт безопасной установки нового wallet

Платформы

Зачем нужен этот wallet

Зачем нужен этот wallet. Приложение устанавливают ради конкретной функции, а не по требованию случайного dapp или человека. Для self-custody пользователя принципиально, что неизвестный клиент тестируют без основного капитала. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

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

Для сценария «Зачем нужен этот wallet» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Официальный маршрут

Официальный маршрут. Домен открывают вручную и переходят к store/apk из download. Важно отдельно подтвердить, что publisher сверяется с vendor. Это позволяет отличить проблему самого приложения от ошибки сети, токена, адреса или выбранного аккаунта и не применять к разным инцидентам один и тот же recovery-сценарий.

Перед значимой суммой действует правило минимального доверия: publisher сверяется с vendor. После каждого шага фиксируется, что изменилось — приложение на устройстве, доступ к секрету или состояние блокчейна. Такое разделение делает расследование воспроизводимым и уменьшает риск второй ошибки.

Для сценария «Официальный маршрут» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Без отключения защиты

Без отключения защиты. Play protect, app store review, code signing и gatekeeper являются полезными слоями. Максимальный возможный ущерб определяется тем, что их не обходят без сильной проверяемой причины. Поэтому сильный контроль — не впечатление от интерфейса, а доказуемая цепочка от официального vendor к конкретной установленной сборке и понимание того, какие секреты она получила.

Операционный стандарт для этого сценария: их не обходят без сильной проверяемой причины. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Без отключения защиты» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Тестовый wallet

Тестовый wallet. Отдельный адрес позволяет проверить permissions, backup, сети и транзакции. Для self-custody пользователя принципиально, что это ограничивает возможный ущерб. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

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

Для сценария «Тестовый wallet» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Импорт существующей seed

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

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

Для сценария «Импорт существующей seed» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Проверка backup после установки

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

Операционный стандарт для этого сценария: малый тест важнее уверенности на словах. При сомнении не нужно экспериментировать основным кошельком. Отдельный тестовый адрес, независимая проверка источника и on-chain подтверждение дают больше информации, чем повторный ввод seed или попытка «починить» клиент методом проб.

Для сценария «Проверка backup после установки» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Аудит после обновлений

Аудит после обновлений. Новые функции и permissions требуют повторной оценки поведения. Для self-custody пользователя принципиально, что внезапный запрос seed не принимается по инерции. Ошибка на этом этапе может затронуть не один экран, а сам контроль над ключами, поэтому решение принимают до передачи recovery phrase, private key или подписи.

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

Для сценария «Аудит после обновлений» полезно заранее определить максимальный возможный ущерб и независимый способ проверки. Если секрет не раскрыт, не нужно без доказательств объявлять весь кошелёк скомпрометированным; если seed или private key уже переданы, локальные настройки приложения не устраняют криптографический риск.

Перед импортом

Stop-list

Вывод

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

Если сомнительный клиент уже получил seed или private key, соответствующий ключевой материал считают скомпрометированным. Если была только подпись, сначала определяется её on-chain эффект. Если выдавались сильные системные права, проверяется вся среда устройства.

Доказательства разделяют на источник приложения и blockchain-события: store URL, publisher, package/version, permissions и предупреждения отдельно; chain, TxID, addresses и token отдельно. Такая структура помогает выбрать правильный recovery-маршрут и не потерять деньги второй раз.