Install Burp Certificate
Na maszynie wirtualnej
Po pierwsze musisz pobrać certyfikat Der z Burp. Możesz to zrobić w Proxy --> Opcje --> Importuj / Eksportuj certyfikat CA
Eksportuj certyfikat w formacie Der i przekształć go w formę, którą Android będzie w stanie zrozumieć. Zauważ, że aby skonfigurować certyfikat burp na maszynie Android w AVD, musisz uruchomić tę maszynę z opcją -writable-system
.
Na przykład możesz ją uruchomić tak:
Następnie, aby skonfigurować certyfikat Burp, wykonaj:
Po zakończeniu ponownego uruchomienia urządzenia certyfikat Burp będzie używany przez nie!
Korzystanie z Magisc
Jeśli zrootowałeś swoje urządzenie za pomocą Magisc (być może emulatora) i nie możesz wykonać poprzednich kroków w celu zainstalowania certyfikatu Burp, ponieważ system plików jest tylko do odczytu i nie możesz go ponownie zamontować jako zapisywalny, istnieje inny sposób.
Wyjaśnione w tym filmie musisz:
Zainstaluj certyfikat CA: Po prostu przeciągnij i upuść certyfikat Burp w formacie DER, zmieniając rozszerzenie na
.crt
w telefonie komórkowym, aby był przechowywany w folderze Pobrane i przejdź doZainstaluj certyfikat
->Certyfikat CA
Sprawdź, czy certyfikat został poprawnie zapisany, przechodząc do
Zaufane poświadczenia
->UŻYTKOWNIK
Uczyń go zaufanym przez system: Pobierz moduł Magisc MagiskTrustUserCerts (plik .zip), przeciągnij i upuść go w telefonie, przejdź do aplikacji Magics w telefonie do sekcji
Moduły
, kliknij naZainstaluj z pamięci
, wybierz moduł.zip
i po zainstalowaniu ponownie uruchom telefon:
Po ponownym uruchomieniu przejdź do
Zaufane poświadczenia
->SYSTEM
i sprawdź, czy certyfikat Postswigger jest tam
Po Androidzie 14
W najnowszej wersji Androida 14 zaobserwowano znaczną zmianę w obsłudze certyfikatów urzędów certyfikacji (CA) zaufanych przez system. Wcześniej te certyfikaty były przechowywane w /system/etc/security/cacerts/
, dostępne i modyfikowalne przez użytkowników z uprawnieniami roota, co pozwalało na natychmiastowe zastosowanie ich w całym systemie. Jednak w Androidzie 14 lokalizacja przechowywania została przeniesiona do /apex/com.android.conscrypt/cacerts
, katalogu w ścieżce /apex
, który jest z natury niemutowalny.
Próby ponownego zamontowania ścieżki APEX cacerts jako zapisywalnej kończą się niepowodzeniem, ponieważ system nie zezwala na takie operacje. Nawet próby odmontowania lub nałożenia nakładki na katalog za pomocą tymczasowego systemu plików (tmpfs) nie omijają niemutowalności; aplikacje nadal uzyskują dostęp do oryginalnych danych certyfikatu bez względu na zmiany na poziomie systemu plików. Ta odporność wynika z konfiguracji montowania /apex
z propagacją PRIVATE, zapewniającą, że wszelkie modyfikacje w katalogu /apex
nie wpływają na inne procesy.
Inicjalizacja Androida polega na procesie init
, który po uruchomieniu systemu operacyjnego inicjuje również proces Zygote. Proces ten jest odpowiedzialny za uruchamianie procesów aplikacji w nowej przestrzeni montowania, która obejmuje prywatne montowanie /apex
, izolując zmiany w tym katalogu od innych procesów.
Mimo to istnieje obejście dla osób potrzebujących modyfikować certyfikaty CA zaufane przez system w katalogu /apex
. Polega to na ręcznym ponownym zamontowaniu /apex
, aby usunąć propagację PRIVATE, co czyni go zapisywalnym. Proces ten obejmuje skopiowanie zawartości /apex/com.android.conscrypt
do innego miejsca, odmontowanie katalogu /apex/com.android.conscrypt
w celu usunięcia ograniczenia tylko do odczytu, a następnie przywrócenie zawartości do ich pierwotnego miejsca w /apex
. Ten sposób postępowania wymaga szybkiej reakcji, aby uniknąć awarii systemu. Aby zapewnić systemowe zastosowanie tych zmian, zaleca się ponowne uruchomienie system_server
, co skutecznie restartuje wszystkie aplikacje i przywraca system do spójnego stanu.
Montowanie katalogu poprzez NSEnter
Konfiguracja katalogu z możliwością zapisu: W pierwszej kolejności, katalog z możliwością zapisu jest ustanawiany poprzez zamontowanie
tmpfs
nad istniejącym katalogiem certyfikatów systemowych non-APEX. Można to osiągnąć za pomocą poniższej komendy:
Przygotowanie certyfikatów CA: Po skonfigurowaniu katalogu z możliwością zapisu, certyfikaty CA, które zamierza się użyć, powinny zostać skopiowane do tego katalogu. Może to wymagać skopiowania domyślnych certyfikatów z
/apex/com.android.conscrypt/cacerts/
. Istotne jest odpowiednie dostosowanie uprawnień i etykiet SELinux tych certyfikatów.Bind Mounting dla Zygote: Korzystając z
nsenter
, wchodzi się do przestrzeni nazw montowania Zygote. Zygote, będąc procesem odpowiedzialnym za uruchamianie aplikacji na Androidzie, wymaga tego kroku, aby zapewnić, że wszystkie aplikacje uruchomione od tego momentu będą korzystać z nowo skonfigurowanych certyfikatów CA. Używane polecenie to:
To zapewnia, że każda nowa aplikacja rozpoczęta będzie przestrzegać zaktualizowanej konfiguracji certyfikatów CA.
Stosowanie zmian do działających aplikacji: Aby zastosować zmiany do już działających aplikacji, ponownie używany jest
nsenter
, aby wejść do przestrzeni nazw każdej aplikacji indywidualnie i wykonać podobne podłączenie. Wymagane polecenie to:
Alternatywne podejście - Miękkie ponowne uruchomienie: Alternatywna metoda polega na wykonaniu bind mount na procesie
init
(PID 1), a następnie na miękkim ponownym uruchomieniu systemu operacyjnego za pomocą poleceństop && start
. To podejście spowoduje propagację zmian we wszystkich przestrzeniach nazw, eliminując konieczność indywidualnego adresowania każdej działającej aplikacji. Jednakże, ta metoda jest zazwyczaj mniej preferowana ze względu na niedogodność ponownego uruchamiania.
Referencje
Last updated