Anyone on stock unrooted MJ7 (Android 4.3) build willing to test new root method?

Search This thread
T

TheJumpingBean

Guest
Hmmm

Possibly not since SELinux is likely blocking it. You might be able to do this with adb shell.

Also be aware you may have malware on your PC/phone now.

Im still confused. The site that the file comes from is well known, has change logs and everything... Doesnt seem like it would be malware. Weird.
 
D

dothog

Guest
VRoot works, but like most are experiencing, cannot edit certain system files due to that pesky SELinux service. Maybe freezing the app/service with Titanium Backup would help.
However, I decided to use Kingo, seeing as everyone else had some success with VRoot, and I don't get any problems editing system files. Works perfectly. I used the emergency recovery wipe file and cleared the entire phone to MJ7, but I don't know how I stopped getting those notifications. I was actually getting them even when I didn't have root.
 
Last edited by a moderator:
T

TheJumpingBean

Guest
Anyone have the SuperSU Binary

Possibly not since SELinux is likely blocking it. You might be able to do this with adb shell.

Also be aware you may have malware on your PC/phone now.

Does anyone have the su binary for the latest SuperSU? Im willing to give it a try in shell.

Thx,
Maria



Also: Looks like the SU application is: com.noshufou.android.su-1.apk in the /data/app directory.
 

joderme

Senior Member
Jun 13, 2010
554
299
VRoot works, but like most are experiencing, cannot edit certain system files due to that pesky SELinux service. Maybe freezing the app/service with Titanium Backup would help.
However, I decided to use Kingo, seeing as everyone else had some success with VRoot, and I don't get any problems editing system files. Works perfectly. I used the emergency recovery wipe file and cleared the entire phone to MJ7, but I don't know how I stopped getting those notifications. I was actually getting them even when I didn't have root.

Did Kingo trip the knox warranty trigger?
 
T

TheJumpingBean

Guest
Kingo

VRoot works, but like most are experiencing, cannot edit certain system files due to that pesky SELinux service. Maybe freezing the app/service with Titanium Backup would help.
However, I decided to use Kingo, seeing as everyone else had some success with VRoot, and I don't get any problems editing system files. Works perfectly. I used the emergency recovery wipe file and cleared the entire phone to MJ7, but I don't know how I stopped getting those notifications. I was actually getting them even when I didn't have root.

Did you reroot with Kingo? Didn't you try the other one first?
 
D

dothog

Guest
Did Kingo trip the knox warranty trigger?

No, not for me. Knox still shows 0x0 so far. I guess its where I have a totally clean slate. Im really thinking most people's problems is due to them using incomplete wipes, or by using recovery-done factory resets. Safestrap's factory reset tries to keep root, and itself, intact, so anyone who used that in preparation for update to MJ7 might have problems.

---------- Post added at 07:10 PM ---------- Previous post was at 07:05 PM ----------

Did you reroot with Kingo? Didn't you try the other one first?

Yeah, I did VRoot, then reflashed the emergency recovery with Odin, then tried again with Kingo. I did that because I didn't see any people bothering with Kingo because VRoot worked fine for the most part.
 

k1mu

Senior Member
Apr 11, 2011
1,945
1,620
Virginia
I've just asked the mods to delete this thread as it's very likely causing people to infect their PCs and their phones.

VRoot and Kingo install a SuperSU program that has a network backdoor to China. You've given someone full control of your phone.
They also modify your PC's IE configuration, apparently for the same thing.

Why you can't replace the hacked SuperSU is because the malware won't let you.

These rooting programs may work, but they're closed-source and have behavior that can't be explained.

If I had installed this mistakenly, I'd wipe my phone *and* my PC and reinstall from scratch.
 
I've just asked the mods to delete this thread as it's very likely causing people to infect their PCs and their phones.

VRoot and Kingo install a SuperSU program that has a network backdoor to China. You've given someone full control of your phone.
They also modify your PC's IE configuration, apparently for the same thing.

Why you can't replace the hacked SuperSU is because the malware won't let you.

These rooting programs may work, but they're closed-source and have behavior that can't be explained.

If I had installed this mistakenly, I'd wipe my phone *and* my PC and reinstall from scratch.

I think the less paranoid explanation is that the su app has an auto-update feature and since the app isn't hosted in the Play Store, a connection to a chinese server doesn't see all that unexpected.
 

LilTechPrincess

Senior Member
Sep 27, 2012
145
64
Southwest, MO
Do not install

At this point I have every reason to believe there is a huge threat with rooting this way. The su binary starts a listening server and remains connected:

unix 3 [ ] STREAM CONNECTED 5629 3127/su /dev/com.mgyun.shua.su.daemon/server
unix 3 [ ] STREAM CONNECTED 11730 3118/.suv

---------- Post added at 01:55 PM ---------- Previous post was at 01:52 PM ----------

root@jfltevzw:/dev # ls -la
ls -la
---------- root root 0 1970-03-11 22:45 .coldboot_done
drwx--x--x system system 1970-03-11 22:45 .secure_storage
-rw-r--r-- root root 66560 1970-03-11 22:45 __properties__
crw-rw-r-- system radio 10, 25 1970-03-11 22:45 alarm
crw-rw---- adb adb 10, 30 1970-03-11 22:45 android_adb
crw-rw-rw- root root 10, 21 1970-03-11 22:45 ashmem
crw------- nfc nfc 10, 34 1970-03-11 22:45 bcm2079x
crw-rw-rw- root root 10, 22 1970-03-11 22:45 binder
drwxr-xr-x root root 2013-11-04 13:26 block
crw------- bluetooth bluetooth 10, 224 1970-03-11 22:45 btlock
drwxr-xr-x root root 1970-03-11 22:45 bus
crw------- root root 10, 28 1970-03-11 22:45 ccid_bulk
crw------- root root 10, 29 1970-03-11 22:45 ccid_ctrl
drwxrwx--- u0_a247 u0_a247 2013-11-04 13:26 com.mgyun.shua.su
drwxr-xr-x root root 2013-11-04 13:43 com.mgyun.shua.su.daemon

crw------- root root 5, 1 1970-03-11 22:45 console




In all fairness that could be an update daemon.
 
Last edited:

kdogg78

Senior Member
Apr 15, 2009
127
36
Phoenix, AZ
At this point I have every reason to believe there is a huge threat with rooting this way. The su binary starts a listening server and remains connected:

unix 3 [ ] STREAM CONNECTED 5629 3127/su /dev/com.mgyun.shua.su.daemon/server
unix 3 [ ] STREAM CONNECTED 11730 3118/.suv

---------- Post added at 01:55 PM ---------- Previous post was at 01:52 PM ----------

root@jfltevzw:/dev # ls -la
ls -la
---------- root root 0 1970-03-11 22:45 .coldboot_done
drwx--x--x system system 1970-03-11 22:45 .secure_storage
-rw-r--r-- root root 66560 1970-03-11 22:45 __properties__
crw-rw-r-- system radio 10, 25 1970-03-11 22:45 alarm
crw-rw---- adb adb 10, 30 1970-03-11 22:45 android_adb
crw-rw-rw- root root 10, 21 1970-03-11 22:45 ashmem
crw------- nfc nfc 10, 34 1970-03-11 22:45 bcm2079x
crw-rw-rw- root root 10, 22 1970-03-11 22:45 binder
drwxr-xr-x root root 2013-11-04 13:26 block
crw------- bluetooth bluetooth 10, 224 1970-03-11 22:45 btlock
drwxr-xr-x root root 1970-03-11 22:45 bus
crw------- root root 10, 28 1970-03-11 22:45 ccid_bulk
crw------- root root 10, 29 1970-03-11 22:45 ccid_ctrl
drwxrwx--- u0_a247 u0_a247 2013-11-04 13:26 com.mgyun.shua.su
drwxr-xr-x root root 2013-11-04 13:43 com.mgyun.shua.su.daemon

crw------- root root 5, 1 1970-03-11 22:45 console


if we uninstall the Chinese SU app is the phone clean.. or do i need a full wipe?

Also my PC appears to RUN OK. looking for any malware but don't see any.
 

k1mu

Senior Member
Apr 11, 2011
1,945
1,620
Virginia
At this point I have every reason to believe there is a huge threat with rooting this way. The su binary starts a listening server and remains connected:

unix 3 [ ] STREAM CONNECTED 5629 3127/su /dev/com.mgyun.shua.su.daemon/server
unix 3 [ ] STREAM CONNECTED 11730 3118/.suv

---------- Post added at 01:55 PM ---------- Previous post was at 01:52 PM ----------

root@jfltevzw:/dev # ls -la
ls -la
---------- root root 0 1970-03-11 22:45 .coldboot_done
drwx--x--x system system 1970-03-11 22:45 .secure_storage
-rw-r--r-- root root 66560 1970-03-11 22:45 __properties__
crw-rw-r-- system radio 10, 25 1970-03-11 22:45 alarm
crw-rw---- adb adb 10, 30 1970-03-11 22:45 android_adb
crw-rw-rw- root root 10, 21 1970-03-11 22:45 ashmem
crw------- nfc nfc 10, 34 1970-03-11 22:45 bcm2079x
crw-rw-rw- root root 10, 22 1970-03-11 22:45 binder
drwxr-xr-x root root 2013-11-04 13:26 block
crw------- bluetooth bluetooth 10, 224 1970-03-11 22:45 btlock
drwxr-xr-x root root 1970-03-11 22:45 bus
crw------- root root 10, 28 1970-03-11 22:45 ccid_bulk
crw------- root root 10, 29 1970-03-11 22:45 ccid_ctrl
drwxrwx--- u0_a247 u0_a247 2013-11-04 13:26 com.mgyun.shua.su
drwxr-xr-x root root 2013-11-04 13:43 com.mgyun.shua.su.daemon

crw------- root root 5, 1 1970-03-11 22:45 console




In all fairness that could be an update daemon.

That's not a listening network server, it's a local RPC daemon. That may be how the su program talks to the new SuperSU program.

What do you see if you try
$ netstat -an | grep LISTEN

That will show you any existing network listeners that anyone could connect to.

$ netstat -an | grep ESTAB
will show you established connections.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 17
    Break down of VRoot Application

    Maybe a mod can retitle this thread to "does anyone want to stick their junk in a vice?" :cowboy:

    Why would they do that?

    I have been doing some long running tests on this, and here is what I have found: This applies the VRoot Method specifically. I have 6 S4's, two Note 2's and 1 Note 3. All of them were rooted with this method. Additionally, I installed the root application on a clean Windows 7 VM. I then setup dumps of netstat each second, and RAN this for the last 48 hours. Additionally, I filtered everything on the VM through the stateful packet inspection feature of my Cisco ASA, and did a complete TCP Dump of all tests.

    When I first installed the application I made a dump of my registry hive, and then again after installation and first run. The application made no malicious or suspicious changes to my file system or registry. I observed that the application was not automatically running on install. Once I was done with that I launched the application for the first time. I found that the app spawned three process, specifically, Root.exe, RomasterConnection.exe, rommaster_daemon.exe. I observed that the Root.exe was the primary application process. This process made a few http calls to 91.199.212.171, 178.255.82.1, 58.61.152.154. All of these packets were captured on my tcpdump were non-encrpyted, standard HTTP. They all appear to be requests for updated banners, logos, and check for updates.

    The second process that was spawned was rommaster_deamon. This application appeared to be the local listeners for the root exploit. Specifically, it bound three sockets to my loopback address. All data that was transmitted in regards to the daemon appeared to be local only. This process never established communication with a non loopback address.

    The third process that was created was RonnasterConnection.exe. This process was only active during the root itself, and when you initially connect the phone. This process connected to the following IP's: 123.235.32.69, 202.104.151.51 and 218.59.209.165. These resolve back to dataservice.mgyun.com, and point to an API located at: /models/api/Adaptation. This was also done via HTTP. After reviewing the packets there are some strings being exchanged that are obfuscated. This is likely due to the fact that they are exchanging data via an API. I don't personally feel like there was a real threat to this.

    Additionally, this application never transmitted data beyond the initial execution. I let it run for almost two days and the application never sent a single packet beyond initial startup, connection of a phone, and actual rooting. In fact, after a few minutes the root.exe application would allow it's sub processes to die if they werent used, completely unbinding the ports.

    Lastly, I dug into the included DLL's and executables. I decompiled a lot of them, and checked the manifests on almost all of them. Here is an example of the manifest for the main application:

    1 VERSIONINFO
    FILEVERSION 1,7,2,0
    PRODUCTVERSION 1,7,2,4200
    FILEOS 0x4
    FILETYPE 0x1
    {
    BLOCK "StringFileInfo"
    {
    BLOCK "080404b0"
    {
    VALUE "CompanyName", "????"
    VALUE "FileDescription", "Root??"
    VALUE "FileVersion", "1, 7, 2, 0"
    VALUE "InternalName", "Root"
    VALUE "LegalCopyright", "Copyright (C) 2013 Xinyi All Rights Reserved"
    VALUE "OriginalFilename", "Root.exe"
    VALUE "ProductName", "Root??"
    VALUE "ProductVersion", "1, 7, 2, 4200"
    }
    }

    BLOCK "VarFileInfo"
    {
    VALUE "Translation", 0x0804 0x04B0
    }
    }

    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
    <requestedPrivileges>
    <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
    </requestedPrivileges>
    </security>
    </trustInfo>
    <dependency>
    <dependentAssembly>
    <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.30729.1" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
    </dependency>
    </assembly>

    Specifically, I noticed that its execution level is set to "asInvoker" which basically means the application is content with running as whatever level it was executed as. If you were to execute the application as a non-admin it would be completely "OK" with that. Thats not very typical or ideal for a malicious application.

    Ill follow up shortly with my findings on the phone application. Again, these captures, etc. have been performed over about 48 hours.

    000_0015.jpg
    13
    Alright, now on the phone. I did notice that the application is very hard to remove on the Galaxy S4, running 4.3. I had two S4's that were not OTAed. In both cases I noticed that when I rooted them I could install SuperSU, and update the binarys without issues. On the other 4, I had to manually kill the processes, move the files, etc. This appears to be a result of the SU binaries running with a daemon. I actually found that when I tried to use the Chinese Superuser app to update su from SuperSU, it also failed. This MUST mean that SuperSU is a virus! (OK, that part was a joke).

    Anyhow, I did the same, I bound my MAC address on each of the S4's the Ciscos and the packet capture server, and watched them for just shy of two days. In all cases the Superuser apk, or SU binaries never attempted to reach out to any remote hosts. I also ensured this to be true via the LTE. Lets just say I have access to that.

    In conclusion: I think that the root application itself probably does some nontraditional methods of root, due to the SE Kernel, 4.3, etc. I don't personally have any issues with using this root method in the future. I will go ahead and replace the included SU and superuser apps with SuperSU (because Im familiar with it), but have no reason to be concerned about the originals.
    11
    Would you mind writing up a nooby guide to do this? I'm rooted with vroot and have never done adb scripts. I tried all the commands with terminal emulator but the first step when trying to mount system it fails

    Sent from my SCH-I545 using xda app-developers app

    After you succesfull root with vroot follow these steps

    1. you will need titanium backup installed on your phone.
    2.go into titanium backup, click backup/restore
    3. scroll down until you reach all of the knox apps and click on each individual knox app and freeze it
    4. download
    http://www.megafileupload.com/en/file/467618/root-de-la-vega-zip-zip.html and then unzip the folder and add root files folder and the .sh file to the root of your phone and not your sd card.
    5. go into terminal emulator and type SU, if you get a # then your good, if it asks for root permission grant it.
    6.one you have # showing or no error comes up in terminal emulator press the home button and go back into Titanium backup then back/restore and scroll down to superuser should have blue shield, and freeze it.
    7.now go into terminal emulator and type mount -o rw,remount /system hit enter
    8. now type rm /system/bin/su hit enter
    9. now type rm /system/xbin/su hit enter
    10. now type cd /mnt/sdcard/ hit enter
    11. now type sh root_de_la_vega.sh and hit enter
    12. now type reboot.

    once your phone reboots you should be root with supersu, launch titanium backup to test.

    let me know if you run into issues.
    9
    I have a few high level devs looking into these root exploits to see exactly what is going. Don't worry guys, we'll get to the bottom of these odd and sketchy methods. Whatever it is, the exploits themselves for actually gaining root are working so we're trying to see if we can recreate them into our own guaranteed safe method.
    9
    Be aware that as of this moment XDA has deemed the Kingo root method and Vroot method are not allowed on XDA. There are concerns with the information which is collected during the root method by the exploit. It is not about a continuous malware which may affect your device but about important information shared about your device, serial numbers etc during the root process which could be huge securities issues. You have all been warned.