• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

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

mainefungi said:
Can please you do a pull of the full /system/etc directory with privileges for stayboogy... Or at least do a ls of the directory to be sure those scripts and the verify.zip are the only contents of the directory...

Good news is I finally got a tracking number for my replacement phone yesterday. Bad news is Fedex is not registering it yet, which means it has not been scanned yet. :(
Click to expand...

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

custom_config/app:
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

dhcpcd/dhcpcd-hooks:
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

security/cacerts:
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
...
...
 
stayboogy said:
i like your style.

and great effort, but

this won't work, as it is right now anyway

1) the verify.zip must be removed first, and whatever file calls it's function. changing the script changes its hash

2) su has to already be on the phone for your commands to work, which it's not.

it would need something like

cp /sdcard/su /system/xbin

then

chown 0.0 /system/xbin/su
chmod 06755 /system/xbin/su
ln -s /system/xbin/su /system/bin/su


but then it would also run at every boot, unless later modified not to do so.

3) also, after init.qcom.thermald_conf.sh is run, the system is mounted ro once again (last line of that script), so the root command would have to come right after the rw mount of this script


hypothetically, though, your method would work as long as these hiccups are dealt with first.
Click to expand...

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 :(
 
ebildude123 said:
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 :(
Click to expand...

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?
 
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
 
mainefungi said:
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?
Click to expand...

The su binary doesn't survive reboots unfortunately. It is not present in /system/xbin following reboots.
 
mainefungi said:
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
Click to expand...

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.
 
Unkn0wn0ne said:
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.
Click to expand...

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...
 
stayboogy said:
i'll be glad to help find a root method if someone can give me some info on the phone.

i'm wanting to buy one, but i don't want to buy it if i can't root it. so let's get root.

info i need:

1. is there a locked bootloader???

--to find out, make sure usb debugging is enabled in your phone settings; ie, settings, system, developer options, usb debugging
--then download this file sdk-tools, unzip it, open a command window from within this folder and type adb reboot-bootloader
--if all you get is <waiting for device> then just close the command window
--if the phone does reboot into the bootloader, then in the same command window type fastboot oem unlock
--if a warning comes up, just accept it, and now your bootloader is unlocked--there is a chance you could lose all your data, so back it up first


2. is there a recovery, and if so what is it???

--to find out, download the zip from above, open a command window within that folder, then type adb reboot recovery
--give me some info on what type of recovery comes up--even a picture would be better


Then we'll go from here. someone please do this that has this phone. the quicker i get this info, the quicker a root can be found. it's quite possible one of the many jelly bean root processes could work. i assume the reason no one has found a working one is because of an incompatible su file maybe, but i'm not sure.
Click to expand...
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
eek.gif
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....!!
 
ebildude123 said:
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 :(
Click to expand...

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
 
stayboogy said:
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
Click to expand...

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?
 
Unkn0wn0ne said:
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?
Click to expand...

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.
 
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.
 
ebildude123 said:
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.
Click to expand...

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.
 
stayboogy said:
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.
Click to expand...



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...
 
stayboogy said:
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.
Click to expand...

I don't think you understand, if the app does the exploit it will be able to mount /system r/w
 
ebildude123 said:
I don't think you understand, if the app does the exploit it will be able to mount /system r/w
Click to expand...

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.
 
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.
 
ebildude123 said:
I don't think you understand, if the app does the exploit it will be able to mount /system r/w
Click to expand...

no,

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...
 
You must log in or register to reply here.
Back
Top Bottom