Install Burp Certificate
На віртуальній машині
По-перше, вам потрібно завантажити сертифікат Der з Burp. Ви можете зробити це в Proxy --> Options --> Import / Export CA certificate
Експортуйте сертифікат у форматі Der і давайте перетворимо його в форму, яку Android зможе зрозуміти. Зверніть увагу, що для налаштування сертифіката burp на Android машині в AVD вам потрібно запустити цю машину з опцією -writable-system
.
Наприклад, ви можете запустити її так:
Тоді, щоб налаштувати сертифікат burp:
Як тільки машина завершить перезавантаження, сертифікат burp буде використовуватися!
Використання Magisc
Якщо ви рутнули свій пристрій за допомогою Magisc (можливо, емулятор), і ви не можете виконати попередні кроки для встановлення сертифіката Burp, оскільки файлова система є тільки для читання і ви не можете змонтувати її для запису, є інший спосіб.
Пояснено в цьому відео, вам потрібно:
Встановити сертифікат CA: Просто перетягніть DER сертифікат Burp, змінивши розширення на
.crt
на мобільному, щоб він зберігся в папці Завантаження, і перейдіть доВстановити сертифікат
->CA сертифікат
Перевірте, що сертифікат був правильно збережений, перейшовши до
Довірені облікові дані
->КОРИСТУВАЧ
Зробіть його системно довіреним: Завантажте модуль Magisc MagiskTrustUserCerts (файл .zip), перетягніть його на телефон, перейдіть до додатку Magics на телефоні в розділ
Модулі
, натиснітьВстановити з пам'яті
, виберіть модуль.zip
і після встановлення перезавантажте телефон:
Після перезавантаження перейдіть до
Довірені облікові дані
->СИСТЕМА
і перевірте, що сертифікат Postswigger там
Після Android 14
У останньому випуску Android 14 спостерігається значна зміна в обробці сертифікатів сертифікаційних органів (CA), яким довіряє система. Раніше ці сертифікати зберігалися в /system/etc/security/cacerts/
, доступні та змінювані користувачами з правами root, що дозволяло негайне застосування по всій системі. Однак з Android 14 місце зберігання було переміщено до /apex/com.android.conscrypt/cacerts
, каталогу в межах шляху /apex
, який за своєю природою є незмінним.
Спроби змонтувати шлях APEX cacerts як записуваний зазнають невдачі, оскільки система не дозволяє такі операції. Навіть спроби демонтувати або накласти каталог з тимчасовою файловою системою (tmpfs) не обходять незмінність; програми продовжують отримувати доступ до оригінальних даних сертифіката, незважаючи на зміни на рівні файлової системи. Ця стійкість зумовлена тим, що монтування /apex
налаштоване з PRIVATE пропагандою, що забезпечує, щоб будь-які зміни в каталозі /apex
не впливали на інші процеси.
Ініціалізація Android включає процес init
, який, запускаючи операційну систему, також ініціює процес Zygote. Цей процес відповідає за запуск процесів додатків з новим простором монтування, який включає приватне монтування /apex
, таким чином ізолюючи зміни в цьому каталозі від інших процесів.
Проте існує обхідний шлях для тих, хто потребує змінити сертифікати CA, яким довіряє система, у каталозі /apex
. Це передбачає ручне змонтування /apex
для видалення PRIVATE пропаганди, що робить його записуваним. Процес включає копіювання вмісту /apex/com.android.conscrypt
в інше місце, демонтаж каталогу /apex/com.android.conscrypt
для усунення обмеження на читання, а потім відновлення вмісту на їхнє первісне місце в межах /apex
. Цей підхід вимагає швидких дій, щоб уникнути збоїв системи. Щоб забезпечити системне застосування цих змін, рекомендується перезапустити system_server
, що ефективно перезапускає всі програми та повертає систему до узгодженого стану.
Bind-mounting through NSEnter
Налаштування записуваної директорії: Спочатку створюється записувана директорія шляхом монтування
tmpfs
над існуючою директорією системних сертифікатів, що не є APEX. Це досягається за допомогою наступної команди:
Підготовка CA сертифікатів: Після налаштування записуваного каталогу, CA сертифікати, які планується використовувати, слід скопіювати в цей каталог. Це може включати копіювання стандартних сертифікатів з
/apex/com.android.conscrypt/cacerts/
. Важливо відповідно налаштувати дозволи та мітки SELinux для цих сертифікатів.Прив'язка монтування для Zygote: Використовуючи
nsenter
, входять у простір імен монтування Zygote. Zygote, будучи процесом, відповідальним за запуск Android додатків, вимагає цього кроку, щоб забезпечити, що всі додатки, які будуть запущені надалі, використовують новонаконфігуровані CA сертифікати. Використовується команда:
Це забезпечує, що кожен новий додаток, який запускається, буде дотримуватися оновленої конфігурації CA сертифікатів.
Застосування змін до запущених додатків: Щоб застосувати зміни до вже запущених додатків, знову використовується
nsenter
, щоб увійти в простір імен кожного додатка окремо та виконати подібне зв'язування. Необхідна команда:
Альтернативний підхід - М'який перезавантаження: Альтернативний метод передбачає виконання прив'язки до процесу
init
(PID 1), після чого слідує м'яке перезавантаження операційної системи з командамиstop && start
. Цей підхід дозволить поширити зміни на всі простори імен, уникаючи необхідності окремо вирішувати питання з кожним запущеним додатком. Однак цей метод зазвичай менш бажаний через незручність перезавантаження.
Посилання
Last updated