Related
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
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
If you ever used CWM, CWMT or other non factory recoveries to wipe your data, you probably noticed that you lost the ability to encrypt your phone. Or maybe you did not even realize this is why encryption does not work.
For the Android phone encryption to work, it needs the /data (usrdata) partition to have a little bit of unused space between the end of the filesystem and the end of the partition. And as soon as you use CWM to wipe, it actually reformats using all space, and encryption does not work anymore.
User lolo250612 brought this to my attention, and together we created a update.zip that shrinks the /data filesystem by 1MB
In fact, we created 2 patches: One to shrink, and one to first repair the filesystem. The first will refuse to shrink if the file system is not clean and healthy. They will automatically find the correct usrdata partition device and its size. The shrink will then resize to 1MB less then the partition size (which means it could also be used to grow if you somehow had a filesystem a lot smaller, for example because you restored an smaller image from somewhere).
Both patches are created with statically linked e2fsprogs binaries and its own static copy of busybox shell interpreter. So they should work on all Android devices that use ext file system (probably all V2.3.1 Gingerbread and higher androids), and you should not lose any data because of this. But it is always good to make a backup.
We tested this on 2 phones, both ICS phones, and with both CWM and TWRP type recoveries, and are fairly certain it is safe to use. But to repeat, you should always take a backup of your phone.
Both patches can be found on my shared drive:
ICS_usrdata_fix-fs.zip
ICS_usrdata_shrink.zip
Procedure:
- Make backup of your phone
- Place files on SD card
- Boot into recovery
- Apply the shrink update
- If it tells you the filesystem is damaged apply the fix-fs update first
The patch only shrinks the filesystem, nothing is actually installed or removed on the phone. But if you use encryption, you could leave this patch on your SD card so that every time you wipe data, you can run the shrink patch again afterward to enable encryption again.
If you do use this, please report back in this thread, possibly mentioning your phone model and ROM you are using.
Quick encryption guide (and more)
I won't go deep into useless details as everything has already been described about Android phone protection somewhere on the internet. I will just give some meaningful links and tips by illustrating how I have protected my phone. Really nothing new or innovative, just a compilation of a few hints that I have put in practice to protect the numerous pieces of information that are on my phone.
Step 0: awareness
----------------------------
Why bother with phone security?
In short, I am clearly paranoid. Well, in fact, I don’t really feel at ease when I know all the information, both personal and professional I have on my phone. Over the month, my Androphone has become a real digital Swiss-knife and personal secretary. This includes:
Personal and professional contacts
Personal and professional agendas
Personal and professional digital exchanges (SMS and email)
Personal and professional photos
Banking account information
Trails where I run
Etc… etc…
Don't want someone looks at them. Not you?
Fist step: on-line protection
----------------------------------------
The first step in protecting your data consists in making hard to access indirectly the data that lay on your phone memory. This access consists in using the system when the phone is on, either via the GUI and the phone controls, or remotely (essentially by network connections, or phone basic functionalities like sms). So, basically, you need to lock efficiently your phone from preventing someone else to unlock the user interface that allows interactions with the system, and protect all communication channels.
To lock efficiently your phone, you must use a pin code of at least 4 digits (6 is better) or a pass-phrase. The latter is much less practical without improving online security that much. Above all, you must avoid those silly locking solutions like face recognition unlocking, or pattern lock. Those are toys for naive young boys. Not for those concerned seriously by security.
For protecting remote access to your phone, I would suggest:
1) Double check that USB debugging is disabled. This a major security hole.
2) Turn on data connections (bluetooth, wifi and 2/G/3G/4G) only when required (email checking, web-surfing session, data synchronising), and off rest of the time.
3) Avoid install cracked unofficial apks, or applications that asks for permission far beyond their obvious and principal utility
4) Install a software security app, if possible, open source and recognised by xda members. Once an adept of Droiwall, I have switched to Avast mobile security because of its extra features. But it is not opensource and it is a question of taste. But do this carefully, see that for instance before making a choice: http://download.cnet.com/8301-2007_4-57391170-12/dont-get-faked-by-android-antivirus-apps/ and http://www.av-test.org/fileadmin/pdf/avtest_2012-02_android_anti-malware_report_english.pdf.
But, you must be rooted (which is in itself a security hole if not mastered) and one must have a kernel with netfilter functionalities activated. This is the case with the stock kernel of the phone I use at the present time (Lenovo A789). But was not the case of 2 Samsung phones I used before. You have to either install a custom kernel adapted to your phone, or make your own if you have access to its sources (see tutorials as: http://forum.xda-developers.com/showpost.php?p=22941057&postcount=1)
5) Personally, I would feel more at ease if I could find an easy to use firewall solution that could close, and better, make stealth all the local ports of my phone, especially when I am not behind a wifi router. But I haven’t found one yet. Droidwall, nor Avast, addresses this functionality, whereas it would be fairly easy to implement it with the netfilter system layer underneath.
Second step: offline protection
-------------------------------------------
Here we are. Now your phone is protected when it is on. But, what if you switch it off, or remove its sdcard? The data lay on the internal memory, unprotected (at best obfuscated). Really easy to find a custom recovery for almost all phones, write a script to dump /data on a sdcard and then make whatever you want with the copy.
Don’t like that? The only solution to prevent /data from being read by someone else is to encrypt the /data partition. To do that, your phone or tablet internal storage partitions must be seen by your system as block devices. This is the case with eMMC but not with Yaffs. So beware, if you want encryption you need to buy a device that answers this requirement. This is not always true and almost never documented. Notes on the implementation of Android encryption are there: http://source.android.com/tech/encryption/android_crypto_implementation.html
Now, as me, if you are reading these lines, you are certainly looking for extra information about your Android device and probably extra functionalities.
Certainly, the most frequent way to install extra functionalities and custom ROMs to your phone is to use an update zip file. With stock recovery, this zip file needs to be signed, otherwise it is rejected. For maximum flexibility and ease of use, alternative boot recovery have been developed, of which CWRP is certainly the most famous.
Usually, for 99% of users and operations, CWRP operates great. Sometimes, as nothing is perfect, a bug may occur. This is the case for built in ICS encryption process. As Cybermaus indicates in the first post, to be able to perform this encryption the /data filesystem must be slightly smaller than the underlying partition. But CWRP, at least up to the version 5.5, formats all the corresponding partition leaving no place for Android to store the required information to be able to start the encryption process. This is clearly described in the following links: http://forum.xda-developers.com/showthread.php?t=1792101 and http://rootzwiki.com/topic/25652-fixing-galaxy-tab-2-encryption/
I have discovered that by using aLogcat to track down the origin of the failure. The interesting part revealed to be: E/Cryptfs ( 87): Orig filesystem overlaps crypto footer region. Cannot encrypt in place.
To circumvent this problem, you will find in Cybermaus first post, two CWM update zip files that will do the trick in a simple and secure way. After flashing your ROM and wiping data with CWM, apply them, go to system encryption as described here:http://support.google.com/android/bin/answer.py?hl=en&answer=1663755, and after waiting one or two minutes (not more), the system should restart automagically to encrypt your /data partition.
Third step: making your phone even more secure and practical at the same time
-------------------------------------------------------------------------------------------------------------------
Android built-in encryption is in fact more or less Linux LUKS (http://en.wikipedia.org/wiki/Linux_Unified_Key_Setup). Plus, it is open-source so that everyone with the required skills can make an audit of the code to see if no security hole is present in the Android implementation. The underlying mechanism is strong and secure, as long as you use a strong password. I mean by strong, at least 12 characters that includes at the same time lower-case letters, upper-case letters, numbers and symbols. And it must be something impossible to guess for others while easy to remember for yourself. You will find a lot of resources on the internet on how to create such a password. For instance: https://help.ubuntu.com/community/StrongPasswords .
The problem with Android, in its attempt to keep the system not too complicated to use, is that the GUI (I insist: only the GUI, not the system) does not distinguish between the PIN or passphrase that you use to lock your phone when it is on, and the password used to encrypt the data that lay physically on your phone storage. So the casual user is in front of a paradigm: either he chooses a strong password for its data, but this will rapidly become tedious to type at least 12 characters to unlock his device several times a day; or he decides to use a PIN code, which is more practical to unlock the phone, and consequently uses a really weak password to encrypt its data which contains only digits, and thus may be cracked in a breath by any PC.
Fortunately, this paradigm is addressed and solved by small tools like EncPassChanger or Cryptfs Password (both requiring that your phone be rooted, which is by the way, paradoxically, a security hole if not used with caution ). See: http://nelenkov.blogspot.fr/2012/08/changing-androids-disk-encryption.html for complete notes about that. So for me, the only way, both secure and practical, to secure your phone is by using a PIN code of at least 4 numbers (6 is better). Then use a handy tool like EncPassChanger to have a true complex password for decryption at boot time.
Fourth step: increase security, without sacrifying practicability
-----------------------------------------------------------------------------------------
As I am paranoid, but at the same time don’t want my phone to become a source of annoyances, the previous “basic” steps were not enough for me.
So I decided to improve security in two ways:
1) By following the following tip, which I find great and is itself self-explaining: http://forum.xda-developers.com/showpost.php?p=26730989&postcount=2
2) By encrypting the photos I take with my phone, because these are linked with my private life and I won’t like that somebody gain access to them.
3) By encrypting documents I scan with CamScanner, for home and work, which may be sensitive.
4) By automating the action that disables USB debugging in case I forget to put it off after using it .
For point 2 and 3, documents lay on your sd card uncrypted. Android built-in encryption does not deal with both internal and external sdcard (just to be clear, by sdcards I mean partitions mounted as /mnt/scard or /mnt/scard2). To encrypt them you have to use once again an external tool. As I am an opensource fanatic for all that deal with security, I would recommend to use LUKS Manager (https://play.google.com/store/apps/details?id=com.nemesis2.luksmanager&feature=search_result and http://forum.xda-developers.com/showthread.php?t=1141467) which is based on dm-crypt module (yes, the same that Android uses for its build-in encryption), or Cryptonite (https://play.google.com/store/apps/details?id=csh.cryptonite&feature=search_result) which is completely open-source and implements the rock-solid Linux encfs on Android.
The latter is my personal choice. I do not use Crytonite in itself, except for creating the initial .encfs6.xml file. For everyday use, I use directly the Android port of the binary file encfs that comes with Cryptonite, and embed it into shell scripts. Up to now, no flaw, no problem. The password to open my encfs encrypted volumes is stored in a text file located on the /data partition. It is thus encrypted by Android and made accessible on boot when you decrypt this partition. So nothing more to remember.
To make things usable and practical, I use Tasker to automate the following things:
- Mount encfs volumes on start-up, by reading directly the password in the file located on /data
- Umount encfs volumes when usb is plugged
- Copy photos on a regular basis from the unencrypted /mnt/sdcard/DCIM to the safe place I created with encfs, delete AND wipe the original ones
Fifth step: be coherent about security
-----------------------------------------------------
Some people, torn apart by the paradigm described in Third step, by negligence or by lack of knowledge, strongly secure one part of the system, but make other parts big security holes.
Concretely, I am thinking about two examples: mixing encryption with pattern lock (or, even worse, with face unlock), or mixing encryption with usb debugging. Face recognition is just a jock. It is not reliable and fails very often. Moreover it is really easy to crack, with a photo for example. One of my colleague even achieved to unlock my phone with its own face, just because we are morphologically close enough. Pattern lock is not much better. (See: http://forum.xda-developers.com/showpost.php?p=37649447&postcount=6 and https://www.google.fr/search?q=smudge+attack).
So always ponder over (two times rather than one) each action you take that may touch system security.
Thanks lolo
I'm trying to use this on my VZW Galaxy S3 16Gb and this is what I'm seeing in TWRP v2.2.0:
Mounting System
Extracting system fixes
Update script starting...
Update script started
Disk /dev/block/mmcblk0p15: 13.1GB, 13140754432
4 heads, 10 sectors/track, 401024 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
ERROR: unlikely size of KB
aborting operation!
Update script ended
Unmounting system...
Update Complete
Click to expand...
Click to collapse
edit: The same thing happens with both scripts.
I need to enable device encryption because my employer requires it for email and other Google Apps for Business apps. Thank you for your help!
Anyone know why full disk encryption isn't available on some (if not most roms)? Is it something that needs to be added with intent aside in the building process, or dependent on how the stock rom was set-up to work with?
I was hoping this would help get encryption working on an EVO ics rom which has encryption available, but when you click "encrypt phone" it just hangs on an android screen and doesn't actually do anything.
i was really happy to find your solution to enable encryption on my HTC desire S (ICS, rooted), but unfotunately it doesn't work. the same thing happen to me as it happened to mushu13, only different numbers in lines 5 and 6. same result whichever script i choose. please help, i really need system encryption.
thanky you very much!
First thing you should know, I am not an Android Guru. And unfortunately, if your phone is not an A789, I won't be able to help you deep in technical details. Cybermaus is the most skilled of the two of us, technically speaking, and he may lack time to answer correctly every request he is regurlarly faced with.
Okay, I do not know your phones and don't own them. So, distant debugging is much harder in these conditions. But the first things you should check, before applying Cybermaus' patches, are :
1) if encryption works with stock rom
2) follow thoroughly all steps I described in "Second step: offline protection" of the second post of this thread :
- your phone or tablet internal storage partitions must be seen by your system as block devices. This is the case with eMMC but not with Yaffs. If you don't have this information from the manufacturer, install Terminal Emulator from the Play Store and type 'mount' in it. You should see lines beginning with /[email protected] and /[email protected] If this is not the case, I fear encryption won't be able to work on your device.
- use aLogcat to track down the origin of the failure (see resources on the internet to learn how to use it, and links I have put in the second post)
3) Be sure that required modules are built into the kernel you use, especially dm-crypt
4) Post your results and cross your fingers that either this is a problem I have already encountered (in this case I may help you further), or Cybermaus see your posts.
While this script did allow me to encrypt my phone, it also shrunk my /data partition to roughly 1.1 GB.
Any ideas on how to expand it back to a reasonable size? I supposedly have 4 GB of ROM, and I assume more than 1 GB ought to be available for data.
Sent from my HTC Sensation using xda app-developers app
Thank you for your nice guide.
Only one thing is missing: baseband security.
Attacks on the baseband system requires very skilled people. Such as government agencies. It is believed they use baseband attacks to break into almost every mobile device. And there is only little you can do. Some vendors like Cryptophone have mobile devices with a hardened Android system. All others have no way to protect their device against baseband attacks.
Is this patch and reasoning still valid for newer android releases.
I am running a custom kitkat rom and twrp on a note 3 and can't encrypt so im looking for a fix.
I have been looking around for fixes but different posts blame different things.
Sometimes its the fact its a custom recovery, sometimes its that root is on the device and then there is this reasoning
Is there a way to find out the cause and fix for kitkat?
Virus
Hi, i tried to download your files
ICS_usrdata_fix-fs.zip
ICS_usrdata_shrink.zip
But the file are exe files with viruses.
Any ideas?
u2funker said:
Hi, i tried to download your files
ICS_usrdata_fix-fs.zip
ICS_usrdata_shrink.zip
But the file are exe files with viruses.
Any ideas?
Click to expand...
Click to collapse
Maybe false alarm.
Lossyx said:
Maybe false alarm.
Click to expand...
Click to collapse
no, but if you search for these file, you will find some which work and which are without viruses. Check the link..it is not an zip file..it is an exe file
@cybermaus: just tried flashing the two *.zips on my Galaxy S 4 Mini running CM 12 (Android Lollipop) because my logcat tells me I'm getting the described cryptfs error. It seems my /data partition doesn't have that 1 MB of unused space needed for encryption. Now I would love to encrypt my phone using CM's integrated function without having to completely format the internal storage (because that's the other workaround I found: flash stock rom, wipe data (factory reset), flash Custom Recovery, flash CM again)
Do you have the time and device to update your script so it works with Android Lollipop as well? I see a lot of people come across this issue recently so there would be definetly use for such a nice script like yours!
Thanks for sharing this with us!
-Teutone
no available for download any mirror ?
Or write the script on the thread.
Thanks
Can you post the scripts? links are dead!
---------- Post added at 16:33 ---------- Previous post was at 16:32 ----------
cybermaus said:
If you ever used CWM, CWMT or other non factory recoveries to wipe your data, you probably noticed that you lost the ability to encrypt your phone. Or maybe you did not even realize this is why encryption does not work.
For the Android phone encryption to work, it needs the /data (usrdata) partition to have a little bit of unused space between the end of the filesystem and the end of the partition. And as soon as you use CWM to wipe, it actually reformats using all space, and encryption does not work anymore.
User lolo250612 brought this to my attention, and together we created a update.zip that shrinks the /data filesystem by 1MB
In fact, we created 2 patches: One to shrink, and one to first repair the filesystem. The first will refuse to shrink if the file system is not clean and healthy. They will automatically find the correct usrdata partition device and its size. The shrink will then resize to 1MB less then the partition size (which means it could also be used to grow if you somehow had a filesystem a lot smaller, for example because you restored an smaller image from somewhere).
Both patches are created with statically linked e2fsprogs binaries and its own static copy of busybox shell interpreter. So they should work on all Android devices that use ext file system (probably all V2.3.1 Gingerbread and higher androids), and you should not lose any data because of this. But it is always good to make a backup.
We tested this on 2 phones, both ICS phones, and with both CWM and TWRP type recoveries, and are fairly certain it is safe to use. But to repeat, you should always take a backup of your phone.
Both patches can be found on my shared drive:
ICS_usrdata_fix-fs.zip
ICS_usrdata_shrink.zip
Procedure:
- Make backup of your phone
- Place files on SD card
- Boot into recovery
- Apply the shrink update
- If it tells you the filesystem is damaged apply the fix-fs update first
The patch only shrinks the filesystem, nothing is actually installed or removed on the phone. But if you use encryption, you could leave this patch on your SD card so that every time you wipe data, you can run the shrink patch again afterward to enable encryption again.
If you do use this, please report back in this thread, possibly mentioning your phone model and ROM you are using.
Click to expand...
Click to collapse
links are dead. Can you post the scripts?
Hello,
I own the Redmi 2 16 GB (HM 2014813), that's a good device but MIUI ROMs do not support device encryption. I've been searching for a clear answer but could not find any "definitive" information: Is there any custom ROM that will enable full/partial device encryption on this phone? Has anyone successfully tried with some of the ROMs that are maintained here?
Thanks a lot
Temasek CM13.0 can
Still no joy
harsh405 said:
Temasek CM13.0 can
Click to expand...
Click to collapse
Thanks Harsh405, I've checked on Temasek thread but apparently nobody has tried it, and my question there remains unanswered.
I'v got an old version of ResurrectionRemix installed (ResurrectionRemix-M-v5.6.0.-201601106-wt88047) with full encryption activated. Don't know about recent versions though.
I also have the same device like you..
And i confused what the custom rom can i flash be sides miui rom
gwgjust said:
I'v got an old version of ResurrectionRemix installed (ResurrectionRemix-M-v5.6.0.-201601106-wt88047) with full encryption activated. Don't know about recent versions though.
Click to expand...
Click to collapse
Thanks gwgjust, I'll take that a look!
rkpg has given a pretty clear answer on CM Thread: the Redmi 2 CPU ARM Cortex-A53 does not have native support for AES instructions, so it won't support device encryption or, even if you flash it with a custom ROM that has the option to enable it, it will perform VERY poolry.
So, here is the final short answer: Redmi 2 doesn't support device encryption. And even if you have changed the ROM and you can enable it, don't use it or you'll get huge problems. Instead, use Google Device Manager or the built-in "Find Device" MIUI functionality (https://i.mi.com) for protecting your device in case it's lost or stolen.
Additional information can be found here
Colosseo said:
rkpg has given a pretty clear answer on CM Thread: the Redmi 2 CPU ARM Cortex-A53 does not have native support for AES instructions, so it won't support device encryption or, even if you flash it with a custom ROM that has the option to enable it, it will perform VERY poolry.
So, here is the final short answer: Redmi 2 doesn't support device encryption. And even if you have changed the ROM and you can enable it, don't use it or you'll get huge problems. Instead, use Google Device Manager or the built-in "Find Device" MIUI functionality (https://i.mi.com) for protecting your device in case it's lost or stolen.
Additional information can be found here
Click to expand...
Click to collapse
Google device manager only help in finding phone, which is like peanut against full device encryption. Full device encryption helps to secure personal data being shared with servers of different apps and sites. No firewall or antivirus can stop sharing data with app and internet servers except full device encryption which Apple phones do.
rkpg said:
Google device manager only help in finding phone, which is like peanut against full device encryption. Full device encryption helps to secure personal data being shared with servers of different apps and sites. No firewall or antivirus can stop sharing data with app and internet servers except full device encryption which Apple phones do.
Click to expand...
Click to collapse
Totally agree. The only thing that these apps can do for security is allowing user to remote wipe the phone
mine works
rkpg said:
Google device manager only help in finding phone, which is like peanut against full device encryption. Full device encryption helps to secure personal data being shared with servers of different apps and sites. No firewall or antivirus can stop sharing data with app and internet servers except full device encryption which Apple phones do.
Click to expand...
Click to collapse
I just installed cm-12.1-20161121-UNOFFICIAL-hermes.zip and it encrypted within seconds, NO performance hit (that I could tell)...
cheers,
tencarsb
Good to know, thanks for update!
Encryption should work in ARM64 builds, geekbench tests show big difference in AES performance:
19.4 MB/sec (32bit) VS 354.6 MB/sec (64bit)
4 hours later...
Just flashed [WIP][ROM][ARM64][VoLTE][Redmi 2] CAF_AOSP_7.1.2 for Redmi2 WT88047, and encryption works!!
I am wondering if there's a working temp root (or even perm root without bricking Android 6.0 OS) for this Verizon exclusive ASUS Zenpad z10, as I am now looking for a way to unlock the bootloader as most of unlock commands are intact in the bootloader itself - only "Allow OEM unlock" tab is missing, so I will have to extract the bootloader partition and system configuration partitions - the problem is root.
That way I can get started on putting TWRP after unlocking the bootloader.
Already tried temp root the manual way; running su in /data/local/tmp after giving it the correct permission. All I got was "1" in shell, basically along the line, "f*** you, I am not letting you run as root." Why temp root? I have to do it so I don't accidentally brick the tablet - all I want to do right now is to extract the vital partitions and examine every single of them to see if I can indeed get "Allow OEM Unlock" or some bootloader unlock approval commands so I can get ASUS ZenPad z10 unlocked. And there's absolutely NO ASUS update RAW file extractor tool to date.
Apparently it looks like ASUS and several other OEMs don't bother going the extra miles getting the bootloader locked down as tightly as Evil Moto, or worse, Samsung. They just simply remove "Allow OEM Unlock" tab and call it a day. (Beware, though, Qualcomm second stage bootloader varies so much among OEMs which is why I have to take a peek into the partition image and see what I can find.)
Although I'm of no help to you, I will be following this. I just picked up one of these today. There's simply not a lot of information out there.
Sent from my SM-N920V using XDA-Developers mobile app
Apparently, due to the way Android Marshmallow security system works, all I can do is wait (and probably trawl the forums, although I doubt it will happen unless I pull the kernel from the eMMC SSD which is technically a catch-22 situation, as I have to root before I can touch the kernel or even "Allow OEM Unlock" configuration file in some partition - a bit like chicken and egg paradox).
UNLESS there is a temporary root that works by abusing the Dirty Cow exploits, and allows me to pull the eMMC SSD partitions so I can look through the files contained within the pulled partitions.
Discovered that this tablet do have root detection system - it basically tattle to Verizon. Those bastards. Nevertheless, I would need to find a way to allow OEM unlocking (which I had gut feeling that it's there somewhere) without it getting all antsy.
The more I dig into it, the more I just want the bootloader itself to be unlocked. It never cease to amaze me how far Verizon will do anything to be so nosy.
Slightly off topic, but since you seem to be the only other person here who has this tablet... Have you attempted to figure out a simultaneous charge and data option? I've tried several different cables and adapters so far without much luck.
Sent from my SM-N920V using XDA-Developers mobile app
Good question, however I don't really have a computer with USB-C port, if you meant that (been considering doing a new computer build at some point which then I get better idea how this tablet function on USB-C doing general stuff via USB - it may be by the time this tablet is running CM 14.x, once we figure out how to unlock the bootloader, so it may be hard to say how it will function with stock ROM). On the other hand, regular USB is usually limited to 500 milliamps (1/4 that of bundled charger), so may not charge because of the current requirements that may have to be met within the power management firmware (meaning about 1 Amp - which many DIY PC motherboards now meet the minimum specifications).
However, the screen backlight consume the most juice so you may try turning off the screen after you have mounted the MTP drive (due to MTP security in Android - it will stay mounted after you plug it into computer and turn off the screen however), which then you may be able to charge it. It will take a while as there's a huge battery inside (7.8 Amp hour rating). You would have better luck with a computer that conforms to USB Power Delivery specifications (USB 3.x already support that - USB 3.x ports are usually blue, BTW, so it's kind of hard to miss).
Finally extracted the files from ASUS' Verizon ROM image - ZArchiver Pro apparently can read ASUS' RAW image file, much to my delight. Now, I will have to figure out how to treat the Qualcomm second-stage bootloader (aboot.img) and few other partition images as a disk drive so I can figure out how to enable OEM unlock so I can get this thing unlocked (and I will disassemble the Linux kernel - boot.img - and recovery toolkit - recovery.img - so I can get ball rolling).
Tried to unpack the boot.img and recovery.img - the boot unpacker failed with "Android boot magic not found". Oh well, I will try to keep at it.
Alright, I think it's because the kernel is compiled in ARM64 assembly codes (thus not really standard as far as most Linux kernel boot.img unpackers are concerned), so now I will try one that can and will touch 64-bit kernel image. Then keep on probing the entire recovery and boot images for potential clues to the OEM unlock configuration (and as well as system.img - one problem is, Linux refuse to touch the system.img even though it is evidently the EXT4 FS SSD image).
Anyone who know of decent multi-faceted disk image extractor (the ones that can touch the non-standard disk image, including boot.img and recovery.img which doesn't have the standard "ANDROID!" magic), let me know. I have been googling anywhere, and it's difficult to pull the vital files which I can look for important files. System image, however, may have to be analyzed for type of fuse file system (if it's not sparse file system, then it's definitely an odd SSD image).
Another ZenPad owner checking in. I had to go to asus's site to say this thing even is. The model number P00l is absolutely worthless.
Anyways I've ordered a laptop with native USB 3.0 so will poke around where I don't belong soon.
I absolutely hate this UI, who is to blame? Asus? Verizon?
Verizon. They usually make the call in firmware development (Can you say who locked the bootloader?) and yeah, they're famous for horrible stock firmware. Hence, I am figuring out how to unlock the bootloader just so we can get rid of garbage on the tablet. ZenUI is on ASUS though.
Nice hardware, bad software. That's kind of a shame. It will hurt even less when we get CyanogenMod 14.x operating system on it.
EDITED: the model number is zt500kl, not superfluous "P00l" - I had to figure it out, and GSM Arena had the model number (and bootloader apparently confirmed that).
Did a bit researching in how the "Enable OEM Unlock" tab in other devices' Developer Option works; the toggle goes into persistent data block (hitting home in PersistentDataBlockService.java file), thus going into factory device configuration file in the syscfg partition (mmcblk0p28) - however, I will need to successfully extract the system.img in the ASUS Verizon OTA, or if we can successfully root this thing, I can go ahead and pull some apps and files and see how Allow OEM Unlock can be accomplished.
Correction: it's actually config (mmcblk0p13) as the build.prop said ro.frp.pst points to /dev/block/bootdevice/by-name/config - this is where it will get tricky; the config.img file is actually blank - it's on the physical soft efuse partition on the eMMC SSD itself, which there will be some legit data. Which is essentially untouchable until we get shell root of some kind to extract it. After I get to it, all I have to do is to find out the magic value to "blow" the last value sector in soft efuse partition to allow OEM unlock (note - soft efuse is just that, you can relock the bootloader when you write blank partition image to reset the efuse values contained herein, so beware the official OTA update image package).
Asus ZenPad ZT500KL
I just purchased this tablet yesterday. If you need me to test anything feel free to pm me.....
Thanks for working on this, if I can be of any help. do not hesitate to ask.
Dr. Mario said:
Did a bit researching in how the "Enable OEM Unlock" tab in other devices' Developer Option works; the toggle goes into persistent data block (hitting home in PersistentDataBlockService.java file), thus going into factory device configuration file in the syscfg partition (mmcblk0p28) - however, I will need to successfully extract the system.img in the ASUS Verizon OTA, or if we can successfully root this thing, I can go ahead and pull some apps and files and see how Allow OEM Unlock can be accomplished.
Correction: it's actually config (mmcblk0p13) as the build.prop said ro.frp.pst points to /dev/block/bootdevice/by-name/config - this is where it will get tricky; the config.img file is actually blank - it's on the physical soft efuse partition on the eMMC SSD itself, which there will be some legit data. Which is essentially untouchable until we get shell root of some kind to extract it. After I get to it, all I have to do is to find out the magic value to "blow" the last value sector in soft efuse partition to allow OEM unlock (note - soft efuse is just that, you can relock the bootloader when you write blank partition image to reset the efuse values contained herein, so beware the official OTA update image package).
Click to expand...
Click to collapse
Due to a potential brick risk due to entering the wrong magic value, I'd rather that we have temporary root or shell root first so we can pull the soft efuse partition and some setting files from ASUS settings.apk / systemui.apk to figure out the FRP values just so we don't accidentally lock ourselves out or worse.
Once we find out what it is, we can go ahead and test that (kind of wish I have extra money to get a sacrificial tablet to take a jab at the bootloader, as Verizon love to make it risky).
Oh, and BTW, this tablet also have several hardware disabled by Verizon, like the fingerprint scanner (home button). All the reasons to get CyanogenMod, crDroid and any of the favorite CyanogenMod derivatives on it.
Dr. Mario said:
Oh, and BTW, this tablet also have several hardware disabled by Verizon, like the fingerprint scanner (home button). All the reasons to get CyanogenMod, crDroid and any of the favorite CyanogenMod derivatives on it.
Click to expand...
Click to collapse
I'm within my 14 day return period ...., send me a pm
Sent from my iPhone using Tapatalk
Give me a bit time and I will figure out what to poke in config partition and we can go from thereon. Some one-click root (like KingRoot) are questionable so it's hard to know as of yet, due to secure boot which will prevent the tablet from booting all the way to password request lockscreen if it notice something (and there's a root detection app inside /system/priv-app directory - even though Verizon doesn't care about me, whether I hacked it or not, given my history of hacking several Qualcomm-based smartphones, especially RAZR M, even though it may probably be because I paid all my bills on time).
Dr. Mario said:
Give me a bit time and I will figure out what to poke in config partition and we can go from thereon. Some one-click root (like KingRoot) are questionable so it's hard to know as of yet, due to secure boot which will prevent the tablet from booting all the way to password request lockscreen if it notice something (and there's a root detection app inside /system/priv-app directory - even though Verizon doesn't care about me, whether I hacked it or not, given my history of hacking several Qualcomm-based smartphones, especially RAZR M, even though it may probably be because I paid all my bills on time).
Click to expand...
Click to collapse
Sounds good. Didn't even know the tablet had a fingerprint reader ( home button)
Sent from my iPhone using Tapatalk