Jump to content
fluxcapacitor

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

Recommended Posts

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?

 

 

Share this post


Link to post
Share on other sites

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

 

  • Upvote 1

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

[email protected]_32:/

This is whats i get sys not locked stock 5.02 rooted

Edited by lunario

Share this post


Link to post
Share on other sites

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

Edited by lunario

Share this post


Link to post
Share on other sites

[email protected]_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 by kunft

Share this post


Link to post
Share on other sites
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

[email protected]_32:/

This is whats i get sys not locked stock 5.02 rooted

 

16 hours ago, kunft said:

[email protected]_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.

Share this post


Link to post
Share on other sites

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 by KonstaT

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 **** :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 by lunario

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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! 

"

Share this post


Link to post
Share on other sites
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 by c0d3x42
  • Upvote 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.