1. Are you ready for the Galaxy S20? Here is everything we know so far!

Root i'll help find a root method if...

Discussion in 'Android Devices' started by stayboogy, Nov 25, 2013.

  1. karmmisht

    karmmisht Newbie

    stayboogy - thanks for the extra explanation. Here's a listing of ls -al /system/etc. Following that is a listing of ls -al */* at /system/etc to get the next directory level below. A full listing of the security/cacerts subdirectory was omitted - nothing more there than certs. I'll be out most of the rest of the day but if interested I'll try to attach or put what you might need out somewhere for download or perhaps unkn0wn0ne can do it.

    total 13592
    drwxr-xr-x 11 root root 4096 Dec 29 19:16 .
    drwxr-xr-x 14 root root 4096 Jan 1 1970 ..
    -rw-r--r-- 1 root root 5203 Jul 19 11:20 AudioFilter.csv
    -rw-r--r-- 1 root root 38140 Jul 19 11:20 BCM4330B1_002.001.032.0518.0520.hcd
    -rw-r--r-- 1 root root 148918 Jul 19 11:20 NOTICE.html.gz
    -rw-r--r-- 1 root root 2259 Jul 19 11:20 OperatorPolicy.xml
    -rw-r--r-- 1 root root 870 Jul 19 11:20 UserPolicy.xml
    -rw-r--r-- 1 root root 14124 Jul 19 11:20 apns-conf.xml
    -rw-r--r-- 1 root root 3999 Jul 19 11:20 audio_effects.conf
    -rw-r--r-- 1 root root 3836 Jul 19 11:20 audio_policy.conf
    drwxr-xr-x 2 root root 4096 Jul 19 11:20 bluetooth
    drwxr-xr-x 3 root root 4096 Jul 19 11:20 custom_config
    -r--r----- 1 bluetoot bluetoot 935 Jul 19 11:20 dbus.conf
    drwxr-xr-x 3 root root 4096 Jul 19 11:20 dhcpcd
    -rw-r--r-- 1 root root 12675 Jul 19 11:20 event-log-tags
    -rw-r--r-- 1 root root 3977 Jul 19 11:20 fallback_fonts-ja.xml
    -rw-r--r-- 1 root root 3977 Jul 19 11:20 fallback_fonts.xml
    drwxr-xr-x 2 root root 4096 Jul 19 11:20 firmware
    -rw-r--r-- 1 root root 2521 Jul 19 11:20 gps.conf
    -rw-r--r-- 1 root root 25 Jul 19 11:20 hosts
    -rw-r--r-- 1 root root 2755 Jul 19 11:20 init.ath3k.bt.sh
    -r-xr-x--- 1 root shell 1755 Jul 19 11:20 init.goldfish.sh
    -rw-r--r-- 1 root root 4660 Jul 19 11:20 init.qcom.bt.sh
    -rw-r--r-- 1 root root 3639 Jul 19 11:20 init.qcom.coex.sh
    -rw-r--r-- 1 root root 3546 Jul 19 11:20 init.qcom.composition_type.sh
    -rw-r--r-- 1 root root 1725 Jul 19 11:20 init.qcom.efs.sync.sh
    -rw-r--r-- 1 root root 3071 Jul 19 11:20 init.qcom.fm.sh
    -rw-r--r-- 1 root root 12900 Jul 19 11:20 init.qcom.post_boot.sh
    -rw-r--r-- 1 root root 2157 Jul 19 11:20 init.qcom.post_fs.sh
    -r-xr-x--- 1 root system 2767 Jul 19 11:20 init.qcom.sdio.sh
    -rw-r--r-- 1 root root 2337 Jul 19 11:20 init.qcom.thermald_conf.sh
    -rw-r--r-- 1 root root 9969 Jul 19 11:20 init.qcom.wifi.sh
    -rw-r--r-- 1 root root 2177 Jul 19 11:20 init.target.8x25.sh
    -rw-r--r-- 1 root root 50 Jul 19 11:20 init.wlanprop.sh
    -rw-r--r-- 1 root root 1804 Jul 19 11:20 loc_parameter.ini
    -rw-r--r-- 1 root root 6062 Jul 19 11:20 media_codecs.xml
    -rw-r--r-- 1 root root 15234 Jul 19 11:20 media_profiles.xml
    -rw-r--r-- 1 root root 730 Jul 19 11:20 mkshrc
    -rw-r--r-- 1 root root 13178880 Jul 19 11:20 pcsuite.iso
    drwxr-xr-x 2 root root 4096 Jul 19 11:20 permissions
    drwxr-xr-x 2 root root 4096 Jul 19 11:20 ppp
    -rw-r--r-- 1 root root 1070 Jul 19 11:20 qosmgr_rules.xml
    drwxr-xr-x 3 root root 4096 Jul 19 11:20 security
    -rw-r--r-- 1 root root 3187 Jul 19 11:20 system_fonts.xml
    -rw-r--r-- 1 root root 487 Jul 19 11:20 thermal-8x25-evb.conf
    -rw-r--r-- 1 root root 651 Jul 19 11:20 thermal-8x25-sku7.conf
    drwxr-xr-x 2 root root 4096 Jul 19 11:20 updatecmds
    -rw-r--r-- 1 root root 264492 Jul 19 11:24 verify.zip
    -rw-r--r-- 1 root root 16294 Jul 19 11:20 voicemail-conf.xml
    -rw-r--r-- 1 root root 1787 Jul 19 11:20 vold.fstab
    drwxr-xr-x 2 root root 4096 Jul 19 11:20 wifi
    -rw-r--r-- 1 root root 719 Jul 19 11:20 wiperconfig.xml

    ls -al */* at /system/etc:

    -r--r----- 1 bluetoot bluetoot 1760 Jul 19 11:20 bluetooth/audio.conf
    -rw-r----- 1 system system 1556 Jul 19 11:20 bluetooth/auto_pairing.conf
    -r--r--r-- 1 net_bt net_bt 401 Jul 19 11:20 bluetooth/blacklist.conf
    -r--r----- 1 bluetoot bluetoot 262 Jul 19 11:20 bluetooth/input.conf
    -rw-r--r-- 1 root root 4071 Jul 19 11:20 bluetooth/iop_device_list.conf
    -r--r----- 1 bluetoot bluetoot 3058 Jul 19 11:20 bluetooth/main.conf
    -r--r----- 1 bluetoot bluetoot 168 Jul 19 11:20 bluetooth/network.conf
    -r-xr-x--- 1 dhcp shell 1009 Jul 19 11:20 dhcpcd/dhcpcd-run-hooks
    -rw-r--r-- 1 root root 190 Jul 19 11:20 dhcpcd/dhcpcd.conf
    -rw-r--r-- 1 root root 235079 Jul 19 11:20 firmware/fw_bcmdhd.bin
    -rw-r--r-- 1 root root 1156 Jul 19 11:20 firmware/yamato_pfp.fw
    -rw-r--r-- 1 root root 9220 Jul 19 11:20 firmware/yamato_pm4.fw
    -rw-r--r-- 1 root root 944 Jul 19 11:20 permissions/android.hardware.camera.flash.xml
    -rw-r--r-- 1 root root 942 Jul 19 11:20 permissions/android.hardware.location.gps.xml
    -rw-r--r-- 1 root root 816 Jul 19 11:20 permissions/android.hardware.sensor.light.xml
    -rw-r--r-- 1 root root 815 Jul 19 11:20 permissions/android.hardware.sensor.proximity.xml
    -rw-r--r-- 1 root root 883 Jul 19 11:20 permissions/android.hardware.telephony.cdma.xml
    -rw-r--r-- 1 root root 881 Jul 19 11:20 permissions/android.hardware.telephony.gsm.xml
    -rw-r--r-- 1 root root 1144 Jul 19 11:20 permissions/android.hardware.touchscreen.multitouch.jazzhand.xml
    -rw-r--r-- 1 root root 975 Jul 19 11:20 permissions/android.hardware.usb.accessory.xml
    -rw-r--r-- 1 root root 791 Jul 19 11:20 permissions/android.hardware.wifi.direct.xml
    -rw-r--r-- 1 root root 829 Jul 19 11:20 permissions/android.hardware.wifi.xml
    -rw-r--r-- 1 root root 1050 Jul 19 11:20 permissions/android.software.live_wallpaper.xml
    -rw-r--r-- 1 root root 880 Jul 19 11:20 permissions/android.software.sip.voip.xml
    -rw-r--r-- 1 root root 828 Jul 19 11:20 permissions/com.android.location.provider.xml
    -rw-r--r-- 1 root root 816 Jul 19 11:20 permissions/com.google.android.maps.xml
    -rw-r--r-- 1 root root 835 Jul 19 11:20 permissions/com.google.android.media.effects.xml
    -rw-r--r-- 1 root root 261 Jul 19 11:20 permissions/com.google.widevine.software.drm.xml
    -rw-r--r-- 1 root root 930 Jul 19 11:20 permissions/com.qualcomm.location.vzw_library.xml
    -rw-r--r-- 1 root root 3191 Jul 19 11:20 permissions/handheld_core_hardware.xml
    -rw-r--r-- 1 root root 824 Jul 19 11:20 permissions/org.simalliance.openmobileapi.xml
    -rw-r--r-- 1 root root 9459 Jul 19 11:20 permissions/platform.xml
    -rw-r--r-- 1 root root 167 Jul 19 11:20 permissions/qcnvitems.xml
    -rw-r--r-- 1 root root 167 Jul 19 11:20 permissions/qcrilhook.xml
    -r-xr-xr-x 1 root root 5352 Jul 19 11:20 ppp/ip-up-vpn
    -rw-r--r-- 1 root root 1356 Jul 19 11:20 security/otacerts.zip
    -rw-r--r-- 1 root root 846 Jul 19 11:20 updatecmds/google_generic_update.txt
    -rw-r--r-- 1 root root 1102 Jul 19 11:20 wifi/bcmdhd.cal
    -rw-r--r-- 1 root root 95 Jul 19 11:20 wifi/p2p_supplicant.conf
    -rw-r--r-- 1 root root 77 Jul 19 11:20 wifi/wpa_supplicant.conf

    total 24
    drwxr-xr-x 6 root root 4096 Jul 19 11:20 .
    drwxr-xr-x 3 root root 4096 Jul 19 11:20 ..
    drwxr-xr-x 2 root root 4096 Jul 19 11:20 Launcher
    drwxr-xr-x 2 root root 4096 Jul 19 11:20 Settings
    drwxr-xr-x 2 root root 4096 Jul 19 11:20 contact
    drwxr-xr-x 2 root root 4096 Jul 19 11:20 mms

    total 16
    drwxr-xr-x 2 root root 4096 Jul 19 11:20 .
    drwxr-xr-x 3 root root 4096 Jul 19 11:20 ..
    -rw-r--r-- 1 root root 773 Jul 19 11:20 20-dns.conf
    -rw-r--r-- 1 root root 924 Jul 19 11:20 95-configured

    total 1040
    drwxr-xr-x 2 root root 4096 Jul 19 11:20 .
    drwxr-xr-x 3 root root 4096 Jul 19 11:20 ..
    -rw-r--r-- 1 root root 4767 Jul 19 11:20 00673b5b.0


  2. ebildude123

    ebildude123 Member

    This assumes you already did that temp root process, which means the su binary should already exist. I only see here that root privileges are lost upon reboot, the file shouldn't be deleted (but if it is, yes, we would need that command), just that the permissions on the file have changed. And lastly to deal with #3, we can just mount it read write again first using "mount -o rw,remount,barrier=1 /system" before the commands proceed, I purposely placed it at the end, so I know that it runs AFTER all that other scripts run, so that the root commands would be the last to run (meaning no other scripts come after modifying the system again).

    edit: And yup, verifying would be a problem :(
  3. mainefungi

    mainefungi Well-Known Member

    If indeed the su stays in the /system/xbin folder, then the checksum and size would already be different on reboot, causing a verify fail... wouldn't it?

    And if it stays... and it does not cause a verify fail... Then it seems to me that the only issue would be if some part of the verification specifically checked the size or checksum of "/system/etc/init.qcom.post_fs.sh"

    Or am I completely off base here?
  4. mainefungi

    mainefungi Well-Known Member

    This may also be completely useless... But here is a bit of code someone plugged into pastbin for the ZTE Warp Sequent... I only think it may be relevant because of how I found it...

    I sound it by searching for "/system/etc/verify.zip" on google... Not sure what the code is doing, as I am not that advanced... but if there is anything useful there that may give clues on how to work with the valet and/or whirl... then it is worth putting on the table...

    update - Pastebin.com

    EDIT: I know this is a long shot, but what are the chances of dumping the needed drivers from the stock ROM and then building a completely custom rom for the hardware? Of course, that would mean converting it to a qpst compatible hex image, and flashing it...

    If possible, it would eliminate the verify issues, replace the bootloader and recovery, and give us native root access... all in one fell swoop...

    Yes, it is okay to tell me to put down the crack pipe and hold my reality check until it can clear the bank... LOL
  5. Unkn0wn0ne

    Unkn0wn0ne Newbie

    The su binary doesn't survive reboots unfortunately. It is not present in /system/xbin following reboots.
  6. Unkn0wn0ne

    Unkn0wn0ne Newbie

  7. Unkn0wn0ne

    Unkn0wn0ne Newbie

    I wonder if this could be unlocked with fastboot. I still can't get fastboot to recognize the phone. I might try calling zte and saying that fastboot is beneficial to a developer and asking if there is anyway of getting to fastboot and/or unlocking the bootloader.

    I'm almost 100% positive unlocking the bootloader (either official or by forcefully exploiting it) would have prevented that verify error. I don't want to risk the later right now as this is my only phone and I have no backup phones I can use right now.
  8. ebildude123

    ebildude123 Member

  9. mainefungi

    mainefungi Well-Known Member

    Another longshot... but I know that adb reboot bootloader does not work by default (been there, done that, got the T-Shirt), but I wonder if the phone will load into the bootload with the temp root working...
  10. terminal23

    terminal23 Lurker

    Hi,can you help me to root Galaxy express 2(sm g3815)i tried all the methods for autoroot but nothing works i have a Vodafone Spain branded sm g3815...in download mode ihave this :CURRENT BINARY:Samsung Official,SYSTEM STATUS[​IMG]fficial,CSB-CONFIG-LSB 0X30,WRITE PROTECTION:Enable(locked bootloaders????)i installed android sdk and when i tap in cmd adb command "adb reboot bootloader"reboots in download mode and then i tap "fastboot oem unlock"and nothing(waiting for device)does this means locked bootloaders??sorry if i posted on the wrong forum but im looking for 4 days to root this device and nothing,im desperated....!!
  11. stayboogy

    stayboogy Android Expert
    Thread Starter

    let me explain a little better.

    init.qcom.thermald_conf.sh gets called before you put the root in there, which mounts the /system ro all by itself, meaning the ro command at the end of the init.qcom.post_fs.sh [the file in question] is useless--the system has already been mounted ro by thermald_conf. the root would have to be first in this script, after the inital rw mount, no other way around it. (i've been up and down all the scripts after i downloaded it.)

    then the verify problem dealt with, which

    seems to me, in my limited knowledge, unless something is hidden in the ramdisk of the boot.img, there's no reason verify.zip can't be removed, if read/write privileges are actually gained.

    of course this could also cause another brick. absolutely crazy why they've done this. it's a test. we'll figure it out.

    but... and this is real important

    what everyone seems to miss is that temp root is only active at that moment before the system is rebooted. the file is apparently not in actuality on the emmc else it would remain after boot. the reason's it's not there after reboot is because it wasn't there to begin with.

    all that has been done is pseudo-superuser privileges have been given to the user, but the system is still in read-only mode because it has not been successfully re-mounted read/write in the temp root process.

    the system must be truly mounted read/write then the su pushed, chown'd, chmod'd, symlinked, all before the phone has ever been rebooted.

    it would probably be best that the system was re-mounted once more read-only before the first reboot of a real push of su just to verify the system accepts the binary. if the binary is wrong, the system will deny access to #root
  12. Unkn0wn0ne

    Unkn0wn0ne Newbie

    Are you saying I should retry the exploit, but this time mount system as ro after I'm done than see if it's still there?
  13. stayboogy

    stayboogy Android Expert
    Thread Starter

    unless i missed something in all this the system hasnt been mounted rw yet.

    **edit. i see where you said it accepts the remount rw, but obviously it hasnt been else the binary would still be there on*reboot. at least i would think so. i doubt theres a command for wiping su if it exists on boot.
  14. Unkn0wn0ne

    Unkn0wn0ne Newbie

    I did get the system to mount rw on multiple occasions., it's a semi-long process back up a few posts.
  15. ebildude123

    ebildude123 Member

    Instead of trying to get around ZTE's silly verification, which I have doubts we'll have success at, why not just make an app that will perform the exploit everytime the devices boots up? Sure it's not ideal, but it'll work.
  16. stayboogy

    stayboogy Android Expert
    Thread Starter

    no, this will not work.

    there is no root access with read/write privileges to /system, period.

    apps do not have read/write access to /system.

    only rooted apps, which are for rooted systems can do such.
  17. mainefungi

    mainefungi Well-Known Member

    Best we can hope for short term is building our own PC script to make it more streamlined...

    One that will run the exploit, and then run through the terminal commands needed to grant privs...
  18. mainefungi

    mainefungi Well-Known Member

    I have been thinking about the battery below 25% vulnerability, and I wonder if the ZTE Valet may be able to use a USB Jig like some Samsung phones to put it into download mode...
  19. ebildude123

    ebildude123 Member

    I don't think you understand, if the app does the exploit it will be able to mount /system r/w
  20. mainefungi

    mainefungi Well-Known Member

    Not being an app writer, I would not even know where to begin.

    The app would need to have telnet integrated, and be granted the same privileges that are currently being granted to the wifi telnet session exploit being done by Cydia Impactor currently... Then the app can quickly run through the telnet commands currently being done manually.
  21. karmmisht

    karmmisht Newbie

    Seems like things are at some sort of impasse. If I understand things correctly, stayboogy's point is that if we are never really able to mount /system as rw, then there is no effective root for running root apps. Yet, Unkn0wn0ne has reported writing to /system. One quick test to see if this really is the case is to check the date-time stamp on /system/xbin or /system/bin to see if it has changed. On my phone (I have not been able to successfully remount /system), /system/xbin has a date of July 19 11:20 which I believe is about the same as the build date. So the directory date-time stamp is consistent with my experience of no remount.

    Now I can display more of my ignorance by asking a question - is /system restored from elsewhere each time during startup or is it simply mounted?

    Can some of you others try out the method outlined by Unkn0ne0ne and report back on what you can do? Can you install titanium backup root and do a backup?

    Also, I really appreciate the work done by stayboogy - it seems like the most robust approach. I really would like to see a more permanent root.
    It would be nice to be able to try some things out without the risk of a brick. I'm starting to worry that if some of the methods out there (Bin4ry, etc) actually worked, it might brick the phone.

    To contribute to mainefungi's brainstorming, here's another idea:

    [Q] Understanding how motochopper works - xda-developers

    It's a variation on motochopper. The author analyzed motochopper and put out an open source interpretation named kernelchopper. On p2 of the thread, a user proposed a method that did not require the kernel source. I messed with it a bit but am not sure if the Valet is vulnerable. I ran into some memory problems. Anyone else know if this could work?

    Happy New Year all.

    ** - just wanted to clarify something. I can get the phone to report /system as rw but if I try to write to it, I get an I/O error (same error message as from Impactor) and the partition is immediately shown to be ro.
  22. stayboogy

    stayboogy Android Expert
    Thread Starter


    trust me,

    YOU don't understand...

    there isn't r/w access to /system. if there was, then that would mean the phone is rooted which it's not.

    telnet has psuedo-root privileges, nothing more. never has been r/w access else the phone would be rooted.

    how come you don't understand this?

    unknown says he had r/w access, but obviously it wasn't real else su would still be on the phone, meaning it would be rooted and we wouldn't be having all this discussion...
  23. bummpr

    bummpr Newbie

  24. stayboogy

    stayboogy Android Expert
    Thread Starter

  25. mainefungi

    mainefungi Well-Known Member

    Right, and I think that is because the Valet is only vulnerable to bug 9695860, not to the original master key bug (8219321).

    From everything I read, bug 9695860 is a lot more limiting.

    On the bright side, I got my new phone today... I am back in the game.

Share This Page