How Updates Work (or Why OTAs Break Root)

Updates can make or break functionality on your phone or tablet. No matter which operating system you may have (iOS, Android, Windows Phone, etc.), updates can be troublesome, as they can break your jailbreak/root that you may have worked hard on to get (and make it harder to re-obtain it). But before we can explain why they are so destructive to custom tweaks, we must first explain what updates are and what they consist of.

What are updates?

Updates (known as OTAs, or over-the-air updates, to Android users) are patches to an operating system that can add, remove, or change functionality of said operating system. Updates can be made to patch only certain system files (minor updates), or they can be made to patch the entire operating system (major updates). For example, an update can contain fixes for security breaches or hacks that can be exploited to create a jailbreak/root. If you're a user that is security-minded and/or ready to try new concepts as they are deployed, OTAs can be very useful. However, if you're a person that likes to jailbreak/root and tweak the operating system(s) installed on your device, OTAs can be bad. For example, a version of an OS that could be jailbroken/rooted via an exploit can be patched in an update, making it harder to jailbreak/root your phone/tablet. Sometimes updates will leave custom tweaks as is, but this is usually not the case.

Why are updates so destructive to custom tweaks?

Updates are often destructive to custom tweaks for a few reasons: 1) they can wipe the entire operating system core (usually leaving alone apps and user data stored in internal memory and/or an external SD card) and copy in all core OS files from the update; 2) they can make modifications to only certain files, breaking tweaks dependent upon said modifications; 3) they can safely remove any and all custom modifications to the OS; and/or 4) they can create file patches that will need to be bypassed in order to preserve root and/or re-obtain it. Not all files used in rooting (Android only) may be removed with an OTA, so re-rooting could be easier. Also note (Android only) that performing a factory reset may not remove root and/or other tweaks, as a factory reset will usually only overwrite user data and not system files (although custom tweaks may be dependent upon certain user data), while an OTA will typically do the opposite (keep user data, overwrite system files).

Is there anything that can be done to preserve my root/jailbreak when an update occurs?

While not guaranteed, there are steps you can take to attempt to preserve your root/jailbreak and/or custom tweaks. If you're using the SuperSU app on Android, you can try checking the "OTA Survival" checkbox in the SuperSU settings, although OTAs may fail while the checkbox is checked. Make sure to search the Web to check if your device root will survive or break after a particular OTA or if the "OTA Survival" setting will prevent an OTA from being applied. You may find after an update that root is preserved through the OTA with the OTA survival setting off, in which case that particular OTA is probably a minor one. For iOS, an OS update will almost certainly patch a jailbreak, so if you wish to keep it for future use, make a backup of your OS before you update so you can revert to it in a later point in time. As for Windows Phone, you may not have an option to keep your jailbreak after an update, so update only when a way of jailbreaking the latest update is available. One surefire way of preventing a root/jailbreak loss is to not update (or if you must update, wait until a method of jailbreaking/rooting the update is available). Another option is to install a custom OS (each device has a specific way of doing this), but you will often need to unlock your bootloader, install custom firmware to bypass any security measures implemented by your carrier/device manufacturer, and/or void your warranty. For instance, CyanogenMod and most derivatives of it come with root and Busybox (a package for rooted Android users that allows you to use a broader spectrum of typical Linux commands) by default, so you can update these without worrying about breaking root, but OTAs/updates of custom operating systems of any kind may break custom tweaks.

How to Root the Kindle Fire HD 8.9 (2012 edition)

WARNING: This root method will only work on the Kindle Fire HD 8.9 models released in 2012. If you attempt to root any other device with this, it will potentially brick your device. Follow these instructions to the letter.

Do you have a Kindle Fire that has Amazon's boring stock version of Android (a.k.a., Fire OS)? Tired of ads, but unwilling to fork over $15 to Amazon? Want an Android OS closer to the AOSP (Android Open Source Project) project? Then check out CyanogenMod, a free operating system built for Android devices. To install this OS, we need to perform a host of operations, which will 1) allow you to communicate between the Kindle Fire and the computer, 2) root the Kindle Fire itself, 3) install a custom bootloader and recovery, and 4) install CyanogenMod or another OS.

a) Prerequisites

The first step is to prepare the computer that will be used to root the Kindle Fire. Ensure that 1) the Android Debug Bridge (ADB) tools are downloaded and working; 2) the apps and files necessary to root and flash the bootloader, recovery, and CyanogenMod are downloaded; and 3) the Kindle Fire is set up to be rooted.

1) Download and extract the Android Developer Tools (ADT) bundle from the Android Developers website. The file will take a while to download (as well as to extract), so be patient.

2) Download, extract, and install the ADB drivers for the Kindle Fire HD 8.9. Before you do so, however, unplug the Kindle Fire from the computer and remove the old drivers using these directions. Once that's done, open either the "Kindle Fire ADB drivers" fire, or the "KindleDrivers" file, depending on which is successful.

3) Open the platform-tools folder inside the folder where you extracted the ADT bundle. Download the package we compiled that includes the tools you will need to root, and extract the files to the platform-tools folder.

4) Finally, enable the correct tools on your Kindle Fire as follows:

Swipe down from the top of the screen, then tap "More", as highlighted in the picture.

In the settings, tap "Device".

In the device menu, tap "Allow installation of Applications", and accept the dialog box that appears. Tap the back button on your device.

Now tap the "Security" section.

Tap "Enable ADB", accept the prompt that appears.

Now let's get rooting!

b) Testing, testing, 1-2-3... (and rooting!)

Still have that platform-tools window open? Good, because we'll need it! Hold down the shift key while right-clicking on an empty space, and click "Open command prompt here". Now you should see a terminal that looks like this:

Plug in your Kindle Fire now (give it a minute or so to install the drivers, and if failure is reported, install them again), and in this command prompt, type the following command:


adb devices

Now you should see the following screen (you may or may not see text pertaining to an adb server):

As long as you see an alphanumeric string followed by "device", and the only device plugged into your computer is your Kindle, you're fine.

OK, now it's time to get our figurative hands dirty (in other words, actually root the Kindle Fire). Any mistakes here, and you could be stuck with a half-broken device, so follow this guide to the letter. Issue the following commands one by one (when you type an "adb reboot" command, wait for the device to completely boot, then unlock the device, and then continue typing):


adb shell
rm -r /data/local/tmp 
ln -s /data/ /data/local/tmp 
exit

adb reboot

adb shell
echo 'ro.kernel.qemu=1′ > /data/local.prop
exit

adb reboot

adb shell mount -o remount,rw /system
adb push su /system/xbin/su
adb shell
chown 0.0 /system/xbin/su
chmod 06755 /system/xbin/su
rm /data/local.prop
exit

adb reboot

adb install Superuser.apk
adb install "Root Checker App.apk"
adb install fireflash.apk



Now you can stop the adb commands. Anyway, we just told the system to remount as a rewritable file system so we could push the su file, changed the permissions so the Kindle can detect the root file and create a gateway, and we installed 3 apps that will permit us to test root access and perform the rest of the steps.

c) New bootloader (and OS!)

The next logical step is to test our root. If you feel comfortable with this and you would like to continue, feel free to skip ahead. Otherwise, look on your Kindle's app launcher (or tap the Apps button at the top). You should see 3 new apps: fireflash, Superuser, and Root Checker. If you see all three apps, then you're ready. Open the Superuser app, as it is what you will use to give root access to apps on your device that ask for it. As we are going to test root, press the back button, and open the Root Checker app. Click the button that says to "Verify root access", and a prompt should appear on your screen. If you see it, press the Allow button. Next, wait a few seconds, and the root checker app should say that you're rooted, along with some data that identifies your device. If you don't see this screen, then press the "Verify root access" button again, and accept any prompts from Superuser. If you still see red text that says you're not rooted, try to perform step b again.

Now that you're rooted at this point, you must download the freedom-boot file, the TWRP recovery, a custom ROM/OS built for the Kindle Fire HD 8.9 (like the unofficial port of CyanogenMod 11/Android 4.4.2 [KitKat] (which is the latest CM version as of the time of writing)), and (optionally) the latest Google Apps package (this last link is laced with ads!). However, we have fireflash installed, so we will simply download the files, put them in the "Internal storage" folder, and open FireFlash. To quote seokhun and his useful guide to installing TWRP, the bootloader, and CM:

The first thing you notice is that there are spots to plug in files for different partitions. This is where those files from Hashcode come into play. Plug the freedom-boot.img into the boot partition space, plug the TWRP recovery.img into the recovery partition, and make sure to hit "apply stack". If you are NOT on the 8.1.4 bootloader (you'll see red letters warning you), then hit the check box next to that to flash the 8.1.4 bootloader, otherwise you'll see a red screen after you reboot. If you don't see that warning, you're fine, move on.

Check that "disable recovery auto update" box, leave everything else alone, unplug the cable, and hit flash (the first option). You will see a progress window, and just hit OK. Then, turn off the device. Now, when you turn it on, this is the way to enter recovery every time: the moment you turn it on, you'll see the yellow Kindle title. Immediately hold down the Volume Up button (leftmost from the power button) before it turns blue, and once it does, count to three in your head and let go and you'll see the TWRP splash logo.

Now, inside TWRP, press the "Install" button. Find the file where the CM/other ROM zip is located, and click on it. If you downloaded the gapps package as well, then click "Add more ZIPs", and navigate to the gapps file. When you're done choosing ZIPs to flash (the buffer can hold a maximum of 10 ZIPs at a time), swipe where indicated to flash the files. When done, tap the button that says to "Wipe cache/dalvik". Swipe where indicated, and your device's application cache (as well as the Dalvik cache) will be cleared. In general, if you're switching from one OS to another, like from AOKP to CyanogenMod), or if you're having trouble with apps constantly crashing, use the cache/dalvik wipe, which can be accessed from the Wipe button in the main menu of TWRP. From this point on, if you want to flash a new OS onto your Kindle, all you have to do is download the ZIP(s) for the OS (as well as the gapps if you choose), boot into TWRP, flash your ROM (and gapps if necessary), clear the cache/dalvik (if you're moving from one different ROM to another, like Amazon's OS to AOKP, CyanogenMod to Amazon's stock OS, etc.), and reboot (Reboot button if freshly flashing a ROM, or Reboot -> System from the TWRP main menu). It's that simple.

Take care to only flash ROMs that were made for your particular device model (in this case, the Kindle Fire HD 8.9. Remember, the Kindle Fire HD 8.9 is not the same as the HD 7, the Kindle Fire 2, the Kindle Fire HDX models, or the original Kindle Fire. If you try to flash a bootloader or custom recovery made for the HD 8.9 on an HD 7 (or vice versa), your tablet will not boot, and may subsequently and/or irrevocably become bricked. Enjoy your now-freed Kindle Fire HD 8.9.

Watch Out For Google Drive Phishing Attack Emails

At one point in time or another, you may have seen some emails from Google Drive/Docs that include a link to a folder and/or document. However, not all of these emails are legit. The non-legit emails will, upon opening the contained link(s), will ask you to sign in, even if you are already logged into a Google Account.

The emails will typically look like one of the following 2 screenshots (keep in mind that the emails you receive, if you are targeted, may be similar to these, if not identical):

However, these emails do NOT link to valid Google Drive sign-in URLs. The URLs actually point to phishing websites, such as the one shown below:

What's wrong with that page? Take 5 minutes to spot all the mistakes, or just read on...

Firstly, the URL in the address bar is not a valid Google Drive URL. The proper Google Drive URL always begins with:

https://drive.google.com/

As we can see, the URL obviously does not pass as a link to a document in Google Drive.

Secondly, the methods you can login with are incorrect. The real Google Drive login page will only let you login with a valid Google Account (usually xuser@gmail.com, where xuser is your Gmail username without the @gmail.com part). Since the fake page above will let you login with any email, it is not a legit sign-in page. This fake page will actually capture your login credentials and use them to hack your account.

Thirdly, the layout of the page is incorrect. A real Google Drive login page will look something like:

Now that we can differentiate between the real sign-in pages and the fake ones, we need to know how to stop or diminish the non-legit emails:

1) Always make sure to check that the URL that claims to be a Google Drive sign-in page starts with https://drive.google.com. If not, exit the webpage immediately. If you inadvertently enter your login credentials to your email, change the password to it immediately.

2) If you get a fake email, report it as a phishing attack (in Gmail, open the message, click the dropdown arrow next to the reply button, and click "Report phishing."

3) If the email came from someone you know, or if they have sent you legitimate emails in the past, send an email to them about the attack. They should change their passwords as soon as possible.