<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
**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`**.\
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.
1.**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ź do `Zainstaluj certyfikat` -> `Certyfikat CA`
2.**Zrób go zaufanym przez system**: Pobierz moduł Magisc [MagiskTrustUserCerts](https://github.com/NVISOsecurity/MagiskTrustUserCerts) (plik .zip), **przeciągnij i upuść** go w telefonie, przejdź do aplikacji Magics w telefonie do sekcji **`Moduły`**, kliknij na **`Zainstaluj z pamięci`**, wybierz moduł `.zip` i po zainstalowaniu **ponownie uruchom** telefon:
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 wraz z Androidem 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 na katalog tymczasowego systemu plików (tmpfs) nie omijają niemutowalności; aplikacje nadal uzyskują dostęp do oryginalnych danych certyfikatów 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 odpowiada za uruchamianie procesów aplikacji z nową przestrzenią montowania, która obejmuje prywatne montowanie **`/apex`**, izolując zmiany w tym katalogu od innych procesów.
Mimo to istnieje sposób obejścia 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.
1.**Konfigurowanie katalogu z możliwością zapisu**: W pierwszej kolejności, ustanawiany jest katalog z możliwością zapisu poprzez zamontowanie `tmpfs` nad istniejącym katalogiem certyfikatów systemowych non-APEX. Można to osiągnąć za pomocą poniższej komendy:
2.**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.
3.**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:
4.**Zastosowanie 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 montażowe. Wymagane polecenie to:
5.**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.