tdm
-
Content Count
801 -
Joined
-
Last visited
-
Days Won
84
Posts posted by tdm
-
-
I don't recall anyone mentioning when or whether stock will be upgraded to Q. Has anyone official chimed in on this?
Lineage is getting close to releasing Q (which will be 17.1). By the time that happens, I should have Lineage running well and updating should hopefully be pretty easy.
-
8
-
-
7 minutes ago, david said:
I was just curious how much work a casual bad guy would have to go through. For a real casual one, who doesn't know how to transfer data through adb, that does seem like an easy way for them to disable it and then boot into the phone to get at the goodies. Also good for someone who doesn't remember their code/pattern or it gets set wrong or fails for some reason.
Magisk must be intercepting that functionality that is auto enabling encryption on first boot I guess. Maybe by setting whatever the system settings set when they allow disabling it?
I avoid magisk like the plague but my first guess is bind-mounting the fstab file with a copy that removes the encryption parameters from the userdata partition.
-
2
-
-
1 minute ago, david said:
Thanks for all the info, and obviously, for the LOS work. Greatly appreciated.
Regarding diabling the lock code in recovery, that is by modifying a file?
Yeah, I meant running the SD card unencrypted so that it can be accessed in another computer, which is how a lot of people run it.
If we factory reset, will something try to force encryption again on first boot? I believe I read the way to get around that is to install Magisk after factory reset and before boot. But I wasn't sure how the Pro1 would behave if a factory reset is done or /data is formatted.
It is relatively well known that all you do is remove /data/system/locksettings.* to remove the lock screen. This can be done very easily in TWRP with the file browser. But if your data is unencrypted, why bother? Just suck the data out directly.
Yes, Android will force encryption on first boot. How it does that depends on FDE or FBE. With FDE (stock), it will encrypt in-place and then reboot. With FBE (Lineage), it will just encrypt files as per usual. Now, if you have files that are unencrypted under FBE, I don't know exactly how that would be handled. It may just continue to read them and only encrypt new files, or it may treat the unencrypted files as corrupt. I don't really know. Might be an interesting thing to test.
-
1
-
-
Just now, david said:
🙂 Thanks. I just wasn't sure if it would cause other problems with something that expects encryption.
I am more worried about me being able to access my data if/when things go wrong than a bad actor accessing it with physical access to the phone. I have been using my current phone without encryption for the last 8 years. I use a pass code for locking it. That should keep out the casual bad guys.
Someone can get around the pass code by doing a factory reset, but then they have wiped the data partition, so can't get at my data, in theory. They could use data recovery tools to possibly get at some of it, I guess. All my photos and videos will be on the unencrypted SD card anyway, so they will easily be able to get those from anyone's phone, if that is where people store them.
And the ability to use recovery tools is a prime reason I don't use encryption on my computers either. I want to be able to recover my data more than I care about bad guys with physical access. I encrypt at the file level for sensitive data.
I do realize many people want that added security though.
Question. Does the stock rom allow for disabling encryption in the system settings?
Nope there are no problems with encryption disabled. It just leaves your data open to anyone with access to your device. I always used to run unencrypted because entering a pin to unlock the device was a pain. But with the advent of fingerprint readers, this is mostly mitigated.
Just so you know, if your data is not encrypted, it is trivial to boot into recovery and remove the screen lock.
I haven't actually used an external sdcard in some time. But generally speaking, my sensitive data isn't there anyway. The stuff that's sensitive is usernames and passwords to various things. If you do care about your sdcard data, Android can encrypt the sdcard also. It just makes the sdcard unreadable on other devices.
I always encrypt my personal devices. They run Linux and decryption is very standard and straightforward. No need to worry about recovery. I understand that Android devices aren't quite as straightforward but at least there are various ways to backup your data.
Ultimately it's your device and your choice.
Finally, no, stock has no way to disable encryption. And neither does Lineage. But in both cases all you need to do is edit the fstab. Which will also require disabling other things like vbmeta and verity. Or, once Lineage is stable, you can do your own build with the fstab change.
-
1
-
-
Alright, so I got gnss fixed. I just did a fresh build and wipe and .... it boots. Unfortunately there are some broken things that need to be fixed before I can do another release (namely wifi and cell radio). But now that I've gotten it to boot, it should be all downhill from here. So I'll work on those and hopefully will have a working build within a few days. After that the bugs should fall quickly and official support won't be far off.
-
6
-
-
2 minutes ago, david said:
What bad things happen if we disable encryption?
You ... don't have encrypted data. 🙂 You may not care about it now, but if your device is lost or stolen it's nice to know that your data is (relatively) secure. I'm sure that if someone with a lot of resources was after you, they could hack into your data. But for most of us, encrypted data is "secure enough".
-
2
-
-
On 1/22/2020 at 11:34 AM, Noir said:
thanks alot @tdm for your work,
has anyone tried to use microG with this build? I am not experienced with microG, but I am trying to gain some knowledge about it. Having admitted that sorry if this question is unnecessesary, but maybe an answer is possible nevertheless.
My understanding is that microG requires a framework hack to work. I did not add that. Additionally, modifying /system to add the microG files will break verity so that would also need to be disabled. There may be more issues but those are the ones that come immediately to mind.
-
2
-
-
On 1/23/2020 at 7:35 AM, EvilDragon said:
@tdm If you've not read before: I'm the shop where the device has been returned..... sadly I found out here in this thread that he KNOWS what went wrong, in the contact form he only mentioned that he followed the official documentation to use sailfish OS and something probably went wrong. Not nice, but, oh well, I'll try to get it back in working state.
I also tried your flasher and can confirm it flashes the device successfully - but nothing happens afterwards.
I've tried both with Windows and Linux and both firmware versions you offered.
Of course, I want to get it back in a working state and if I can help improving the tool with that, I would be even happier 🙂
I'm pretty techie myself, so I know what I'm doing and can try whatever you suggest me to do 😄
I'm using the Pro1 myself, which means I have both a working version and the other non-working one.If you let me know how / send me the tools or firmware files, I'm happy to help.
It's really awesome you're working on this... as this is not the case on most smartphones 😕@EvilDragon nice to see you're actually here on the forums. That is a huge stroke of luck!
I'll be happy to work with you on getting the device back to a working state, but we should probably take this to another place. Feel free to reach out to me in email tdm.code at gmail dot com.
In answer to some of your other questions, no, the tool does not do a read-back-verify. But it's always been reliable for me.
If the flash process takes several minutes and succeeds, it is surely working as intended. So the problem is most likely (1) something that is not flashed by the tool is messed up, or (2) the device has a hardware issue such as bad UFS blocks.
Again, contact me, and we can work on figuring it out.
-
1
-
3
-
-
4 hours ago, mcdinner said:
@tdmare there any plans to release a third test build ?
Yup, absolutely. As soon as I can get a vendor image built and working.
I've just now gotten Lineage to boot with a custom built vendor image plus one remaining hack (copying the gnss blobs from stock). I'll try to clean that up and get it going today.
And hey what do you know... with the custom vendor image, a2dp actually works. 😄 😄 😄
-
4
-
-
13 hours ago, Gigadoc2 said:
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 in several functions (in the native part, not Java). To get going somehow I just omitted that app by removing "FMRadio" from "PRODUCT_PACKAGES" in your device makefile. That avoids this problem (obviously not fixing it, but I would have tackled that later), but now the doze apk won't build (or, apparently, link):
device/idealte/msm8998-common/doze/res/values/styles.xml:34: error: resource layout/preference_category_material_settings (aka org.lineageos.settings.doze:layout/preference_category_material_settings) not found. device/idealte/msm8998-common/doze/res/values/styles.xml:45: error: resource layout/preference_material_settings (aka org.lineageos.settings.doze:layout/preference_material_settings) not found.
I am a bit confused as to what is going on here? FMRadio not building should have nothing to do with the pro1 - except if the pro1 is the only phone using that app nowadays and that app is actually deprecated and not supposed to be built. Similarly, you did not change the styles.xml after the initial commit, which means it is not a recent change breaking things, and the builds you uploaded were using that version of the styles.xml. So, I would suspect that my fault is building against the current HEAD of lineage-16.0 while you build against some specific commits or the repos as they were at some point in time? If that is the case, could you tell me what I should build against?
Apparently no other device builds FMRadio nowdays. I have a local patch to make it build, but I'm holding off on submitting until I can get it to actually work.
As for the doze apk, I don't know. The current trees are heavily copy/pasted from dumpling (1+5t) so they should work. I'll be cleaning things up soon (again, after things actually work).
-
13 hours ago, david said:
@tdm, during your development, did you find any way to disable file system encryption? I believe things I read earlier indicated that ADB and TWRP can't read the /data partition due to it being encrypted.
Don't disable encryption. I'll get a TWRP that does decryption soon after I get Lineage in a usable state. But really you should have no need to decrypt data anyway.
-
1
-
2
-
-
On 1/20/2020 at 5:03 AM, Maplesteel said:
I use an AT&T MVNO on my main phone whilst working on the Pro1 cut-over. While I haven't yet flashed any LOS, would it help if I put my SIM into the Pro1 and report what APN settings it receives from the network? The Pro1 auto-set its APN settings when I fed it a T-Mobile USA Sim.
Thank you but I don't think that will help. The APN should only affect data. I think there is something else going on with my voice service.
-
On 1/19/2020 at 1:50 PM, igor said:
@tdm Lineage OS is a must have for me. The pro1 would be worthless without Lineage OS for me. Can you estimate the release date of the official Lineage OS on https://www.lineageoslog.com/build/scheduler ?
My plan is to order the pro1 six weeks before the official LOS release in order to get the device just in time.
Thanks for all your work you have already done!!!
I imagine that it will probably be within a week or two. I'm quite disappointed that I cannot get voice service (yet?) but that should not stop official support if the issue is my device.
-
3
-
-
Got to tier2 support with my carrier and they verified that voice should work. They focused on the "mobile network / preferred network type" setting to try fixing it. But we couldn't get it working. I'll keep trying.
I don't suppose anyone here uses AT&T USA with the Pro1 and wants to share their network type setting?
-
4 minutes ago, Hook said:
I know that @Craig had to input an APN for his AT&T MNVO. You might check their web site or ask customer service what apn you should use in your area.
Thanks but been there, done that, didn't work. I'll probably be calling them today.
-
1
-
-
12 hours ago, silversolver said:
If your carrier is Verizon, it requires some fiddling. Check the network compatibility thread for the short answer, and the verizon thread for the TL;DR version. 🙂 If it's not Verizon, I'd love to know what it is. There is a report of Australian carriers doing something unusual that causes the original stock firmware to not work but the OTA updates resolve that. LOS at last check did not work for this person.
It's Pure Talk USA, an AT&T MVNO.
-
So just a quick update regarding Secure Boot. I had considered posting a new thread about this but I'm not sure it's warranted. So I'll just drop this here...
I spoke with FxTec and they confirmed that they disabled Secure Boot intentionally. The rationale was that it makes the device more developer friendly, especially for non-Android OS's. I'm not sure I agree with this conclusion, but that is/was the decision. The one thing that disabling Secure Boot allows is building a custom abl (boot loader). I have yet to see anything that requires a custom abl. But it does leave the door open for me to reconfigure the device as non-AB and reclaim that 4gb of storage without getting the OEM to rebuild and sign a custom abl. Which is good, because I have doubts that they would be willing to do that.
-
3
-
7
-
-
So I've spent the better part of a day trying to figure out what's wrong with voice calls. I can't see anything wrong.
I've got reports from several people that voice calls work fine on Lineage. The one person that reported an issue on github says that it doesn't work on either stock or Lineage, so that's not a Lineage specific issue.
My experience is that I can get SMS and data, but no voice calls, both on Lineage and on stock. I have to assume this has something to do with my carrier and the IMEI, because there really isn't anything else that I can see that would affect it. I'll be contacting my carrier to see what's going on. But for now I'm going to table this issue and move on.
If anyone is able to make voice calls on stock but not on Lineage, please let me know.
-
7
-
-
2 hours ago, mcdinner said:
I have problems with Bluetooth audio devices. After connecting there is no audio and volume control.
I opened a bug and can send you more information if you need.Reproduced here, thanks for the report.
-
2
-
2
-
-
So I've been thinking about this custom key that AVB allows, and I've also read a bit of the source for abl where it's implemented. I've come to the conclusion that AVB is worthless at best and dangerously misleading at worst on devices that have Secure Boot (*) disabled, and the Pro1 is such a device by design. Let me explain...
The security that AVB intends to provide is to ensure that you are running code that has been signed, either by your OEM or by your custom ROM vendor that does AVB signing (Copperhead, Graphene, etc.) Note that it does not ensure the integrity of your data nor that your data has not been decrypted -- it's only about the system/vendor code. This is all good in theory, as long as there is an unbroken chain of trust. But when Secure Boot is not enabled, the chain of trust is broken. xbl will not verify abl, and abl may be modified by an attacker. All it takes is a root exploit or access to EDL mode. Once that happens, abl can be modified to always pass the custom key check no matter what it finds in the boot partition. Then the boot partition can be modified with any kernel of the attacker's choosing while still showing you a yellow boot state.
Now, I'm not a security guy. I am somewhat interested in security issues but I am pretty bad at spotting security flaws in code and I would never even so much as call myself a hacker. So you can be guaranteed that if I thought this out independently in less than a day, pretty much all attackers that are even halfway serious would also be aware of this. I presume this is why Copperhead and Graphene are only available for select devices, and I certainly hope that they make it known to users in big, bold print that AVB is worthless when Secure Boot is not enabled.
Now, having said all that, it is probably possible to enable Secure Boot on a Pro1 and enjoy all this security goodness. But if anything goes wrong, you'll have an expensive paper weight. Who's going to be the first to try? 😄
(*) Secure Boot is Qualcomm's implementation of the chain of trust from the lowest level of the boot loader up to the Linux kernel. It uses a key that is baked into the hardware (this was referenced a few posts ago) using a physically destructive and irreversible process. The secure boot flag itself is also stored in the same manner and, once enabled, can never be disabled on a given device.
-
2
-
-
6 hours ago, Zamasu said:
Thank you so much for the information you're posting here, it's very interesting. I do have a question about the "firmware" though, some people say that custom ROMs will lack the firmware updates that official (still supported) ROMs have, and thus can be less secure in that way. Are they talking about what you're calling the "vendor bits" for hardware support? And how out of date could these be for this ROM or LineageOS for the Pro1?
In this case, I would take "firmware" to mean everything closed source. Particularly the abl partition and the vendor bits for hardware support which occasionally have security issues.
The official Lineage policy for device maintainers is to assert on the latest firmware version from the OEM (eg. fail to install if it is out of date). Some maintainers are better than others at following through on this.
Here's an example of how this is supposed to work. I have been using OnePlus devices for the last year or so. Every time they release a new firmware, the maintainer extracts it from the package, makes a recovery flashable package out of it, and posts it for download. He also updates the vendor blobs on TheMuppets and updates the firmware version to be asserted. When I go to flash the lasted Lineage ROM on an outdated firmware, it tells me this, and I have to go through the (annoying but more secure) process of downloading the updated firmware and flashing it first.
-
2
-
-
4 hours ago, Noob said:
Thanks @tdm for this build, this is awesome. My only question is, in the absense of OTA, how feasible is it to create updated builds? And I presume there'd be no data loss on upgrade, like updating LOS?
That's entirely up to how often I get bsp updates. IdeaLTE gives updates to FxTec on request and they are passed along. So I can't just grab the latest code on demand.
Yes you can upgrade without data loss. Generally you should always be able to update the same ROM without loss. You only need to wipe when switching ROMs.
-
1
-
-
Well, this looks promising...
tommy@neuron:~$ echo x > foo tommy@neuron:~$ fastboot flash avb_custom_key foo target reported max download size of 536870912 bytes sending 'avb_custom_key' (0 KB)... OKAY [ 0.009s] writing 'avb_custom_key'... OKAY [ 0.003s] finished. total time: 0.011s tommy@neuron:~$ fastboot erase avb_custom_key erasing 'avb_custom_key'... OKAY [ 0.003s] finished. total time: 0.003s tommy@neuron:~$-
3
-
-
8 minutes ago, okayphoneme said:
There's a bit more info here:
https://source.android.com/security/verifiedboot/device-state
So your co-worker was right (the original key is permanently baked into the hardware), but you can also in theory supply another key to use. It guess this feature isn't widely implemented though (or at least, nobody cares / hasn't tried it) - supposedly OnePlus 5/5T and a Xiaomi phone in addition to Google's own devices.
Well, what do you know ... the qcom bootloader in the bsp does reference avb_custom_key. I'll have to dig more to see if it's actually enabled and usable.
Thanks!
-
2
-
Factory Restore Tool
in Support
Posted
Because it's likely going to require real time communication in order to not stretch into weeks, and I doubt there is anything at the end user level to learn from this.
I'm offering to do this for two reasons: I'm genuinely curious what is wrong with this device, and I don't feel it's right to make other people pay for your mistakes.