Security hardening of Android native code — статья, рассказывающая, как защитить от реверса нативные библиотеки в приложениях для Android.
Обычно разработчики выносят сенситивный код в нативные, написанные на языках C/C++ библиотеки, чтобы повысить производительность и затруднить реверс приложения (читать дизассемблерные листинги нативного кода гораздо сложнее, чем код smali, и тем более сложнее, чем декомпилированный с помощью того же jadx код на Java). Однако не стоит забывать, что одно лишь наличие нативного кода не остановит опытного и мотивированного взломщика, поэтому стоит использовать дополнительные средства, чтобы его запутать. Есть несколько несложных способов это сделать.
Еще по теме: Защита приложения от отладки
Защита нативной библиотеки. Способ №1
Замена вызовов функций стандартной библиотеки языка С (libc, роль которой в Android играет Bionic) прямыми системными вызовами. Это позволит защититься от взломщиков, которые используют Frida для перехвата вызовов функций или подменяют библиотеку libc аналогом с функцией дампа всех вызовов и возвращаемых ими данных (например, какие файлы открывает приложение, какие порты слушает).
Применять системные вызовы напрямую довольно сложно, но можно воспользоваться наработками проекта MUSL с реализацией минималистичного варианта libc. Для этого достаточно взять из проекта файл syscall_arch.h и использовать определенный в нем набор функций __syscallX, где X — это число аргументов системного вызова. Реализованные с помощью этой функции системные вызовы open и read могут выглядеть так:
|
1 2 3 4 5 6 7 |
static inline int my_openat(int __dir_fd, const void* __path, int __flags, int __mode ){ return (int)__syscall4(__NR_openat, __dir_fd, (long)__path, __flags, __mode); } static inline ssize_t my_read(int __fd, void* __buf, size_t __count){ return __syscall3(__NR_read, __fd, (long)__buf, (long)__count); } |
Обрати внимание: благодаря ключевому слову inline код этих функций будет встроен в вызывающий код, что еще больше усложнит его анализ.
Защита нативной библиотеки. Способ №2
Замена функции libc на собственные реализации. Кроме функций — оберток системных вызовов, библиотека libc также включает в себя множество подсобных функций, в том числе для работы со строками (strcmp, strlen, strstr) и памятью (memcmp, memset, memcpy). Эти функции также лучше встроить прямо в код библиотеки. Взять их реализацию можно из той же библиотеки MUSL или Glibc.
Защита нативной библиотеки. Способ №3
Обфускация с помощью Obfuscator-LLVM. Этот форк известного набора компиляторов LLVM выполняет преобразования кода (запутывание графа исполнения, замена инструкций, мертвые инструкции, тупиковые переходы и так далее), затрудняющие его анализ. Чтобы заставить среду разработки собрать библиотеку с использованием O-LLVM, необходимо внести соответствующие правки в CMakeLists.txt, указав путь до O-LLVM (первая переменная):
|
1 2 3 4 5 6 7 8 9 10 |
set(OLLVM_PATH ${CMAKE_HOME_DIRECTORY}/../../../../../build/bin) set(OLLVM_C_COMPILER ${OLLVM_PATH}/clang) set(OLLVM_CXX_COMPILER ${OLLVM_PATH}/clang++) set(OLLVM_C_FLAGS "-mllvm -sub -mllvm -bcf -mllvm -fla") set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OLLVM_C_FLAGS}") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OLLVM_C_FLAGS}") set(CMAKE_C_COMPILER ${OLLVM_C_COMPILER}) set(CMAKE_CXX_COMPILER ${OLLVM_CXX_COMPILER}) |
Размер результирующей библиотеки при этом может возрасти в десять раз благодаря внедрению больших объемов неиспользуемого кода и запутыванию графа исполнения.
Еще по теме: Лучшие программы для реверс-инжиниринга
А что Android — это что-то DOS-а получается. У современных процессоров есть режим ядра для ОС, закрытый от пользователя, в который извне не попадешь, если не захочет хозяин пк. Если народ не хочет думать, как безопасно работать, разве это проблема разработчика. вы же не сядите за руль, не уменя водить машину и не зная правила дорожного движения.