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

Search This thread

Surge1223

Recognized Contributor
Nov 6, 2012
2,622
7,466
Florida
Google Pixel 6 Pro
After I posted what I saw in the log I recieved, I though it might be a good idea to begin reverse engineering this thing as well. Doesnt that log look sketchy to anyone else? It was enough to give me the green light on starting ida lol.

P.S.

Can someone run this command below in terminal then immediatley proceed to attempt to update the su binaries (while keeping terminal running) Then after it fails, go in back to terminal, hold vol down and press the letter "d" to end the terminal process if its still going, and finally save the output then post/pm it to me?

Code:
busybox cat /system/bin/*

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

k1mu

Senior Member
Apr 11, 2011
1,945
1,620
Virginia
I installed DroidWall, and blocked almost everything, including this app. I personally have no reason to believe this is malware. So far it seems pretty normal. I have also Sandboxed the root tool on my PC, and don't see that its trying to comm to anything except when actually rooting. Additionally, Googling indicates this is a pretty normal, and tested Chinese root too. Im leaving it on my phone to see what happens.

---------- Post added at 02:55 PM ---------- Previous post was at 02:53 PM ----------

Are you using a clean MJ7 update, or did you try to keep root through an OTA? I am using stock MJ7 and worked like a charm.



---------- Post added at 02:59 PM ---------- Previous post was at 02:55 PM ----------




root@jfltevzw:/ # busybox netstat -an | grep LISTEN
busybox netstat -an | grep LISTEN
... noise deleted..

That help? Thats the local daemon you are talking about?
Yes. That means that there's no open listeners.

With the ESTABLISHED search, we would be able to say that there's no outbound connections *at the time you checked*.

---------- Post added at 08:19 PM ---------- Previous post was at 08:10 PM ----------

I can't update the SU binaries, but am fully rooted. I wonder if haxxor had better luck... ill txt him and ask

So, you claim to have root with this.
What happens if you try to remount /system read/write? You should always be able to do that then delete the "SuperSU" replacement apk.
That won't remove the "su" binary that gives you root.

What I would try is to put a known good SuperSU.apk onto the sdcard. Then, mount /system read/write, remove the current .apk, then install the new one.

If you can't remount /system, then the supplied SuperSU isn't working right - you're still SELinux constrained. The original SuperSU runs a daemon that is supposed to work around those constraints on 4.3. (Unfortunately, I'm not rooted so can't tell.. but the half-a$$ root that I got after the upgrade definitely could not remount /system.)

If you can remount /system read/write but can't remove the installed SuperSU apk, then there's two possibilities: the APT's SuperSU replacement is protecting itself for some reason, or the SELinux protections aren't completely bypassed.
 

Ythan

Member
Oct 31, 2013
13
2
www.shroomery.org
This worked for me. After installing vroot I got a copy of SuperSU's su binary. Then from an ADB console:

$ su
# mount -o rw,remount /system
# cp -f /path/to/supersu/su /system/bin/

Reboot, uninstall vroot's "Superuser" app with Titanium Backup, install SuperSU. Seems to be working great so far!
 

k1mu

Senior Member
Apr 11, 2011
1,945
1,620
Virginia
This worked for me. After installing vroot I got a copy of SuperSU's su binary. Then from an ADB console:

$ su
# mount -o rw,remount /system
# cp -f /path/to/supersu/su /system/bin/

Reboot, uninstall vroot's "Superuser" app with Titanium Backup, install SuperSU. Seems to be working great so far!

Thanks - that's positive news.
 

Andrew149

Senior Member
Jul 17, 2010
1,515
243
Modesto CA
This worked for me. After installing vroot I got a copy of SuperSU's su binary. Then from an ADB console:

$ su
# mount -o rw,remount /system
# cp -f /path/to/supersu/su /system/bin/

Reboot, uninstall vroot's "Superuser" app with Titanium Backup, install SuperSU. Seems to be working great so far!

Awesome anyone have exposed working?

Sent from my SAMSUNG-SGH-I337 using Tapatalk
 

Menardo

Senior Member
This worked for me. After installing vroot I got a copy of SuperSU's su binary. Then from an ADB console:

$ su
# mount -o rw,remount /system
# cp -f /path/to/supersu/su /system/bin/

Reboot, uninstall vroot's "Superuser" app with Titanium Backup, install SuperSU. Seems to be working great so far!


Any confirmation of this working?!

Sent from my HTC6500LVW using XDA Premium HD app
 

gsi30

Member
Nov 5, 2013
5
1
I have a Samsung galaxy s 4 with Verizon. the root worked fine but cant get supersu to update. I have try a few things that have been posted here and nothing. Is there any thing wrong with just using the Chinese super su. don't know that much about this rooting stuff.
 

stuckintheskull

Senior Member
Sep 12, 2012
170
56
OnePlus 9 Pro
This worked for me. After installing vroot I got a copy of SuperSU's su binary. Then from an ADB console:

$ su
# mount -o rw,remount /system
# cp -f /path/to/supersu/su /system/bin/

Reboot, uninstall vroot's "Superuser" app with Titanium Backup, install SuperSU. Seems to be working great so far!

Could you do this from terminal on phone?

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

Ythan

Member
Oct 31, 2013
13
2
www.shroomery.org
I'm honestly not sure but I think you have to use ADB. I know Linux but I'm pretty new to Android. I wish I could give a more authoritative answer. :eek:

Xposed is working fine, you just have to make sure to get the latest version, otherwise Knox won't let you enable or disable modules. The Tweakbox module is a little weird (like the options for the long-press home button option don't actually correspond to the real settings anymore), but overall I haven't had any problems.
 
  • Like
Reactions: stuckintheskull

LilTechPrincess

Senior Member
Sep 27, 2012
145
64
Southwest, MO
Yes. That means that there's no open listeners.

With the ESTABLISHED search, we would be able to say that there's no outbound connections *at the time you checked*.

---------- Post added at 08:19 PM ---------- Previous post was at 08:10 PM ----------



So, you claim to have root with this.
What happens if you try to remount /system read/write? You should always be able to do that then delete the "SuperSU" replacement apk.
That won't remove the "su" binary that gives you root.

What I would try is to put a known good SuperSU.apk onto the sdcard. Then, mount /system read/write, remove the current .apk, then install the new one.

If you can't remount /system, then the supplied SuperSU isn't working right - you're still SELinux constrained. The original SuperSU runs a daemon that is supposed to work around those constraints on 4.3. (Unfortunately, I'm not rooted so can't tell.. but the half-a$$ root that I got after the upgrade definitely could not remount /system.)

If you can remount /system read/write but can't remove the installed SuperSU apk, then there's two possibilities: the APT's SuperSU replacement is protecting itself for some reason, or the SELinux protections aren't completely bypassed.

I know her and helped her root hers and did my own as well. System is definitely R/W. Ill try a few things when Im not mobile.



This worked for me. After installing vroot I got a copy of SuperSU's su binary. Then from an ADB console:

$ su
# mount -o rw,remount /system
# cp -f /path/to/supersu/su /system/bin/

Reboot, uninstall vroot's "Superuser" app with Titanium Backup, install SuperSU. Seems to be working great so far!

Ill give this a try in a bit, too. Will report back.

---------- Post added at 09:26 PM ---------- Previous post was at 09:25 PM ----------

I'm honestly not sure but I think you have to use ADB. I know Linux but I'm pretty new to Android. I wish I could give a more authoritative answer. :eek:

Xposed is working fine, you just have to make sure to get the latest version, otherwise Knox won't let you enable or disable modules. The Tweakbox module is a little weird (like the options for the long-press home button option don't actually correspond to the real settings anymore), but overall I haven't had any problems.


Ill write up a how to on this.
 

Ythan

Member
Oct 31, 2013
13
2
www.shroomery.org
I got su copied, uninstalled superuser, installed SuperSU, but SuperSU wont update binary

Hrm, I don't think I left anything out of my instructions, I wonder if there's something different about our phones..? Do you still have root after rebooting? It sounds like you may need to run vroot again and give it another try. Maybe for good measure, also put a copy of the SuperSU su binary in /system/xbin in addition to /system/bin, and make sure the binaries are -rwsr-sr-x root root. Other than that I'm kind of at a loss... hopefully someone else with more expertise will chime in. If I can help in any way please let me know.
 

Tada10

Senior Member
Feb 19, 2013
486
182
Looks like the 1.7.2 of Vroot worked for me. :) Just got done disabling all of Knox crap...

Sent from my SCH-I545 using Tapatalk
 

thekantorfour

New member
Dec 19, 2010
3
0
Kingo Root Didn't work for me

i have the MJ7 build stock, and it says it's not supported. Did anyone do anything special to get it to work? Also, any details anyone did besides just let it run?
 

Tada10

Senior Member
Feb 19, 2013
486
182
i have the MJ7 build stock, and it says it's not supported. Did anyone do anything special to get it to work? Also, any details anyone did besides just let it run?


Try this and let it update itself then run. I think it has to have the latest version to work for some like mine.

MOD EDIT: Vroot is currently being investigated so links are not allowed at this time

This is a link to Vroot.

Sent from my SCH-I545 using Tapatalk
 
Last edited by a moderator:

Tada10

Senior Member
Feb 19, 2013
486
182
I actually like their Superuser has other features like boot speed and cache cleaner. :)
yvebe6y3.jpg
amaby2a4.jpg
a3are3yt.jpg


Sent from my SCH-I545 using Tapatalk
 

Attachments

  • uploadfromtaptalk1383631158906.jpg
    uploadfromtaptalk1383631158906.jpg
    52.9 KB · Views: 358

open1your1eyes0

Senior Member
Dec 13, 2010
2,651
3,671
New York City
Looks like the 1.7.2 of Vroot worked for me. :) Just got done disabling all of Knox crap...

Sent from my SCH-I545 using Tapatalk

Are you able to successfully install Safestrap after disabling all the Knox related files? If my guess is correct, SELinux is set to force Enforcing in the kernel and should not allow you anyways. Also you may not be able to access settings.db (Settings Storage) with SQL Editor either.

This is of course beyond the scope of root here but just curious.
 
Last edited:

open1your1eyes0

Senior Member
Dec 13, 2010
2,651
3,671
New York City
Try this and let it update itself then run. I think it has to have the latest version to work for some like mine.

REMOVED

This is a link to Vroot.

Sent from my SCH-I545 using Tapatalk

There's actually an even later version straight from VRoot source

As we are still unsure about the safety of these root methods (though no hard evidence of malicious activity yet) use to your discretion.
 
Last edited by a moderator:

Tada10

Senior Member
Feb 19, 2013
486
182
Are you able to successfully install Safestrap after disabling all the Knox related files? If my guess is correct, SELinux is set to force Enforcing in the kernel and should not allow you anyways. Also you may not be able to access settings.db (Settings Storage) with SQL Editor either.

This is of course beyond the scope of root here but just curious.

I didn't try Safestrap yet but just tested SQL and no go.
apajudu8.jpg


Sent from my SCH-I545 using Tapatalk
 

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.