CM14 / LineageOS support

[TwizzyDizzy]

Hi @nelenkov,

do you plan to support CM14 / LineageOS or is there anything present in those releases that don't make your app necessary anymore?

Cheers & thanks in advance
Thomas

[nelenkov]

Have you tried it on LineageOS?
There is some code to support CM, if they didn't change anything should work as is.

[TwizzyDizzy]

Oh... yes I did, with the 14.1 release of LineageOS. The app requested root privileges and I granted them.

When I tried to change the password, it always says that the old password is not correct (which it is, since I decrypt my data partition on boot with exactly that passphrase) and won't change the password.

If I can provide you with more details, please let me know :)

Cheers
Thomas

[fdutheil]

Hi,
I tried to use this application with either CM13 (last stable version from dec 2016 before RIP) and a derivative of LOS 14.1, and on both the app closes in a blink right after starting, with a popup "cannot get superuser access, exiting". Same device used: Moto G/peregrine with a(healthy) sdcard formated as internal and encrypted, root is enabled too (LOS "builtin" su installed + root enabled for applications).

Here are the logs from the LOS14.1 (clean install fresh from today):

05-03 16:17:12.961 30380 30380 I cr_BindingManager: onTrimMemory: level=80, size=0
05-03 16:17:12.997  2474  2528 E Notification: setLatestEventInfo() is deprecated and you should feel deprecated.
05-03 16:17:12.997  2474  2528 E Notification: java.lang.Throwable
05-03 16:17:12.997  2474  2528 E Notification: 	at android.app.Notification.setLatestEventInfo(Notification.java:2084)
05-03 16:17:12.997  2474  2528 E Notification: 	at com.android.server.am.ActivityManagerService$MainHandler.handleMessage(ActivityManagerService.java:2367)
05-03 16:17:12.997  2474  2528 E Notification: 	at android.os.Handler.dispatchMessage(Handler.java:102)
05-03 16:17:12.997  2474  2528 E Notification: 	at android.os.Looper.loop(Looper.java:154)
05-03 16:17:12.997  2474  2528 E Notification: 	at android.os.HandlerThread.run(HandlerThread.java:61)
05-03 16:17:12.997  2474  2528 E Notification: 	at com.android.server.ServiceThread.run(ServiceThread.java:46)
05-03 16:17:13.095  7146 13111 D OpenGLRenderer: endAllActiveAnimators on 0x99639c00 (RippleDrawable) with handle 0x98603bf0
05-03 16:17:13.095 31484 31484 D CryptfsCommands: ro.crypto.state= encrypted
05-03 16:17:13.139 31484 31530 I Adreno-EGL: <qeglDrvAPI_eglInitialize:379>: QUALCOMM Build: 10/09/15, 6cbbf7d, I3193f6e94a
05-03 16:17:13.140 31484 31530 I OpenGLRenderer: Initialized EGL, version 1.4
05-03 16:17:13.140 31484 31530 D OpenGLRenderer: Swap behavior 1
05-03 16:17:13.142 31484 31530 W Adreno-ES20: <get_gpu_clk:229>: open failed: errno 13
05-03 16:17:13.140 31530 31530 W RenderThread: type=1400 audit(0.0:143): avc: denied { read } for uid=10105 name="gpuclk" dev="sysfs" ino=16809 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:sysfs:s0 tclass=file permissive=0
05-03 16:17:13.154 31627 31627 D su      : su invoked.
05-03 16:17:13.155 31627 31627 D su      : starting daemon client 10105 10105
05-03 16:17:13.160 31629 31629 D su      : remote pid: 31627
05-03 16:17:13.161 31629 31629 D su      : remote pts_slave: 
05-03 16:17:13.161 31629 31629 D su      : waiting for child exit
05-03 16:17:13.168 31631 31631 D su      : su invoked.
05-03 16:17:13.170 31631 31631 E su      : SU from: u0_a105
05-03 16:17:13.172 31631 31631 D su      : Checking whether app [uid:10105, pkgName: org.nick.cryptfs.passwdmanager] is allowed to be root
05-03 16:17:13.175 31631 31631 D su      : Privilege elevation allowed by appops
05-03 16:17:13.175 31631 31631 D su      : Allowing via appops.
05-03 16:17:13.176 31631 31631 D su      : 10105 /system/bin/app_process32 executing 0 /system/bin/sh using binary /system/bin/sh : sh
05-03 16:17:13.177 31631 31631 D su      : Waiting for pid 31632.
05-03 16:17:13.207 31631 31631 D su      : Finishing su operation for app [uid:10105, pkgName: org.nick.cryptfs.passwdmanager]
05-03 16:17:13.210 31631 31631 W IPCThreadState: Calling IPCThreadState::self() during shutdown is dangerous, expect a crash.
05-03 16:17:13.210 31631 31631 W IPCThreadState: Calling IPCThreadState::self() during shutdown is dangerous, expect a crash.
05-03 16:17:13.213 31629 31629 D su      : sending code
05-03 16:17:13.213 31629 31629 D su      : child exited
05-03 16:17:13.214 31627 31627 D su      : client exited 0
05-03 16:17:13.236  2474  2544 I ActivityManager: Displayed org.nick.cryptfs.passwdmanager/.MainActivity: +317ms
05-03 16:17:13.248  2474  2484 I art     : Background partial concurrent mark sweep GC freed 10948(707KB) AllocSpace objects, 4(80KB) LOS objects, 33% free, 11MB/17MB, paused 3.078ms total 307.835ms
05-03 16:17:13.260  2712  2712 I SuControllerImpl: Got change
05-03 16:17:13.280  2712  2712 I SuControllerImpl: Got change
05-03 16:17:13.436  2474  2896 D WindowManager: relayoutVisibleWindow: Window{c1cd7c3 u0 org.fdroid.fdroid/org.fdroid.fdroid.AppDetails EXITING} mAnimatingExit=true, mRemoveOnExit=false, mDestroying=false
05-03 16:17:13.570 31484 31484 W IInputConnectionWrapper: reportFullscreenMode on inexistent InputConnection

As a side note, the syntax chown in the #14 and #15 issues is still valid for LOS 14.1: vdc cryptfs password current-password new-password, not the one documented in the Readme.md. Thanks to your research and the documentation gathered in this github repo, I was able to manually change the cryptfs password.
Thank you.

[TwizzyDizzy]

Hi @fdutheil,

vdc cryptfs password current-password new-password

nope... not working on LineageOS 14.1 (latest weekly). Tells me that it's an unknown cryptfs subcommand. However, vdc cryptfs changepw password foobar doesn't work either and prints out syntax help.

Trying (as advised in those help texts) vdc cryptfs changepw pin 0000 password plaintext-pw prints the same help text again.

Kinda lost here now :/

Cheers
Thomas

[fdutheil]

Hi @TwizzyDizzy ,
sorry (bad C-C/C-V from other ticket), yes, I used vdc cryptfs changepwd password current-password new-password (latest AOKP, LOS based). Anyway, the "usage" help displayed was wrong.
I'll try a vanilla LOS weekly soon, to compare.

[TwizzyDizzy]

Well... I now did the vdc cryptfs changepw pin 0000 test and in TWRP I can decrypt the data partition with the password test but on booting android, it only shows a pin pad instead of a keyboard. I guess I'll have to get around that somehow :/

But thanks so far!

Cheers
Thomas

[frauhottelmann]

Here is what I did on my Pixel C with the latest (unofficial) LOS 14.1 build and LOS' su:

1. I encrypted the tablet
2. I set a pattern unlock without the need to enter it at startup
3. I used the app to change the PW with current password empty
4. On reboot it asks for the password and for unlock it asks for the pattern! 🤗

[eugenesan]

Confirming @fdutheil suggestion.
Official LOS 14.1 (as of 20170516) accepts the following syntax: "vdc cryptfs changepwd password current-password new-password" while command usage displays: "cryptfs changepw default|password|pin|pattern [currentpasswd] default|password|pin|pattern [newpasswd]" which is incorrect.

Thank you, now I was finally able to change my encryption password from a pattern using:
vdc cryptfs changepw password 2365 xyz1$abc
2365 is the number representing the wipe pattern i had before.
the result code was: 200 9076 0
unfortunately i forgot to use quotes and now i cannot unlock the phone anymore because the password "new1$pwd" is not recognized by the unlock dialog :-( I am using LOS 14.1 and the unlock dialog does start with a full keyboard so it did recognize that the new pass is text.
I also tried "xyz1", and adding a space, but no success. right now i'm stumped...
EDIT: When I boot into TWRP recovery, I'm prompted for the passowrd and it works if I enter the part before the "$" but it's not accepted by the normal system boot sequence, possibly because its only 3 characters? I can even get into the terminal via adb but I can't figure out how to change the password again, I can mount /system but i can't chroot into it, keeps complaining that it can't run /bin/sh but it IS present... any help much appreciated! Without chroot vdc complains about "cannot link executable / cannot locate symbol"

[eugenesan]

@arnolde73,
I believe your only option is using TWRP to:

1. Backup data
2. Backup sdcard
3. Format data
4. Restore data
5. Restore sdcard
6. Re-encrypt

It will take time but at least all your data shouldn't be lost 🤞.

Thanks, too bad there seems to be no "perfect" solution... but that worked for me. I guess I was lucky I got back in at all...

[magicgoose]

Hi buddies, this is what finally worked for me (latest LOS nightly, athene, LOS' addon su):

1. Enable encryption somehow
2. Unset screen lock (change to "swipe")
3. Set crypt password from root shell: vdc cryptfs changepw password myawesomepwd
4. Reboot and test the password prompt
5. Set PIN screen lock, but don't agree to "boot/encryption enhancements".

The end result is that you have different password for decrypting at the boot time.

Not sure if this will work with FBE, I apparently only had/have FDE.

Probably it's worth integrating this workflow into the app (with appropriate hints etc).
Maybe I'll give it a shot when I have some free time 😆

[freayd]

Hi all. I'm running the latest LineageOS 14.1.

I first tried vdc cryptfs changepwd password current-password new-password which resulted in "Unknown cryptfs subcommand".

Then I ran vdc cryptfs changepw password current-password new-password and voilà! (notice the changepw without 'd')

[DJCrashdummy]

beforehand: i tested with RR-OS 5.8.5 (which is also based on LineageOS 14.1) with LOS' su and OpenGApps...

---

@magicgoose
your procedure works, after a fashion... 😕 the command changes definitely something and the phone gets protected, but at

4. Reboot and test the password prompt

i was screwed, because the prompt for the boot-password didn't accept any password i could think of and neither TWRP did!
the only way to use the phone again was to perform a complete factory reset via TWRP.

--> according to my further investigation (read the 2nd part for more information) i figured out the password was set to "an empty value" (''), but you have to enter at least one character to perform an unlock-attempt.

---

@freayd

Then I ran vdc cryptfs changepw password current-password new-password and voilà! (notice the changepw without 'd')

i can confirm that this works. (thanks, btw!)

1. chose the protection you want to use for the screen-lock
2. encrypt the phone
3. maybe check with a reboot if everything is working
   • jfi: vdc cryptfs verifypw 'current-password' only checks the boot-protection: 200 xxxx 0 --> the last 0 stands for true/success
4. and then change the boot-password with vdc cryptfs changepw password 'current-password' 'new-password' - to be on the save side, add surrounding quotes (just at the command-line) to prevent problems with spaces or special characters.
   • hint: it seems that the 'current-password' hasn't any relevance, because the whole process also worked when i entered a completely random or empty ('') string.
     --> but no fear! i guess it's still no security-issue because as far as i know, the phone must be unlocked/booted to perform the command.
   • clarification: sometimes i saw others misinterpreting the use of the syntax because of the old one (vdc cryptfs changepw default|password|pin|pattern 'current-password' default|password|pin|pattern 'new-password')... although the second default|password|pin|pattern vanished, and the remaining default|password|pin|pattern stands in front of the 'current-password', it specifies the input-method for the 'new-password' used in future.
     if you think about it, it makes sense... because the 'current-password' doesn't matter anyway, and where else should you specify the new input-method.
     --> so be careful to enter the correct input-method! using pattern or pin, but a password, won't let you boot the OS since for now you can't change the input-method at start.
   • additional hint: take care that the 'new-password' has 4 or more characters, since it seems although only one or more are accepted at the boot-prompt, a password with less than 4 characters gets principally rejected. (but with TWRP the shorter password worked!)
     --> for sure this won't be a problem for secure passwords... just wanted to mention this, because i noticed this silly behavior while testing.
5. attention: with changing the screen-lock you will unfortunately always also change the boot-lock! - either you select require lock for start, then both locks will be changed; or if you select no, the boot-lock will be cleared.
   --> but not a really big deal, just redo the procedure to set the boot-password.