{{Header}}
{{title|title=
Android Insecurity
}}
{{#seo:
|description=Android Insecurity, How Android Blocks Effective Malware And Backdoor Analysis, How Android Prevents Full Device Backups, Limitations of Internal Storage Access on Non-Rooted Android Devices, Vulnerability to Target Malicious Upgrades
}}
{{mobile_mininav}}
{{intro|
Android Insecurity, How Android Blocks Effective Malware Analysis, How Android Prevents Full Device Backups, Limitations of Internal Storage Access on Non-Rooted Android Devices, Vulnerability to Target Malicious Upgrades
}}

= Android Insecurity =
== How Android Blocks Effective Malware Analysis ==
[[Malware]]: This is due to [[Android#Limitations_of_Internal_Storage_Access_on_Non-Rooted_Android_Devices|Limitations of Internal Storage Access on Non-Rooted Android Devices]]

A simpler, alternative write-up: [[Backdoor#The_Perfect_Malicious_Backdoor|The Perfect Malicious Backdoor]]

== How Android Blocks Effective Backdoor Analysis ==
[[Backdoor|Backdoors]] ([[Backdoor#Malicious_Backdoor|Malicious Backdoors]]): Same as above.

== How Android Prevents Full Device Backups ==
Full Device Backup Prevention: This is also due to [[Android#Limitations_of_Internal_Storage_Access_on_Non-Rooted_Android_Devices|Limitations of Internal Storage Access on Non-Rooted Android Devices]].

== Android Hinders Detection of Low-level Rootkits ==
The following research paper starts with explaining what rootkits are and why Android makes rootkit detection difficult.

Note: <u>Underline</u> added.

{{quotation
|quote=Abstract — Smartphones and tablets have become prime targets for malware, due to the valuable private and corporate information they hold. While <u>Anti-Virus (AV) program</u> may successfully detect malicious applications (apps), <u>they remain ineffective against low-level rootkits</u> that evade detection mechanisms by masking their own presence.
|context=[https://arxiv.org/pdf/1512.04116 JoKER: Trusted Detection of Kernel Rootkits in Android Devices via JTAG Interface], Mordechai Guri, Yuri Poliak, Department of Information Systems Engineering, Ben-Gurion University, Beer-Sheva, Israel
}}

{{quotation
|quote=Furthermore, any detection mechanism run on the same physical device as the monitored OS can be compromised via application, kernel or boot-loader vulnerabilities.
}}

{{quotation
|quote=Consequentially, trusted detection of kernel rootkits in mobile devices is a challenging task in practice.
}}

{{quotation
|quote=A. Kernel Rootkits<br/>

Mobile and desktop malware can operate in user space or kernel space. The user space malware can modify and inject code only into the memory areas allocated to apps and user processes. The kernel space malware can manipulate objects that reside in the entire memory area of the OS. Although sophisticated Mandatory Access Control (MAC) mechanisms such as SElinux [4] are integrated into current versions of Android, malware developers still manage to run their code in the kernel [5] [6] [3]. Rootkits are kernel space malware that use illicitly granted exclusive permissions to hide the malware's existence from detection systems, by manipulating the kernel's internal data structures [7]. A malicious code that has penetrated into the memory of the kernel can neutralize any security tool running in the OS. For instance, if an process sends a request to the kernel asking for the list of files in a specific directory there is no guarantee for the integrity of the returned list. Consequently, in order to detect presence rootkits, a trusted snapshot of the kernel memory has to be obtained [8]
}}

The research paper then continues to suggest their proposed solution.

{{quotation
|quote=Proposed System<br/>

In this paper we present JoKER (JTAG observe Kernel), a system that utilizes the JTAG hardware interface of the mobile device in order to obtain trusted snapshot of the device memory for detection of kernel rootkits.
}}

But this is very most likely never going to happen.

<div class="toccolours mw-collapsible mw-collapsed">
For detailed reasoning why that is unlikely, please press "Learn More" on the right site.
<div class="mw-collapsible-content">
Some phones do have JTAG (Joint Test Action Group) interfaces, but they are "in most cases" <ref>
No quantifiable data has been researched/found yet on how many are versus are not.
</ref> not openly or easily accessible for end users and developers. The JTAG interface is typically used by repair professionals and hackers for low-level hardware debugging, firmware backup, unbricking, and data recovery purposes. However, this JTAG interface is generally not exposed or documented for general use.

This is very device specific. 

JTAG access is treated a security issue by phone vendors. <ref>
* [https://patents.google.com/patent/US9633185B2/en Device having secure JTAG and debugging method for the same]
* https://www.acldigital.com/blogs/jtag-technology-security-guide
* https://www.startupdefense.io/cyberattacks/jtag-injection
* https://cellebrite.com/en/glossary/jtag-extraction-mobile-device-forensics/
</ref>

{{quotation
|quote=Turn Off JTAG by Default<br/>

To minimize security risks, JTAG capabilities should be disabled by default in production systems or end-user devices. This precautionary measure reduces the potential attack surface by ensuring that the JTAG interface cannot be exploited unless specifically enabled for essential testing or debugging purposes. For instance, manufacturers can implement a system where JTAG is only activated temporarily during authorized maintenance activities, thereby protecting devices from unauthorized access.
|context=ACL Digital: [https://www.acldigital.com/blogs/jtag-technology-security-guide Protect and Validate Essential JTAG Practices for Electronics]
}}

However, JTAG be also used for security.

{{quotation
|quote=Could JTAG be used for security analysis?<br/>

Yes, JTAG can be utilized for security analysis purposes. By accessing a device's internal state via its JTAG interface, security researchers can scrutinize firmware, identify potential vulnerabilities, and assess the effectiveness of security measures. This analysis may involve examining memory contents, identifying unauthorized access points, and assessing the resilience of cryptographic implementations. JTAG provides valuable insights into a device's security posture, aiding in the development of robust defenses against potential threats and exploits.
|context=[https://www.lenovo.com/us/en/glossary/what-is-jtag Lenovo: What is JTAG?]
}}

The research paper acknowledges the awkwardness of requiring JTAG access.

{{quotation
|quote=C. Method Limitation<br/>

Using the JTAG interface requires physic the JTAG port which is placed on the same board. Compared to software-based method may appear rather awkward.
}}
</div>
</div>

The research paper continues to describe features useful for rootkit analysis.

{{quotation
|quote=Our detection system uses <u>two important debugging features</u> of JTAG:
}}

{{quotation
|quote=
1. The ability to halt the system instantly by sending special instruction to the main processor.
}}

{{quotation
|quote=
2. The ability to access the content of the device’s volatile memory (RAM) while it is being halted. The overall system does not run on the mobile device and therefore can securely read the kernel’s memory areas in a trusted manner.
}}

{{quotation
|quote=Once the kernel memory is extracted, it is passed through an array of programmed scripts. Each script reconstruts specific data-structures in the kernel and analyzes them for traces of suspicious modifications.
}}

{{quotation
|quote=However, memory acquisition capabilities (from outside offers the advantage of trusted memory inspection.
}}

https://blog.thalium.re/posts/linux-kernel-rust-module-for-rootkit-detection/

https://www.cs.tufts.edu/comp/116/archive/fall2013/azakaria.pdf

boot from external media and integrity check

https://scholar.afit.edu/cgi/viewcontent.cgi?article=2086&context=etd

== Malware Analysis Capabilities: Traditional Linux vs. Android ==
{{Anchor|Technical Malware Analysis: Traditional Linux vs. Android}}

'''Table:''' ''Comparison of Malware Analysis Possibilities on Traditional Linux versus Android''

{| class="wikitable"
! Aspect
! '''Traditional Linux'''
! '''Android'''
|-

| '''System Access (Researcher-Controlled)'''
| ✅ Full root access common in testbeds and forensic imaging
| ❌ Root typically restricted; requires OEM unlock (often unavailable) or exploit to gain privileged access
|-

| '''Live Memory Acquisition'''
| ✅ Readily possible via tools like <code>gcore</code>, <code>procfs</code>, <code>volatility</code>, <code>LiME</code>
| ❌ Not feasible without root; no official RAM acquisition APIs
|-

| '''Kernel Analysis'''
| ✅ Kernel modules can be inserted, traced, or extracted; symbols often available
| ❌ No.
|-

| '''Binary Reverse Engineering'''
| ✅ Straightforward access to malware files, system binaries, logs
| ⚠️ Possible, but often limited to app-level APKs unless rooted or firmware access is available
|-

| '''Hook & Injection Analysis'''
| ✅ LD_PRELOAD, ptrace, syscall interposition techniques easily traced
| ⚠️ Requires rooting; SELinux and sandboxing block injection methods by default
|-

| '''Dynamic Instrumentation'''
| ✅ Tools like <code>strace</code>, <code>ltrace</code>, <code>gdb</code> available and effective
| ⚠️ Requires root or debugging permissions
|-

| '''Filesystem Analysis'''
| ✅ Full access to logs, temp files, malware droppers, rootkits
| ⚠️ App sandbox limits access to other app data; root or forensic image required for full view
|-

| '''Network Monitoring & C2 Analysis'''
| ✅ Tools like <code>tcpdump</code>, <code>Wireshark</code>, <code>iptables</code> usable without restriction
| ⚠️ Requires root or VPN-based monitoring
|-

|}

== Limitations of Internal Storage Access on Non-Rooted Android Devices ==

On most Android phones, accessing the internal storage for purposes such as data recovery or malware/rootkit analysis is not reasonably easy.

Prerequisite knowledge: [[Malware_and_Firmware_Trojans#Basics_of_Malware_Analysis_and_Backdoor_Hunting|Basics of Malware Analysis and Backdoor Hunting]]

This is primarily due to hardware limitations. The internal storage is a soldered chip, making physical removal highly impractical. Most repair shops lack the tools or skills to safely desolder and extract it. Even if removal is successful, finding a device capable of reading the chip without booting from it is difficult.

Booting the storage in another device might be possible in theory, but that defeats the purpose in most forensic contexts. If the original phone's software is damaged and unbootable, the storage likely won't boot elsewhere either. More importantly, malware analysis requires inspecting suspicious files from a clean, trusted system and never executing code from the infected device.

These limitations are compounded if the device uses full disk encryption, as explained in [[Android#Limitations_on_Encryption_Key_Backups|Limitations on Encryption Key Backups]].

References:

* [https://android.stackexchange.com/questions/176276/replace-internal-memory/176277 replace internal memory]
* [https://en.wikipedia.org/wiki/Mobile_device_forensics#Forensic_desoldering forensic desoldering]

Hence, not "reasonably easily" possible.

Quote from [https://android.stackexchange.com/questions/28296/how-to-fully-backup-non-rooted-devices How to fully backup non-rooted devices?]:

<blockquote>
For 4.0+ devices there is a solution called "adb backup".

Note: This only works for apps that do not disallow backup! Apps that disallow backup are simply ignored when creating a backup using this way.
</blockquote>

Information from [https://stackoverflow.com/questions/29442630/copy-full-disk-image-from-android-to-computer Copy full disk image from Android to computer] does not work for non-rooted / non-rootable devices.


=== Appendix ===
<div class="toccolours mw-collapsible mw-collapsed">
Taking a non-rooted Android device with GrapheneOS, contributed by a user.
<div class="mw-collapsible-content">

<pre>
$ adb devices
List of devices attached
xxxxxxxxxxx    device

$ adb root
adbd cannot run as root in production builds

$ adb shell
walleye:/ $ ls
ls: ./init.zygote64_32.rc: Permission denied
ls: ./init.rc: Permission denied
ls: ./init.usb.rc: Permission denied
ls: ./ueventd.rc: Permission denied
ls: ./init.zygote32.rc: Permission denied
ls: ./init: Permission denied
ls: ./cache: Permission denied
ls: ./init.environ.rc: Permission denied
ls: ./persist: Permission denied
ls: ./postinstall: Permission denied
ls: ./init.usb.configfs.rc: Permission denied
ls: ./metadata: Permission denied
acct apex bin bugreports charger config d data debug_ramdisk default.prop dev dsp etc firmware lost+found mnt odm oem proc product product_services res sbin sdcard storage sys system vendor
1|walleye:/ $ sudo ls
/system/bin/sh: sudo: inaccessible or not found
127|walleye:/ $ su
/system/bin/sh: su: inaccessible or not found
127|walleye:/ $
</pre>

<pre>
walleye:/dev/block $ ls -lah
total 0
drwxr-xr-x  6 root   root       2.4K 1970-07-03 11:40 .
drwxr-xr-x 18 root   root       3.9K 2020-05-26 15:41 ..
lrwxrwxrwx  1 root   root         37 1970-07-03 11:40 bootdevice -> /dev/block/platform/soc/1da4000.ufshc
drwxr-xr-x  2 root   root       1.6K 1970-07-03 11:40 by-name
brw-------  1 root   root   252,   0 1970-07-03 11:40 dm-0
brw-------  1 root   root   252,   1 1970-07-03 11:40 dm-1
brw-------  1 root   root     7,   0 1970-07-03 11:40 loop0
brw-------  1 root   root     7,   8 1970-07-03 11:40 loop1
brw-------  1 root   root     7,  80 1970-07-03 11:40 loop10
brw-------  1 root   root     7,  88 1970-07-03 11:40 loop11
brw-------  1 root   root     7,  96 1970-07-03 11:40 loop12
brw-------  1 root   root     7, 104 1970-07-03 11:40 loop13
brw-------  1 root   root     7, 112 1970-07-03 11:40 loop14
brw-------  1 root   root     7, 120 1970-07-03 11:40 loop15
brw-------  1 root   root     7,  16 1970-07-03 11:40 loop2
brw-------  1 root   root     7,  24 1970-07-03 11:40 loop3
brw-------  1 root   root     7,  32 1970-07-03 11:40 loop4
brw-------  1 root   root     7,  40 1970-07-03 11:40 loop5
brw-------  1 root   root     7,  48 1970-07-03 11:40 loop6
brw-------  1 root   root     7,  56 1970-07-03 11:40 loop7
brw-------  1 root   root     7,  64 1970-07-03 11:40 loop8
brw-------  1 root   root     7,  72 1970-07-03 11:40 loop9
drwxr-xr-x  2 root   root         80 1970-07-03 11:40 mapper
drwxr-xr-x  3 root   root         60 1970-07-03 11:40 platform
brw-------  1 root   root     1,   0 1970-07-03 11:40 ram0
brw-------  1 root   root     1,   1 1970-07-03 11:40 ram1
brw-------  1 root   root     1,  10 1970-07-03 11:40 ram10
brw-------  1 root   root     1,  11 1970-07-03 11:40 ram11
brw-------  1 root   root     1,  12 1970-07-03 11:40 ram12
brw-------  1 root   root     1,  13 1970-07-03 11:40 ram13
brw-------  1 root   root     1,  14 1970-07-03 11:40 ram14
brw-------  1 root   root     1,  15 1970-07-03 11:40 ram15
brw-------  1 root   root     1,   2 1970-07-03 11:40 ram2
brw-------  1 root   root     1,   3 1970-07-03 11:40 ram3
brw-------  1 root   root     1,   4 1970-07-03 11:40 ram4
brw-------  1 root   root     1,   5 1970-07-03 11:40 ram5
brw-------  1 root   root     1,   6 1970-07-03 11:40 ram6
brw-------  1 root   root     1,   7 1970-07-03 11:40 ram7
brw-------  1 root   root     1,   8 1970-07-03 11:40 ram8
brw-------  1 root   root     1,   9 1970-07-03 11:40 ram9
brw-------  1 root   root     8,   0 1970-07-03 11:40 sda
brw-------  1 root   root     8,   1 1970-07-03 11:40 sda1
brw-------  1 root   root     8,  10 1970-07-03 11:40 sda10
brw-------  1 root   root     8,  11 1970-07-03 11:40 sda11
brw-------  1 root   root     8,  12 1970-07-03 11:40 sda12
brw-------  1 root   root     8,  13 1970-07-03 11:40 sda13
brw-------  1 root   root     8,  14 1970-07-03 11:40 sda14
brw-------  1 root   root     8,  15 1970-07-03 11:40 sda15
brw-------  1 root   root   259,   0 1970-07-03 11:40 sda16
brw-------  1 root   root   259,   1 1970-07-03 11:40 sda17
brw-------  1 root   root   259,   2 1970-07-03 11:40 sda18
brw-------  1 root   root   259,   3 1970-07-03 11:40 sda19
brw-------  1 root   root     8,   2 1970-07-03 11:40 sda2
brw-------  1 root   root   259,   4 1970-07-03 11:40 sda20
brw-------  1 root   root   259,   5 1970-07-03 11:40 sda21
brw-------  1 root   root   259,   6 1970-07-03 11:40 sda22
brw-------  1 root   root   259,   7 1970-07-03 11:40 sda23
brw-------  1 root   root   259,   8 1970-07-03 11:40 sda24
brw-------  1 root   root   259,   9 1970-07-03 11:40 sda25
brw-------  1 root   root   259,  10 1970-07-03 11:40 sda26
brw-------  1 root   root   259,  11 1970-07-03 11:40 sda27
brw-------  1 root   root   259,  12 1970-07-03 11:40 sda28
brw-------  1 root   root   259,  13 1970-07-03 11:40 sda29
brw-------  1 root   root     8,   3 1970-07-03 11:40 sda3
brw-------  1 root   root   259,  14 1970-07-03 11:40 sda30
brw-------  1 root   root   259,  15 1970-07-03 11:40 sda31
brw-------  1 root   root   259,  16 1970-07-03 11:40 sda32
brw-------  1 root   root   259,  17 1970-07-03 11:40 sda33
brw-------  1 root   root   259,  18 1970-07-03 11:40 sda34
brw-------  1 root   root   259,  19 1970-07-03 11:40 sda35
brw-------  1 root   root   259,  20 1970-07-03 11:40 sda36
brw-------  1 root   root   259,  21 1970-07-03 11:40 sda37
brw-------  1 root   root   259,  22 1970-07-03 11:40 sda38
brw-------  1 root   root   259,  23 1970-07-03 11:40 sda39
brw-------  1 root   root     8,   4 1970-07-03 11:40 sda4
brw-------  1 root   root   259,  24 1970-07-03 11:40 sda40
brw-------  1 root   root   259,  25 1970-07-03 11:40 sda41
brw-------  1 root   root   259,  26 1970-07-03 11:40 sda42
brw-------  1 root   root   259,  27 1970-07-03 11:40 sda43
brw-------  1 root   root   259,  28 1970-07-03 11:40 sda44
brw-------  1 root   root   259,  29 1970-07-03 11:40 sda45
brw-------  1 root   root     8,   5 1970-07-03 11:40 sda5
brw-------  1 root   root     8,   6 1970-07-03 11:40 sda6
brw-------  1 root   root     8,   7 1970-07-03 11:40 sda7
brw-------  1 root   root     8,   8 1970-07-03 11:40 sda8
brw-------  1 root   root     8,   9 1970-07-03 11:40 sda9
brw-------  1 root   root     8,  16 1970-07-03 11:40 sdb
brw-------  1 root   root     8,  17 1970-07-03 11:40 sdb1
brw-------  1 root   root     8,  32 1970-07-03 11:40 sdc
brw-------  1 root   root     8,  33 1970-07-03 11:40 sdc1
brw-------  1 root   root     8,  48 1970-07-03 11:40 sdd
brw-------  1 root   root     8,  49 2020-05-26 15:41 sdd1
brw-------  1 root   root     8,  58 1970-07-03 11:40 sdd10
brw-------  1 root   root     8,  59 1970-07-03 11:40 sdd11
brw-------  1 root   root     8,  60 1970-07-03 11:40 sdd12
brw-------  1 root   root     8,  61 1970-07-03 11:40 sdd13
brw-------  1 root   root     8,  62 1970-07-03 11:40 sdd14
brw-------  1 root   root     8,  63 2020-05-26 15:42 sdd15
brw-------  1 root   root   259,  30 2020-05-26 15:41 sdd16
brw-------  1 root   root   259,  31 2020-05-26 15:41 sdd17
brw-------  1 root   root   259,  32 1970-07-03 11:40 sdd18
brw-------  1 root   root     8,  50 1970-07-03 11:40 sdd2
brw-------  1 root   root     8,  51 1970-07-03 11:40 sdd3
brw-rw----  1 system system   8,  52 2020-05-26 15:48 sdd4
brw-------  1 root   root     8,  53 1970-07-03 11:40 sdd5
brw-------  1 root   root     8,  54 1970-07-03 11:40 sdd6
brw-------  1 root   root     8,  55 1970-07-03 11:40 sdd7
brw-------  1 root   root     8,  56 1970-07-03 11:40 sdd8
brw-------  1 root   root     8,  57 1970-07-03 11:40 sdd9
brw-------  1 root   root     8,  64 1970-07-03 11:40 sde
brw-------  1 root   root     8,  65 1970-07-03 11:40 sde1
brw-------  1 root   root     8,  66 1970-07-03 11:40 sde2
brw-------  1 root   root     8,  67 1970-07-03 11:40 sde3
brw-------  1 root   root     8,  68 1970-07-03 11:40 sde4
brw-------  1 root   root     8,  69 1970-07-03 11:40 sde5
brw-------  1 root   root     8,  80 1970-07-03 11:40 sdf
brw-------  1 root   root     8,  81 1970-07-03 11:40 sdf1
brw-------  1 root   root     8,  82 1970-07-03 11:40 sdf2
brw-------  1 root   root     8,  83 1970-07-03 11:40 sdf3
brw-------  1 root   root     8,  84 1970-07-03 11:40 sdf4
brw-------  1 root   root     8,  85 1970-07-03 11:40 sdf5
drwx------  2 root   root         40 1970-07-03 11:40 vold
brw-------  1 root   root   253,   0 2020-05-26 15:41 zram0
</pre>

<pre>
$ adb shell
walleye:/ $ mount
/dev/root on / type ext4 (ro,seclabel,nodev,relatime)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,size=1851548k,nr_inodes=462887,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,nosuid,noexec,relatime,mode=600)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime,gid=3009,hidepid=2)
sysfs on /sys type sysfs (rw,seclabel,nosuid,nodev,noexec,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
tmpfs on /mnt type tmpfs (rw,seclabel,nosuid,nodev,noexec,relatime,size=1851548k,nr_inodes=462887,mode=755,gid=1000)
tmpfs on /apex type tmpfs (rw,seclabel,nosuid,nodev,noexec,relatime,size=1851548k,nr_inodes=462887,mode=755)
/dev/block/sdd3 on /persist type ext4 (rw,seclabel,nosuid,nodev,noatime,data=ordered)
/dev/block/dm-1 on /vendor type ext4 (ro,seclabel,relatime)
none on /dev/cpuctl type cgroup (rw,nosuid,nodev,noexec,relatime,cpu)
none on /acct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct)
none on /dev/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset,noprefix,release_agent=/sbin/cpuset_release_agent)
none on /dev/stune type cgroup (rw,nosuid,nodev,noexec,relatime,schedtune)
/dev/root on /apex/com.android.tzdata@290000000 type ext4 (ro,seclabel,relatime)
/dev/root on /apex/com.android.tzdata type ext4 (ro,seclabel,relatime)
/dev/root on /apex/com.android.runtime@1 type ext4 (ro,seclabel,relatime)
/dev/root on /apex/com.android.runtime type ext4 (ro,seclabel,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,seclabel,relatime)
none on /config type configfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,seclabel,relatime)
/dev/block/sde4 on /metadata type ext4 (rw,sync,seclabel,nosuid,nodev,noatime,discard,data=ordered)
/dev/block/sda28 on /firmware type vfat (ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=437,iocharset=iso8859-1,shortname=lower,errors=remount-ro)
tmpfs on /storage type tmpfs (rw,seclabel,nosuid,nodev,noexec,relatime,size=1851548k,nr_inodes=462887,mode=755,gid=1000)
/dev/block/sda45 on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,noauto_da_alloc,resgid=1065,errors=panic,stripe=4096,data=ordered)
/dev/root on /apex/com.android.conscrypt@290000000 type ext4 (ro,seclabel,nodev,relatime)
/dev/root on /apex/com.android.conscrypt type ext4 (ro,seclabel,nodev,relatime)
/dev/root on /apex/com.android.media@290000000 type ext4 (ro,seclabel,nodev,relatime)
/dev/root on /apex/com.android.media type ext4 (ro,seclabel,nodev,relatime)
/dev/root on /apex/com.android.media.swcodec@290000000 type ext4 (ro,seclabel,nodev,relatime)
/dev/root on /apex/com.android.media.swcodec type ext4 (ro,seclabel,nodev,relatime)
/dev/root on /apex/com.android.resolv@290000000 type ext4 (ro,seclabel,nodev,relatime)
/dev/root on /apex/com.android.resolv type ext4 (ro,seclabel,nodev,relatime)
adb on /dev/usb-ffs/adb type functionfs (rw,relatime)
mtp on /dev/usb-ffs/mtp type functionfs (rw,relatime)
ptp on /dev/usb-ffs/ptp type functionfs (rw,relatime)
/data/media on /mnt/runtime/default/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6,derive_gid,default_normal)
/data/media on /storage/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6,derive_gid,default_normal)
/data/media on /mnt/runtime/read/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=23,derive_gid,default_normal)
/data/media on /mnt/runtime/write/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=7,derive_gid,default_normal)
/data/media on /mnt/runtime/full/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=7,derive_gid,default_normal)
pstore on /sys/fs/pstore type pstore (rw,seclabel,relatime)
</pre>
</div>
</div>

== Limitations on Encryption Key Backups ==
It is not reasonably easy to make a backup of encryption keys.

The masterkey is not stored on the internal storage. [https://source.android.com/security/encryption/full-disk#storing_the_encrypted_key It is stored in hardware.] which is even harder to extract.

Note: "masterkey" here does not mean "backdoor". This is normal for most Linux desktop distributions offering full disk encryption. The masterkey is stored somewhere. When entering the password at boot with Linux desktop full disk encryption enabled, what gets decrypted is not actually the disk but the masterkey. This is then used to decrypt the disk, which is also called luks header. The advantage of the masterkey is that changing the disk encryption password is possible without having to re-encrypt the whole disk. (<code>cryptsetup-reencrypt</code>).

It is perhaps possible to dump the masterkey if the phone can still be started and can be rooted. There are no instructions how to do so. Hence, not "reasonably easily".

== Vulnerability to Target Malicious Upgrades ==
Most Google Android phones are at risk of targeted malicious upgrades.

Most Android phones have a feature which allows logging in on the Google Play web/desktop version using the same e-mail address that is used on the phone, usually the same Gmail address. When clicking "Install" for an app using the Google Play web/desktop version, the user will be prompted (in case of having registered multiple devices) to choose which device the app should be installed on. After pressing "Install," the app will be installed on the phone. This {{VideoLink|videoid=HljSquJ7yCo|text=video}} demonstrates this. It is therefore established that the Google website can result in remote app installation on the phone.

It follows that a coerced or compromised Google Play website could do the same. Since the Gmail-based web login can be linked to the same Gmail address on the phone, pushing targeted malicious upgrades is especially easy. Even if a phone was always fully torified (all traffic routed over Tor), the Gmail identifier could still be used. While Tor can anonymize the connection, it does not (and should not) attempt to modify anything inside the traffic (the Gmail identifier).

== Additional Android Security Issues ==
This wiki page is not standalone. It should be read together with the following wiki pages:

{{mobile_mininav}}

{{Footer}}
[[Category:Documentation]]