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

What if we alter the contents of their update.zip without breaking the signature?
Click to expand...

Don't think that will work...the contents of the META-INF folder, especially the CERT.RSA file, will reveal that something in the package has been changed.

The individual files of the signed .zip will be checked against the name / value (SHA1 sums) listed in either the MANIFEST.MF file.

Still not exactly sure why the CERT.SF file also lists name / value pairs whose SHA1 digests differ from what's listed in the MANIFEST.MF...:dontknow:

(sorry, not Stayboogy :) -- I'm sure he'll correct me if I made a faux pas)
 
scary alien said:
Don't think that will work...the contents of the META-INF folder, especially the CERT.RSA file, will reveal that something in the package has been changed.

The individual files of the signed .zip will be checked against the name / value (SHA1 sums) listed in either the MANIFEST.MF file.

Still not exactly sure why the CERT.SF file also lists name / value pairs whose SHA1 digests differ from what's listed in the MANIFEST.MF...:dontknow:

(sorry, not Stayboogy :) -- I'm sure he'll correct me if I made a faux pas)
Click to expand...

i'm not really sure why the update fails since it's signed.

and alien is right on the money.

i'm not the authority by any means though lol.

supposedly there is a "dumpkey" java tool that i'm seen mentioned in other places that can dump the key from a signed zip

but i've yet to find the actual binary anywhere.

zte has locked down the recovery to not accept the platform keys, meaning they're using a private key pair .pk8 and .pem to verify packages against.

previously, my thoughts were that zte was using a special command to mount the /system partition from updater-script, but all i saw was they are using a secure assert verifying the bootloader(?) locked state / boot.img hash verified.

but even using their supplied assert it still fails, meaning the key is wrong i assume.
 
stayboogy said:
supposedly there is a "dumpkey" java tool that i'm seen mentioned in other places that can dump the key from a signed zip

but i've yet to find the actual binary anywhere.
Click to expand...

In Unix / Linux, you used the openssl utility to dump the key / signature information (you'll have to extract the CERT.RSA file from the META-INF folder first):

openssl pkcs7 -inform DER -in CERT.RSA -noout -print_certs -text
Click to expand...

If you just wanted to verify the signed .jar or .zip file and display a little less information, you can do it two ways (both of the below utilities are part of standard Java):

keytool.exe -list -printcert -jarfile signed.zip
Click to expand...

jarsigner.exe -verbose -verify -certs signed.zip
Click to expand...

(the jarsigner.exe command above will verify each file contained in the signed file)

My AFV (Android File Verifier) app also has a signed jar verification function if you're interested (although you guys are not debating whether or not a file is properly signed or not).
 
Code: 
****@******:~$ openssl pkcs7 -inform DER -in '/home/****/Downloads/META-INF/CERT.RSA' -noout -print_certs -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 16338405541404418605 (0xe2bdad467baf222d)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=CN, ST=Shanghai, L=Shanghai, O=ZTE, OU=Smartphone Software Dept., CN=ZTE/emailAddress=support@zte.com.cn
        Validity
            Not Before: Apr 25 02:21:50 2013 GMT
            Not After : Sep 10 02:21:50 2040 GMT
        Subject: C=CN, ST=Shanghai, L=Shanghai, O=ZTE, OU=Smartphone Software Dept., CN=ZTE/emailAddress=support@zte.com.cn
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b7:43:30:17:b9:de:b5:e7:da:59:01:be:2e:71:
                    f5:89:cb:f6:6a:5f:3f:fe:30:3c:f5:9e:2d:29:50:
                    e6:15:04:2b:b7:dc:38:49:6f:c5:77:f7:cc:6c:01:
                    37:48:a4:8b:93:61:25:99:57:e8:3b:c4:15:e2:d1:
                    a3:fe:e6:0a:2d:e8:1e:20:1a:11:f7:9b:39:1e:55:
                    7c:95:3a:d1:0d:5d:70:7b:5b:7a:9c:85:a4:25:13:
                    ad:1a:cf:34:6a:a3:b3:7f:58:9b:11:0d:42:8b:70:
                    6a:20:4b:4c:ce:60:5b:10:2f:a0:6b:b2:ec:57:28:
                    60:48:c0:49:d8:bc:fe:e3:a9:45:77:da:32:1b:40:
                    44:ad:ec:2f:f5:36:7d:f0:c3:13:27:de:b8:4c:06:
                    32:8d:38:38:65:64:9a:fc:ac:5b:c6:06:72:96:d6:
                    f9:ec:0f:09:49:8b:b7:1b:45:31:48:d1:66:cb:91:
                    50:b9:a3:16:ec:2c:af:ce:0b:1c:96:5c:75:b6:eb:
                    4b:ad:37:67:85:f5:23:44:93:fa:78:f2:f8:5c:ba:
                    0a:4e:53:9f:3e:e9:af:ef:c3:71:c7:d4:80:21:d4:
                    f0:bc:70:71:70:76:59:41:ff:b5:d1:c8:0a:9a:8d:
                    11:a1:72:00:53:1e:37:45:9e:ef:d2:df:2a:01:6b:
                    e0:e9
                Exponent: 3 (0x3)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                B8:5E:0E:3B:85:DA:32:18:00:EF:EE:A7:C2:FB:01:3E:C8:90:59:22
            X509v3 Authority Key Identifier: 
                keyid:B8:5E:0E:3B:85:DA:32:18:00:EF:EE:A7:C2:FB:01:3E:C8:90:59:22

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
         75:e0:4c:5c:fc:b7:69:66:68:93:02:76:fa:cb:a2:9d:55:b9:
         0e:e4:a4:17:1f:6a:49:b5:73:08:aa:9f:65:ca:6a:10:fb:49:
         1c:38:cf:ba:de:24:f8:15:f0:f9:05:dc:be:e9:29:41:6b:10:
         8a:9a:80:76:0e:7f:22:be:95:40:29:ee:1d:6b:4b:71:13:a1:
         99:36:4e:5c:e6:80:e9:0c:5c:d9:bc:f0:33:b9:30:fc:7d:fd:
         72:d8:d2:2e:c5:b3:ce:30:5b:e3:d5:76:58:d0:ab:8d:d8:3f:
         4e:14:b7:c8:6c:70:24:16:83:9c:30:c3:64:94:ff:2b:05:ca:
         36:42:67:40:92:70:92:f7:53:81:68:4c:4b:70:97:18:f0:99:
         4f:99:f7:b8:2e:07:7d:80:a0:f8:88:b7:c5:8b:5b:7a:33:07:
         98:a3:e4:fc:29:ac:10:7f:9e:5c:a0:40:2d:94:7e:b5:e4:d2:
         7d:72:f0:71:11:a3:a5:2e:da:64:e6:50:f8:b7:4e:e1:c8:f5:
         78:04:91:02:99:b4:00:fa:5f:f5:f2:18:04:64:c9:ae:c2:75:
         f3:87:e1:33:30:37:22:94:36:93:e7:f6:7d:76:00:80:80:6f:
         aa:fb:be:fc:8d:d7:0c:54:e4:da:a7:72:71:20:a2:f0:fb:a4:
         da:af:21:c3

Using my Ubuntu system I dumped CERT.RSA key info from the update.zip and got this which looks like ZTE's public key which I believe confirms that ZTE signed the update using their own keypair. I hope this will be of some help.
 
i have a straight talk zte valet z665c phone and honestly iv been working on this same root for abouth 3 months now little sleep and on going process and non stop mtndew and monsters and ciggs and pizza so yeah hoping we come to a conclusion soon because id like to recover my lost photos from this phone using wondershare and dr fone and get this think licked what if we read the phone differently than just a mobile device and as a external hard drive like windows is programmed and change it to a storage device and by pass the protection on the storage some how

~~~

sincerely thank u guys for all the hard working hours ill be calling straight talk seeing if they will release their info on the phone
 
and i was thinking if we all go through diffrent towers then why couldt they modify the coding in wich u recive during a update a little to everyone have the extact time zone and adjust it to their time zone at the main company and redo the whole configuration and completly whipe the phone and redo all signature for the phone
 
locouseking69 said:
and i was thinking if we all go through diffrent towers then why couldt they modify the coding in wich u recive during a update a little to everyone have the extact time zone and adjust it to their time zone at the main company and redo the whole configuration and completly whipe the phone and redo all signature for the phone
Click to expand...


I am sorry I can not understand the what you are trying to say in this reply.
 
what i was trying to say was that every cell phone company is different right right then what would keep them from doing different updates and changing out something for their updates

~~~

/system/app/SettingsProvider.apk

~~~

/system/framework/framework-res.apk
/system/framework/ime.jar
/system/framework/input.jar
/system/framework/monkey.jar
/system/framework/pm.jar
/system/framework/requestsync.jar
/system/framework/svc.jar
/system/lib/drm/libfwdlockengine.so

~~~

the following files would have the networks and ditributor files in them iv been doing up computer for the past few months now and honestly their lies your problem if u can brake these down i believe u will find your sources u need
 
jjfriede said:
Code: 
****@******:~$ openssl pkcs7 -inform DER -in '/home/****/Downloads/META-INF/CERT.RSA' -noout -print_certs -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 16338405541404418605 (0xe2bdad467baf222d)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=CN, ST=Shanghai, L=Shanghai, O=ZTE, OU=Smartphone Software Dept., CN=ZTE/emailAddress=support@zte.com.cn
        Validity
            Not Before: Apr 25 02:21:50 2013 GMT
            Not After : Sep 10 02:21:50 2040 GMT
        Subject: C=CN, ST=Shanghai, L=Shanghai, O=ZTE, OU=Smartphone Software Dept., CN=ZTE/emailAddress=support@zte.com.cn
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b7:43:30:17:b9:de:b5:e7:da:59:01:be:2e:71:
                    f5:89:cb:f6:6a:5f:3f:fe:30:3c:f5:9e:2d:29:50:
                    e6:15:04:2b:b7:dc:38:49:6f:c5:77:f7:cc:6c:01:
                    37:48:a4:8b:93:61:25:99:57:e8:3b:c4:15:e2:d1:
                    a3:fe:e6:0a:2d:e8:1e:20:1a:11:f7:9b:39:1e:55:
                    7c:95:3a:d1:0d:5d:70:7b:5b:7a:9c:85:a4:25:13:
                    ad:1a:cf:34:6a:a3:b3:7f:58:9b:11:0d:42:8b:70:
                    6a:20:4b:4c:ce:60:5b:10:2f:a0:6b:b2:ec:57:28:
                    60:48:c0:49:d8:bc:fe:e3:a9:45:77:da:32:1b:40:
                    44:ad:ec:2f:f5:36:7d:f0:c3:13:27:de:b8:4c:06:
                    32:8d:38:38:65:64:9a:fc:ac:5b:c6:06:72:96:d6:
                    f9:ec:0f:09:49:8b:b7:1b:45:31:48:d1:66:cb:91:
                    50:b9:a3:16:ec:2c:af:ce:0b:1c:96:5c:75:b6:eb:
                    4b:ad:37:67:85:f5:23:44:93:fa:78:f2:f8:5c:ba:
                    0a:4e:53:9f:3e:e9:af:ef:c3:71:c7:d4:80:21:d4:
                    f0:bc:70:71:70:76:59:41:ff:b5:d1:c8:0a:9a:8d:
                    11:a1:72:00:53:1e:37:45:9e:ef:d2:df:2a:01:6b:
                    e0:e9
                Exponent: 3 (0x3)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                B8:5E:0E:3B:85:DA:32:18:00:EF:EE:A7:C2:FB:01:3E:C8:90:59:22
            X509v3 Authority Key Identifier: 
                keyid:B8:5E:0E:3B:85:DA:32:18:00:EF:EE:A7:C2:FB:01:3E:C8:90:59:22

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
         75:e0:4c:5c:fc:b7:69:66:68:93:02:76:fa:cb:a2:9d:55:b9:
         0e:e4:a4:17:1f:6a:49:b5:73:08:aa:9f:65:ca:6a:10:fb:49:
         1c:38:cf:ba:de:24:f8:15:f0:f9:05:dc:be:e9:29:41:6b:10:
         8a:9a:80:76:0e:7f:22:be:95:40:29:ee:1d:6b:4b:71:13:a1:
         99:36:4e:5c:e6:80:e9:0c:5c:d9:bc:f0:33:b9:30:fc:7d:fd:
         72:d8:d2:2e:c5:b3:ce:30:5b:e3:d5:76:58:d0:ab:8d:d8:3f:
         4e:14:b7:c8:6c:70:24:16:83:9c:30:c3:64:94:ff:2b:05:ca:
         36:42:67:40:92:70:92:f7:53:81:68:4c:4b:70:97:18:f0:99:
         4f:99:f7:b8:2e:07:7d:80:a0:f8:88:b7:c5:8b:5b:7a:33:07:
         98:a3:e4:fc:29:ac:10:7f:9e:5c:a0:40:2d:94:7e:b5:e4:d2:
         7d:72:f0:71:11:a3:a5:2e:da:64:e6:50:f8:b7:4e:e1:c8:f5:
         78:04:91:02:99:b4:00:fa:5f:f5:f2:18:04:64:c9:ae:c2:75:
         f3:87:e1:33:30:37:22:94:36:93:e7:f6:7d:76:00:80:80:6f:
         aa:fb:be:fc:8d:d7:0c:54:e4:da:a7:72:71:20:a2:f0:fb:a4:
         da:af:21:c3
Using my Ubuntu system I dumped CERT.RSA key info from the update.zip and got this which looks like ZTE's public key which I believe confirms that ZTE signed the update using their own keypair. I hope this will be of some help.
Click to expand...


let me see if i can use this...

in the meantime, someone try towelroot.

there's no reason towelroot shouldn't work

tr
 
i looked for the app on the app playstore too and their nothing their for this app
and i went and dowladed the apk from my phone and it only reads as js
 
how do i get binary on my phone i have some weird japonese emblems on my phone too i tried the programs ill go and phone it and sen u guy the link just need binoary becuse my phone intalled the app and yeah asked me yes or no i belive in chinese
 
mainefungi said:
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
Click to expand...

stayboogy said:
let me see if i can use this...

in the meantime, someone try towelroot.

there's no reason towelroot shouldn't work

tr
Click to expand...

mainefungi already tried towelroot. I just tested it on my phone too and I got the same results. no root.
 
the keys posted are the "key"

using this pair an update should pass verification

however,

turning that info into a pk and pem are beyond my pay grade.

if someone can give me some good info on the subject i'll have a properly signed update in seconds....
 
stayboogy said:
the keys posted are the "key"

using this pair an update should pass verification

however,

turning that info into a pk and pem are beyond my pay grade.

if someone can give me some good info on the subject i'll have a properly signed update in seconds....
Click to expand...

I'm no cryptography expert but I found a command online that I used to generate a PEM from the CERT.RSA:
Code: 
openssl pkcs7 -inform DER -in CERT.RSA -out CERT.pem -outform PEM  -print_certs

--- update ----
I'm not so sure this will work because the key in CERT.RSA I believe is only the public key and from what I know you would need the private key to do the signing.
 

Attachments

stayboogy said:
i'm not really sure why the update fails since it's signed.

and alien is right on the money.

i'm not the authority by any means though lol.

supposedly there is a "dumpkey" java tool that i'm seen mentioned in other places that can dump the key from a signed zip

but i've yet to find the actual binary anywhere.

zte has locked down the recovery to not accept the platform keys, meaning they're using a private key pair .pk8 and .pem to verify packages against.

previously, my thoughts were that zte was using a special command to mount the /system partition from updater-script, but all i saw was they are using a secure assert verifying the bootloader(?) locked state / boot.img hash verified.

but even using their supplied assert it still fails, meaning the key is wrong i assume.
Click to expand...

I found a Java class named "DumpKey.java" here:

"DumpKey.java" Dumping Private Keys Out of "keystore"

Would this help?
 
I guess I never would have thought it possible to be this hard to root. That said my last real programming language I knew was BASIC haha. Maybe I should pick up Linux/android. Anyway, can't we just wipe the thing down to nothing but a chunk of hardware and install whatever version of android the guts will run? I mean these smart phones are basically little computers...granted no CD drive but why can't we bypass all the software and just basically do a reformat?
 
Oh and I do want to thank you guys for the hard work and hours you have been putting in on this piece of crap haha. I guess I should have not bought this phone, from a company I've never even heard of. But it was cheap and I needed a new phone after my proclaim went to hell. Cheapest smartphone Walmart had for straightalk and this thing is so slow at times I think it might really have a 386 or 486 at best haha instead of the 1ghz the package says. That's why I'd been hoping for root, perhaps get rid of whatever is sliwin it down and run no frills CPU control to crank up the processor governor. As close as you guys seem to be getting I wonder if I shouldn't just get a phone from a reputable company instead... I'll be watching for now...got a week before payday and the 14 day "trial period"
 
chubyboy, i think tracfone stores the minutes/credentials on the phone itself. if you wipe the phone you'll be invalidating its use with the tracfone service. it seems they locked this phone down pretty hard to keep anyone from screwing with their account, i remember a while ago there was a glitch in one of their dumbphones that allowed people to redeem the same code over and over again.

sucks to hear it's running slow. i love tracfone, and their scheme on divvying minutes for android phones looks really good. unfortunately you'll be forced to deal with their custom apps, which is usually just spam.. when you say it's slow is that after some heavy use? can you tell what programs are always kept running in the background?

i'm gonna be watching this thread.. hopefully a root method exists somewhere, but it's obvious they'd do their best to keep it under wraps. i'll definitely get this phone if it can be modded.

thanks for your work stayboogy >:)
 
chubyboy said:
Oh and I do want to thank you guys for the hard work and hours you have been putting in on this piece of crap haha. I guess I should have not bought this phone, from a company I've never even heard of. But it was cheap and I needed a new phone after my proclaim went to hell. Cheapest smartphone Walmart had for straightalk and this thing is so slow at times I think it might really have a 386 or 486 at best haha instead of the 1ghz the package says. That's why I'd been hoping for root, perhaps get rid of whatever is sliwin it down and run no frills CPU control to crank up the processor governor. As close as you guys seem to be getting I wonder if I shouldn't just get a phone from a reputable company instead... I'll be watching for now...got a week before payday and the 14 day "trial period"
Click to expand...

It has a 1GHz processor, so it is not lacking in the CPU department. The reason it is so slow is because of its extremely low amount of RAM (~400MB). Jelly Bean (Android 4.1) needs at least 1GB of RAM to run smoothly.
 
richg said:
It has a 1GHz processor, so it is not lacking in the CPU department. The reason it is so slow is because of its extremely low amount of RAM (~400MB). Jelly Bean (Android 4.1) needs at least 1GB of RAM to run smoothly.
Click to expand...
It sucks that the phone has very little ram.

Also I don't want to state something obvious, but did anybody try the "fastboot oem unlock" or similar commands while under recovery mode to unlock the bootloader?
 
richg said:
It has a 1GHz processor, so it is not lacking in the CPU department. The reason it is so slow is because of its extremely low amount of RAM (~400MB). Jelly Bean (Android 4.1) needs at least 1GB of RAM to run smoothly.
Click to expand...

Kitkat (Android 4.4) is supposed to be highly optimized for devices with as little as 512MB of RAM so If we could root this thing and install a custom Kitkat rom and take out all the bloatware we might some some performance improvements. I know other android tracfones have been rooted and rom'd so I still don't see why it is so difficult to achieve that on the valet.

werewolfboy said:
It sucks that the phone has very little ram.

Also I don't want to state something obvious, but did anybody try the "fastboot oem unlock" or similar commands while under recovery mode to unlock the bootloader?
Click to expand...

the valet isn't even recognized by fastboot. I've seen ways to force a phone to boot into the bootloader but none of them were for the valet.
 
chubyboy said:
So it doesn't have the 2.34gb of total internal memory(which is what it says it has) or is only 400mb allotted to the os
Click to expand...

Check the specs here: ZTE Valet Specs, Features (Phone Scoop)

It has 2.34 of built in internal storage, a 4gb removable sd card.

Completely seperate from the internal storage and the sd card is the RAM. There is 512MB total. About 126MB of the RAM is reserved for the android operating system and the remaining 386MB is left for running all user applications and services.

---

Stayboogy, when you get a chance to look at it I generated a PEM file from the certificate in the update.zip. cert.pem.zip
 
jjfriede said:
Kitkat (Android 4.4) is supposed to be highly optimized for devices with as little as 512MB of RAM so If we could root this thing and install a custom Kitkat rom and take out all the bloatware we might some some performance improvements. I know other android tracfones have been rooted and rom'd so I still don't see why it is so difficult to achieve that on the valet.



the valet isn't even recognized by fastboot. I've seen ways to force a phone to boot into the bootloader but none of them were for the valet.
Click to expand...


you can force the bootloader on any device by wiping the boot partition / sometimes the recovery also.

and that is still an option.

make a backup of the current boot with the psuedo root method and using dd,

then dd if=/dev/zero of=path/to/by-name/boot bs=4096

reboot and you are in the bootloader.

on a linux box, you will need to run sudo fastboot oem unlock

it will only work with sudo unless you have some specific udev rules, which are completely unnecessary and unnecessarily complicated to set up correctly. as long as fastboot is in your path sudo fastboot should work.

doing this on a windows machine just running fastboot when in the bootloader you will more than likely get a "? fastboot" or permissions fault.

i just acquired a zte open c and thought that working with it would help in rooting this phone, but no luck.

a brave soul can try wiping the boot though to get to bootloader and unlock it

in order to get back to the device though you have to reflash the boot.img backup made previously with sudo fastboot flash boot /path/to/boot.img
 
You must log in or register to reply here.
Back
Top Bottom