| KotCzarny | maxd: nope, its full unlock, thats why the 70000usd reward | 07:57 |
|---|---|---|
| KotCzarny | it bypasses you all android lock screens, and you can use the phone normally | 08:02 |
| Maxdamantus | KotCzarny: pretty sure it will only be unlocking phone that is "locked" as in on the lock screen. | 08:09 |
| Maxdamantus | not "locked" as in just booted, hasn't had pin yet. | 08:09 |
| KotCzarny | yup, its just that, full unlock at boot | 08:10 |
| KotCzarny | if you have spare android phone try it | 08:10 |
| Maxdamantus | so what? Android is programmed to brute force the encryption key? | 08:10 |
| Maxdamantus | the pin is used as part of the encryption key. | 08:10 |
| Maxdamantus | at least in my version of Android (11). | 08:10 |
| KotCzarny | its like those complicated locks that unlock on the single wire signal | 08:10 |
| KotCzarny | key stores can have multiple entries to unlock | 08:11 |
| Maxdamantus | so what entry is used to recover the masker key in this case? | 08:12 |
| Maxdamantus | s/masker/master/ | 08:12 |
| KotCzarny | i would guess so | 08:13 |
| Maxdamantus | I'm asking what entry would be used. | 08:13 |
| KotCzarny | but since its only my guess, it would require checking personally | 08:14 |
| Maxdamantus | Unless they're storing a plaintext entry that allows the master key to be recovered just from data that's already decrypted (outside of the /user directory), it's not going to allow you to decrypt the device. | 08:14 |
| Maxdamantus | The CVE only talks about a "lockscreen bypass" | 08:15 |
| Maxdamantus | ie, the state that the phone gets in after you've booted and decrypted it, then you soft lock it. | 08:16 |
| Maxdamantus | you need to enter the pin on boot in order to generate some entry in the kernel keyring that allows the /user directory to be read (since it's encrypted using fscrypt). | 08:17 |
| KotCzarny | are all androids encrypted by default or one has to enable it specifically? | 08:42 |
| KotCzarny | s/all/all recent/ | 08:46 |
| Maxdamantus | afaik they're all encrypted at two levels. there's a key which is used for block-level encryption (ie, dm-crypt) which I think is meant to be derived from some sort of measured boot mechanism (so using something similar to a TPM, where the key is derived without user input). There's also filesystem-level encryption, where there's a master key stored inside a file called something like | 08:52 |
| Maxdamantus | "/data/unencrypted/encryption_key". | 08:52 |
| Maxdamantus | that "encryption_key" file should be encrypted using the device PIN, and it gets added to the kernel keyring so that files in /data/user can be read. | 08:53 |
| Maxdamantus | it's possible to not have a device PIN, in which case presumably the "encryption_key" file is either unencrypted, or it's encrypted using some dummy password. | 08:54 |
| KotCzarny | this is the original story about it: https://bugs.xdavidhu.me/google/2022/11/10/accidental-70k-google-pixel-lock-screen-bypass/ | 09:15 |
| KotCzarny | citing: 'It was a fresh boot, and instead of the usual lock icon, the fingerprint icon was showing. It accepted my finger, which should not happen, since after a reboot, you must enter the lock screen PIN or password at least once to decrypt the device.' | 09:16 |
| KotCzarny | so it might be the case if you just hotswap the sim card | 09:19 |
| KotCzarny | which is possible in phones nowadays | 09:20 |
| KotCzarny | long time ago sim was hidden under the battery | 09:20 |
| Maxdamantus | Hmm.. maybe they add an additional option for decrypting the master key using a previously used SIM PIN. | 09:28 |
| * Maxdamantus hasn't tried using a SIM PIN. | 09:29 | |
| Maxdamantus | it would be interesting to know if the "chapter 1" issue works with unknown SIM cards. | 09:30 |
| Maxdamantus | Hmm.. after enabling the SIM lock pin, it did indeed seem to rewrite the encryption key file. | 09:57 |
| Maxdamantus | so maybe it adds it as a secondary policy. | 09:59 |
| Maxdamantus | though I'm not able to unencrypt ("unlock" after boot) the phone with the SIM PIN, so I'm not sure what it actually updated. | 10:02 |
| Maxdamantus | actually, I don't know if it rewrote the "encrypted_key" file. I misinterpreted the timestamp, since it's in 1971 for some reason. | 10:06 |
| Maxdamantus | oh right, nothing actually got unlocked in "chapter 1". | 10:36 |
| Maxdamantus | they said that it got stuck saying "Pixel is starting...", presumably because the lockscreen mechanism was meant to be dismissed, but the device wasn't unencrypted yet. | 10:37 |
| Maxdamantus | so yeah, my initial understanding seems to be correct. if the device is off, the data is encrypted at rest, and can only be unencrypted using the device PIN (not SIM PIN or SIM PUK) | 10:38 |
| KotCzarny | you might be right | 10:39 |
| KotCzarny | still, hotswap simcard can fully unlock once it was initially unlocked by user | 10:40 |
| KotCzarny | and if patch level is older than september 2022 or so | 10:40 |
| Maxdamantus | I guess it's fixed on my phone, since I wasn't able to reproduce either issue, though I'm confused about the timeline. | 10:43 |
| KotCzarny | fix only came in sept 2022 | 10:44 |
| Maxdamantus | I'm using OxygenOS rather than plain Android, though it says the "Android security update" is 2022-07-01. | 10:44 |
| KotCzarny | maybe they fixed it on their own | 10:44 |
| Maxdamantus | maybe. looks like I last updated on Oct 31. | 10:46 |
| sicelo | voice calls work now on n900 in maemo leste, with clear audio | 10:46 |
| sicelo | early stages, but great achievement | 10:47 |
| KotCzarny | sicelo: niiiice | 10:49 |
| hexnewbie | Great news | 11:13 |
| KotCzarny | https://www.olx.pl/d/oferta/obudowa-pc-rack19-solidna-wytrzymala-CID99-IDTO2EC.html?reason=seller_profile | 13:10 |
| KotCzarny | ciekawe co w srodku | 13:10 |
| KotCzarny | darn, wrong window | 13:11 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!