I've created this thread in an attempt to document which actions remove write protections on which partitions.
I'm sure there are individuals who know the information, but I haven't seen in documented anywhere.
Here is what I believe is confirmed so far:
Unlocking the bootloader removes write protections on system, boot and recovery.
Getting S-OFF removes write protections on recovery (and other partitions which haven't been specifically identified).
Changing the one byte as per this thread removes write protections on p6 (and other partitions which haven't been specifically identified).
The combination of all the above removes write protections on all partitions as per this post.
What I would like to do is compile a list of partitions that have write protections removed by taking various actions.
Hopefully we can fully document this.
Below is the relevant discussion from a separate thread, which I have moved into the current thread.
efrant said:
@scotty1223 any comments on my question below? Thanks.
Click to expand...
Click to collapse
No, no comments.
Most folks do it for the ease of changing the tamper flag, but you can also do that with an RUU.
Sent from my HTC One using Tapatalk
@scotty1223 any comments on my question below? Thanks.
efrant said:
Aside from preventing the change of the tamper flag, what else is "write-protected" after S-OFF? In other words, once someone has S-OFF, what does executing "echo -ne '\x04' | dd of=/dev/block/mmcblk0p32 bs=1 seek=4126" allow you to do (that you that you otherwise would not be able to do)?
Click to expand...
Click to collapse
scotty1223 said:
No, no comments.
Most folks do it for the ease of changing the tamper flag, but you can also do that with an RUU.
Sent from my HTC One using Tapatalk
Click to expand...
Click to collapse
So we don't know what other write-protections are removed (aside from the tamper flag) by changing that byte?
efrant said:
So we don't know what other write-protections are removed (aside from the tamper flag) by changing that byte?
Click to expand...
Click to collapse
That is not what I said
Sent from my HTC One using Tapatalk
scotty1223 said:
That is not what I said
Sent from my HTC One using Tapatalk
Click to expand...
Click to collapse
You're being awfully cryptic! What write-protections are removed (i.e., what can you do that you otherwise couldn't)?
efrant said:
You're being awfully cryptic! What write-protections are removed (i.e., what can you do that you otherwise couldn't)?
Click to expand...
Click to collapse
As stated in the original post, all write protections are removed. You can do whatever you want. I am not sure exactly what you're fishing for. Just keep in mind, that just because you can write anything anywhere, does not mean that you should. Not all things are without consequence.
Sent from my HTC One using Tapatalk
scotty1223 said:
As stated in the original post, all write protections are removed. You can do whatever you want. I am not sure exactly what you're fishing for. Just keep in mind, that just because you can write anything anywhere, does not mean that you should. Not all things are without consequence.
Sent from my HTC One using Tapatalk
Click to expand...
Click to collapse
I'm just trying to figure out what protections are still in place when one gets S-OFF. I understand that by changing that one byte it removes all write protections, but it doesn't tell me what protections are in place not changing that byte (i.e., by only having S-OFF).
EDIT: Essentially I'm trying to determine what the "remaining" is in your thread title...
efrant said:
I'm just trying to figure out what protections are still in place when one gets S-OFF. I understand that by changing that one byte it removes all write protections, but it doesn't tell me what protections are in place not changing that byte (i.e., by only having S-OFF).
EDIT: Essentially I'm trying to determine what the "remaining" is in your thread title...
Click to expand...
Click to collapse
The remaining is the misc partition. Your setting a flag on the misc partition to allow writing to the pg2fs partition.
cmlusco said:
The remaining is the misc partition.
Click to expand...
Click to collapse
Thank you. So, if I understand correctly:
1) getting S-OFF eliminates the write protection on everything except system, boot and misc;
2) unlocking the bootloader eliminates the write protection on system and boot; and
3) making the change in this thread elimiates the write protection on misc.
Is that correct?
efrant said:
I'm just trying to figure out what protections are still in place when one gets S-OFF. I understand that by changing that one byte it removes all write protections, but it doesn't tell me what protections are in place not changing that byte (i.e., by only having S-OFF).
EDIT: Essentially I'm trying to determine what the "remaining" is in your thread title...
Click to expand...
Click to collapse
few people can answer that, or what HTC's security checks are all about (or why),
but if you remember the older days of the M7, when s-off was first achieved using revone and/or moonshine, i recall revone being able to go from s-off to s-on using a simple revone command, which was quickly removed, because if something was modded in there -> InstaBrick
using the "normal" fastboot oem writesec.... would trigger a security/signature check and not allow modded stuff (at the time, I guess only hboot, was checked)
from here:
* Safety update: No longer allows -s 3 since this can lead to bricks with custom HBOOTs, use: fastboot oem writesecureflag 3 (which is safer - and checks such things)
Click to expand...
Click to collapse
(I don't keep bookmarks of those, but here's an example: http://forum.xda-developers.com/htc-one/help/s-t2801146 or http://forum.xda-developers.com/htc-one/help/set-phone-to-s-t2822021)
and there were quite a few others,
"I'm 100% sure I put my phone back to 100% stock, so don't tell me ........"
Click to expand...
Click to collapse
but still, trying to go S-ON, would "luckily" trigger
Code:
...
(bootloader) partition hboot signature error
(bootloader) writesecureflag: partitions siganture failed
OKAY [ 1.048s]
You could still manually change the flag, and have an InstaBrickTM
I can only assume, that those signature checks have been extended to more partitions, so "messing with them", could cause a signature check, and if that fails, then you could be in deep trouble
---------- Post added at 22:04 ---------- Previous post was at 22:02 ----------
cmlusco said:
The remaining is the misc partition. Your setting a flag on the misc partition to allow writing to the pg2fs partition.
Click to expand...
Click to collapse
since when was/is misc a "privileged/sensitive" partition?
efrant said:
Thank you. So, if I understand correctly:
1) getting S-OFF eliminates the write protection on everything except system, boot and misc;
2) unlocking the bootloader eliminates the write protection on system and boot; and
3) making the change in this thread elimiates the write protection on misc.
Is that correct?
Click to expand...
Click to collapse
No,it is not correct.
Doing the mod in this thread eliminates the Wp on p6 (making it easier to change your tampered flag. As I've stated)
Sent from my HTC One using Tapatalk
nkk71 said:
since when was/is misc a "privileged/sensitive" partition?
Click to expand...
Click to collapse
It's not. If it was,the mod in this thread wouldn't work
Sent from my HTC One using Tapatalk
efrant said:
EDIT: Essentially I'm trying to determine what the "remaining" is in your thread title...
Click to expand...
Click to collapse
"Remaining" is the write protections that are still in place even after s off(such as those protecting p6)
Sent from my HTC One using Tapatalk
scotty1223 said:
It's not. If it was,the mod in this thread wouldn't work
Sent from my HTC One using Tapatalk
Click to expand...
Click to collapse
it was a rhetorical question
and not really directed towards this thread and definitely not you
I've had more than enough dealings with misc (s-on or s-off), and the bcb
nkk71 said:
it was a rhetorical question
Click to expand...
Click to collapse
I figured as much,lol. Just thot it still needed clarified for others reading thru
Sent from my HTC One using Tapatalk
scotty1223 said:
"Remaining" is the write protections that are still in place even after s off(such as those protecting p6)
Click to expand...
Click to collapse
"Remaining" obviously means what's still in place. You've told us which write protections are still in place after flipping the byte (i.e., nothing), but no where that I've seen (in this thread or anywhere else) is mentioned what protections are in place before flipping the byte, other than p6.
What partitions have write-protections removed when someone goes from S-ON to S-OFF? (For example, S-OFF removes write protection on recovery, irrespective of the lock-state of the booloader. What other partitions?)
What partitions have write-protections removed when someone unlocks the bootloader? (My understanding is that it removes write protection on system, boot and recovery. What other partitions?)
What partitions have write-protections removed when we flip the byte mentioned in this thread? (Based on your findings, it removes write protection on p6. What other partitions?)
I'm interested in this not because I want to make any changes -- I am interested out of curiosity, and so that we have this information posted for reference here on XDA.
Let me know if you don't want this discussion in your thread, and I will move it out to a new thread. Thanks!
efrant said:
"Remaining" obviously means what's still in place. You've told us which write protections are still in place after flipping the byte (i.e., nothing), but no where that I've seen (in this thread or anywhere else) is mentioned what protections are in place before flipping the byte, other than p6.
What partitions have write-protections removed when someone goes from S-ON to S-OFF? (For example, S-OFF removes write protection on recovery, irrespective of the lock-state of the booloader. What other partitions?)
What partitions have write-protections removed when someone unlocks the bootloader? (My understanding is that it removes write protection on system, boot and recovery. What other partitions?)
What partitions have write-protections removed when we flip the byte mentioned in this thread? (Based on your findings, it removes write protection on p6. What other partitions?)
I'm interested in this not because I want to make any changes -- I am interested out of curiosity, and so that we have this information posted for reference here on XDA.
Let me know if you don't want this discussion in your thread, and I will move it out to a new thread. Thanks!
Click to expand...
Click to collapse
I am also curious about this. Sometimes you just want to know exactly how something works, not just that it works. That is how we grow here on XDA and in the world.
Maybe if @scotty1223 doesn't want to discuss it more thoroughly a new thread on this should be started, but since he's the one that came out with this he should be the one to decide.
Using XDA to unleash the power of Android on my HTC One M9 & S6 Edge Plus
efrant said:
You've told us which write protections are still in place after flipping the byte (i.e., nothing), but no where that I've seen (in this thread or anywhere else) is mentioned what protections are in place before flipping the byte, other than p6.
Click to expand...
Click to collapse
nothing?
and p6, may not in fact be p6 (at least on this device)
jbfountain said:
I am also curious about this. Sometimes you just want to know exactly how something works, not just that it works. That is how we grow here on XDA and in the world.
Maybe if @scotty1223 doesn't want to discuss it more thoroughly a new thread on this should be started, but since he's the one that came out with this he should be the one to decide.
Using XDA to unleash the power of Android on my HTC One M9 & S6 Edge Plus
Click to expand...
Click to collapse
Yes,there should be a new thread. I'm happy to discuss,but This is not the place.
Sent from my HTC One using Tapatalk
Related
I'm no expert when it comes to the topics of rooting and getting access to the emmc and all of that good stuff. I more specialize in ROMs and themes and stuff, the less complexed stuff lol
Someone has posted an idea in the general forums in relation to permanent root, I'm not sure if he posted it here or not. So here's what he wrote....and is it possible? Or does it have to be done manually first before this idea can happen?
Originally Posted by deliberate187
In order to unlock the phone, we have to figure out what the protected sectors are first and all related flags. If an Android app could be made to have direct read access to the eMMC filesystems (including write protect flags) and save a log to the SD card detailing these items, this would be ideal.
Then all that would remain is a program to undo the write protection (and re-do it if necessary to unvoid warranty)
If anyone is willing to create these programs, I would be more than happy to test them out on my own G2.
However, I think the keys to the mystery may lie in the recovery image, and/or in the bootloader itself. Has anyone disassembled these yet?
Click to expand...
Click to collapse
Sorry to have to tell you but this is all old information stuff we already know just are unable to do anything about it. Its harder then just coming up with an idea of something. Now if we knew a person that programed the g2 in htc factory then all would be good but as of now we just dont have the information we need to do anything
thanks
Thanks for the idea. Some people will be mad you didn't post in the root thread though.
File under "I'm no expert but..."
Here is one observation I have noted in my exploration. The root filesystem and system partition are mounted with the flags "-o ro,relatime" but in addition the /system partition has ",errors=continue" leading me to believe that this change is in fact written to the release configuration rather than to the eMMC itself. Can anyone try to get a permanent write to the fstab and see if this can net us permanent root? Possibly take a temp root session and remount the system and / filesystems read/write to see if writes stick... just an idea.
The errors=continue flag allows the ext3 filesystem to continue working even if there was a read/write error.
I've been able to get the system to change to r/w a couple times while wandering through root explorer. I have made subtle changes to certain folders such as moving txt files but nothing has ever been permanent. I can't really tell you how I did it either seeing as I can't replicate it on demand...I'm assuming it still gets written to cache despite being in the /system
Sent from my T-Mobile G2 using XDA App
heyy, I'm not punchie, I've got what the doctor calls a relaxed brain
I am thinking there should be a set of adb commands to unlock the nand. I am definitely thinking a nand dump and full disassembly of the bootloader and recovery image could be absolutely crucial in discovering what needs to be done. Just a thought, has anyone done a nandroid backup of the G2 yet? I'm pretty sure TMob doesn't have HTC encrypt its bootloaders...
deliberate187 said:
I am thinking there should be a set of adb commands to unlock the nand. I am definitely thinking a nand dump and full disassembly of the bootloader and recovery image could be absolutely crucial in discovering what needs to be done. Just a thought, has anyone done a nandroid backup of the G2 yet? I'm pretty sure TMob doesn't have HTC encrypt its bootloaders...
Click to expand...
Click to collapse
if you can figure it out, go for it and i wish you luck
deliberate187 said:
Here is one observation I have noted in my exploration. The root filesystem and system partition are mounted with the flags "-o ro,relatime" but in addition the /system partition has ",errors=continue" leading me to believe that this change is in fact written to the release configuration rather than to the eMMC itself. Can anyone try to get a permanent write to the fstab and see if this can net us permanent root? Possibly take a temp root session and remount the system and / filesystems read/write to see if writes stick... just an idea.
The errors=continue flag allows the ext3 filesystem to continue working even if there was a read/write error.
Click to expand...
Click to collapse
If it were only this easy.
Re-mounting /system as r/w is part of the rooting process. This does not result in changes written to eMMC. In fact, the controller "lies" to Linux that the change has been synced. From then on, Linux holds the changes in its cache which, when dropped or rebooted, reverts changed files to their original state (because they were never written in the first place.)
The ext3 continue on errors thing is merely a way to skip fsck in the event that the read-only system has issues in the journal (very unlikely to happen, since nothing can write to it.) Presumably, this only covers an oversight in OTA updates (where the journal of the image provided by the OEM is dirty for some odd reason.) Again, since nothing can write to /system, it's all but an impossible scenario (nothing can write to the journal either...)
As for marking "sectors" as write-protected or not, that's also easier said than done. Entire partitions are locked, and half of the space is mysteriously "missing." It's difficult to see what's really going on from userland, as the device is deceptive as to what is and is not being written, or what is even stored on the eMMC in the first place.
The real solution is to exploit either the boot-loader or eMMC (re)/initialization somehow to allow a) unsigned firmware to be loaded and/or b) allow booting without write protection, allowing us to c) flash rooted rom to the phone and/or d) disable said protection. The unlock procedure will likely be similar to Unrevoked, as that is essentially the same situation (aside from the controller issue.)
All of this is covered in the wiki and various threads - check those out, if you find a way around it everyone would be glad to hear it.
HamNCheese said:
If it were only this easy.
Re-mounting /system as r/w is part of the rooting process. This does not result in changes written to eMMC. In fact, the controller "lies" to Linux that the change has been synced. From then on, Linux holds the changes in its cache which, when dropped or rebooted, reverts changed files to their original state (because they were never written in the first place.)
The ext3 continue on errors thing is merely a way to skip fsck in the event that the read-only system has issues in the journal (very unlikely to happen, since nothing can write to it.) Presumably, this only covers an oversight in OTA updates (where the journal of the image provided by the OEM is dirty for some odd reason.) Again, since nothing can write to /system, it's all but an impossible scenario (nothing can write to the journal either...)
As for marking "sectors" as write-protected or not, that's also easier said than done. Entire partitions are locked, and half of the space is mysteriously "missing." It's difficult to see what's really going on from userland, as the device is deceptive as to what is and is not being written, or what is even stored on the eMMC in the first place.
The real solution is to exploit either the boot-loader or eMMC (re)/initialization somehow to allow a) unsigned firmware to be loaded and/or b) allow booting without write protection, allowing us to c) flash rooted rom to the phone and/or d) disable said protection. The unlock procedure will likely be similar to Unrevoked, as that is essentially the same situation (aside from the controller issue.)
All of this is covered in the wiki and various threads - check those out, if you find a way around it everyone would be glad to hear it.
Click to expand...
Click to collapse
Listen to this dude. Absolutely correct.
So, I've been following this thread recently and I need to ask a very basic question about some bootloader basics.
Someone referenced a post that explained the difference between locked and encrypted bootloaders but I cannot seem to find it.
From what I understand, in the simplest of terms, locked is good news and encrypted is bad news. In other words, a locked bootloader will enable us to eventually install custom ROMs from a different kernel not currently supported by the latest OTA update. Whereas with an encrypted bootloader, it is pretty much impossible to install ROMs from a different kernel and are limited to installing from the same kernel.
I'm not sure if some (if any) of the above is right.
So, I go back to check on that thread today and I notice the OP has been updated to say that the bootloader is signed is the same as either locked or encrypted? Or is it a completely different term?
I really home it's the same as a locked bootloader, but I have no idea.
If anyone has a good link describing this, or feels like explaining it themselves, it would be appreciated.
Thanks!
First of all, thanks for asking this question in General, instead of the Development section.
Encrypted means that the data payload is encrypted and cannot be decrypted without a valid private key. These days private keys are virtually impossible to decrypt in any reasonable amount of time, even with thousands of machines helping out. So there are generally two other attack vectors for this scenario:
1) someone leaks the private key, or
2) There is a weakness or flaw in the encryption algorithm that allows us to bypass the need for the private key.
Signed produces a digital signature that is computed from the contents of the payload. If one modifies the payload, the generated digital signature would no longer match and verification would fail. It's very similar to when you see md5/sha checksums for a file download.
This is a very layman's explanation of what's going on and subject to pedantic corrections . For further discussion, check out the following links:
http://en.wikipedia.org/wiki/Public-key_cryptography (Especially the section: http://en.wikipedia.org/wiki/Public-key_cryptography#Description)
http://en.wikipedia.org/wiki/Digital_signature
Hope that helps
perdurabo2 said:
First of all, thanks for asking this question in General, instead of the Development section.
Encrypted means that the data payload is encrypted and cannot be decrypted without a valid private key. These days private keys are virtually impossible to decrypt in any reasonable amount of time, even with thousands of machines helping out. So there are generally two other attack vectors for this scenario:
1) someone leaks the private key, or
2) There is a weakness or flaw in the encryption algorithm that allows us to bypass the need for the private key.
Signed produces a digital signature that is computed from the contents of the payload. If one modifies the payload, the generated digital signature would no longer match and verification would fail. It's very similar to when you see md5/sha checksums for a file download.
This is a very layman's explanation of what's going on and subject to pedantic corrections . For further discussion, check out the following links:
http://en.wikipedia.org/wiki/Public-key_cryptography (Especially the section: http://en.wikipedia.org/wiki/Public-key_cryptography#Description)
http://en.wikipedia.org/wiki/Digital_signature
Hope that helps
Click to expand...
Click to collapse
Thanks for the reply!
So, is signed better news than encrypted? Sorry for my confusion but I'm not the best with understanding this kind of stuff.
But in the mean time, I'll be checking those wikipedia articles.
qcom100 said:
Thanks for the reply!
So, is signed better news than encrypted? Sorry for my confusion but I'm not the best with understanding this kind of stuff.
But in the mean time, I'll be checking those wikipedia articles.
Click to expand...
Click to collapse
For the most part, it's better news because the payload can be examined for exploits.
PKI (public/private key crypto) is a good thing to have an understanding of because it's use is so widespread in the computing world.
perdurabo2 said:
First of all, thanks for asking this question in General, instead of the Development section.
Encrypted means that the data payload is encrypted and cannot be decrypted without a valid private key. These days private keys are virtually impossible to decrypt in any reasonable amount of time, even with thousands of machines helping out. So there are generally two other attack vectors for this scenario:
1) someone leaks the private key, or
2) There is a weakness or flaw in the encryption algorithm that allows us to bypass the need for the private key.
Signed produces a digital signature that is computed from the contents of the payload. If one modifies the payload, the generated digital signature would no longer match and verification would fail. It's very similar to when you see md5/sha checksums for a file download.
This is a very layman's explanation of what's going on and subject to pedantic corrections . For further discussion, check out the following links:
http://en.wikipedia.org/wiki/Public-key_cryptography (Especially the section: http://en.wikipedia.org/wiki/Public-key_cryptography#Description)
http://en.wikipedia.org/wiki/Digital_signature
Hope that helps
Click to expand...
Click to collapse
OK, thanks!
In case that someone missed it
(tnx to user garwynn)
Fresh off the press...
Q: Do you know the commands to reset the eMMC controller in question?
Originally Posted by Ken Sumrall (Android)
Once the chip has locked up, no command will reset it. It must be power cycled. If instead you are asking how to clear the metadata so the chip works again, the only solution I know is to update the firmware inside the chip, and that also wipes all the data. This probably includes factory calibration data that must be saved before the firmware is updated, and restored after. Also, the boot loader is probably in the chip, and must be restored after the firmware update, or the device will be bricked. This is a dangerous operation, because if something goes wrong, the device will probably be bricked. (emphasis added)
Q: Is there any documentation available on this issue? If so and it is private is it possible to have it released?
Originally Posted by Ken Sumrall (Android)
It is private, I'm asking if I can release it, along with the code to update the emmc firmware. Don't get your hopes up, my guess is the answer will be no.
Q: Alternate erase method?
Originally Posted by Ken Sumrall (Android)
If you really want to erase data on a rev 0x19 samsung emmc chip, I suggest you just write zeros to the entire partition.
Q: Difference between GB/ICS Wipe
Originally Posted by Ken Sumrall (Android)
IIRC, when using recovery to wipe the phone on GB, the make_ext4fs() library would not issue an erase command first, it would just write one a new blank filesystem. This, of course, doesn't really erase all the private data of the user, so we changed make_ext4fs() to first erase the partition, then write out the new filesystem. You can see the code in system/extras/ext4_utils/wipe.c, which didn't exist in gingerbread, but does in honeycomb and later. It is the erase operation on the rev 0x19 firmware that can cause the emmc chip to lockup. (emphasis added)
Regarding Entropy512's summary of observations:
Originally Posted by Ken Sumrall (Android)
Regarding the notes on MMC_CAP_ERASE, the just lists the cards ability to perform the erase command. In other words, if the mmc_erase() function works. What is more important is if anyone calls the mmc_erase() function. Looking at the mmc driver, in drivers/card/block.c, it is only called when a secure discard or discard request is made. As far as I know, those requests are only sent if the filesystem is mounted with the "discard" option, or if userspace code does an ioctl() to erase a partition, like make_ext4fs does. So check the mount options on the filesystems. *If they don't specify "discard", the erase operations are probably not happening.
Of course, a simple debugging printk() in the mmc_erase() function will tell you if anyone is calling it.
Additional info not directly related to questions:
Originally Posted by Ken Sumrall (Android)
The lockup doesn't happen immediately after power-on. The chip doesn't lock up until a sector is referenced that has corrupted wear leveling data inside the chip. Once that sector is referenced, the chip will lockup hard, and the only thing that will get it talking again is to power cycle it. Once it is power cycled, the chip will talk again, until that bogus sector is accessed.
http://forum.xda-developers.com/showpost.php?p=26521643&postcount=293
So, absolutely no CWM wipe for Note, until we got a solution? Maybe change custom ROM CWM wipe as write zeros or delete all files instead of file system format?
It just seems crazy that Samsung/Google cannot release a small file to flash that would fix this problem. I'm sure they could if they really wanted to.
I am asking Samsung Singapore about the eMMC bug on their facebook page. Hope to get some info on whether the bug is proliferating across region ICS versions or have they actually silently fixed it.
for what the note is worth and they sold millions it should be fixed now this is putting me off getting another samsung ,which i really do like them it feels like they have let us down
It is not just the Note, it is all Eyxnos based Samsung phones including the GSII. I could be wrong, but I think they sold a few of those...
It is not just CWM wipe that is the problem. You can brick performing a factory reset on official XXLPY (and all official ICS kernels so far... and all leak ICS kernels). The only safe kernels are those based on GT-I9100 Update4 source code release - this includes XplodWILD's CM9 release (and it's derivatives such as Asylum, Paranoid, MIUI) and Entropy's DAFUQ and that other WizDom kernel with more to come now that there is source available.
FYI, the N7000 source even has the MMC_CAP_ERASE bug. Just look at Franko's kernel thread.
Global recall lmao
Sent from my GT-N7000 using Tapatalk 2
nickshertzer said:
It is not just the Note, it is all Eyxnos based Samsung phones including the GSII. I could be wrong, but I think they sold a few of those...
It is not just CWM wipe that is the problem. You can brick performing a factory reset on official XXLPY (and all official ICS kernels so far... and all leak ICS kernels). The only safe kernels are those based on GT-I9100 Update4 source code release - this includes XplodWILD's CM9 release (and it's derivatives such as Asylum, Paranoid, MIUI) and Entropy's DAFUQ and that other WizDom kernel with more to come now that there is source available.
FYI, the N7000 source even has the MMC_CAP_ERASE bug. Just look at Franko's kernel thread.
Click to expand...
Click to collapse
And the devs on here, now that they have a source, will eventually remove that MMC_CAP_ERASE code from the kernel. Just give them some time. If Samsung won't do anything, then we at XDA will make the best of what we can. And I say Samsung and not Google because the ball really is in Samsung's court, not Google's.
wasnt this published a little while ago on the portal?
panyan said:
wasnt this published a little while ago on the portal?
Click to expand...
Click to collapse
Yes, it was.
So that makes sense FINALLY. GB never did a true wipe, sorta like a soft format pc. Can we just modify the ics kernels to mmc_erase() as how gb runs it and get rid of the new code? This is a temporary work around.
PoisonWolf said:
Can we just modify the ics kernels to mmc_erase() as how gb runs it and get rid of the new code? This is a temporary work around.
Click to expand...
Click to collapse
that was my exact thoughts too as i was reading it -> just do a quick wipe and not full erase
panyan said:
that was my exact thoughts too as i was reading it -> just do a quick wipe and not full erase
Click to expand...
Click to collapse
Yeah, like how Ken talked about Honeycomb and forward having wipe.c, let's just get rid of that nonsense.
I dont know how it works, but if you're on Gingerbread, and you encrypt your phone, and you do a full-wipe in CWM, can a person still access the data? I mean, we now know that they could with the right tools since the information is still on the chip, just not easily accessible. But if it is encrypted, can it be decrypted and accessed? I guess what's the encrypting algorithm and is it the same for all devices?
If the information cannot be accessed if it is encrypted, then paranoid folks shouldn't have to worry with soft wipes.
Can anyone confirm that a 32 GB Note shipped with the same 0x19 firmware on the emmc?
Markuzy said:
I am asking Samsung Singapore about the eMMC bug on their facebook page. Hope to get some info on whether the bug is proliferating across region ICS versions or have they actually silently fixed it.
Click to expand...
Click to collapse
Well don't hold your breath that would mean that Samsung has made a BIG mistake in their's firmware's and that would produce lots of anger and sales drop.
I think IF they decide that they will eventually fix this it would be in big quiet and just like part of "new" firmware like 4.0.4 etc
panyan said:
wasnt this published a little while ago on the portal?
Click to expand...
Click to collapse
andreww88 said:
Yes, it was.
Click to expand...
Click to collapse
Where? This was written yesterday so i don't know what is exactly "little while ago" ?
Additional info not directly related to questions:
Originally Posted by Ken Sumrall (Android)
The lockup doesn't happen immediately after power-on. The chip doesn't lock up until a sector is referenced that has corrupted wear leveling data inside the chip. Once that sector is referenced, the chip will lockup hard, and the only thing that will get it talking again is to power cycle it. Once it is power cycled, the chip will talk again, until that bogus sector is accessed.
Click to expand...
Click to collapse
This concerns me the most. Is there any way to "test" all sectors of the phone's emmc to see if we have the bogus sector?
Like a terminal command to create a file of X size so you could "fill" up the entire phone with a bogus file. Could this work?
PoisonWolf said:
This concerns me the most. Is there any way to "test" all sectors of the phone's emmc to see if we have the bogus sector?
Like a terminal command to create a file of X size so you could "fill" up the entire phone with a bogus file. Could this work?
Click to expand...
Click to collapse
Yes that would be very useful, to actually check if our phones are already damaged ...
Hm, makes me wonder about some peoples SODs
GocaS6 said:
Where? This was written yesterday so i don't know what is exactly "little while ago" ?
Click to expand...
Click to collapse
http://www.xda-developers.com/android/hard-brick-bug-on-galaxy-s-ii-and-note-leaked-ics-kernels/
panyan said:
http://www.xda-developers.com/android/hard-brick-bug-on-galaxy-s-ii-and-note-leaked-ics-kernels/
Click to expand...
Click to collapse
If you read it carefully you'll notice that this is not same conversation
Where is the BIOS in this thing? I get that it has /boot /system and /recovery but where is the firmware that the device very first utilizes?
Does the streak even have any type of NVRAM memory?
webdawg said:
Where is the BIOS in this thing? I get that it has /boot /system and /recovery but where is the firmware that the device very first utilizes?
Does the streak even have any type of NVRAM memory?
Click to expand...
Click to collapse
What are you attempting to do?
Understanding and Hacking
I am trying to understand the device and search for potential exploit vectors. If I take out the inner SD card what type of data does the device still have on it?
It has to have something that starts the boot from the inner SD card. Does this something insert anything into the running code on the device? Can it?
Can, if the device has the type of storage I am talking about, the device record and store even a small amount of data?
I have heard of reference to NAND backups and even seen a quote about how the NAND backup util included in the recovery utils does not backup something. The something I am referring to is not the external SD card.
Web...
Strephon Alkhalikoi said:
What are you attempting to do?
Click to expand...
Click to collapse
Why would you need exploit vectors when the system is completely open/unprotected?
the innerSD holds the /data and /cache partitions
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
TheManii said:
Why would you need exploit vectors when the system is completely open/unprotected?
the innerSD holds the /data and /cache partitions
Click to expand...
Click to collapse
webdawg said:
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
Click to expand...
Click to collapse
Unfortunately for you it seems you don't know what you're doing or why you're even asking about it
Sent from my GT-I9100 using Tapatalk 2
Okay Then
cdzo72 said:
Unfortunately for you it seems you don't know what you're doing or why you're even asking about it
Sent from my GT-I9100 using Tapatalk 2
Click to expand...
Click to collapse
Please. Unless you have an answer please do not reply. I know exactly what I am talking about. If the device does not have any NVRAM in it that one could flash to and only internal memory via SD card then just say this.
webdawg said:
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
Click to expand...
Click to collapse
Manii knows far more about the Streak than you do, so if you want your questions answered, I suggest you check that attitude of yours at the door.
Strephon Alkhalikoi said:
Manii knows far more about the Streak than you do, so if you want your questions answered, I suggest you check that attitude of yours at the door.
Click to expand...
Click to collapse
Your right. Did not realize it was him, work has an affect on my attention. Sorry Manni.
I am at home now. Let me try and expain myself.
I just do not get it. All the pages I have read and the research I have done everything tells me that everything is stored on the internal SD card.
But I still have this nagging thought from this page: http://www.rdtk.net/2011/06/25/using-streakmod-recovery/ that says this: the firmwares reside on the nand but in an entirely separate area. only stock recoverys can write to them under normal circumstances, you can probably read/write them manually but it’s dangerous as you can super-brick if you don’t know what you’re doing
What the hell is that guy talking about? The way I read it is that an entire subset of firmware exists on the device that only that one webpage has ever talked about. (That I have read)
I have read alot about BIOS hacks and how they function inserting code into Windows. Even legitimate code for paid services. Computrace.
I know about the Carrier IQ software. What I do not know about is the software outside the rom, recovery, boot partitions and such that exists on the Dell streak or any Android device.
I suppose my attitude comes from the ton of forum posts that I read with unanswered questions because people wanted to know why the OP is asking such a question.
I took Manii's post the wrong way because of your question Steven. Not to offend you and I understand why you ask. For example I just hate going into support channels and asking questions about an iptable rule and being told that I should relearn Linux networking because...well just because I did not understand one concept. I took it the same way here.
I apologize to all.
Web...
MTD based nands are more complicated then eMMC nands in this aspect, as MTD nands you simply cannot read from the 'hidden' portions of the nand. eMMC ones you can.
eMMC devices you can always read from any eMMC partition, so you can likely make complete backups including your modem (though no custom recovery does this by default, it's still a bad idea)
Fortunately for us, MTD seems to be 'obsolete', every device that launched with GB installed or newer uses eMMC.
Dell Streak 5/Partition layout - XDA wiki
Dell Streak Pro/Partition layout - XDA wiki
The S5 is a MTD device, the SPro is eMMC, note how the SPro has many more partitions.
The majority of them also exist on the S5, but the only way to access them (safely) is though a stock recovery.
You can write to them with fastboot, but some of them must be unpacked by an updater in the stock recovery. Simply flash them (specific ones) and you'll super-brick that would require JTAGging at a minimum to fix.
You simply cant read the other MTD partitions without JTAGing (it might be possible with a specificly modified kernal, but you dont gain anything doing this, if at all), assuming that the hidden parts are MTD partitions even. For all we know the controller could be directly writing onto NAND pages with their locs hardcoded (which would kinda be like partitioning, but without the formal partition tables(?) )
There's also is a small amount of memory that can only be written (afaik) via JTAG.
It contains your device's ID, such as Service tag and IMEI.
On tegra devices (at least the S7 and S10) it's the WP1 and WP2 partition.
It could be possible that it's on the NAND as a MTD partition, but if it is we dont know about it. It would be insane (and illegal, as changing your IMEI is illegal in most countries) to write to it, but so there's never been an example of it. I dont know where they are on the SPro, i'd need a live device to check.
The modem OS itself is stored on the nand, the modem processor knows (or the bootloader knows) how to feed it it's OS image.
Location breakdown:
NAND: <everything on the partition layout above, including the below>
/system
/firstboot
boot.img
recovery.img
amss.mbn
appsboot.mbn
dbl.mbn
dsp1.mbn
fsbl.mbn
osbl.mbn
DT.img
The innerSD
/data
/cache
Modem storage (lock state)
Device unique data (IMEI and Service tag)
RTC (the clock)
I dont know the exact terminology or the exact order of booting on qualcomm snapdragons (it's likely to be the same with all at least in the same generation)
But it's something like:
Press power button
CPU powers up
IPL loads <hardwired onto cpu>
Check if innerSD is valid (this is streak specific, device also locks up if it fails as the loader isnt robust enough to work around it)
Init modem and it's firmware <amss.mbn on older devices, non_hlos.bin on newer devices> (FYI modems are themselves complete 'system's in that they have their own ram and OS, basebands are complete OS images in most devices)
Check what button combos are pressed
Start booting:
If you pressed the recovery mode combo:
Load recovery SPL <dbl.mbn? + DT.img>
Display SPL menu:
Reboot
Load Recovery ("update from update.pkg")
Read from recovery.img and load it
Caliberate screen
If you pressed fastboot mode combo:
Load the fastboot loader <fsbl.mbn?>
If you pressed the download mode combo:
Go into download mode (for QDLtool)
If you did not press any combo: begin booting normally
Load dsp1.mbn
Load boot.bin
Linux kernal mounts and starts reading:
/system
/cache
/firstboot
/data
Android boots normally
Boot completes, you're at the lockscreen/home screen
I'm just making educated guesses at which *.mbn does what, as noone's really studied them to the point that they are willing to modify them.
Regardless they're signed so you cant modify them (we dont know per-se that the CPU checks the signatures on *.mbns, but I dont think any is willing to risk their device to try anyway)
The kernal images arnt signed, you can simply toss any kernal that is valid (otherwise it wouldnt boot)
When your device boots, the logo flashes 4 times:
1st logo: IPL and it's logo (possibly hardwired onto chip)
2nd logo: SPL and it's logo (stored in one of the *.mbns)
3rd logo: UBOOT and the kernal logo (stored with the kernal, sounds like a band name)
4th logo: bootimage.zip (whatever boot splash is with the installed rom
TheManii,
Thanks for the information. This is everything I wanted to know. If I have anymore questions I will ask later.
Web...
I have the Verizon Pixel XL and can now toggle the oem unlock switch in developers settings. Annoyed with the "grey out" I have done several things to make the switch useable. Well... Something worked. Now it's time to figure out what did the trick.
Solved. Using a root file explorer, got to /data/system/users/ 0.xml Open it up and edit it to reflect no restrictions. Or clone mine, might wanna remove my name though.. One requirement for this to work, all testing shows it will not work on stock kernel. Not sure if its a selinux issue or not but the modified ElementalX I made does boot up permissive and removes forceencryption. And using it Confirmed working..
I am decrypted and running permissive. All done through kernel editing. Not sure that made a difference or not but did notice any changes beforehand.
So you added the supercid through the kernel editing?
blueyes said:
I am decrypted and running permissive. All done through kernel editing. Not sure that made a difference or not but did notice any changes beforehand.
Click to expand...
Click to collapse
Sorry to be a bit off-topic but do you plan to document how you did the decrypt and permissive mode anywhere?
I'm guessing one of the unlock properties is what did it. I think something on the phone is recognizing it as a VZW model and is setting one of the properties to 0 and graying it out. I'll do some digging this weekend
dualityim said:
Sorry to be a bit off-topic but do you plan to document how you did the decrypt and permissive mode anywhere?
Click to expand...
Click to collapse
To decrypt you must fastboot format userdata. Flash a kernel the does NOT force encryption. Don't know if any are available so I edited the radial my self , on both kernel and boot-to-root images. To run permissive you simply add androidboot.selinux=permissive. I can upload the edited images later if your unfamiliar with modifications
jjayzx said:
So you added the supercid through the kernel editing?
Click to expand...
Click to collapse
Just added it to the kernel cmdline
blueyes said:
Just added it to the kernel cmdline
Click to expand...
Click to collapse
Thanks. I'll be back in a moment.
Update: It didn't work that way. Trying something a little different.
Update 2: Managed to change cid but still 0 for unlock support and grey. Going to try 1 more thing.
jjayzx said:
Thanks. I'll be back in a moment.
Update: It didn't work that way. Trying something a little different.
Update 2: Managed to change cid but still 0 for unlock support and grey. Going to try 1 more thing.
Click to expand...
Click to collapse
The kernel cmdline has to be edited before flashing. Try adding the persist.sys.oem_unlock... Line. Before run su , then set enforce 0
Why is being able to toggle it a big deal? If your unlocked then why does that matter ?
Rootuser3.0 said:
Why is being able to toggle it a big deal? If your unlocked then why does that matter ?
Click to expand...
Click to collapse
Who said it was a big deal. I clearly stated in op that it annoyed me. If you've got nothing positive to say then don't say anything.
blueyes said:
Who said it was a big deal. I clearly stated in op that it annoyed me. If you've got nothing positive to say then don't say anything.
Click to expand...
Click to collapse
And it's not just about being greyed out. I can now lock my bootloader and unlock it without any exploits. Simply using fastboot. Which sir, I do find to be a nice feature...
blueyes said:
Who said it was a big deal. I clearly stated in op that it annoyed me. If you've got nothing positive to say then don't say anything.
Click to expand...
Click to collapse
I never said you said" it was a big deal" I said that. Go kick rocks
I lost my ability of changing the cid but then i remembered it was after i had did the supercid. So when i put them both back my cid is now changed but my unlock support is still 0. I tried adding persist to default.prop but it didn't take or i did it wrong.
blueyes said:
To decrypt you must fastboot format userdata. Flash a kernel the does NOT force encryption. Don't know if any are available so I edited the radial my self , on both kernel and boot-to-root images. To run permissive you simply add androidboot.selinux=permissive. I can upload the edited images later if your unfamiliar with modifications
Click to expand...
Click to collapse
Did you do the kernel command on the phone? How do I edit default. Prop? I feel like that's where the transformation takes place since it's not editable like the build prop
jjayzx said:
I lost my ability of changing the cid but then i remembered it was after i had did the supercid. So when i put them both back my cid is now changed but my unlock support is still 0. I tried adding persist to default.prop but it didn't take or i did it wrong.
Click to expand...
Click to collapse
Did you add the line persist.sys.oem_unlock_supported=1.
Persists seems to be equivalent to a system override
Rootuser3.0 said:
I never said you said" it was a big deal" I said that. Go kick rocks
Click to expand...
Click to collapse
Go troll somewhere else.
blueyes said:
Did you add the line persist.sys.oem_unlock_supported=1.
Persists seems to be equivalent to a system override
Click to expand...
Click to collapse
Here's my build.prop
https://www.dropbox.com/s/bxgrk7ug66jiuz1/logs.zip?dl=0
cam30era said:
Use Android Image Kitchen > http://forum.xda-developers.com/showthread.php?t=2073775
Click to expand...
Click to collapse
Ok thank you and is this done through terminal or pc
cam30era said:
There are Windows and Linux versions (which I use). There's also a mobile version, but I've never used it.. Read @osm0sis thread. Very helpful.
Click to expand...
Click to collapse
That may be over my head as far as my abilities and I hate to create a new brick