[ROOT] Hardmod Root Your Amazon Fire HD 8 (7th Gen) - Fire HD 8 and HD 10 Original Android Development

{
"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"
}
Amazon Fire HD 8 (7th Gen) Hardmod Root Guide​
I have successfully rooted the Amazon Fire HD 8 (7th Gen), and I want to help you do it too! This is not an easy root, but it's as easy as it can be. The aim for this root was to get at least one working method in order to help aid the development of an easier software root in the future. Countless people from the xda-developers forums worked together to make this root method possible. This thread is where everything started. In no particular order, I want to thank for their help:
@Supersonic27543, @DragonFire1024, @teixeirap, @diplomatic, @richaardvark, @t0x1cSH, @Qiangong2, @MontysEvilTwin, @TheRealIntence, @Snigglez, @ambush_boy, @cybersaga, @gamblodar, @adidasos
… and everyone else who I missed. You're all amazing. Thank you!
I sunk a couple hundred dollars into finding this exploit, so if it works for you please consider helping me recuperate the costs. I want to find an exploit for the newer 8th gen tablets but cannot keep spending money like this. If nothing else, please give this post a thumbs up!
Start Here
Remember, this is a hardware root, so you will need experience with a soldering iron. All the hardware modifications needed for this tablet are pretty easy even if you have never soldered before. However, especially in the case of hardware modifications, there is a chance you can permanently brick your tablet. If you follow this guide, don't hold me responsible if you break things.
This guide will be improved as time goes on. Please reply with any questions or comments and I will help out where I can! Let's get started
General Procedure:
Preparation - Gather the materials, build an SD card adapter, etc.
Disassembly - Take the tablet apart and turn over the motherboard
Hardware Modifications - Soldering the SD card adapter to the board
Communication - Getting the device to talk to your computer
Software Modifications - Installing SuperSU by hand
Testing and Cleanup - Checking for root, removing the SD card adapter, reassembly.
1. Preparation
You will need:
An SD card reader that can read in 1-bit mode. This one will work. If you already have a reader you'd like to try, find a working SD card and referring to this diagram use some electrical tape to cover up pins 1, 2, and 9 (DAT 1-3). If you plug in the card and it still reads, then the reader will work.
A micro-sd card adapter. This will be taken apart so you can solder to the inside.
A soldering iron, solder, and experience.
Some thin wire. I like to use some 28 AWG magnet wire since it has an insulative enamel coating to prevent short circuits.
A small phillips head screwdriver to remove the motherboard.
Either a linux-based computer or a virtual machine running linux through which you can mount a raw physical disk from the host computer. VirtualBox can do this and I will show you how.
Experience using Linux commands and mounting partitions.
SuperSU version 2.79.
Modifying the SD Card Adapter
Pry apart the SD card adapter. You need to connect wires to CMD, GND, CLK, and DAT0. Give yourself at least a few inches of length to work with. Here are some images to help you figure it out:
SD Card Pinout (Ignore column SPI. VSS = GND).
SD Card Adapter Internals
I recommend putting some tape on the wires and writing what they are so you don't lose track after putting the adapter back together (or in my case, wrapping tape around the adapter because I broke the shell).
Also, you will need to either make sure that the sliding lock on the side of the adapter is still there (or fill it in so that there's no more indent) or take apart your SD card reader and ground the read-only pin so that the reader allows you to write to the card. (Grounding it makes it writable, having it open makes it read-only). This pin is located to the far left of the reader when the opening is facing you and the card is facing up.
2. Disassembly
Use a pry tool to take apart the tablet at the seam. There are no ribbon cables connecting the back cover to the front so you can just pull it off. Start at the bottom, and pull upwards so that the fulcrum is on the top of the tablet where the USB port is. This is the easiest way to get it off.
Next, unscrew the screws near the top of the board. Remove the tape covering the camera and disconnect the camera. It just pops off with your pry tool. There is a battery connector at the bottom right, an LCD connector at the bottom left, and a touch screen connector at top center. The battery connector pops out without lifting any hinges. Use tweezers to get underneath the wires and pop it up out of the slot. Lift up the hinge on the touch screen connector and use something very thin to get underneath the glued down ribbon cable. Be careful not to break things. Once it's free from the glue, slide the ribbon cable sideways to pull it out from the connector. Lift the hinge on the LCD connector.
Now, take the board from the top and lift upwards. Stick something under the board to break free some of the glue underneath while you pull upwards. This time the fulcrum of the motherboard is where the LCD and battery connector are. Do be cautious, there are speaker wires at the bottom right to be aware of. Once you have it lifted up most of the way, you can slide it out from under the plastic parts near the power connector and fold it sideways towards the right side of the tablet. The speaker wires act as a hinge.
If all goes well you should be looking at the back of the motherboard right now.
3. Hardware Modifications
Solder the wires from the sd card adapter to the respective test points in this diagram. VSS means GND. Once done with this, fold the motherboard back over and plug the ribbon cables back in. Plug in the power cable last. Loosely put the tablet back into its cover so that you don't crush the wires you just soldered, but also to protect the tablet from short circuiting on your table or something.
4. Communication
Plug your SD card reader into your computer, but do not plug in the SD card adapter. Power up your tablet with the volume down button pressed. At the recovery, use the volume keys to navigate to "Enter bootloader" but DO NOT press power yet.
You need to be ready. Within half a second of pressing power you need to plug the SD card adapter into the reader. This is the most reliable way I have gotten the reader to talk to the eMMC chip.
If all goes well you will see all the partitions appear on your computer. On Windows, check disk manager to see them all. On Ubuntu, use the disks program. When on Windows, it will pop up probably 20 different windows asking you to format drives. CLICK NO. And no and no and no and .... You do not want to format your eMMC lmao. Now just leave the card plugged in and don't touch the tablet. Don't even breathe on it.
5. Software Modifications
Mounting the drive:
Ok this is the most difficult part. On Windows you need to get a linux virtual machine. I prefer to use Ubuntu for this. I also use VirtualBox to run the VM and I can't help you if you don't use it. If you are already using Linux this will make things easier, but if you must use Windows, then you need to mount the eMMC on your virtual machine.
To do this, open a command prompt as an Administrator and navigate to "C:\Program Files\Oracle\VirtualBox". Using disk manager, find what disk number (left side) the SD card reader is mounted on. Then, run this command:
Code:
VBoxManage internalcommands createrawvmdk -filename "C:\Users\<user_name>\firehd8.vmdk" -rawdisk \\.\PhysicalDrive#
Where the # at the end is the disk number you found earlier (mine was 2), and "<user_name>" is obviously the name of your account. This should make a vmdk file on your desktop and be successful. Then you can open your VirtualBox settings for your VM, go to Storage, SATA, and add an existing drive being that vmdk file that just got created. Now boot the machine, and the drive will disappear off Windows but will reappear inside the VM. Please note that VirtualBox must be running as an administrator.
Now, in linux, mount the system partition (it should be about 1.5GB and will usually be partition 14). Open a terminal into it.
Writing SuperSU:
Did I say the last part was most difficult? Well this one is most time-consuming and most easy to do wrong. Here we go! Extract your SuperSU zip that you downloaded. You only need to keep two folders: common and arm64. You will copy the files from these folders into the system partition and set permissions as follows.
Note: When you see 4 numbers like 0644, this is referring to the permissions to set via chmod.
Note 2: When you see something like ubject_r:system_file:s0, this is referring to the extended attribute security.selinux which can be set with this command:
Code:
sudo setfattr -n security.selinux -v "u:object_r:system_file:s0" FILENAME
(Get setfattr by installing the attr package)
Or on most Ubuntu systems, this command will work too:
Code:
chcon u:object_r:system_file:s0 FILENAME
Note 3: All files copied or created will be owned by root:root. If you use sudo for these commands or do them as root, you'll be fine.
Create a directory at /system/app/SuperSU (0644 ubject_r:system_file:s0)
Copy common/Superuser.apk to /system/app/SuperSU/SuperSU.apk (0644 ubject_r:system_file:s0)
Copy common/install-recovery.sh to /system/etc/install-recovery.sh (0755 ubject_r:system_file:s0)
Create symlink from /system/bin/install-recovery.sh to /system/etc/install-recovery.sh
Copy arm64/su to /system/xbin/su (0755 ubject_r:system_file:s0)
Copy arm64/su to /system/xbin/daemonsu (0755 ubject_r:system_file:s0)
Copy arm64/supolicy to /system/xbin/supolicy (0755 ubject_r:system_file:s0)
Copy arm64/libsupol.so to /system/lib64/libsupol.so (0644 ubject_r:system_file:s0)
Move /system/bin/app_process to /system/bin/app_process_backup
Create symlink from /system/bin/app_process to /system/xbin/daemonsu
Create an empty file at /system/etc/.installed_su_daemon (0644 ubject_r:system_file:s0)
That's it! Now properly unmount and eject your SD card and boot up your device.
6. Testing and Cleanup
If all goes well you'll find a SuperSU app on your homescreen. Run it and it will probably tell you to update the su binary. Do so, restart, and then you should have root! Congrats! Make sure to go into settings and set it to grant rather than prompt.
Power down your device, unplug the cables, flip the board, desolder the wires, flip the board again, plug in the cables, put your camera back in, and then screw it all back together and slap on the back cover. You did it!
Extra Info and Troubleshooting
I will add troubleshooting steps here as time goes on.
Should you need them, here are the eMMC dumps from the 16GB and 32GB variants:
16 GB eMMC Dump
32 GB eMMC Dump

Reserved

This is beautiful!!! I have to get some basic supplies, but I am excited to try this out! I'd just about given up hope that this device would ever be rooted, but you made it happen! Definitely not the easiest root process, but maybe it will eventually lead to easier ways to obtain root. Thank you again for your hard work and dedication (and to everyone else as well!) on this!! ???

richaardvark said:
This is beautiful!!! I have to get some basic supplies, but I am excited to try this out! I'd just about given up hope that this device would ever be rooted, but you made it happen! Definitely not the easiest root process, but maybe it will eventually lead to easier ways to obtain root. Thank you again for your hard work and dedication (and to everyone else as well!) on this!! ??
Click to expand...
Click to collapse
Haha yay! It makes me happy to see people excited over this. That's what I was hoping for in the long run. I saw the progress thread struggling and thought I could try and help out on the hardware side. It turned out to be a hobby I never knew I needed; something to look forward to each day that made my life a little more exciting. I'm really proud of how far we've come
And you're right, it's definitely not the easiest. I want to make a video tutorial sometime. I have little experience making video tutorials so we'll see.

Wow, this is outstanding! First, @</br>, thanks for all the work. You really got into the system and I love what you have found. Unfortunately I am not really good with hardware (totally sw guy) but I will find someone who might help me out here. Again, thanks for all your hard work!

I don't know Linux and I don't know how to solder but what the hell I've got an unused 7th gen hd8 sitting here and I'm pretty methodical so why not give it a go eh? Just for fun.
Edit: I'm looking at you @DragonFire1024, you know you want to

YAY!!! Finally, After almost a year of brainstorming by lots of people, and 700+ posts in the progress thread, we have root! THANK YOU for the work you put into this! :victory:
A pity that after so much time finally a root is found, but I can't do it (because it involves soldering which is a thing I can't do for a lot of reasons LOL). So, the progress thread will continue searching for a software root, and of course the next step, a bootloader unlock! You helped a couple of my ideas for a software root too, by full access to the eMMC dump.
Thank you again for your great work, and everyone, good luck hardware modding!

obvious said:
I don't know Linux and I don't know how to solder but what the hell I've got an unused 7th gen hd8 sitting here and I'm pretty methodical so why not give it a go eh? Just for fun.
Edit: I'm looking at you @DragonFire1024, you know you want to
Click to expand...
Click to collapse
Right now I don't have the supplies or means to get them. Otherwise I'd have already started this AM. Right now I'm focused on looking at the partitions to get these things unlocked, whether i have help and advice, or not. I'd prefer help, but as with most of my work, I am sure I'll eventually figure it it out on my own.
---------- Post added at 04:09 PM ---------- Previous post was at 04:04 PM ----------
With that being said, is anyone going to clarify what @diplomatic was talking about? I don't like receiving half of the advice/instructions.

I have the same Transcend SD card reader which I use to copy files to and from my Amazon tablets with a USB OTG cable. I was wondering if it would be possible to use a rooted Fire 7 (2015) or Fire HD 10 (2017) with Busybox installed to copy the SuperSU files and set permissions using a terminal emulator with a root shell, instead of a Linux machine/ virtual machine?
I am happy to break a couple of micro SD adapters to connect up the eMMC, but I am anxious about soldering to the motherboard. Is just taping the wires to the motherboard feasible, or is this just not robust enough?

Right now, this is a little too hard for me to attempt, but great job! Congratulations on figuring out how to root this stubborn thing!

DragonFire1024 said:
Right now I don't have the supplies or means to get them. Otherwise I'd have already started this AM. Right now I'm focused on looking at the partitions to get these things unlocked, whether i have help and advice, or not. I'd prefer help, but as with most of my work, I am sure I'll eventually figure it it out on my own.
---------- Post added at 04:09 PM ---------- Previous post was at 04:04 PM ----------
With that being said, is anyone going to clarify what @diplomatic was talking about? I don't like receiving half of the advice/instructions.
Click to expand...
Click to collapse
The way I understand it, you're looking for the address of the unlock 'partition' so if you flash a text file with renamed file extension to it then you can trawl through address space till you find the text you recognize. Then you'll be able to work out where it is. It might overflow to or from another area but knowing the content of the file will enable you to figure out where correct offsets are....or something like that. Just my interpretation.

MontysEvilTwin said:
I have the same Transcend SD card reader which I use to copy files to and from my Amazon tablets with a USB OTG cable. I was wondering if it would be possible to use a rooted Fire 7 (2015) or Fire HD 10 (2017) with Busybox installed to copy the SuperSU files and set permissions using a terminal emulator with a root shell, instead of a Linux machine/ virtual machine?
I am happy to break a couple of micro SD adapters to connect up the eMMC, but I am anxious about soldering to the motherboard. Is just taping the wires to the motherboard feasible, or is this just not robust enough?
Click to expand...
Click to collapse
Honestly it might be possible. I'll look into this and get back to you later.
As for taping the wires, you might get away with it but it better be strong tape. If the connection is broken at any point while mounted you risk corrupted data and such. Who knows what would happen. I believe in you though! Soldering is easy on this board, there's not much to go wrong. Just be careful around the resistors next to the CLK pad and you'll be fine.

Code:
sudo setfattr -n security.selinux -v "u:object_r:system_file:s0" FILENAME
Click to expand...
Click to collapse
Most Ubuntu systems come with selinux installed, so it might be easier to just do
Code:
chcon u:object_r:system_file:s0 FILENAME
.
P.S. How did you find out which test points were connected to the EMMC? I might be able to use that method to root a completely different device.

nonnymoose said:
Most Ubuntu systems come with selinux installed, so it might be easier to just do
Code:
chcon u:object_r:system_file:s0 FILENAME
.
P.S. How did you find out which test points were connected to the EMMC? I might be able to use that method to root a completely different device.
Click to expand...
Click to collapse
Thanks for that command! I did not know that.
I bought a broken tablet on eBay and removed the eMMC chip from the motherboard, then used a multimeter to test the points based on the datasheet for the chip. You could also probably figure it out with a logic analyzer by guessing and checking but this tablet gave no clues as to where the points were so I had to go the hard route.

Sorry to ask for more, but can we have pictures or a video of the whole process please. Also, can we get custom rom with this method?

JellyBeanGreen2 said:
Sorry to ask for more, but can we have pictures or a video of the whole process please. Also, can we get custom rom with this method?
Click to expand...
Click to collapse
Yes, pictures will be added soon. I'm overloaded with schoolwork but I wanted to get something out quickly so that's why this guide is not the best quality. I will probably make a video in the future. I don't know too much about roms so I'm not the best person to ask that question. I think @diplomatic would know, but my guess is that roms require an unlocked bootloader.

obvious said:
The way I understand it, you're looking for the address of the unlock 'partition' so if you flash a text file with renamed file extension to it then you can trawl through address space till you find the text you recognize. Then you'll be able to work out where it is. It might overflow to or from another area but knowing the content of the file will enable you to figure out where correct offsets are....or something like that. Just my interpretation.
Click to expand...
Click to collapse
I don't know if the partition is a bin or img. I looked at it as a text and there's only a few characters in it. I don't know if it means anything though. I'll have to get into this tomorrow
Sent from my Galaxy S4 using XDA Labs

obvious said:
The way I understand it, you're looking for the address of the unlock 'partition' so if you flash a text file with renamed file extension to it then you can trawl through address space till you find the text you recognize. Then you'll be able to work out where it is. It might overflow to or from another area but knowing the content of the file will enable you to figure out where correct offsets are....or something like that. Just my interpretation.
Click to expand...
Click to collapse
Also I would name the file proinfo.bin and flash it doing fastboot flashing correct?
Sent from my Galaxy S4 using XDA Labs

<br /> said:
Yes, pictures will be added soon. I'm overloaded with schoolwork but I wanted to get something out quickly so that's why this guide is not the best quality. I will probably make a video in the future. I don't know too much about roms so I'm not the best person to ask that question. I think @diplomatic would know, but my guess is that roms require an unlocked bootloader.
Click to expand...
Click to collapse
The Fire 5th gen from 2015 has custom roms via flash fire and a locked bootloader.

@<br /> Thank you so much for making this into reality! I can't wait to test this out on my tablet!
P.S. If I get this working, I'll see if I can try to create a custom rom; there's always time for first times, right?

Related

Today I made my first Mistake (fixed it) but would like some information.

I am old school DOS user, so I don't know linux commands very well.
It is my understanding that the command line is similar in function but with different commands i.e. C\: copy file blah.exe to C:\here\.
Can the Recovery command line be used as such to move around on the sdcard in recovery mode using the same method, and if so, is there a list of linux commands I can familiarize myself with?
I would like to add this to all current/future G1 Hackers.
I learned a valuable mistake today. After doing lots of reading to correct it (thanx to the help of people who know what they are doing). I would like to make this one suggestion:
Get a cheap USB Card reader. Essentially you can do everything you need in windows w/o using a command line.
http://cgi.ebay.com/Cheap-MicroSD-Micro-SD-USB-2.0-Card-Reader---SHIP-$2.50_W0QQitemZ380101445086QQcmdZViewItem
It is a life saver if you makea mistake.
Brutal-Force said:
I am old school DOS user, so I don't know linux commands very well.
It is my understanding that the command line is similar in function but with different commands i.e. C\: copy file blah.exe to C:\here\.
Can the Recovery command line be used as such to move around on the sdcard in recovery mode using the same method, and if so, is there a list of linux commands I can familiarize myself with?
Click to expand...
Click to collapse
yes it can .. however .. the way android is setup i found everything has to be mounted from scratch .. so you wouldn't have /sdcard .. it would be blank until the mmcblk0p1 was mounted .. likewise /system would be blank etc until the mtdblock3 was mounted
So basically...
Yes it can, but not with out a lot of typing. I.e. for every command I would have to do a mount?
The linux commands I found online were difficult, because while they are comparable to the dos ones, they cannot be used verbatim. Also other commands are used while connecting to the device, which do not show up when you do a google search they way I was. I was wondering why when I did a remount from the command line, I could get to the /sdcard but then I tried to use a ls or a l command to list the files and nothing shows. I will (for my own sake) ask more questions and try to push/pull rather than do it simply by windows.
This was the first thing I tried, but it helped very little.
http://www.pixelbeat.org/cmdline.html
Thank you for your input.
I think the usb micro card reader is the best solution. Heres what I do
*8 gig sdhc micro card (everyday card)
*kingston microsd reader with 1 gig micro sd card loaded with the latest JF update.zip
Now I can just pop the 1gb card into my phone and flash the JF if I brick. And since the reader is attached to my keys, I always have the recovery with me even if Im not near a computer.
You really should learn the commands before screwing with things. The linux terminal is infinitely more powerful than dos. The side effect of this is that it is equally more complex. I suggest that you install some linux distro on your desktop computer (or an old junker you have shoved into a corner in the basement), and learn it real well. With just a little experience, you'll surely want to wipe that microshaft turd off of everything you own.
I have had ubuntu installed on my computer before
I can say that ubuntu definitely has is benefits.
A long time ago I was really into computer stuff, constantly tweaking, installing, trying out new stuff. Today I can safely say I use my computer for primarily internet browsing, googleing, information and such. That being said, it really doesn't matter which OS I actually have installed. Ubuntu, my understanding is that it simply uses less resources and of course is open source. Applications are free and there is always someone willing to lend you a hand.
Other than that, I can't see where Ubuntu was really a necessary must for me up until today. Realistically I fall back into the category of "just need it to do one thing". No doubt that Linux has its place, and If I wasn't so out of date and lazy, I would take up the coding myself.
Thanx for the Suggestion Xavier
After I read your post I was like Duhhh. Considering I have the original 1 gig that came with the phone, I did what you suggested. I have pretty much a boot disk/back up for the phone in case everything goes to pot, and I can carry it in my wallet just in case I am doing something while away from a USB port. After all, I shouldnt be tied to a usb port anyways, thats why I bought my G1 .

[Q] [DEV][Android Platform]Creating partitions through script in init.rc

Context/Resume:
-I´m changing the android platform to create two partitions in a SD Card. I need to do this as early as possible. I´m currently trying at init.rc
-It would be nice to obfuscate the access to one of the partitions. If i could keep ithidden would be better
And...the long story:
I´m trying to create new partitions in a sdcard in a device, and i need to be done as early as possible. I thought that the init.rc should be the best location for this, so i tried to add a script call to perform the task, but i´m unable to create these partitions ( or get information of the reason of fail ) First of all, is this premiss valid? Should i be able to do this?
I call the script by:
service myscript /system/bin/logwrapper /system/bin/myscript.sh
disabled
oneshot
at init-time
And the content´s of the .sh file is
fdisk /dev/sdcard < mykeys.input
where "mykeys.input" is the sequence os keys used to perform the taks of create the partitions.
Well, is this the recommended way to do this?
thanks!
Not to sure bout the boot order and its effect on what you are trying to achieve. What phone and os? You might want to look at your phones logs to see in what order what/which/where is going on when. As that could explain your issues a bit more clearly and possibly even provide the mystery errors. If not try running it in an emulator where you can make the boot up verbose and boot log it.
As for hiding the partition have you tried formatting the sdcard outside the phone environment. The hiding ability should be able to be gotten if you were to format in gparted I.e. Format it how you want size wise and format wise, then for the partition you want hidden flag it lba. Not sure if lba hides from your phone or not, but worth a shot.
*edit* what are you trying to achieve again? Dual booting os on phone? If so, I would take a look more towards the /dev/loop and chmod approach. Also keep in mind if this is what you are aiming at you might want to make 3 partitions as a swap partition would be beneficial.
Sent while wearin my foam helmet ridin the short bus.
Hy blackadept:
What i want: Ensure that there is two partitions in a sdcard as early as possible. ( i must create them if needed ). My focus now is in how to create. The logic of "if/when" todo a will deal later.
Why i want this: Project requirement. Not negotiable.
What will be stored: Part1 : User acessible. Nothinf special. Part2: Special Data user by an apk.
"Phone model": It´s a tablet. STI´s tablet. Android 2.2
Well the partitions will be there just from formatting the card, as to whether or not the init sees that I am not sure. I'm one of them poor simple folk who ain't got no money....aka I don't have the fun fancy toys like a tablet. haha. Only reason I bring that up is for the fact that being as I am not around them, literally haven't even seen one let alone hold lmao, not sure how it's boot up goes.
Have you tried creating a partition and formatting it with various flags such as lba to hide it from the OS? If we are talking small sizes here then I'd think you could hide it within such a flagged partition surrounded by fluff. Throw some encryption into the mix and your gtg. At that point all that's left for you to do would be writing script to navigate the maze and unlock it. If that would work then it would be a fairly easy out.
Otherwise we could go back to the "dual booting" that I brought up in the last post. Being as my phone can't mnt to bin *droid x.....hate u Motorola* I have done all of my dual and triple boots via looping thru /dev. This could work for you as well, tho again I'm not familiar with the tablets. If you did that tho..... well you could hide it in a myriad of ways.... flags, encryption, straight up "Where's Waldo" type shenanigans....
Have you ever put an ARM OS onto an android device before? If so, maybe give it a shot and let me know? Only question I'm wondering, tho, is android's ability to see the flag and be able to handle it. Also as to the level of root that particular device has (regular not-so-super user like my phone or is it completely unlockable?) would determine a game plan too in a way. If you have full access then you could just format the card thrice (sorry always wanted to use that in a sentence and feel all smert), making a special ext3 partition with the flags or encryption, make note in the root mnt's of it's existence thru your init script (tho just giving physical note to it.... not size or content). Write your .apk or specialized script with the UUID or GUID or w/e the *beep* android uses this week, and again you win at android....
Sorry for the long winded verbal response....lately I always seem to post when I ain't slept for 2-3 days as opposed to when I ain't delirious...

My MicroSD card is starting to corrupt

My /Removable/MicroSD is starting to corrupt. I've been editing scripts on my MicroSD with ES note editor. It started today with files not overwriting other files with the same name, then progressed into edited files saved with corrupt or no data at all, then a few files disappeared, then a directory became corrupt and I could not see a file that ES told me I was overwriting with another file with the same name, and now I am loosing full directories. Is this a partition issue or is the whole card going/gone bad? The card is as factory shipped. I have never formatted or partitioned it.
I have unmounted and remounted the card. That allowed me to edit and save for a few hours. Then another corrupted file happened. I just took the card out and reinserted it as this fixed a similar problem I had a while ago but it only happened once and went away until now, so we'll see if it just wasn't seated properly. One of the 2 directories that disappeared came back after reinserting the card but the second is still missing. I had already backed up my scripts, and now I will back up the entire card to disk.
Does this sound like its going or gone South, or will pulling all the data off, formatting the card, and putting it all back on work to fix it? Is it safe to trust this card anymore or should I RMA it as it should still be under warranty? Its a Sandisk 64 SDXC and not "officially" compatible and was wondering about that as well. I've had it for about 6 mos. I had hoped by spending the little extra $ and picking a name brand it would be more reliable but I guess I got a bad one despite the on-average Sandisk quality. Any advice would be appreciated.
So far, I've only once suspected my microSD (as in yoru case a 64 GB Sandisk UHS-1 Class card) to have gone bad. (Re)formatted it with Gparted (was running data2sd at the time, kicked that out, too) and it has been going strong since without a single hitch.
I'd try and format it, doesn't hurt, only takes time, and it satisfies your tinkering needs at the same time.
MartyHulskemper said:
So far, I've only once suspected my microSD (as in yoru case a 64 GB Sandisk UHS-1 Class card) to have gone bad. (Re)formatted it with Gparted (was running data2sd at the time, kicked that out, too) and it has been going strong since without a single hitch.
I'd try and format it, doesn't hurt, only takes time, and it satisfies your tinkering needs at the same time.
Click to expand...
Click to collapse
Thanks for the reply. What is interesting and seems far-fetched to be coincidental is the corrupted directories are the directories that I am constantly editing and saving files to - My scripts dir and its sub-directories. Guess they mean it when they say flash was not designed to be constantly written to. I can't *believe* I have cycled it to its limit just editing scripts over a 6 mos span. I couldn't have saved files more than a couple thousand times if that.
Waterproof**, x-ray proof**, temperature proof**, shockproof**, but NOT write-proof**
Double directories? This is getting out of hand!
Well I am backing up my MicroSD now, and I just ran across two directories with the same name in the same folder? Two "Scripts". How is this possible? One had files, the other was blank? How can the OS allow this to happen? When it copied to Windows, a (1) was appended to the directory name of the second duplicate.
Just for S&G, I tried to copy a file from one into the other and Windows errored saying something like "device is busy or has been disconnected."
If I had files in both directories and I cd to that directory, which one would I get (trick question)? I believe the dups are only on Windows. I don't think the device actually sees both directories. At least it doesn't show them to me in ES. Bizarre corruption. That surely might explain why files in this directory were getting corrupted. Or maybe the corruption of the files was responsible for the double directories. Time for a format (and a beer) for sure.
Let this be a word to the wise:
So yes I am going to format this, but I wanted to play with this problem a bit and see what I could figure out. As I predicted, and made about my 5th backup just in case, here's what just happened.
1. When there were Script dir duplicates, I could copy from the one with files.
2. I deleted the one without files (predicting it may delete both, but it only deleted the blank one as intended but...)
3. The remaining Script dir could not be copied from, nor a new sub-directory created inside. File names could not be changed. Actually it did allow me to make a copy, but the target directory was blank.
4. Deleted the second Script directory. Now the B2R script is lost forever (no just kidding, I have 5 backups at least)
5. Copied one of my backup copies of Scripts back to the card
6. Now its fine (until I can format it), I can copy from it and create sub-dirs inside it, etc. But I will be working off another copy in Internal storage until I format this card.
7. So the lesson here is ALWAYS make a backup before something glitches out on you because it eventually will and you will need it, or choose to be SOL; life is full of choices. And if it has already glitched out on you, make a second backup of your critical files just in case something like this happens to you and you've made incremental changes. Without my backups I would be loosing about 3 months work in just this one folder alone. It contains every script I have ever written and a bunch of example scripts to learn from.
@_that to comment, but this is what I think happened: This must be some kind of corrupt FAT problem. Very similar to the recovery blob not being found by the bootloader issue from a recent post, but instead of a partition problem its a file allocation table problem, as they reside on the same partition in my case, quote _that below:
"I have a new theory about why this happens: partition tables mismatch. In other words: The location where the recovery writes the blob is not the same as where the bootloader expects it. Thus the bootloader ignores your blob."
It seems the empty directory was the directory the system thought the files were in. Once that directory was removed, the actual one (as the human perceives; as seen in ES) containing files no longer contained them, as far as the OS was concerned. So by deleting the one you effectively deleted the other because its impossible that can can coexist and both be functional. I thought something like this would happen and it did. Like I said earlier, its Miller time.
elfaure said:
7. So the lesson here is ALWAYS make a backup before something glitches out on you because it eventually will and you will need it, or choose to be SOL; life is full of choices. And if it has already glitched out on you, make a second backup of your critical files just in case something like this happens to you and you've made incremental changes.
Click to expand...
Click to collapse
Good advice. Always make one backup more than you think you need.
elfaure said:
This must be some kind of corrupt FAT problem.
Click to expand...
Click to collapse
Probably. ExFAT is a proprietary and patented Microsoft filesystem, and support for it in our TF700 is through a proprietary closed-source third-party kernel module that contains this licensed "technology".
You could try running chkdsk in Windows on the card to detect and fix filesystem errors.
_that said:
Good advice. Always make one backup more than you think you need.
Probably. ExFAT is a proprietary and patented Microsoft filesystem, and support for it in our TF700 is through a proprietary closed-source third-party kernel module that contains this licensed "technology".
You could try running chkdsk in Windows on the card to detect and fix filesystem errors.
Click to expand...
Click to collapse
Funny how they don't even support exFAT in XP without an extension. Maybe it was developed after XP was released. I would assume it is supported by default in W7 and above?
Question: Do you know what is the su password for the terminal app in GParted Live? Or is this limited to GNU staff use??
Do I "sudo gparted" or "sudo passwd root" and set a new password??
elfaure said:
Funny how they don't even support exFAT in XP without an extension. Maybe it was developed after XP was released. I would assume it is supported by default in W7 and above?
Click to expand...
Click to collapse
Good guess. See http://en.wikipedia.org/wiki/ExFAT
elfaure said:
Question: Do you know what is the su password for the terminal app in GParted Live? Or is this limited to GNU staff use??
Do I "sudo gparted" or "sudo passwd root" and set a new password??
Click to expand...
Click to collapse
http://lmgtfy.com/?q=gparted+live+root+password
GParted live is based on Debian live, and the default account is "user", with password "live". There is no root password, so if you need root privileges, login as "user", then run "sudo" to get root privileges.
Click to expand...
Click to collapse
You can run "sudo -i" to just get a root shell if you want.
_that said:
Good guess. See http://en.wikipedia.org/wiki/ExFAT
http://lmgtfy.com/?q=gparted+live+root+password
You can run "sudo -i" to just get a root shell if you want.
Click to expand...
Click to collapse
Looks like my windows\system32 dir has a 2004 date on it. So just before it came out. Nice they have a patch now.
lmgtfy.com is very cool! I've never seen _that before. Really a good way to say "why can't YOU just Google it YOURSELF". Yes, I already followed the same link to get the commands I asked about.
I couldn't figure out a way to get a Logitech bluetooth mouse working in Gparted Live. Probably need linux drivers?
elfaure said:
I couldn't figure out a way to get a Logitech bluetooth mouse working in Gparted Live. Probably need linux drivers?
Click to expand...
Click to collapse
That's a live distro for partitioning stuff, not for supporting all kinds of exotic hardware. Most likely it doesn't even have any bluetooth stack. Use a full desktop distribution like Mint if you want support for bluetooth input devices.
_that said:
That's a live distro for partitioning stuff, not for supporting all kinds of exotic hardware. Most likely it doesn't even have any bluetooth stack. Use a full desktop distribution like Mint if you want support for bluetooth input devices.
Click to expand...
Click to collapse
Yeah, I figured as much but I thought you possibly have a trick.
Cinnamon or Mate desktop? Live iso version available somewhere (couldn't find one)? Never mind, I think I got it. I don't need you to send me another lmgtfy link. But still, Cinnamon or Mate desktop?
Ok, here's my problem. I need to make a bootable CD (not DVD). The iso for Mint 15 Cinnamon is 923MB. It won't fit on a 700MB CD, and my PC can't boot off DVD or USB. Any suggestions besides having to partition a HDD to install a dual-boot configuration which I don't want to have to do just to run Linux once in a while. I would like a Live CD instead. Reduced size minimal distro somewhere to be found?
Ok, found one here for Linux Mint 13 Maya. Hope its not someone's hack. But I think its a better option than Plop. I don't want to start hacking my Windows PC all up just to get Linux. If its any more hassle than burning a CD I'll just use GParted with a corded mouse.
Only 7 available seeds for this torrent, and only 1 is up now. Popular item! (ha). Had it going with 4 but I was hogging too much bandwidth and had to pause fpr a bit then restart. When it restarted, looks like 3 of my seeds blew away in the wind. Looks like tomorrow then...I was hoping to burn the iso and play with it tonight. Oh wait, just got another 1 back. Now were up to 100kB/s. Whoopee
**********************************************************************************************************
http://forums.linuxmint.com/viewtopic.php?f=46&t=110933 (last link goes to next link)
http://forums.linuxmint.com/viewtopic.php?f=61&t=103449&p=604069
elfaure said:
Ok, here's my problem. I need to make a bootable CD (not DVD). The iso for Mint 15 Cinnamon is 923MB. It won't fit on a 700MB CD, and my PC can't boot off DVD or USB.
Click to expand...
Click to collapse
You have a strange PC. Or no DVD drive?
All PCs that I know (that have been produced in this millennium) can boot from DVD or USB with correct BIOS setting and a correctly formatted bootable medium.
_that said:
You have a strange PC. Or no DVD drive?
All PCs that I know (that have been produced in this millennium) can boot from DVD or USB with correct BIOS setting and a correctly formatted bootable medium.
Click to expand...
Click to collapse
Yes I know. I'm cheap and old school with PCs, what can I say. The rest of my devices are current offering. I haven't bought a new PC for over 10 years. Its an older "failed" CAD station that was slated for the dumpster about 3 years ago, then being about 3-4 years old, because our admin was too lazy to test for a simple problem - a failed RAM SIMM. I resurrected it, replaced the failed 512 SIMM and added two more, added a scavenged drive (now 3), and now its my home $100 desktop (replacing the free Pentium I had but was too slow to use). It already had the Quadro FX 3800 video card with a dual core Xeon CPU @ 3.33 GHz. But no DVD drive, only CD drive. BIOS does not support boot from USB either.
Its faster than my old work Dell Precision 690 before I got my new 6-core Xeon T3500. So those were my limitations to work with. And I think I found the best possible solution with Mint 13 Maya iso CD. Looks like Mint 15 just was released. Beautiful OS by the way, I checked out some uTube on it last night. Can't wait to test drive it. Might even make an MS defector out of me. Linux seems to run well on older hardware with slower CPUs vs Windows on the same hardware, so I'm hoping it can breath new life into this semi-archaic box I call my desktop. Now you see why I'm on the tablet so much.
Hey @_that
You were right again. It is a DVD drive. In XP Pro SP2 it was just a CD but after installing SP3 it shows up now as a DVD/CD. Getting Mint 15 32 bit now instead. The DVD drive bay load door is scratched and faded, so I couldn't tell just by looking at it, and was going off what Windows device manager was showing in its tree. I did initially pop a DVD in and it couldn't read it which further substantiated that it was a CD and I never questioned it. Turns out the DVD I tested it with was a DL, and this is only a SL DVD drive. Now I have a 1.7GB limitation, not 700MB which opens up most iso options. But I still have no boot from USB option in my BIOS. I'll look to see if there's an updated BIOS available to open up that option. It would be very nice to have a few thumb drives with different Linux distros to test drive, and a puppy Linux on my key chain.
Sent from my ADR6350 using xda app-developers app
Live Mint 15 Mate
Hey @_that-
Coming to you live from Linux Mint 15 Mate. I guess when running this off a live CD, there is no way to copy a file to /etc is there? I opened it as administrator, and it still wouldn't let me copy the file because this directory is on the CD, not the HDD, correct? I was trying to get my Synergy connected between my MS PC and my other PC running live Linux so I can share my mouse and keyboard seamlessly without my KVM switch. I'm impressed with how easy this is to setup. Also with your ability to see me as a Windows transitional user, and point me to Mint and not Ubuntu. I like it.
elfaure said:
Coming to you live from Linux Mint 15 Mate. I guess when running this off a live CD, there is no way to copy a file to /etc is there?
Click to expand...
Click to collapse
I don't know about the live environment - it's normally only used to install the OS to a real hard drive. I find it still strange that your PC doesn't support booting from USB. Maybe that's a sign that you really should install Linux on a HDD.
elfaure said:
I was trying to get my Synergy connected between my MS PC and my other PC running live Linux so I can share my mouse and keyboard seamlessly without my KVM switch. I'm impressed with how easy this is to setup. Also with your ability to see me as a Windows transitional user, and point me to Mint and not Ubuntu. I like it.
Click to expand...
Click to collapse
2 monitors, 1 keyboard, 1 mouse? Yes, Synergy is nice.
And why Mint: I simply don't agree with Mark Shuttleworth's direction where he is taking Ubuntu - fortunately there are alternatives in the OSS world. I consider Mint as the "sane", i.e. actually usable, version of Ubuntu.
_that said:
I don't know about the live environment - it's normally only used to install the OS to a real hard drive. I find it still strange that your PC doesn't support booting from USB. Maybe that's a sign that you really should install Linux on a HDD.
2 monitors, 1 keyboard, 1 mouse? Yes, Synergy is nice.
And why Mint: I simply don't agree with Mark Shuttleworth's direction where he is taking Ubuntu - fortunately there are alternatives in the OSS world. I consider Mint as the "sane", i.e. actually usable, version of Ubuntu.
Click to expand...
Click to collapse
Yes, this is my work environment now. I have two Dell Precisions, one a 690 and the other a T3500. You got it, two monitors, 1 kb, 1 mouse. Downloading and installing Wine now. I am interested to see if I can run Solidworks on Linux thru Wine. Wow, Linux had come a long way. "sudo apt-get install synergy". All the terminal commands I learned for Android are very useful now, thanks!
ps-"sudo -i" works like a charm.
[Edit] Doesn't look like SW wants to run on Linux loaded thru Wine. I figured as much, but it was worth a try.
Video is not bad at all, despite all I've read. They really must have clean it up for 15. Picture is good, sound is good, seeking is a bit slow, and my biggest complaint is there is no stretch or zoom to fill the entire screen. You have to select from predefined aspect ratios and get as close as you can. Android has better tools in this area than Mint, or maybe it more closely matches a standard aspect ratio like 16:9 for 1920 x 1200 is close (1.77 vs 1.6). Ok, _that's it for the day. Got to get some real work done here now.
Regarding the live environment, its used all the time to test drive different Linux distros before deciding which one to finally install. That's the beauty of a free open OS and a 50 cent DVD and its advantage over a flash card in this case, if you wanted to test 3-5 different ones (back and forth, not sequentially) before deciding on *the one* to finally install to HDD.
elfaure said:
Video is not bad at all, despite all I've read. They really must have clean it up for 15. Picture is good, sound is good, seeking is a bit slow, and my biggest complaint is there is no stretch or zoom to fill the entire screen. You have to select from predefined aspect ratios and get as close as you can. Android has better tools in this area than Mint, or maybe it more closely matches a standard aspect ratio like 16:9 for 1920 x 1200 is close (1.77 vs 1.6).
Click to expand...
Click to collapse
I have no idea what you are talking about. There are lots of media players to choose from, and all that I know have a fullscreen mode.
_that said:
I have no idea what you are talking about. There are lots of media players to choose from, and all that I know have a fullscreen mode.
Click to expand...
Click to collapse
What I mean is by toggling full screen in Mint, its less than full screen because the movie aspect ratio of its recorded resolution is preserved in the scaling function. So there are still black bands either high/low or left/right if you don't play with the player aspect ratio (4:3 vs 16:9) to best match that of your movie in the distros fullscreen mode with the stock player. Which ever limits to extents first in the scaling horiz or vertical DPI defines the "fullscreen" size you get which is less than a full screen. A zoom function does not but a stretch function does override the recorded aspect ratio to fill the full screen (I'm talking about TV's and Dice/BS/MX Player features now, not what's in the Linux default distro player) so with stretch you can get a distorted picture (disproportionate scaling) but not with zoom. These are not included in the stock distro player.
elfaure said:
What I mean is by toggling full screen in Mint...
Click to expand...
Click to collapse
I am using mplayer for video playback - I don't know if that is still included in end-user-focused distros like Mint, but it's one of the most powerful video players that exist. Mplayer has no GUI at all (everything is controlled via the keyboard) - and the "f" key toggles between fullscreen and window.

Kingo Root (still) steals your IMEI

This is probably a hell of a way to make a first post, but whatever.
So, in preparation for the wall of text upcoming, a tl;dr: kingoroot for windows (and probably the android app as well) calls "dumpsys iphonesubinfo" over adb for no discernible reason, obtaining the IMEI of every phone one attempts to root with kingoroot. In addition, the application tries to obtain some other nasty things, like the phone's GSM baseband version number and battery information, all of which are entirely useless for something claiming to just root a phone.
Ok, so first for some backstory. I recently got a prepaid ZTE paragon from best buy for 5 dollars. The hardware is pretty good for the price:
-Qualcomm 410
-1 GB RAM
-sd card slot
- IPS screen
Unfortunately, the phone is running Android 4.4.4 out of the box. Because of this, every trustworthy rooting app I could find failed on the phone, as all of the relevant bugs have been patched. So, I turned to China to give me my su jollies, and indeed, Kingoroot managed to root my phone with little trouble. This got me curious: what exactly was that windows executable doing on the phone anyway? And that's where this all begins....
I first tried to sniff the adb traffic between the computer and the phone. Unfortunately, there is no way to do this: adb sessions are isolated from one another, and so there is no real way to see what the Kingo adb thread was doing from a different shell. So, I went one level deeper and scanned ALL of the USB packet traffic on the computer with USBPcap. After opening up the hex dump, this worked a treat: I could see plaintext in the packets corresponding to adb shell commands. After several hours of skimming through the several megabyte dump, I could see roughly what the Kingo app was doing on the phone: It determines some system information (the model number, whether or not the phone is already rooted, some more unsavory stuff I'll get onto later), then copies over the apk of the splash screen that you get on your phone. When you click the button to root the phone, the executable copies over a lot of files to /data/local/tmp (some root essentials like the su binary and busybox, the main exploit binary called "kingo", and some scripts to ensure root persistence after the main root), chmods busybox, the root exploit, and su to give execution rights, and runs "./kingo kingo", which after several seconds creates a temporary instance of the su binary which you can call over adb at that point. (Interestingly, this must be run as "./kingo kingo" to work; anything else causes a segfault. Some form of password protection, maybe?) It then runs some scripts and rearranges some files with this newfound root access to maintain persistence, deletes all the files it brought over, and quits.
My main interest here was determining the root exploit Kingo were using to root the phone, and so after factory resetting the phone, I rooted it again using the app and copied over any files I could see in /data/local/tmp from a second adb instance. This gave me the set of files Kingo was using to root the phone, and after another reset, running the magic exploit offline indeed gave me temporary root access to the device (I haven't fully figured out how to make persistence work, but that is not the main issue here). So, after some hunting around on the internet to see if anyone else had gotten any information on this magic executable, I found some threads here on XDA claiming that Kingo was stealing some information about your phone and sending it to the Chinese mafia or something. Naturally, I was somewhat upset by this: I was running this in my good Windows VM! Now I have to reset it! But this again piqued my interest, and so I went to see if Kingo really was doing anything malicious.
For those who are unfamiliar with the story, Kingo was caught obtaining the IMEIs of phones which were rooted with the app. This upset a lot of people, and so with version 1.2.2, the Kingo developers claimed to have removed the ability to capture phone IMEIs. (Of course now, I know this is a pile of ****, but let's keep going.) So, first things first, I pulled out my packet log of the rooting endeavor and searched for my ZTE's IMEI. And with this, I found in the packet log:
Code:
529 17.074812 5.2 host USB 58 URB_BULK in:
Device ID = 865895021744484
Oh dear....
(Note that I'm not planning on using this phone for any networking over the cellular modem. I don't really care if this phone's IMEI is stolen. That is actually the phone's IMEI, btw)
Looking a little higher into the packet log revealed that Kingoroot was calling "dumpsys iphonesubinfo" over adb shell to obtain this information, and looking around some more revealed the following gems:
Code:
535 17.102832 host 5.2 USB 56 URB_BULK out
getprop gsm.version.baseband
and
Code:
547 17.124868 host 5.2 USB 43 URB_BULK out
dumpsys battery
Now I don't know about you, but I can't for the life of me figure out why a rooting program needs access to my IMEI, my GSM baseband version (!) and my battery information just to root the phone. To add insult to injury, all of this is done after
Code:
388 13527122 5.2 host USB 108 URB_BULK in
Qdevice::ro.product.name=P821A21;ro.product.model=Z753G;ro.product.device=faerie;
was sent over by the phone, indicating that all of the identifying device information that should have been sent was already sent.
This is only the shady stuff kingo is doing before the root happens too! After root privileges have been obtained, there is an unsettling amount of time taken until the application claims to be done and when it appears to actually be done.
I haven't looked through the whole packet log yet, but just from a brief look at the post-root adb commands packet 15710 has the executable calling "getprop", and who knows what the Chinese mafia are going to do with all of that information!
So, in conclusion, I set out to figure out how KingoRoot for windows roots android phones, but also determined that Kingo never really stopped doing shady **** as they claimed. To anyone who wants to take a look at the files I found for themselves, here (www (dot) filedropper (dot) com (slash) kingo)(I still can't post urls) is a link to everything I found during my little experiment. In that zip is the USB packet log for others to find some interesting information in (just open in wireshark) , the files kingo uses to root my Android 4.4.4 phone (I humbly defer to people who know more about binary reversing than I do to figure out what the hell that binary does), and some instructions to rooting a ZTE paragon z753g with this binary should you happen to have such a phone yourself. I realize that disclosing a root executable is not a particularly good idea, but considering the process to obtain it is so straightforward, I don't think not providing it is stopping anyone who wants to do something nefarious. If someone tells me to take it down, I will, however.
In addendum, I have a couple requests of anyone reading this. If you have a phone you don't particularly care about, download USBPcap, ADB, and the kingoroot executable and get the USB packet log during the whole interaction and the contents of /data/local/tmp (just copy that directory to a known safe place, like /sdcard/Download). Im curious if
1) Kingo actually uses different exploits for different phones and
2) the IMEI and baseband firmware version are always sent over
Finally, if anyone out there is good at binary reversing, I am curious about what exploit the "kingo" file is using to root the phone. When I look again at this process, nothing particularly screams that this actually requires the debugging bridge to work; presumably a rogue .apk could do the same thing. (Or worse yet, an ACE exploit like Stagefright) Although the Kingoroot Android app did not root the phone I used for this experiment, I have reason to believe that the same or a similar exploit is being used there, as opening a simultaneous adb shell reveals su privileges being obtained at a certain point of the process, although presumably the process fails because the persistence creating scripts didn't work for some reason.
So, in actual conclusion, Kingoroot is untrustworthy, panic and run
Thanks for this thread.
Kingoroot didn't root the phone, but stole the IMEI. This is 100% theft.
---------- Post added at 05:56 PM ---------- Previous post was at 05:35 PM ----------
zzazzdsa said:
This is probably a hell of a way to make a first post, but whatever.
So, in preparation for the wall of text upcoming, a tl;dr: kingoroot for windows (and probably the android app as well) calls "dumpsys iphonesubinfo" over adb for no discernible reason, obtaining the IMEI of every phone one attempts to root with kingoroot. In addition, the application tries to obtain some other nasty things, like the phone's GSM baseband version number and battery information, all of which are entirely useless for something claiming to just root a phone.
Ok, so first for some backstory. I recently got a prepaid ZTE paragon from best buy for 5 dollars. The hardware is pretty good for the price:
-Qualcomm 410
-1 GB RAM
-sd card slot
- IPS screen
Unfortunately, the phone is running Android 4.4.4 out of the box. Because of this, every trustworthy rooting app I could find failed on the phone, as all of the relevant bugs have been patched. So, I turned to China to give me my su jollies, and indeed, Kingoroot managed to root my phone with little trouble. This got me curious: what exactly was that windows executable doing on the phone anyway? And that's where this all begins....
Click to expand...
Click to collapse
Does Helium Backup work on this phone? I also bought this phone for $5.
I don't really need to root this phone. I just need to disable some System apps for my privacy.
Some members want root at any cost. You're not posting anything that's not already known.
But as with anything, flash at your own risk. That is the bottom line in this hobby.
Read, research, decide. The responsibility is on members to flash what they want. So, use it or dont. Not much more to say. :good:
And SU ??
Sent from my SM-A700FD using Tapatalk
Awesome post. Thanks!
Two comments/questions:
1. I bought two of these phones for my girls (3 years old and 1 year old). I want to load some games and some videos. I need to root so that I can load apps onto the SD card, etc. Should I worry about using Kingoroot or just go for it? They aren't going to be doing email.. at most taking pictures probably. Maybe Dropbox access. Pandora. So some (of mostly my) credentials going over the air.
2. The link you didn't post (see what i did there?) doesn't work any more. Care to upload it elsewhere? Feel free to PM me if you want.
Edit: I should also say this.. these are the only android phones I've ever owned. But I do consider myself very tech savvy (few programming languages, very comfortable at a unix command line, etc). So if there's any newbie android advice for securing a phone for kid use I'm happy to hear it!). Thanks
I have only used KingRoot on a Blu device and then which, gave to my father.
Thanks for all the work, another vendor of my list.
couldn't get Kingo to work
So inspired by the above post I tried Kingo and it didn't work. After much screwing around with Windows in VirtualBox I got Kingoroot installed and it even said it rooted it - but I couldn't get anything (i.e. SuperUser) to work correctly. Mind sharing your method for getting it to work?
@zzazzdsa You gotta do some research on Kingroot
They claim on their website that they parented up with XDA....
{
"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"
}
Newyork! said:
@zzazzdsa You gotta do some research on Kingroot
They claim on their website that they parented up with XDA....
Click to expand...
Click to collapse
Nope. Lol
No affiliation. But anyone can put anything out there on the interwebz.
So i haven't had much time to play around with this some more, but I can post a rough guide to making a sniffing setup if you want to play along at home.
First, you're going to need a windows computer. It doesn't matter if it's virtualized, it just needs to have USB support enabled (via native support in VMware or the PUEL extension pack in VirtualBox)
Second, you will need to download adb for windows, USBPcap, and wireshark. All of those can be found with minimal googling. Once you have installed all three, you are ready to go.
Plug in your phone, enable adb on the phone, start USBPcap and an adb shell, and then start kingoroot.
Let kingoroot do its thing. While it is rooting the phone, pay close attention to the directory /data/local/tmp over adb. If anything interesting appears there, copy it over to a safe directory, like the emulated SD card.
Once the phone is rooted, close USBPcap, open wireshark, and comb through the packet log with a fine-toothed comb to find plaintext adb commands which will make the exploit work. A useful tip: the packet log will be extremely long, but almost all of the length will be due to the packet capture picking up file transfers as well. You can filter out these long file transfer sequences without losing any useful information.
zzazzdsa said:
So i haven't had much time to play around with this some more, but I can post a rough guide to making a sniffing setup if you want to play along at home.
First, you're going to need a windows computer. It doesn't matter if it's virtualized, it just needs to have USB support enabled (via native support in VMware or the PUEL extension pack in VirtualBox)
Second, you will need to download adb for windows, USBPcap, and wireshark. All of those can be found with minimal googling. Once you have installed all three, you are ready to go.
Plug in your phone, enable adb on the phone, start USBPcap and an adb shell, and then start kingoroot.
Let kingoroot do its thing. While it is rooting the phone, pay close attention to the directory /data/local/tmp over adb. If anything interesting appears there, copy it over to a safe directory, like the emulated SD card.
Once the phone is rooted, close USBPcap, open wireshark, and comb through the packet log with a fine-toothed comb to find plaintext adb commands which will make the exploit work. A useful tip: the packet log will be extremely long, but almost all of the length will be due to the packet capture picking up file transfers as well. You can filter out these long file transfer sequences without losing any useful information.
Click to expand...
Click to collapse
How did you get kingoroot to root your ZTE Paragon? I thought this phone cannot be rooted.
Get a virtual Windows machine running. Download the pc app at kingoapp com. Plug in, root. The problem is getting apps like super su to work given lack of /system write access. get that figured out and I'll give you a few gold stars. Because from what I can tell that's all that's holding me back from moving my apps to the sd card.
OMG LOL!
Then What? They are going to sell my imei number
With as much due respect for someone I've never met: so what? It's a $5 phone. If they get your imei and something bad happens I'll personally refund your $5.
If you're really nervous about that run your virtual machine thru a mitm proxy and filter out anything that looks like your imei.
Sounds like a very shady enterprise overall.
Wasn't planning on using it anytime soon but thank you for the heads up.
Just goes to show, when in doubt come here first.
Hi, my only concern is many novice use wifi at work is there a risk to hijacking a system via
Wifi, if the imei is the security password key used
By many phone services that allow access to towers.
Sweet i didnt know that thanks for the information.
Imei is not a security password.
It's used to identify the phone when programming a number to it (which then gets stored on your sim card)
Verizon won't even tell you the imei associated with a line unless your the account holder.
Curious what the mobile app installation of kingroot saves.
Sent from my unknown using XDA Free mobile app
wonderful article
iam the victim of the kingroot imei stealing

Sony M2 - D2305 Super-HardBrick

Hello, I ask for help and assistance, please.
Sony M2 - D2305
The whole tutorial was read carefully and followed as is, it was achieved, used and tried to meet the objectives happily, it is not my first flash, nor the first device to die (another lg L80 d375ar) I have vague concepts thanks to the forum and booble, I understand something. I am not a developer but I would like to go deeper, without more, I will give a description with my best effort and in the end I will go to the problem in question. (which arose from layer 8 human error in an oversight)
-the bootloader was successfully unlocked;
-I don't remember which flashtool version to use, I have 0.9.18-6 as recommended; following 0.9.22-3 (I think I used this); 0.9.25-0; 0.9.33-0; 0.9.34-0;
-all those files in theory means that then, they work, it was used very well (congratulations to dev's, great job);
-woow!! What's that? Did you launch a new updated version of the lineage, good! I want to try that now! (telling me);
TROUBLE:
Between so many times that I have done it, after doing the format, and the corresponding wipes ... I realize that I never inserted the sd card.
I slide on off.
There is no system, it does not light its LED light under any combination, its battery was at 100%, there is no dfu, there is no recovery, there is no download, no adb, no fastboot, the battery was removed, I charged it with a source of experiments and its voltage is correct, it was allowed to drain and retry after several months assuming the kernel is the one who tried to charge the battery by auto-restarting, and correcting itself, it was tested with every program found in Windows and Linux, and not gave signs of nothing.
win32
semc_device
win64
somc_device
linux
qhsusb_bulk
DEAD!! x_X
*this reminded me of the other device mentioned, qhdloader9008 or something like that, in addition to the qhsusb_bulk, it died with its stock-rom forcing shutdown with buttons because it frozen, among the few possible solutions found and tried, it is mentioned about another possible ported solution, It consists of something like making a copypaste of a complete image of all internal sectors and taking it to the sd-card, and I remember that it almost revived although something was missing and I no longer remember, I could try again but it did not work.
**I have hopes that someone with a lot of knowledge appears, a better solution or someone's help, using their image or helping me create one in some way or another, I do not know what else to do, maybe someone with it same model to try to boot from sdcard.
(I have never done it, if someone wanted to confirm, detail, or know how to provide the complete process, it would also be of great help. But according to what I "don't understand" is that the most reliable thing is to do it from a Linux environment and it would be something like for example )
dd if = /dirInput | vp | dd of = /dirOutput
and share it compressed?)
(If there is any private data, it reserves its right)
***From ignorance, I want to ask according to how little I have learned until today...
what happened here?
Was the recovery installed by mounting in cache? and was the data saved as temporary in a sector that is volatile not persistent? Wrong indexes were formatted and inserted into wrong sectors, losing access to gpt / mbr of all complete? or what happened here?)
****Something extreme and crazy out of context that I wonder, is the result of mixing mcu microcontroller, needles, wires, spi, i2c, bidirectional ttl converter, vcc, gnd, dat + dat- but I still don't understand much, to Unless they make it very easy for me to understand with kiss principles, boxes, apples and kittens.

Categories

Resources