We need a fix for the /system write protected phones. Can anyone help!

[Guest fluxcapacitor]

For some reason, some, but not all of us with a SU6 have the problem where /system is still readonly despite being rooted. 

Any changes made, look like they are kept but once you remount readonly or reboot, it reverts to the previous state.

There doesn't seem to be any talk of a fix so i thought i'd made a thread to see if we can sort something out!

For another phone with a similar problem (HTC)  it seems the fix was to edit the kernel source to stop a MMC Write Protect command from starting.
I looked in the kernel source but couldn't find a similar reference.

Does anyone have any insight into this problem?

 

 

[Guest fluxcapacitor]

I found this which relates to the ZTE MAX

 

Quote

This is how ZTE implements this system write protection.

When the phone is turned and when the boot loader is loading (this is before the boot kernel). There is code executed that reads the Extended CSD of the mmc card (ext_csd)
https://android.googlesource.com/ker...m_shared/mmc.c
Line 2567

I am not sure if we can mod the ext_csd or not, I have tried and failed, and there is a lot of info in that csd, but it also has information on any sectors that are to be write protected, this is determined by some params like wp_grp_size and such. Now if the boot loader boots you into regular Android (boot from the "boot" partition" it temporarily write protects those sectors and they can not be changed. If however the boot loader boots you into recovery, the boot loader does not do this.


Now there is code in the kernel zImage that denies permission to mounting or remounting /system as r/w. This is why people get permission denied, when they try to remount /system, same thing it is not called if you booted into recovery

Since we have the source code to the kernel, you can bypass or removed this code if you want and you will not get the permission denied error anymore when you try to re-mount system, and it will look like you have R/W to the /system partition, and you can delete a file and it will disapear, but as soon as you reboot the phone any changes you made will be gone, because you were only modding the buffer, I have it this way in my CM12.1 I think

https://github.com/hroark13/android_...c/card/block.c

if you look at line 271 and3239

they both says #if 0, it use to say #if 1, but I changed it to bypass the code, I am not sure why I did this, I dont know if we can use it anyway or not

Anyway to get back to my point, unpacking the boot.img, and changing some lines in the init rc files is not gonna get you system r/w

what you want is a bootloader unlock or a way to mod the ext_csd

And consider yourself lucky because ZTE implements this write protection on more than one partition on other phones, like the ZTE Whirl 2 is write protected, on /system boot recovery, basically everything but data and cache, so they can not even flash a custom recovery to get r/w access, or flash boot to recovery to get Android booted with /system r/w

If you dont believe me maybe @jcase can verify it, he should know all this

 

[Guest nhmanas]

I found this which relates to the ZTE MAX

 

Quote This is how ZTE implements this system write protection.

When the phone is turned and when the boot loader is loading (this is before the boot kernel). There is code executed that reads the Extended CSD of the mmc card (ext_csd)
https://android.googlesource.com/ker...m_shared/mmc.c
Line 2567

I am not sure if we can mod the ext_csd or not, I have tried and failed, and there is a lot of info in that csd, but it also has information on any sectors that are to be write protected, this is determined by some params like wp_grp_size and such. Now if the boot loader boots you into regular Android (boot from the "boot" partition" it temporarily write protects those sectors and they can not be changed. If however the boot loader boots you into recovery, the boot loader does not do this.


Now there is code in the kernel zImage that denies permission to mounting or remounting /system as r/w. This is why people get permission denied, when they try to remount /system, same thing it is not called if you booted into recovery

Since we have the source code to the kernel, you can bypass or removed this code if you want and you will not get the permission denied error anymore when you try to re-mount system, and it will look like you have R/W to the /system partition, and you can delete a file and it will disapear, but as soon as you reboot the phone any changes you made will be gone, because you were only modding the buffer, I have it this way in my CM12.1 I think

https://github.com/hroark13/android_...c/card/block.c

if you look at line 271 and3239

they both says #if 0, it use to say #if 1, but I changed it to bypass the code, I am not sure why I did this, I dont know if we can use it anyway or not

Anyway to get back to my point, unpacking the boot.img, and changing some lines in the init rc files is not gonna get you system r/w

what you want is a bootloader unlock or a way to mod the ext_csd

And consider yourself lucky because ZTE implements this write protection on more than one partition on other phones, like the ZTE Whirl 2 is write protected, on /system boot recovery, basically everything but data and cache, so they can not even flash a custom recovery to get r/w access, or flash boot to recovery to get Android booted with /system r/w

If you dont believe me maybe @jcase can verify it, he should know all this

 

I'm not a native speaker so I can't understand whole article.

Do you or article's writer think that this is caused by rom?

[Guest KonstaT]

I highly doubt there's anything anyone will be able to do about this. You'd need ZTE to provide tools/update to remove the write protection. Ask them the to 'unlock' the bootloader while at it. ;)

LK (little kernel) bootloader is included in stock firmware packages (emmc_appsboot.mbn) so it's the same on both type of devices. Write protection is implemented somewhere even 'lower' in the boot chain or maybe LK reads some magic value from some other partition (or NV memory) where this is toggled. Someone who has both type of devices could dump some partitions (and/or backup NV memory with QPST) to poke around. There's at least few 'non-standard' partitions that I haven't seen on Qualcomm devices in general (config -> /dev/block/mmcblk0p27, devinfo -> /dev/block/mmcblk0p30, ztecfg -> /dev/block/mmcblk0p10).

Without a doubt there's at least two variants/generations of this device. It's also said that these two versions likely have different display panels. Already posted a long time ago an easy way to figure this out ('cat /proc/cmdline') and I've received exactly zero resposes. No one seems to care so good luck in getting any info that could help...

[Guest lunario]

boot_cpus=0 androidboot.earlyboot_cpus=2,4,6 sched_enable_hmp=1 console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.selinux=permissive androidboot.hardware=qcom user_debug=30 msm_rtb.filter=0x3F ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1 androidboot.emmc=true androidboot.serialno=**** androidboot.baseband=msm mdss_mdp.panel=1:dsi:0:qcom,mdss_dsi_nt35596_lead_otp_1080p_video:1:none androidboot.mode=normal loglevel=4 serial_status=0

root@msm8916_32:/

This is whats i get sys not locked stock 5.02 rooted

Edited December 5, 2015 by lunario

[Guest lunario]

so only need someone that can post with those nasty ones that have root through TWRP

Edited December 5, 2015 by lunario

[Guest kunft]

root@msm8916_32:/ # cat /proc/cmdline

boot_cpus=0 androidboot.earlyboot_cpus=2,4,6 sched_enable_hmp=1 console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.selinux=permissive androidboot.hardware=qcom user_debug=30 msm_rtb.filter=0x3F ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1 androidboot.emmc=true androidboot.serialno=*** androidboot.baseband=msm mdss_mdp.panel=1:dsi:0:qcom,mdss_dsi_nt35596_lead_otp_1080p_video:1:none androidboot.mode=normal loglevel=4 serial_status=0

 

mine is system protected

Edited December 5, 2015 by kunft

[Guest lunario]

don't see any difference at least not with my eyes :\  maybe konstat will see something

[Guest macbreakweeklyfan]

Next time run a "diff" on them; that's what I'm doing right now, and will post results if found.

[Guest BlueMoonRising]

16 hours ago, lunario said:

boot_cpus=0 androidboot.earlyboot_cpus=2,4,6 sched_enable_hmp=1 console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.selinux=permissive androidboot.hardware=qcom user_debug=30 msm_rtb.filter=0x3F ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1 androidboot.emmc=true androidboot.serialno=**** androidboot.baseband=msm mdss_mdp.panel=1:dsi:0:qcom,mdss_dsi_nt35596_lead_otp_1080p_video:1:none androidboot.mode=normal loglevel=4 serial_status=0

root@msm8916_32:/

This is whats i get sys not locked stock 5.02 rooted

 

16 hours ago, kunft said:

root@msm8916_32:/ # cat /proc/cmdline

boot_cpus=0 androidboot.earlyboot_cpus=2,4,6 sched_enable_hmp=1 console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.selinux=permissive androidboot.hardware=qcom user_debug=30 msm_rtb.filter=0x3F ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1 androidboot.emmc=true androidboot.serialno=*** androidboot.baseband=msm mdss_mdp.panel=1:dsi:0:qcom,mdss_dsi_nt35596_lead_otp_1080p_video:1:none androidboot.mode=normal loglevel=4 serial_status=0

 

mine is system protected

No difference whatsoever there, so it's done somewhere else.

[Guest KonstaT]

Well, both of those devices have the same display panel (mdss_dsi_nt35596_lead_otp_1080p_video). Would be still interesting get that from a device that has allegedly different color saturation in the display.

As for the write protection, I guess there's no way to differentiate these devices but to try.

Edited December 6, 2015 by KonstaT

[Guest cashflow67]

There must be a way! Manufacturers don't allow to root normally. They avoid their warranties if we root phones, this is not a problem for them!. But what a logic is not to allow root and make a system write protection! This is really rubbish!! ZTE should look into this problem and user desire!! I can't remove bloatware, I can't edit build prop etc. Please and Please someone help the system ptotected users about this problem!

[Guest lunario]

Talk to ZTE you can do that through the website. Bloatware only messenger +and Vodafone update cant be removed

[Guest cashflow67]

4 hours ago, lunario said:

Talk to  you can do that through the website. Bloatware only messenger +and Vodafone update cant be removed

Google apps cant be removed too. Ggole News, games drive photos etc.

[Guest lunario]

You are right forgot about those

[Guest jaysnotcool]

The difference between the two readouts appears to be:

androidboot.serialno=*** system protected

androidboot.serialno=**** not locked

[Guest lunario]

11 minutes ago, jaysnotcool said:

The difference between the two readouts appears to be:

androidboot.serialno=*** system protected

androidboot.serialno=**** not locked

naa its the same I just replaced the serial number with **** :)

[Guest BlueMoonRising]

29 minutes ago, lunario said:

naa its the same I just replaced the serial number with **** :)

I think he was joking.

 

 

 

I hope he was anyway.

[Guest cRaZyzMaN]

the ones having this issue are the ones having issues to root
im one of those

[Guest lunario]

ppl who have the system write protection on why don't you guys ask zte directly why is that ? http://www.ztedevice.com/support/ choose you phone then on help and troubleshooting choose please tell us of your trouble maybe if many will ask they can solve the problem

Edited December 8, 2015 by lunario

[Guest Unable]

32 minutes ago, lunario said:

ppl who have the system write protection on why don't you guys ask zte directly why is that ? http://www.ztedevice.com/support/ choose you phone then on help and troubleshooting choose please tell us of your trouble maybe if many will ask they can solve the problem

Done. Let's hope they reply

[Guest lunario]

Good hope more of you guys do the same

[Guest Unable]

8 hours ago, lunario said:

Good hope more of you guys do the same

"

Dear Valued ZTE Customer,

Thanks for contacting ZTE.

Please do remember if you root the device, the internal system will be destroyed and the device will not be stable

And you will loose manufacture warranty

Should there be further assistance, please do not hesitate to contact us.

We shall always be glad of service.

Best Regards! 

"

[Guest lunario]

Diplomatic answer

[Guest c0d3x42]

On 12/8/2015 at 9:56 PM, lunario said:

ppl who have the system write protection on why don't you guys ask zte directly why is that ? http://www.ztedevice.com/support/ choose you phone then on help and troubleshooting choose please tell us of your trouble maybe if many will ask they can solve the problem

Asked them about unlocking bootloader. Lets see if the following yields anything useful

 

 Hello,
I have a Vodafone Smart Ultra 6. I would like to unlock the bootloader so that i can develop a custom ROM with CyanogenMod 12.1 / 13.  An unlocked bootloader would make this process much easier. I fully understand this will invalidate my warranty and i fully accept responsibilities for this.

Could you please tell me how to unlock the bootloader?
Cheers and best wishes,

 

Edited December 15, 2015 by c0d3x42