Делаем свою прошивку для IP-камеры на Rust и боремся с фродом30.01.2018 12:33

Это продолжение рассказа о лучших (по мнению участников) докладах HighLoad++ 2017. В предыдущей статье я писал о двух лидерах рейтинга. Идем дальше. В этом материале — доклад Вадима Антонюка о фродах и Макса Лапшина — о прошивке для IP-камеры на Rust.

Fraud in mobile applications: how to define and detect, Vadim Antonyuk (4,73 балла)

Почетное третье место. Вадим не первый раз рассказывает про антифрод на Highload++. Годом ранее он говорил об антифроде в RTB-системах в целом, в этот раз «досталось» мобильным приложениям. Забегая вперед, скажу, что до сих пор идут споры о том, что считать фродом именно в мобильных приложениях, в отличие от веба, где все более-менее понятно. Тем не менее, растет и сам сегмент, и вместе с ним проблема. А значит, самое время начать ее решать — «пока не началось».

Между тем, если вы не знаете или все еще сомневаетесь, что RTB — это хайлод, — как вам цифра в 400 миллиардов запросов в сутки? При этом по статистике на долю мобильных приложений приходится около 40% — больше, чем на десктопный веб. IPONWEB (один из крупных игроков рынка RTB-рекламы) достаточно давно и успешно детектирует фрод в веб-сегменте, но до приложений добрались только вот-вот.

Итак. Классические методы (боты, AdStackng, Domains Spoofing, Ghost sites), которые давно применяются в классическом вебе, в мобильных приложениях в явном виде не работают. Как следствие, не подходят и методы борьбы с ними, и нужно изобретать что-то новое.
Кстати, индустрия еще не договорилась о том, что считать фродом в мобильных приложениях. Казалось бы, истории с рекламой в мобилках уже прилично, но факт остаётся фактом, и об этом говорит Вадим.

В докладе рассматриваются два (а на самом деле почти три) подхода детектирования фрода:

• Backgroundness — показ рекламы в фоновом режиме. Суть такого типа фрода — в его названии. То есть реклама есть, но пользователь ее не видит. Как ее искать? Все не очень сложно, но есть нюансы.  Суть изначального метода состоит в поиске в потоке входящих запросов всех запросов от пары «приложение+пользователь», которые шлют запросы непрерывно. Вычисляются такие интервалы и делается анализ на реалистичность.

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

  

  Можно сделать проще? Оказывается, что можно опираться только на значение T (период непрерывного испускания сигнала) и анализировать интервалы между соседними отрезками времени (в нашем примере — искомый интервал  между T1 и T2. Если в течение суток нет реалистичного перерыва (допустим, 6 часов), то, скорее всего, что-то пошло не так. В итоге при большом числе измерений от одного приложения точность метода растет.

• Второй метод — Entropy Score.  Поиск негодяев через аномальную энтропию. Чтобы стало понятнее, рекомендую предварительно почитать вики. Метод строится на последовательном численном анализе поведения пользователей и приложений. Вычисляется Entropy Score, за счет большого числа измерений определяется допустимый интервал значения этого параметра — когда с высокой степенью вероятности поведение приложения и пользователя являются реальными — , а все остальные приложения подвергаются анализу.  

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

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

  

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

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

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

Делаем свою прошивку для IP-камеры на Rust, Макс Лапшин (Max Lapshin) (4,70 балла)

Макс — постоянный участник айтишных мероприятий, член программного комитета Highload++, автор очень быстрых и производительных решений для стриминга видео, которыми пользуются по всей планете, знаток erlang«a и просто отличный спикер. Его рассказ не вошел в тройку лучших, но послушать его обязательно надо — хотя бы потому, что его компания — одна из немногих в России успешно продвигает свой программный продукт на мировом рынке.

Непосредственно про стриминг и его нюансы Макс рассказывал на прошлых конференциях. В этот раз речь шла о том, как поменять софт на IP-камерах, как появился в этой истории Rust, и что из этого вышло. В докладе две части: первая — непосредственно про специфику работы с IP-камерами, вторая же посвящена Rust«у и его особенностям.

Несмотря на то, что IP-камеры широко распространены, дешевы, а аппаратная платформа с каждым годом становится все надежнее, софт для IP-камер оставляет желать лучшего. То есть вместе с камерой вы получаете софт 10–12 летней выдержки со всеми дефектами, отсутствием фич, а главное — невозможностью вносить изменения. В итоге разумнее всего написать свой софт, чтобы получить набор нужных фич и снизить сложность работы с устройством. Кстати, вариант сделать свою камеру тоже был —, но от него отказались ввиду дороговизны и длительности, а также необходимости работать с уже существующими камерами, которых миллионы.

По сути IP-камера является компьютером с процессором, памятью и прочими узлами, а значит и работать с ней можно, например, по аналогии с мобилками. Так же, как и в мобилках, здесь есть куча вариантов исполнения внутреннего программного обеспечения: где-то что-то можно писать, где-то только читать, есть разный U-boot (мощный загрузчик с кучей нужных для заливки функций) с разным софтом для перезаписи, есть большой набор различных шлейфов, щипцов и паяльников. Ну и, как следствие, — вылезают все прелести перепрошивки вашего любимого андроида: скакнуло питание — камера превратилась в кирпич, ошиблись в прошивке — снова кирпич. Благо, стоимость такого «кирпича» на текущий момент в пределах десяти долларов за штуку.

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

После сборки можно смело приступать к прошивке. Оказывается, что то, что вы раньше считали «зоопарком» технологий, — детский лепет по сравнению с тем, когда речь идет о камерах. Различные версии ядра, библиотек, SDK — абсолютная норма для них. Нормой же следует считать полное отсутствие возможности погонять тесты без заливки на камеру, жесткую нехватку места (8 мегабайт, ага), а также постоянную работу с железом и точное управлением памятью.  Подытожим — камера очень интересный и одновременно дешевый прибор (можно смело экспериментировать и превращать камеры в кирпичи), с которым можно очень неплохо взаимодействовать, достигая свои цели.

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

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

Детально останавливаться не буду, отмечу только, что Макс очень доходчиво объясняет любителям хайпа, что за все надо платить, и Rust — не исключение.  В заключении отмечается, что, несмотря на внешнюю сложность, использовать для полу-embedded систем Rust можно, и это свежо и прикольно, хоть и придется немного переформатировать свой мозг.

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

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

© Habrahabr.ru