269
Android: хакинг, кодинг и прочая жесть @ezobnin
Мини-карта кода в стиле Sublime для vim. https://github.com/severin-lemaignan/vim-minimap
Читать полностью…
SpyDealer: Android Trojan Spying on More Than 40 Apps (https://researchcenter.paloaltonetworks.com/2017/07/unit42-spydealer-android-trojan-spying-40-apps/) - результаты исследования трояна SpyDealer, который способен красть данные 40 различных приложений (включая Facebook, WhatsApp, Skype, Line, Viber, Telegram и Firefox). Наиболее интересные моменты:
* Для получения данных приложения троян использует сразу несколько техник, включая root доступ (для получения которого используется инструмент Baidu Easy Root) и Android Accessibility Service;
* Троян умеет скрытно отвечать на звонки с заданного номера, позволяя таким образом подслушивать разговоры просто позвонив на телефон жертвы;
* Умеет записывать звонки, делать снимки и видеозаписи фронтальной и задней камерами, отслеживать перемещения устройства, снимать скриншоты;
* Копирует себя в системный каталог чтобы избежать удаления;
* Получает команды от удаленного сервера сразу тремя способами: слушая команды на портах TCP и UDP, самостоятельно подключаясь к удаленному серверу, или через SMS;
* Троян реализует свой собственный протокол поверх UDP, который разбивает данные на небольшие блоки и отправляет каждый из них по три раза. Сервер собирает их воедино следуя специальным заголовкам в начале каждого блока;
* Для сбора данных из сторонних приложений SpyDealer использует нативное приложение dealapp, работающее с правами root. Оно напрямую читает файл базы данных приложения;
* Для извлечения данных из приложений, использующих шифрование, троян полагается на Accessibility Service, с помощью которого незаметно копирует строки прямо из открытого окна приложения;
* Эффективно работает только на Android версий 2.2-4.4. На более поздних версиях может унести массу информации, но не может получить права root, дающие доступ к данным сторонних приложений.
Seccomp filter in Android O (https://android-developers.googleblog.com/2017/07/seccomp-filter-in-android-o.html) - еще один пост разработчиков Android. На этот раз о новом общесистемном фильтре seccomp в Android O.
Seccomp - это технология ядра Linux, которая позволяет ограничить список доступных приложению (и в перспективе опасных) системных вызовов. Например, используя seccomp можно запретить приложению использовать системный вызов execve, который часто используют эксплойты, или заблокировать системный вызов listen, с помощью которого можно повесить на сетевой порт бекдор.
Технология используется в Android уже достаточно давно, но применяется в основном к системным компонентам. Теперь разработчики решили внедрить seccomp-фильтр в zygote, процесс, который порождает процессы всех установленных в систему приложений.
Они проанализировали какие системные вызовы нужны для загрузки ОС и работы большинства приложений, а затем отсекли лишние. В итоге в черный список попали 17 из 271 системных вызовов на arm64 и 70 из 364 на arm. В списке оказался и системный вызов для подключения swap-раздела, так что возможно в Android O приложения для активации свопа не заведутся.
Shut the HAL Up (https://android-developers.googleblog.com/2017/07/shut-hal-up.html) - пост разработчиков Android об инициативе Treble, которая заключается в разделении Android на два независимых части, одна из которых обеспечивает связь с железом (ядро Linux, драйверы и другие низкоруровневые компоненты ОС), а другая как раз и представляет собой операционную систему Android.
Я уже писал (https://xakep.ru/2017/06/07/treble-android-upadtes/) о Treble как решении проблемы обновлений и фрагментации Android. Однако разработчики Android завяляют, что Treble также способен решить многие проблемы безопасности. Все дело в том, что в рамках Treble планируется не только разделить ОС на две части, но и реаргонизовать сами низкоуровневые компоненты ОС, каждый из которых теперь будет работат в жестко изолированной песочнице и общаться с компонентами ОС через типизированные каналы с проверкой полномочий (для этого внесены соответствующие правки в IPC Binder).
Отчет о результатах анализа операционной системы Tizen с помощью статического анализатора PVS-Studio. Автор проанализировал 3.3% кода Tizen и нашел в нем 900 серьезных ошибок. Умножив 900 на 30 он пришел к выводу, что в результате анализа всего исходного кода, с помощью PVS-Studio удастся найти не менее 27 000 ошибок.
Наиболее интересные фрагменты кода:
* Ошибка сравнения:
return m_len < m_len;
* Забытый унарный оператор (должно быть *focus_unit):
int *focus_unit = (int *)data;
if (focus_unit == NULL || focus_unit < 0) {
...
}
* Небрежное использование функции аллокации памяти в цикле:
while (1) {
char *buffer = alloca(size);
...
}
* Неправильное использование функции memset (в данном случае длина типа данных gboolean - 4 байта, а memset оперирует байтами):
static gboolean req_id_used[BT_REQUEST_ID_RANGE_MAX];
...
memset(req_id_used, 0x00, BT_REQUEST_ID_RANGE_MAX);
* Повторное присовение значений:
_focused_ic = context_scim;
_focused_ic = old_focused;
* Идентичные действия:
if (mouse_info.pressed == false) {
return ECORE_CALLBACK_RENEW;
}
return ECORE_CALLBACK_RENEW;
* А также: разыменование NULL-указателей, проверки условий, которые всегда возвращают true/false, некорректное использование printf(), ошибки выделения/освобождения памяти, использование неинициализированных переменных, переполнения буфера, утечки памяти, бесмысленная проверка возвращаемого с помощью new объекта на NULL, запись в read-only память и множество других глупых ошибок.
https://www.viva64.com/en/b/0519/
Exploring Easter functions in Kotlin (https://android.jlelse.eu/easter-functions-in-kotlin-ab5e9b8b7ce6) - краткий рассказ об функциях Kotlin, облегчающих разработку:
* let - функция-расширение всех объектов Kotlin, позволяет ограничить область видимости или выполнить код только в том случае, если объект не равен null:
person?.let {
it.name = "Tony Stark"
}
* with - позволяет выполнить код в контексте объекта:
val person = with(Person()) {
name = "Tony Stark"
age = 52
this
}
* apply - более удобный в использовании аналог with:
val person = Person().apply {
name = "Tony Stark"
age = 52
}
* also - аналог apply, внутри которого можно использовать ключевое слово it:
val person = Person().also {
it.name = "Tony Stark"
it.age = 52
}
* use - своего рода аналог try в Java:
FileReader("input.txt").use {
// Read the file
}
* run - похожая на with, let и apply функция, позволяющая вернуть значение;
* takeIf - функция для фильтрации:
val index = "Kotlin".indexOf('K').takeIf { it > 0 } ?: 0
* takeUnless - противоположность takeIf:
val index = "Kotlin".indexOf('K').takeUnless { it < 0 } ?: 0
* measureTimeMillis - позволяет измерить скорость выполнения блока кода:
val executionTime = measureTimeMillis {
// Do your task
}
println("Execution Time = $executionTime ms")
Kotlin's hidden costs - Benchmarks (https://sites.google.com/a/athaydes.com/renato-athaydes/posts/kotlinshiddencosts-benchmarks) - сравнение производительности приложения при использовании схожих языковых конструкций в Kotlin и Java. Статья проверяет выводы, сделанные автором серии статей "Kotlin's hidden costs". Результат:
1. Лямбды Kotlin быстрее своего аналога в Java 8 на 30% (вне зависимости от использования ключевого слова inline);
2. Объекты-компаньоны (companion object) не создают никакого оверхеда, а доступ к ним происходит даже быстрее, чем к статическим полям и методам в Java;
3. Вложенные функции не создают оверхеда, они даже немного быстрее обычных;
4. Повсеместные проверки на null не создают оверхеда, код получается более быстрый, чем код на Java;
5. Передача массива как аргумента функции, ожидающей неопределенное число аргументов (vararg) действительно замедляет исполнение кода в два раза;
6. Делегаты работают на 10% медленней своей наиболее эффективной эмуляции на языке Java;
7. Скорость прохода по диапазону (range) не зависит от того, вынесен он в отдельную переменную или нет;
8. Вынесенный в константу range всего на 3% быстрее аналога в коде;
9. Конструкция for (it in 1..10) { ... } в три раза быстрее конструкции (1..10).forEach { ... }.
BootStomp: On the Security of Bootloaders in Mobile Devices (http://cs.ucsb.edu/~yanick/publications/2017_sec_bootstomp.pdf) - большое исследование безопасности загрузчиков смартфонов, в ходе которого было найдено 5 ранее неизвестных уязвимостей. Документ включает в себя массу интересной информации, о которой стоит знать любому, кто так или иначе связан с IT Security:
* Приниципы работы Trusted Execution Environment (TEE) в современных смартфонах;
* Понятие ARM Exception Levels, определяющее контекст исполнения кода (от наименее привилегированного EL1 до EL3, в котором работают начальный загрузчик и операционная система TEE);
* Отличия современных загрузчиков смартфонов от традиционных загрузчиков в ПК;
* Принипы реализации Trusted Boot в загрузчиках и Android;
* Реализация механизма разблокирования загрузчика;
* Сравнение загрузчиков Qualcomm, HiSilicon (Huawei), MediaTek и NVIDIA (загрузчики HiSilicon и MediaTek очень толсты, работают с максимальными привилегиями и включают в себя массу кода, который обычно располагается в загрузчиках, прошитых в ROM).
How to reduce APK size in android (https://blog.mindorks.com/how-to-reduce-apk-size-in-android-2f3713d2d662) - описание способов сократить размер apk приложения. В целом советы очень простые:
* используй Proguard, он безжалостно избавляется от неиспользуемого кода и сокращает имена классов, методов и полей;
* настрой разделение apk для разных версий Android (к в передыдущей статье);
* прогоняй приложение через redex (https://github.com/facebook/redex);
* используй утилиту lint (https://developer.android.com/studio/write/lint.html#overview) чтобы избавиться от ненужных ресурсов;
* используй gradle-директиву shrinkResources для удаления неиспользуемых ресурсов;
* переходи на векторные иконки;
* удали любые библиотеки для отладки из финального приложения;
* замени изображения в форматах png и jpg на webp
* используй оптимизатор TinyPNG (https://tinypng.com/) или Optipng (http://optipng.sourceforge.net/) для сокращения размера png-изображений.