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

That's true. I just realized that that line in the fstab is commented out anyways, so it might not be the file we're looking for.

It's getting pretty late I'll have to check it out more tomorrow

Interesting.... So I wonder what its for then?

Just to let you all know, I have tried getting temp root, creating a folder called /part and mounting the parts there with telnet. Every one wouldn't mount except system and data.
 
Interesting.... So I wonder what its for then?

Just to let you all know, I have tried getting temp root, creating a folder called /part and mounting the parts there with telnet. Every one wouldn't mount except system and data.

I figured out that that file is a hexidecimal file, but I think it's just some optional block device driver or something since it was commented out in the fstab file. It just looked interesting, especially because It was in fstab.

Wait so you're creating the 'part' directory in / (root) directory? I'm confused on how you're going about achieving temp root.
 
I figured out that that file is a hexidecimal file, but I think it's just some optional block device driver or something since it was commented out in the fstab file. It just looked interesting, especially because It was in fstab.

Wait so you're creating the 'part' directory in / (root) directory? I'm confused on how you're going about achieving temp root.

I see.

I achieve temp root just like in the wiki for the first method. I then, with root privileges, create a folder in / called something (I choose "part") and then type adb shell, su, then busybox mount -w /dev/block/mmcblk0p1 /part. All though any partitions from 1-18 did not work (19 did, that's system) and 21 (data).
 
I see.

I achieve temp root just like in the wiki for the first method. I then, with root privileges, create a folder in / called something (I choose "part") and then type adb shell, su, then busybox mount -w /dev/block/mmcblk0p1 /part. All though any partitions from 1-18 did not work (19 did, that's system) and 21 (data).

Oh I see, you mounted /system in a different directory. I'm guessing /part didn't survive reboot and niether did any changes to the contents?
 
That is correct, nothing survived. :(

I tried placing a bunch of simple txt files all around the filesystem and after reboot none of them survived. I'm starting to think whoever said that this telnet trick isn't getting us 'real' root access is right. ):

I know this is kind of unrelated, but since the ZTE Valet is affected by the HeartBleed SSL bug, will we be able to patch that once this device is rooted by copying updated openssl binaries to the device? Sorry, this is my first Android device i don't know if you have to have a whole custom ROM or something like that for the phone to recognize the binaries. ZTE hasn't responded to any of my emails about this issue or anything else so I'm guessing I'll have to patch the bug manually, but that will be impossible if we can't at least gain 'real' temp root access.
Screenshot_2014-06-12-16-20-04.png
 
I tried placing a bunch of simple txt files all around the filesystem and after reboot none of them survived. I'm starting to think whoever said that this telnet trick isn't getting us 'real' root access is right. ):

I know this is kind of unrelated, but since the ZTE Valet is affected by the HeartBleed SSL bug, will we be able to patch that once this device is rooted by copying updated openssl binaries to the device? Sorry, this is my first Android device i don't know if you have to have a whole custom ROM or something like that for the phone to recognize the binaries. ZTE hasn't responded to any of my emails about this issue or anything else so I'm guessing I'll have to patch the bug manually, but that will be impossible if we can't at least gain 'real' temp root access.
Screenshot_2014-06-12-16-20-04.png

It is real root access in my opinion, its just that something is erasing (or replacing) unknown files on reboot.

Unfortunately, I don't have any better idea than you do. I am asuming that that would be possible to just copy binaries, but I don't know. I have never dealt with OpenSSL.
 
I tried placing a bunch of simple txt files all around the filesystem and after reboot none of them survived. I'm starting to think whoever said that this telnet trick isn't getting us 'real' root access is right. ):

I know this is kind of unrelated, but since the ZTE Valet is affected by the HeartBleed SSL bug, will we be able to patch that once this device is rooted by copying updated openssl binaries to the device? Sorry, this is my first Android device i don't know if you have to have a whole custom ROM or something like that for the phone to recognize the binaries. ZTE hasn't responded to any of my emails about this issue or anything else so I'm guessing I'll have to patch the bug manually, but that will be impossible if we can't at least gain 'real' temp root access.
Screenshot_2014-06-12-16-20-04.png

I tried that and got the same results.
 
Its possible but the root method is still in process of being completed so there will be no errors.
Yeah, I figured it was still in development. I just want to root this thing to get rid of the bloatware and solve some performance issues. You guys have been doing a fantastic job working on a solution for these ZTE phones! A lot of us out here are very grateful for your work!
 
Yeah, I figured it was still in development. I just want to root this thing to get rid of the bloatware and solve some performance issues. You guys have been doing a fantastic job working on a solution for these ZTE phones! A lot of us out here are very grateful for your work!

Im not working on it. lol I am just a tester too. Though if they get it working it would be great.
 
I'm not sure if this information is helpful or not but I gained root ADB access.
Code:
me@mycomputer:~$ adb remount
remount succeeded
me@mycomputer:~$ adb shell
root@android:/ #

I got it by gaining temp root by using method 1 here: https://github.com/Unkn0wn0ne/RootMyValet/wiki/Manual-installation-Instructions and then installing and running this app: [2013.05.24][ROOT] adbd Insecure v1.30 - xda-developers.

After that I remounted system as read only and then exited out and typed adb remount again. It said 'remount succeeded' but I got back into adb shell and ran mount and it showed /system as read only still. Everything behaves pretty much the same way as before with those 'mount: Read-only file system' errors when I try to manually mount /system as rw.

I would have thought that having native insecure adb would fix that problem with mounting /system as rw. Maybe that app doesn't do the same thing as setting ro.secure=0?

-------- UPDATE ---------
You know how /system automatically gets remounted as read only after a while? it happened while i was in root adb and the su binary disappeared from /system/xbin but the symlink still remained in /system/bin until reboot along with a test file I planted in /system. Why did the su binary get erased when /system was remounted but the other two files stayed there? An Anti-SU mechanism like we suspected before?
 
Hey guys, sorry I have been absent for so long. For what it's worth I just had a heart to heart with ZTE... That is, I just gave them hell for not complying with GPL... I am going to see if I can get them to budge on releasing their code. Here is the conversation I just had with them... I know that in the past manufactures have released code if they get enough pressure about GPL compliance.


Please hold while a Service Agent responds
Evelyn is serving You
Evelyn said:(09:46:03 07-04-2014)
Welcome to ZTE’s Live-Chat service. How may I help you?
Evelyn said:(09:46:11 07-04-2014)
Hi

You said:(09:46:41 07-04-2014)
I need to get the source code for the ZTE Valet. Can you please point me to the proper URL?

Evelyn said:(09:49:02 07-04-2014)
I am sorry to tell you that it is not open to public, so I can not offer it to you.

You said:(09:50:18 07-04-2014)
Under the GPL for the Android Operating system the source must be made available.

Evelyn said:(09:53:23 07-04-2014)
I am sorry, I don't have the relevant information.

You said:(09:57:09 07-04-2014)
Unless source is provided, I will be sending an email to gnu.org to report the violation of the Android GPL. This could result in the banning of US sales for android devices manufactured by ZTE, as well as many fines.
You said:(09:59:46 07-04-2014)
I am also aware that ZTE has refused to provide source for other devices falling under GPL, including routers and DSL modems working off of the Linux OS. These violations will also be referenced. A class action suit will be organized.

Evelyn said:(10:00:38 07-04-2014)
Please wait one second, I'll check more details for you.

You said:(10:00:55 07-04-2014)
I will wait. Thank you.

Evelyn said:(10:04:56 07-04-2014)
Thanks for your waiting. Would you mind to provide me your full name, best call-back number and e-mail address, I will informe our technicians to call you back in 2~3 hours.

You said:(10:07:30 07-04-2014)
Yes, my name is Ryan Clark call back number is 1-xxx-xxxx. Email address is xxxxxxxxxx@gmail.com, and this is my preferred method of contact.
You said:(10:07:57 07-04-2014)
Please be advised of the following. https://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
You said:(10:08:40 07-04-2014)
If you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.
You said:(10:09:27 07-04-2014)
Because ZTE has released it's device for public use, it is required to provide the Source to the user.

Evelyn said:(10:11:29 07-04-2014)
Thanks for your information. We don't have the souce except our development engineer.

You said:(10:12:42 07-04-2014)
Thank you. Please pass this conversation along to them, and a link to the source can be provided to my email. xxxxxxxxx@gmail.com

Evelyn said:(10:13:59 07-04-2014)
Okay, I'll.
Evelyn said:(10:14:08 07-04-2014)
Sorry for the inconvenience.
Evelyn said:(10:14:17 07-04-2014)
Is there anything else I can do for you?

You said:(10:14:43 07-04-2014)
No, nothing else. Thank you for your help.
Evelyn said:(10:20:41 07-04-2014)

 
Hey guys, sorry I have been absent for so long. For what it's worth I just had a heart to heart with ZTE... That is, I just gave them hell for not complying with GPL... I am going to see if I can get them to budge on releasing their code. Here is the conversation I just had with them... I know that in the past manufactures have released code if they get enough pressure about GPL compliance.


Please hold while a Service Agent responds
Evelyn is serving You
Evelyn said:(09:46:03 07-04-2014)
Welcome to ZTE
 
Nice job mainefungi! Hopefully the development engineer will actually get back to you.

Funny you should ask. I did get a call at 3:49 EST, from customer service. While BBQing with the family.

The call came in with caller ID 8675526773333, which when converted to a proper international number would be "+86-755-26773333". This is also the the number listed on the Contact Us page for calling customer service.

I stressed to them that I am entitled to have access to the source code. They asked what I wanted it for, so I explained that I am an amateur developer, but that makes no difference because the Android OS is Open Source. I explained that by using the Android OS on their devices they are agreeing to the terms of the Android GPL... And because of this, if they release a modified version of the OS to the public, the terms of the GPL requires them to make the modified source code publicly available to the end user.

The person on the other end seemed VERY polite and understanding. They thanked me for giving more details about my request and said they would have a technician get in contact with me early next week either by phone or email...

I guess all I can do is wait... Just took a screen shot of the call. Not that it proves anything... This still may go nowhere, but it is worth a shot. Keep your fingers crossed everyone!

1zf6auf.jpg


I pulled the dialer up to hide my sisters number... Although she is the very best veterinarian I know, I am not sure how she would handle being inundated with calls... LOL
 
Found something interesting. Using Towelroot (with modstring "1337 0 0 0 4 0"), it reports that I now should have root. However, my root checker says it's not rooted. And no prompts from SuperSU to allow access... Which means to me that the su binary did not get copied.

If I run Towelroot without the modstring it simply fails and reboots. What is significant though is that with the modstring the kernel did at least allow the towelroot exploit to run.

Any thoughts?

2s7avk8.png
 
Back
Top Bottom