Хождение по граблям в чистом поле или как собрать MAC-адреса близлежащих Wi-Fi-устройств

    Все свои публичные выступления (благо, их не так много) я начинаю с явного или неявного упоминания тезиса “Наша индустрия — сложная, проблемы могут вскрыться на любом, даже самом очевидном шаге, а оптимистично предполагать, что все будет просто и легко — наивно”. Как ни странно, эта простая мысль, полученная многолетним набиванием шишек, порой является откровением и для более опытных специалистов, хотя, казалось бы, весь оголтелый задор и вера в непогрешимость собственных идей и практик должна была выветриться уже давно. Расскажу байку на этот счет, пример простого, с первого взгляда, проекта.




    В один прекрасный день товарищ скинул мне ссылку на интересный стартап. Ребята предлагали представителям малого бизнеса из сферы услуг и продаж поставить у себя точку доступа (с captive portal-ом) для своих клиентов, дабы раздавать интернет, попутно собирая MAC-адреса смартфонов людей, проходящих мимо. Цель сего действия весьма простая — большое количество рекламных сетей позволяют таргетироваться по списку адресов устройств, поэтому, направив рекламную компанию на проходящих мимо пользователей, мы с большой долей вероятности получим новых посетителей (потому что близко и “где-то это я уже видел”). Т.е. такая раздача виртуальных флаеров. Товарищ спросил, как это делается и сможем ли мы такое повторить.

    Быстрый гуглеж на тему вскрыл механизм такого сбора данных. WiFi-адаптер запускался в режиме прослушивания эфира и бегал по каналам, захватывая пакеты, анализируя их и агрегируя полученные данные. Существовали и готовые открытые утилиты для этого, например, airodump-ng из состава aircrack-ng. Т.е. для повторения нам надо просто запустить эту утилиту, желательно, на отдельном компактном и носимом устройстве, и запихнуть полученные данные в БД, из которой потом уже доставать готовые списки MAC-адресов для рекламных сетей. Вроде бы задача простая, решаемая за один, максимум — два вечера неспешной работы, почти все готово же.

    Разумеется, это оказалось ни разу не так.

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

    Первоначально мы хотели взять что-то простое и дешевое, например, коробочки Orange Pi Zero, поставить туда airodump-ng и пробросить данные, выплевываемые утилитой на сервер, где благополучно их сложить в базу. У меня был опыт работы с такими распределенными системами с выделенным центром (правда, там в роли рабочих лошадок выступали виртуальные машины, поднимаемые через API облака этим же самым центром по мере необходимости, но не суть), так что часть кода благополучно перекочевала в новый проект.

    Инструментом проброса данных на сервер послужило написанное простейшее Erlang-приложение, которое, как предполагалось, будет выдергивать данные с дампера эфира (парсинг), сериализовать их (родной сериализацией Erlang-а) и передавать через web-сокет на сервер по HTTPS (не вызывая подозрений у DPI-систем и не изобретая собственных протоколов). Процессоры Allwinner H2+, которые использовались в Orange Pi, достаточно мощные, чтобы собираться и отлаживаться прямо на устройстве. Опять же, в теории все хорошо.

    На практике началось.

    1. как оказалось, встроенный WiFi в Orange Pi годился только на то, чтобы подцепиться к точке доступа и швырнуть данные в сервер. Ну, точнее, не сам адаптер, а поддержка его чипсета в ядре. Для большинства IoT проектов этого, наверняка, было бы достаточно. Впрочем, к этому удару мы были готовы, потому что предварительное изучение сайта aircrack-ng дало вполне четкое и неоднозначное “везде это работать не будет, если что — мы не виноваты, список проверенных чипсетов прилагаем”. В списке обнаружились почти все устройства Atheros (купленной Qualcomm) и Ralink (купленной MediaTek), что внушало некоторые перспективы в случае перехода с прожорливых китайских ARM-ов на более аскетичные MIPS-ы из чипсетов для роутеров.

    Но, пока это все собирается из соплей и палок, т.е. прототипируется — надо решить проблему здесь и сейчас. Поэтому мы воспользовались такой экзотикой в наше технологичное время (когда беспроводная связь есть в любой зажигалке) как Wi-Fi USB-адаптер. Изучение списка совместимости и сопоставление его с ассортиментом ближайшего магазина выдало жертву — DLink DWA-160 в ревизии C1 (это важно, поскольку другие аппаратные ревизии использовали другой чип и вызывали неиллюзорную головную боль в плане принуждения к работе). Двухдиапазонный, не требующий плясок с драйвером, поскольку поддержка давно в ядре, этот свисток пригодился в дальнейшем и в эксплуатации в других проектах, поэтому я скупил их, наверное, все (пять штук), что оказались доступны в нашем провинциальном городе.



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



    Вторую свинью подложил aircrack-ng. Этот набор утилит был создан с целью взлома проверки на проникновение WiFi-сетей, т.е. был написан хакерами для хакеров. Не знаю, благодаря какой логике они предпочли использовать дампер эфира беспроводных сетей не в виде традиционного unix-way подхода выплюнуть структурированный текст для последующей обработки, а сделать полноценный term-интерфейс, на котором почти в реальном времени (и с учетом настроек терминала) отображать информацию по обнаруженным сетям и устройствам, но они сделали именно так. Да, я нашел Python API неизвестной степени готовности ко всему этому, но, опять же, паук прототипирования, обитавший в моей голове, жестко запретил тащить еще один язык, переключаться на другой (мы же помним, серверная часть уже была частично готова и написана она была далеко не на Python-е) или, упаси боже, реализовывать airodump-ng самостоятельно на базе tcpdump-а. А, следовательно, надо было искать обходные пути.

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

    Решением этого стал механизм inotify в ядре, уведомляющий об файловых операциях — как только мой код видел изменения файла с данными, он инициировал его чтение с небольшой задержкой (скорее, имеющей чисто психологическое значение, успокоить его автора). Проведенные опыты показали, что в этом случае сбоев при чтении и потерь данных не возникает. Ну славно, парсим CSV, укладываем во внутренние структуры и передаем на сервер. На сервере сохраняем в PostgreSQL (спасибо за jsonb) и после этого уже можно делать запросы, формировать выгрузки и т.д. Добавим простейшей авторизации по симметричному ключу, чтобы нам туда не напихали мусора и мы могли бы привязать данные к точке, где установлено устройство, и вроде бы все хорошо, можно в бой.

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

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

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

    Первая установка вскрыла сразу кучу недостатков.

    Во-первых, большинство китайских плат для прототипирования поставляется с долгосрочной памятью на MicroSD в противовес NAND/NOR flash чипам. Исключение делается только для мощных SoC, явно избыточных для данной задачи. Увы, MicroSD — это непосредственная головная боль эксплуатационщика — окисление контактных площадок, выход из строя SD-карт, зависимость контактов от температуры внутри корпуса (а она немалая, китайские чипы не являются сильно энергоэффективными, а платы, зачастую, и вовсе рассчитываются сразу исходя из пикового энергопотребления, поэтому без дополнительного радиатора ну никак). Так и оказалось, что при выдергивании питания из устройства система приходила в неработоспособное состояние — повреждались файлы с байт-кодом ERTS, после перезагрузки приложение отказывалось работать.

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

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

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

    В это момент я вспомнил, что у меня в коллекции есть замечательная плата Carambola 2 от литовских товарищей 8Devices. А если зайти на их сайт, то можно обнаружить еще более компактное устройство на том же чипе под названием Centipede. Прошлые эксперименты с данным классом устройств показали, что Erlang вполне влезает в отведенные 16 МБайт flash-памяти (и еще немного остается приложению). Единственный минус (который, скорее, даже плюс) — это маломощный MIPS и необходимость кросс-компиляции, что делает сборку Erlang-приложения чуть более нетривиальной. Но это был уже известный маршрут, поэтому я заказал парочку Centipede, а сам пока портировал существующую версию, работающую с сервером, на Carambol-у.



    Когда приехали компоненты, начался новый этап. Чип AR9331 успешно поддерживался aircrack-ng из коробки, данные можно забирать с Ethernet-интерфейса, последние версии OpenWRT и ERTS собраны и успешно опробованы. Приложение переписано — часть кода переехала в код устройства, данные накапливались в отдельном процессе и периодически сбрасывались в файл в виде сериализованного Erlang-терма. К этому был нарисован простейший web-интерфейс, получающий данные через websocket. Порты для inotify и erlexec благополучно собраны средствами OpenWRT.

    Смущало только одно — на данные оставалось 300 килобайт. Не то, чтобы мало, если хранить только MAC-адреса клиентских устройств, но airodump-ng отдает гораздо больше интересной информации, в том числе адреса точек доступа, их ESSID-ы и прочее, которое тоже неплохо было бы запомнить. На всякий случай. Ладно, будем действовать по обстоятельствам.

    Собираем, проверяем. С ходу вскрывается проблема.

    OpenWRT, как мы все знаем — это такой минималистичный вариант сборки Linux, который предназначен специально для устройств с ограниченными объемами памяти. Как следствие — оттуда выкинуто то, что можно было выкинуть безболезненно, и упрощенно то, что можно было упростить, в том числе многопользовательский режим. Т.е. обычная практика, когда код стартует от root-а и работает с максимальными привилегиями, что, конечно, облегчает вопросы связанные с группами, пользователями и контроль их действий. Да-да, буква S в аббревиатуре IoT отвечает за безопасность. Беда заключается в том, что erlexec, который я использовал для запуска и управления airodump-ng, не может выполнять операции из под root-а — для этого ему необходим дополнительный пользователь, от имени которого он будет порождать назначенные ему процессы. А при создании дополнительного пользователя с другим уровнем привилегий… правильно, не дает airodump-у достучаться до сетевого устройства. Выкрутить это ограничение из библиотеки показалось процессом небыстрым, поэтому erlexec был заменен на порты — встроенный механизм запуска сторонних процессов в Erlang. Мелочь, а неприятно.

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

    Проверить, впрочем, работоспособность этого варианта руки так и не дошли — в поле зрения попала очередная игрушка — Onion Omega2+ на Mediatek 7688. Как и у их собратьев, конструктора LinkIt Smart 7688, там было много всего, но самое главное — вдвое больше flash-памяти, а, значит, уже можно не переживать за нехватку места для хранения данных. Окей.

    Заказываем, ждем. Месяц. Два. Терпение лопается — пишем американцам на предмет “где товар, Зин”. Тишина. Открываем спор на PayPal. Американцы просыпаются. Говорят “Ой, у нас система приема заказов сбойнула, сейчас все пришлем”. Высылают, ждем три недели. Фух, устройство на руках и даже работает.



    Тут надо сделать небольшое отступление — при том, что у меня в шаговой доступности лежало несколько плат LinkIt Smart, я не рассматривал их в качестве платформы, потому как в самом начале эпопеи попытка использовать их как устройства захвата провалилась. Тогда драйвера для чипа поставлялись в виде собранных модулей под конкретные версии ядра и, видимо, это и стало причиной неработоспособности. В последних версиях OpenWRT появилась как родная поддержка 7688, так и открытый драйвер, так что это повод пересмотреть подход к данным устройствам.

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

    Соответственно, комбинируем предыдущие подходы — используем единственный выведенный на MiniDoc USB-интерфейс под WiFi-свисток для сканирования пространства, а встроенный WiFi — для управления устройством в виде маломощной точки доступа. Собираем, проверяем, все работает.

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

    Встраиваем между WiFi-свистком и устройством USB-хаб. Настройки (а они зависят от положения устройства на шине в случае OpenWRT) идут лесом, но это уже незначительные мелочи. Правим. Вытаскиваем из завалов USB-GPS приемник, благо, уже проверенный временем и с написанным кодом разбора NMEA-0183 (код, конечно же, все равно пришлось подправить). Проверяем — устройство благополучно не обнаруживается системой, явно нехватка драйверов. Собираем драйвера USB Serial и закидываем на устройство — тоже тишина. Потом вспоминаем, что в больших системах GPS-свисток обнаруживался не как ttyUSBx, а как ttyACMx, т.е. USB GSM modem. Ну отлично, второй заход на добавление драйверов, успех.

    Берем код, интегрируем в приложение. Добавляем в приложение sqlite3 в качестве хранилища. Теперь не надо будет проверять наличие записи в состоянии и вообще работа с данными упрощается до небольшого количества строчек. Собираем все в кучу, учим при добавлении данных забирать показания GPS, правим JS-код на мордочке для отображения в случае неполного набора данных (может случится, когда GPS еще не поймал спутники, а данные сканирования эфира уже идут). Проверяем работу — вроде живет. Можно объявлять промежуточную победу.



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

    Так вот, все вышеописанные мытарства — это только pet-проект с очень низкой сложностью (почти сразу было понятно, что и как делать), отсутствием разработки аппаратной части (привет, физика) и выходом на сколько-нибудь более-менее завершенное изделие. Нет, конечно, нельзя исключить, что автор этих строк — дремучий дилетант, а настоящие гуру проходят этот путь за один вечер в промежутке между вечерним чаем и рюмкой коньяка, но пока опыт показывает только одно: ИТ это сложно и оптимизм здесь наказуем финансово, репутационно и мотивационно, а те, кто говорит “там все просто” — либо гении, либо жулики, причем второе более вероятно.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 44

      0

      Как-то видел компанию, которая похожие решения на MikroTik LtAP Mini LTE собирала и предлагала людям. Договорились, что они приедут к нам в офис и потом дадут список мак адресов наших айфонов. И на этом основании примем решение о приобретении. Ребята эти так и не приехали...

        0
        Спасибо за статью!
        большое количество рекламных сетей позволяют таргетироваться по списку адресов устройств

        вспомнив факт, что мобильные устройства, зачастую, для сокрытия своего истинного MAC-адреса генерируют локальные адреса
        Мне лень ходить по ссылкам — проще спросить, потому что Вы знаете точнее, чем написано на каких-то заборах (о чем как раз Ваша статья).
        Мой вопрос:
        правильно ли я понимаю, что МАС генерируются рандомно, но их начало хотя бы соответствует вендору железки?

        Но независимо от этого, мой главный вопрос:
        а как ваще таргетировать рекламу, если кроме вендора проходимцев, неизвестно ничего больше?
        Или все же известно? Но что же это?
        Я не понял :(
          0
          правильно ли я понимаю, что МАС генерируются рандомно, но их начало хотя бы соответствует вендору железки?

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

          а как ваще таргетировать рекламу, если кроме вендора проходимцев, неизвестно ничего больше?
          Или все же известно? Но что же это?

          Очень просто. Рекламная платформа, как правило, знает ваш MAC-адрес (приложения Гугла и Яндекса есть почти на каждом смартфоне, равно как и привязка их к аккаунтам). Вы просто загружаете список адресов в рекламную сеть, они отбирают только те, что им известны, после чего на них можно настроить рекламную компанию. Можно посмотреть в самой первой ссылке на стартап — там у них на сайте все хорошо описано.

          У Гугла есть такой интересный патент на этот счет — patents.google.com/patent/US9501777B1/en
            +2
            Необязательно.
            Извините мою тупость, и из статьи я не понял: весь этот таргетинг применим только для тех железок, которые не рандомят свои МАС-и?
              0
              Все так.
                0
                С учётом того, что этим уже занимаются Android (Starting in Android 8.0, Android devices use randomized MAC addresses when probing for new networks while not currently associated with a network), Apple и даже Windows — вы опоздали с такой штуковиной года на три-четыре.

                Кроме того, много девайсов, использующих рандомный мак кладут болт на бит U/L, поэтому фильтрация по этому биту что мёртвому припарки.
                  0
                  Для пробы — да, используется рандомизация. Как только точка известна — соединение с ней происходит с применением реального адреса.

                  Поклание на U/L — это нехорошо, но я так понимаю, примерно с той же вероятностью рандомизация может быть и отключена.

                  Вообще-то вся статья писалась только ради первого и последнего предложения (как песня про выборы Шнура), но окей, опоздал так опоздал.
                    0
                    Это не так.
                    «In Android 10, MAC randomization is enabled by default for client mode, SoftAp, and Wi-Fi Direct.» — современные устройства уже ушли от работы с реальным MAC.

                    При этом, если вы посмотрите на большой хотспот с андроидами, то увидите, что второй бит там поголовно равен 0, а устройство сохранило OUI производителя. Т.е. на U/L положено на уровне дефолтных настроек как минимум андроида и эпла.
                      0
                      Я проверил на моем телефоне с Android 10 и нашел его MAC (отображается в настройках устройства) в списке захваченных. Не знаю, следует ли из этого делать какие-то обобщения, но не могу принять вашу категоричность.
                        0
                        Обобщения лучше делать из официальной документации, а не из частных случаев.
                        source.android.com/devices/tech/connect/wifi-mac-randomization?hl=ru

                        Там:
                        The System UI must… have MAC randomization enabled by default for all newly added networks.

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

                          0
                          Меня немного смутило:
                          . In Android 9, you can enable a developer option (it's disabled by default) to cause the device to use a randomized MAC address when connecting to a Wi-Fi network.


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

                          Мой телефон вполне среднестатистический, известного китайского бренда (не Xiaomi). Возможно да, забили. А может быть и нет. Встроенная паранойя не дает повода для надежды. )
                            0
                            К слову, у меня под рукой лежал еще один телефон на Android 10 от Nokia. Его MAC тоже нашелся в списке найденных. Так что, похоже, тотальная рандомизация MAC еще не столь всеохватывающая. Свежей продукции Apple, увы, под рукой нет, проверить не могу.
                0
                Какой-то он уже устаревший — этот патент.
                И здесь большая часть посвящена реализации передачи MAC адреса (понимать как: идентификатора устройства) веб-сайту.
                  0
                  Там на пятом рисунке очень интересная диаграмма, как раз про выдачу рекламы.
                    0
                    "… направив рекламную компанию на проходящих мимо пользователей, мы с большой долей вероятности получим новых посетителей"
                    Как вы собрались направлять на кого-то рекламную кампанию? С помощью раздачи им wi-fi? Встроить баннер в HTTP? Так зачем вам нужны MAC адреса? Если вы маленькая точка — то и ассортимент фиксирован, а если кто-то вроде М.Видео — да в жизнь не угадаете, зачем человек зашел — ноутбуки посмотреть или телевизоры.

                    Стартап я понял, с рандомизацией MAC адреса он нежизнеспособен. Больше похож на какой-то развод, если честно. «сколько людей посетили заведение после просмотра рекламы» — он не может помочь узнать, т.к. рекламу могли смотреть на чем угодно, а не с мобильного. Все упирается в то, что MAC адреса веб сайтам никак без дополнительного ПО не доступны. Поэтому, даже предоставив MAC адреса тех, кто прошел мимо вас рекламной площадке — они не сопоставят их впоследствии, посетителю, зашедшему через HTTP(S).

                    А вы что хотите?
                      0
                      Я прям даже не знаю что ответить, кроме как «а с кем вы сейчас разговаривали?» )
                        0
                        Да вроде не ошибся. Вы собирались собирать MAC адреса, чтобы как-то таргетировать рекламу (я делаю тоже самое только двумя ESP8266 и для другой цели, однако диапазон сбора ограничен только частотой 2.4G). Вот и хотел уточнить, собрали вы адреса — а дальше?
                        А дальше до меня дошло. Эти MAC передаются рекламным сетям, которые крутят рекламу в мобильном приложении, а мобильное приложение уже знает MAC адрес.
                          0
                          Да, все так. Только MAC-адреса сопоставляются не мобильным приложениям, а конкретным пользователям. Реклама же может прилететь вообще из других каналов и устройств.
                        0
                        Впрочем, развлекаться — так по-полной.

                        Как вы собрались направлять на кого-то рекламную кампанию?

                        В рекламных сетях есть инструмент выбора аудитории, когда вы на всех жертв, доступных рекламной сети (вы пользуетесь Яндексом, Мейлом или Гуглем — поздравляю, вас посчитали), фильтруете по какому-либо признаку. Если рекламная сеть знает о принадлежности вам какого-либо устройства (а она знает, если у вас есть приложение с аутетифицированным аккаунтом), то она знает и MAC-адрес устройства. Например, так. Соответственно, рекламодатель может по списку MAC-адресов подобрать аудиторию и сказать «вот эту рекламу покажите этим пользователям». А дальше уже вопросы сети, как она это будет делать.

                        Да, отключение WiFi в публичных местах и использование блокировщика рекламы выключит вас из этого увлекательного процесса. Но это — нетипичное поведение. At mass определенная часть пользователей все же попадет «под раздачу». Разумеется, как потом их настигнет реклама заведения, мимо которого они ходят каждый день — головная боль рекламной сети.

                        Встроить баннер в HTTP?

                        Вы что-то путаете. Вышеописанное в статье устройство пассивно слушает эфир и собирает данные. Для встраивания в трафик необходимо завернуть на себя мобильное устройство (например, притворившись популярной открытой точкой доступа) и уже в этом случае можно говорить о каком-то встраивании через DPI или transparent proxy. Это другая интересная задача, впрочем, как вы верно отметили, абсолютно бесполезная вследствие повального использования HTTPS. Поэтому особо хитрые используют для этого captive portal непосредственно при подключении к точке доступа. А, поскольку анонимный доступ к публичному wifi запрещен законодательно, можно посредством captive portal и данных dhcp еще и выудить телефон подключенного пользователя. На особых параноиках не сработает, а вот с остальными не уверен.

                        Если вы маленькая точка — то и ассортимент фиксирован, а если кто-то вроде М.Видео — да в жизнь не угадаете, зачем человек зашел — ноутбуки посмотреть или телевизоры.

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

                        Стартап я понял, с рандомизацией MAC адреса он нежизнеспособен.

                        Вы не совсем правильно понимаете. Рандомизация MAC-адресов происходит при сканировании эфира в поисках новых точек доступа, к которым можно подключится. При наличии известной точки доступа рандомизация не используется, устройство работает на своем «родном» MAC-адресе.

                        Больше похож на какой-то развод, если честно.

                        Тут я не доктор. Но беглый гуглинг выдал пять штук аналогичных проектов. Особое впечатление произвело как эти ребята бодаются на ЦП.
                          0
                          >> Встроить баннер в HTTP?
                          >> Вы также пишите и " для своих клиентов, дабы раздавать интернет "
                          Я имел в виду: раздавать интернет и встроить баннер. Уточнял, т.к. целесообразности не вижу.

                          >> При наличии известной точки доступа рандомизация не используется, устройство работает на своем «родном» MAC-адресе.
                          Это я тоже знаю, сразу и написал ниже. И насколько ещё знаю, устройство не подключится к открытой неизвестной сети, пока вы явно не разрешите. Сначала будет уведомление. А за это время потенциальная жертва мимо вас уже пройдет, а если останется, с целью использования wi-fi — то, скорее всего это школьник-халявщик в торговом центре.
                            0

                            Это просто сужает аудиторию. Потом же ее можно будет сверху отполировать по возрасту и другим предпочтениям.

                              0

                              Сеть можно сделать и известной, например, с названием MT_FREE. В Москве многие используют WiFi в транспорте...

                                0
                                Действительно, тогда телефон к ней автоматически подключится и сольет реальный MAC. Но применимо только в «экосфере» Москвы.
                  0
                  Все чаще (в смысле новые устройства), пока телефон не подключен к известной ему WiFi сети, то он использует случайный MAC адрес. Возможно не полностью случайный, но узнать, что каждый день мимо вас проходит один и тот же человек не получится.
                    0
                    пока телефон не подключен к известной ему WiFi сети — он использует случайный MAC адрес.
                    А после обнаружения известной он признается во всем и перекрашивается обратно? А что, фильтры доступа по МАС все еще кто-то где-то всерьез использует? Именно учитывая этот модный нонче рандом…
                    … вопросы, вопросы, вопросы...
                      0
                      Пока да. Для удобства ещё как используется: по MAC адресам DHCP IP адреса назначает.
                      0
                      Все чаще (в смысле новые устройства), пока телефон не подключен к известной ему WiFi сети, то он использует случайный MAC адрес.

                      В москве есть MT_FREE, к сожалению, без пароля.
                        0
                        Да в общем-то не важно с WPA* она или нет — это одинаково поможет идентификации устройств там, где она есть всем желающим (MAC адреса не шифруются).
                      +1
                      Для Orange pi платы есть вот такой проект.
                      Это мини линукс, типа OpenWrt для загрузки с spi flash. MicroSD не нужна.
                      У меня куча устройств на нем, от роутеров до ip-serial конвертеров.
                      Рекомендую попробовать.
                        0
                        Ага, спасибо, интересный проект.

                        Увы, у меня не было в тот момент OPI Zero с SPI-флешкой, они, вроде, стали их напаивать только в LTE-инкарнации. Поэтому пришлось MicroSD + Armbian.
                        +1
                        Всё уже украдено до вас: evotor.ru/news/evotor-zapustil-dmp-na-oflajn-dannyh
                        У Эвотора сейчас более 600 тысяч Wi-Fi-сенсоров, расположенных не только в городах, но и в малых населенных пунктах. Это крупнейшая сеть Wi-Fi-сенсоров в стране.
                        Сниффер MAC-ов встроен как функция в онлайн-кассу. У которой хороший процессор и by design подключение к интернету, чтобы отсылать фискальные чеки в ФНС. А ещё касса стыкует данные о ваших покупках с вашим maс-адресом (если в чеке «Доширак», вас запишут в один сегмент, если икра — в другой).
                          0
                          Всё уже украдено до вас
                          да, только в гугл-маркете число установок смешное, а на самом сайте ссылки ведут не туда, а на начало страницы.
                          И ваще они мелкие совсем в сравнении с монстрами вроде
                          marketolog.mts.ru
                          target.megafon.ru
                          moskva.beeline.ru/business/services/beeline-prodvizhenie/sms-rassylka
                          msk.tele2.ru/business/option/sms-target-new
                          Но и цены тут другие, хе-хе…

                          А где цены высокие и технологии модные — там и tiktok.baza.io
                            0
                            МегаФон-таргет работает по другому принципу, он для другого. К телекомовским трекинговым технологиям я руку прикладывал, мне можно про них не рассказывать.

                            да, только в гугл-маркете число установок смешное


                            вы не понимаете. Сниффер стоит в кассе. Касс в России у Эвотора — 600 тыс. Если вам пробили чек, то ваш телефон посчитали. Если вы постояли у витрины — вас посчитали. Независимо от того, какие у вас там приложения стоят. Их авторам заплатили за то, что они поставили совершенно бесплатную AppMetrica или MyTracker, а они позаботятся о том, чтобы к вашему MAC подверстать ID в рекламных системах и куки.

                            Смотреть надо не в плей-маркет, а в target.my.com/segments/external, например.

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

                                Мне кажется, ни вы, ни я в данном вопросе статистически незначимы.

                                  0
                                  Реклама — это частности; переживать вам стоит о том, что на основании этих данных решается, по какой ставке вам дать (или вообще не дать) ипотеку.
                            +1

                            А не рассматривали возможность использовать андроид? Почему-то о нем ни слова. И да, очень понравился стиль изложения материала, приятно читать. Спасибо

                              0
                              Да, наверняка, можно использовать Android. Увы, у меня больше опыта с классическим Linux-ом и OpenWRT, поэтому выбор пал именно на них.

                              Спасибо.
                              0

                              Linux, aircrack-ng, OpenWRT… И все это для простейшей задачи сниффинга с фильтрацией по типу пакета?


                              Есть же ESP32 — готовая железка для этих целей. Относительно небольшой код на C++ (практически все в SDK уже есть).
                              Сам недавно подобное делал (ну точнее несколько большее по общему функционалу и для других целей).

                                0

                                С удовольствием прочитаю про ваш опыт. Где можно глянуть?

                                  0

                                  https://habr.com/ru/post/493412/
                                  Там же ссылка на Git.
                                  Одна из функций — это получение списка STA (как активно подключенных, так и просто включенных).


                                  Одновременно сниф и доступ к данным снифа я не делал (не нужно было), но в принципе, это должно работать.

                              +1
                              Ох… В своё время я пробовал почти точно такую же штуку сделать, только заказчику хотелось, чтобы устройство отгружало МАСи по мобильной связи. Взяли самую дешёвую железку — Orange Pi 2G-IOT. Это было очень зря, свои мытарства описал даже на Хабре: Orange Pi 2G-IOT: карта минного поля. Добиться стабильной работы так и не удалось. Вероятно, надо было бы просто взять любой модем и любую железку с вай-фаем, нормально работало бы, но на тот момент я не хотел закапываться в эту тему
                                0
                                Содержательный текст))



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

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

                                Самое читаемое