В качестве нашей первой попытки стимулировать исследования в области разработки программного обеспечения для OpenHarmony теперь мы представляем предварительный план исследований, обобщая пробелы в исследованиях между Android/iOS и OpenHarmony. Подробно описывая пробелы, мы также представляем примеры работ, которые, по нашему мнению, также следует предложить для OpenHarmony. Мы надеемся, что наши коллеги-исследователи смогут внести свой вклад в эти работы, чтобы заполнить вышеупомянутые пробелы и сделать OpenHarmony популярной мобильной платформой и популярной темой исследований в области разработки мобильного программного обеспечения.

5.1. Пробелы в исследованиях, связанных с приложениями

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

(1) [Требование] Обзоры пользователей для анализа требований. Поскольку, как правило, невозможно получить исходные требования к мобильным приложениям (например, какие функции предлагать и как с ними взаимодействовать с пользователями), которые часто считаются конфиденциальными, исследовательское сообщество в основном сосредотачивается на анализе отзывов пользователей для понимания требований. Здесь отзывы пользователей могут быть собраны либо посредством реальных интервью, либо посредством комментариев пользователей, оставленных на странице выпуска приложения в магазине приложений. К счастью, такие усилия можно напрямую использовать для улучшения приложений OpenHarmony, поскольку выявленные требования часто не зависят от мобильных платформ. Тем не менее, предложенные методы также можно использовать для сбора отзывов пользователей, специально предназначенных для приложений OpenHarmony.

−→Репрезентативные работы: Chen et al. [21] утверждают, что можно выяснить потребности и предпочтения пользователей, анализируя комментарии пользователей в Интернете, что впоследствии может помочь разработчикам приложений правильно позиционировать себя на рынке и тем самым увеличить объем загрузок приложений. Используя набор методов НЛП, таких как семантический анализ, анализ частоты слов, авторы демонстрируют возможность получения полезных требований. Аналогичным образом, Паломба и др. [84] предлагают поддерживать эволюцию мобильных приложений посредством краудсорсинга отзывов пользователей. Опросив 73 разработчиков, они обнаружили, что более 75 % разработчиков принимают во внимание отзывы пользователей при обновлении своих приложений, и такие обновления часто вознаграждаются в виде значительного повышения пользовательских рейтингов.

(2) [Дизайн] Распознавание эскизов Дизайнеры приложений часто используют эскизы для быстрого рисования пользовательских интерфейсов приложения, чтобы ускорить итеративный процесс проектирования при разработке приложений. Однако такие эскизы нельзя напрямую использовать для создания прототипа приложения, которое можно немедленно протестировать для сбора отзывов пользователей. Чтобы преодолеть этот разрыв, исследователи предложили методы автоматического распознавания эскизов и последующего преобразования их в компоненты пользовательского интерфейса. Таким образом, разработчики приложений могут сосредоточиться на разработке пользовательского опыта, а не на создании прототипов с помощью различных инструментов. Такие подходы могут быть чрезвычайно полезны разработчикам OpenHarmony при разработке своих приложений.

-→Репрезентативные работы: Kim et al. [52] представили сообществу подход к идентификации виджетов пользовательского интерфейса мобильных приложений непосредственно из эскизных изображений с использованием функций геометрического и текстового анализа. извлечение графических элементов, таких как текст или формы, из входного изображения эскиза с использованием метода оптического распознавания символов (OCR) и обнаружения краев. Аналогичным образом, Ли и др. [68] предложили сообществу инструмент прототипирования на основе эскизов под названием Xketch для ускорения процессов проектирования мобильных приложений. Они продемонстрировали, что Xketch действительно полезен и может помочь разработчикам приложений быстро создавать приложения на своих планшетах.

(3) [Дизайн] Визуальный поиск рекомендуемых примеров дизайна. Поскольку разработать красивый пользовательский интерфейс с нуля нетривиально, разработчики часто прибегают к относительным примерам дизайна пользовательского интерфейса, чтобы получить вдохновение и сравнить альтернативы дизайна. Однако найти такие примеры дизайна сложно, поскольку существующие поисковые системы поддерживают только текстовые запросы. Чтобы смягчить это, наше сообщество предложило провести визуальный поиск, который принимает в качестве входных данных изображение дизайна пользовательского интерфейса и выдает визуально похожие проекты. Поскольку визуальный поиск не зависит от мобильных платформ, такие усилия могут быть напрямую использованы и на пользу сообществу OpenHarmony. Тем не менее, приложения OpenHarmony могут иметь особые предпочтения на своих страницах пользовательского интерфейса. Также существует необходимость изобрести специальные системы визуального поиска для поддержки дизайна приложений OpenHarmony.

−→Репрезентативные работы: Bunian et al. [17] предложили сообществу систему визуального поиска, которая включает в себя структуру поиска изображений на основе обнаружения объектов, которая моделирует контекст пользовательского интерфейса и иерархическую структуру. На основе крупномасштабного набора данных о пользовательском интерфейсе авторы показали, что их платформа визуального поиска может обеспечить высокую производительность при запросе аналогичных дизайнов пользовательского интерфейса.

(4**) Рекомендация Кодекса [Разработка]**. Мобильные приложения разрабатываются на основе официального SDK с тысячами API, а через так называемые сторонние библиотеки доступны сотни тысяч API. следовательно, существует острая необходимость автоматически рекомендовать соответствующие API (или библиотеки) разработчикам при реализации своих приложений. Кроме того, было продемонстрировано, что библиотеки чрезвычайно полезны для облегчения разработки приложений, поскольку они предоставляют множество существующих реализаций функций, которые можно повторно использовать и часто являются высококачественными (например, уже проверенными различными вариантами их использования). Нередко разработчики поощряют использовать сторонние библиотеки для реализации приложений OpenHarmony. Поскольку количество доступных библиотек постоянно растет, разработчикам становится нетривиально искать подходящие библиотеки. Поэтому существует острая необходимость автоматически рекомендовать необходимые библиотеки разработчикам приложений OpenHarmony.

-→Репрезентативная работа: Чжао и др. [122] представили сообществу прототип инструмента под названием APIMatchmaker, который автоматически подбирает правильные API для поддержки разработки приложений для Android. Рекомендуемые API взяты из других приложений Android, которые считаются похожими на разрабатываемое. Другой пример: Yuan et al. [116] предлагают использовать поисковую систему API, чтобы рекомендовать API функций, и делают еще один шаг вперед, чтобы продемонстрировать необходимость рекомендовать обратные вызовы событий (которые необходимо переопределить, чтобы они содержали код функции) для разработчиков.

(5) [Разработка] Реализация компонентов графического пользовательского интерфейса. В мобильных приложениях используется множество значков. Чтобы сохранить одинаковый внешний вид, аналогичные компоненты графического интерфейса (значки или анимация) в разных мобильных приложениях часто сохраняют схожие функциональные возможности. Таким образом, можно изучить семантику популярных компонентов графического интерфейса и впоследствии рекомендовать разработчикам реализацию кода при использовании соответствующих компонентов графического интерфейса.

-→Репрезентативная работа: Чжао и др. [121] предложили подход под названием Icon2Code, который использует интеллектуальную систему рекомендаций, помогая разработчикам приложений эффективно и результативно реализовывать методы обратного вызова иконок Android. Система рекомендаций построена на основе крупномасштабного набора данных, содержащего сопоставления значков с их реализациями в коде. Аналогичным образом, Ван и др. [104] предложили подход, рекомендующий API для реализации анимации пользовательского интерфейса Android. При этом подходе создается база данных, содержащая сопоставления между анимацией пользовательского интерфейса в формате GIF/видео и соответствующими API, а затем используется ее для выполнения рекомендаций.

(6) [Тестирование] Случайное тестирование (генерация тестовых примеров). Мобильные приложения, как и любое другое программное обеспечение, необходимо тщательно протестировать перед выпуском для пользователей. Применительно к OpenHarmony нет никакой разницы. Существует как минимум два сценария, которые требуют создания тестовых примеров, чтобы гарантировать, что приложения ведут себя должным образом. Первый — генерировать тест-кейсы для модульных тестов, что обеспечивает корректность только определенных функций. Второй — генерировать входные данные для приложений, работающих в мобильных операционных системах. Сообщество OpenHarmony предъявляет аналогичные требования. Случайное тестирование считается одним из наиболее полезных инструментов для создания тестовых примеров для изучения мобильных приложений благодаря его простоте в использовании и масштабируемости. Наши коллеги-исследователи показали, что Monkey, простой подход и инструмент для выборочного тестирования приложений Android, удивительно эффективен, превосходя по производительности гораздо более сложные инструменты за счет более высокого покрытия кода. Мы считаем, что в OpenHarmony также необходим такой подход к выборочному тестированию, который также является основой для поддержки реализации многих передовых инструментов тестирования приложений.

-→Репрезентативная работа: Амальфитано и др. [5] представили сообществу исследовательский прототип под названием AndroidRipper, в который встроен автоматизированный метод тестирования приложений Android через их графический интерфейс пользователя (путем автоматического исследования графического интерфейса приложения с целью структурированного использования приложения). Существующие экспериментальные результаты показывают, что AndroidRipper превосходит метод случайного тестирования, поскольку способен обнаруживать серьезные и ранее неизвестные ошибки в приложениях Android с открытым исходным кодом. Ли и др. [69] представили сообществу еще один автоматический генератор тестового ввода для приложений Android. Инструмент под названием DroidBot спроектирован так, чтобы быть легким (нет необходимости оснащать тестируемое приложение) и поддерживает настройку для реализации специальных стратегий тестирования с использованием графического пользовательского интерфейса. Аналогичным образом, в области iOS Wu et al. [108] представили сообществу платформу тестирования на основе моделей под названием CydiOS для случайного тестирования приложений iOS. Инструмент CydiOS был опубликован его авторами как проект с открытым исходным кодом.

(7) [Тестирование] Пробное тестирование. Выполнение модульных тестов для мобильных приложений, включая приложения OpenHarmony, является нетривиальной задачей. Действительно, для некоторых тестируемых функций требуется контекст, который является частью жизненного цикла приложения или системы. Эта контекстная информация доступна только тогда, когда приложение работает в мобильной системе, что противоречит тому факту, что модульные тесты не предполагают фактического запуска приложений на мобильных устройствах.

-→Репрезентативная работа: существует несколько хорошо известных платформ, таких как Mockito в MSE, которые предоставляются практиками для поддержки макетного модульного тестирования. Подобные фреймворки также пользуются большим спросом у сообщества OpenHarmony. Что касается исследований, Бересфорд и др. [14] предложили сообществу новый подход под названием MockDroid, который позволяет пользователю «имитировать» доступ приложения к ресурсу. Впоследствии ресурс сообщается как пустой или недоступный всякий раз, когда приложение его запрашивает. Их работа продемонстрирована как полезная для тестирования мобильных приложений с помощью W.R.T. их терпимость к сбоям ресурсов.

(8) [Тест] Целенаправленный фаззинг. В настоящее время мобильные приложения работают на сенсорных дисплеях и включают в себя множество страниц графического пользовательского интерфейса, каждая из которых включает в себя различные методы жизненного цикла и содержит различные виджеты, которые в дальнейшем связаны с методами обратного вызова. Такая сложная настройка затрудняет достижение высокоэффективного случайного тестирования. Чтобы смягчить это, исследователи предлагают проводить целенаправленный фаззинг, например, генерируя тестовые входные данные, которые позволяют приложению достичь определенного состояния. Приложения OpenHarmony также требуют большого количества графического интерфейса, и к ним также применимы недостатки случайного тестирования. Следовательно, существует острая необходимость в разработке целевых подходов фаззинга для правильного тестирования приложений OpenHarmony.

-→Репрезентативная работа: Растофер и др. [90] представляют сообществу целевой метод фаззинга, а именно FuzzDroid, для автоматического создания среды выполнения Android, в которой приложение демонстрирует вредоносное поведение. Эта цель достигается за счет объединения расширяемого набора статического и динамического анализа с помощью алгоритма поиска, который направляет приложение к настраиваемому целевому местоположению. Другой пример: Азим и др. [10] представляют другой подход под названием 𝐴 3𝐸, который использует статический анализ потока данных в стиле taint для сначала создания высокоуровневого графа потока управления, который фиксирует допустимые переходы между экранами приложения. 𝐴 3𝐸 затем выполняет целевое исследование для быстрого и прямого изучения действий.

(9) [Тест] Запись и воспроизведение. Мобильные приложения после публикации в открытом доступе необходимо запускать на нескольких устройствах, на которых могут работать разные версии платформы. Эти устройства также могут иметь экраны разных размеров с настроенными версиями платформы. Чтобы гарантировать, что одно и то же приложение может корректно запускаться на всех этих устройствах, исследователи предлагают проводить тестирование записи и воспроизведения, при котором сценарий тестирования сначала записывается на устройстве, а затем применяется к другим устройствам с ожиданием достижения того же результата. результаты тестирования. Поскольку одной из наиболее важных функций OpenHarmony является поддержка так называемой стратегии «1+8+N» (т. е. поддержка одного основного устройства (например, смартфона), 8 важных устройств, таких как телевизор, умные часы, планшет, ПК, и т. д., а также многих других настраиваемых пользователем устройств, этот метод записи и воспроизведения чрезвычайно важен для OpenHarmony, поскольку он обеспечивает успех стратегии «1+8+N».

-→Репрезентативная работа: Гомес и др. [42] представляют прототип инструмента под названием RERAN, который обеспечивает синхронизацию и сенсорную запись и воспроизведение для Android. RERAN пытается напрямую захватить поток событий низкого уровня на телефоне и воспроизвести его позже с точностью до микросекунды. Поскольку мобильные приложения могут запускаться на разных устройствах с экранами разных размеров, инструмент записи и воспроизведения может применяться к приложениям, которые могут иметь разные макеты графического интерфейса на разных устройствах. Чтобы учесть это, Guo et al. [44] представляют еще один инструмент записи и воспроизведения под названием Sara, который достигает этой цели за счет механизма адаптивного воспроизведения с динамическим инструментальным подходом, учитывающим богатые источники входных данных в текущих мобильных приложениях.

(10) [Тест] Краудсорсинговое тестирование. Автоматизированное тестирование приложений не может обеспечить 100% охвата, поэтому для обеспечения качества мобильных приложений всегда необходимы обязательства пользователей. Однако всестороннее изучение приложения вручную сложно и требует много времени. Чтобы облегчить эту ситуацию, исследователи предложили использовать усилия краудсорсинга для достижения вышеупомянутой цели тестирования. Действительно, краудсорсинговое тестирование обеспечивает многообещающий способ проведения крупномасштабных и ориентированных на пользователя сценариев тестирования. Такой подход также можно использовать для всестороннего тестирования приложений OpenHarmony.

-→Репрезентативная работа: Ge et al. [39] обнаружили, что большинство краудсорсинговых тестов приложений имеют низкое качество, поскольку краудсорсинговые работники часто незнакомы с тестируемым приложением и не знают, какую часть приложения следует тестировать. Чтобы восполнить этот пробел, авторы предлагают построить модель Annotated Window Transition Graph (AWTG) для тестируемого приложения путем объединения результатов динамического и статического анализа, а затем использовать модель AWTG для реализации конвейера помощи при тестировании, который предлагает извлечение тестовых задач, тестирование. рекомендации по задачам и руководство по тестированию заданий для коллективных работников. Недавно Сан и др. [101] представляют сообществу облегченный подход, целью которого является достижение полностью автоматизированного краудсорсингового тестирования приложений путем отправки только части кода приложения для краудсорсингового исполнения. Результаты экспериментов, включающие тестирование только кода, связанного с API (реальных приложений), показывают, что их подход полезен (о чем свидетельствует возможность обнаружения многих проблем совместимости, вызванных API) и приветствуется на практике.

(11) [Проверка кода] Платформа статического анализа. Статический анализ — это фундаментальная технология, которая часто применяется для решения различных проблем анализа приложений Android. Такие решения часто реализуются на основе так называемых фреймворков статического анализа, которые предлагают реализации основных функций статического анализа, таких как построение графов потока управления, построение графов вызовов и т. д. OpenHarmony использует новый программный язык под названием ArkTS для разработки своих приложений. Поэтому для поддержки реализации других целевых подходов статического анализа (например, обнаружения уязвимостей) требуется специфичная для ArkTS структура статического анализа.

-→Репрезентативная работа: Soot [56] — одна из самых популярных платформ статического анализа, способная анализировать приложения Android. Soot изначально предназначен для анализа программ Java, а затем расширен для приложений Android (написанных на Java) благодаря модулю Deexpler, предоставленному Bartel et al. [12]. Другой популярной структурой статического анализа должна стать система под названием WALA [93], разработанная и поддерживаемая IBM. В Android наши коллеги-исследователи неоднократно использовали Soot и WALA для поддержки реализации подходов статического анализа.

(12) [Проверка кода] Статический анализ вредоносных данных (для обнаружения утечек конфиденциальной информации). Одним из наиболее популярных применений статического анализа является выполнение статического анализа пятен для выявления потоков конфиденциальных данных (также известных как утечки конфиденциальной информации). Статический анализ ошибок сначала окрашивает некоторые переменные, содержащие конфиденциальные данные, такие как номер телефона пользователя, а затем отслеживает их потоки в коде. Поток конфиденциальных данных считается обнаруженным, если такие цветные данные в конечном итоге передаются конфиденциальным операциям (например, отправка цветных данных за пределы устройства через SMS). Приложения OpenHarmony будут запускаться на мобильных устройствах и, следовательно, будут иметь аналогичные требования. Поэтому также важно изобрести методы статического анализа ошибок для проверки приложений OpenHarmony.

-→Репрезентативная работа: Арцт и др. [7] представили сообществу MSE инструмент с открытым исходным кодом под названием FlowDroid, который выполняет анализ пятен с учетом контекста, потока, поля и объекта, а также с учетом жизненного цикла приложений Android. Авторы также предоставляют алгоритмы по запросу для FlowDroid, позволяющие одновременно достичь высокой эффективности и точности. На основе FlowDroid исследователи также представляют сообществу три расширения, а именно IccTA [58], DroidRA [62, 63, 102] и SEEKER [100], которые выполняют статический анализ искажений, дополнительно рассматривая межкомпонентное взаимодействие приложений, отражение и функции, связанные с датчиком, соответственно. В области iOS Эгеле и др. [31] представляют инструмент под названием Pios, который использует статический анализ вредоносных данных для обнаружения утечек конфиденциальности в приложениях для iOS.

(13) [Проверка кода] Анализ сходства кода. Анализ сходства кода — еще одно распространенное применение статического анализа, которое также неоднократно применялось разработчиками для выполнения различных функций, например, для обнаружения клонов кода, использования сторонних библиотек и переупакованных (или объединенных) приложений. Анализ сходства кода также важен для понимания разницы между двумя фрагментами кода, включая две версии одного и того же фрагмента кода с отметкой времени. Такое различие затем может быть использовано для поддержки реализации различных задач разработки программного обеспечения, таких как автоматическое создание сообщений о фиксации или поиск исправлений для определенных дефектов кода и т. д.

-→Репрезентативная работа: Рассел и др. [24] представили сообществу MSE прототип инструмента под названием AnDarwin для обнаружения семантически схожих приложений для Android. AnDarwin использует подход на основе кластеризации, при котором он пытается объединить похожие приложения в одну группу на основе семантической информации, извлеченной из кода приложений. Совсем недавно Li et al. [59, 65] разработали еще один прототип инструмента под названием SimiDroid, целью которого является выявление сходств в приложениях Android посредством статического анализа кода. Инструмент SimiDroid представляет собой универсальную платформу, которую можно легко расширить для поддержки многоуровневого сравнения приложений Android. Авторы продемонстрировали полезность SimiDroid, добившись эффективного анализа сходства приложений Android в трех сценариях (сравнение ресурсов, компонентов и методов).

(14) [Проверка кода] Анализ происхождения приложения. Из-за быстрого развития структуры ОС, а также необходимости исправлять ошибки или добавлять новые функции, мобильные приложения постоянно обновляются их разработчиками (часто через магазины приложений). Такие обновления приведут к серии выпусков одного и того же приложения, которые в сообществе называются линиями приложений. Поскольку эти линии приложений фиксируют все изменения в приложениях, наши коллеги-исследователи предложили изучить их[11], чтобы узнать, почему обновляются мобильные приложения. Аналогичные подходы можно применить и к OpenHarmony, например, для сбора знаний по обновлению (или исправлению) существующих приложений.

-→Репрезентативная работа: Гао и др. [37] представляют экспериментальное исследование эволюции уязвимостей приложений Android. Сначала они определяют термин «линия приложения» (т. е. серию исторических версий данного приложения). Затем они собирают набор данных о родословных приложений и впоследствии используют его для понимания эволюции уязвимостей, анализируя обновления между двумя последовательными версиями приложения. Их эмпирическое исследование выявило различные интересные результаты. Авторы также проводят еще одну работу по изучению происхождения приложений для понимания эволюции сложностей приложений для Android [36]. Их экспериментальные результаты показывают противоречивый вывод: разработчики приложений могут не знать, как контролировать сложность своих приложений.

(15) [Просмотр кода] Автоматическое восстановление программы. Автоматизированное восстановление программ (APR) уже много лет является горячей темой в сообществе разработчиков программного обеспечения. Идея APR заключается в том, чтобы компьютеры автоматически создавали исправления на уровне исходного кода для устранения ошибок и уязвимостей. Наши коллеги-исследователи также пытались изобрести методы автоматического восстановления мобильных приложений. Мы считаем, что такие методы следует изучить и для приложений OpenHarmony.

-→Репрезентативная работа: Marginean et al. [77] представляют отраслевой инструмент под названием SapFix, который обеспечивает комплексное устранение ошибок, от разработки тестовых сценариев до развернутого исправления в производственном коде. SapFix достигает своей цели путем объединения ряда различных методов, включая тестирование мутаций, тестирование программного обеспечения на основе поиска и локализацию ошибок. Чжао и др. [120] представили сообществу еще один прототип инструмента под названием RepairDroid, целью которого является автоматическое устранение проблем совместимости непосредственно в опубликованных приложениях Android (на уровне байт-кода). Для обеспечения гибкого восстановления авторы ввели общий язык описания исправлений приложений, который позволяет пользователям создавать шаблоны исправлений с использованием IR-кода.

(16) [Проверка кода] Межъязыковый статический анализ. Мобильные приложения не всегда пишутся на одном языке программирования. Действительно, существуют различные приложения, реализованные на нескольких языках. Например, модуль, требующий высокой производительности в приложениях Android, может быть написан на C или C++, тогда как основная часть по-прежнему написана на Java, который является языком по умолчанию для реализации приложений Android. Другой пример: для таких приложений Android, которые используют веб-компоненты, некоторые функции могут быть написаны на Javascript, чтобы дополнять основные функции, написанные на Java. Мы утверждаем, что для правильного анализа этих приложений, использующих несколько языков программирования, необходимо провести межъязыковой статический анализ, для которого анализ потока данных должен переносить переменные с одного языка на другой.

-→Репрезентативная работа: Wei et al. [106] и Чжоу и др. [125] демонстрируют, что важно поддерживать межъязыковый статический анализ для проверки безопасности приложений Android. Для этого Самхи и др. [92] представляют сообществу прототип инструмента под названием Jucify, целью которого является унификация кода Android (между Java и C/C++) для поддержки статического анализа. Их работа позволяет построить подробный граф вызовов для всех методов, написанных в приложении, независимо от того, написаны ли они на Java или C/C++. Сюэ и др. [111] также изобрели прототип инструмента под названием NDroid для отслеживания потоков информации в различных контекстах Android, включая анализ собственного кода в приложениях Android [126].

(17) [Проверка кода] Гибридный анализ. Как обсуждалось ранее, наши коллеги-исследователи постоянно применяют методы тестирования (также известные как динамический анализ) и статического анализа для анализа мобильных приложений. Однако известно, что оба этих двух метода имеют недостатки: например, подходы к тестированию страдают от проблем покрытия кода, которые в конечном итоге приводят к ложноотрицательным результатам, в то время как известно, что статический анализ, вероятно, дает ложноположительные результаты. Чтобы смягчить это, наши коллеги-исследователи предложили объединить эти два подхода для проведения так называемого гибридного анализа мобильных приложений. Мы считаем, что существует также необходимость изобрести гибридные подходы для анализа приложений OpenHarmony.

-→Репрезентативная работа: Wang et al. [103] представляют автоматизированный гибридный анализ вредоносного ПО для Android путем дополнения фаззинга принудительным выполнением. Они предлагают подход под названием DirectDroid, целью которого является инициирование скрытого вредоносного поведения путем обхода некоторых связанных проверок при использовании фаззинга для подачи необходимых входных данных программы. Шпрейценбарт и др. [? ] разработали еще один гибридный подход к анализу под названием Mobile-Sandbox, в котором статический анализ используется для достижения более высокого покрытия кода во время динамического анализа (т. е. тестирования приложений).

(18) [Просмотр кода] Машинное/глубокое обучение. Машинное обучение стало одним из самых популярных методов, который часто используют наши коллеги-исследователи для проверки логического кода приложений. Действительно, много исследовательских усилий тратится на то, чтобы найти лучший набор функций, который мог бы точно отражать поведение приложения. Такой набор функций затем используется для поддержки двух типов подходов машинного обучения: обучения с учителем и обучения без учителя. Обучение с учителем требует знания меток набора обучающих данных, например, важно собрать набор известных вредоносных программ, чтобы обучить предиктор вредоносных программ. Напротив, для обучения без учителя не обязательно знать метки набора данных. Этот тип подхода часто используется для объединения похожих выборок в одну группу. Когда речь идет о глубоком обучении, разработка функций больше не требуется.

-→Репрезентативная работа: Лю и др. [75] недавно провели систематический обзор литературы о подходах глубокого обучения, применяемых для защиты от вредоносного ПО Android. Авторы проанализировали статьи, опубликованные с 2014 по 2021 год, и обнаружили 132 тесно связанных между собой статьи. Авторы обнаружили, что статический анализ является наиболее используемым методом получения функций из приложений Android, и существует 13 работ, в которых классификация вредоносных программ достигается путем прямого кодирования необработанного байт-кода приложений Android в векторы функций. Машинное обучение применяется не только для анализа вредоносного ПО, но и для решения других задач разработки программного обеспечения. Например, Растофер и др. [89] представили сообществу основанный на машинном обучении подход к классификации и категоризации источников и приемников в Android, который затем можно использовать для поддержки анализа вредоносных данных приложений Android с целью обнаружения утечек конфиденциальности.

(19) Обфускация кода [развертывания]. Из-за особенностей мобильных устройств перед установкой на них необходимо загружать мобильные приложения. Это, к сожалению, дает злоумышленникам возможность прямого доступа к мобильным приложениям. Хуже того, злоумышленники могут получить прямой доступ к реализации кода приложений, если применить методы обратного проектирования. Чтобы злоумышленники не могли легко понять код, сообщество MSE приняло практику выполнения обфускации кода перед сборкой кода приложения в релизную версию. Поскольку приложения OpenHarmony необходимо устанавливать на устройства пользователей, также важно изобрести методы обфускации кода, чтобы предотвратить использование приложений OpenHarmony злоумышленниками.

-→Репрезентативная работа: Аонзо и др. [6] разработали инструмент «черного ящика» с открытым исходным кодом для приложений Android. Авторы назвали свой подход Obfuscapk и разработали модульную архитектуру, которую пользователи могут легко расширять для поддержки реализации новых стратегий запутывания. Донг и др. [29] провели крупномасштабное эмпирическое исследование методов обфускации Android в надежде лучше понять ее использование. Авторы специально изучили четыре популярных подхода к обфускации: переименование идентификаторов, шифрование строк, отражение Java и упаковку, что привело к различным выводам, которые могут помочь разработчикам выбрать наиболее подходящий подход к обфускации.

(20) [Развертывание] Усиление защиты приложений. Обфускация кода — это полезный метод, который не позволяет злоумышленникам легко понять код. Тем не менее, невозможно предотвратить получение злоумышленниками кода. С помощью подходов деобфускации злоумышленники все же смогли понять детали реализации. Чтобы этого не произошло, сообщество MSE дополнительно представило сообществу так называемую технику усиления безопасности aWpp, цель которой - затруднить извлечение реализации кода из приложений (например, не дать инструментам реверс-инжиниринга дизассемблировать выпущенные приложения).< /п>

-→Репрезентативная работа: Расселло и др. [91] представляют сообществу MSE основанную на политиках структуру под названием FireDroid, которая обеспечивает соблюдение политик безопасности без изменения ОС Android или самих приложений. FireDroid включает в себя новый механизм для подключения, мониторинга и применения политик для любого процесса, порожденного материнским процессом Android Zygote. Благодаря этому FireDroid можно применять для блокировки уязвимостей ОС и приложений, повышая безопасность телефонов Android. Чжан и др. [119] провели первое систематическое исследование служб упаковки Android с целью понять основные методы, используемые современными службами упаковки, и их влияние на приложения. Кроме того, они обнаруживают, что защита, обеспечиваемая этими службами упаковки, ненадежна, т. е. Dex можно восстановить. Чтобы продемонстрировать это, авторы разработали и внедрили прототип инструмента под названием DexHunter для извлечения файлов Dex из упакованных приложений Android. После этого Сюэ и др. [112–114] пошли дальше, чтобы добиться распаковки с помощью различных методов, например, аппаратного подхода, подхода на основе виртуальной машины и т. д.

5.1.1 Пробелы в исследованиях, связанных с инфраструктурой ОС. Как показано на рис. 1, инфраструктура ОС — это уровень, который связывает приложения с возможностями системы. Он предоставляет все необходимые возможности (включая все API, предлагаемые SDK) для поддержки приложений, работающих на мобильных устройствах. Поскольку эта часть тесно связана с приложениями, она также часто является темой, на которую обращают внимание наши исследователи SE. Теперь суммируем репрезентативные.

(20) [Статический] Эволюционный анализ. Подобно тому, что было сделано для мобильных приложений, наши коллеги-исследователи также предложили подходы к изучению эволюции инфраструктур ОС. Они показали, что понимание эволюции структуры может предоставить полезную информацию мобильному сообществу. Однако, в отличие от мобильных приложений, исследования, связанные с развитием платформы ОС, в основном основаны на исходном коде, поскольку платформа (в основном платформа Android) имеет открытый исходный код. Поскольку фреймворк OpenHarmony также имеет открытый исходный код, подобные методы, применяемые для изучения эволюции фреймворка Android, могут быть применены и к OpenHarmony.

-→Репрезентативная работа: Ли и др. [66] предложили изучить эволюцию платформы Android, чтобы охарактеризовать устаревшие API. Их эмпирическое исследование выявило различные интересные результаты, включая несогласованность реализации API, его комментариев и аннотаций. Они также обнаружили, что платформа Android включает в себя множество недоступных API, которые не предназначены для вызова клиентскими приложениями, но к которым фактически осуществляется доступ на практике [61]. Как утверждают Лю и др. [71], изучая эволюцию API-интерфейсов Android, мы могли обнаружить незаметно развивающиеся API, которые в конечном итоге могут привести к необнаружимым проблемам совместимости [101], поскольку реализация API обновляется в ходе эволюции, а комментарий к нему остается прежним.

(21) [Статический] Анализ разрешений. Наше сообщество SE приложило немало исследовательских усилий, чтобы понять систему разрешений Android, которая считается основным механизмом обеспечения безопасности приложений и системы. В идеале приложения должны декларировать разрешение, необходимое им для правильной работы на определенных мобильных устройствах. Однако нет четкого определения разрешений на использование API, предоставляемых разработчикам приложений. В результате разработчики приложений часто заявляют больше разрешений, чем действительно необходимо приложениям, что приводит к расширению поверхности атаки. Поэтому наши коллеги-исследователи предложили проанализировать код платформы, чтобы построить такое сопоставление и впоследствии поддержать более детальный анализ разрешений. Поскольку OpenHarmony также включает в себя систему разрешений для обеспечения безопасности приложений, аналогичные недостатки, связанные с разрешениями, которые были обнаружены в Android, также могут возникнуть в OpenHarmony. Следовательно, существует острая необходимость провести аналогичное исследование, чтобы обеспечить правильное использование разрешений в OpenHarmony.

-→Репрезентативная работа: Au et al. [8] представляют сообществу прототип инструмента под названием PScout, который автоматически извлекает спецификацию разрешений из исходного кода ОС Android (т. е. более миллиона строк кода) с помощью статического анализа. Их подход позволил решить несколько проблем, в том числе проблему, связанную с обеспечением соблюдения разрешений из-за использования Android IPC и разнообразных механизмов проверки разрешений Android. Бартель и др. [13] провели аналогичное исследование, используя статический анализ для извлечения проверок разрешений из платформы Android. Их подход разработан с учетом поля и использует расширенную стратегию анализа иерархии классов и использует новые оптимизации для конкретной предметной области, предназначенные для Android.

(22) [Статические] Обеспечение контроля доступа. Безопасность — это не только самая большая проблема мобильных приложений, но и одна из самых больших проблем со стороны ОС. Чтобы обеспечить безопасность системы, структура ОС часто полагается на механизмы контроля доступа для достижения этой цели. Однако такие механизмы контроля доступа могут быть обойдены вредоносным ПО для выполнения несанкционированных операций, чувствительных к безопасности. Следовательно, необходимо обеспечить правильное применение функции контроля доступа.

-→Репрезентативная работа: Чжоу и др. [124] представили сообществу прототип инструмента под названием IAceFinder, целью которого является извлечение и сопоставление контроля доступа, реализованного в Java и собственном контексте Android, а затем обнаружение межконтекстных несоответствий в качестве основного средства предотвращения использования функций контроля доступа. обходят. Авторы применили свой подход к анализу 14 платформ ОС Android с открытым исходным кодом (т. е. ПЗУ), на основе чего они смогли выявить 23 несоответствия, которые могут быть использованы злоумышленниками для компрометации устройства.

(23) [Статическая] Настройка платформы. Из-за открытости Android и необходимости обеспечения пользовательского опыта в зависимости от поставщика, платформа Android постоянно адаптируется поставщиками смартфонов. Например, Xiaomi сделала это и назвала кастомизированную версию MIUI. Аналогичным образом, компания Huawei выпустила EMUI, чтобы обеспечить более персонализированный пользовательский интерфейс при использовании телефонов Huawei. К сожалению, такой широкий спектр настроек создал для сообщества серьезные проблемы с совместимостью, что затрудняет разработчикам приложений реализацию приложения, совместимого со всеми доступными мобильными устройствами. Поэтому наши исследователи SE предложили подходы к выявлению различий между настроенными платформами, чтобы смягчить проблемы совместимости в мобильном сообществе. Будучи системой с открытым исходным кодом, OpenHarmony может столкнуться с аналогичными проблемами. Следовательно, также необходимо потратить исследовательские усилия на контроль настройки и тем самым предотвратить возникновение подобных проблем в OpenHarmony.

-→Репрезентативная работа: Лю и др. [70] провели эмпирическое исследование, чтобы понять, идут ли кастомизированные платформы Android в ногу с официальным Android. Они изучили эволюцию восьми нижестоящих фреймворков (например, AOKP, AOSPA, LineageOS, SlimROM и т. д.) и обнаружили различные интересные результаты (например, нижестоящие проекты выполняют операции слияния только для небольшой части всех выпусков версий в восходящем потоке). проекта, а большинству последующих проектов требуется более 20 дней, чтобы внести изменения в соответствующие вышестоящие проекты). Далее авторы рассматривают различия между настроенными платформами (в том числе модифицированными популярными техническими компаниями, такими как Xiaomi и Huawei) и обнаруживают, что эта настройка привела к серьезным проблемам совместимости (также известным как проблема фрагментации) в сообществе Android [ 73]. Этот результат убедительно свидетельствует о том, что необходимы дополнительные усилия для обеспечения правильной обработки и управления настройкой платформы.

(24) [Динамический] инструментарий выполнения. Поскольку невозможно решить все проблемы статически, исследователи также изучили возможность динамического анализа структуры, например, для контроля выполнения структуры. Одна из показательных работ — инструментирование инфраструктуры для добавления методов-перехватчиков к интересующим функциям. Во время выполнения такие методы-перехватчики при выполнении предоставляют информацию о среде выполнения, которая, как было продемонстрировано, полезна для понимания поведения платформы, а также приложений, работающих на ней. Такая полезная методика также должна быть предоставлена сообществу OpenHarmony, чтобы обеспечить возможность реализации многих передовых подходов к анализу фреймворков/приложений.

-→Репрезентативная работа. Одним из самых известных подходов к инструментированию среды выполнения в Android является платформа Xposed, которая позволяет разработчикам устанавливать небольшие программы (называемые модулями) на устройства Android, чтобы настроить их внешний вид и функциональность. Что касается исследований, Costamagna et al. [23] представляют аналогичный подход под названием ARTDroid, который поддерживает перехват виртуальных методов во время выполнения Android ART. Другой пример: наиболее репрезентативная работа, связанная с инструментированием среды выполнения, предложена Энком и др. [32], которые представили сообществу MSE один из первых подходов к инструментированию среды выполнения в Android. Они внедрили систему отслеживания информации под названием TaintDroid, целью которой является мониторинг конфиденциальности на смартфонах в режиме реального времени. Инструментарий времени выполнения TaintDroid активируется за счет использования виртуализированной среды выполнения Android.

5.2 Пробелы в исследованиях, связанных с экосистемами

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

(24) Проверка целостности [App Store]. Магазин приложений стал пробным камнем современной жизни и проник во многие уникальные платформы. Самыми известными магазинами приложений являются магазин Google Play и Apple Store, которые созданы для облегчения поиска, покупки, установки и управления приложениями Android и iOS для пользователей телефонов Android и iPhone соответственно. Эти магазины приложений по сути образуют центральный репозиторий, в котором записан большой список доступных приложений и их метаданных, что считается полезным, помогая пользователям обнаружить приложение и впоследствии решить, покупать его или нет. Чтобы поддерживать здоровье экосистемы, специалисты по обслуживанию магазинов приложений часто создают систему проверки для фильтрации некачественных приложений (например, приложений, содержащих уязвимости или проблем совместимости) с доступом в магазин. Здесь метаданные часто содержат два типа информации: (1) те, которые предоставлены авторами приложения, такие как имя и описание приложения, и (2) те, которые собираются платформой, такие как рейтинг пользователей приложения и т. д. В этом разделе, поскольку анализ приложений уже хорошо обсуждался, мы сосредоточимся только на метаданных и докажем, что приложение и его метаданные должны быть согласованными. В противном случае это существенно повлияет на опыт использования приложения, и это негативное чувство может в дальнейшем распространиться на опыт использования магазина приложений.

-→Репрезентативные работы: Горла и др. [43] предложили сверить поведение приложения с его описаниями, поскольку они считают, что нет никакой гарантии, что код приложения делает то, что заявлено, при загрузке в магазин приложений. Их экспериментальные результаты на наборе из более чем 22 500 приложений для Android показывают, что такое несоответствие действительно существует в сообществе, подтверждая гипотезу о том, что магазин приложений еще не выполняет проверки согласованности во время загрузки приложений. Другой тесно связанный пример - это пример, предложенный Ху и др. ?? которые знакомят сообщество с новым типом атаки под названием «сквоттинг мобильных приложений». При «сквоттинге приложений» злоумышленники выпускают приложения (в магазинах приложений) с идентификаторами (например, названием приложения или названием пакета), которые до степени смешения похожи на идентификаторы популярных приложений или известных интернет-брендов. С помощью таких уловок злоумышленники надеются, что их приложения выберут пользователи приложений, которые не собираются их использовать. Всех вышеупомянутых проблем можно было бы избежать, если бы магазины приложений проводили тщательные проверки согласованности.

(25) Проверка соответствия [App Store]. Помимо проверок согласованности, необходимо также выполнять проверки соответствия, прежде чем разрешить отправку мобильных приложений в магазины приложений. Существуют различные политики, которым должны следовать мобильные приложения. К таким политикам относятся политики, разработанные правительством (например, Общий регламент по защите данных (GDPR) Европейского Союза), самим магазином приложений (например, политики в отношении спама и минимальной функциональности Google Play), а также политики, созданные определенными библиотеками (политики в отношении контента и политики поведения AdMob и AdSense). Эти проверки соответствия также следует проводить для проверки приложений OpenHarmony, и, следовательно, необходимы целенаправленные усилия для реализации таких подходов.

-→Репрезентативные работы: Fan et al. [33] провели исследование с целью изучения нарушений соответствия GDPR в приложениях Android eHealth. Их экспериментальное исследование показывает, что подобные нарушения (включая неполноту политики конфиденциальности, непоследовательность сбора данных и небезопасность передачи данных) действительно широко представлены в сообществе Android. Чжао и др. [123] провели исследование, чтобы проверить, соответствует ли мобильная реклама возрастной группе приложения. Донг и др. [28] провели предварительное исследование, чтобы понять, как мобильные приложения нарушают поведенческую политику, установленную библиотеками рекламы. Все вышеупомянутые работы подтвердили, что в современном мобильном сообществе существует множество нарушений нормативных требований, которые в конечном итоге приводят к ухудшению пользовательского опыта. Поэтому, чтобы избежать этого, мы утверждаем, что магазин приложений OpenHarmony должен поддерживать проверки соответствия, чтобы ограничить возникновение таких нарушений соответствия.

(26) [Обзор приложения] Человеческие ценности. Мобильные приложения по существу разрабатываются для пользователей, и необходимо учитывать взаимосвязь между человеческими ценностями и разработкой и внедрением мобильных приложений. Действительно, было продемонстрировано, что нарушение мобильных приложений (или технологий в целом) человеческих ценностей, таких как конфиденциальность, справедливость, порядочность, любопытство, честность или социальная справедливость, приведет к значительным негативным последствиям. Если такие нарушения можно будет выявить раньше, разработчики смогут лучше их устранить и тем самым смягчить их последствия (например, до того, как приложения будут выпущены для пользователей). Поскольку человеческие ценности также должны быть «первым гражданином» в OpenHarmony, такие подходы к обнаружению нарушений также должны поддерживаться.

-→Репрезентативные работы: Оби и др. [82] представили сообществу MSE первое исследование о нарушении человеческих ценностей в обзорах приложений, оставленных реальными пользователями приложений. Из 22 119 обзоров приложений, собранных в магазине Google Play, авторы обнаружили, что 26,5% обзоров содержали текст, указывающий на предполагаемые пользователем нарушения человеческих ценностей, при этом доброжелательность и самоуправление являются наиболее нарушаемыми ценностными категориями. Оби и др. ?? далее сделаем еще один шаг глубже, чтобы изучить нарушения честности в мобильных приложениях и впоследствии предложить подходы к их автоматическому обнаружению. Их исследование показывает, что нарушение честности является довольно распространенным явлением, и к основным категориям нарушений относятся несправедливые правила отмены и возврата средств, ложная реклама, обманные подписки, системы мошенничества и т. д. Эти подходы подчеркивают необходимость активных подходов, принимаемых сообществом для лучшего внедрения человеческих ценностей в OpenHarmony. приложения.

(27) [Другое] Анализ черного рынка. В условиях быстрого роста мобильной экосистемы злоумышленники пытались изучить различные способы получения нелегальной прибыли (например, с помощью некоторых скрытых вредоносных действий). Например, злоумышленники пытались получить прибыль, внедряя рекламу в безопасные приложения или отправляя SMS-сообщения на платные номера. Другие пытались собрать личную информацию пользователей (используя отдельные устройства или накапливая информацию с нескольких устройств) и впоследствии продать ее третьим лицам для поддержки других вредоносных действий. Вышеупомянутые виды деятельности наши коллеги-исследователи называют черным рынком, которые приложили много усилий, чтобы понять и впоследствии защититься от них в мобильной экосистеме. К сожалению, пока есть возможности для получения прибыли, будут злоумышленники, которые будут ею пользоваться. Это относится и к OpenHarmony. Поэтому мы утверждаем, что существует острая необходимость смягчить последствия черного рынка OpenHarmony, и приглашаем наших коллег-исследователей совместно изучить это важное направление исследований.

-→Репрезентативные работы: Гао и др. [38] провели предварительное исследование, чтобы демистифицировать нелегальные мобильные азартные приложения, которые стали одним из самых популярных и прибыльных подпольных предприятий. Их исследование показывает, что, чтобы обойти строгие правила как со стороны государственных органов, так и со стороны рынков приложений, коварные авторы приложений разработали ряд скрытых каналов для распространения своих приложений и злоупотребляли сторонними платежными сервисами для получения прибыли. Другой пример: Ху и др. [47] провели тщательное исследование, чтобы понять экосистему мошеннических приложений для знакомств, которые пытаются побудить пользователей покупать премиум-услуги, чтобы начать общение с другими (вероятно, фальшивыми женскими) учетными записями, то есть чат-ботами. Все подобные действия на черном рынке могут случиться и с сообществом OpenHarmony, поэтому необходимы специальные подходы, чтобы этого не допустить.

5.3 Новые возможности для исследований

• Подходы SE на основе LLM для OpenHarmony. Как указано в разделе 4, большинство исследований в области разработки мобильного программного обеспечения сосредоточено на этапе анализа. Существует лишь ограниченное количество исследований, посвященных этапам разработки приложений. Это имеет смысл, поскольку разработка приложений для Android уже была достаточно зрелой (с большой поддержкой со стороны Google и сообщества), когда наши коллеги-исследователи приступили к этой области. Однако это не относится к OpenHarmony. Действительно, OpenHarmony все еще находится на очень ранней стадии: разработано лишь небольшое количество приложений и ограниченное количество сторонних библиотек, доступных сообществу. Сообществу OpenHarmony будет чрезвычайно полезно, если будет предложено больше работ для облегчения разработки приложений OpenHarmony. Теперь, с быстрой разработкой больших языковых моделей (особенно ориентированных на разработку, таких как Copilot от Github), мы считаем, что сейчас это еще лучшая возможность поддержать это. LLM может помочь разработчикам быстро освоить базовые знания OpenHarmony, понять использование API, автоматически генерировать код (одну или несколько строк), создавать примеры модульного тестирования, рекомендовать варианты ремонта и т. д.

• Платформа Corss для поддержки OpenHarmony. Чтобы реализовать идею разработки однажды и запуска повсюду, сообщество MSE изобрело для поддержки так называемые кроссплатформенные платформы, такие как ReactNative и Flutter. Эти кроссплатформенные платформы сами по себе определили способ разработки универсального приложения. Например, в ReactNative кодовая база приложения обычно формируется с помощью Javascript. Эту базу кода затем можно скомпилировать как в собственное приложение для Android, так и в собственное приложение для iOS. Самое приятное в использовании межъязыковых платформ — это то, что обслуживание приложений также унифицировано. Независимо от того, исправляете ли вы ошибки или добавляете новые функции, это нужно сделать только один раз. Учитывая это большое преимущество, мы считаем, что для экосистемы OpenHarmony будет чрезвычайно полезно, если эти кроссплатформенные платформы смогут поддерживать OpenHarmony. В этом случае все существующие приложения, разработанные с помощью кросс-платформенных фреймворков, можно будет запускать непосредственно на устройствах OpenHarmony. Поэтому мы настоятельно рекомендуем нашим коллегам-исследователям рассмотреть возможность изучения этого направления исследований.

• Учитесь на Android/iOS. В этой работе мы обобщили множество подходов, связанных с Android/iOS, и считаем, что необходимо извлечь из них уроки, создавая специальные подходы для OpenHarmony. Хотя это, безусловно, правда, мы также считаем, что необходимо извлечь уроки из большого количества артефактов, накопленных в Android и iOS. Действительно, сообщество MSE накопило множество артефактов, в том числе миллионы реальных приложений, тысячи приложений с открытым исходным кодом, документацию, записи вопросов и ответов, отзывы пользователей и т. д. Несмотря на то, что они собраны с разных платформ, мы утверждаем, что эти артефакты могут быть полезны для поддержки реализации задач, связанных с OpenHarmony. Например, одна из возможностей — изучить направление автоматического преобразования приложений Android, написанных на Java (или приложений iOS, написанных на Swift), в приложения OpenHarmony, написанные на ArkTS. В этой работе мы также приглашаем наших коллег-исследователей исследовать это направление, развивая экосистему OpenHarmony, стоя на плечах гигантов.

[11] Исследователям приходится сосредоточиваться на выпущенных версиях приложения, поскольку часто невозможно получить его исходный код.

:::информация Этот документ доступен на arxiv по лицензии CC 4.0.

:::

Оригинал

Разработка программного обеспечения для OpenHarmony: план исследований

Таблица ссылок

5 ПЛАН ИССЛЕДОВАНИЯ

5.1. Пробелы в исследованиях, связанных с приложениями

5.2 Пробелы в исследованиях, связанных с экосистемами

5.3 Новые возможности для исследований

Recent Post

RaspberryPi: технологическая перегрузка — от LAMP🕯 до UASP🐝

Что такое деобфускация Javascript? Все, что Вам нужно знать

Хранение паролей в базе данных: лучший способ сделать это

Вот что нужно знать об Apache Cassandra 5.0

Проектирование для безопасности: что вам нужно знать

Categories