I need help rooting my zte quest 5

Search This thread

TexasPride

Member
Jun 3, 2018
19
2
Ok so i got a zte quest 5 (z3351s) though qlink. Not the phone i wanted but it was one i could afford. And it works very well just can't run amazon music and other apps at the same time.

But the bloatware is unreal. Used to in my galaxy s3&s4 days i could root and delete all apps i didn't need. I know i can disable them but i want them gone completely.

Majisk didnt work
Kingoroot same even used pc.

I am hoping someone knows of a way i can root this phone or at least delete all the un needed apps for example i have Google maps go (came stock) i put the org google maps which is better plus offers sat view.

Edit i did some math and converting and the useless apps 11 out of 58 come out to 349.72mb which is a lot if your phone only has 16gb of space. Also note i don't have hardly anything.

Worst case i can Hotspot to my note10+ for multitasking but not sure of data limit.
 
Last edited:

vp1117

Senior Member
Jan 30, 2019
55
6
@TexasPride

a phone's Android can get considered "rooted" as soon as in Android the SU-binary is present. Hence you at any time at your own can install the appropriate SU-binary onto your phone's Android by means of ADB.
Are you sure it will always work?

I tried this method of installing supersu: https://github.com/spff/install-supersu-via-adb

As a result, I got my phone eternally showing the boot logo and not booting.

Not a problem to re-flash stock ROM but it is an example that there in no universal way to install SU (or SuperSU) via adb.

If you could give a link to some other method how SU could be installed, I'll give it a try of course.
 

jwoegerbauer

Senior Member
  • Jul 11, 2009
    5,585
    9
    1,342
    European Union
    Are you sure it will always work?

    I tried this method of installing supersu: https://github.com/spff/install-supersu-via-adb

    As a result, I got my phone eternally showing the boot logo and not booting.

    Not a problem to re-flash stock ROM but it is an example that there in no universal way to install SU (or SuperSU) via adb.

    If you could give a link to some other method how SU could be installed, I'll give it a try of course.
    I spoke of SU-binary and NOT of SuperSU installer package
    Example:
    Code:
    adb devices
    adb push <location-of-matching-su-binary-on-computer> /sdcard/Downloads/ 2>nul
    adb shell "chmod 0777 /sdcard/Downloads/su"

    Of course you can install SuperSU package by means of ADB and this even when device is booted into Stock Recovery: but this requires to make some mods to SuperSU zip.
     

    vp1117

    Senior Member
    Jan 30, 2019
    55
    6

    TexasPride, sorry I stepped in your thread.​

    I spoke of SU-binary and NOT of SuperSU installer package
    I see. It is often mixed in numerous materials one can find in the net. Subject is SU-binary update, but the ultimate goal is to install supersu.

    Example:
    Code:
    adb devices
    adb push <location-of-matching-su-binary-on-computer> /sdcard/Downloads/ 2>nul
    adb shell "chmod 0777 /sdcard/Downloads/su"
    What should be result of running this code? SU-binary located in Downloads with 777 permission? What is the practical sense/use of it?
    What software/application would use SU in that location?
    Sorry for my questions. I'm not arguing. I try to understand the idea.

    Of course you can install SuperSU package by means of ADB and this even when device is booted into Stock Recovery: but this requires to make some mods to SuperSU zip.
    Somehow, with my almost zero knowledge of edify and linux command line I got the same conclusion: SuperSU zip has to be modified in order to install it via adb on devices that do not have TWRP for sideload. I failed to find any examples of SuperSU modding...
     
    Last edited:

    jwoegerbauer

    Senior Member
  • Jul 11, 2009
    5,585
    9
    1,342
    European Union
    @vp1117

    Answering your questions from last to first:

    1. Installing SuperSU.zip via ADB
      The SuperSU.zip doesn't come with an EDIFY coded script, but with an Android SHELL script - everyone who has knowledge of LINUX scripting can read / modify it.
      Android comes with TAR-binary, but not ZIP-binary. Hence the SuperSu.zip must get repacked into SuperSU.tar thus it can get extracted on Phone. The contents of such a TAR-file would look as shown here
      SU-installer.png
    2. Making use of SU-binary
      The SU-binary ( ~110KB ) is nothing else then the root user, as known from LINUX.
      Running in Android via ADB a command that requires super-user ( root ) rights is done as follows

      Example:
      Code:
      adb devices
      adb shell "/sdard/Downloads/su -c '<ommand-that-requires-root-here>'"
     
    Last edited:

    vp1117

    Senior Member
    Jan 30, 2019
    55
    6
    Answering your questions from last to first:

    1. Installing SuperSU.zip via ADB
      The SuperSU.zip doesn't come with an EDIFY coded script, but with an Android SHELL script - everyone who has knowledge of LINUX scripting can read / modify it.
      Android comes with TAR-binary, but not ZIP-binary. Hence the SuperSu.zip must get repacked into SuperSU.tar thus it can get extracted on Phone. The contents of such a TAR-file would look as shown here
      SU-installer.png

    OK. I guess, I can repack zip to tar.
    Sorry for my silly question but why should I need to keep superSU as an archive? Could not I just upload all folders + update-binary.sh to the phone? I'm sure I can do it.
    Am I right my next step would be running update-binary.sh (~60 KB) from <adb shell> command line?

    1. Making use of SU-binary
      The SU-binary ( ~110KB ) is nothing else then the root user, as known from LINUX.
      Running in Android via ADB a command that requires super-user ( root ) rights is done as follows

      Example:
      Code:
      adb devices
      adb shell "/sdard/Downloads/su -c '<ommand-that-requires-root-here>'"
    Interestingly, I can execute all commands I need without having su-binary (~100 KB) uploaded to my phone. It is strange but I see #-prompt after I ran <adb shell>. This happens on my UNrooted phone, running stock ROM. I guess, it's a specifics of my phone, no need to try explain it.
     

    jwoegerbauer

    Senior Member
  • Jul 11, 2009
    5,585
    9
    1,342
    European Union
    Sorry for my silly question but why should I need to keep superSU as an archive? Could not I just upload all folders + update-binary.sh to the phone? I'm sure I can do it.
    Am I right my next step would be running update-binary.sh (~60 KB) from <adb shell> command line?
    Of course it's your decision how you transfer the SuperSU package onto phone: many ways lead to Rome. :)

    My decision was to push SuperSU package repacked as TAR-file onto phone, extract it there, and finally run the modified update-binary.sh when phone is booted into recovery mode:

    Code:
    adb shell "$(cat < %supersu_dir%/update-binary.sh); echo $?"
     

    vp1117

    Senior Member
    Jan 30, 2019
    55
    6
    So I rebooted to stock recovery and then uploaded following from UPDATE-SuperSU-v2.82-20170528234214.zip package to my phone's folder /tmp:

    /arm64
    /common
    /META-INF
    update-binary.sh

    Here is what I got:

    Z:\android\adb>adb shell "$(cat < /tmp/update-binary.sh); echo $?"
    127
    /system/bin/sh: #!/sbin/sh: not found


    And here's what I got running same command from # command line:

    # $(cat < /tmp/update-binary.sh); echo $?
    /system/bin/sh: #!/sbin/sh: not found
    127


    In response to # ls -al /sbin I get lots of lines one of them is as follows:

    lrwxrwxrwx 1 root root 7 1970-01-01 00:00 sh -> busybox


    I feel that I'm doing something wrong, but what exactly?

    In attached txt-file I put some more details I got in command line.
     

    Attachments

    • supersu_via_adb.txt
      2.5 KB · Views: 1
    Last edited:

    jwoegerbauer

    Senior Member
  • Jul 11, 2009
    5,585
    9
    1,342
    European Union
    @vp1117

    NO.

    When I said modified then I didn't mean simply rename it: The contents of original update-binary file must be rewritten / deleted in some parts. Also, believe me, it makes sense to repack original SuperSU.zip to SuperSu.tar as I demonstrated above. Take also note that, if device's Android isn't rooted yet, the location for unpacked SuperSU mandatory must be /data/local/tmp.

    BTW:
    I can see BusyBox is installed on your device's Android. Take note that BusyBox by default comes with the SU-binary. Hence your device's Android is rooted! Wondering why you waste your time with trying to completely install SuperSU from scratch?
     

    vp1117

    Senior Member
    Jan 30, 2019
    55
    6
    Wondering why you waste your time with trying to completely install SuperSU from scratch?
    Good question.
    Probably, because I see this when phone restarts from recovery to normal android:
     

    Attachments

    • Screenshot_2021-05-15-16-05-24[1].png
      Screenshot_2021-05-15-16-05-24[1].png
      62.7 KB · Views: 9
    • Screenshot_2021-05-15-16-22-11[1].png
      Screenshot_2021-05-15-16-22-11[1].png
      93.7 KB · Views: 8
    • Screenshot_2021-05-15-16-22-32[1].png
      Screenshot_2021-05-15-16-22-32[1].png
      211.4 KB · Views: 9
    • Screenshot_2021-05-15-16-31-26[1].png
      Screenshot_2021-05-15-16-31-26[1].png
      93.5 KB · Views: 9
    Last edited:

    vp1117

    Senior Member
    Jan 30, 2019
    55
    6
    Also, believe me, it makes sense to repack original SuperSU.zip to SuperSu.tar as I demonstrated above.
    OK, no problem, I can re-pack zip into tar.

    However, what you demonstrated above was a screenshot showing update-binary.sh being inside the tar. At the same time you don't tell how update-binary.sh must be amended. Is it OK?