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.
Android 3+ has a nice feature -- device encryption. You can encrypt the contents of your device with a password, and after that this password must be entered during device boot, otherwise the data is permanently lost.
The bad thing is that this password is set to the screen lock PIN / password. So you either set a short password or PIN, that you can enter quickly each time you unlock your phone from sleep (but this provides weak encryption), or set a long password and have to type it 20-30 times during the day.
This stupid behavior may be fixed easily. Android provides command-line tool called 'vdc', an interface to Android Volume Manager. As written in "Notes on the implementation of encryption in Android 3.0" [1], it has a command 'cryptfs changepw', that allows changing encryption password. Of course this command must be executed as root.
vdc has some other commands related to encryption, one of them is 'cryptfs verifypw', that allows to validate the supplied password.
I'm currently writing an application that will assist user with changing encryption password. This is my first public application for Android. You can find a source code on GitHub [2]. It is very simple, but maybe android gurus here may find what to make better.
Comments and pull requests are welcome
Thanks!
[1] http source.android.com/tech/encryption/android_crypto_implementation.html
[2] https github.com/kibab/encpasschanger
Updated 30.06.2012: Added APK file!
Kibab said:
Android 3+ has a nice feature -- device encryption. You can encrypt the contents of your device with a password, and after that this password must be entered during device boot, otherwise the data is permanently lost.
The bad thing is that this password is set to the screen lock PIN / password. So you either set a short password or PIN, that you can enter quickly each time you unlock your phone from sleep (but this provides weak encryption), or set a long password and have to type it 20-30 times during the day.
This stupid behavior may be fixed easily. Android provides command-line tool called 'vdc', an interface to Android Volume Manager. As written in "Notes on the implementation of encryption in Android 3.0" [1], it has a command 'cryptfs changepw', that allows changing encryption password. Of course this command must be executed as root.
vdc has some other commands related to encryption, one of them is 'cryptfs verifypw', that allows to validate the supplied password.
I'm currently writing an application that will assist user with changing encryption password. This is my first public application for Android. You can find a source code on GitHub [2]. It is very simple, but maybe android gurus here may find what to make better.
Comments and pull requests are welcome
Thanks!
[1] http source.android.com/tech/encryption/android_crypto_implementation.html
[2] https github.com/kibab/encpasschanger
Click to expand...
Click to collapse
Sorry im noob
What will change visualy?
Or screenshot?
Sent from my LT26i using XDA Premium HD app
Thank you for this. I wanted a more simple password for the unlock, but a longer more complicated password for the decryption. You should put it on the market and charge $.99USD (or equivalent in your currency) as it's quite useful. I'd buy it
Thank you!
Actually I have registered myself as Google Play Developer, now I'm waiting for approval. As soon as my registration is approved, I will update this thread
Although I'm going to make a free and donate versions, because I believe that will help to make Android better, and people who want to say "Thank you" will buy Donate version anyway
uDroid said:
Sorry im noob
What will change visualy?
Or screenshot?
Sent from my LT26i using XDA Premium HD app
Click to expand...
Click to collapse
Nothing will change visually, hence no screenshot. What's important is that you may set strong password for decrypting the internal storage, but keep using simple password (or PIN) to unlock the screen.
P.S. I have verified that my app works on Jelly Bean too.
I have finally published an application on Google Play! Currently there is a free version, Donate version will come a bit later
The link is: https:// play.google.com/store/apps/details?id=com.kibab.android.EncPassChanger
Enjoy!
Thanks for that app, that is also what annoyed me
Thanks for this. I've been trying to work out why encryption wont work on any ROM on my HOX (dies with unable to get size of block device cryptfs), and you have given me a good lead to investigate with vdc. Information on encryption in android is sparse, and almost all threads here on XDA get no replies.
Thanks again.
I've been tempted to use device encryption recently, but there is a distinct lack of information about it, particularly on custom ROMs...
Might need to give it a go, just the lack of backup abilities might be an issue...
pulser_g2 said:
I've been tempted to use device encryption recently, but there is a distinct lack of information about it, particularly on custom ROMs...
Might need to give it a go, just the lack of backup abilities might be an issue...
Click to expand...
Click to collapse
I use CM10 on the Galaxy Nexus (maguro). Encrypted. Actually, only /data is encrypted. /system stays unencrypted. And this App works as described.
For Backup use TWRP. It asks for your password to decrypt storage.
You can then backup, restore, flash, install whole ROMs, wipe and what not.
>> I would like to see this app in Play Store <<
I should read before I post:
Kibab said:
I have finally published an application on Google Play! Currently there is a free version, Donate version will come a bit later
The link is: https://play.google.com/store/apps/details?id=com.kibab.android.EncPassChanger
Enjoy!
Click to expand...
Click to collapse
Thanks for that
btw. The encrypted /data partition lets you have two boot animations, one that is shown before code has been entered (the one in /system/media) and one after the correct code entry (the one in /data/local).
zurchpet said:
I use CM10 on the Galaxy Nexus (maguro). Encrypted. Actually, only /data is encrypted. /system stays unencrypted. And this App works as described.
For Backup use TWRP. It asks for your password to decrypt storage.
You can then backup, restore, flash, install whole ROMs, wipe and what not.
>> I would like to see this app in Play Store <<
btw. The encrypted /data partition lets you have two boot animations, one that is shown before code has been entered (the one in /system/media) and one after the correct code entry (the one in /data/local).
Click to expand...
Click to collapse
Hmm... I have i9100 (S2), so I would need to see about putting TWRP onto it...
Yeah, only data and SD are encrypted... Can TWRP cope with encrypted SD btw?
Great, it's easier than to change on command line
This should just be default android behavior
pulser_g2 said:
Hmm... I have i9100 (S2), so I would need to see about putting TWRP onto it...
Yeah, only data and SD are encrypted... Can TWRP cope with encrypted SD btw?
Click to expand...
Click to collapse
Yes, SD is encrypted too. And TWRP can only read from it after correct code entry. Don't know about the external SD though (since the Galaxy Nexus doesn0t have one).
zurchpet said:
Yes, SD is encrypted too. And TWRP can only read from it after correct code entry. Don't know about the external SD though (since the Galaxy Nexus doesn0t have one).
Click to expand...
Click to collapse
Wish I had a second phone, then I could just research this
Quite awesome. Now, can I use a strong password for encryption and then pattern lock for normal day to day use? That would be my ideal situation. I heart pattern lock!
Just trying to clarify how this works... so you keep your normal 'short' pin unlock code for unlocking the screen, but set a long code for decryption, and this code will only be requested once per boot, during bootup? Is this correct?
Thanks
How it works
Yes Sir. You are correct.
adrianblack said:
Quite awesome. Now, can I use a strong password for encryption and then pattern lock for normal day to day use? That would be my ideal situation. I heart pattern lock!
Click to expand...
Click to collapse
Unfortunately it's not possible to use pattern lock while using device encryption, Android forbids it. Patching Android framework will help, but this is completely another story and possible suggestion for ROM makers such as Cyanogenmod.
Is the 16 character Android limitation present, when using this tool? I currently use a 16 character device encryption/unlock pass phrase. I'd like to strengthen the device pass phrase some more.
I don't know if this is even possible during the device boot sequence, but being able to use a Yubikey with an OTG cable would be awesome!
RF
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...
Afternoon,
I'm using Exchange AcitveSync Policies (EAS) to encrypt our new WP8 devices for work. I wanted to know where the Bitlocker encryption is stored once encrypted?
And what is the process of decrypting an encrypted WP8 phone?
thanks
Without the key the phone would not be able to decrypt it's data - so I guess: yes, the key is stored on the device (presumably encrypted itself, using the users password/pin to start decryption).
As for decryption that is an interesting question. Someone will have to try it out. As far as I know there is no switch in the system to do this. One could try to remove the Exchange account from the device although I have no idea on how to even check wether it's decrypting/decrypted.
Settings -> Phone Storage
It is my first post here so hello. Can you help me?
I broke my phone. Fortunately it was insured. However I haven't been doing backup for a while. Main board remains untouched and so I had been trying to recover my data before sending it to service. Phone was encrypted. I had little time that weak and get little confused with fastboot/odin. Thus, I decided to send it and reconciled with data lost. Phone back to me form service with flashed android 5.0.
I have no experience with android.
I am trying to recover my data. My idea is simple. If disc encryption master key (specifically crypto footer) is untouched I should be able to decrypt data partition (I am thinking about low level decryption, bit by bit) and then use some software to recover files (because directory table was overwritten) that where no overwrite when phone was flashed. Since I was not deleting my files often, the most recent files should be placed at the end of data partition. Whats is more I should be able to decrypt my sdcard which Is also encrypted.
What I determinated for this moment:
1. According to: source.android.com/security/encryption/#storing_the_encrypted_key every android 5.0 is encrypted with default password at first boot. However mine was no. Encryption flags are not set and data are available form TWPR level without decrypting.
2. Here is more how encryption works: (p. 263-266) books.google.pl/books?id=y11NBQAAQBAJ&pg=PA262&lpg=PA262&dq=android+disk+encryption+master+key&source=bl&ots=nUYyBSuT2G&sig=w77YZ9EJValOVoGhGXxbRMgwtmY&hl=pl&sa=X&ved=0ahUKEwi9qMzlgd3MAhUE_ywKHV0sAdwQ6AEISzAF#v=onepage&q=android%20disk%20encryption%20master%20key&f=false
I haven't read everything for now...
It says that crypto footer is written on either end of user data partition, file or dedicated partition. There is a chance that crypto footer remains untouched after flash. Can somebody check what is the the case on s5? I cant do this on my of because If I encrypt phone I erase previous crypto footer.
3. cmds: vdc cryptfs chengepw | checkpw returning -1 and no more and any valuable informations. I did not search in logs, there is noting in dmesg also.
Does anyone have ideas how to do this procedure? Check if master key is still there or any clues?
Thank you in advice