[General Topics] zzazzdsa:
I posted this as its own thread last week and ZipAddict asked if I wanted to post this here, so here goes! Basically, I sniffed the USB traffic of the Kingo for Windows app from the computer to the phone and obtained the binary of the exploit Kingo uses and obtained proof that Kingo takes all sorts of system information it really shouldn't be taking.

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:

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:

535	17.102832	host	5.2	USB	56	URB_BULK out
getprop gsm.version.baseband

and

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

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 (s000.tinyupload(dot)com/index.php?file_id=58121731659161137653 )(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