• 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...

I'm sorry for all the inactivity. I've been committing on the git repository, but I haven't had a lot of time to get things together. I am off from school on Easter break for a little while, so I'm going to try and put it together soon.
 
I tried compiling it myself a couple weeks ago to see how the app looked while it ran and if it worked. It did not. Was my first try at compiling an android apk and the source was almost greek to me. I can try compiling again tonite if the project is finished.
 
All

I am also trying to root my Valet - but I am a bit shocked , it does not appear that anyone has tried either stopping the cron that runs at bootup which verifies and validates the root fs and removes unlisted files, or adding SU to the list of valid files.

I am not a coder of any sort so I might be wrong about this - but it appears the FS is using some sort of file to verify against what is there - and then remove undesirables. Possibly verify.zip in system/etc ?

Also , in platform.xml , it appears there is a permissions group called "diag" and also "input" which authorizes RW permissions to any system resource. Wouldn't it be possible to elevate the permissions group to the user to "diag"? I understand that we are talking file system level elevations when talking about groups ; but there has to be some way of controlling what level the user's permission has.

If some one has figured out a way to temp SU into the file system - why not start by figuring out which files are running cron at startup and either stopping them, or adding SU as a legitimate file so that it will not delete it. Has anyone tried adding some other file to the root instead of SU, to see if the filesystem deletes it as well? Would most certainly prove that a cron was doing cleanup at boot.

Just trying to put my 2c in , cause I would love to see this phone rooted. Too many things require a rooted phone - but the most important to me ;; titanium.
 
I am having an issue trying to gain temp root:
root@android:/ # busybox cp /sdcard/su /system/xbin/su
cp: can't create '/system/xbin/su': Input/output error
1|root@android:/ # cd /system/xbin
root@android:/system/xbin # chmod 06755 su
Unable to chmod su: No such file or directory

Also are there any updates on how the root is coming? I noticed that the release date is a few days due (on github).
 
All

I am also trying to root my Valet - but I am a bit shocked , it does not appear that anyone has tried either stopping the cron that runs at bootup which verifies and validates the root fs and removes unlisted files, or adding SU to the list of valid files.

I am not a coder of any sort so I might be wrong about this - but it appears the FS is using some sort of file to verify against what is there - and then remove undesirables. Possibly verify.zip in system/etc ?

Also , in platform.xml , it appears there is a permissions group called "diag" and also "input" which authorizes RW permissions to any system resource. Wouldn't it be possible to elevate the permissions group to the user to "diag"? I understand that we are talking file system level elevations when talking about groups ; but there has to be some way of controlling what level the user's permission has.

If some one has figured out a way to temp SU into the file system - why not start by figuring out which files are running cron at startup and either stopping them, or adding SU as a legitimate file so that it will not delete it. Has anyone tried adding some other file to the root instead of SU, to see if the filesystem deletes it as well? Would most certainly prove that a cron was doing cleanup at boot.

Just trying to put my 2c in , cause I would love to see this phone rooted. Too many things require a rooted phone - but the most important to me ;; titanium.


i'm of the opinion that the "temp root" is nothing more than some pseudoroot error that happens through the telnet server because the user never has root privileges because not a single file can be added to or taken from the filesystem, or edited and the changes persist a reboot--it may say it has done so but obviously it hasn't else the phone would be rooted by now.

secondly, in order to modify permissions in any of the permission files, the system needs to be rw, yet it's not, so there's that.

thirdly, obviously the system is verifying its contents, this was observed long ago. so nothing new there. and since trying to edit this to show that su is a valid file can't be done because the system is not rw.


***this is what i've been thinking for a long time now***

the system is either being ghost mounted or symbolically linked on another partition at boot which is what the user has access to--which if you look at the partition table and how many partitions there are one could see how this would be possible http://androidforums.com/zte-valet/799676-ill-help-find-root-method-if.html#post6293292http://androidforums.com/zte-valet/799676-ill-help-find-root-method-if.html#post6293292); or one of the many other partitions contains a copy of some individual part of the /system and is shown as being mounted as one partition by the user.

the only problem with these ideas is that i'm familiar with linux, but not familiar with any way to even begin to duplicate these same scenarios on a linux machine.


The basic thing to note is that read/write access has never not once been gained by anyone on this device. I know many think they have, but obviously they have not because nothing has ever persisted a reboot.

The best possible fix is for someone to figure out exactly what's on all those other partitions, and find the file or files that verifies the boot.img hash and change it to match the size with ro.secure=0 modified in the default.prop of the ramdisk. modifying the boot worked, it just also happened to brick the phone because its hash couldn't be verified...
 
Unkn0wn0ne...I have gone to your repository and been able to build and compile source code into working apk. The problem I'm having is with the manual installation instructions that mention su, roothandler and push.sh script. I can download su binary and roothandler is part of source but I can't find push.sh script. Where is this script or what does it contain?
 
All I want to do is to delete some internal system apps that are VERY annoying. I do not mind having files that I added disappear after reboot all I want is to delete the app(s). My goal is to remove some junk addware apps that came with it. I do not need permanent root.

Yes I do know about disabling them but I wan to get rid of them PERMANENTLY because one of them is DRIVING ME INSANE!!!! (email app)

Can somebody be more clear when it says to "Run some commands"? I do not understand...

On a separate note: The Raptor_Jesus account has had its password by an *** changed so I made a new bugmenot account.
 
There is a apk called RootmyValet.apk. Which was posted 17 hours ago on github. I'd like to hear about from unknownone though. Make sure everything is working correctly.
 
No root achieved for me.

everything pushed via adb to /data/local/tmp
chmod 755 all files
the apk reported no error, rebooted, tried multiple times to no avail.
 
All I want to do is to delete some internal system apps that are VERY annoying. I do not mind having files that I added disappear after reboot all I want is to delete the app(s). My goal is to remove some junk addware apps that came with it. I do not need permanent root.

Yes I do know about disabling them but I wan to get rid of them PERMANENTLY because one of them is DRIVING ME INSANE!!!! (email app)

Can somebody be more clear when it says to "Run some commands"? I do not understand...

On a separate note: The Raptor_Jesus account has had its password by an *** changed so I made a new bugmenot account.


just to be clear, regardless what the thread says, there really hasn't even been a "temp root" achieved as the user never has superuser privileges to change anything on the filesystem, meaning no adding, no deleting, no moving, no changing...
 
just to be clear, regardless what the thread says, there really hasn't even been a "temp root" achieved as the user never has superuser privileges to change anything on the filesystem, meaning no adding, no deleting, no moving, no changing...

I agree. the farthest i've gotten is successfully copying and apply permissions to the binary with the help of cydia impactor. The SuperUser application even recognizes that it is there but as soon as i try to use the binary to gain su on my device, it fails and some mechanism reverts everything leaving the binary nowhere to be found. (Check the spoiler below for a copy of my telnet session.) Although it's possible that the binary was never truly copied in the first place, if the was the case, it is quite strange that the SuperUser application was able to find it and even analyze it to indicate that its an out-of-date binary that i'm using (it prompted me to update the binary to a newer version.)

Screenshot of the SuperUser app recognizing the binary:
Screenshot_2014-05-16-17-11-30.png


Anyways, i definitely agree that temporary root using the method explained in the thread is impossible due to the fact that the su binary is unusable and gets erased even when it is successfully copied. I think we will have to dig deeper to find a root method. Are there any other devices with similar security mechanisms that have been rooted?

***@**:~$ telnet 192.168.1.144 2222
Trying 192.168.1.144...
Connected to 192.168.1.144.
Escape character is '^]'.

~ $ su
su: must be suid to work properly
~ $ ls
acct init.qcom.class_core.sh persist
cache init.qcom.class_main.sh proc
charger init.qcom.rc res
config init.qcom.ril.path.sh root
d init.qcom.sh sbin
data init.qcom.usb.rc sdcard
default.prop init.qcom.usb.sh storage
dev init.rc sys
etc init.target.rc system
fstab.msm7627a init.trace.rc ueventd.goldfish.rc
init init.usb.rc ueventd.qcom.rc
init.charger.rc logo.bmp ueventd.rc
init.goldfish.rc mnt vendor
~ $ cd /system
/system $ ls
app etc lib tet xbin
bin fonts media usr
build.prop framework partner-app vendor
/system $ exit
Connection closed by foreign host.
***@**:~$ telnet 192.168.1.144 22
Trying 192.168.1.144...
Connected to 192.168.1.144.
Escape character is '^]'.

~ # su
FIX ME! implement ttyname_r() bionic/libc/bionic/stubs.c:466
root@android:/ # mount -o rw,remount /system
root@android:/ # mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/mmcblk0p19 /system ext4 rw,relatime,data=ordered 0 0
/dev/block/platform/msm_sdcc.3/by-num/p22 /data ext4 rw,nosuid,nodev,relatime,noauto_da_alloc,data=ordered 0 0
/dev/block/mmcblk0p10 /persist ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
/dev/block/mmcblk0p21 /cache ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
/dev/fuse /storage/sdcard1 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/block/vold/179:33 /storage/sdcard0 vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:33 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /storage/sdcard0/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0
root@android:/ # cd /system
root@android:/system # ls
app
bin
build.prop
etc
fonts
framework
lib
media
partner-app
tet
usr
vendor
xbin
root@android:/system # echo test >> test.txt
sh: can't create test.txt: I/O error
1|root@android:/system # mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
~ # exit
Connection closed by foreign host.
***@**:~$ clear





















***@**:~$ telnet 192.168.1.144 2222
Trying 192.168.1.144...
Connected to 192.168.1.144.
Escape character is '^]'.

~ $ su
su: must be suid to work properly
~ $ cp
BusyBox v1.21.1 (2013-10-18 12:31:34 PDT) multi-call binary.

Usage: cp [OPTIONS] SOURCE... DEST

Copy SOURCE(s) to DEST

-a Same as -dpR
-R,-r Recurse
-d,-P Preserve symlinks (default if -R)
-L Follow all symlinks
-H Follow symlinks on command line
-p Preserve file attributes if possible
-f Overwrite
-i Prompt before overwrite
-l,-s Create (sym)links

~ $ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: permission denied (are you root?)
~ $ exit
Connection closed by foreign host.
***@**0:~$ telnet 192.168.1.144 22
Trying 192.168.1.144...
Connected to 192.168.1.144.
Escape character is '^]'.

~ # su
FIX ME! implement ttyname_r() bionic/libc/bionic/stubs.c:466
root@android:/ # mount -o rw,remount /system
root@android:/ # mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/mmcblk0p19 /system ext4 rw,relatime,data=ordered 0 0
/dev/block/platform/msm_sdcc.3/by-num/p22 /data ext4 rw,nosuid,nodev,relatime,noauto_da_alloc,data=ordered 0 0
/dev/block/mmcblk0p10 /persist ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
/dev/block/mmcblk0p21 /cache ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
/dev/fuse /storage/sdcard1 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/block/vold/179:33 /storage/sdcard0 vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:33 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /storage/sdcard0/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0
root@android:/ # busybox cp /data/local/tmp/su /system
root@android:/ # busybox cp /system/su xbin
cp: can't create 'xbin': Read-only file system
1|root@android:/ # mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/mmcblk0p19 /system ext4 rw,relatime,data=ordered 0 0
/dev/block/platform/msm_sdcc.3/by-num/p22 /data ext4 rw,nosuid,nodev,relatime,noauto_da_alloc,data=ordered 0 0
/dev/block/mmcblk0p10 /persist ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
/dev/block/mmcblk0p21 /cache ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
/dev/fuse /storage/sdcard1 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/block/vold/179:33 /storage/sdcard0 vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:33 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /storage/sdcard0/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0
root@android:/ # cd /system
root@android:/system # ls
app
bin
build.prop
etc
fonts
framework
lib
media
partner-app
su
tet
usr
vendor
xbin
root@android:/system # rm su
root@android:/system # busybox cp /data/local/tmp/su /system/xbin
root@android:/system # cd xbin
root@android:/system/xbin # ls
dexdump
su
root@android:/system/xbin # busybox chmod 06755 su
root@android:/system/xbin # ls -l
-rwxr-xr-x root shell 55664 2013-07-19 11:20 dexdump
-rwsr-sr-x root root 380532 2014-05-16 22:02 su
root@android:/system/xbin # mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/mmcblk0p19 /system ext4 ro,relatime,data=ordered 0 0
/dev/block/platform/msm_sdcc.3/by-num/p22 /data ext4 rw,nosuid,nodev,relatime,noauto_da_alloc,data=ordered 0 0
/dev/block/mmcblk0p10 /persist ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
/dev/block/mmcblk0p21 /cache ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
/dev/fuse /storage/sdcard1 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/block/vold/179:33 /storage/sdcard0 vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:33 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /storage/sdcard0/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0
root@android:/system/xbin # ls
dexdump
root@android:/system/xbin #
*********** NOTE *************
Right before the last mount command is when i tried giving root access to the Adaway app, but obviously something was screwed up and everything got reverted and /system was mounted read-only again.
 
I have been working with unknown one on GitHub. Right now we are just fixing a shell script so that the root system works properly.
At the moment the apk is bugged and will be wooed on after the shell script is fixed. The apk is dependent on the shell script working.
(This post was posted by Elliot Labs from the github project)
Unknown one has been busy but he has been working on the github project. Don't lose hope!
 
Have you guys tried the strace command? A guy who works on Linux supercomputers said that would tell you where the all of the commands originate from (read from) so in effect it will tell you if there is a symlink or ghosted partition ( or some other type of partition spoofing).
On a related note:
At github we are working on correcting the shell script that roots the system. We will fix the apk when the shell script is fixed. Unknown one said he is busy with school and that is the reason for him being absent.

Thanks for all of your help so far!!! You are a great community! Keep up the great work!
 
Root(temp) has been achieved and bloatware was removed.:five: The root did not persist after a reboot but the bloatware was still not present after a reboot. Unfortunately there is an error on trying to remount the /system/xbin folder. :eviltongue:

So there is proof that there is no symlinked or ghosted partitions. It is an internal anti-su mechanism. I personally think it resides in the firmware (BIOS) not in the verify.zip file. :musicus:

As said before there was some certs in the verify.zip file. I personally believe that those are for signing the OS and or Updates (if there will be any). They would be like SSL certs in that case.
 
So as Bugmenot_Rules said, I did, and can, get very, very temporary root access:

Screenshot_2014-06-02-21-13-32_zps2fe2d159.png


Screenshot_2014-06-02-21-04-50_zpsf7b40957.png


As you can see, it does look like true root. However, it is not even close, even to temp root. Heres the latest why.

After accepting root access once (ex. Titanium Backup) you can use root privileges in that app. If you close and reopen it, or try to use another app, you cannot use root privileges again until you reboot, and run cmds again. The superuser app also recognizes it incorrectly after that, as shown by jjfriede (see this page). It seemes that the firmware is constantly scanning the FS for any sort of SU, as this happens without a reboot. :pcguru:

The other thing is that when I deleted LiveWallpapers.apk and Email.apk, I thought they hadnt returned for some reason, and thats what I told Bugmenot_Rules. However, I was wrong. I investigated it more recently and yes, they did return:

output_zps36b5bae0.jpg


So that means that there IS something replacing the apps on reboot. Whether it is another partition or what, I dont know.

For those that would like to try the method, go here https://github.com/benjimt/RootMyValet/blob/master/Install.txt and follow method 2.

Follow the latest progress here: https://github.com/Unkn0wn0ne/RootMyValet/issues?state=open
 
Back
Top Bottom