• 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 may have something. In the zip file with the heartbleed update, there is a file called EMMCBOOT.MBN. It shows more information about the write protection that is used:
Code: 
$ strings EMMCBOOT.MBN | grep -i mmc
mmc init failed!
Failure enabling MMC Clock!
Error No.:%d: Failure resetting MMC cards!
cmmc_structure: %d
Error No. %d: Failure Initializing MMC Card!
 mmc_boot_main emmc gpio init start!
 Initializing MMC host data structure and clock!
MMC Boot: Error Initializing MMC Card!!!
MMC Boot: Failed detecting MMC/SDC @ slot%d
mmc_boot_set_system_partition_power_on_wp : enable H/W reset function
ERROR : mmc_boot_get_card_status failed , val = %d
ERROR : mmc_enable_hw_reset failed
ERROR : mmc_set_erase_group_def failed
before setting MMC_BOOT_US_PWR_WP_EN: USER_WP[%d] = 0x%x
MMC_BOOT_EXT_US_PERM_WP_DIS is not disabled , disable it now
ERROR : disabling PERM_WP and enable MMC_BOOT_US_PWR_WP_EN for USER AREA failed
enable MMC_BOOT_US_PWR_WP_EN to apply power on write protection
ERROR : enable MMC_BOOT_US_PWR_WP_EN for USER AREA failed
ERROR : mmc_boot_get_card_status failed
ERROR : mmc_boot_send_ext_cmd failed
after setting MMC_BOOT_US_PWR_WP_EN: USER_WP[%d] = 0x%x
MMC_BOOT_EXT_ERASE_GROUP_DEF is defined
ERROR : mmc_boot_get_card_status failed
ERROR : mmc_boot_set_clr_power_on_wp_user failed , val = %d
mmc_boot_set_system_partition_power_on_wp : set ERASE_GROUP_DEF in extended CSD register
mmc_boot_set_system_partition_power_on_wp : apply eMMC power on write protection on system partition
Could not read partition from mmc
MBR written to mmc successfully
Failed to write MBR block to mmc.
GPT: Could not read primary gpt from mmc
GPT: Could not read backup gpt from mmc
GPT: mmc read card failed reading partition entries.
MMC Boot: MBR read failed!
MMC Boot: GPT read failed!
Failed to erase the eMMC card
 androidboot.emmc=true
ERROR: Cannot set eMMC power on write protection on system partition
eMMC power on write protection applied on system partition successfully
error in emmc_recovery_init
mmc read failure %s %d
mmc write failure %s %d
A little google search on MMC_BOOT_US_PWR_WP_EN resulted in the page https://www.codeaurora.org/cgit/qui.../?id=e9f077b639b8878ba3aa2d832f2708d19e5d647d
Enable write protection for eMMC partitions based on the write group protection availability in the card. Write group protection availablity is checked by reading CSD. If it is available, then write protect group size is calculated from EXT_CSD or CSD based on ERASE_GROUP_DEF. SET_WRITE_PROT is sent for the number of write protect groups to be protected. For e.g. if 10MB is to be protected from a starting sector and if write protect group size is 4MB, then 3 groups of 4MB i.e. 12MB from the starting sector will be write protected. For clearing user power-on write protect, CLEAR_WRITE_PROT is sent and it is similar to SET_WRITE_PROT.Note that the sector to be write and the size should be specified in sectors.
Click to expand...
So, we need to somehow send a CLEAR_WRITE_PROT.

Not sure if this is really it though, since this code also appears at https://code.google.com/p/moboot/so...708d19e5d647d&path=/platform/msm_shared/mmc.c and https://github.com/ilarrain/lk-thunderg/commit/e9f077b639b8878ba3aa2d832f2708d19e5d647d

mmcutils can be used to remove write protection. From https://github.com/Hashcode/mmc-utils I downloaded the code in a zip-file. Then I modified the Makefile to compile it for android; I believe only three lines needed to be changed:
Code: 
CC = arm-linux-gnueabi-gcc
CFLAGS ?= -static -O2 -march=armv5
CHECKFLAGS = -Wall -Wuninitialized -Wundef
If you can't compile it, get my compiled file from here (MD5 ebe3bb5d07f131de40579d0ae83bdefe). After running make, I got an executable 'mcc' that I copied to the ZTE valet via the sd card.
Code: 
/system # cp /mnt/sdcard/mmc /system/mmc
/system # chmod 700 mmc
/system # ./mmc  writeprotect get /dev/block/mmcblk0p19
ioctl: Operation not permitted
Could not read EXT_CSD from /dev/block/mmcblk0p19
/system # ./mmc  writeprotect get /dev/block/mmcblk0
Boot write protection status registers [BOOT_WP_STATUS]: 0x00
Boot Area Write protection [BOOT_WP]: 0x00
 Power ro locking: possible
 Permanent ro locking: possible
 ro lock status: not locked
/system # ./mmc extcsd read /dev/block/mmcblk0 | grep WP
High-capacity W protect group size [HC_WP_GRP_SIZE: 0x08]
Boot write protection status registers [BOOT_WP_STATUS]: 0x00
Boot Area Write protection [BOOT_WP]: 0x00
User area write protection register [USER_WP]: 0x10
Note the value of USER_WP. A little Google search reveals that 0x10 corresponds to MMC_BOOT_US_PERM_WP_DIS, which means that permanent write protection for user area is not enabled. So, whatever it is, it is reversible. I thought this could fix it, but it does not work:
Code: 
/system # ioctl /dev/block/mmcblk0 1 171 0
sending ioctl 0x1 0xab 0x00 0x00 0x00 0x00 0x00 0x00 0x00
ioctl 0x1 failed, -1
I think we need to issue a command CLR_WRITE_PROT (see here).
 
I found out that ioctl should be used, but that it is complicated to do it from the command line, since you need to supply an entire mmc_ioc_cmd structure.

I have tried to run this piece of code:
Code: 
void clearprot(int memaddr) {
        int fd = open("/dev/block/mmcblk0", O_RDWR);
        if(! fd) {
                printf("open failed");
                return;
        }
        int ret = 0;
        struct mmc_ioc_cmd idata;

        memset(&idata, 0, sizeof(idata));
        idata.write_flag = 1;
        idata.opcode = 29;
        idata.arg = 34817; // from fdisk -l
        idata.flags = MMC_RSP_SPI_R1B | MMC_RSP_R1B | MMC_CMD_AC;

        ret = ioctl(fd, MMC_IOC_CMD, &idata);
        printf("return value: %d\n", ret);
        printf("response 1: %d\n", idata.response[0]);
        printf("response 2: %d\n", idata.response[1]);
        printf("response 3: %d\n", idata.response[2]);
        printf("response 4: %d\n", idata.response[3]);
}
Code: 
/system # ./test
return value: 0
response 1: 2304
response 2: 0
response 3: 0
response 4: 0
Not sure what this means.

When searching for "CMD29" in other root topics, I found a few discussions:
[WIP][DEV] S-Off [off-topic discussion prohi… - Pg. 158 | AT&T, Rogers HTC One X, Telstra One XL | XDA Forums
Root: shaking something loose [WIP] - Pg. 30 | HTC EVO 3D | XDA Forums
[DISCUSSION][SOLVED] ROOTING G2 Vision T-mob… - Pg. 73 | G2 and Desire Z | XDA Forums
They have not managed to remove the write protection, but also haven't tried hard enough (I think).
 
CDM:

CMD28 SET_WRITE_PROT
CMD29 CLR_WRITE_PROT
CMD30 SEND_WRITE_PROT

To do a force erase you have to send a CMD 42 (while the card is in transfer state) to the card with Bit_3 set to 1 and Bit_2, Bit_1 and Bit_0 set to 0.
This shold remove all temporary write protection bits from the CSD register and Group Write protections from the commands 28-30.
Click to expand...

Could this help at all?
 
Not sure that information is correct. The JEDEC specifications specifically mention that if bit 3 is set, the other bits should be 0. Moreover, a forced erase means that the emmc memory is wiped, even if it is password protected. Wiping is not something I'd try.
 
Very interesting stuff, Raptor_Jesus! :thumbup:

A part of This post on XDA (from one of the threads you linked to above), which I'm guessing you probably saw, says this and nicely summarizes what I think you guys are seeing on the Valet:

Fre3vo^2 is really just based on mapping around /system. The reason the files are "vanishing" or getting stuck is because they're being purged by the OS to make room in RAM. Unfortunately, because the /system partition in write-protected by the eMMC, the write never completes, and the data is lost. When the OS tries to get it back, it gets confused and fails with the stuck file handles in memory. So I created a tmpfs and over-mounted on /system, and transferred all the goods to /data/fre3vo/system/... and used symlinking. It didn't work all that well, and I decided to spend my time focusing on S-OFF.
Click to expand...

I do think that since the Valet appears to be locked-down (locked bootloader) that it may be very difficult to properly re-write to the /system partition (i.e., you might be chasing a locked bootloader issue as opposed to being able to write to /system--these two items are linked/related).

~ ~ ~

Also, I still don't understand why the Valet doesn't respond to the fastboot utility...:dontknow: :confused:

I don't remember if I've read that anyone has used fastboot on Linux to avoid the USB driver issues on Windows? (I'm pretty sure someone would have tried this, but thought I'd [re-]ask)
 
scary alien said:
Very interesting stuff, Raptor_Jesus! :thumbup:

A part of This post on XDA (from one of the threads you linked to above), which I'm guessing you probably saw, says this and nicely summarizes what I think you guys are seeing on the Valet:



I do think that since the Valet appears to be locked-down (locked bootloader) that it may be very difficult to properly re-write to the /system partition (i.e., you might be chasing a locked bootloader issue as opposed to being able to write to /system--these two items are linked/related).

~ ~ ~

Also, I still don't understand why the Valet doesn't respond to the fastboot utility...:dontknow: :confused:

I don't remember if I've read that anyone has used fastboot on Linux to avoid the USB driver issues on Windows? (I'm pretty sure someone would have tried this, but thought I'd [re-]ask)
Click to expand...

Yes. I used to have linux installed and my Valet still didn't respond to the fastboot command.

I don't know much about write-protection but good luck to all of those who might be able to figure it out.
 
Via a Google search on "MMC_CLR_WRITE_PROT", I found this nice kernel module: https://github.com/hiikezoe/android_mmc_protect

That is just what we need. If someone could compile it for the Valet that would be great; I can't.

This piece of code ran for about a minute, but didn't seem to make /system writable:
Code: 
void clearprot() {
        int i;
        int fd = open("/dev/block/mmcblk0", O_RDWR);
        if(! fd) {
                printf("open failed");
                return;
        }
        int ret = 0;
        struct mmc_ioc_cmd idata;

        memset(&idata, 0, sizeof(idata));
        idata.write_flag = 1;
        idata.opcode = 29;
        idata.flags = MMC_RSP_SPI_R1B | MMC_RSP_R1B | MMC_CMD_AC;

        int start_sect = 34817; // from fdisk -l
        int end_sect = 100352;
        int grp_size = 8; // mmc util gives that ERASE_GROUP_DEF = 1, that means that  protected segments are defined in units of HC_WP_GRP_SIZE = 8 erase  groups
        for(i=start_sect; i<=end_sect; i+=grp_size) {
                idata.arg = i;
                ret = ioctl(fd, MMC_IOC_CMD, &idata);
        }
}
 
Raptor_Jesus, I just ordered one. That's a great deal. The Moto E by iteself costs $100 and they throw in a $100 dollar service card with it so you get 1200 talk/text/data and 1 year of service. Once that arrives I'll be willing to do more risky testing on my Valet.
 
2BitGary said:
I don't see this phone listed on tracfones site. Are you sure this is for tracfone? Or is it only for certain areas?
Click to expand...
Tracfone now has a Bring Your Own Phone program, so phones don't have to be mentioned on tracfones site. I am in no way affiliated with the eBay seller or with tracfone, so I don't know how this deal can be priced so well or if it is even legit.
 
Raptor_Jesus said:
Tracfone now has a Bring Your Own Phone program, so phones don't have to be mentioned on tracfones site. I am in no way affiliated with the eBay seller or with tracfone, so I don't know how this deal can be priced so well or if it is even legit.
Click to expand...

I believe that eBay seller is the one I got my Valet from. The Valet was $129 with the one-year card... so not so much different. I'm not too suspicious.
 
mainefungi said:
You guys are more determined than I am. I finally broke down and got a Moto X.
Click to expand...

Don't blame you a bit...the Valet was nice to experiment with but NOT A REAL phone. I just ordered the Moto E just to get the refill card and so I could trash my ZTE. I want to keep my fingers in Android and TracFone but my real phone is an iPhone 6.

I bet you are thrilled with your Moto X!!!
 
bummpr said:
Don't blame you a bit...the Valet was nice to experiment with but NOT A REAL phone. I just ordered the Moto E just to get the refill card and so I could trash my ZTE. I want to keep my fingers in Android and TracFone but my real phone is an iPhone 6.

I bet you are thrilled with your Moto X!!!
Click to expand...

No offense, but I hope not everyone has given up on this REAL PHONE just yet:-) Its not the top of the line, but it gets everything done I need it to, as I am sure it does for those of us in the tracfone universe. I wish I could offer more than just words of encouragement and thanks to those that will get this thing rooted! All I really want is to be able to remove some of the bloat and make this phone perform that much better.
Thanks
 
Sorry I haven't posted in a while, but...

I can successfully root and flash the stock boot.img now. I was using the wrong unpacking tools before and that is why it failed. It will now work.

The only problem is that I have updated my device using the heartbleed update and the new boot.img is in a different format and cannot be successfully unpacked and repacked at this time.

If someone wants to try again with the rooted boot.img I have, then let's do it

I am 99% sure it will work now.


If for some crazy reason it does not work this time, all that has to be done is the update installed and the phone will be working again--only you will be updated to the new kernel and system.

I was using old (gingerbread/ics) unpacking tools originally that only work with .img files that do not contain 3.0 kernels. I also left a gedit temp file in the repacked boot.img way back when and that was another problem. these have since been remedied.

I used the new tools from the kitchen and successfully unpacked and repacked without errors.
 
stayboogy said:
Sorry I haven't posted in a while, but...

I can successfully root and flash the stock boot.img now. I was using the wrong unpacking tools before and that is why it failed. It will now work.

The only problem is that I have updated my device using the heartbleed update and the new boot.img is in a different format and cannot be successfully unpacked and repacked at this time.

If someone wants to try again with the rooted boot.img I have, then let's do it

I am 99% sure it will work now.


If for some crazy reason it does not work this time, all that has to be done is the update installed and the phone will be working again--only you will be updated to the new kernel and system.

I was using old (gingerbread/ics) unpacking tools originally that only work with .img files that do not contain 3.0 kernels. I also left a gedit temp file in the repacked boot.img way back when and that was another problem. these have since been remedied.

I used the new tools from the kitchen and successfully unpacked and repacked without errors.
Click to expand...
That's great news, unfortunately I've already done the heartbleed patch as well:-(
 
I'm willing to try also. I don't believe I have the heartbleed fix; is there a way to check?

Thanks for coming back stayboogy - I thought you were gone for good. Please provide files and instructions.
 
stayboogy said:
Sorry I haven't posted in a while, but...

I can successfully root and flash the stock boot.img now. I was using the wrong unpacking tools before and that is why it failed. It will now work.

The only problem is that I have updated my device using the heartbleed update and the new boot.img is in a different format and cannot be successfully unpacked and repacked at this time.

If someone wants to try again with the rooted boot.img I have, then let's do it

I am 99% sure it will work now.


If for some crazy reason it does not work this time, all that has to be done is the update installed and the phone will be working again--only you will be updated to the new kernel and system.

I was using old (gingerbread/ics) unpacking tools originally that only work with .img files that do not contain 3.0 kernels. I also left a gedit temp file in the repacked boot.img way back when and that was another problem. these have since been remedied.

I used the new tools from the kitchen and successfully unpacked and repacked without errors.
Click to expand...
stayboogy, while trying to learn what's going on with unpacking the update.zip boot.img and recovery.img as well as interpret what I see after doing so, tried several different tools and none would work. They all failed with an error referring to no android magic found. But I finally found one that appears to unpack both the boot.img and the recovery.img files in the update.zip package. I don't know if it will help you or not but if it will let me know and I'll post a link to the tools I found. I'm still trying to learn enough to interpret what I see.
 
Has anyone had any luck with stayboogy's root method? Hoping those of us that have done the heartbleed update won't be to far behind.
 
You must log in or register to reply here.
Back
Top Bottom