Database Users

[REF] Understanding the basics before rooting your S3 (GT-i9300/i9305)

Note from the Author -
I am moving on to the N5 now and ditching my S3. I will continue to maintain this thread, however - please do PM me if you think that something needs to be changed or updated in this thread as I doubt I will be answering questions within the thread as much. Please don't PM support questions to me. Only PM updates that need to be made in the thread.
It's been a blast!
Regards
Dan
efs | backup your efs | backup your efs | backup your efs | backup your efs | backup your
Understanding the basics before rooting your S3 (GT-i9300/i9305)
This thread is intended to give you (as someone considering rooting your device) an overview of some of what I deem to be, really important information. Many people blindly follow guides and end up in trouble because they break their phones and don't really know what they were even doing at the time.
This may seem a bit overwhelming at first, there is a lot of text, but please do take the time to read it. It may save you further down the line.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Before we get started...
Here are a couple of threads you should get familiar with before posting on XDA.
Forum Rules - use Search before posting
Post Questions or Support queries in Q&A, NOT General
What is root access?
"root" is (but not exclusively) a Linux term. As you may or may not know, Android is based on a Linux Kernel.
The term "root" refers to the root of the device. All devices with an operating system use a series of directories (or folders) nested within one another. If you think of windows, your documents folder would be C:\users\username\documents.. Well, "documents" is a directory. It is within another directory (username).
Imagine "documents" being the top of a tree (A folder tree). You climb down the tree to username, past there to "users" and down to the root, in this example "c:". You cannot go beyond this level, because nothing exists beyond the root. To save a file directly on C: (not within any folders) would be to save a file to the root of your c: drive.
In Linux (unlike Windows), these root locations are completely locked down. A user of normal priviledges cannot edit any file or create files in these locations. They can only do this in their "home" location, which is the equivelant of username on windows. To gain access to these locations, you would need to be an administrator of the machine. Linux calls this Super User (su), and this user is said to have "root access".
This applies to Android in the same way. To root your Android device, is to have superuser access to the root locations of your phone, that you normally could not have access to.
Is it Risky?
There is always a risk having access to locations on your phone that are supposed to be locked down. You can easily delete things that your phone needs to boot up, which could lead to you losing all your data or even breaking your phone. This is why it is good have an understanding of your device and root access BEFORE you root.
It is worth noting that although many say rooting shouldn't void your warranty (it does in many places) even where that is supposed to be true, in practice, it isn't really. Even in the EU, I've seen many warranty claims rejected due to root so do think of your phone as out of warranty when you root.
The advantages of rooting
Why root?
More control over how the CPU acts. This can increase performance or battery life
More control over power consumption (undervolting)
More control over how apps start up. Prevent apps from starting up when they don't need to
Baseband. Try different basebands with the possibility of reducing drain or imporving signal strength
De-bloat. Remove or freeze system apps that you don't use
Access to community driven bug fixes that Samsung haven't released
Custom ROMs. Add additional functionality and controls over and above the stock experience
Increase redundancy. The ability to backup apps and entire phone
Theme. Don't be stuck with Samsung driving aesthetics.
Innovations. Use community driven features that improve your day to day experience
Better RAM management. Change the values of "Out of memory". Decide yourself when android should kill unused apps. Increase mutlitasking capabilities
Custom kernels. With kernels you can bring support for better audio features, better graphics performance and support for stock unsupported files systems
Google Android. Use android as it was intended before Samsung got their hands on it.
The Disadvantages of rooting
Why not root?
For all intents and purposes, rooting voids warranty.
Dangerous. You can break your phone and need the warranty you probably just voided
You open the doors for more mistakes. These mistakes may cause you to panic and further damage your phone
Lack of understanding. Blindly following guides and not understanding what you're doing.
No more official updates. Updating is a more manual process
Basic layout of /root on the GT-i9300
I'm not going to go into too much detail here. I just need you to know the basics. The GT-i9300 has an embedded Multi Media Card. This is the internal memory that everything on your phone you need to run it, is insalled on. It is the "internal memory" of the device.
Like windows and linux, there is a root to this memory, which has a few basic partitions that you need to know.
/efs - This is REALLY important. This is where your IMEI is stored, which you need to connect to your provider's network. Unfortunately it is the easiest partition to corrupt and impossible to restore without a backup so ensure you have a recovery or application to backup your efs cause if it goes (likely) you'll be sending your S3 to Samsung for repair.
Please read THIS THREAD for more info on EFS and IMEI issues.
/system - This is where the ROM is installed. Within /system are many important folders that you normally cannot get to.
For example, you have /system/app where all the important ROM apps are located. Things like the phone app and the messaging app. /system/bin, where all the important binaries are located that allow android to execute commands that it needs to, so it can function as an OS and /system/framework, where the crucial policies that control how things the user and processes interact with - act.
/data - This is where apps you install are kept. This is also where your data is kept, eg your SMS and e-mails. It also stores settings. If you change the wallpaper, it is stored here. What ringtone you have chosen... etc. The important directories here are /data/app and /data/data. These are what get wiped when you choose to wipe data\factory reset
/data/media is an important directory in /data. This is what is known as your "internal storage" or your "internal sdcard". /sdcard maps to here.
When you have root access to android, you can browse these partitions with a root explorer / file manager with root functionality.
There are also some hidden partitions you cannot browse like this. These are the partitions that contain recovery, bootloader and kernel
What are those things?
Kernel - This is always supplied with a ROM. It is the beating heart of Android. The ROM cannot function without the kernel. Since all ROMs include a kernel, if you're using a custom Kernel then flash a ROM, you will need to reflash the kernel again.
Please note, unlike the Galaxy S2 (and like almost every other modern android device) the kernel and recovery are independent. There is no link between recovery and kernel. Kernels are boot.img files.
Bootloader - this is what handles what you boot into. When you see the black Galaxy s III text, thats the bootloader. Its job is to handle the boot. It is responsible for booting into android, or if you manipulate the buttons in a certain way, it will boot into recovery or download mode. PLEASE NOTE, i9300/5 Bootloader is NOT LOCKED. DO NOT TRY TO UNLOCK IT. Only some US variants have a locked bootloader...
When you see this screen, you're looking at the bootloader:
Download mode is part of the bootloader itself. Again, it is a mini OS. It is designed for flashing stock (official) ROMs onto the phone (Which you can do using Odin). It is also used by Samsung to detect the status of your phone (if you have modified it or not).
If you have (or had before rooting) an official ROM above 4.1.1, Your bootloader flash counter in download mode will change to "1" at every boot, if you have a custom kernel or recovery - even if you reset it with Triangle Away. See the return for warranty link later in this post to get around this.
To access download mode, turn off your phone. Home volume down + home then press power. You will get to the screen below:
Press volume up to continue into Download mode:
Recovery - a secondary, min operating system designed to offer a few "drastic" options to recover when you cannot boot into android. For example, factory reset. Recovery isn't part of android. It is a seperate operting system. You can either boot into android or boot into reocvery.
To access recovery (custom or stock), turn of you phone. Hold volume up + home then press power.
The intial use of Stock recovery was to allow a user whose phone does not boot, to wipe their device to "recover" it to a booting state. It could also flash official updates from the sdcard. Custom recoveries do so much more, such as allowing you to flash custom rom.zip or kernel.zips from sdcard or backing up your device with a nandroid recovery.
Here is an example of a custom recovery (Philx Touch 5):
Please note, unlike the Galaxy S2 (and like almost every other modern android device) the kernel and recovery are independent. There is no link between recovery and kernel.
Some other stuff you may have heard about
Baseband / Modem / Radio - This is the software that manages your connection to wireless networks, be that voice or data. Unlike unrooted users, you can download and flash any number of i9300 (Versions for other models WILL BRICK YOUR PHONE) or i9305 radios pulled from official ROMs. I wouldn't waste too much time on them. Usually what your official ROM comes with in your country / for your carrier, is the most optimised for you. Try a few by all means but don't waste time testing every last one.
Be aware that Samsung official ROMs come with a baseband. Often this means Samsung based custom ROMs may also do so. Some ROMs which install using the Aroma installer (A kind of set-up wizard) may give the option to not flash the baseband. AOSP ROMs almost never come with a baseband. When you flash a ROM withotu a baseband, the previous baseband remains. You can by all means, mix and match ROMs and basebands. You are not tied to the baseband with the same build number as the ROM. For example, if you are on XXEMB1 ROM, you definitely do NOT have to stay on the XXEMB1 baseband.
RIL - RIL is Radio Interface layer. It's what sits between the radio (above) and the android telephony services. Each Radio is supposed to have a specific RIL. Every ROM comes with RIL as it's a requirement to function. Again, although the best pair is a matched RIL and Radio version, if you do change your Radio, it's not the end of the world. You may notice a little difference flashing the right one, but it's not something to get bogged down with. Personally, I very rarely try a new Radio. I almost never change my RIL.
It's worth mentioning that the above is only really valid for Touchwiz ROMs. AOSP ROMs use OpenRIL and are not compatible with Samsung RILs. Do not use apps like GetRIL or flash Modem+RIL packages on AOSP ROMs. You would have to reflash the ROM if you do this because using a Samsung RIL on your AOSP ROM will likely break your signal.
Also note, Nandroid backups generally don't backup the Radio. Some recoveries may give you a separate option to do so however. The RIL (as part of the ROM itself) is backed up in a Nandroid.
ROM - ROM really stands for "Read Only Memory" which refers to memory that cannot be overwritten. When we talk about an Android ROM, we are really talking about the Android OS which is installed ON the Read Only Memory, of course since rooting, the /system partition where the ROM is installed is no longer read only. It is read / write. Flashing a ROM will over write the entire /system partition with whatever is in the ROM.zip or ROM.tar. Any mods, scripts, themes or apps will be replaced. You can only have one ROM at a time, unless you use one of those funky dual boot kernels.
More advanced layout of the GT-i9300
Here we have a lovely MS paint diagram of the eMMC layout of the GT-i9300/5. Some of this you don't need to know, some of it you do.
1 BOTA0 - mmcblk0p1 - 4 MB
2 BOTA1 - mmcblk0p2 - 4 MB
3 EFS - mmcblk0p3 - 19.7M
4 PARAM - mmcblk0p4 - 8 MB
5 BOOT - mmcblk0p5 - 8 MB
6 RECOVERY - mmcblk0p6 - 8 MB
7 RADIO - mmcblk0p7 - 33 MB
8 CACHE - mmcblk0p8 - 1 GB
9 SYSTEM - mmcblk0p9 - 1.48 GB
10 HIDDEN - mmcblk0p10 - 587 MB
11 OTA - mmcblk0p11 - 8 MB
12 USERDATA - mmcblk0p12 - 11.4 GB
The above sizes are approximate and the diagram is not to scale.
Rooting the phone
When you go through the process of rooting the phone, you have to alter the ROM. Although the risks of this are very minimal, we couldn't technically say it was risk free. The process of rooting puts a binary (called "su") in /system/bin (remember we talked about that earlier?). This binary is what allows the user (you) to run things at an elevated privilidge (super user). That in itself would be quite risky, so rooting also gives you one of the superuser apps (there are 2 - SuperSU and SuperUser, both very good). These apps install to /system/app and act as a gateway. Essentially, these apps prompt you when another application wants "root access" so you can allow it or deny it. It's a form of protection against malicious intent.
Root is often enough for most people who simply want to run a few root apps, but many people will need to replace their stock recovery with a custom recovery. This is because you cannot flash custom roms from the stock recovery. Some methods of rooting give you root AND recovery. Some just give you root, but you can flash a recovery yourself using Odin and download mode. Technically you do not need root to flash a recovery and then flash a custom ROM as the rom will include /system/bin/su and /system/app/SuperSU anyway.
Odin is a useful Windows tool. You'll be using this to return your phone back to stock too by flashing a stock "firmware"
Please read Samsung Galaxy S3 General Sticky Roll-Up Thread ***Stickies found here!** to find all the rooting and flashing guides you need for the GT-i9300
If I were asked my opinion on how to root, I would recommend one of the 2 scenarios.
1) You want root only. No custom ROMs, kernels etc. Just root, just to use root apps.
CF Auto Root Via Odin
Why? Tried and tested method, simple to use. No need to choose what exploit you want to use as it's tailored for your device.
What does it do? It gives you a stock recovery (so can't flash things) and roots the Android OS
The Steps:
1) Download the Latest Odin
2) Download CF-Auto-Root for your model
3) Follow These steps to root
2) You want to flash custom ROMs / Kernels
If you want root on your existing Android ROM, you can do 1) first. Then flash a recovery of your choice (CWM, Philz, TWRP) via Odin
However, if you immediately plan on flashing a ROM, there's no need to root your existing ROM. Simply skip straight to installing a recovery. Backup then flash what you like.
The Steps:
1) Download the Latest Odin
2) Download recovery of your choice CWM, Philz, TWRP
3) Follow The steps to Flash Philz recovery (But for the recovery of your choice)
These steps can also be followed to update recovery to newer versions

Official Updates
Once you have rooted your phone, the phone is classed as "modified" and no longer qualifies for Official Samsung OTA updates.
It is possible to receive official updates (whilst rooted) via Kies, however this will remove root (just like flashing a full stock rom) and if you have any custom themes, kernels or /system modifications, this could really cause some problems to the ROM so it is best to avoid. Of course if you have flashed a custom ROM (even TouchWiz based ones) Official updates are a big, fat No-No.
If you do run custom ROMs, it's best to use their OTA method if they have one, or download from the threads on XDA and flash via recovery.
Flashing - Good practice
Recovery - Custom recoveries are very handy tools. Unlike the stock recovery, they have lots of options. Not only do they allow you to flash custom ROMs, but you can backup your current ROM too. This is called a Nandroid backup. Its a snapshot in time. It backs up your entire device, from the ROM to the Kernel and all your data too. If you restore a nandroid backup, your device will be extactly the same as it was when you took the backup. This means if you took a backup 2 weeks ago and restored it today, you could have lost 2 weeks worth of SMS.. but it is very handy. As soon as you have a custom recovery, a Nandroid backup should be the FIRST thing you do. You should take one before you flash any Mod, kernel, ROM or theme. It really is important, incase you manage to break your device.,
The RIGHT files - Always be careful that you know what you're flashing is for your device and you know what it is. Flashing files (ROMs, kernels etc) for other devices could BRICK your phone. Bricking means that it is beyond normal levels of repair, often meaning it needs the internal memory (which equates to the motherboard) being replaced. very expensive.
NEVER remove power - When flashing something, be it from your computer or from recovery (or mobile Odin), do NOT remove the power. It can corrupt not only what you're flashing but also what you're flashing to. If you corrupt any of your eMMC partitions, you could have Bricked the device.
Read, read and read - Read the development threads before you flash anything. Ensure you understand what you are flashing. Ensure you know the specific procedure layed out by the developer and you follow it closely. Do not ad lib. If you are unsure, ask.
DON'T PANIC - Think you've bricked your device? Dont panic. Stay calm. Dont google "unbrick S3" and flash lots of files you dont understand. There are many types of S3 "brick" (they're not bricks if you can easily recover) and many varients of the S3. Flashign these files could further break your phone and actually brick a not already bricked phone. Nothing for any other variant than the GT-i9300 should be flashed on it. The same goes for the i9305. Never flash for another model number.
Search and Ask - Unsure of something, read the stickies Samsung Galaxy S3 General Sticky Roll-Up Thread ***Stickies found here!** and do a search. Can't find your answer? Ask. It is easier for us to help you understand something before you do it than to fix something after you've broken it.
Provide details - ALWAYS tell us exactly what happened if you are requesting help. Always describe in detail what is happening.
"Flashed my phone now it doesn't work" is useless information.
"I rooted my phone 3 months ago and flashed a custom ROM. I decided today to flash ROM X from recovery Y. I booted into recovery and flashed from my internal SD card. I rebooted the phone and it is not starting up. It is looping at the boot animation" is GOOD information. We need to know What, when, how. We need to know if you followed a guide and which one (links where possible)
Backups
Backups are really important. This is how you can mitigate the risk of losing all your important data. Without these you could have to start again from scratch or worse, need to send your device for repair.
Your entire phone - Nandroid - Recovery
[*]efs - Recovery - EFS backup aapplications
[*]Your apps and data - Titanium backup
[*]SMS - SMS backup+
[*]Photos - Dropbox
[*]sdcards - FolderSync
The reason we backup is multifaceted.
A Nandroid will backup your entire phone. This is usually taken immediately before you flash a mod or a new ROM. Nandroid restores /system and /data. Usually when you flash a mod (kernel, theme, some system app or libs etc) and it causes a bootloop, a simple restore of Nandroid will return your phone as it was and booting again. In fact, you can use an advanced restore in recovery and choose ONLY to restore /system if appropriate
Titanium backup would often be done on a schedule. Every 2nd night or something, maybe once a week if you're daring. These are important for a number of reasons but the most important is if you are flashing a new ROM.
Remember earlier, we talked about all your data and apps being in /data/data and /data/app? Well, Titanium backs that up. When you flash a ROM, you have to perform a full wipe / factory reset before it will boot up properly. This is because you have settings stored in data/data for apps in /system/app that may have changed or no longer exist, or settings different to the settings in the new ROM. These are incompatibilities and these incompatibilities often will prevent a new ROM booting. Of course, a factory reset doesn't fully restore it to it's factory condition. It cannot restore the bootloader, rom, baseband etc because you overwrote these by flashing a new one.
We wipe, we install titanium and we restore all the data/apps and the /data/data related to /data/apps, but none of the data/data related to /system/apps (because that would restore the incompatibilities)
Here is how I restore using titanium backup after a wipe and flash....
Remember if your backup is on external sd, you need to point titanium to the location using preferences > backup folder location...
Go to backup / restore tab and press "click to edit filters" and deselect "system" and press the done tick icon to apply. Then from the previous backup / restore screen, go into the batch screen (another tick icon top right).
From this batch screen, select "restore missing apps with data" by pressing "run". Manually go through every app (yes, even if you have 300 apps) ensuring there's nothing samsung or rom specific there, unticking anything that is...
This should ensure a clean, user only app and settings. You will then need to manually set your system settings (ring tones, email etc)
Warranty
So, as we have discussed, warranty should be considered void once rooted. Technically in the EU, the OEM must prove root damaged your phone to reject warranty, however this is almost never the case.
When the S3 was released, it came with android 4.0.4 (ICS). The bootloader with ICS was normal. If you used Triangle Away once rooted, it would reset your binary counter forever. You may have kept status: Modified until you factory reset but that is not so much a problem.
When the S3 was upgraded to 4.1.1 Jelly Bean, a new bootloader was introduced. You could still reset with Triangle away, however on the next boot, if you had a custom recovery or kernel, the binary counter went back up to 1 again, which can present a problem.
Please see the following scenarios.
1) You just want root. No custom Kernels, no custom ROMs, no custom recoveries.
This is fine. If you root with CF-Auto Root it gives you a stock recovery. Once you reset the flash counter with triangle away, you should be fine.
2) You want root and recovery on a 4.1.1+ S3.
If you have a custom recovery or kernel, you can set triangle away to reset at every boot. The problem is if your phone breaks in such a way that you can never boot into android, but download and recovery mode still work, you're screwed, It goes back up to 1 on boot, fails to boot then you can only reset it with triangle away, which you can't use because it needs you to boot into Android. You see the risk?
3) You want root and recovery on a 4.1.1+ S3.
The alternative to the above is to flash This 4.0.4 bootloader via cwm. It can be reset by Triangle Away, and stays reset forever. Well why aren't we all using this? Because it is NOT SDS safe. This means if you ahev the unsafe internal memory, if you use download mode to flash anything, you risk bricking your device. Read [Important] Sudden Death Fix - Are you covered? for more information.
So it's a choice between:
I risk that under certain conditions, I may not be able to reset the binary counter for a warranty return
or
I have my binary counter at 0 always, but I cannot use download mode.
Please note, you need to run a TouchWiz ROM to use triangle away
Popular misconceptions
USB Debugging is always required for flashing.
Incorrect. USB debugging is an Android setting. It is only applicable within android. This setting does not work in recovery or download mode, so obviously anything done in those modes does not require USB debugging.
When rooting, all your data is lost.
Incorrect. Rooting adds a binary and application to your phone. It does not wipe it.
I need to root to fix my battery by wiping battery stats.
Incorrect. No one needs to wipe battery stats. Please read the wiping battery stats thread linked below:
Battery stats
What's good for you is good for me!
Incorrect. Everyone's usage is different. Everyone's set-up is different. Everyone's environment is different. There is no "Best" ROM. There is no "Best kernel for..." There is no "Most battery efficient baseband". All these things may acti differently for you than they will for me. What I like isn't what you like. Please do not create any "Best" threads.
If I ask the question "Blah blah blah for custom ROMS?", everyone will know what I am talking about
Incorrect. "Custom ROM" and "AOSP ROM" are NOT synonymous. People imagine when they ask about "Custom ROMS" that we know they really mean "AOSP ROMS". We don't. There are TouchwIz based custom ROMs too. We assume nothing.
B]I need yo be on a certain ROM to flash certain other ROMs[/b]
Incorrect. You're overwriting the ROM so why would ot matter what ROM you're overwriting?!
Important threads and resources
A list of important threads and resources...Please read ALL of these threads before rooting.
Mskip's unified toolbox(Root, drivers etc)
Index of Roms, recoveries and kernels
Guide for flashing roms, backups etc
Returning to stock for warranty
Odin flashing guide
Sammobile.com - stock firmwares
Be prepared ahead of time to fix a Brick
rootSU recommends
A few recommendations from me...
RootExplorer
Titanium Backup
Philz Recovery (CWM advanced)
Odin
Heimdall (Linux / Mac odin equivelant
That's it for now. I know this is a lot of information, but I believe this info to be the very least you should know before deciding to go ahead with rooting your S3. Please read it and read it again. Anything doesn't make sense, please ask in this thread and I will gladly help.
If any other seasoned rooters / flashers think there is something salient missing, please post her too. happy to add to it.

Glossary of terms
adb - Android Debug Bridge. This is a Windows or Linux command line tool that can be used to push files to a device, pull them, create directories. Very handy with a custom Kernel if you can't boot and need to get data from the device. This can be downloaded as part of the Android SDK or mskip's unified toolbox mentioned earlier.
AOSP - Android Open Source Project. This is google's code base. This is Android in it's pureset form. Anyone can download this code and build a ROM. It will take some work to build for a specific device however. Even Samsung start with this code at some point.
AOKP - Unofficial development team building ROMs based on AOSP accross a range of devices. AOKP stands for Android Open Kang Project. A play of the AOSP it is based on. Kang means to find / use (or even steal, although not in this case) source code.
baseband - The software responsible for controlling the radio hardware. Essential for network connectivity. Also referred to as "modem" or "radio"
bash - bash is a shell script language. Natively used in unix and linux, it can also be used within terminal emulators on android and scripts. Most mods that are scripts, use bash.
binary - a binary file is the opposite of a text file. It may contain data to be read by the OS rather than a human. It usually contains instructions on how a particular function should be handled.
binary counter - also referred to as flash counter. This is in part of the bootloader, viewed in download mode. The Binary counter increases as you flash non-stock (custom) recoveries and roms and kernels not "signed" by Samsung. The app, triangle away can help a little
boot.img - the kernel is contained within an .img file named boot.img. Not to be confised with sboot.img (bootloader)
bootloader - Bootloaders exist on almost any multi-OS bootable system. Windows has one, linux has one and android has one. It is how the device "decides" which OS to boot into. the user can manipulate hardware buttons during boot to alter which OS the bootloader boots into. It boots into Android by default but it can also boot into recovery or download mode. The bootloader is within an .img called sboot.img
brick - brick refers to a device that has been "bricked". A bricked device is beyond repair. In other words, your phone may as well be a brick, because it cant be a phone any more. A bricked device must be sent to the manufacturer / carrier / service centre for repair. You cannot repair a brick yourself. If you have something that can be repaired, it is not a true brick.
There are 2 types of brick referred to..
Soft brick, where the phone bootloops. These can sometimes be repaired, so for that reason it is not a true brick and I prefer to never use the term "Soft Brick".
Hard Brick. This is what I call a true brick. The phone cannot be repaired by a user. This of course does not extend to replacing parts. Sure, a brick can be replaced by replacing parts. It can't be fixed with external hardware or software however.
busybox - A set of tools to be added to android. Many root apps require busybox to run. It can be installed using an installer from the market. Similarly, most custom ROMs will contain busybox by default
clockwork mod - clockwork mod is a custom recovery
cfq - this is a scheduler (see scheduler). There is some info that can be read here: http://www.alliance-rom.com/community/wiki/i-o-schedulers/
checksum - see md5 checksum
cm - abbreviation for cyanogen mod. See Cyanogen
CPU - central processing unit. This is the brains of the operation. the CPU is what translates all the instructions and processes them. This is the main "power" behind any device. The better the CPU, the faster these instructions can be processed
custom ROM - A Custom ROM can be based on Touchwiz (Samsung stock), or it can be built from AOSP code. It really just means "unofficial" and will usually contain tweaks, fixes and imporvements for your device. A Custom ROM is a complete android replacement.
cwm - abbreviation for (see) Clockwork Mod.
cyanogen - a team of developers spanning multiple devices. Probably the most famous of development teams releasing heavily modified AOSP based ROMs. If there's any AOSP ROM thread for any Android device forum, there will be credits to cyanogen in there.
dalvik-cache - Dalvik-cache is a way of optimising applications. Its a way of ensuring all the dependencies an app requires are "at hand" to speed up use. It is rebuilt at start up when wiped. A de-odexed system will have more dalvik-cache than an odexed one.
de-odex - The act of removing odex from a stock ROM. On Stock ROMs, instead of using a dalvik-cache for system apps, we use .odex files instead. Generally custom ROMs prefer de-odexed configurations as it's easier to wipe and maintain when you make changes to your system.
deadline - this is a scheduler (see scheduler). There is some info that can be read here: http://www.alliance-rom.com/community/wiki/i-o-schedulers/
download mode - Samsung's own mode accessible via the bootloader. Hold Vul down, Home and power (from off) to boot here. Also referred to as "Odin Mode". This replaces the "fastboot mode" that most other devices have.
efs - Important partition / directory on the root of your phone. Ensures the IMEI number is present in the software. Back this up, because if it breaks, it's gone for ever. You need Samsung to repair.
eMMC - Embedded MultiMedia Card. This is like an SD card, but it's embedded in a device. the eMMC is a NAND flash memory chip which acts as internal memory (storage) on the S3.
exFAT - exFAT is a Microsoft proprietary (closed source) file system, used for media (sdcards, USB flash memory, HDD's etc). ExFAT is not natively supported in Linux and AOSP ROMs
ext - ext2, ext3 and ext4 are file systems created specifically for Linux. Our internal memory is ext (or "extended" as it is known). This can sometimes be used to refer to an ext partition, an old school method of partitioning your sdcard to link the internal ext partitions to to increase app space on low memory devices. Ext file systems cannot be read on Windows machines without special applications / drivers installed.
extSdCard - This is referring to the removable Micro SD card. Samsung ROMs mount the rremovable sd card in Android as /extSdCard. Recoveries such as CWM will mount it as external_sd. Both of these terms are valid, but it depends if the phone is booted to Android or Recovery. In AOSP ROMs, the removable SD card is often mounted as /sdcard1
FAT32 - another file system which is quite old now but still a good one. This is the only file system that is compatible with all devices unconditionally. The downfall is a maximum file size limit of 4 GB. Windows disk management GUI can only format up to 32 GB. Windows command lien tool "diskpart" can format up to the max volume size of 2 TB, as can many 3rd party tools such as easeus.
flash - Flash means a few things. It can refer to the fact that our internal memory is NAND Flash (Solid state) memory. It can also be the act of "flashing", or "to flash", meaning to install to flash memory. This doesn't really refer to installing an .apk. Rather, it refers to bigger, OS, System or device wide altering modifications (Kernels, recoveries, ROMs etc). Always back up before flashing.
Custom ROMS are usually flashed from your SDcard via recovery, as are kernels and basebands however, kernels and basebands usually can come in .tar format which means odin/mobile odin can flash them too from your computer/sdcard respectively. Rule of thumb, .zip from sdcard via recovery. .tar from sdcard via mobile odin or from computer using odin
flash counter - See binary counter
framework - The android frameworks are a standard structure within android that the OS is built around. It determines things like policy (how the OS should manage an event). It controls everything from notification behaviours to the theme. Anything visual within Android with exception to the notification area is controlled by framework-res-apk. AOSP and most manufactured ROMs only have 1 frsamework-res, however Samsugn Touchwiz ROMs alsu have a twframework-res.apk for Samsung only visuals.
gapps - Google Apps (gapps). AOSP ROMs like Cyanogen, have been asked by google to not include the google apps packages, which are proprietary to google (meaning not open source). This means that when you download these roms, you need to flash a gapps package separately. They are usually available as link in the ROM thread
governor - governors are included with kernels. I will not go into too much detail but essentially, the governor is a set of instructions which tell the kernel how to manage the CPU. It can control when the CPU ramps up or down, or how long it stays at a certain frequency. Most custom kernels come with a selection of governors to choose from using things like Set CPU. The governor settings for each can also be fine tuned or tweaked to y7our liking.
hotplug - this is a governor (see governor). Governors are explained in great detail here: http://www.alliance-rom.com/community/wiki/governors-explained/ - not all these governors are valid for our device, but it's a good technical read.
jig - a small usb device that plugs into the USB port of the S3. Designed to provoke "bricked" S3's to boot to download mode in an attempt to help recovery the device.
kernel - The kernel, it is said - is the "beating heart" of Android (or any OS for that matter). It sit's between the application layer (Android, applications etc) and the Hardware (CPU, Memory) and handles all transactions between the physical and the virtual. It passes information and instructions inbetween and translates. Very important stuff!
lulzactive - this is a governor (see governor). Governors are explained in great detail here: http://www.alliance-rom.com/community/wiki/governors-explained/ - not all these governors are valid for our device, but it's a good technical read.
md5 checksum - md5 checksum is a way to verify that a zip (or file) is not corrupt. A developer or uploader may provide a hexidecimal string called an md5 checksum. This checksum is a test done on the files that gives it a unique string based on it's contents. If you download the file and check the checksum and it does not match, it means the contents of the file have altered, usually meaning it is corrupt and shouldn't be flashed.
An md5 checksum is easy to check on android. My preferred method is using an android terminal emulator. Lets imaging I have a file on my external sd card called "rom.zip"...
In terminal emulator, type "md5 /mnt/extSdCard/rom.zip" and the terminal will give you an md5 string, If this matches the uploader's string, you're good to go.
If you're downloading something on Windows and then transferring it to your phone, it's a good idea to check md5 on both.
Linux is pretty much the same except the command is "md5sum"
For windows: http://www.winmd5.com/
modem - see baseband
NAND - NAND is a type of Flash memory. If anyone say's "NAND" to you, they are talking about the internal memory (Storage) of your device.
nandroid - nandroid refers to a backup taken or restored via custom recoveries. This is a universal term, although nowadays most recoveries simply say "backup" or "restore", but it is a nandroid backup they will be taking or restoring, which got it's name from the NAND flash memory that Android devices use internally. Nandroids are often only compatible with the variant of recovery you have. For example, a backup taken with CWM may not be compatible with TWRP, unless they introduce a compatibility setting in the future, which Philz recovery has done.
noop - this is a scheduler (see scheduler). There is some info that can be read here: http://www.alliance-rom.com/community/wiki/i-o-schedulers/
oem - Original Equipment Manufacturer. The OEM ROM for us is teh one the Manufacturer (Samsung) shipped with the phone.
overclock - overclocking is to set the CPU clock speed (frequency) higher than intended by the manufacturer. For example, the S3 has a 1.4 GHz (1400 MHz) maximum clock speed. With the use of a custom kernel and an application such as Set CPU, you can set this higher, to 1.6GHz or maybe even higher.
The risk is that the higher clock speed uses more voltage and voltage = heat. A higher clock with higher heat can permanently damage the CPU. Overclocking is usually paired with undervolting for these reasons. Another risk is instability. Each individual CPU has different tolerances due to imperfections in the manufacturing process. My CPU may be stable at 1.6 GHz, yet yours may be stable at a higher or lower clock. The side effects you will see here will be random reboots when the phone is under load.
pegasusq - this is a governor (see governor). Governors are explained in great detail here: http://www.alliance-rom.com/community/wiki/governors-explained/ - not all these governors are valid for our device, but it's a good technical read.
radio - see baseband
RAM - Random Access Memory. Great explanation here: http://www.androidcentral.com/ram-what-it-how-its-used-and-why-you-shouldnt-care
scheduler - built into kernels, there are schedulers to determine how CPU load is spread across different tasks. There are also read / write schedulers that spread out read and write operation priorities across the internal memory. Like Governors, there are different types of scheduler available.
sio - this is a scheduler (see scheduler). There is some info that can be read here: http://www.alliance-rom.com/community/wiki/i-o-schedulers/
stock - Imagine your phone is on a shelf in a shop. The phone is "stock" of that shop. If anything is referred to as "stock", this means standard for the device / as it was when shipped / as per factory set up. It is the opposite of custom. Some people refer to AOSP ROMs as "Stock Android". This may be the case for some phones, like the Nexus devices, but generally this is incorrect. Stock is whatever the phone came with as standard.
triangle away - an application designed to reset the binary counter. Warning, newer bootloaders (4.1.1+) now re-increment the binary counter at boot, so some trickery is required to get the counter to remain 0. This can be troublesome if you need to return for warranty.
undervolt - to undervolt is to lower the voltage used, either by the CPU or the GPU. Kernels assign a static voltage to each clock speed. For example, 200 MHz = 900 mV, 300MHz = 925 mV. Undervolting is the process of lowering this voltage staticaly for each clock speed, which potentially will save battery, although many people think it wont have much affect. Beware, undervolting too much can cause instability. When a clock frequency hasn't got enough power to sustain, the device will likely reboot or power off.
vanilla - meaning plain. Often used to refer to the "pure" android. AOSP without OEM skins, UI's and Launchers etc. The people who incorrectly use "Stock" to describe AOSP, really mean vanilla.
zzmove - this is a governor (see governor). Governors are explained in great detail here: http://www.alliance-rom.com/community/wiki/governors-explained/ - not all these governors are valid for our device, but it's a good technical read.

Every phone specific section needs something like this.
Very well done!:beer:

abaaaabbbb63 said:
Every phone specific section that can be rooted needs something like this.
Very well done!:beer:
Click to expand...
Click to collapse
Now you need the difficult part, people to actually read it.

Nice work @rootSU
Needs to be stickied and a humongous "READ ME" sticker attached! :thumbup::thumbup:
Edit........Reported©®™ so it gets stickied!

Its getting noobs to actually bother to read is the problem .
jje

True but i'll start with the "read my sig" method. At least if it's here, thats a small part of the battle. Anyone anything to add to post 1? Slappy? jje?
Sent from my GT-I9300 using Tapatalk 4 Beta

Add backup EFS first ??
jje

Some of the stickies in the roll up thread are badly out of date, you also might want to link to Mike Skip's toolbox, which reduces the chances of bricking considerably.

rootSU said:
True but i'll start with the "read my sig" method. At least if it's here, thats a small part of the battle. Anyone anything to add to post 1? Slappy? jje?
Sent from my GT-I9300 using Tapatalk 4 Beta
Click to expand...
Click to collapse
Seeing as this may well attract lots of attention, possibly add a reminder about reading the rules and link? I know it's not relevant particularly, but any chance to ram the message home is good :thumbup:

rootSU said:
True but i'll start with the "read my sig" method. At least if it's here, thats a small part of the battle. Anyone anything to add to post 1? Slappy? jje?
Sent from my GT-I9300 using Tapatalk 4 Beta
Click to expand...
Click to collapse
Instead of [REF] you should write [BOOBS]. That would attract attention.

Added:
Link to forum rules and "post in Q&A" threads
Important links and resources
efs (in partitions)
backups

I'm sure there's still loads missing, I just can't think of much so all suggestions welcome.

Added "The advantages of rooting". Miss anything?
EDIT > added disadvantages too.

OP, I have moved your thread to the q&a section and stuck it. It is a great FAQ type thread and will serve a good purpose being stuck where people go to ask these types of questions. :good:
Towle
XDA Moderator

Towle said:
OP, I have moved your thread to the q&a section and stuck it. It is a great FAQ type thread and will serve a good purpose being stuck where people go to ask these types of questions. :good:
Towle
XDA Moderator
Click to expand...
Click to collapse
Thanks @Towle
Sent from my GT-I9300 using Tapatalk 4 Beta

I've updated the following to sections to read as below:
Bootloader - this is what handles what you boot into. When you see the black Galaxy s III text, thats the bootloader. Its job is to handle the boot. It is responsible for booting into android, or if you manipulate the buttons in a certain way, it will boot into recovery or download mode. PLEASE NOTE, i9300 Bootloader is NOT LOCKED. DO NOT TRY TO UNLOCK IT.
Download mode is part of the bootloader itself. Again, it is a mini OS. It is designed for flashing stock (official) ROMs onto the phone. It is also used by Samsung to detect the status of your phone (if you have modified it or not).
If you have an official ROM above 4.1.1, Your bootloader flash counter in download mode will change to "1" at every boot, if you have a custom kernel or recovery - even if you reset it with Triangle Away. See the return for warranty link later in this post to get around this.

oops
first i thought it was typo but after i check out dictionary i just learn a new and rare word ... teh ....:fingers-crossed:

qtwrk said:
oops
first i thought it was typo but after i check out dictionary i just learn a new and rare word ... teh ....:fingers-crossed:
Click to expand...
Click to collapse
Not new, not rare:
http://en.wikipedia.org/wiki/Teh

[Q] N7 APX mode only - full recovery?

Hi all,
Has anyone followed Rayman's excellent article the-inner-workings-of-secure-boot-key-and-nvflash and fully recovered a N7 from APX only mode?
I have this situation which I think resulted from the battery dying during the 4.4.2 update - Doh I know, but thought I had enough juice to complete the update.
Rayman says the required files will be made available but I cannot find them anywhere

Since every motherboard has a unique key, there is no generic blob. To be able to recover your N7, you will need a backup of it, but it's impossible to make if your device is dead.
Try to send it to Asus/Google.

Erovia said:
Since every motherboard has a unique key, there is no generic blob. To be able to recover your N7, you will need a backup of it, but it's impossible to make if your device is dead.
Try to send it to Asus/Google.
Click to expand...
Click to collapse
Did you read the article? Sounds like you can use the sbk which is a hash of the cpuid...

Nope, but why don't you ask around in the flatline topic?

Erovia said:
Nope, but why don't you ask around in the flatline topic?
Click to expand...
Click to collapse
too much of a noob to post on the forum, but thanks for the pointer.
FYI Raymans article. It does sound possible to bring it back, but there was no follow up with the required files;
What is Secure Boot Key and how does it work?
I've been getting lots of questions about this, so here is some simple background:
The secure boot key is an AES128 encryption key that can used to encrypt various data on the flash memory. It's a generic nvidia tegra2 thing, that the manufacturer can optionally use to make their device more "secure".
When the SBK is set, it's stored in a one-time-programmable "fuse". This also means that now that the key is out, they can't change it on already released devices, only new devices.
When the tegra2 starts up, the AES key is available to the hardware AES engine only. E.g. not even the bootloader can read it back! However, the bootloader can *use* the key to encrypt whatever data it wants through the hardware AES engine. And here is the explanation why the blob flashing method actually works! The bootloader checks for the blob in the staging partition and encrypts and flashes it as needed.
Once the bootloader is done, it clear the key from the AES engine which makes it impossible to encrypt or decrypt things from within the OS.
So what happens when it boots into APX/Nvflash mode?
The basic APX mode is stored in the BootROM and hence can never be changed. It appears to accept only a very limited range of commands, and each command needs to be encrypted using the SBK to be accepted. If it receives a command that's not properly encrypted, it disconnects the USB and appears to be off. This is the dreaded "0x4" error that people have been getting when attempting to get nvflash working.
It should be noted, that even with the SBK inputted into nvflash, most regular nvflash commands won't be available. I'm still not entirely sure why (and I can't rule out it will change).
What *is* available, is the nvflash --create command. What this command does is repartition and format all partitions, set bct and odmdata and send over all needed partitions to the device (and encrypt them as needed). This means a full recovery is possible, but regular ability to flash e.g. just boot.img or read partitions off of the device is not possible at this point.
So what do we need for nvflash?
In order to get a working (e.g. --create) nvflash, we need a few bits of information as well as some files:
◦Secure Boot Key
◦BCT file (boot device setup, ram configuration and a bit more)
◦ODM data (board-specific bit-field specifying various board settings. *Needs* to be correct
◦flash.cfg (e.g. list of settings and names/identifiers of partitions.
On top of these files, we also need all the partitions, e.g. bootloader.bin, boot.img, recovery.img and system.img. Luckily, these partition files are available in official ASUS updates and can be extracted from the blob file using my blob tools
The first four peices aren't readily available, but through lots of effort and a good deal of luck, we have managed to recreate the needed files. Secure Boot Key has already been released (note that this was by far the hardest!) and the rest will most likely follow over the weekend. Keep in mind that we want to keep this legal, so don't expect us to release any ready-made packs for unbricking! We will however make the recreated files available. Since these are recreated and not actual ASUS files, there should be no problems with them.
I hope this helps give a better understanding of how and what secure boot key is and what it gives us.

ASUS Zenpad Z10 (ZT500KL - Verizon)

I am wondering if there's a working temp root (or even perm root without bricking Android 6.0 OS) for this Verizon exclusive ASUS Zenpad z10, as I am now looking for a way to unlock the bootloader as most of unlock commands are intact in the bootloader itself - only "Allow OEM unlock" tab is missing, so I will have to extract the bootloader partition and system configuration partitions - the problem is root.
That way I can get started on putting TWRP after unlocking the bootloader.

Already tried temp root the manual way; running su in /data/local/tmp after giving it the correct permission. All I got was "1" in shell, basically along the line, "f*** you, I am not letting you run as root." Why temp root? I have to do it so I don't accidentally brick the tablet - all I want to do right now is to extract the vital partitions and examine every single of them to see if I can indeed get "Allow OEM Unlock" or some bootloader unlock approval commands so I can get ASUS ZenPad z10 unlocked. And there's absolutely NO ASUS update RAW file extractor tool to date.
Apparently it looks like ASUS and several other OEMs don't bother going the extra miles getting the bootloader locked down as tightly as Evil Moto, or worse, Samsung. They just simply remove "Allow OEM Unlock" tab and call it a day. (Beware, though, Qualcomm second stage bootloader varies so much among OEMs which is why I have to take a peek into the partition image and see what I can find.)

Although I'm of no help to you, I will be following this. I just picked up one of these today. There's simply not a lot of information out there.
Sent from my SM-N920V using XDA-Developers mobile app

Apparently, due to the way Android Marshmallow security system works, all I can do is wait (and probably trawl the forums, although I doubt it will happen unless I pull the kernel from the eMMC SSD which is technically a catch-22 situation, as I have to root before I can touch the kernel or even "Allow OEM Unlock" configuration file in some partition - a bit like chicken and egg paradox).
UNLESS there is a temporary root that works by abusing the Dirty Cow exploits, and allows me to pull the eMMC SSD partitions so I can look through the files contained within the pulled partitions.

Discovered that this tablet do have root detection system - it basically tattle to Verizon. Those bastards. Nevertheless, I would need to find a way to allow OEM unlocking (which I had gut feeling that it's there somewhere) without it getting all antsy.
The more I dig into it, the more I just want the bootloader itself to be unlocked. It never cease to amaze me how far Verizon will do anything to be so nosy.

Slightly off topic, but since you seem to be the only other person here who has this tablet... Have you attempted to figure out a simultaneous charge and data option? I've tried several different cables and adapters so far without much luck.
Sent from my SM-N920V using XDA-Developers mobile app

Good question, however I don't really have a computer with USB-C port, if you meant that (been considering doing a new computer build at some point which then I get better idea how this tablet function on USB-C doing general stuff via USB - it may be by the time this tablet is running CM 14.x, once we figure out how to unlock the bootloader, so it may be hard to say how it will function with stock ROM). On the other hand, regular USB is usually limited to 500 milliamps (1/4 that of bundled charger), so may not charge because of the current requirements that may have to be met within the power management firmware (meaning about 1 Amp - which many DIY PC motherboards now meet the minimum specifications).
However, the screen backlight consume the most juice so you may try turning off the screen after you have mounted the MTP drive (due to MTP security in Android - it will stay mounted after you plug it into computer and turn off the screen however), which then you may be able to charge it. It will take a while as there's a huge battery inside (7.8 Amp hour rating). You would have better luck with a computer that conforms to USB Power Delivery specifications (USB 3.x already support that - USB 3.x ports are usually blue, BTW, so it's kind of hard to miss).

Finally extracted the files from ASUS' Verizon ROM image - ZArchiver Pro apparently can read ASUS' RAW image file, much to my delight. Now, I will have to figure out how to treat the Qualcomm second-stage bootloader (aboot.img) and few other partition images as a disk drive so I can figure out how to enable OEM unlock so I can get this thing unlocked (and I will disassemble the Linux kernel - boot.img - and recovery toolkit - recovery.img - so I can get ball rolling).

Tried to unpack the boot.img and recovery.img - the boot unpacker failed with "Android boot magic not found". Oh well, I will try to keep at it.

Alright, I think it's because the kernel is compiled in ARM64 assembly codes (thus not really standard as far as most Linux kernel boot.img unpackers are concerned), so now I will try one that can and will touch 64-bit kernel image. Then keep on probing the entire recovery and boot images for potential clues to the OEM unlock configuration (and as well as system.img - one problem is, Linux refuse to touch the system.img even though it is evidently the EXT4 FS SSD image).

Anyone who know of decent multi-faceted disk image extractor (the ones that can touch the non-standard disk image, including boot.img and recovery.img which doesn't have the standard "ANDROID!" magic), let me know. I have been googling anywhere, and it's difficult to pull the vital files which I can look for important files. System image, however, may have to be analyzed for type of fuse file system (if it's not sparse file system, then it's definitely an odd SSD image).

Another ZenPad owner checking in. I had to go to asus's site to say this thing even is. The model number P00l is absolutely worthless.
Anyways I've ordered a laptop with native USB 3.0 so will poke around where I don't belong soon.
I absolutely hate this UI, who is to blame? Asus? Verizon?

Verizon. They usually make the call in firmware development (Can you say who locked the bootloader?) and yeah, they're famous for horrible stock firmware. Hence, I am figuring out how to unlock the bootloader just so we can get rid of garbage on the tablet. ZenUI is on ASUS though.
Nice hardware, bad software. That's kind of a shame. It will hurt even less when we get CyanogenMod 14.x operating system on it.
EDITED: the model number is zt500kl, not superfluous "P00l" - I had to figure it out, and GSM Arena had the model number (and bootloader apparently confirmed that).

Did a bit researching in how the "Enable OEM Unlock" tab in other devices' Developer Option works; the toggle goes into persistent data block (hitting home in PersistentDataBlockService.java file), thus going into factory device configuration file in the syscfg partition (mmcblk0p28) - however, I will need to successfully extract the system.img in the ASUS Verizon OTA, or if we can successfully root this thing, I can go ahead and pull some apps and files and see how Allow OEM Unlock can be accomplished.
Correction: it's actually config (mmcblk0p13) as the build.prop said ro.frp.pst points to /dev/block/bootdevice/by-name/config - this is where it will get tricky; the config.img file is actually blank - it's on the physical soft efuse partition on the eMMC SSD itself, which there will be some legit data. Which is essentially untouchable until we get shell root of some kind to extract it. After I get to it, all I have to do is to find out the magic value to "blow" the last value sector in soft efuse partition to allow OEM unlock (note - soft efuse is just that, you can relock the bootloader when you write blank partition image to reset the efuse values contained herein, so beware the official OTA update image package).

Asus ZenPad ZT500KL
I just purchased this tablet yesterday. If you need me to test anything feel free to pm me.....
Thanks for working on this, if I can be of any help. do not hesitate to ask.
Dr. Mario said:
Did a bit researching in how the "Enable OEM Unlock" tab in other devices' Developer Option works; the toggle goes into persistent data block (hitting home in PersistentDataBlockService.java file), thus going into factory device configuration file in the syscfg partition (mmcblk0p28) - however, I will need to successfully extract the system.img in the ASUS Verizon OTA, or if we can successfully root this thing, I can go ahead and pull some apps and files and see how Allow OEM Unlock can be accomplished.
Correction: it's actually config (mmcblk0p13) as the build.prop said ro.frp.pst points to /dev/block/bootdevice/by-name/config - this is where it will get tricky; the config.img file is actually blank - it's on the physical soft efuse partition on the eMMC SSD itself, which there will be some legit data. Which is essentially untouchable until we get shell root of some kind to extract it. After I get to it, all I have to do is to find out the magic value to "blow" the last value sector in soft efuse partition to allow OEM unlock (note - soft efuse is just that, you can relock the bootloader when you write blank partition image to reset the efuse values contained herein, so beware the official OTA update image package).
Click to expand...
Click to collapse

Due to a potential brick risk due to entering the wrong magic value, I'd rather that we have temporary root or shell root first so we can pull the soft efuse partition and some setting files from ASUS settings.apk / systemui.apk to figure out the FRP values just so we don't accidentally lock ourselves out or worse.
Once we find out what it is, we can go ahead and test that (kind of wish I have extra money to get a sacrificial tablet to take a jab at the bootloader, as Verizon love to make it risky).

Oh, and BTW, this tablet also have several hardware disabled by Verizon, like the fingerprint scanner (home button). All the reasons to get CyanogenMod, crDroid and any of the favorite CyanogenMod derivatives on it.

Dr. Mario said:
Oh, and BTW, this tablet also have several hardware disabled by Verizon, like the fingerprint scanner (home button). All the reasons to get CyanogenMod, crDroid and any of the favorite CyanogenMod derivatives on it.
Click to expand...
Click to collapse
I'm within my 14 day return period ...., send me a pm
Sent from my iPhone using Tapatalk

Give me a bit time and I will figure out what to poke in config partition and we can go from thereon. Some one-click root (like KingRoot) are questionable so it's hard to know as of yet, due to secure boot which will prevent the tablet from booting all the way to password request lockscreen if it notice something (and there's a root detection app inside /system/priv-app directory - even though Verizon doesn't care about me, whether I hacked it or not, given my history of hacking several Qualcomm-based smartphones, especially RAZR M, even though it may probably be because I paid all my bills on time).

Dr. Mario said:
Give me a bit time and I will figure out what to poke in config partition and we can go from thereon. Some one-click root (like KingRoot) are questionable so it's hard to know as of yet, due to secure boot which will prevent the tablet from booting all the way to password request lockscreen if it notice something (and there's a root detection app inside /system/priv-app directory - even though Verizon doesn't care about me, whether I hacked it or not, given my history of hacking several Qualcomm-based smartphones, especially RAZR M, even though it may probably be because I paid all my bills on time).
Click to expand...
Click to collapse
Sounds good. Didn't even know the tablet had a fingerprint reader ( home button)
Sent from my iPhone using Tapatalk

[DEV] LG G5 VS987 bootloader unlock

LG G5 VERIZON VS987
Unofficial bootloader unlock
In-Progress
This is a project to disassemble and rebuild an unlocked aboot that passes the sbl loader test, thus allowing installation of custom kernels, read/write access to system, TWRP recovery, and custom ROMs. You can follow the progress or ask questions about it here, or offer your help to make my life a little easier. Donations help, too, especially to maintain the machine these VMs and tools run on.
PHASE 1 - RAMDISK EXTRACTION: DONE
(Attachment 2 & 3): I have extracted the ramdisks from the KDZ bin data. I have the ramdisks and accompneying kernel files in tar files.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
PHASE 2 - TARGET DISASSEMBLY: DONE
(Attachment 1): I have disassembled the ELF binaries. objdump is sloppy, but I was able to get to the branch instructions and find my offsets for each subroutine. I also located the factory signature data for verification by sbl.
PHASE 3 - CERTIFICATE EXTRACTION: IN-PROGRESS
Extracting and parsing the PCS data. It's needed for verification by the sbl to avoid security fail when booting a modified aboot.
PHASE 4 - UNLOCKING NEEDS DONE
Re-coding aboot to accept a bootloader unlock, and access to fastboot.
PHASE 5 - RECOMPILATION AND TESTING (ABOOT)NEEDS DONE
Re-building the aboot binary and testing it.
PHASE 5 - LITTLEKERNEL AND SYSTEM ACCESS (BOOT)NEEDS DONE
Puling apart stock kernel, grabbing needed modules, disabling SELinux and dmverify.
Analysing system image, removing boot-time LG security checks, applying root.
PHASE 6 - TWRP BUILD (RECOVERY) NEEDS DONE
Building user-friendly recovery image.
PHASE 7 - BUILD TOT FILE NEEDS DONE
Package it all into an LGUp Flashable TOT and release.
If you would like to help with this project, please make yourself known.
If you would like to donate to show thanks, the button is underneath my name or in my profile.
If you have a comment or can leave documentation or advice, do so below ​

Nice.. Hoping for the best

LupineDream said:
LG G5 VERIZON VS987
Unofficial bootloader unlock
In-Progress
This is a project to disassemble and rebuild an unlocked aboot that passes the sbl loader test, thus allowing installation of custom kernels, read/write access to system, TWRP recovery, and custom ROMs. You can follow the progress or ask questions about it here, or offer your help to make my life a little easier. Donations help, too, especially to maintain the machine these VMs and tools run on.
PHASE 1 - RAMDISK EXTRACTION: DONE
(Attachment 2 & 3): I have extracted the ramdisks from the KDZ bin data. I have the ramdisks and accompneying kernel files in tar files.
View attachment 4016279
View attachment 4016280
PHASE 2 - TARGET DISASSEMBLY: DONE
(Attachment 1): I have disassembled the ELF binaries. objdump is sloppy, but I was able to get to the branch instructions and find my offsets for each subroutine. I also located the factory signature data for verification by sbl.
View attachment 4016278
PHASE 3 - CERTIFICATE EXTRACTION: IN-PROGRESS
Extracting and parsing the PCS data. It's needed for verification by the sbl to avoid security fail when booting a modified aboot.
PHASE 4 - UNLOCKING NEEDS DONE
Re-coding aboot to accept a bootloader unlock, and access to fastboot.
PHASE 5 - RECOMPILATION AND TESTING (ABOOT)NEEDS DONE
Re-building the aboot binary and testing it.
PHASE 5 - LITTLEKERNEL AND SYSTEM ACCESS (BOOT)NEEDS DONE
Puling apart stock kernel, grabbing needed modules, disabling SELinux and dmverify.
Analysing system image, removing boot-time LG security checks, applying root.
PHASE 6 - TWRP BUILD (RECOVERY) NEEDS DONE
Building user-friendly recovery image.
PHASE 7 - BUILD TOT FILE NEEDS DONE
Package it all into an LGUp Flashable TOT and release.
If you would like to help with this project, please make yourself known.
If you would like to donate to show thanks, the button is underneath my name or in my profile.
If you have a comment or can leave documentation or advice, do so below ​
Click to expand...
Click to collapse
Nice to know there is people working on an unofficial bootloader unlock for the lg g5 good job !
I would also like to ask a question if you don't mind : once done, does this variant of the g5 is similar enough to some variants to be able to "port" the unlock or the approach is too specific to the variant ?

Im currently grabbing a more android build-friendly release of Xenial. Google does not support building from a x86 OS. When I tried to git the "official" google toolchain in consideration of doing things 100% correct in a VM, I ran into the dreaded "x86 build host unsupported" problem. The VM host I am grabbing is here: https://forum.xda-developers.com/chef-central/android/guide-how-to-setup-ubuntu-16-04-lts-t3363669 I am going to need the google build source for the kernel, plus the makefiles for the generic arm v7a neon arcitecture. Best do it all the right way instead of having to re-do it all later.
In the meantime, I am cramming some thumb-2 tutorials. La la la~

nalf3in said:
Nice to know there is people working on an unofficial bootloader unlock for the lg g5 good job !
I would also like to ask a question if you don't mind : once done, does this variant of the g5 is similar enough to some variants to be able to "port" the unlock or the approach is too specific to the variant ?
Click to expand...
Click to collapse
I'd have to check the aboot and boot / kernel to see if there's any major differences. Since this is a direct aboot disassembly, it's varient specific, but I will surely be checking if the approach can be applied to different varients' booters via scripting or some such thing. It would mean coding of a patchfile and a TOT builder, adding an entire extra level of complexity, but I'll get to your answer as soon as I have finished with this model.

Howdy there,
Looks like you're attempting to modify an element in the Qualcomm Secure Boot chain (aboot in this case) - unfortunately what you're trying to do won't work.
I don't want to rain on your parade here, or discourage you from learning something for the sake of learning it but simply modifying a component of the boot stack by recompiling it and slapping the same signatures on it isn't possible.
I'd recommend you take a look at any of the awesome posts on XDA about how the Secure Boot 3 (is there a newer version?) process works as you'll see that each step in the boot process (pbl -> xbl -> {tz, rpm} -> aboot) is verified using RSA public/private key signatures.
You won't be able to simply extract the certificate chain from the old aboot (LK) image and append it to your source-built LK, as the hash embedded in the certificate chain won't match the computed hash of the LK application.
Your next thought would be "what if I could find where the validation function is called and replace it?", but you'll find that each step in the boot process calls TrustZone's secureboot verification functions which rely on data stored in qFuses.
Even then, the function TrustZone itself calls is actually provided by PBL and is burned into the chip itself.
Essentially, the path you're trying to take is one that Qualcomm has thoroughly hardened the boot process to protect against.
I'm not trying to discourage you from learning, since doing this sort of reverse engineering is very fascinating and a fun learning exercise - I just want to let you know that if you try to flash a modified aboot image that you'll end up with a brick (and no way that I'm aware of to recover short of soldering up some UFS lines and reflashing like that since iirc even JTAG is disabled now and we lack signed programmers for USB recovery).
Check out one of the Secure Boot PDFs that are available on Google/XDA and you should see what I mean.
Best of luck to you, and happy learning!

LupineDream said:
(Attachment 2 & 3): I have extracted the ramdisks from the KDZ bin data. I have the ramdisks and accompneying kernel files in tar files.
View attachment 4016279
View attachment 4016280
PHASE 2 - TARGET DISASSEMBLY: DONE
(Attachment 1): I have disassembled the ELF binaries. objdump is sloppy, but I was able to get to the branch instructions and find my offsets for each subroutine. I also located the factory signature data for verification by sbl.
View attachment 4016278
Click to expand...
Click to collapse
Like thecubed said, by flashing a modified aboot you'll brick the device, but the fact that you figured out how to extract the aboot image is EXTREMELY impressive! If you wouldn't mind it would be very helpful if you make a guide on how you did that or if you could post your extracted aboot files that would be much much appreciated An insight on how aboot for the G5 works would be something very nice to have

thecubed said:
Howdy there,
Looks like you're attempting to modify an element in the Qualcomm Secure Boot chain (aboot in this case) - unfortunately what you're trying to do won't work.
I don't want to rain on your parade here, or discourage you from learning something for the sake of learning it but simply modifying a component of the boot stack by recompiling it and slapping the same signatures on it isn't possible.
...
[ removed in quote ]
...
Best of luck to you, and happy learning!
Click to expand...
Click to collapse
Thank you for the inspiration. The task has been a thorough crash-course in arm v7a NEON Cortex technology and thumb-2 assembler. I was concerned when I saw the TrustZone documentation from ARM and the ACEP (Arbitrary Code Execution Prevention) stack. Your mention of qfuse brings back memories of the Samsung "Golden Routines" folly.
Unfortunetly I wasn't a backer of the Raspberry PI, but there are other PCBs with GPIO pins. My reason for mention this is the JTAG connundrum you mentioned. It is null and void to a soldering gun, a few resisters ($2-$3, and the on-chip ARM debugging interface included in most integrated ARM chipsets. PCBs that run Linux with a GPIO pin array are the cheapest and most flexable solution to an expensive piece of lab / R & D equipment (JTAG), and the impact on the bank account is a fraction of what it would cost the end-consumer.
Hash collisions and backprop neural nets. What? OK, I'll explain. Most reverse engineering begins with monitoring the usual operation of the device as you are aware. Approach 1 involves training a backpropping neural network to recognize (within a reasonably less amount of computation) a hash collision. Of course, you aren't going to be getting to these pre-coded hashes without breaking the RSA chain (thats 100 zeros O__O ) , this is fixed by monitoring the debug interface we both mentioned earlier, at power-on. ARM processors work such that they cannot do DMAC (direct memory access computation), so the values need to be pushed into registers and acted on as plain byte, then pushed back to memory. Sniff, find out what's coming to/from the qfuse memory bus area into registers, dump the data, and you'll have your root CA with luck. You'll be looking for the in operand, that is, the one that is to be acted on in the cipher that is incoming from qfuse. Cycle-timing to ignore the rest of the computations for this byte, you're basically waiting until qfuse pushes the next byte of its keys into a register and grabbing it in the same cycle the instruction is working on it.
That said, with a $100 and a soldering gun and a laptop, you have your RSA key direct from CPU memory via the debug interface. After you've got your root CA, would it be feasable to start decrypting the intermediate CA chain for each component of boot until you get the hash? In theory this should work without brute-force, but a lot of time in a code window and with an oscilliscope. Once you've had the decrypted hash, you can begin to look for a hash collision. There are open source tools that will find hash collisions in an hour or less using neural nets. Write an aboot that complies to this hash collision, flash it, and qfuse will not be able to tell the difference.
Thats my theory on exploiting the fact ARM needs to do its computations in an area that is accessable to the debug interface. Of course my theory falls apart if the TrustZone chipset has its own processor.
Honestly Annoying said:
Like thecubed said, by flashing a modified aboot you'll brick the device, but the fact that you figured out how to extract the aboot image is EXTREMELY impressive! If you wouldn't mind it would be very helpful if you make a guide on how you did that or if you could post your extracted aboot files that would be much much appreciated An insight on how aboot for the G5 works would be something very nice to have
Click to expand...
Click to collapse
I'd be okay with writing such guide as long as it followed community guidelines. I should not be posting disassembled code and analysis if it's against the rules to do so. If a mod could clear this for me....

After searching around I located the true specs for the G5. It's a Snapdragon 820 SoC. It runs the new ARM v8A instruction set.
More detailed information here -> http://www.tomshardware.com/reviews/snapdragon-820-performance-preview,4389-2.html.
More specifically, it's on the msm8996 platform: http://system-on-a-chip.specout.com/l/1170/Qualcomm-Snapdragon-820-MSM8996
Phones with this arcitechture: https://www.kimovil.com/en/list-smartphones-by-processor/qualcomm-snapdragon-820-msm8996
Xiaomi Mi5 has official bootloader unlock via a tool (reverse engineer to work with our platform?)
HTC 10 bootloader on certain models can be oem-unlocked.
Lenovo ZUK Z2 bootloader can be oem-unlocked
LG V20 bootloader can be oem-unlocked, and is the closest in hardware to our G5!
Perhaps stealing a kernel and boot from a similar varient that allows it, signing it with our key, hash-matching it? It all runs on the same platform with the same instruction set. Most of these phones have unlockable bootloaders.
I'd say the best target would be that unlock tool by Xaoimi. Its usually the third party vendor's tools you can find the biggest security holes in. xD From their documentation, it isn't an "enable OEM unlock" switch in Developer Options used to enable the unlock, the tool itself actually works on the bootloader. Perhaps the tool uses a feature of the MSM8996 we aren't aware of. It's worth looking into.

LupineDream said:
Thank you for the inspiration. The task has been a thorough crash-course in arm v7a NEON Cortex technology and thumb-2 assembler. I was concerned when I saw the TrustZone documentation from ARM and the ACEP (Arbitrary Code Execution Prevention) stack. Your mention of qfuse brings back memories of the Samsung "Golden Routines" folly.
Unfortunetly I wasn't a backer of the Raspberry PI, but there are other PCBs with GPIO pins. My reason for mention this is the JTAG connundrum you mentioned. It is null and void to a soldering gun, a few resisters ($2-$3, and the on-chip ARM debugging interface included in most integrated ARM chipsets. PCBs that run Linux with a GPIO pin array are the cheapest and most flexable solution to an expensive piece of lab / R & D equipment (JTAG), and the impact on the bank account is a fraction of what it would cost the end-consumer.
Hash collisions and backprop neural nets. What? OK, I'll explain. Most reverse engineering begins with monitoring the usual operation of the device as you are aware. Approach 1 involves training a backpropping neural network to recognize (within a reasonably less amount of computation) a hash collision. Of course, you aren't going to be getting to these pre-coded hashes without breaking the RSA chain (thats 100 zeros O__O ) , this is fixed by monitoring the debug interface we both mentioned earlier, at power-on. ARM processors work such that they cannot do DMAC (direct memory access computation), so the values need to be pushed into registers and acted on as plain byte, then pushed back to memory. Sniff, find out what's coming to/from the qfuse memory bus area into registers, dump the data, and you'll have your root CA with luck. You'll be looking for the in operand, that is, the one that is to be acted on in the cipher that is incoming from qfuse. Cycle-timing to ignore the rest of the computations for this byte, you're basically waiting until qfuse pushes the next byte of its keys into a register and grabbing it in the same cycle the instruction is working on it.
That said, with a $100 and a soldering gun and a laptop, you have your RSA key direct from CPU memory via the debug interface. After you've got your root CA, would it be feasable to start decrypting the intermediate CA chain for each component of boot until you get the hash? In theory this should work without brute-force, but a lot of time in a code window and with an oscilliscope. Once you've had the decrypted hash, you can begin to look for a hash collision. There are open source tools that will find hash collisions in an hour or less using neural nets. Write an aboot that complies to this hash collision, flash it, and qfuse will not be able to tell the difference.
Thats my theory on exploiting the fact ARM needs to do its computations in an area that is accessable to the debug interface. Of course my theory falls apart if the TrustZone chipset has its own processor.
I'd be okay with writing such guide as long as it followed community guidelines. I should not be posting disassembled code and analysis if it's against the rules to do so. If a mod could clear this for me....
Click to expand...
Click to collapse
Hello again!
Regarding your points:
JTAG is disabled on most production devices, as in 100% inoperable. No amount of soldering will enable it. I'm sure there are some exceptions to the rule, but in this case I'm fairly confident in saying that the JTAG interface on the G5 is unusable.
...even if JTAG was enabled, the Qualcomm Secure Boot stack is designed to protect itself from the exact type of attack you're describing here. The component of TrustZone that is doing the verification of boot images is not running in anything that is JTAG-accessible, and to my understanding it's not even running in the main ARM core.
Re: hash collisions and neural nets... What you're describing sounds neat in theory, but in application (again, to my knowledge) won't work. I suggest you read up on how RSA works.
RSA is public/private key cryptography - in this case, the certificates contained on the phone are the public component, and LG/Qualcomm are the only ones with the private component. "Extracting the CA" will yield the public portion that is only useful for verifying signatures, not signing them.
The only way you'd be able to sign anything and have the phone trust it is to either a) replace the CA on the phone (not possible, it's burned into qFuses) or b) obtain the private component of the CA or any of it's subsidiaries (also burned into qFuses)
CA chains aren't encrypted, they're just a list of things that the device will accept a signature for. In our case it's Qualcomm as the Root CA, then LG as an intermediate (and possibly a few other intermediates to allow OTA updates to come from differing builders/engineering teams within LG). Again, extracting the 'hash' of a CA will do no good here, as there's no meaningful collisions that can be generated and still be a valid boot image. I'm not the best person to explain RSA in depth, so I'd really recommend doing some further research on it.
LupineDream said:
After searching around I located the true specs for the G5. It's a Snapdragon 820 SoC. It runs the new ARM v8A instruction set.
More detailed information here -> http://www.tomshardware.com/reviews/snapdragon-820-performance-preview,4389-2.html.
More specifically, it's on the msm8996 platform: http://system-on-a-chip.specout.com/l/1170/Qualcomm-Snapdragon-820-MSM8996
Phones with this arcitechture: https://www.kimovil.com/en/list-smartphones-by-processor/qualcomm-snapdragon-820-msm8996
Xiaomi Mi5 has official bootloader unlock via a tool (reverse engineer to work with our platform?)
HTC 10 bootloader on certain models can be oem-unlocked.
Lenovo ZUK Z2 bootloader can be oem-unlocked
LG V20 bootloader can be oem-unlocked, and is the closest in hardware to our G5!
Perhaps stealing a kernel and boot from a similar varient that allows it, signing it with our key, hash-matching it? It all runs on the same platform with the same instruction set. Most of these phones have unlockable bootloaders.
I'd say the best target would be that unlock tool by Xaoimi. Its usually the third party vendor's tools you can find the biggest security holes in. xD From their documentation, it isn't an "enable OEM unlock" switch in Developer Options used to enable the unlock, the tool itself actually works on the bootloader. Perhaps the tool uses a feature of the MSM8996 we aren't aware of. It's worth looking into.
Click to expand...
Click to collapse
Bootloaders for other phones will not work on our phone, as of course it'll fail the Secure Boot check.
Bootloader unlock tools for other phones will not work because they're relying on manufacturer specific unlock code that's compiled into aboot (LK). Qualcomm's CAF version of LK doesn't include any unlock code checking functionality, so most manufacturers add that themselves.
LG, in this case, is not even including the code for a bootloader unlock in the US model bootloaders. If you're familiar with C, essentially LG has `#ifdef`'d the entire section of code out (including fastboot).
The V20 bootloader does indeed contain oem-unlock code, but Secure Boot will prevent you from flashing the V20's bootloader (even if it magically was code-compatible with the G5) because Secure Boot checks the hardware ID that's burned into qFuses.
This means, to add a bootloader unlock, you'd have to modify aboot, which can't be done because of Secure Boot. Secure Boot components can't be modified because of RSA, and the RSA verification can't be altered because the keys are burned into qFuses.

thecubed said:
Hello again!
Regarding your points:
JTAG is disabled on most production devices, as in 100% inoperable. No amount of soldering will enable it. I'm sure there are some exceptions to the rule, but in this case I'm fairly confident in saying that the JTAG interface on the G5 is unusable.
...even if JTAG was enabled, the Qualcomm Secure Boot stack is designed to protect itself from the exact type of attack you're describing here. The component of TrustZone that is doing the verification of boot images is not running in anything that is JTAG-accessible, and to my understanding it's not even running in the main ARM core.
Re: hash collisions and neural nets... What you're describing sounds neat in theory, but in application (again, to my knowledge) won't work. I suggest you read up on how RSA works.
RSA is public/private key cryptography - in this case, the certificates contained on the phone are the public component, and LG/Qualcomm are the only ones with the private component. "Extracting the CA" will yield the public portion that is only useful for verifying signatures, not signing them.
The only way you'd be able to sign anything and have the phone trust it is to either a) replace the CA on the phone (not possible, it's burned into qFuses) or b) obtain the private component of the CA or any of it's subsidiaries (also burned into qFuses)
CA chains aren't encrypted, they're just a list of things that the device will accept a signature for. In our case it's Qualcomm as the Root CA, then LG as an intermediate (and possibly a few other intermediates to allow OTA updates to come from differing builders/engineering teams within LG). Again, extracting the 'hash' of a CA will do no good here, as there's no meaningful collisions that can be generated and still be a valid boot image. I'm not the best person to explain RSA in depth, so I'd really recommend doing some further research on it.
Bootloaders for other phones will not work on our phone, as of course it'll fail the Secure Boot check.
Bootloader unlock tools for other phones will not work because they're relying on manufacturer specific unlock code that's compiled into aboot (LK). Qualcomm's CAF version of LK doesn't include any unlock code checking functionality, so most manufacturers add that themselves.
LG, in this case, is not even including the code for a bootloader unlock in the US model bootloaders. If you're familiar with C, essentially LG has `#ifdef`'d the entire section of code out (including fastboot).
The V20 bootloader does indeed contain oem-unlock code, but Secure Boot will prevent you from flashing the V20's bootloader (even if it magically was code-compatible with the G5) because Secure Boot checks the hardware ID that's burned into qFuses.
This means, to add a bootloader unlock, you'd have to modify aboot, which can't be done because of Secure Boot. Secure Boot components can't be modified because of RSA, and the RSA verification can't be altered because the keys are burned into qFuses.
Click to expand...
Click to collapse
So in this case, what would be the next image in the stack that would allow any kind of modifications? Should I be looking at boot.img instead? Would there be a method of tricking the signed and secure boot chain into believing what it sees isn't executing as root?
had been looking through some old methods of root, like causing a boot error by zeroing laf or flashing over it, causing the bootloader to drop you into fastboot, booted securely from there you could call a kcal perameter of the stock kernel that allowed a sort of debugging mode with systemwide root. That exploit was in the G2 era, and how that device obtained root.
I've seen a method that causes Knox to lock up on some Samsung devices by overloading its memory addresses or repeatedly zeroing certain bits of RAM.
I'd really need to find out what method works. If you can't make any modification, maybe there's a workaround to make it THINK everything is legit beyond the boot chain.

aboot decription
Ok I have been working on an lg g5 vs987 myself and I got to the recoding the aboot part and was totally lost its all encrypted and I have no idea where to start to even see what the code is really saying I am new to this website and I am also new to coding on android if you can guide me in the right direction I might be able to help. I have always dreamed of being a part of a development like this and now I might have a shot. Thank you so much for your work and I hope to hear from you soon!

alphawolves said:
Ok I have been working on an lg g5 vs987 myself and I got to the recoding the aboot part and was totally lost its all encrypted and I have no idea where to start to even see what the code is really saying I am new to this website and I am also new to coding on android if you can guide me in the right direction I might be able to help. I have always dreamed of being a part of a development like this and now I might have a shot. Thank you so much for your work and I hope to hear from you soon!
Click to expand...
Click to collapse
Dissembling and recoding aboot wont work no matter even if it is not encrypted..
It is already mentioned above by @thecubed ..
The secure boot will always verify the signature and dissassembly will generate no signature.
We need to find the private keys used for generating the public hash.. but that is not possible unless leaked from lg which is also very unlikely..
What a hacker can do is find a bug/vulnerability in aboot that can bypass secureboot..or a hardware loophole..
Plus there is a trustzone that itself secures the secureboot process.. so we have to find ways to exploit the bootchain so that we can somehow make the bootloader load unsigned ramdisks/recovery and such..
experienced people could do it.. but i guess there has been a lot of fuss between devs and wannabees..
Also if we can get debug build of aboot/ramdisk we can flash them to get unlock or at the very least root..
I am not expert on this but that how its simply put

A brave member sent me a very useful PDF specification on the TSF. The TSF is the official name for the portion of the integrated circuitry that controls the storage of the secure boot chain. The hardware routines are there to allow root to happen, but as stated before by @thecubed, LG commented out the entire section of a boot at compile time that allows anything to occur. Now the approach is to disassemble HOW the code that LG commented out works in the international variant that has an OEM unlock. Hardware routines exist that place the TSF into non-commercial mode, disabling functionality of certain enterprise software and deauth-ing the root CA in qfuse, allowing the user to flash their own signing certificates to the TSF (TrustZone) when a request to switch off CC mode is sent. There are all kinds of virtual memory protections, ACE protections, malicious code protections, and other things that the TSF handles. Trying any kind of unauthorised write to protected areas of memory results in blow of qfuse write fuse. It's actually a physical microscopic fuse that when pushed a specific voltage pops at a microscopic level kind of like a big fuse blowing only at a very tiny level. At this point write access anywhere is gone. This happens at the same time a full wipe of the system happens. That is why they say once qfuse blows your phone becomes a very expensive cup holder. Because after the qfuse blows there is no way of software recovery.
The only way to be able to disable commercial (CC mode) and be allowed to do anything to put your own boot chain in is to place the device in debug mode. The international varient contains code how to accomplish this, our devices don't. You would need to compile an app that runs in normal mode, causes a flag to be set that places the device into debug mode, then reboot. While in debug boot, you should be able to execute a CC unlock manually. The PDF I got says it's very specifically timed when this can happen, what parts of boot the TSF allows it to happen, and a rough explanation if what disabling CC mode means. The only way of getting root is to use the TSF-approved method but all this code is removed. The TSF does not stop you from executing code if booted into factory debug mode. The new approach I propose is to find an exploit to get into userdebug, and manually write an unlock routine with disassembled information from the international varient., pushing it directly into execution memory while in userdebug, being absolutely sure to give the TSF what it asks for, when it asks for it, at the exact timing for it.

LupineDream said:
A brave member sent me a very useful PDF specification on the TSF. The TSF is the official name for the portion of the integrated circuitry that controls the storage of the secure boot chain. The hardware routines are there to allow root to happen, but as stated before by @thecubed, LG commented out the entire section of a boot at compile time that allows anything to occur. Now the approach is to disassemble HOW the code that LG commented out works in the international variant that has an OEM unlock. Hardware routines exist that place the TSF into non-commercial mode, disabling functionality of certain enterprise software and deauth-ing the root CA in qfuse, allowing the user to flash their own signing certificates to the TSF (TrustZone) when a request to switch off CC mode is sent. There are all kinds of virtual memory protections, ACE protections, malicious code protections, and other things that the TSF handles. Trying any kind of unauthorised write to protected areas of memory results in blow of qfuse write fuse. It's actually a physical microscopic fuse that when pushed a specific voltage pops at a microscopic level kind of like a big fuse blowing only at a very tiny level. At this point write access anywhere is gone. This happens at the same time a full wipe of the system happens. That is why they say once qfuse blows your phone becomes a very expensive cup holder. Because after the qfuse blows there is no way of software recovery.
The only way to be able to disable commercial (CC mode) and be allowed to do anything to put your own boot chain in is to place the device in debug mode. The international varient contains code how to accomplish this, our devices don't. You would need to compile an app that runs in normal mode, causes a flag to be set that places the device into debug mode, then reboot. While in debug boot, you should be able to execute a CC unlock manually. The PDF I got says it's very specifically timed when this can happen, what parts of boot the TSF allows it to happen, and a rough explanation if what disabling CC mode means. The only way of getting root is to use the TSF-approved method but all this code is removed. The TSF does not stop you from executing code if booted into factory debug mode. The new approach I propose is to find an exploit to get into userdebug, and manually write an unlock routine with disassembled information from the international varient., pushing it directly into execution memory while in userdebug, being absolutely sure to give the TSF what it asks for, when it asks for it, at the exact timing for it.
Click to expand...
Click to collapse
Thanks for that post @LupineDream ! I unfortunately doesn't understand most of the things you explained but perhaps I can save you a bit of time (your last post looks like you aren't aware of that exploit but thats maybe only me misundertanding) ; as far as I know the adb root method develloped by @HonestlyAnnoying include a userdebug kernel so (afaik) we already know an exploit to get into userdebug on marshmallow(dirty santa) and the fact that the users needs to run marshmallow shouldn't matter as (afaik) once the bootloader unlocked, the userdebug kernel is no longer needed and it is possible to change it.
Edit: just saw your post on the adb root thread, so I guess you are now aware of the exploit Sorry for the post, I just wanted to be sure you didn't missed it.

nalf3in said:
Thanks for that post @LupineDream ! I unfortunately doesn't understand most of the things you explained but perhaps I can save you a bit of time (your last post looks like you aren't aware of that exploit but thats maybe only me misundertanding) ; as far as I know the adb root method develloped by @HonestlyAnnoying include a userdebug kernel so (afaik) we already know an exploit to get into userdebug on marshmallow(dirty santa) and the fact that the users needs to run marshmallow shouldn't matter as (afaik) once the bootloader unlocked, the userdebug kernel is no longer needed and it is possible to change it.
Edit: just saw your post on the adb root thread, so I guess you are now aware of the exploit Sorry for the post, I just wanted to be sure you didn't missed the exploit.
Click to expand...
Click to collapse
Yes thank you for affirming that, but not to worry, I got it. LG has an sbl module called anti-rollback that prevents flashing older software. If we look at the boot chain:
Code:
recovery
| /------------------ laf (fastboot)
__________________|__|_________________________________________ laf (security fail screen)
/ / / /
pbl -> sbl > aboot > boot (kernel/ramdisk) > system
^ ^
| |
| \-- IS_UNLOCKED and sig_Check()
Anti-rollback
I beleive anti-rollback was updated to a new version that prevents this on Nugout. Correct me if I'm wrong. I've tried every LG hidden menu code I could find to see, but can't even seem to get the hidden menu working... And the reason they did this is because of the worldwide alerts about dirtycow, which affects not only Android, but the whole of Linux, so we need a nogout kernel. A marshmallow kernel with the new anti-rollback would theoretically end up in the red triangle of death.
We need someone that has an engineering model with a userdebug kernel. LG makes you apply. Their program is called "LG GATE", and they are very picky. I think that's what helped out the Sprint community. Someone got a hold of a developer / engineering model with a marshmallow kernel.

Well, I already heard of that strange issue with the hidden menu and I always though it was a code 18 but after googling, it looks like it some carrier potentially disabled it.. Anyway, I can confirm you that the anti-rollback version is still 0 on my h831 running the latest nougat unless the hidden menu is "lying". (And most variant I know except sprint, which did triggered the counter with the update, stayed at their rollback version). I still encounter the same issues most people on nougat experienced with the adb root (wasn't able to get past reboot and needed to flash with uppercut a fresh 7.0 ) so I guess the issue is somewhere else.
Also, if you need any information that is on the hidden menu, feel free to ask me
http://m.imgur.com/gallery/fTwgSUF

Very exciting, gl

finally they are working on it

What about this line in the aboot.bin
(from canadian aboot)
LOAD:0F960100 aBootVerificati DCB " : boot verification skip ",0xA,0
Is there any way to disable boot verification? no need to go with full bootloader unlock.. if it's possible to just disable boot verification, right?

XT1528 (Moto E2 LTE Surnia) bootloader unlock

I`m sorry if I created new thread that already exist .
I think, there is the way to unlock bootloader on this device. laginimaineb posted awesome information on blogger a couple years ago and I`m wondering ,if can somebody apply this on xt1528.
I don`t know how to insert link on that post. Try to google first sentence .It is better to read original post.
And i am sorry for my English
Unlocking the Motorola Bootloader
In this blog post, we'll explore the Motorola bootloader on recent Qualcomm Snapdragon devices. Our goal will be to unlock the bootloader of a Moto X (2nd Gen), by using the TrustZone kernel code execution vulnerability from the previous blog posts. Note that although we will show the complete unlocking process for this specific device, it should be general enough to work at-least for most modern Motorola devices.
Why Motorola?
After reporting the previous TrustZone kernel privilege escalation to Qualcomm, I was gifted a shiny new Moto X. However... There was one little snag - they accidentally sent me a locked device. This was a completely honest mistake, and they did offer many times to unlock the device - but where's the fun in that? So without further ado, let's dive into the Motorola bootloader and see what it takes to unlock it.
Setting the Stage
Before we start our research, let's begin with a short introduction to the boot process - starting right at the point at which a device is powered on.
First - the PBL (Primary Boot Loader), also known as the "BootROM" is executed. Since the PBL is stored within an internal mask ROM, it cannot be modified or provisioned, and is therefore an intrinsic part of the device. As such, it only serves the very minimal purpose of allowing the device to boot, and authenticating and loading the next part of the boot-chain.
Then, two secondary bootloaders are loaded, SBL1 (Secondary Boot Loader), followed by SBL2. Their main responsibility is to boot up the various processors on the SoC and configure them so that they're ready to operate.
Next up in the boot-chain, the third and last secondary bootloader, SBL3, is loaded. This bootloader, among other tasks, verifies and loads the Android Bootloader - "aboot".
Now this is where we get to the part relevant for our unlocking endeavours; the Android Bootloader is the piece of software whose responsibility is, as its name suggests, to load the Android operating system and trigger its execution.
This is also the piece of boot-chain that OEMs tend to customize the most, mainly because while the first part of the boot-chain is written by Qualcomm and deals with SoC specifics, the Android bootloader can be used to configure the way the Android OS is loaded.
Among the features controlled by aboot is the "bootloader lock" - in other words, aboot is the first piece of the boot-chain which can opt to break the chain of trust (in which each bootloader stage verifies the next) and load an unsigned operating system.
For devices with an unlockable bootloader, the unlocking process is usually performed by rebooting the device into a special ("bootloader") mode, and issuing the relevant fastboot command. However, as we will later see, this interface is also handled by aboot. This means that not only does aboot query the lock status during the regular boot process, but it also houses the code responsible for the actual unlocking process.
As you may know, different OEMs take different stances on this issue. In short, "Nexus" devices always ship with an "unlockable" bootloader. In contrast, Samsung doesn't allow bootloader unlocking for most of its devices. Other OEMs, Motorola included, ship their devices locked, but certain devices deemed "eligible" can be unlocked using a "magic" (signed) token supplied by the OEM (although this also voids the warranty for most devices).
So... it's all very complex, but also irrelevant. That's because we're going to do the whole process manually - if aboot can control the lock status of the device, this means we should probably be able to do so as well, given an elevated enough set of privileges.
Getting Started
Now that we have a general grasp of the components involved and of our goal, the next stage is to analyse the actual aboot code.
Since the binaries for all stages of the boot-chain are contained within the factory firmware image, that would naturally be a good place to start. There are several download links available - here are a few. In case you would like to follow along with me, I'm going to refer to the symbols in the version "ATT_XT1097_4.4.4_KXE21.187-38".
After downloading the firmware image, we are faced with our first challenge - the images are all packed using a proprietary format, in a file called "motoboot.img". However, opening the file up in a hex-editor reveals it has a pretty simple format we can deduce:
As you can see above, the sought-after aboot image is stored within this file, along with the TrustZone image, and various stages of the boot-chain. Good.
After analysing the structure above, I've written a python script which can be used to unpack all the images from a given Motorola bootloader image, you can find it here.
Much ado aboot nothing
We'll start by inspecting the aboot image. Discouragingly, it is 1MB large, so going over it all would be a waste of time. However, as we've mentioned above, when booting the device into the special "bootloader" mode, the actual interaction with the user is provided by aboot itself. This means that we can start by searching for the strings which are displayed when the unlocking process is performed - and continue from there.
A short search for the "unlock..." string which is printed after starting the unlock process brings us straight to the function (@0xFF4B874) which deals with the unlocking logic:
That was pretty fast!
As you can see, after printing the string to the console, three functions are called consecutively, and if all three of them succeed, the device is considered unlocked.
Going over the last two functions reveals their purpose is to erase the user's data partitions (which is always performed after the bootloader is unlocked, in order to protect the device owner's privacy). In any case, this means they are irrelevant to the unlocking process itself and are simply side-effects.
This leaves us with a single function which, when called, should unlock the bootloader.
So does this mean we're done already? Can we just call this function and unlock the device?
Actually, not yet. Although the TrustZone exploit allows us to achieve code-execution within the TrustZone kernel, this is only done after the operating system is loaded, at which point, executing aboot code directly could cause all sorts of side-effects (since, for example, the code might assume that there is no operating system/the MMU could be disabled, etc.). And even if it were that simple, perhaps there is something interesting to be learned by fully understanding the locking mechanism itself.
Regardless, if we can understand the logic behind the code, we can simply emulate it ourselves, and perform the meaningful parts of it from our TrustZone exploit. Analysing the unlocking function reveals a surprisingly simple high-level logic:
Unfortunately, these two functions wreak havoc within IDA (which fails to even display a meaningful call-graph for them).
Manually analysing the functions reveals that they are in fact quite similar to one another. They both don't contain much logic of their own, but instead they prepare arguments and call the following function:
This is a little surprising - instead of handling the logic itself, this function issues an an SMC (Supervisor Mode Call) in order to invoke a TrustZone system-call from aboot itself! (as we've discussed in previous blog posts). In this case, both functions issue an SMC with the request code 0x3F801. Here is the relevant pseudo-code for each of them:
At this point we've gleaned all the information we need from aboot, now lets switch over to the TrustZone kernel to find out what this SMC call does.
Enter Stage Left, TrustZone
Now that we've established that an SMC call is made with the command-code 0x3F801, we are left with the task of finding this command within the TrustZone kernel.
Going over the TrustZone kernel system calls, we arrive at the following entry:
This is a huge function which performs widely different tasks based on the first argument supplied, which we'll call the "command code" from now on.
It should be noted an additional flag is passed into this system-call indicating whether or not it was called from a "secure" context. This means that if we try invoking it from the Android OS itself, an argument will be passed marking our invocation is insecure, and will prevent us from performing these operations ourselves. Of course, we can get around this limitation using our TrustZone exploit, but we'll go into that later!
As we've seen above, this SMC call is triggered twice, using the command codes #1 and #2 (I've annotated the functions below to improve readability):
In short, we can see both commands are used to read and write (respectively) values from something called a "QFuse".
QFuses
Much like a real-life fuse, a QFuse is a hardware component which facilitates a "one-time-writeable" piece of memory. Each fuse represents a single bit; fuses which are in-tact represent the bit zero, and "blown" fuses represent the bit one. However, as the name suggests, this operation is irreversible - once a fuse is blown it cannot be "un-blown".
Each SoC has it's own arrangement of QFuses, each with it's own unique purpose. Some fuses are already blown when a device is shipped, but others can be blown depending on the user's actions in order to change the way a specific device feature operates.
Unfortunately, the information regarding the role of each fuse is not public, and we are therefore left with the single option of reversing the various software components to try and deduce their role.
In our case, we call a specific function in order to decide which fuse we are going to read and write:
Since we call this function with the second syscall argument, in our case "4", this means we will operate on the fuse at address 0xFC4B86E8.
Putting it all together
Now that we understand the aboot and the TrustZone logic, we can put them together to get the full flow:
First, aboot calls SMC 0x3F801 with command-code #1
This causes the TrustZone kernel to read and return the QFuse at address 0xFC4B86E8
Then, iff the first bit in the QFuse is disabled, aboot calls SMC 0x3F801 once more, this time with command-code #2
This causes the TrustZone kernel to write the value 1 to the LSB of the aforementioned QFuse.
Turns out to be very simple after all - we just need to set a single bit in a single QFuse, and the bootloader will be considered unlocked.
But how can QFuses be written?
DIY QFuses
Luckily the TrustZone kernel exposes a pair of system-call which allow us to read and write a restricted set of QFuses - tzbsp_qfprom_read_row and tzbsp_qfprom_write_row, respectively. If we can lift those restrictions using our TrustZone exploit, we should be able to use this API in order to blow the wanted QFuse.
Lets take a look at these restrictions within the tzbsp_qfprom_write_row system-call:
So first, there's a DWORD at 0xFE823D5C which must be set to zero in order for the function's logic to continue. Normally this flag is in fact set to one, thus preventing the usage of the QFuse calls, but we can easily enough overwrite the flag using the TrustZone exploit.
Then, there's an additional function called, which is used to make sure that the ranges of fuses being written are "allowed":
As we can see, this function goes over a static list of pairs, each denoting the start and end address of the allowed QFuses. This means that in order to pass this check, we can overwrite this static list to include all QFuses (setting the start address to zero and the end address to the maximal QFuse relative address - 0xFFFF).
Trying it out
Now that we have everything figured out, it's time to try it out ourselves! I've written some code which does the following:
Achieves code-execution within TrustZone
Disables the QFuse protections
Writes the LSB QFuse in QFuse 0xFC4B86E8
In this blog post we went over the flow controlled by a single QFuse. But, as you can probably guess, there are many different interesting QFuses out there, waiting to be discovered.
On the one hand, blowing a fuse is really "dangerous" - making one small mistake can permanently brick you device. On the other hand, some fuses might facilitate a special set of features that we would like to enable.
One such example is the "engineering" fuse; this fuse is mentioned throughout the aboot image, and can be used to enable an amazing range of capabilities such as skipping secure boot, loading unsigned peripheral images, having an unsigned GPT, and much more.
However, this fuse is blown in all consumer devices, marking the device as a "non-engineer" device, and disabling these features. But who knows, maybe there are other fuses which are just as important, which have not yet been discovered...

Spent the last day or so looking at this. The surnia bootloader attempts to call the SMC function 0x3000A0A. That's as far as I got without the symbols for the trustzone kernel.

programmargorp said:
Spent the last day or so looking at this. The surnia bootloader attempts to call the SMC function 0x3000A0A. That's as far as I got without the symbols for the trustzone kernel.
Click to expand...
Click to collapse
I don't know if it will helps, but there in comment section of "Full TrustZone exploit for MSM8974" post , one user mentioned about tz_service of msm8916
also on MSM 8916 there is a function called
tz_service <0x3F802, aTzbsp_oem_svc, 0xF, 0x86500ECB, 1> ; "tzbsp_oem_svc"
which doesnt check the ranges and write 3 dwords to an arbitrary address
int __fastcall tzbsp_oem_svc(int a1, int a2)
{
int v2; // [email protected]
v2 = a2;
*(_DWORD *)a2 = 0xC;
*(_DWORD *)(a2 + 4) = get_tzbsp_params(); =>returns 0x0F
*(_DWORD *)(v2 + 8) = sub_865164FE(); =>returns 0x0
return 0;
}
this can be used to neutralise range check.

3max3 said:
I don't know if it will help, but there in comment section of "Full TrustZone exploit for MSM8974" post , one user mentioned about tz_service of msm8916
also on MSM 8916 there is a function called
tz_service <0x3F802, aTzbsp_oem_svc, 0xF, 0x86500ECB, 1> ; "tzbsp_oem_svc"
which doesnt check the ranges and write 3 dwords to an arbitrary address
int __fastcall tzbsp_oem_svc(int a1, int a2)
{
int v2; // [email protected]
v2 = a2;
*(_DWORD *)a2 = 0xC;
*(_DWORD *)(a2 + 4) = get_tzbsp_params(); =>returns 0x0F
*(_DWORD *)(v2 + 8) = sub_865164FE(); =>returns 0x0
return 0;
}
this can be used to neutralise range check.
Click to expand...
Click to collapse
Yes, that gives you a arbritary write gadget but doesn't bring you any closer to blowing the required qfuse.
You may or may not be able to use the other trustzone exploit (CVE-2016-2431) to trigger trustzone call 0x3000A0A with the provided parameters to force an unlock.

Good exploit, but too bad it was not converted into a more general tool ...
There is low single digit number of people who can use the instructions, and unlock other models.

bibikalka said:
Good exploit, but too bad it was not converted into a more general tool ...
There is low single digit number of people who can use the instructions, and unlock other models.
Click to expand...
Click to collapse
You`re absolutely right! Unfortunately , this device is not so popular and chances to practical use any of these exploits are close to zero.
But hope dies last.
P.S. : I really appreciate your attempt to use Dirty COW exploit on this device.

3max3 said:
You`re absolutely right! Unfortunately , this device is not so popular and chances to practical use any of these exploits are close to zero.
But hope dies last.
P.S. : I really appreciate your attempt to use Dirty COW exploit on this device.
Click to expand...
Click to collapse
Actually, I never posted this, but if your phone still has an older ROM where Dirty Cow works (5.0.2 or 5.1.1?), you should try Kingoroot as per these exact extractions:
https://forum.xda-developers.com/hd8-hd10/general/tut-fire-hd-10-7th-gen-2017-root-box-t3726443
This was the most stable temporary root I've seen on XT1528, since I was using XT1528 to debug my Fire HD how-to, and I was very pleased with how well the temporary root stuck around on XT1528, and it also survived soft reboots very well. So then you can do Titanium Backup and any other software that wants root to access /data, and other parts of the system. But of course, it cannot write into /system.
Then, there is a russian dude on the Internet selling Sunshine unlock for (1300 roubles ~$20) vs the usual $25. I'd guess Sunshine does the exact the same unlock, as that blog posted copy-pasted in post #1.
Update: here is the 1300 roubles Sunshine unlock - http://1droid.ru/?page_id=51

programmargorp said:
Spent the last day or so looking at this. The surnia bootloader attempts to call the SMC function 0x3000A0A. That's as far as I got without the symbols for the trustzone kernel.
Click to expand...
Click to collapse
The blog post seems to say that the issue was reported and fixed back in 2014. It's unlikely that XT1528 has this bug since it's a later device, and the Android versions for XT1528 are some flavor of Lollipop, not KitKat.

bibikalka said:
The blog post seems to say that the issue was reported and fixed back in 2014. It's unlikely that XT1528 has this bug since it's a later device, and the Android versions for XT1528 are some flavor of Lollipop, not KitKat.
Click to expand...
Click to collapse
AFAIK Widevine exploit and the QSEE exploit both weren't patched until late 2015/early 2016. If you have a firmware version previous to the last update, then it's very likely at least the Widevine exploit still exists.
In fact, the bootloader unlock exploit did not rely on either the Widevine OR QSEE exploits, but was completely a trustzone exploit.

programmargorp said:
AFAIK Widevine exploit and the QSEE exploit both weren't patched until late 2015/early 2016. If you have a firmware version previous to the last update, then it's very likely at least the Widevine exploit still exists.
In fact, the bootloader unlock exploit did not rely on either the Widevine OR QSEE exploits, but was completely a trustzone exploit.
Click to expand...
Click to collapse
I see what you mean:
https://googleprojectzero.blogspot.com/2017/07/trust-issues-exploiting-trustzone-tees.html
If only we could get that Project Zero dude to start unlocking our phones, LOL
Btw, my ancient xt1028 with 4.4.4 is a great candidate for this original route : http://bits-please.blogspot.com/2016/02/unlocking-motorola-bootloader.html
I plan to try to replicate exactly what the guy in the post was doing (IDA Pro package, his exact phone firmware version, etc), to understand if I am even able to follow his instructions first, and see the same output that he was getting. If I won't even get that far - no reason to proceed with any any other devices
Edit: btw, any suggestions what's the best package to compile his code? https://github.com/laginimaineb/Alohamora It's all provided as source files.

bibikalka said:
I see what you mean:
https://googleprojectzero.blogspot.com/2017/07/trust-issues-exploiting-trustzone-tees.html
If only we could get that Project Zero dude to start unlocking our phones, LOL
Btw, my ancient xt1028 with 4.4.4 is a great candidate for this original route : http://bits-please.blogspot.com/2016/02/unlocking-motorola-bootloader.html
I plan to try to replicate exactly what the guy in the post was doing (IDA Pro package, his exact phone firmware version, etc), to understand if I am even able to follow his instructions first, and see the same output that he was getting. If I won't even get that far - no reason to proceed with any any other devices
Edit: btw, any suggestions what's the best package to compile his code? https://github.com/laginimaineb/Alohamora It's all provided as source files.
Click to expand...
Click to collapse
FYI the base address and probably fuse values will be completely wrong. His code runs directly in Python.

programmargorp said:
FYI the base address and probably fuse values will be completely wrong. His code runs directly in Python.
Click to expand...
Click to collapse
Would that be Python on Android, I guess ? Something like QPython3?
There is a small piece that needs to be compiled, shellcode.S. It wants arm-eabi-gcc to work. Is there an Android version, or would I need to do it in Linux or Windows?

Well, I tried to open the same TZ as in the blog (for XT1095) in IDA, and for now cannot even find the relevant addresses which should be the same as in the blog (SECURE_BOOT_FUSE = 0xfC4B86E8).
Overall, there are about 20 things that need to be filled for a different model/TZ version:
https://github.com/laginimaineb/Alohamora/blob/master/symbols.py
Anyway, it looks like people who could re-trace the unlocking steps fully don't hang out on this thread

programmargorp said:
Spent the last day or so looking at this. The surnia bootloader attempts to call the SMC function 0x3000A0A. That's as far as I got without the symbols for the trustzone kernel.
Click to expand...
Click to collapse
I've spent some time staring at IDA here - with me being a total IDA novice. I gotta say, @laginimaineb instructions on the blog are incomplete, and have quite a few gaps.
I could locate the fuse address for XT1098 (just to repeat his steps), and then for XT1028 that I have. Overall, I decompiled the whole TZ into a big *.c file, and then text searched for similar strings as in the blog. His variable/function names were cleaned up, only operands look the same.
But the challenge is that his exploit for bootloader unlock seems to rely on the kernel module being compiled and loaded (his "/data/local/tmp/fuzz_zone" utility), which seems to imply having root access at the very least. @beaups says exactly the same here : link
Also, I did not pursue searching for the memory addresses that enable fuse writing, since that code seems to sit in aboot which I was not able to decompile yet due to its non-standard format (TZ is a standard ELF). The blog never talks how he loaded aboot into IDA, and addressed this non-ELF format.
Anyway, now I don't understand how he unlocked bootloader in XT1098, he never mentions that he had root access, while his code is using the fuzz_zone program, which relies on the kernel module to talk to TZ via SCMs. It just seems a bit circular.
Then @laginimaineb posted some later exploits which could escalate from a normal user access all the way to SCMs and TZ, but the later exploits never loop back to the bootloader unlock. The code he uploaded is very research-y, inconsistent, and tough to take forward.
Technically, one could be unlocking a bunch of MOTOs and other phones just like peanuts, with a bit of skill/time. How come nobody bothered to collect misc bounties, especially back in 2016? No skill? Or the blog instructions were not so good after all?

bibikalka said:
I've spent some time staring at IDA here - with me being a total IDA novice. I gotta say, @laginimaineb instructions on the blog are incomplete, and have quite a few gaps.
I could locate the fuse address for XT1098 (just to repeat his steps), and then for XT1028 that I have. Overall, I decompiled the whole TZ into a big *.c file, and then text searched for similar strings as in the blog. His variable/function names were cleaned up, only operands look the same.
But the challenge is that his exploit for bootloader unlock seems to rely on the kernel module being compiled and loaded (his "/data/local/tmp/fuzz_zone" utility), which seems to imply having root access at the very least. @beaups says exactly the same here : link
Also, I did not pursue searching for the memory addresses that enable fuse writing, since that code seems to sit in aboot which I was not able to decompile yet due to its non-standard format (TZ is a standard ELF). The blog never talks how he loaded aboot into IDA, and addressed this non-ELF format.
Anyway, now I don't understand how he unlocked bootloader in XT1098, he never mentions that he had root access, while his code is using the fuzz_zone program, which relies on the kernel module to talk to TZ via SCMs. It just seems a bit circular.
Then @laginimaineb posted some later exploits which could escalate from a normal user access all the way to SCMs and TZ, but the later exploits never loop back to the bootloader unlock. The code he uploaded is very research-y, inconsistent, and tough to take forward.
Technically, one could be unlocking a bunch of MOTOs and other phones just like peanuts, with a bit of skill/time. How come nobody bothered to collect misc bounties, especially back in 2016? No skill? Or the blog instructions were not so good after all?
Click to expand...
Click to collapse
That answer is easy. The bugs you've seen publicly disclosed are long patched. In fact the E2 (and E for that matter) were never vulnerable.

beaups said:
That answer is easy. The bugs you've seen publicly disclosed are long patched. In fact the E2 (and E for that matter) were never vulnerable.
Click to expand...
Click to collapse
How about an ancient XT1028 with 4.4.4 ? It's ROM dates to about mid-2014.

bibikalka said:
How about an ancient XT1028 with 4.4.4 ? It's ROM dates to about mid-2014.
Click to expand...
Click to collapse
No publicly disclosed tz bugs impacted that device past 4.4.3

bibikalka said:
I've spent some time staring at IDA here - with me being a total IDA novice. I gotta say, @laginimaineb instructions on the blog are incomplete, and have quite a few gaps.
I could locate the fuse address for XT1098 (just to repeat his steps), and then for XT1028 that I have. Overall, I decompiled the whole TZ into a big *.c file, and then text searched for similar strings as in the blog. His variable/function names were cleaned up, only operands look the same.
But the challenge is that his exploit for bootloader unlock seems to rely on the kernel module being compiled and loaded (his "/data/local/tmp/fuzz_zone" utility), which seems to imply having root access at the very least. @beaups says exactly the same here : link
Also, I did not pursue searching for the memory addresses that enable fuse writing, since that code seems to sit in aboot which I was not able to decompile yet due to its non-standard format (TZ is a standard ELF). The blog never talks how he loaded aboot into IDA, and addressed this non-ELF format.
Anyway, now I don't understand how he unlocked bootloader in XT1098, he never mentions that he had root access, while his code is using the fuzz_zone program, which relies on the kernel module to talk to TZ via SCMs. It just seems a bit circular.
Then @laginimaineb posted some later exploits which could escalate from a normal user access all the way to SCMs and TZ, but the later exploits never loop back to the bootloader unlock. The code he uploaded is very research-y, inconsistent, and tough to take forward.
Technically, one could be unlocking a bunch of MOTOs and other phones just like peanuts, with a bit of skill/time. How come nobody bothered to collect misc bounties, especially back in 2016? No skill? Or the blog instructions were not so good after all?
Click to expand...
Click to collapse
The aboot image should be a standard ELF image.
Getting root on the xt1528 is possible (without system rw) with initrd root.

beaups said:
No publicly disclosed tz bugs impacted that device past 4.4.3
Click to expand...
Click to collapse
Interesting. Not even the Widevine QSEE issue? How can it be? Or is Widevine too difficult to exploit?
programmargorp said:
The aboot image should be a standard ELF image.
Getting root on the xt1528 is possible (without system rw) with initrd root.
Click to expand...
Click to collapse
Yes, root is very easy. But it's getting further, to bootloader unlock that is the big challenge. Can you double check your "aboot", it does not look like ELF ...

bibikalka said:
Interesting. Not even the Widevine QSEE issue? How can it be? Or is Widevine too difficult to exploit?
Yes, root is very easy. But it's getting further, to bootloader unlock that is the big challenge. Can you double check your "aboot", it does not look like ELF ...
Click to expand...
Click to collapse
Correct, the device does not have that widevine vulnerability.