Related
Script pulled; should have it back up by Wednesday.
Hey guys. I've written a shell script to automate some of the more menial tasks involved with unlocking the Nexus S bootloader and rooting it. It also guides you through the various tasks involved in the process, and IMO is a more noob-friendly alternative to my guide on manually rooting.
Disclaimer again: I take no responsibility if something goes wrong (if it does, it should be fixable though), Unlocking your bootloader voids your warranty (but you can lock it back), Unlocking the bootloader will wipe your entire phone, including USB Storage; so make a copy of all those family photos and other files you may have put onto the USB storage if you want to keep them.
The script should run fine on most configurations; if you have issues post them below. The script isn't very elegant, but it gets the job done. Pay attention to the terminal as you go through it and you should be fine.
Some Notes:
- OTA updates will not flash because the modified boot.img flashed in this script causes an MD5 mismatch. You should flash the latest OTA update before running this script, if you aren't already running the latest update.
- The latest OTA update, GRH78 (2.3.1) can be found with instructions on flashing here: http://forum.xda-developers.com/showthread.php?t=884097
- You do not need root to flash OTA updates.
How to run
1. Download the attached file and rename it to 'nsrootscript.sh'
2. Mark it as executable either by navigating to it, right-clicking it, Properties > Permissions tab, and checking 'Allow executing file as program', or running this command:
Code:
chmod +x /path-to-file-here/nsrootscript.sh
3. Double-click it and choose 'Run In Terminal' or use the command:
Code:
./path-to-file-here/nsrootscript.sh
4. Follow the instructions given in the script, and you should be rooted in no time.
Special Thanks
Koush; Developer of ClockworkMod Recovery and ROM Manager. Buy him a beer here: https://www.paypal.com/us/cgi-bin/w...63663d3faee8d9384d85353843a619606282818e091d0
Paul; Developer of Superboot. Help him raise money for Cancer Research and possibly win yourself a nice gadget here: http://android.modaco.com/content/charitable-projects/317387/10k-for-p10k-for-childhood-leukemia/
If you have any issues, concerns, or comments, feel free to leave them below.
I just looked through your script. Noticed it is using superboot boot.img's to root. You might want to put a note that this will probably prevent future OTA updates from flashing, since those boot.img's are modified and will get MD5 mismatches.
Luxferro said:
I just looked through your script. Noticed it is using superboot boot.img's to root. You might want to put a note that this will probably prevent future OTA updates from flashing, since those boot.img's are modified and will get MD5 mismatches.
Click to expand...
Click to collapse
Thanks for the heads up, I'll put that in the OP.
Thanks man, looking forward to getting and trying this out
works like a charm thank you very much!
I'm sorry but I just don't see the point it rooting a DEVELOPER phone? You open up lots of features that are not available to non root so therefore make developing useless as you will lose more than half your market! I understand if you are specifically making a root application but I'm sure most of you aren't!
[/Rant]
stothy862 said:
I'm sorry but I just don't see the point it rooting a DEVELOPER phone? You open up lots of features that are not available to non root so therefore make developing useless as you will lose more than half your market! I understand if you are specifically making a root application but I'm sure most of you aren't!
[/Rant]
Click to expand...
Click to collapse
Root isn't just of interest to developers. Root allows the end user to do many interesting things, a small set:
- Applying custom themes
- Blocking annoying ads
- Take screenshots
- Set CPU clock speeds / overclock for better performance, underclock for better battery life
- Replacing system apps / files (There are various reasons for this, one example is the modified MMS.apk floating around that fixes the blurry MMS issue)
- Flash custom ROMs which can offer performance increases, battery life increases and add useful features not found in stock (CyanogenMod is a good example)
-And there's a lot more, but it's 2 AM where I live, lol.
As for people that develop applications that require root, that's because what they do (blocking ads, theming, taking screenshots, etc.), well requires root. There's no way around that. And since root is obtainable on most Android devices without too much hassle, what's the harm in coding something to make people's Android experience a little better?
Could this possibly work for our milestones? (Just a question, beginner here)
http://www.phonedog.com/2011/01/20/why-is-motorola-continuing-to-lock-bootloaders/ :
Motorola made it extra difficult – for some – to do what they wanted in terms of software and loading ROMs. Some developers got smart about this though, and an application named Droid X Recovery Bootstrap (by Koush) popped up in Android Market. This application hijacked parts of the boot process and fooled the system into thinking everything was okay. In other words, it was a workaround for Motorola's sneaky and unwelcome software. Point being, no matter how hard a company works to prevent users from loading ROMs on their Android devices or jailbreaking their iPhones, developers find a way around it. Every time. Most people are fond of Motorola's nice build quality, but not everyone is a fan of MOTOBLUR; the same could be said of HTC and Sense UI. So why not give users a choice or at least assist them in making their phone what they want it to be?
Yes, but there is an easier way to boot into recovery.
It doesn't help us at all;
http://www.koushikdutta.com/2010/08/droid-x-recovery.html
So can we now install custom ROMs?
Yes, but you can't replace the kernel or boot image. But really, once you have access to /system, anything is possible. It will just take a little hackery.
Click to expand...
Click to collapse
we don't need tht to gain access to /system. we already got access to /system thts why u can see alot of custom mods downs here. which i think is much better compared to any others custom rom as alot of our dev's are pro's and really spent alot of time to make the mods almost perfect.
We are using similar way to boot custom ROMs on Milestone for some time already.
1. sh-hijack to take over the control during the early init phase (on init)
https://github.com/nadlabak/android_system_core/commit/6c27adb5b0e33f214c48ee2411a717f6343c81b8
(hacked sh will run /system/bin/sh_hijack.sh instead of /init_prep_keypad.sh)
2. 2nd-init run from sh-hijack script, to restart the init process with custom init.rc scripts in use
https://github.com/nadlabak/android_device_motorola_umts_sholes/blob/froyo/prebuilt/bin/sh_hijack.sh
(copy init scripts from /etc/rootfs to root and run 2nd-init)
https://github.com/nadlabak/android_device_motorola_umts_sholes/blob/froyo/prebuilt/bin/2nd-init.c
(restart init)
THIS IS CURRENTLY NOT WORKING
A newer version is available here: https://forum.xda-developers.com/apps/supersu/suhide-lite-t3653855
suhide is an experimental (and officially unsupported) mod for SuperSU that can selectively hide root (the su binary and package name) from other applications.
Pros
- Hides root on a per-app base, no need to globally disable root
- Doesn't need Xposed
- Even supports SuperSU's ancient app compatibility mode (BINDSYSTEMXBIN)
- Passes SafetyNet attestation by default on stock ROMs (last officially tested on 2016.10.07)
Cons
- Ultimately a losing game (see the next few posts)
- No GUI (at the moment) - Unofficial GUI by loserskater
Requirements
- SuperSU v2.78 SR1 or newer (link)
- SuperSU installed in systemless mode
- Android 6.0 or newer
- TWRP (3.0.2 or newer, with access to /data - link!) or FlashFire (link)
Xposed
Xposed is not currently officially supported, but if you want to use it directly, you must be using @topjohnwu 's systemless xposed v86.2 exactly (attached at the bottom). It seems to mostly work during my non-extensive testing, but there are still some performance issues (both boot-time and run-time). Proceed with caution, expect bootloop.
Alternatively, there are some reports that the latest Magisk version + the latest systemless xposed (for Magisk) also works. I have not personally tested this.
CyanogenMod
I've personally tested with CM13 on i9300 without issue, however, several users are reporting it doesn't work for them. Proceed with caution, expect bootloop. Also, aside from just flashing SuperSU, you need to make sure /system/bin/su and /system/xbin/su are removed, or CM's internal root will still be used.
Usage
Install/Upgrade
- Make sure you have the latest SuperSU version flashed in systemless mode
- Make sure you are using the latest TWRP or FlashFire version
- Remove any and all Xposed versions
- If you have been having issues, flash suhide-rm-vX.YY.zip first, and note that your blacklist has been lost.
- Flash the attached suhide-vX.YY.zip
- If you are upgrading from suhide v0.16 or older, reflash SuperSU ZIP, and note that your blacklist has been lost.
- Optionally, flash the Xposed version linked above, and pray
At first install SafetyNet is automatically blacklisted.
If you have just flashed a ROM, it is advised to let it fully boot at least once before installing suhide.
Uninstall
- Flash the attached suhide-rm-vX.YY.zip. The version may appear older, the uninstall script doesn't change very often.
Blacklisting an app
You need the UID (10000 to 99999, usually 10xxx) of the app, which can be tricky to find, or the process name. There may be a GUI for this at some point.
(Note that all commands below need to be executed from a root shell)
If you know the package name, ls -nld /data/data/packagename will show the UID - usually the 3rd column.
Similarly, for running apps, ps -n | grep packagename will also show the UID - usually the 1st column.
Note that the process name is often the same as the package name, but this is not always the case. UID is more reliable for identifying a specific app, and it is also faster than blocking based on process names.
When you know the UID or process name:
Add to blacklist: /su/suhide/add UID or /su/suhide/add processname
Remove from blacklist: /su/suhide/rm UID or /su/suhide/rm processname
List blacklist: /su/suhide/list
All running processes for that UID or process name need to be killed/restarted for su binary hiding. For SuperSU GUI hiding, the device needs to be restarted. I recommend just (soft-)rebooting your device after making any changes.
Please keep in mind that many apps store their rooted state, so you may need to clear their data (and then reboot).
Integration into SuperSU
This mod isn't stable, and probably will never be (see the next few posts). As SuperSU does aim to be stable, I don't think they're a good match. But who knows, it all depends on how things progress on the detection side.
Detections
This mod hides the su binary pretty well, and does a basic job of hiding the SuperSU GUI. The hiding is never perfect, and suhide itself is not undetectable either. This will never be a perfectly working solution.
Debugging bootloops
- Get your device in a booting state
- Make sure you have TWRP or a similar recovery
- Install LiveBoot (link)
- If you are not a LiveBoot Pro user, enable the Freeload option
- Enable the Save logs option
- Recreate the bootloop
- In TWRP, get /cache/liveboot.log , and ZIP+attach it to a post here.
Download
Attached below.
Any rm version should work to uninstall any suhide version.
There may be multiple versions of suhide attached, please look carefully which one you are downloading!
YOU ARE EXPLICITLY NOT ALLOWED TO REDISTRIBUTE THESE FILES
(pre-v0.51: 17410 downloads)
Hiding root: a losing game - rant du jour
Most apps that detect root fall into the payment, banking/investing, corporate security, or (anit cheating) gaming category.
While a lot of apps have their custom root detection routines, with the introduction of SafetyNet the situation for power users has become worse, as developers of those apps can now use a single API to check if the device is not obviously compromised.
SafetyNet is of course developed by Google, which means they can do some tricks that others may not be able to easily do, as they have better platform access and control. In its current incarnation, ultimately the detection routines still run as an unprivileged user and do not yet use information from expected-to-be-secure components such as the bootloader or TPM. In other words, even though they have slightly more access than a 3rd party app, they still have less access than a root app does.
Following from this is that as long as there is someone who is willing to put in the time and effort - and this can become very complex and time consuming very quickly - and SafetyNet keeps their detection routines in the same class, there will in theory always be a way to beat these detections.
While reading that may initially make some of you rejoice, this is in truth a bad thing. As an Android security engineer in Google's employ has stated, they need to "make sure that Android Pay is running on a device that has a well documented set of API’s and a well understood security model".
The problem is that with a rooted device, it is ultimately not possible to guarantee said security model with the current class of SafetyNet tamper detection routines. The cat and mouse game currently being played out - SafetyNet detecting root, someone bypassing it, SafetyNet detecting it again, repeat - only serves to emphasize this point. The more we push this, the more obvious this becomes to all players involved, and the quicker SafetyNet (and similar solutions) will grow beyond their current limitations.
Ultimately, information will be provided and verified by bootloaders/TrustZone/SecureBoot/TIMA/TEE/TPM etc. (Samsung is already doing this with their KNOX/TIMA solutions). Parts of the device we cannot easily reach or patch, and thus there will come a time when these detection bypasses may no longer viable. This will happen regardless of our efforts, as you can be sure malware authors are working on this as well. What we power-users do may well influence the time-frame, however. If a bypass attains critical mass, it will be patched quickly.
More security requires more locking down. Ultimately these security features are about money - unbelievably large amounts of money. This while our precious unlocked bootloaders and root solutions are more of a developer and enthusiast thing. While we're all generally fond of shaking our fists at the likes of Google, Samsung, HTC, etc, it should be noted that there are people in all these companies actively lobbying to keep unlocked/unlockable devices available for us to play with, with the only limitation being that some financial/corporate stuff may not work if we play too hard.
It would be much easier (and safer from their perspective) for all these parties to simply plug that hole and fully lock down the platform (beyond 3rd party apps using only the normal APIs). Bypassing root checks en masse is nothing less than poking the bear.
Nevertheless, users want to hide their roots (so do malware authors...) and at least this implementation of suhide is a simple one. I still think it's a bad idea to do it. Then again, I think it's a bad idea to do anything financial related on Android smartphone that isn't completely clean, but that's just me.
Note that I have intentionally left out any debate on whether SafetyNet/AndroidPay/etc need to be this perfectly secure (most people do their banking on virus ridden Windows installations after all), who should get to decide which risk is worth taking, or even if Google and cohorts would be able to design the systems more robustly so the main app processor would not need to be trusted at all. (the latter could be done for Android Pay, but wouldn't necessarily solve anything for Random Banking App). While those are very interesting discussion points, ultimately it is Google who decides how they want this system to work, regardless of our opinions on the matter - and they want to secure it.
--- reserved ---
Changelogs
2016.10.10 - v0.55 - RELEASE NOTES
- Some code cleanup
- Support for blocking based on process name
- Should fix some crashes (requires uninstall/reinstall to activate)
2016.10.07 - v0.54 - RELEASE NOTES
- Fix for latest SafetyNet update
2016.09.19 - v0.53 - RELEASE NOTES
- Haploid container (monoploid)
2016.09.18 - v0.52 - see v0.51 release notes below
- Fix root loss on some firmwares
2016.09.18 - v0.51 - RELEASE NOTES
- Complete redesign
- Zygote proxying (haploid)
- Binder hijacking (diploid)
- su.d instead of ramdisk modification
- Xposed supported (-ish)
2016.09.04 - v0.16 - RELEASE NOTES
- Fix some SELinux access errors
- Should now work on devices that ask for a password/pattern/pin immediately at boot - for real this time!
- Binderjacking improvements for Nougat
2016.08.31 - v0.12 - RELEASE NOTES
- Fix some issues with suhide-add/rm scripts
- Fix not working at all on 32-bit devices
- Should now work on devices that ask for a password/pattern/pin immediately at boot
- Rudimentary GUI hiding
- No longer limited to arm/arm64 devices: support for x86/x86_64/mips/mips64 devices added
2016.08.29 - v0.01
- Initial release
As always thank you Chainfire! I will try and edit this post.
Edit @Chainfire this seems to work for enabling Android Pay! I didn't get the chance to actually pay yet. But it did let me add my card and did not display the message about a failed authorization of Android check! Before I couldn't even get past that first screen.
Edit 2: @Chainfire It seems to of had an adverse effect on Snapchat. I cleared cache on the app, uninstalled and reinstalled and restarted. It kept Force closing after a photo no matter what. I used suhide-rm and it seems to have fixed the app from any issues. Thanks again and hopefully we'll get you some more reports. Either way your solution works!
Tested on stock rooted 7.0 Nexus 6p.
@Chainfire
What was your reason for doing this project?
Sent from my Nexus 6P using XDA-Developers mobile app
Ofthecats said:
What was your reason for doing this project?
Click to expand...
Click to collapse
For building it, curious if the method I came up with would work well. For releasing, if others are doing it, join them or be left behind.
I'm assuming with custom ROM android pay still won't work right?
HamsterHam said:
I'm assuming with custom ROM android pay still won't work right?
Click to expand...
Click to collapse
I'd just give it a try. It's spoofing the specific app, not the entire ROM that matters. It's fairly simple to try.
Installed on LG G4 w/ V20g-EUR-XX update and rerooted with TWRP 3.0.2-0 and SuperSU-v2.76-2016063161323. seems to be working fine, for the moment. Thank you for the update.
So far so good, I was able to add card to android pay. I would try using it during lunch and report back. Again, thanks for the continuous hard work.
djide said:
So far so good, I was able to add card to android pay. I would try using it during lunch and report back. Again, thanks for the continuous hard work.
Click to expand...
Click to collapse
What was the UID or process you found to blacklist it with?
Sent from my ONEPLUS A3000 using Tapatalk
how to install it? which file should I flash ? Both?
I can't see to add an app using terminal.
I'm typing in
/data/adb/suhide-add 10284
Says file not found. Can someone help, cheers.
Joshmccullough said:
What was the UID or process you found to blacklist it with?
Click to expand...
Click to collapse
Android Pay comes blacklisted out-of-the-box
HamsterHam said:
I can't see to add an app using terminal.
I'm typing in
/data/adb/suhide-add 10284
Says file not found. Can someone help, cheers.
Click to expand...
Click to collapse
Are you in Android or TWRP ?
ls -l /data/adb/
Chainfire said:
Android Pay comes blacklisted out-of-the-box
Click to expand...
Click to collapse
Derp. That's what I get for not reading the entire sentence under 'Install' in the OP......thanks!
PedroM.CostaAndrade said:
how to install it? which file should I flash ? Both?
Click to expand...
Click to collapse
Please don't quote a large post like that just to ask a single question.
Please read the first post, so you know what to do.
OnePlus 2 here, stock 6.0.1, systemless rooted with SuperSU Pro v2.76, flahed using Flashfire.
Passes SafetyNet check, does not pass my bank's root check, propably for the reasons the OP states above.
thdervenis said:
OnePlus 2 here, stock 6.0.1, systemless rooted with SuperSU Pro v2.76, flahed using Flashfire.
Passes SafetyNet check, does not pass my bank's root check, propably for the reasons the OP states above.
Click to expand...
Click to collapse
You need to blacklist the UID for your bank. Directions are in the OP.
Hi everyone,
I have a Sony Z3 compact I just received, model D5803 running Android 6.0.1 with Firmware 23.5.A.0.575.
I really dislike Google and want to run a phone with the minimum of proprietary software (I guess blobs to communicate with the hardware are mandatory). I guess AOSP (any version, but a recent one would be better ) with F-Droid is a good solution.
Unfortunately when checking the sony website but it tells my the bootloader is not unlockable. What should I do? I'm running Ubuntu and have adb and fastboot installed.
I found [this topic](https://forum.xda-developers.com/z3-compact/general/recovery-root-mm-575-lb-t3418714) which tells it roots the phone (and has a GNU/Linux script) but how does that help me to install a Rom, for example the AOSP provided by Sony at /open-devices/list-of-devices-and-resources/ if the bootloader is still locked? What are TWRP and busybox, is that supposed to help?
Flaburgan said:
I found [this topic](https://forum.xda-developers.com/z3-compact/general/recovery-root-mm-575-lb-t3418714) which tells it roots the phone (and has a GNU/Linux script) but how does that help me to install a Rom, for example the AOSP provided by Sony at /open-devices/list-of-devices-and-resources/ if the bootloader is still locked? What are TWRP and busybox, is that supposed to help?
Click to expand...
Click to collapse
TWRP is a custom recovery that allows you to flash a ROM and other files, that are stored on the normal internal or external storage.
Busybox is a binary that gives you command line tools that are often included in a Linux install and some of which aren't included on normal Android. These are commands that other things may make use of, or that you can make use of at a terminal app or run from Tasker or similar app.
You want to look at backing up your TA partition, which stores your DRM keys, before unlocking the bootloader to install a custom ROM because some functionality, camera quality and anti-distortion, sound quality, and some other stuff which I don't remember, won't work if you go back to the stock ROM unless you have these keys backed up and then restored later. You need to unlock the bootloader in order to flash a custom ROM and doing this erases, permanently, these DRM keys, so they need to be backed up and then put back later if you relock the bootloader and flash a stock ROM.
If you look in the Original Development section, Jaguar Aries ROM has no Google Apps, had the latest patches up to Febuary, and had the best battery life of any custom ROM I've seen for this phone, right on par with stock. There are some builds of Lineage OS that are probably closer to being up to date as well and may have a better camera than Jaguar. The developer of Jaguar has moved on to another phone. That said, if you aren't experienced and don't know what TWRP is, then installing it is an extra step from other ROMs as well since it requires you to setup a firewall app to permit connections on data or wifi before you can use the wifi or data at all. I doubt Lineage OS has this, but presume that battery life would not be good.
Also, if you install microg apps, you can still use things such as cell and wifi based location, google push services, and ... I don't remember what else, however it hasn't been updated recently and many apps will complain and refuse to run saying that you need to update google play services, especially annoying for anything that uses push especially. Microg essentially sits in the place of where some functionality of Google Apps would and fills in some blanks.
When you don't have Google Apps installed, many paid apps will refuse to run as well, specifically the ones you paid for, because they can't verify the purchase with Google servers. There should be a **** list for any developers that don't cooperate when this is a problem for a user. I've only had one app developer help me on this, ever.
Thanks for your detailed answer!
You need to unlock the bootloader in order to flash a custom ROM and doing this erases, permanently, these DRM keys, so they need to be backed up and then put back later if you relock the bootloader and flash a stock ROM.
Click to expand...
Click to collapse
Does that mean that I can't use the DRM keys with another ROM? So I will never have the full quality of my hardware? Would using the AOSP rom provided by Sony solve that problem?
On which version of Android Jaguar Aries ROM is based? I searched for a lineageOS image but didn't find any for the Z3 Compact.
I had another z3c which died and was running Firefox OS, I'm fine with not having access to the Google Play store, I plan to install F-Droid and use only FOSS apps. In fact I would even prefer to go back to Firefox OS even if it is not maintained anymore, its UX is so much better than Android... That said, thanks for telling me about Microg, I didn't know it and that's true that many apps use Play services especially for push. Even Signal had that as a dependency (fortunately not anymore). Still, I would avoid any data coming out from my phone to by sent to Google servers, so I will probably avoid it.
Flaburgan said:
Thanks for your detailed answer!
Does that mean that I can't use the DRM keys with another ROM? So I will never have the full quality of my hardware? Would using the AOSP rom provided by Sony solve that problem?
On which version of Android Jaguar Aries ROM is based? I searched for a lineageOS image but didn't find any for the Z3 Compact.
I had another z3c which died and was running Firefox OS, I'm fine with not having access to the Google Play store, I plan to install F-Droid and use only FOSS apps. In fact I would even prefer to go back to Firefox OS even if it is not maintained anymore, its UX is so much better than Android... That said, thanks for telling me about Microg, I didn't know it and that's true that many apps use Play services especially for push. Even Signal had that as a dependency (fortunately not anymore). Still, I would avoid any data coming out from my phone to by sent to Google servers, so I will probably avoid it.
Click to expand...
Click to collapse
When you unlock the bootloader the DRM keys get erased permanently, so you'd need to root the phone and back up the partition where they are held before unlocking it. As far as I know, every custom ROM needs to have the bootloader unlocked. If there is an alternative way to install a ROM on a locked bootloader then it would be one of those scenarios where its installed while keeping the stock one, and I don't know if this has been done on the Z3c or not.
I also don't know if Sony's AOSP requires unlocking the bootloader or not.
Jaguar is based on 5.1.1
Its a mix of AOSP, Lineage, and was getting monthly backports of the latest security patches until Febuary when the developer no longer had a Z series phone for his own use. The only criticism it met was that the developer never released the source code for the entire ROM, just the kernel. He never replied to why that was. A lot of the custom ROMs out there are like this, so its still a case of who you choose to trust when it comes to this a lot of times. I liked it because the battery life was really good and assuming the security was what was advertised then that was also a real plus.
Many apps, by the way, were working fine with microg push but then with updates to apps, they complained about needing to update google services framework, which obviously was spoofed and microg hasn't been updated, and it happened to a lot of apps in a short period of time, so I assume there was a change enforced by Google for their requirements in the Play Store. If you just want it for location, for example if you use Osmand maps, then you don't have to enable the feature for push notifications nor have a google account associated with the phone, and it all works as user installed apps, so it can be undone without any real fear of the system getting modified after you try it out. There's a microg repo that can be added to fdroid. The location is based on either databases you download to the phone, which aren't very good, or also you can opt for cell location from Mozilla servers, and if you have to have wifi based location as well then you can hook into the Apple servers but the latter doesn't sound like something you want, if you want to do any of it at all that is.
I think most likely that GPS location would work without any need for microg.
The post you linked to with the Linux script installs TWRP to the /data partition, then you root it, then you back up the DRM keys after its rooted, then unlock the bootloader, install normal TWRP, and go from there. In Linux you'lle want to use the dd command to back up the DRM keys as all that's available on the forum is a Windows script (I think). There is info on it somewhere but it would be hard to find it. If you search my posts the thread will come up somewhere in the history. Anyway, the reason I broght this up is because the script in the thread for installing TWRP and rooting didn't work properly. I don't remember why, but I had to go through it line by line and enter the commands in from a termnial to get it right, I think there was some bad syntax. If you can't figure it out, quote one of my posts and ask, that way I get a notification that I was replied to, I think I have a fixed version of it on my drive somewhere if it causes a problem.
For the DRM keys you want to backup the TA partition bit for bit to a file. I backed up my Fota partition as well as I was unclear what role it plays. You also want to keep a copy of that particular Sony ROM file, and the two kernels involved, to flash with Flashtool in case you relock and restore so you can get root access to restore the partition while the bootloader is locked again.
May I ask why are you going FOSS only? if that's because privacy concerns, then FF OS is not the best solution... Because any Cloud-based OS is a little bit creepy, doesn't matter if it's ChromeOS from Google, or FirefoxOS from Mozilla.
There are plenty of Linux distros dedicated to run on Android phones, but it's not the best UX.
And yes, you can enjoy clean AOSP install (LOS is fine) without flashing G-Apps. But you won't have Google play at all! F-Droid is fine but you won't find there Gmail alternatives, you can't find Gmail even on Amazon AppStore... Sadly if you install Gmail then you'll find out that it installed bunch of google apps and hidden services behind the scenes... So only option is to use Gmail web app.
But then again, F-Droid is fine, there are many FOSS alternatives to youtube and other apps.
And if privacy (and security) is your concern, use LOS privacy guard / Android's builtin Permission Manager, and on Rooted ROMs you can use AFwall firewall which is the best.
Good luck
GadgetAvi said:
Because any Cloud-based OS is a little bit creepy, doesn't matter if it's ChromeOS from Google, or FirefoxOS from Mozilla.
Click to expand...
Click to collapse
Firefox OS is not a Cloud-based OS at all. It runs perfectly without internet connection.
GadgetAvi said:
F-Droid is fine but you won't find there Gmail alternatives, you can't find Gmail even on Amazon AppStore...
Click to expand...
Click to collapse
Be sure that if I don't want Google on my phone, my e-mails are already **not** on GMail...
Ok, if so, then you'll be fine with any AOSP clean rom. LOS is great, and F-Droid as well. Cheers!
PantsDownJedi said:
The post you linked to with the Linux script installs TWRP to the /data partition, then you root it, then you back up the DRM keys after its rooted, then unlock the bootloader, install normal TWRP, and go from there. In Linux you'lle want to use the dd command to back up the DRM keys as all that's available on the forum is a Windows script (I think).
Click to expand...
Click to collapse
I ran the commands and the phone is now booted on TWRP from the /data partition. I did a backup with TWRP of all proposed options (Boot, TrimArea, Recovery, System, Cache and Data). Is that "TrimArea" enough to have a backup of the DRM keys? The other topic talks about Backup-TA but looking at their github https://github.com/DevShaft/Backup-TA/releases it looks very old and unmaintained.
The current TWRP I'm running is 3.1.0-0.
Also, it looks like I'm not root (at least, su is not available). Do I have to install SuperSu by giving this zip https://download.chainfire.eu/696/supersu/ to TWRP?
Flaburgan said:
I ran the commands and the phone is now booted on TWRP from the /data partition. I did a backup with TWRP of all proposed options (Boot, TrimArea, Recovery, System, Cache and Data). Is that "TrimArea" enough to have a backup of the DRM keys? The other topic talks about Backup-TA but looking at their github https://github.com/DevShaft/Backup-TA/releases it looks very old and unmaintained.
The current TWRP I'm running is 3.1.0-0.
Click to expand...
Click to collapse
I don't know. I haven't looked at a TWRP backup to see what format it is. Back when Clockwork Mod was all that was available, it merely made a tar.gz of partitions. Ideally you want a bit for bit image of the TA partitions to make sure it was exactly what it was when you restore it. I don't know if that's necisarry, or if TWRP does this anyway, but using the dd command is still prudent.
You want to either use a terminal emulator app or run 'adb shell' at a linux terminal (much easier), run 'su' once in the phone environment, allow it at the phone supersu app popup, and then do it like this.
https://forum.xda-developers.com/showpost.php?p=61307511&postcount=6
And store a copy of the image file where it won't get lost.
Edit: Sorry, I didn't see the other post. Yes, you need to flash that supersu zip file. When you try to access root from an app or the command line, it will have a popup on the phone screen asking you if you want to allow access or not, so when you run it from a terminal, 'adb shell' to get into the phone OS, there will be a popup for allowing that often times. Then 'su' there's a popup from the supersu app you just flashed. Then 'cd' to the sdcard or external sd. Then the 'dd' command. The dd command in what I linked to is inevitbaly what all those .bat files in the Windows TA Backup thing does after it does a bit of looking around to find the TA partition for a particular phone model.
The md5sum part of what I linked to compares the partitionn itself to the image file you just wrote, you just look at it to see that there are two of them (that it didn't fail) and that they are the same.
The last part pulls the image file to the hard drive, but there are other ways to accomplish this obviously. If you have a cloud storage you can upload it there, or send it as an email attahment, put it on the external sd, etc etc.
Also, in many cases, once you unlock the bootloader to flash something else, you'lle need to install TWRP again from the command line, pushing it straight to a phone partition. You'lle need help with this if you haven't done it before.
What is this tutorial?
This tutorial will:
Creating an unofficial build of LineageOS 17.1 suitable for using to re-lock the bootloader on a OnePlus 6/6t
Take you through the process of re-locking your bootloader after installing the above
This tutorial will NOT:
Remove *all* warning messages during boot (the yellow "Custom OS" message will be present though the orange "Unlocked bootloader" message will not)
Allow you to use official builds of LineageOS 17.1 on your device with a re-locked bootloader (more details near the end of the tutorial)
This tutorial will assume you are working on an Ubuntu 18.04 installation, if you are using Windows or another Linux distro, the commands may be different.
Supported devices:
Current both the OnePlus 6 (enchilada) and 6t (fajita) have been tested, but newer phones should work as well.
For simplicities sake, all further references will only be to the 6t (fajita).
Pre-requisites:
a mid level knowledge of terminal commands and features
a supported phone
a PC with enough CPU/RAM to build LineageOS 17.1 (recommended 8 cores, 24g of RAM)
a working USB cable
fastboot/adb installed and functional
LineageOS 17.1 source code downloaded
at least one successful build of LineageOS
at least one successful signing of your build with your own keys
Misc. notes:
the basics of building/signing of LineageOS is outside the scope of this tutorial, refer to the LineageOS Wiki for details on how to complete these tasks
you'll be modifying some code in LineageOS, so if you are not comfortable using basic editing utilities as well as patch, do not proceed any further
the path to your LineageOS source code is going to be assumed to be ~/android/lineageos, if it is somewhere else, substitute the correct path in the tutorial
the path to your private certificate files is going to be assumed to be ~/android-certs, if it is somewhere else, substitute the correct path in the tutorial
*** WARNING ****
This process may brick your device. Do not proceed unless you are comfortable taking this risk.
*** WARNING ****
This process will delete all data on your phone! Do not proceed unless you have backed up your data!
*** WARNING ****
Make sure you have read through this entire process at least once before attempting, if you are uncomfortable with any steps include in this guide, do not continue.
And now on with the show!
Step 1: Basic setup
You need a few places to store things, so create some working directories:
Code:
mkdir ~/android/fajita
mkdir ~/android/fajita/oos
mkdir ~/android/fajita/images
mkdir ~/android/fajita/images_raw
mkdir ~/android/fajita/patches
mkdir ~/android/fajita/pkmd
You also need to add "~/android/lineageos/out/host/linux-x86/bin" to your shell's profile path. Make sure to close and restart your session afterwards otherwise the signing will fail later on with a "file not found" error message .
Step 2: Download the latest OxygenOS from OnePlus
Go to https://www.oneplus.com/support/softwareupgrade and download the latest OOS update, store it in ~/android/fajita/oos
Step 3: Extract the vendor.img from OOS
Run the following commands to extract the vendor.img from OOS:
Code:
cd ~/android/fajita/oos
unzip [oos file name you downloaded] payload.bin
cd ../images_raw
python ~/android/lineageos/lineage/scripts/update-payload-extractor/extract.py --partitions vendor --output_dir . ../oos/payload.bin
You should now have a ~1g file named vendor.img in the images_raw directory.
Step 4: Update fajita's BoardConfig.mk
You will need to add a few parameters to the end of ~/android/lineageos/device/oneplus/fajita/BoardConfig.mk, they are:
Code:
BOARD_PREBUILT_VENDORIMAGE := /home/<userid>/android/fajita/images_raw/vendor.img
AB_OTA_PARTITIONS += vendor
BOARD_AVB_ALGORITHM := SHA256_RSA2048
BOARD_AVB_KEY_PATH := /home/<userid>/.android-certs/releasekey.key
Note you cannot use "~"" in the path names above to signify your home directory, so give the full absolute path to make sure the files are found.
Step 5: Update sdm845-common's BoardConfigCommon.mk (optional)
LineageOS by default disables Android Verified Boot's partition verification, but you can enable it now as all the required parts will be in place. However, you may not want to if you intend to make other changes to the system/boot/vendor partitions (like Magisk, etc.) after you have re-locked the bootloader.
To enable partition verification do the following:
Code:
cd ~/android/lineageos/devices/sdm845-common
sed -i 's/^BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS += --flag 2/#BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS += --flag 2/' BoardConfigCommon.mk
Step 6: Patch the AOSP/LineageOS releasetools
Two releasetools included with LineageOS need to be patched as they otherwise will not properly process a pre-built vendor.img.
The required patches can be found here:
https://raw.githubusercontent.com/W.../source/add_img_to_target_files.py-17.1.patch
https://raw.githubusercontent.com/W...r/source/sign_target_files_apks.py-17.1.patch
Download both and store in ~/android/fajita/patches.
Now apply them with the following commands:
Code:
cd ~/android/lineageos/build/tools/releasetools
patch add_image_to_target_files.py ~/android/fajita/patches/add_image_to_target_files.py-17.1.patch
patch sign_target_files_apks.py ~/android/fajita/patches/sign_target_files_apks.py-17.1.patch
Step 7: Build LineageOS
You are now ready to build:
Code:
cd ~/android/lineageos
source build/envsetup.sh
croot
breakfast fajita
mka target-files-package otatools
Step 8: Prepare vendor.img
As part of the build process above, your raw vendor.img will been copied to the $OUT directory and a new hashtree (what AVB uses to verify the image) will have been added to it.
You need to use this new version in the signing process but due to how the build system works, this is not done by default.
So, let's put it where it is needed:
Code:
cp $OUT/obj/PACKAGING/target_files_intermediates/lineage_fajita-target_files-eng.*/IMAGES/vendor.img ~/android/fajita/images
Step 9: Sign the APKs
You are now ready to sign the apks with sign_target_files_apks:
Code:
./build/tools/releasetools/sign_target_files_apks -o -d ~/.android-certs --prebuilts_path ~/android/fajita/images $OUT/obj/PACKAGING/target_files_intermediates/*-target_files-*.zip signed-target_files.zip
Note the new "--prebuilts_path" option, which points to where your new vendor.img file is located.
Step 10: Build the OTA
Now it is time to complete the OTA package:
Code:
./build/tools/releasetools/ota_from_target_files -k ~/.android-certs/releasekey --block signed-target_files.zip lineage-17.1-[date]-UNOFFICIAL-fajita-signed.zip
Note, replace [date] with today's date in YYYYMMDD format.
Step 11: Create pkmd.bin for your phone
Before you can lock your phone, you have to tell it what your public key is so it knows it can trust your build.
To do this you need to create a pkmd.bin file:
Code:
~/android/lineageos/external/avb/avbtool extract_public_key --key ~/.android-certs/releasekey.key --output ~/android/fajita/pkmd/pkmd.bin
Step 12: Flashing your LineageOS build
It's time to flash your build to your phone. The following steps assume you have already unlocked your phone and have flashed an official version of LineageOS to it. You don't need to have flashed LineageOS yet, you could use TWRP through "fastboot boot" if you prefer.
Reboot your phone in to recovery mode
In LineageOS Recovery select "Apply update"
From your PC, run:
Code:
adb sideload ~/android/lineageos/lineage-17.1-[date]-UNOFFICIAL-fajita-signed.zip
When the sideload is complete, reboot in to LineageOS. Make sure everything looks good with your build.
You may also need to format your data partition at this time depending on what you had installed on your phone previously.
Step 13: Flashing your signing key
Now it's time to add your signing key to the Android Verified Boot process. To do so, do the following:
Reboot your phone in to fastboot mode
From your PC, run:
Code:
fastboot flash avb_custom_key ~/android/fajita/pkmd/pkmd.bin
fastboot reboot bootloader
fastboot oem lock
On your phone, confirm you want to re-lock and it will reboot
Your phone will then factory reset and then reboot in to LineageOS.
Which of course means you have to go through the first time setup wizard, so do so now.
Step 14: Disable OEM unlock
Congratulations! Your boot loader is now locked, but you can still unlock it again using fastboot, so it's time to disable that as well.
Unlock you phone and go to Settings->About phone
Scroll to the bottom and find "Build number"
Tap on it you enable the developer options
Go to Settings->System->Advanced->Developer options
Disable the "OEM unlocking" slider
Reboot
Step 15: Profit!
Other things
The above will build a standard USERDEBUG version of LineageOS, however this will still allow LineageOS Recovery to sideload non-signed files. If you have implemented step 5 above, then this protects your system/vendor/boot/dtbo partitions, but none of the others. Likewise USERDEBUG builds will allow for rolling back to a previous version. To increase security and disallow both of these scenarios you may want to build a USER version of LineageOS to install. However this brings in other issues, such as flashing newer firmware from OnePlus so make sure you understand the implications of both choices. For more details on build types, see https://source.android.com/setup/develop/new-device#build-variants.
In the above example the releasekey from your LineageOS install has been used to sign AVB, but AVB supports other key strengths up to SHA512_RSA8192. You could create a key just for signing AVB that used different options than the default keys generated to sign LineageOS.
If you want to remove you signing key from your phone, you can do it by running "fastboot erase avb_custom_key".
The changes you made to the make files and releasetools may conflict with future updates that you pull from LineageOS through repo sync, if you have to reset the files to get repo sync to complete successfully, you'll have to reapply the changes afterwards.
So why can't I do this with official LineageOS builds?
For Android Verified Boot (AVB) to work, it must have the hash values for each of the system/vendor/boot/dtbo partitions stored in vbmeta. Official LineageOS builds do not include the vendor.img in them (for fajita at least, other phones may), instead simply using the existing partition on the phone.
That means that there is no vendor.img information in vbmeta for the official builds, which means AVB will fail to verify it during boot and give the red corruption message and halt the boot process after you have re-locked the bootloader.
And since you cannot add to vbmeta without the LineageOS private key, which only the LineageOS signing server has, you cannot add it.
This means you must do a full build with new signing keys to make it work.
Theoretically you could pick apart a LineageOS release, rehash the system/vendor/boot/dtbo and then recreate vbmeta and the payload.bin file, but that brings a host of other issues. For example, since such a "build" would look like a full LinageOS release, if you ever accidentally let the updater run it would brick (soft) that slot and you'd have swap back to your other slot to boot again. In an extreme case, if you managed to corrupt the second slot somehow you'd have to wipe your entire and recover from the brick with one of the available tools to do so.
Ok, what messages do I see during the boot process then?
During a boot you will of course see the standard OnePlus power up screen, followed by the yellow "custom os" message an then the stardard LineageOS boot animation.
For more details on AVB boot messages, see https://source.android.com/security/verifiedboot/boot-flow
So what do those two patches to the release tools do?
AOSP/LineageOS's add_image_to_target_files.py detects if a vendor.img file already exists, and if so, simply includes it in the build process. The patch adds one extra step, so that AVB is being enabled for the build, it will replace the existing hashtree on vendor.img using the same salt and other options as will be used on system/boot/dtbo. This ensure that when vbmeta is generated, it has the right information from vendor.img.
The script is called from the make system as part of the "mka target-files-package otatools" and the appropriate parameters from the make system, like "BOARD_PREBUILT_VENDORIMAGE", are used to create arguments to the script to build the standard image files as well as include the prebuilt vendor.img.
This script is used both during the initial build as well as the signing process, but this change is only targeted at the build time implementation. During signing, the script uses whatever hashtrees are in place and does not regenerate them.
AOSP/LineageOS's sign_target_files_apks.py is responsible for signing the APKs that have been built as part of "mka target-files-package otatools", unfortunately it is not part of the "make" system, so settings like "BOARD_PREBUILT_VENDORIMAGE" do not impact the script. This means that sign_target_files_apks.py does not have any knowledge that it should be including a pre-built vendor.img, even though it is in the $OUT directory waiting to be used.
The patch adds a new parameter to the script (--prebuilts_path), so that during the signing process, any image files found in the provided path, will be included in the process. So make sure that only vendor.img is in the provided directory. This is a directory instead of a single file as future uses may be to include things like firmware, other partition types, etc. in to the signing process.
Thank you's
Obviously to all of the members of the LineageOS team!
LuK1337 for supporting fajita
optimumpro for the OnePlus 5/5t re-locking guide (https://forum.xda-developers.com/oneplus-5/how-to/guide-relock-bootloader-custom-rom-t3849299) which inspired this one
Quark.23 for helping with the process and testing on enchilada
Nice , Will this enable widewine L1?
jsidney96 said:
Nice , Will this enable widewine L1?
Click to expand...
Click to collapse
I don't believe there is a connection between the two.
WhitbyGreg said:
I don't believe there is a connection between the two.
Click to expand...
Click to collapse
If you unlock bootloader on phones supporting L1 they drop to L3. I know some Oneplus phones (op6 etc.) did not support L1 even on stock.
cowgaR said:
If you unlock bootloader on phones supporting L1 they drop to L3. I know some Oneplus phones (op6 etc.) did not support L1 even on stock.
Click to expand...
Click to collapse
Yeah.. It brings it to L1
Great writeup @WhitbyGreg
As Android security gets tighter and tighter, hoping one day all ROMs would support AVB by default..
---------- Post added at 06:16 PM ---------- Previous post was at 05:48 PM ----------
Curious question here,
WhitbyGreg said:
*** will build a standard USERDEBUG version of LineageOS, however this will still allow LineageOS Recovery to sideload non-signed files. If you have implemented step 5 above, then this protects your system/vendor/boot/dtbo partitions, but none of the others. Likewise USERDEBUG builds will allow for rolling back to a previous version. To increase security and disallow both of these scenarios you may want to build a USER version of LineageOS to install. However this brings in other issues, such as flashing newer firmware from OnePlus so make sure you understand the implications of both choices***
Click to expand...
Click to collapse
After a launch of any phone, how drastic are such firmware updates to bother about? In other words, Unless we're in stock ROM is it mandatory to update phone firmware?
arvindgr said:
Yeah.. It brings it to L1
Click to expand...
Click to collapse
Good to know.
arvindgr said:
Great writeup @WhitbyGreg
As Android security gets tighter and tighter, hoping one day all ROMs would support AVB by default..
Click to expand...
Click to collapse
That would be nice but more importantly, more phones need to support re-locking.
arvindgr said:
Curious question here,
After a launch of any phone, how drastic are such firmware updates to bother about? In other words, Unless we're in stock ROM is it mandatory to update phone firmware?
Click to expand...
Click to collapse
Reasonably important, after all, if you never get firmware updates you'll have outdated security patching for the firmware. Some official LOS builds require newer versions of the firmware as they are released and won't install without it.
This guide was very helpful to me when re-locking my Oneplus 7T and enabling hash/hashtree verification. A dude on telegram had actually sent me the link and I only briefly skimmed over. Ironically when looking for patches to fix my issues after attempting to include pre-built vendor/odm and failing I cross referenced and ended up back here.
Here's where I originally found them:
https://review.lineageos.org/c/LineageOS/android_build/+/278015
https://review.aosip.dev/c/AOSIP/platform_build/+/13385
I myself have made some more patches to ensure every possible pre-built image gets signed on my builds. After some experimentation I have found it possible to have Magisk with hash verification enabled
https://github.com/Geofferey/omni_android_build/commits/geofferey/android-10
There is also a fix to ensure appropriate args get passed when regenerating hashtree for pre-built vendor.
Geofferey said:
This guide was very helpful to me when re-locking my Oneplus 7T and enabling hash/hashtree verification.
Click to expand...
Click to collapse
So you can confirm you have relocked the bootloader on the 7T with AVB enabled?
Geofferey said:
A dude on telegram had actually sent me the link and I only briefly skimmed over. Ironically when looking for patches to fix my issues after attempting to include pre-built vendor/odm and failing I cross referenced and ended up back here.
Here's where I originally found them:
https://review.lineageos.org/c/LineageOS/android_build/+/278015
https://review.aosip.dev/c/AOSIP/platform_build/+/13385
Click to expand...
Click to collapse
Yes, those are my patches that I've submitted to LOS, I also have two other patches submitted to allow for other prebuilt images (aka firmware images) to be included in the build process.
Geofferey said:
I myself have made some more patches to ensure every possible pre-built image gets signed on my builds. After some experimentation I have found it possible to have Magisk with hash verification enabled
https://github.com/Geofferey/omni_android_build/commits/geofferey/android-10
There is also a fix to ensure appropriate args get passed when regenerating hashtree for pre-built vendor.
Click to expand...
Click to collapse
I'll take a look and see if I need to update any of my submissions, thanks.
I will have to update those commits with you as author. I messed that up and set person who picked yours as author. I am sorry. BTW thank you for those patches they were a lifesaver and inspired me.
Yes, I can confirm re-lock with AVB enabled on 7T works and also with hash verification. If I flash an image not signed by the build process with hash verification enabled I go red. Currently I am working on getting magisk directly integrated with build instead of using prebuilt patched imgs that cause builds to not pass CTS.
Geofferey said:
Currently I am working on getting magisk directly integrated with build instead of using prebuilt patched imgs that cause builds to not pass CTS.
Click to expand...
Click to collapse
Why do you want to put Magisk if you went to all the trouble of having avb with a locked bootloader? Isn't rooting defeating the purpose of avb?
quark23 said:
Why do you want to put Magisk if you went to all the trouble of having avb with a locked bootloader? Isn't rooting defeating the purpose of avb?
Click to expand...
Click to collapse
No, it does not defeat the purpose... Hashtree verification will still happen since root can be included in the build as opposed to flashing after the fact. In a way it's actually even more advised. The way I think, having root may lead to a means of being exploited but true AVB closes the door to any persistent rootkits that may try to modify partitions at block level. If ANYTHING modifies the verified partitions phone will refuse to boot and I will be protected. Doing exactly what AVB is supposed to do, verify the phone is in it's intended state. I also think of phone as a computer, you have root access on Linux, Windows and even Mac for Christ sake, why shouldn't it be the same for phones? The ONLY reason we don't by default is so manufacturers and carriers can stay in control. I've been rooting and modifying phones for years without AVB and yet to have a known breech of my data besides the Google apps constantly collecting on me. This just adds another level of security that I used to sacrifice in order to have root access.
Here is my PoC to include Magisk in builds so dm-verity can be kept enabled. Just two commits. If someone could make this better that would be really cool.
https://github.com/Geofferey/omni_android_build/commit/d60958780e6b26d7cb0cec5939b82df3df74a68f
https://github.com/Geofferey/android_vendor_magisk
I have rooted for testing and you don't gen any warning. The way avb works on my phone is it discards any modification after reboot. With no warning at boot time. If you get hacked, you can have persistent hacks with root. Make a modification from twrp with avb enabled and see for yourself.
You break the Android security model by rooting the phone. If you need certain things you can include them at build time, such as a custom hosts file.
Also, what can you do with root that does not alter the hashtree?
The power you mention is of no real use yet you expose yourself by having it. Sure, you can go by without any issues. The problem is if you happen to get hacked, the attacker has full control over your phone. You won't br able to get rid of it by rebooting.
Also I see no way for google to collect data in this setup, with or without root. Afwall has an equivalent in android 10 (that mobile data & wifi setting) and inter process comms are the real issue if you are worried about rogue apps. Afwall leaks dns requests like crazy anyway.
I say you are better off letting root go and include what you need at build time. I see that as better spent effort than trying to add root.
quark23 said:
I have rooted for testing and you don't gen any warning. The way avb works on my phone is it discards any modification after reboot. With no warning at boot time. If you get hacked, you can have persistent hacks with root. Make a modification from twrp with avb enabled and see for yourself.
Click to expand...
Click to collapse
So you built your ROM from source with root included, had TWRP go through signing and was able to modify system and other partitions without receiving a device corrupt message? I highly doubt AVB is even implemented appropriately if you were able to do so. If it is implemented it sounds like the old version, tho I remember if I violated FS too much it wouldn't be able to fix and failed to boot. Having a locked bootloader because AVB is enabled does not mean dm-verity is enabled. Also, it should be nearly impossible to just write things like files to /system or w.e. if you are on a device that ships with 10.
quark23 said:
You break the Android security model by rooting the phone. If you need certain things you can include them at build time, such as a custom hosts file.
Click to expand...
Click to collapse
I know it does, but I am not doing such small things as modifying a host file. The kinds of things I include in my personal ROMs require such a high level of access to the point where I can not write SE polices that will allow me to pass CTS and spit out user builds without serious modifications to the build env.
quark23 said:
Also, what can you do with root that does not alter the hashtree?
The power you mention is of no real use yet you expose yourself by having it. Sure, you can go by without any issues. The problem is if you happen to get hacked, the attacker has full control over your phone. You won't b able to get rid of it by rebooting.
Click to expand...
Click to collapse
The act of flashing Magisk is what breaks AVB, if you include it in the ROM at build time like I am doing then it doesn't need to be flashed. It makes modifications to the system by binding data from the wipeable data partition to /system/. If something utilizes that to install a backdoor or tunnel it goes bye-bye when I wipe. If something utilizes it to flash anything or modify system device no boot.
quark23 said:
Also I see no way for google to collect data in this setup, with or without root. Afwall has an equivalent in android 10 (that mobile data & wifi setting) and inter process comms are the real issue if you are worried about rogue apps. Afwall leaks dns requests like crazy anyway.
Click to expand...
Click to collapse
You're kidding right? Android solely exist as a mean for Google to collect data. That was the whole idea behind Android. Buy & develop an OS that any manufacturer can put on their device, let them certify for Google Play Services and collect the data that powers their ad platform. They certainly didn't opensource their baby for free. If you allow ports 80 and 443 out with inbound related allowed, that's all they need.
quark23 said:
I say you are better off letting root go and include what you need at build time. I see that as better spent effort than trying to add root.
Click to expand...
Click to collapse
I'd just rather the manufactures and Google would implement a root solution that plays nice with Androids security instead of making us resort to violating it. It's funny to me that we find it acceptable for these fools to maintain control of something you purchased with your hard earned dollars because they think we are too stupid to have it. Like I stated root and admin privileges are fully available to us on nearly any PC but phones for some reason are an exception.
_________________________________________________
I could rant and debate about this forever... Fact of matter is, you don't have to disable every Android security feature to have root.
I didn't build with magisk, I just flashed after building.
But you can try and modify anything on /system or /vendor from twrp, without magisk, without locking the bootloader, and see what happens. Avb discards the modification, but doesn't warn you. Curious of your findings regarding this. If you then flash magisk, you ofc break the hashtree and avb and the mods remain persistent.
I understand that you are building with magisk included in the hashtree. What I am wondering is what exactly are you wanting root for? What are you doing with root that does not break the hashtree?
Regarding the data collection, you lost me. What exactly is being collected on a LOS userbuild without google services? Got any dns logs or mitm wireshark packets to show? What service exactly is collecting what kind of data? Google's dns servers can be replaced before building, Greg has some scripts for that. Captive portal can also be replaced or turned off. Apart from that, and any apps you add yourself, what kind of data is being collected as I want to check it out myself. I've monitored my phone and it's pretty silent. Whatever goes out is from additional apps I use. But I don't see anything from LOS. Really curious about this.
Regarding your last point I think it's something akin to risking shooting yourself in the foot by having root by default. I understand (somewhat) the security model and I find it smart to not have it by default. Also Android uses selinux more than your standard linux distro does. There are some differences in the security models between android and pc linux distro.
I'm really hapoy that AOSP exists. Also pretty happy with the LOS project. My problem is with the outdated blobs. Maybe I'll get a Pixel at some point and give GrapheneOS a go. Seems like a really nice project.
Managed to get hardened malloc + Vanadium on LOS atm and I'm liking the browser. Overall I think AOSP is a great project. Not a fan of google's privacy policy but they do make great stuff.
quark23 said:
I understand that you are building with Magisk included in the hashtree. What I am wondering is what exactly are you wanting root for? What are you doing with root that does not break the hashtree?
Click to expand...
Click to collapse
Ah, there lies the real question. I am including in my personal builds a Debian Linux chroot that gets extracted to /data/ so I can run Linux services, etc. I have customized the chroot with Openvpn so that it connects to my server and essentially allows me back into device wherever it may lay. Basically I am adding in the stuff of nightmares that all this security is supposed to prevent. That is why I want dm-verity, because I know I am leaving my self partially open by doing so. I have a decent understanding of dm-verity and have confirmed that it does and will protect me against the scenarios I imagine. BTW it operates completely differently in locked state vs. unlocked.
quark23 said:
Regarding the data collection, you lost me. What exactly is being collected on a LOS userbuild without google services?
Click to expand...
Click to collapse
Well, if you're the type of person who doesn't require Google Play Services, nothing of course. I was merely stating that Google had open sourced Android in hopes that manufacturers would adopt the OS and qualify their devices for Google PS so that it could be used as a data collection platform. You won't easily see all the information Google collects in a Wireshark log because it is encrypted of course. LOS better be silent as hell without it or I'd contact that dev with a strongly worded message lmfao.
quark23 said:
Regarding your last point I think it's something akin to risking shooting yourself in the foot by having root by default. I understand (somewhat) the security model and I find it smart to not have it by default. Also Android uses selinux more than your standard linux distro does. There are some differences in the security models between android and pc linux distro.
Click to expand...
Click to collapse
Oh I DO NOT think it should just be enabled by default. If I had my way it would be enabled in dev ops requiring authentication and protected via a different password than the one you use to unlock the device once setup. You'd also require those "root" privileges to OEM unlock once enabled. While those features were enabled you'd be warned on boot as well but without locking you out of apps etc because that kind of sensitive data should be handled by TEE and TZ. In a real Linux operating system that hasn't been fundamentally raped to offer a false sense of security in the name of protecting carriers and manufactures you can modify SE linux policies etc, not while live but without compiling from source. A lot of us forget most these security features exist more to protect their interest and attempt to hide what's going on behind the scenes. I've actually heard of some pretty shady stories where manufacturers in China place ad-tappers that run in background on devices running GooglePS to be sold in US, so it definitely doesn't protect you if the person building your phone is shade.
quark23 said:
I'm really hapy that AOSP exists. Also pretty happy with the LOS project. My problem is with the outdated blobs. Maybe I'll get a Pixel at some point and give GrapheneOS a go. Seems like a really nice project.
Managed to get hardened malloc + Vanadium on LOS atm and I'm liking the browser. Overall I think AOSP is a great project. Not a fan of google's privacy policy but they do make great stuff.
Click to expand...
Click to collapse
Me too mate. . AOSP has taught me a lot about development and coding in general. Sadly outdated blobs are a usually a by-product of using pre-builts from manufacturers that don't update as often. Pixel would be way to go if that's a concern. I honestly just think a lot of the security is abused to suit their needs. I am just trying to turn it around to work for me where it can.
If you repo sync you should run the vendor files script as there's a couple of new files added. The Muppets github has been updated with them as well. If you don't your build will fail at first power on.
A quick question, forgive me if this is obvious: am I correct in assuming that one the above has been completed and the device is using a locally-built copy of Lineage OS, that I cannot take advantage of OTA updates? I just want to know what I'm getting in to before wiping my phone multiple times.
Thanks in advance, this thread is massively helpful.
nictabor said:
A quick question, forgive me if this is obvious: am I correct in assuming that one the above has been completed and the device is using a locally-built copy of Lineage OS, that I cannot take advantage of OTA updates? I just want to know what I'm getting in to before wiping my phone multiple times.
Thanks in advance, this thread is massively helpful.
Click to expand...
Click to collapse
Correct, though if you setup your own update server you can still use the inbuilt updater app if you want.
I just happened across this thread searching for a proper way to generate the custom avb key. I thought i had found it at one time on aosp documentation but i lost/forgot where it was.
Anyways, I have a quick q about this. Would I be correct in assuming that if i wanted gapps to be available in my build, I would need to include it during build time and not be able to flash it as per the typical methods?
I am pretty sure I won't be able to but wanted to ask here for you guys' experiences.
Also, @WhitbyGreg you should be able to i believe. just setup the url properly and host it somewhere with direct download links. (This also requires setup of json for the updater to monitor for updates)
klabit87 said:
Would I be correct in assuming that if i wanted gapps to be available in my build, I would need to include it during build time and not be able to flash it as per the typical methods?
Click to expand...
Click to collapse
Correct (at least as far as I know), once the bootloader is relocked any modification of the system partition (like adding the play services) would trigger an AVB failure.