Действительно, NAT часто воспринимается как некий "псевдо-файрвол", создающий иллюзию безопасности. Но в эпоху IPv6, настоящая защита сети требует активного управления доступом и грамотной настройки файрвола, а не пассивного спрятаться за Нат.
Печальная реальность уязвимых сетей.. малые офисы и домашние сети часто подключают принтеры напрямую к роутеру с публичным IP, игнорируя базовую сегментацию. Устаревшие роутеры с включенным UPnP автоматически пробрасывают порты вроде 9100 (JetDirect) или 631 (IPP), открывая устройства в интернет «для удобства». Ну IPv6-сетях всё ещё проще каждый девайс получает глобальный адрес по умолчанию, и если файервол не настроен, принтер становится мишенью.
Сервисы вроде Shodan сканируют интернет, находя такие устройства по специфичным ответам например, по заголовкам Xerox или HP. Многие из этих принтеров — жертвы автоматических пробросов портов или ошибок в VLAN. Злоумышленники используют их для ддоса, перехвата документов через PJL-команды или даже внедрения шелл-кода.
Так что это не «аренда IP под принтер», а грубые ошибки конфигурации. Проверьте свой роутер вдруг и ваш принтер уже светится в Shodan как мишень для хакеров))
В статье рассматриваются современные версии винды типо 10/11, где автоматическая установка драйверов через Windows Update стандартный процесс. Даже без прав администратора система может загружать WHQL-подписанные драйверы из репозитория Microsoft. Однако мамины хацкеры эксплуатируют это доверие, подменяя VID/PID устройств (например, через кастомную прошивку), чтобы Windows распознала их как оборудование доверенного вендора. В таких случаях драйверы устанавливаются автоматически, без запроса прав пользователя, что превращает легитимный механизм в угрозу.
Вы затронули нерв индустрии — вопрос ответственности в IoT действительно упирается в системные пробелы. Пример с инсулиновыми помпами, как я понимаю это про Medtronic MiniMed: уязвимость CVE-2019-10966 позволяла через BLE перехватывать данные и дистанционно управлять устройством, это у меня по крайней мере вызывает ужас.
Регуляторы пытаются реагировать — например, FDA выпустило guidelines по кибербезопасности медицинских устройств, обязывая патчиться в 90 дней для критических CVE. Но как это работает на практике? Компания Orvibo попалась на утечке данных более чем двух миллиардов записей из базы данных, включая пароли и информацию об устройствах умного дома, но рынок всё ещё наводнён девайсами вроде замков Lockly с CVE-2021-3609 (обход аутентификации через Bluetooth).
Cyber Resilience Act ЕС пока лишь в черновиках он обяжет патчить CVE уровня 7.0+, но сроки и механизмы неясны. А добровольные инициативы вроде IoXT Alliance (сертификация по 8 параметрам безопасности) —> шаг вперёд. Еще пример китайский гигант Tuya (провайдер IoT-платформ) в 2023 году получил CVE-2023-25917 - RCE через облачный API. Это очевидно вызывает обоснованные опасения, учитывая широкое распространение их недорогих модулей на рынке.. Их модули за $1.5 доминируют на рынке, но Secure Boot там всё ещё экзотика.
И вот вопрос: Если регулятор введёт обязательные пентесты для IoT, а цена устройств вырастет в 2x согласится ли массовый рынок? Или предпочтёт дешёвые гаджеты с бэкдорами, как та же Orvibo?
Ваша точка зрения частично справедлива удалённая печать мемов действительно выглядит как хулиганство уровня script-kiddie. Но именно такие забавные случаи обнажают дыры, которые потом эксплуатируют для атак.
Да, современный IPP удобнее LPD, но его «интересность» — палка о двух концах. Через ipptool можно вытащить не только названия заданий, но и метаданные документов (например, через атрибут job-name). А если принтер корпоративного уровня (вроде Xerox AltaLink) с поддержкой PostScript — тут уже открывается поле для RCE через инъекции в интерпретатор. Та еще задачка, верно?
Но это я о чем, глючные прошивки фича для хакеров: когда речь заходит о неверно сформированных запросах, мы сразу попадаем в зону риска переполнения буфера или коррупции памяти. Взять ту же CVE-2021-3928 в HP LaserJet с CVSS 9.8 — через PJL-команду @PJL SET COPIES=999 можно было не только вызвать краш, но и через артефакты в куче инжектить произвольный код. А PostScript, превращается в скрытый бэкдор: на примере Xerox через PS-документы можно было вытащить логины админа из NVRAM, записать скрипты для персистентности в /var/ или даже подменить прошивку через executive-модуль — и всё это по сети, без физического доступа.
Так что «мелкое хулиганство» с печатью мемов это лишь пристрелка)
Прикольный материал, стоит попробовать PixVerse и Wan,до этого тестил Qwen, и у меня он работал чуть лучше, чем в вашем примере: хоть видео получались короткими, но артефактов было меньше. В любом случае, нейросети для генерации видео — тема хорошая, ваш гайд вдохновил покрутить ещё пару сервисов)
Вот где фишка, в Kotlin нуллабельность реализована на уровне компилятора где явно указываешь, где переменная может быть null, и компилятор тебя жестко ругает, если забудешь это учесть. В Java Optional — это костыль, который ты сам по себе оборачиваешь, а ошибки NPE все равно могут выплыть в проде. Еще коррутины в Kotlin это неплохой game changer для асинхронного кода. Вы пишете код как синхронный, а под капотом всё решается без бесконечных цепочек callback’ов и головной боли с CompletableFuture. И еще хочу сказать про extension-функции и data-классы, которые сокращают бойлерплейт до минимума, в отличие от громоздкого шаблонного кода в Java. Вот это, на мой взгляд, и есть его killer-фича: язык заставляет тебя думать о безопасности и удобстве разработки, а не гоняться за новыми синтаксическими игрушками.
но не всё так однозначно. Расширять старый язык звучит вполне логично, но часто это тупиковый путь. Например, Objective-C тянет за собой runtime-модель с message passing, а Swift это уже совсем другая философия с value semantics и безопасностью на уровне компилятора. Совместимость их тормозила бы на каждом шагу. То же с Kotlin: если бы он был просто “надстройкой” над Java, он бы не смог выйти за рамки JVM. А так он спокойно работает и на Android, и на Native, и на JS.
Насчет “запирания” разработчиков — да, компании хотят контролировать экосистему, но если язык плохой, никто на нём сидеть не будет. Google пушит Go не потому, что им хочется всех привязать, а потому что C++ не тащил их ворклоады без тонны костылей. А вот Dart с Fuchsia — другой кейс, там не сам язык плох, а просто нет killer use case, чтобы он взлетел.
Короче, новый язык это всегда баланс. Если бы всё можно было решить расширением старого, C++ уже давно превратился бы в Rust, а Java в Kotlin. Но так как то не работает.
Где то с версии ядра 4.9 BPF verifier проверяет каждую eBPF-программу на предмет отсутствия бесконечных циклов, выхода за пределы выделенной памяти и других потенциально опасных операций. В результате кол-во аварий в ядре снизилось ~ на 80% по сравнению с версиями до, что уже говорит о повышении стабильности.
Та же Meta использует eBPF в датацентровых сетях для фильтрации пакетов на уровне XDP, снижая нагрузку на CPU на 30% за счет обхода классического сетевого стека. В Kubernetes-кластерах eBPF (например, в Cilium) обеспечивает динамическую фильтрацию трафика без overhead-а iptables, что критично для масштабируемых систем.
Linux — да, монолитное ядро, но eBPF добавляет ему гибкостьпозволяя динамически расширять функциональность без патчинга и перезагрузки, все таки уже не просто “костыль”
Если говорить конкретно, то минимизация рисков в eBPF начинается с жесткого ограничения прав на загрузку и выполнение кода. Например в реальных проектах всегда прописываем seccomp-профили, используем cgroup BPF для ограничения доступа к ресурсам и монтируем bpffs в режиме read-only.
Это позволяет не дать зловредному коду прорваться даже после прохождения верификатора, который, кстати, ловит лишь очевидные косяки. На этапе runtime обязательно применяем bpftool и bpftrace для отслеживания аномалий — это как наш watchdog, который сигналит, если что-то идет не так. Если нужна более конкретика, рекомендую посмотреть quick start-гайды: Security Best Practices for eBPF, Linux Kernel Documentation по eBPF. Надеюсь, такие примеры помогут разобраться, как реально настроить харденинг eBPF в продакшене.
да я слышал про bpfilter от Facebook, он так и остался в подвешенном состоянии — его забросили, потому что впилить eBPF в классическую экосистему фильтрации оказалось не так-то просто. А netfilter (nftables) не переписывают, потому что он уже прочно впаян в сетевой стек Linux и закрывает большинство сценариев.
eBPF это про кастом и высокую гибкость, но не про замену устоявшихся инструментов. Зато его гоняют там, где netfilter уже начинает задыхаться — например, XDP для ультрабыстрой фильтрации или мощный мониторинг без оверхеда..
Cursor снижает нагрузку в сравнении с , но и тут есть свои ограничения. Далеко ходить не нужно, если сортировка выполняется по неуникальному полю, могут возникать дубликаты или пропуски в данных.
Кроме того, курсоры зависят от актуальности данных на момент выполнения — при изменении записей между запросами возможны расхождения. Однако для классической пагинации с произвольным доступом OFFSET всё ещё применяется. Вы сталкивались в вашей практике с ситуациями, когда курсорная пагинация оказалась неудобной?
Если цель стать цифровым призраком, то да, одноразовый звонилка из киоска с оплатой налом – лучший вариант. Но если задача в том, чтобы хотя бы контролировать, когда и что сливает твой смартфон, то железные рубильники явно полезнее, чем просто доверять софту.
Да, любой телефон – это радиомаяк, но одно дело, когда он просто в сети, и совсем другое когда микрофон внезапно активируется без твоего ведома. Так что вопрос не в том, можно ли полностью скрыться, а в том, насколько ты готов минимизировать утечки.
Настоящая аппаратная защита не должна зависеть от софта.
Я предлагаю несколько способов проверки:
Если выключатель работает корректно, система вообще не должна видеть камеру и микрофон например, приложение камеры просто не найдёт устройство ввода.
Также на таких смартфонах часто используется светодиодная индикация: когда цепь размыкается, замыкается другой контур, который зажигает индикатор, подтверждая отключение.
Ну и самый радикальный способ проверки – вскрытие корпуса и тест мультиметром на разрыв цепи)
В любом случае, такой подход куда надёжнее софтверных “режимов приватности”, которые теоретически могут быть взломаны
Да, OpenObserve выглядит любопытно, особенно как универсальный инструмент, который закрывает сразу логи, трейсы и метрики. Плюс RUM — это жирный бонус, далеко не у всех он есть из коробки. Если два года в проде и все устраивает, значит, с перформансом и удобством все действительно ок.
Интересно, как он себя показывает на больших объемах логов и трейсов — стабильно работает без лишней возни?
Действительно, простой переход по QR-коду сам по себе не может "взломать" телефон или перевести деньги — для этого мошенникам требуется активное участие пользователя: ввод данных карты на фишинговом сайте, установка софта или предоставление доступа к данным.
Что касается самокатов, запрос данных карты на этапе регистрации — это распространённая, но не всегда прозрачная практика, скорее это делается для депозита или штрафов, но такие вещи часто воспринимаются как потенциальный риск. Тут нужно обращаться к официальным и проверенным компаниям, тогда все будет ок
Да, тут вся фишка в том, что железо или ОС особо не могут жестко фильтровать такие вещи. Вроде бы iOS/Android уже предупреждают, если QR ведет в никуда, но если домен выглядит норм, то пиши пропало.
Правда, одной осведомленности мало — нужен баланс: юзерам давать базовые механизмы защиты, а разработчикам — больше инструментов для анализа и фильтрации.
Сам по себе переход — это просто открытие ссылки, так что сразу заразиться нельзя. Но если сайт по ту сторону QR подготовлен, то вариантов хватает: фишинг, XSS, drive-by download, подмена Wi-Fi.
Так что сам факт сканирования не страшен, но если дальше начнете что-то скачивать или вводить данные — тут уже можно встрять.
Вернно подмечено! Уязвимости в библиотеках для обработки QR-кодов действительно случаются, как тот же CVE-2023-40889. И хотя сейчас основные атаки завязаны именно на подсовывание ссылок, эксплойт в самом парсере кода — это вполне рабочий сценарий, если удастся запихнуть полезную нагрузку в структуру QR. Хотя пока это редкость, но с ростом количества QR-кодов везде и всюду злоумышленники явно не будут обходить этот вектор стороной.
Действительно, NAT часто воспринимается как некий "псевдо-файрвол", создающий иллюзию безопасности. Но в эпоху IPv6, настоящая защита сети требует активного управления доступом и грамотной настройки файрвола, а не пассивного спрятаться за Нат.
Печальная реальность уязвимых сетей.. малые офисы и домашние сети часто подключают принтеры напрямую к роутеру с публичным IP, игнорируя базовую сегментацию. Устаревшие роутеры с включенным UPnP автоматически пробрасывают порты вроде 9100 (JetDirect) или 631 (IPP), открывая устройства в интернет «для удобства». Ну IPv6-сетях всё ещё проще каждый девайс получает глобальный адрес по умолчанию, и если файервол не настроен, принтер становится мишенью.
Сервисы вроде Shodan сканируют интернет, находя такие устройства по специфичным ответам например, по заголовкам Xerox или HP. Многие из этих принтеров — жертвы автоматических пробросов портов или ошибок в VLAN. Злоумышленники используют их для ддоса, перехвата документов через PJL-команды или даже внедрения шелл-кода.
Так что это не «аренда IP под принтер», а грубые ошибки конфигурации. Проверьте свой роутер вдруг и ваш принтер уже светится в Shodan как мишень для хакеров))
В статье рассматриваются современные версии винды типо 10/11, где автоматическая установка драйверов через Windows Update стандартный процесс. Даже без прав администратора система может загружать WHQL-подписанные драйверы из репозитория Microsoft. Однако мамины хацкеры эксплуатируют это доверие, подменяя VID/PID устройств (например, через кастомную прошивку), чтобы Windows распознала их как оборудование доверенного вендора. В таких случаях драйверы устанавливаются автоматически, без запроса прав пользователя, что превращает легитимный механизм в угрозу.
Вы затронули нерв индустрии — вопрос ответственности в IoT действительно упирается в системные пробелы. Пример с инсулиновыми помпами, как я понимаю это про Medtronic MiniMed: уязвимость CVE-2019-10966 позволяла через BLE перехватывать данные и дистанционно управлять устройством, это у меня по крайней мере вызывает ужас.
Регуляторы пытаются реагировать — например, FDA выпустило guidelines по кибербезопасности медицинских устройств, обязывая патчиться в 90 дней для критических CVE. Но как это работает на практике? Компания Orvibo попалась на утечке данных более чем двух миллиардов записей из базы данных, включая пароли и информацию об устройствах умного дома, но рынок всё ещё наводнён девайсами вроде замков Lockly с CVE-2021-3609 (обход аутентификации через Bluetooth).
Cyber Resilience Act ЕС пока лишь в черновиках он обяжет патчить CVE уровня 7.0+, но сроки и механизмы неясны. А добровольные инициативы вроде IoXT Alliance (сертификация по 8 параметрам безопасности) —> шаг вперёд. Еще пример китайский гигант Tuya (провайдер IoT-платформ) в 2023 году получил CVE-2023-25917 - RCE через облачный API. Это очевидно вызывает обоснованные опасения, учитывая широкое распространение их недорогих модулей на рынке.. Их модули за $1.5 доминируют на рынке, но Secure Boot там всё ещё экзотика.
И вот вопрос: Если регулятор введёт обязательные пентесты для IoT, а цена устройств вырастет в 2x согласится ли массовый рынок? Или предпочтёт дешёвые гаджеты с бэкдорами, как та же Orvibo?
Ваша точка зрения частично справедлива удалённая печать мемов действительно выглядит как хулиганство уровня script-kiddie. Но именно такие забавные случаи обнажают дыры, которые потом эксплуатируют для атак.
Да, современный IPP удобнее LPD, но его «интересность» — палка о двух концах. Через ipptool можно вытащить не только названия заданий, но и метаданные документов (например, через атрибут job-name). А если принтер корпоративного уровня (вроде Xerox AltaLink) с поддержкой PostScript — тут уже открывается поле для RCE через инъекции в интерпретатор. Та еще задачка, верно?
Но это я о чем, глючные прошивки фича для хакеров: когда речь заходит о неверно сформированных запросах, мы сразу попадаем в зону риска переполнения буфера или коррупции памяти. Взять ту же CVE-2021-3928 в HP LaserJet с CVSS 9.8 — через PJL-команду @PJL SET COPIES=999 можно было не только вызвать краш, но и через артефакты в куче инжектить произвольный код. А PostScript, превращается в скрытый бэкдор: на примере Xerox через PS-документы можно было вытащить логины админа из NVRAM, записать скрипты для персистентности в /var/ или даже подменить прошивку через executive-модуль — и всё это по сети, без физического доступа.
Так что «мелкое хулиганство» с печатью мемов это лишь пристрелка)
Прикольный материал, стоит попробовать PixVerse и Wan,до этого тестил Qwen, и у меня он работал чуть лучше, чем в вашем примере: хоть видео получались короткими, но артефактов было меньше. В любом случае, нейросети для генерации видео — тема хорошая, ваш гайд вдохновил покрутить ещё пару сервисов)
Вот где фишка, в Kotlin нуллабельность реализована на уровне компилятора где явно указываешь, где переменная может быть null, и компилятор тебя жестко ругает, если забудешь это учесть. В Java Optional — это костыль, который ты сам по себе оборачиваешь, а ошибки NPE все равно могут выплыть в проде. Еще коррутины в Kotlin это неплохой game changer для асинхронного кода. Вы пишете код как синхронный, а под капотом всё решается без бесконечных цепочек callback’ов и головной боли с CompletableFuture. И еще хочу сказать про extension-функции и data-классы, которые сокращают бойлерплейт до минимума, в отличие от громоздкого шаблонного кода в Java. Вот это, на мой взгляд, и есть его killer-фича: язык заставляет тебя думать о безопасности и удобстве разработки, а не гоняться за новыми синтаксическими игрушками.
но не всё так однозначно. Расширять старый язык звучит вполне логично, но часто это тупиковый путь. Например, Objective-C тянет за собой runtime-модель с message passing, а Swift это уже совсем другая философия с value semantics и безопасностью на уровне компилятора. Совместимость их тормозила бы на каждом шагу. То же с Kotlin: если бы он был просто “надстройкой” над Java, он бы не смог выйти за рамки JVM. А так он спокойно работает и на Android, и на Native, и на JS.
Насчет “запирания” разработчиков — да, компании хотят контролировать экосистему, но если язык плохой, никто на нём сидеть не будет. Google пушит Go не потому, что им хочется всех привязать, а потому что C++ не тащил их ворклоады без тонны костылей. А вот Dart с Fuchsia — другой кейс, там не сам язык плох, а просто нет killer use case, чтобы он взлетел.
Короче, новый язык это всегда баланс. Если бы всё можно было решить расширением старого, C++ уже давно превратился бы в Rust, а Java в Kotlin. Но так как то не работает.
Где то с версии ядра 4.9 BPF verifier проверяет каждую eBPF-программу на предмет отсутствия бесконечных циклов, выхода за пределы выделенной памяти и других потенциально опасных операций. В результате кол-во аварий в ядре снизилось ~ на 80% по сравнению с версиями до, что уже говорит о повышении стабильности.
Та же Meta использует eBPF в датацентровых сетях для фильтрации пакетов на уровне XDP, снижая нагрузку на CPU на 30% за счет обхода классического сетевого стека. В Kubernetes-кластерах eBPF (например, в Cilium) обеспечивает динамическую фильтрацию трафика без overhead-а iptables, что критично для масштабируемых систем.
Linux — да, монолитное ядро, но eBPF добавляет ему гибкостьпозволяя динамически расширять функциональность без патчинга и перезагрузки, все таки уже не просто “костыль”
Если говорить конкретно, то минимизация рисков в eBPF начинается с жесткого ограничения прав на загрузку и выполнение кода. Например в реальных проектах всегда прописываем seccomp-профили, используем cgroup BPF для ограничения доступа к ресурсам и монтируем bpffs в режиме read-only.
Это позволяет не дать зловредному коду прорваться даже после прохождения верификатора, который, кстати, ловит лишь очевидные косяки. На этапе runtime обязательно применяем bpftool и bpftrace для отслеживания аномалий — это как наш watchdog, который сигналит, если что-то идет не так. Если нужна более конкретика, рекомендую посмотреть quick start-гайды: Security Best Practices for eBPF, Linux Kernel Documentation по eBPF. Надеюсь, такие примеры помогут разобраться, как реально настроить харденинг eBPF в продакшене.
да я слышал про bpfilter от Facebook, он так и остался в подвешенном состоянии — его забросили, потому что впилить eBPF в классическую экосистему фильтрации оказалось не так-то просто. А netfilter (nftables) не переписывают, потому что он уже прочно впаян в сетевой стек Linux и закрывает большинство сценариев.
eBPF это про кастом и высокую гибкость, но не про замену устоявшихся инструментов. Зато его гоняют там, где netfilter уже начинает задыхаться — например, XDP для ультрабыстрой фильтрации или мощный мониторинг без оверхеда..
Cursor снижает нагрузку в сравнении с , но и тут есть свои ограничения. Далеко ходить не нужно, если сортировка выполняется по неуникальному полю, могут возникать дубликаты или пропуски в данных.
Кроме того, курсоры зависят от актуальности данных на момент выполнения — при изменении записей между запросами возможны расхождения. Однако для классической пагинации с произвольным доступом OFFSET всё ещё применяется. Вы сталкивались в вашей практике с ситуациями, когда курсорная пагинация оказалась неудобной?
Тогда нужен железный килл-свитч, глушилка или вообще Faraday bag, если цель — полный оффлайн
Если цель стать цифровым призраком, то да, одноразовый звонилка из киоска с оплатой налом – лучший вариант. Но если задача в том, чтобы хотя бы контролировать, когда и что сливает твой смартфон, то железные рубильники явно полезнее, чем просто доверять софту.
Да, любой телефон – это радиомаяк, но одно дело, когда он просто в сети, и совсем другое когда микрофон внезапно активируется без твоего ведома. Так что вопрос не в том, можно ли полностью скрыться, а в том, насколько ты готов минимизировать утечки.
Настоящая аппаратная защита не должна зависеть от софта.
Я предлагаю несколько способов проверки:
Если выключатель работает корректно, система вообще не должна видеть камеру и микрофон например, приложение камеры просто не найдёт устройство ввода.
Также на таких смартфонах часто используется светодиодная индикация: когда цепь размыкается, замыкается другой контур, который зажигает индикатор, подтверждая отключение.
Ну и самый радикальный способ проверки – вскрытие корпуса и тест мультиметром на разрыв цепи)
В любом случае, такой подход куда надёжнее софтверных “режимов приватности”, которые теоретически могут быть взломаны
Да, OpenObserve выглядит любопытно, особенно как универсальный инструмент, который закрывает сразу логи, трейсы и метрики. Плюс RUM — это жирный бонус, далеко не у всех он есть из коробки. Если два года в проде и все устраивает, значит, с перформансом и удобством все действительно ок.
Интересно, как он себя показывает на больших объемах логов и трейсов — стабильно работает без лишней возни?
Действительно, простой переход по QR-коду сам по себе не может "взломать" телефон или перевести деньги — для этого мошенникам требуется активное участие пользователя: ввод данных карты на фишинговом сайте, установка софта или предоставление доступа к данным.
Что касается самокатов, запрос данных карты на этапе регистрации — это распространённая, но не всегда прозрачная практика, скорее это делается для депозита или штрафов, но такие вещи часто воспринимаются как потенциальный риск. Тут нужно обращаться к официальным и проверенным компаниям, тогда все будет ок
Да, тут вся фишка в том, что железо или ОС особо не могут жестко фильтровать такие вещи. Вроде бы iOS/Android уже предупреждают, если QR ведет в никуда, но если домен выглядит норм, то пиши пропало.
Правда, одной осведомленности мало — нужен баланс: юзерам давать базовые механизмы защиты, а разработчикам — больше инструментов для анализа и фильтрации.
Сам по себе переход — это просто открытие ссылки, так что сразу заразиться нельзя. Но если сайт по ту сторону QR подготовлен, то вариантов хватает: фишинг, XSS, drive-by download, подмена Wi-Fi.
Так что сам факт сканирования не страшен, но если дальше начнете что-то скачивать или вводить данные — тут уже можно встрять.
Вернно подмечено! Уязвимости в библиотеках для обработки QR-кодов действительно случаются, как тот же CVE-2023-40889. И хотя сейчас основные атаки завязаны именно на подсовывание ссылок, эксплойт в самом парсере кода — это вполне рабочий сценарий, если удастся запихнуть полезную нагрузку в структуру QR.
Хотя пока это редкость, но с ростом количества QR-кодов везде и всюду злоумышленники явно не будут обходить этот вектор стороной.