{"title":"Georg's Log - android","link":[{"@attributes":{"href":"https:\/\/gms.tf\/","rel":"alternate"}},{"@attributes":{"href":"https:\/\/gms.tf\/feeds\/android.atom.xml","rel":"self"}}],"id":"https:\/\/gms.tf\/","updated":"2017-06-15T21:10:00+02:00","entry":{"title":"Reasons for Rooting Android","link":{"@attributes":{"href":"https:\/\/gms.tf\/reasons-for-rooting-android.html","rel":"alternate"}},"published":"2017-06-15T21:10:00+02:00","updated":"2017-06-15T21:10:00+02:00","author":{"name":"Georg Sauthoff"},"id":"tag:gms.tf,2017-06-15:\/reasons-for-rooting-android.html","summary":"<p>A stock Android device is locked down, by default. Rooting\nis the process of getting access to the root user (think: installing\n<a href=\"https:\/\/en.wikipedia.org\/wiki\/Su_(Unix)\"><code>su<\/code><\/a>). This article lists several advantages of a rooted device.<\/p>\n<div class=\"toc\">\n<ul>\n<li><a href=\"#ntpsync\">NTPsync<\/a><\/li>\n<li><a href=\"#create-usb-mass-storage-devices\">Create USB Mass Storage devices<\/a><\/li>\n<li><a href=\"#simple-backups\">Simple Backups<\/a><\/li>\n<li><a href=\"#separate-disk-encryption-password\">Separate Disk Encryption Password<\/a><\/li>\n<li><a href=\"#side-note-rooting-vs-unlocking-vs-flashing\">Side Note: Rooting vs. Unlocking vs \u2026<\/a><\/li><\/ul><\/div>","content":"<p>A stock Android device is locked down, by default. Rooting\nis the process of getting access to the root user (think: installing\n<a href=\"https:\/\/en.wikipedia.org\/wiki\/Su_(Unix)\"><code>su<\/code><\/a>). This article lists several advantages of a rooted device.<\/p>\n<div class=\"toc\">\n<ul>\n<li><a href=\"#ntpsync\">NTPsync<\/a><\/li>\n<li><a href=\"#create-usb-mass-storage-devices\">Create USB Mass Storage devices<\/a><\/li>\n<li><a href=\"#simple-backups\">Simple Backups<\/a><\/li>\n<li><a href=\"#separate-disk-encryption-password\">Separate Disk Encryption Password<\/a><\/li>\n<li><a href=\"#side-note-rooting-vs-unlocking-vs-flashing\">Side Note: Rooting vs. Unlocking vs. Flashing<\/a><\/li>\n<\/ul>\n<\/div>\n<h2 id=\"ntpsync\">NTPsync<a class=\"headerlink\" href=\"#ntpsync\" title=\"Permanent link\">&para;<\/a><\/h2>\n<p>The Android system has a 'automatic date &amp; time' setting ('use\nnetwork-provided time') that is enabled, by default.\nUnfortunately, Android doesn't use the internet (think:\n<a href=\"https:\/\/en.wikipedia.org\/wiki\/Network_Time_Protocol\">NTP<\/a>) for\nthis but the <a href=\"https:\/\/en.wikipedia.org\/wiki\/GSM\">GSM<\/a> network. The <a href=\"https:\/\/en.wikipedia.org\/wiki\/NITZ\">time synchronisation\nmethods<\/a> provided by mobile operators are notorious for\ndelivering the wrong time (German press coverage: <a href=\"https:\/\/www.inside-handy.de\/news\/36200-falsche-uhrzeit-im-o2-netz-uhrzeit-im-telefonica-netz-mit-9-minuten-zeitverzug\">2015<\/a>,\n<a href=\"https:\/\/www.heise.de\/newsticker\/meldung\/Falsche-Uhrzeit-im-Telefonica-Netz-3088196.html\">2016<\/a>)). Your author nearly missed a train because of such\nincorrect time data.<\/p>\n<p>Accessing a <a href=\"https:\/\/en.wikipedia.org\/wiki\/Network_Time_Protocol\">NTP<\/a> server from an Android app isn't a challenge, but\nthe system doesn't allow to set the system time from an app. This\nmakes sense for the obvious security implications, but the system\ndoesn't even provide a special permission an app could request.<\/p>\n<p>Thus, root is required to sync the device time with an <a href=\"https:\/\/en.wikipedia.org\/wiki\/Network_Time_Protocol\">NTP<\/a>\nserver. The <a href=\"https:\/\/github.com\/Free-Software-for-Android\/NTPSync\">NTPSync app<\/a> is an open-source app that is able to\ndisplay the remote time (doesn't require root) and to set the\nsystem time. It requests root permissions for that and thus\nrequires a rooted device for this feature.<\/p>\n<h2 id=\"create-usb-mass-storage-devices\">Create USB Mass Storage devices<a class=\"headerlink\" href=\"#create-usb-mass-storage-devices\" title=\"Permanent link\">&para;<\/a><\/h2>\n<p>What is better than a collection of USB sticks you have to carry\naround for different purposes? Yes, your Smartphone emulating of\nbunch of USB sticks. After all, you already carry around your\nSmartphone all the time, anyways.<\/p>\n<p>Stock Android doesn't provide this functionality. But it still\nhas enough Linux infrastructure included to easily configure\nemulated mass storage devices - if and only if you have root\naccess on your device.<\/p>\n<p>The <a href=\"https:\/\/github.com\/Streetwalrus\/android_usb_msd\">USB mountr app<\/a> provides a simple GUI for\ntemporarily turning your phone into a <a href=\"https:\/\/en.wikipedia.org\/wiki\/USB_mass_storage_device_class\">USB mass storage\ndevice<\/a>.  When the emulation is active, plugging the phone\nto an USB port looks like attaching a USB stick - from the\ncomputer point of view. And the phone is even able to charge\nitself during the emulation.<\/p>\n<h2 id=\"simple-backups\">Simple Backups<a class=\"headerlink\" href=\"#simple-backups\" title=\"Permanent link\">&para;<\/a><\/h2>\n<p>Backing up important data from an android device to a connected\ncomputer can be a hassle.  Some apps provide sync-into-a-cloud\nsupport, but not all and perhaps you don't want to put your data\ninto some proprietary cloud you don't trust.<\/p>\n<p>Android apps are able to store data under two different\nlocations. Under a public location (i.e. under <code>\/sdcard\/<\/code>) and in\na private directory under <code>\/data\/data\/<\/code>. The public location can\nbe accessed without root-permissions, e.g. via <a href=\"https:\/\/developer.android.com\/studio\/command-line\/adb.html\"><code>adb pull<\/code><\/a> or via\na <a href=\"https:\/\/termux.com\/\">Termux<\/a> session. A normal user cannot access the private\ndirectory, though.<\/p>\n<p>There is a <code>adb backup<\/code> command for backing up the private app\ndata but there are two caveats. This functionality regularly\nbreaks with different Android\/<a href=\"https:\/\/developer.android.com\/studio\/command-line\/adb.html\">adb<\/a> version. The resulting archive\nis encrypted if your Android is encrypted. As always, the\nencrypted archive doesn't use some standard format that you could\ndecrypt using standard tools. Instead, it's in some legacy format\nsuch that you can't easily extract the included XML preference files and\n<a href=\"https:\/\/en.wikipedia.org\/wiki\/SQLite\">SQLite<\/a> database files on your computer.<\/p>\n<p>On a rooted device doing a backup is as simple as starting an\nsshd in a <a href=\"https:\/\/termux.com\/\">Termux<\/a> session, telling <a href=\"https:\/\/en.wikipedia.org\/wiki\/Rsync\">rsync<\/a> to <code>su<\/code> and rsync some\ndirectories.<\/p>\n<p>Example:<\/p>\n<div class=\"m-code\"><pre><span><\/span><code><span class=\"gp\">$ <\/span>rsync<span class=\"w\"> <\/span>-ai<span class=\"w\"> <\/span>--rsync-path<span class=\"o\">=<\/span>\/data\/data\/com.termux\/files\/home\/sursync<span class=\"w\"> <\/span><span class=\"se\">\\<\/span>\n<span class=\"w\">    <\/span>phone.example.org:\/data\/data\/org.example.app<span class=\"w\"> <\/span>\/mnt\/backup\/phone\n<\/code><\/pre><\/div>\n\n<p>where the <code>sursync<\/code> helper script looks like this:<\/p>\n<div class=\"m-code\"><pre><span><\/span><code><span class=\"ch\">#!\/data\/data\/com.termux\/files\/usr\/bin\/bash<\/span>\n<span class=\"nb\">exec<\/span><span class=\"w\"> <\/span>su<span class=\"w\"> <\/span>-c<span class=\"w\"> <\/span><span class=\"s2\">&quot;rsync <\/span><span class=\"nv\">$*<\/span><span class=\"s2\">&quot;<\/span><span class=\"w\"> <\/span>--<span class=\"w\"> <\/span>-<span class=\"w\"> <\/span>--\n<\/code><\/pre><\/div>\n\n<h2 id=\"separate-disk-encryption-password\">Separate Disk Encryption Password<a class=\"headerlink\" href=\"#separate-disk-encryption-password\" title=\"Permanent link\">&para;<\/a><\/h2>\n<p>Android <a href=\"https:\/\/source.android.com\/security\/encryption\/full-disk\">supports disk encryption<\/a> since version 4.4\n(improved architecture since 5). Conceptually, the disk\nencryption works similarly to <a href=\"https:\/\/gitlab.com\/cryptsetup\/cryptsetup\">luks-cryptsetup<\/a>\n(i.e. the user password just encrypts the real key - one\nthat this randomly generated - and can be easily changed with\nhaving to re-encrypt everything). But Android being Android, a\nnew format and new tools were developed.<\/p>\n<p>By default, Android uses the same password for disk encryption as\nfor the lock screen and there is no GUI for changing them\nindependently. As-is, this is unfortunate - because you\nnaturally want to use a strong password for disk encryption and a\nweaker (think: shorter) one for the lock screen.<\/p>\n<p>Thus, using a strong password for both is impractical due to the\nnumber of unlock operations during the day and using a weak\npassword for both enables trivial brute-forcing (e.g. when\nsomebody steals your phone).<\/p>\n<p>One some Android devices the situation is improved with\nadditional hardware. There, the user password <a href=\"https:\/\/source.android.com\/security\/encryption\/full-disk#storing_the_encrypted_key\">is signed with a\nprivate key<\/a> that presumably can't leave a <a href=\"https:\/\/lwn.net\/Articles\/717125\/\">trusted\nhardware environment (a.k.a. TEE, TrustZone)<\/a>. The\nsignature then is used to encrypt the real disk encryption key.\nThis helps against brute forcing if and only if the\ntrusted environment really is secure, implements some kind of\nrate limiting and\/or automatic lock-down in case of to many\nauthentication failures.<\/p>\n<p>In any case, with root permissions it is easily possible to\nindependently set a filesystem encryption password.<\/p>\n<p>With that it is sufficient that just the lock-screen implements\nsome effective rate-limiting which could even escalate to\nunmounting the encrypted filesystem - e.g.  via a shutdown. And\nat that point the attacker has to deal with the stronger disk\nencryption password.<\/p>\n<p>Example:<\/p>\n<p>Change the disk encryption password on Lineage 14.1:<\/p>\n<div class=\"m-code\"><pre><span><\/span><code><span class=\"gp\">$ <\/span>adb<span class=\"w\"> <\/span>shell\n<span class=\"gp\">$ <\/span>su\n<span class=\"gp\"># <\/span>vdc<span class=\"w\"> <\/span>cryptfs<span class=\"w\"> <\/span>verifypw<span class=\"w\"> <\/span><span class=\"nv\">$currentpw<\/span>\n<span class=\"gp\"># <\/span><span class=\"nb\">echo<\/span><span class=\"w\"> <\/span>returns<span class=\"w\"> <\/span>a<span class=\"w\"> <\/span><span class=\"m\">3<\/span>-tuple,<span class=\"w\"> <\/span>last<span class=\"w\"> <\/span>component<span class=\"w\"> <\/span><span class=\"m\">0<\/span><span class=\"w\"> <\/span>-&gt;<span class=\"w\"> <\/span>success,<span class=\"w\"> <\/span><span class=\"m\">1<\/span><span class=\"w\"> <\/span>-&gt;<span class=\"w\"> <\/span>failure\n<span class=\"gp\"># <\/span>vdc<span class=\"w\"> <\/span>cryptfs<span class=\"w\"> <\/span>changepw<span class=\"w\"> <\/span>password<span class=\"w\"> <\/span><span class=\"nv\">$oldpw<\/span><span class=\"w\"> <\/span><span class=\"nv\">$newpw<\/span>\n<span class=\"gp\"># <\/span>vdc<span class=\"w\"> <\/span>cryptfs<span class=\"w\"> <\/span>verifypw<span class=\"w\"> <\/span><span class=\"nv\">$newpw<\/span>\n<\/code><\/pre><\/div>\n\n<p>The vdc syntax <a href=\"https:\/\/github.com\/nelenkov\/cryptfs-password-manager\/\">varies between different Android versions<\/a>.<\/p>\n<h2 id=\"side-note-rooting-vs-unlocking-vs-flashing\">Side Note: Rooting vs. Unlocking vs. Flashing<a class=\"headerlink\" href=\"#side-note-rooting-vs-unlocking-vs-flashing\" title=\"Permanent link\">&para;<\/a><\/h2>\n<p>Perhaps not all of this isn't directly obvious:<\/p>\n<ul>\n<li>Unlocking the bootloader doesn't automatically root your phone.<\/li>\n<li>After unlocking the bootloader and flashing an alternative\n  recovery image like <a href=\"https:\/\/en.wikipedia.org\/wiki\/TWRP\">TWRP<\/a>, booting into the recovery image\n  allows you to connect via <code>adb shell<\/code> and that session then has\n  root permissions.<\/li>\n<li>The device isn't rooted by default after flashing an alternate\n  system image like <a href=\"https:\/\/lineageos.org\/\">Lineageos<\/a>.  With stock Lineageos the device\n  is still unrooted. Lineageos provides a <a href=\"https:\/\/download.lineageos.org\/extras\">su addon<\/a>.<\/li>\n<li>The sandboxing of apps using Linux mechanisms like SELinux is\n  still active after the device is rooted.<\/li>\n<li>Rooting results in the availability of a <a href=\"https:\/\/en.wikipedia.org\/wiki\/Su_(Unix)\"><code>su<\/code> command<\/a>.<\/li>\n<li>After rooting, the <code>su<\/code> command can directly be executed from an\n  <code>adb shell<\/code> session.<\/li>\n<li>The Lineageos su addon installs <code>su<\/code> such that it is integrated\n  into the permission system. That means that an app trying\n  to get root (via su) needs the root-permission. With <a href=\"https:\/\/lineageos.org\/\">Lineageos'\n  Privacy Guard<\/a> the default for this permission is always-ask.<\/li>\n<\/ul>","category":[{"@attributes":{"term":"android"}},{"@attributes":{"term":"root"}}]}}