[Q] Write protection on mmcblk0p4 - One (M7) Q&A, Help & Troubleshooting

I am trying to edit partition /dev/mmcblk0p4 on HTC One, but even though dd command executes, partition keeps old info. On One X, similar method was used to put phone in temporary brick state that allowed access to hboot and other partitions that were protected using S-ON.
I am trying to do the same and M7 has similar partition layout as HOX, except that I could r/w to that partition as root, but on M7 its write protected. Can anyone help to disable write protection on that partition?
Thanks

Related

[FYI] Beware of eMMC data leakage.

It would appear that the N7 eMMC controller wear-leveling implementation does not enforce page/block erasure during wear leveling re-mapping.
Further, there is no reason to believe that partition boundaries are relevant to the block remapping.
The upshot of this is that pages (containing arbitrary data) that were once in /data can end up in slack space - for instance in the back end of the boot or recovery partitions. (The valid images written in there are megabytes shorter than the full partition sizes). So, don't give folks Nandroid backups - even if a factory reset has been performed prior to the nandroid creation time or the userdata backup removed. (The boot & recovery partitions are captured as full partition dumps, so you get valid images plus slack space)
I ran a simple test yesterday:
- record the boot partition using "dd"
- boot into bootloader and then "fastboot erase boot"
- boot into custom recovery and capture boot partition (again) using "dd"
- restore boot partition (fastboot or nandroid)
Then I examined the boot partition dumps (e.g. using "hexdump" or "strings"). In my case the "erased" boot partition contained (among other stuff) what looked like pathnames for lots of files stored in /data. Clearly that is the type of stuff that would never be found in the boot partition without block remapping. You can also find the same kind of thing going on in the USP partition - have a look if you are curious.
I suppose this has implications for folks "cleaning up" tablets for resale or return - bits of your data lives on in unexpected places...
cheers

[Q] Internal Memory FUBAR? ADB help

Hi all,
Tearing my hair out here (and I have SFA left anyway)
My Father-in-law's SGS i9000 seems to have real issues. Initially problem I was having was that there was an app I could not uninstall- it would reappear on reboot. I initially suspected malware or such, but it appears to be a real problem with the internal memory. I had MIUI installed on it, but wanted to change to a more stock ROM.
First time I really started to worry was when I found that every time I put a new rom onto the internal sdcard, it disappeared at reboot (and thus wasn't there to install when rebooted into CWM)
Since then, haven't had a functioning phone.
adb push to sdcard still not persistent on reboot.
Cannot flash new ROM with ODIN either, although KERNEL changes, filesystem no longer mounts.
I think the version of MIUI I was using used an ext4 lagfix, as inside an adb shell, I can see the partitions:
parted /dev/block/mmcblk0
a "print" lists two partitions:
Number Start End Size Type File system Flags
1 32.8kB 14.4GB 14.4GB primary fat32 lba
2 14.4GB 16.4GB 2013MB primary ext4 lba
rm 1, rm 2
to try to delete the partitions and start again- doesn't work. Nothing happens
If I load partition 2 into parted:
parted /dev/block/mmcblk0p2
print
Model: Unknown (unknown)
Disk /dev/block/mmcblk0p2: 2013MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Number Start End Size File system Flags
1 0.00B 2013MB 2013MB ext4
Can;t check any partitions as ext4 isn't supported by parted.
I cannot remove any partitions, reformat them or anything.
e2fsck errors as it cant read superblock flags on any of the partitions.
Any other ideas? Anyone?
I don't want to toss the phone out
http://forum.xda-developers.com/showthread.php?t=845708
i dont know if this will help u but u can try this guy instruction. See link above
compacity said:
http://forum.xda-developers.com/showthread.php?t=845708
i don't know if this will help u but u can try this guy instruction. See link above
Click to expand...
Click to collapse
If that worked, it would have been just what I was looking for
I googled the hell out of this problem, and that one never came up, but others I'd seen led me to try that same plan.
Where it fails on my device, is that deleting the partitions in "parted" fails- rm1 followed by rm 2 to delete the partitions. "Print" reveals they're still there.
Any other partition tools worth trying?
I got it back to square one:
Flashed kernel thru Odin with a version of CWM that worked.
reboot into recovery.
Flash update from SDcard- card contents still the same, so could re-flash MIUI.
reboot, bootloop. Re-enter CWM recovery and reflash.
Back to Square One - MIUI 1.12.16 (JVK)
Cannot install anything - nothing is persistent after reboot, even WIFI settings disappear
If it is any help to anyone who knows what they're talking about:
Now that MIUI boots I can look at the filesystem better.
Can anyone point me in the direction of what I should be looking for/trying to do to figure out what is wrong here?
try finding solution here, its PIT stop for i9000 problem
http://forum.xda-developers.com/showpost.php?p=30415128&postcount=1
Mine seems to be a bit tougher than these solutions can deal with.
Tried assorted ROMs over past day. No install works.
Cannot install anything from internal memory, as nothing dropped into that card will remain after a reboot.
Installing anything from an external card just throws up bootloops etc- as the only thing that seems to be able to retained between boots is the kernel/CWM.
If I install a new ROM, first flash says partition table is incompatible and /data will be overwritten (no problems, nothing on it). I accept the inevitable and re-select the ROM.
Reboot bootloops, as expected, reboot into CWM (now a new version with the Kernel), try reflashing the ROM image- Error 0 or 7. Try from External Memory- same. Try sideloading image. Same. All I can do is re-flash the MIUI image on internal SDcard (which works)
It looks like the internal memory refreshes itself from a recovery image at each boot? (I think).
Anyway- can't get anything to stick, except MIUI
edit:
http://forum.xda-developers.com/showthread.php?t=761537&page=3
http://forum.xda-developers.com/showthread.php?t=1230059&page=3
hav u try this 2 link as this is da only thread matches ur MBR problem
compacity said:
did u try any jb kernel out there? as its also ext4 n push it using adb. juz a suggestion though.
Click to expand...
Click to collapse
Good suggestion Logical
I'd thought that also- The JB kernels should support ext4.
No joy though
The version of CWM recovery that is stable with the MIUI install is 5.0.2.7, and it doesn't have any voodoo/lagfix options
When I flash a kernel with a CWM with lagfix, and try to use the CWM lagfix toggles, nothing changes.
Doesn't matter what I select inside CWM, it reads the status from memory as "Lagfix on, Debug off"
The reason I asked about ext4 tools in ADB is that running filesystem commands in a shell just throws up errors I can't seem to fix.
e2fsck just throws up superblock errors (on both /dev/block/mmcblk0 and the partition /dev/block/mmc0p2.
Defining one of the backup superblocks doesn't help- they're all bad.
"parted" doesn't work anymore (i note it isn't in /sbin, so I am picking this kernel doesn't install it), but even when I did have it, "parted" doesn't support ext4. Using "rm" to remove a partition did exactly nothing.
Starting to think the only way forward would possibly be flashing a custom .pit file to define partitions that move the data off an obviously bad block? Above my skill level however LOL
refresh browser see my post above again

[Q] How to mount encrypted storage with TWRP?

I'm using Android Revolution HD 30 and TWRP 2.6.3.0 (Flyhalf205 version). The phone is S-OFF.
I tried to encrypt the phone storage. It worked, but TWRP was not able to mount /data anymore. It should have asked me for the encryption password, but it didn't.
What are the commands to mount /data using and adb shell?
Regards
Same issue here. TWRP 2.6.3.0 asks for password on Nexus 7 (2012), doesn't ask or mount anything on my One. I'm on the latest stock GPE ROM, S-ON, custom kernel with /system protection off.
I feel uncomfortable knowing that if I lose my phone, anyone could very easily retrieve private content.
At least with stock recovery and locked bootloader, accessing private content requires motivation and work, since simply unlocking the bootloader to install a custom recovery would erase /data/ partition too.
With a custom recovery installed the risk is even worse, since reading personal data doesn't require any work.

[Q] partitions at the base of the phone

So just out of curiosity and for the sake of information, I need to ask one thing . Are the partitions present at the base of the phone namely /acct, /cache, /config, /d, /data, dev , / devlog, /etc, /firmware, /mnt, /proc, /ramdump, /root, /sbin, /storage, /sys, /system, /tombstone, and /vendor (present along with /sdcard and these partitions can be viewed using ES File Explorer) read or write protected? i know that /data and /firmware partitions are read protected on unrooted phones and /system is write protected. But what about the various other partitions that i mentioned? are they read or write protected as well? Any help to clear up the confusion will be appreciated.
PS: i know that these partitions are important so i'm not gonna mess with them but i asked this question just for information
muhammad.uzi1994 said:
So just out of curiosity and for the sake of information, I need to ask one thing . Are the partitions present at the base of the phone namely /acct, /cache, /config, /d, /data, dev , / devlog, /etc, /firmware, /mnt, /proc, /ramdump, /root, /sbin, /storage, /sys, /system, /tombstone, and /vendor (present along with /sdcard and these partitions can be viewed using ES File Explorer) read or write protected? i know that /data and /firmware partitions are read protected on unrooted phones and /system is write protected. But what about the various other partitions that i mentioned? are they read or write protected as well? Any help to clear up the confusion will be appreciated.
PS: i know that these partitions are important so i'm not gonna mess with them but i asked this question just for information
Click to expand...
Click to collapse
Well as far has I understand it. On a unrooted phone; you can write to the virtual SD card only. On a rooted phone you can still only write to the virtual SD card but you get root privileges to run apps that non rooted phones can't. . With S-Off you can write, delete from the phones system as well has the virtual SD card, hence the increased danger of permanently hard bricking your phone. Personally I think S-Off is worth the risk providing you THINK BEFORE YOU DO.... S-Off can save many a soft brick and a few almost hard bricks too; but more importantly, if you want to return to a factory shipped phone after rooting and installing a custom recovery/rom. You have to be S-Off.
Sent from my GT-I9505 using XDA Premium 4 mobile app
bored_stupid said:
Well as far has I understand it. On a unrooted phone; you can write to the virtual SD card only. On a rooted phone you can still only write to the virtual SD card but you get root privileges to run apps that non rooted phones can't. . With S-Off you can write, delete from the phones system as well has the virtual SD card, hence the increased danger of permanently hard bricking your phone. Personally I think S-Off is worth the risk providing you THINK BEFORE YOU DO.... S-Off can save many a soft brick and a few almost hard bricks too; but more importantly, if you want to return to a factory shipped phone after rooting and installing a custom recovery/rom. You have to be S-Off.
Sent from my GT-I9505 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I have s off but as far as I know, writing to /system requires root privileges AND a custom non protected kernel , I'm sure about the write protection status of /system , /data and /firmware on an unrooted phone but I'm not sure about the rest.
muhammad.uzi1994 said:
I have s off but as far as I know, writing to /system requires root privileges AND a custom non protected kernel , I'm sure about the write protection status of /system , /data and /firmware on an unrooted phone but I'm not sure about the rest.
Click to expand...
Click to collapse
Sorry should have written; " with S-Off and root you can write or delete from phone system ". That includes the entire system as far has I know. To be honest, I've never tried altering any of the phones system apart from deleting some system apps and altering CID to super CID.
Sent from my GT-I9505 using XDA Premium 4 mobile app
bored_stupid said:
Sorry should have written; " with S-Off and root you can write or delete from phone system ". That includes the entire system as far has I know. To be honest, I've never tried altering any of the phones system apart from deleting some system apps and altering CID to super CID.
Sent from my GT-I9505 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I'm s off and unrooted so basically it means I can write to virtual sd card ONLY, I can't modify any of the partitions mentioned in the OP?
If your S-Off and rooted; you can write to all your partitions, So be careful.
Sent from my GT-I9505 using XDA Premium 4 mobile app
Those you have named [/acct /system etc] are Directories/Folders and only a couple of Partitions [SDCard/User Data] which are part of your Android system.
The base as you said is actually /root directory of the system.
Just to make it a little clearer, S-OFF isn't required to be able to write to the /system directories if you are rooted.
S-OFF does however give you the capability to write to ANY and all Partitions on your phone, making it useful but highly dangerous if used incorrectly.
Bashing away at my HTC Desire C
There are a number of factors that control read and write access to the file system.
/data, /system, /cache are mount points, where partitions are attached to the root file system by the OS.
By default, /system is mounted as read only, but can be remounted as read write if you have root access. /data and /cache are mounted as read write.
Then there's the question of user permissions within the operating system. System processes can write to /data, but root access is needed for users to write to it in a file explorer, etc.
That's where su comes in. It's called 'root' because when you su you are switching roles from the restricted Android standard user to the more privileged root user, allowing you to execute commands like remounting file systems, copying partitions with dd, etc.
S-on and s-off have to do with performing block operations on partitions, such as in recovery.
With s-on you can read all partitions (assuming you have root access) and write to system, data, boot, cache, radio, and recovery partitions only.
With s-off you can write to every partition in recovery.
Hope that helps.
cschmitt said:
There are a number of factors that control read and write access to the file system.
/data, /system, /cache are mount points, where partitions are attached to the root file system by the OS.
By default, /system is mounted as read only, but can be remounted as read write if you have root access. /data and /cache are mounted as read write.
Then there's the question of user permissions within the operating system. System processes can write to /data, but root access is needed for users to write to it in a file explorer, etc.
That's where su comes in. It's called 'root' because when you su you are switching roles from the restricted Android standard user to the more privileged root user, allowing you to execute commands like remounting file systems, copying partitions with dd, etc.
S-on and s-off have to do with performing block operations on partitions, such as in recovery.
With s-on you can read all partitions (assuming you have root access) and write to system, data, boot, cache, radio, and recovery partitions only.
With s-off you can write to every partition in recovery.
Hope that helps.
Click to expand...
Click to collapse
Copy and pasting this for future reference. .
Sent from my GT-I9505 using XDA Premium 4 mobile app
cschmitt said:
There are a number of factors that control read and write access to the file system.
/data, /system, /cache are mount points, where partitions are attached to the root file system by the OS.
By default, /system is mounted as read only, but can be remounted as read write if you have root access. /data and /cache are mounted as read write.
Then there's the question of user permissions within the operating system. System processes can write to /data, but root access is needed for users to write to it in a file explorer, etc.
That's where su comes in. It's called 'root' because when you su you are switching roles from the restricted Android standard user to the more privileged root user, allowing you to execute commands like remounting file systems, copying partitions with dd, etc.
S-on and s-off have to do with performing block operations on partitions, such as in recovery.
With s-on you can read all partitions (assuming you have root access) and write to system, data, boot, cache, radio, and recovery partitions only.
With s-off you can write to every partition in recovery.
Hope that helps.
Click to expand...
Click to collapse
thanks a lot, but what about the folders like /d , and /dev , do they have restricted user permissions or read/write protection as well?
muhammad.uzi1994 said:
thanks a lot, but what about the folders like /d , and /dev , do they have restricted user permissions or read/write protection as well?
Click to expand...
Click to collapse
They all have standard unix file system permissions. There are many good tutorials, like this one.
cschmitt said:
They all have standard unix file system permissions. There are many good tutorials, like this one.
Click to expand...
Click to collapse
i read the link you provided twice but couldnt comprehend, i'm gonna leave it at that, i was just asking for information purposes, Since i dont understand it, i'll leave it at that
cschmitt said:
They all have standard unix file system permissions. There are many good tutorials, like this one.
Click to expand...
Click to collapse
i did some digging/googling and found out that /dev contains system devices info and is write protected as well on unrooted phones http://stackoverflow.com/questions/14277639/android-permission-denied-for-dev-directory thanks a lot for helping out @cschmitt

Resizing Data and System Partitions?

Assuming that I debloated the rom that I want, and have some extra space I want to transfer from the system partition to the data partition; how would one go about resizing the partitions of this device? I know it is possible on some other phones, but I was wondering if this process is similar with this one, if there is a type of universal process or if it must be done specific to this phone with a specific script or command sequence via ADB?
davidw.roggenkamp said:
Assuming that I debloated the rom that I want, and have some extra space I want to transfer from the system partition to the data partition; how would one go about resizing the partitions of this device? I know it is possible on some other phones, but I was wondering if this process is similar with this one, if there is a type of universal process or if it must be done specific to this phone with a specific script or command sequence via ADB?
Click to expand...
Click to collapse
If you're hoping to resize the partitions such as System mmcblk0p43 or any other mmcblk's it's not possible on this device you'll break it and besides, you can't even try to resize it while you're s-on!

Categories

Resources