Gigadoc2

Thats... actually somewhat awesome. I mean, enrolling my own key would be better, but this way, I can prevent an "quick reflash" evil maid attack while still being able to run custom roms. Although, someone might still reflash via EDL without wiping data, defeating that. And, I don't know whether I want to risk not being able to fastboot flash anymore without wiping data first^^

To my great surprise, I have to object here. I just re-locked the bootloader after flashing a self-singed LineageOS build, and it still boots. I even disabled OEM unlock... I don't really know whats happening here. This does not sound like what the android documentation says, and also not how other bootloaders behave. But I have a re-locked bootloader now that boots my LineageOS...

@tdm: Is the switch from test2 to test3 requiring a wipe because of switching from stock vendor to lineage vendor? I am asking because I've built from your repositories already and for me it does, but I could be doing something wrong.

But I thought it was officially not wanted anymore? The xda post and https://review.lineageos.org/c/LineageOS/android_device_lineage_sepolicy/+/257100 kinda sound like it is being dropped deliberately. Well, I'd be glad to be wrong :)

That is very good to know. I already lost my included screen protector and now am worried to death (I've never before spent so much money on a phone) that I will scratch my screen. So if I actually ruin it there is at least some way to fix it :D

Why Elephone U, is it known to have the same screen as the Pro1? (It does look similar)

@tdm: I figured out what went wrong with the doze apk, and someone else did simultaneously: https://github.com/tdm/android_device_idealte_msm8998-common/issues/1

Soo, this might not be the ideal place to ask, but with the pro1 not yet being a device officially supported by LineageOS, i don't really know where else to ask... I am trying to build LineageOS myself to try out patches and use my own signing keys from the beginning (so that I don't have to wipe or migrate later). I have built LOS for my LG G3 in the past, that worked well (except for me not having enough hardware to keep compiling the builds every week), but now I am stumbling upon some unexpected errors: First, the FMRadio app would not build, with errors about unused parameters i

Just for the record: 275 here. But you probably noticed that the deliveries are rolling out now :D

Unfortunately not, fxtecs payment provider did not accept my credit card, so I had to use bank transfer (and thus I have no idea as to when they registered the payment). EDIT: So, when there is a cutoff for that I should probably not get my hopes up.

Haha, I had my d855 (yes, no keyboard, the last one for me was the n900) phone die on my after I ordered and paid the pro1, and then I almost immediately bought a used a5y17lte as a holdover. Turned out to be quite the good decision 😅 Another stupid question: Is the order status "processing" normal, or does that mean it's not even registered as paid?

Soo, I did not read all 116 pages of this thread - apologies in advance - but given the recent announcements I now wonder: What exactly are "Those with Indiegogo deals"? Are they all those who used the voucher from the IGG campaign for the Moto mod? Or all those backing an IGG campaign for the pro1 itself (did that even exist)? Or those having used the coupon and ordered + paid before a certain date? I am asking because I did use the voucher from the Moto mod campaign, and do have a number in the #36xxx range, yet have not received any mails so far. Now if this announcement does p

It is somewhat funny (but please don't take this as an insult, it is not) how the community "rediscovers" why horizontal sliders like this (or maybe sliders in general) died out. From people selling this phone in a very public way to debating over reviews like this it kinda looks like history repeating itself :D It is not only that phones without sliding mechanisms and complicated keyboards are easier to produce and are (in some ways at least) more durable (or waterproof, etc) than those with them; it is also that the learning curve for a "candy bar" is basically nonexistent. Sure, you wi

BTW (please tell me if this goes too far off-topic), it seems that full disk encryption is - cryptographically speaking - somewhat difficult and probably unsafer than just encrypting a file in its entirety: https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/ As I understand it, the problem arises from FDE having to find a compromise between a lot of properties, in particular that every sector on a disk may be accessed at any time. So, in theory file-based encryption would be better - if it would work on the whole file as opposed to on blocks. It seems though that Linux' FBE is doing

I can't give you exact commands to build and install it, but I can link you to the sources and the issue tracker: These are the two repos from @tdm: https://github.com/tdm/android_device_fxtec_pro1 https://github.com/tdm/android_kernel_idealte_msm8998 I think the issue tracker meant to be used for general issues his here: https://github.com/tdm/android_device_fxtec_pro1/issues Keep in mind though that not every issue reported may also be confirmed ;)

@Waxberry: Can we re-lock the bootloader with our own keys or is it only possible to lock it to your firmware?

Well now I am curious. If it's OK I would like to bombard you with questions: Are you allowed to share (part of) the sources? I'd guess you are allowed to share something, since you openly develop the LOS port, but is there more you can share or are you only allowed to use the knowledge from the sources to make the port work? I will probably use your LOS port as a basis for my phone (once I get it), but I am still somewhat interested in a "stock-like" build for mainly two reasons: For one, there might be features in stock (maybe also added later) which are unsuitable or not lega

From reading through the articles I got the impression that FBE would be more secure if Android were to evict some of the keys on device lock, which it currently does not. So, right now the advantage of FBE would only be that the phone can boot up some services before the passphrase input? I wonder, if Android ever introduces the "lock on device lock" FBE category, whether App developers would actually make use of it. Also, I suspect that App developers can choose files to be "device encrypted", in which case FDE may be indirectly more secure than FBE as it will encrypt all user data with

Are you sure that the bootloader itself decrypts anything? I was under the impression that the system partition (and whatever boot stages happen before mounting that) is unencrypted (but verified by prior stages in one way or another), the Android system partially boots and then you ask the passphrase and decrypt the data partition. True (that is why I mentioned the "key to encrypt your key" earlier), but I think that detail can be abstracted away (for all intents and purposes, a key saved on insecure storage but encrypted with another key (may be the passphrase) is as secure as the ot

Does the pro1 switch to landscape when the slider is opened? That is probably a modification to stock Android? Also, I got the feeling I am derailing this topic a bit 😅

Both is true, but I was more referencing to the "higher layers" of Android, i.e. UI customization and everything related to the slider. Though, that might very well be just the launcher. We could try pulling the launcher from stock and putting it into a LineageOS install, but of course having the source would be nicer :D

Man, stuff like this should be illegal under antitrust law... Do you know how far this extends? E.g, could fxtec provide us with enough sources of their Android customizations so that we can easily build those "alternative stock roms" ourselves, or is even that forbidden?

That is a very good point. I think it is mandatory nowadays to have some sort of hardware-backed keystore for Android. The pro1 has a qualcomm chipset, so it probably has QSEE, which uses the ARM TrustZone. The trust zone can have its own memory, but that is not mandatory, so I don't know if QSEE in particular has memory hardened against extraction. But if it does, and the encryption key (or parts necessary for it) is stored there, the locked bootloader makes way more sense to me. I mean, several vunlerabilities of QSEE have already been found, but exploiting those still seems more diffic

The method can't be used twice, because you notice after the first time. Even with the current procedure of locked bootloader + encrypted data, you notice when your phone has been tampered with as your data is gone. However, you only notice after you have given away the passphrase for your encryption. With the 3-stage scenario, you notice after giving away the stage 1 password (because the stage 2 password displayed by your phone is wrong), so you can stop before you enter the stage 3 password (which is the important one, because it is your encryption key / the key to your encryption key).

This is actually the first plausible argument I've heard as to why a locked bootloader could benefit the user (as opposed to only the HW vendor): If you have an attacker who gains physical access to your phone, with an unlocked bootloader they could dump the encrypted content from the phone and then either brute-force the key (if you used a PIN or a weak password), or (if you used a strong password) repace the OS with a version that logs the encryption password and sends it to the attacker, who then decrypts the previously gained dump when you unlock your phone the next time. With a locked boo