Verizon Droid Turbo Has Been Rooted?!

[Mustang02]

Why would you want to? I used to with my blackberry storms but I've never seen a need for an android phone.

 

[94lt1]

I used to have my blackberry devices power off and power back on at a set time.. But a missed emergency phone call stopped that...

 

[FoxKat]

So I'm editing this to clear up any confusion I may or may have caused (though I've seen no complaints yet...).

This is a demonstration that root has been achieved. This is NOT the process to achieve root.

I have compiled the lines of code as were executed in the video, and then provided a cut and paste version of the visual representation of the steps as were executed in the video.

• adb devices -l
• adb shell
• id
• ls -l /dev/block/mmcblk0p11
• chmod 664 /dev/block/mmcblk0p11
• su
• id
• ls-l /dev/block/mmcblk0p11
• chmod 664 /dev/block/mmcblk0p11
• ls -l /dev/block/mmcblk0p11
• chmod 600 /dev/block/mmcblk0p11
• ls -l /dev/block/mmcblk0p11

I included a final "ls -l /dev/block/mmcblk0p11" in the transcript even though it wasn't in the screen capture above, simply because the dev did that one last step as shown in the final video capture compilation.



Click on image to expand and view.

This is only a demonstration that the user has attained root access on this device. Without already having root, the SU command would have failed, and then the ADB comand to CHMOD the permissions to MMCBLK0P11 would fail as well with another "Permission denied".

SO what we now have to wait for is when the method used to attain root access will be released. We're not even sure that persistent root has been achieved, however this is a HUGE step in that direction because by having ANY access to write to the root partition, a code can be inserted which is executed at boot and essentially re-roots the phone with each reboot, so that persistent root can be achieved.

In other words, keep your television tuned to this channel for important updates.

For my crude interpretation of a rudimentary explanation of what is taking place see my post below.

 

[Mustang02]

Are you able to retain root after rebooting?

 

[FoxKat]

OK, here's the thing... This is just a demonstration that he has access to write to a root protected sector. Not that this gives you root access. So this is the "evidence" that root has been attained on this device. This is NOT the method to attain root.

• adb devices -l
  • devices [-l]- list all connected devices
    ('-l' will also list device qualifiers)

• adb shell
  • Gives you an interactive Linux command-line shell on your device
  • this is in contrast to root access

• id
  • Identify the Android device attached
  • this first time it returns the response that you have 2000(shell) access for the UserID and the GroupID (shell@quark) along with a number of other special accesses

What he is doing is showing that initially he only has shell access (shell@quark) to certain User and Group partitions starting at location 2000 in the memory file allocation table, uid=2000 (shell) & gid=2000 (shell), along with the specific partitions in the 1000 and 3000 ranges for special purposes (graphics, input, log, adb, scard, etc...), but no read or write access to the Root partition (0 through 2000) other than those specific exclusions. This is the default, locked down mode the phone comes from the factory with.

• ls -l /dev/block/mmcblk0p11

• • ls -l is a command to list files (ls) in long format (-l)
  • /dev/block/mmcblk0 is a BLocK (BLK) of memory within the MultiMediaCard (MMC), in this case BLocK 0, with various Partitions (P), and we are looking at Partition 11
  • p11 is the 11th partition. This corresponds to a specific range of addresses in the memory partition, much like a sector and block on a hard drive
  • the command returns the block and partition and tells us the permissions as well as whether it's part of the root or not, what it's size is, date and taime, and it's formal address (i.e. mmcblk00p11)
  • this first time it returns that you only have Read and Write access for the User in the shell (600) as demonstrated by the permissions list at the far left (brw - - - - - - -), where RW represents the System access to the root partition, and the dashes (-) are showing no access to User or Group

He then lists (ls -1) a BLocK (BLK) and Partition (P) of the MediaMemoryCard (MMC) (/dev/block/mmcblk0p11) and it shows that it is a root partition, and that the permissions are only to the System (the first rw at the far left), or 600. The rest of the permissions are none, represented by "-" (dashes).

• chmod 644 /dev/block/mmcblk0p11

• • chmod 644 sets read and write access permissions for a specific partition
  • the first 6 is the File Owner (system), and it is being set to read and write, the next access is to Group and it is being set to Read only, the third digit - 4 sets the Other Users to Read only
  • So this attemtping to set the permissions to rw - r - r - - for the MMCBLK0Partition11 in the root partition
  • It returns a "Permission denied" because it doesn't have authorization to write in ADB to the root partition

Then when he tries to write to change permissions the computer returns a "Permission denied", since he doesn't have root permission (still quark@shell).

• su

• • tells the ADB shell to gain (at least temporary) root access for the next commands from the phone.
  • the phone then authorizes the root access

Then he requests SU and the phone provides the familiar window prompt to ask if you wish to allow root access. This then opens the User and Group to Root rather than Shell access. He wouldn't get that option and pop up window on the phone if the phone weren't already successfully rooted.

• id

• • This shows that the phone now has root access

Now he does another ID and this time it shows uid-0(root) and gid-0(root). This is proof that the phone has at least temporary root access, to all partitions all the way to address 0 on the MMC.

Now it shows he has root access and permission at the command prompt to make changes to the root partition (quark@root).

• ls-l /dev/block/mmcblk0p11

• • command is excuted, but nothing has been told to change yet.

Next, he lists the partition again and you still see the same permissions as above (brw - - - - - - -) showing nothing has changed...yet.

• chmod 644 /dev/block/mmcblk0p11

• • This time, chmod is allowed to change permissions and there is no error "Permission denied"

Then he is able to do the permission changes to the partition (chmod 644 mmcblk0p11). He has changed the permissions to the partition from read/write, no access, no access to Read/Write/Read only/Read only.

• ls -l /dev/block/mmcblk0p11

• • Now when it is listed, the proof is there in the permissions

Then he does the list command again and this time you see that the permissions to the left are now "brw - r - - r - -

• chmod 600 /dev/block/mmcblk0p11

• • Then he executes a chmod command to change the permssions back to the default

This time he changes the permissions back to the original brw - - - - - - - with a 600 where 6 represents read/write and the 0s represent no access.

• ls -l /dev/block/mmcblk0p11
  • finally, he shows that they are back to brw - - - - - - -

He executes another list command to prove that the root access permissions were changed back to before root was attained. A reference chart for the respective permissions and their numerical representations is below.

 

[Mustang02]

boo

 

[FoxKat]

Are you able to retain root after rebooting?

This is the BIG question. This phone was already powered on when he started this demonstration, so we know only one thing for sure so far... He HAS at least temporary root, but there is no proof yet that it's persistent root. In order to do that he would have to reboot the phone and then straight from power up begin requesting root access and get that familiar screen asking for authorization, or simply running a root checker app at the home screen, or running an app that requires root and again seeing that window.

Still, jcase is saying that they "have root" so that could mean that they have persistent root, or simply that they have temporary root but that persistent root is now within their reach.

 

[hammerhead13]

This is definitely promising. I miss using some Root Apps and Functions. Titanium Backup was so good to me.

 

[FoxKat]

This is definitely promising. I miss using some Root Apps and Functions. Titanium Backup was so good to me.

Agreed. Tibu and wireless tether are the biggies for me.

 

[kodiak799]

Concerning the method still hasn't been released.

The more I read, the more I didn't realize how many things I took advantage of root for. All the Xposed modules. And the notification/power menu/quick settings tweaks.

Don't think I need to flash custom roms, but definitely hoping for root.

 

[jstafford1]

Its not going to be released before the 5.1 update to ensure the exploit wasn't patched.

 

[FoxKat]

Its not going to be released before the 5.1 update to ensure the exploit wasn't patched.

That's quite a real possibility but not for certain since I didn't see any mention of that from either jcase or the one who posted the exploit.

 

[kodiak799]

Its not going to be released before the 5.1 update to ensure the exploit wasn't patched.

I always thought it was easier to mod an update to keep root than it was to root a device after taking the update. You can't delay the auto update very long, so there's a good chance if you don't root and delay taking 5.1 update you'll never get root.

 

[jstafford1]

I always thought it was easier to mod an update to keep root than it was to root a device after taking the update. You can't delay the auto update very long, so there's a good chance if you don't root and delay taking 5.1 update you'll never get root.

It all depends on if there's an exploit in the update. If not then either way is a no go.

 

[hammerhead13]

not sure if there is any truth to it but i thought i heard that Lollipop was easier to Root than KitKat.