Related
I'm really looking for an app that I can use to SSHFS essentially, so that I can sorta' use a mounted remote dir as an extension of my phones storage, much like you would do in normal, every-day linux.
Is there such a thing? To date, I have not been able to find anything...
You would first need to get Fuse working with the kernel. If/once we can boot custom kernels, it's possible one might ship with Fuse enabled but according to
http://groups.google.com/group/android-kernel/browse_thread/thread/096dda136ce772cb
stock does not have Fuse. Stock does support modules though and I'm fairly sure you can compile Fuse as a module. You'd need to get ahold of the Droid 3 stock kernel source, cross compile a module for Arm and try and get it to not kernel panic the phone. Once you have Fuse in there, it shouldn't be too bad to build a copy of sshfs.
In the mean time, I have found https://market.android.com/details?id=nextapp.fx to be an incredible file manager that support SSH, SMB, and FTP. The only thing missing would be root.
Anyway, I think Fuse support would be awesome but don't have time to work on it at the moment. Do we have the D3 kernel source somewhere?
Naex said:
You would first need to get Fuse working with the kernel. If/once we can boot custom kernels, it's possible one might ship with Fuse enabled but according to
http://groups.google.com/group/android-kernel/browse_thread/thread/096dda136ce772cb
stock does not have Fuse. Stock does support modules though and I'm fairly sure you can compile Fuse as a module. You'd need to get ahold of the Droid 3 stock kernel source, cross compile a module for Arm and try and get it to not kernel panic the phone. Once you have Fuse in there, it shouldn't be too bad to build a copy of sshfs.
In the mean time, I have found https://market.android.com/details?id=nextapp.fx to be an incredible file manager that support SSH, SMB, and FTP. The only thing missing would be root.
Anyway, I think Fuse support would be awesome but don't have time to work on it at the moment. Do we have the D3 kernel source somewhere?
Click to expand...
Click to collapse
Yes, D3 source has been released. There's a thread on it here on XDA in the dev section. Thank's for the info!
I am not responsible for any possible bad effects which may result from using included software! You flash it on your own risk!!!
STOCK RELOADED v1 fix 1
Kernel base: stock XXUANC3 (kernel 3.4.0-1131235)
Kernel ramdisk: modded
Features: a few...
Security level: low!
Purpose: giving everyone who loves free exploring of Android secrets and who doesn't consider security as an absolute priority and who wants to put some life in this, indeed, awesome device, a possibility of playing with his device without disturbing restrictions, forced by Samsung, at least until fully-custom kernels, compiled from sources, appear (and that may take some time, as source code available atm seems to be broken, causing all the compiled kernels to stuck at boot screen).
Features working out-of-the-box:
- su binary from SuperSU by Chainfire @ /sbin/su (binary only for scripting purposes! Flash cf-root to use SuperSU app!)
- busybox 1.22.1 binary compiled by Stericson @ /sbin/busybox
- init.d support - just put your favorite scripts into /system/etc/init.d using any file manager and chmod 755 (not 777! it's NOT smart to permit write access for "world" to any system file), chown root:root, they will run on every boot. Well, to be honest, above permissions are given to all the scripts automatically during boot, but it has not yet been tested
- SELinux: Permissive - Samsung's most recent policy of forcing SELinux Enforcing mode by pre-compiling it into a kernel binary part, found in latest KitKat builds since at least a few months, HACKED FOR THE FIRST TIME EVER using innovative method of injecting an information directly into kernel memory space and forcing overwriting potentially-persistent kernel symbol value on-line during boot!)
- unsecure adb access (not tested yet)
- ext4 tweak: 20 sec (instead of stock 5 sec) write commit delay for /data partition (significantly increases IO performance!)
- some further, minor modifications
WARNING!!!
- flashing this WILL undoubtly trip KNOX, avoiding your warranty (which atm cannot be reverted! in any way)
- flashing this WILL cause a warning message of avoided warranty to be displayed on every boot (ofc it disappears right after reverting to stock boot.img)
- flashing this WILL disable some of the very important security features provided with stock firmware!!!! For advanced and experienced users only!!! Use at your own risk!
Known issues:
- AllCast Share mirroring not working (typical for all Samsung devices running not-exactly-stock kernels since S3). WORKING FIX AT POST #16!!!
http://forum.xda-developers.com/showpost.php?p=54516532&postcount=16
Please consider solution from post #3 as not-always-working and depreciated!
Installation:
- compatibile with XXUANC3 firmwares but probably also with other (past and hope future too...) KitKat 4.4.2 Samsung branded firmwares;
- rooting by Chainfire's CF-Root first recommended as it will install SuperSU app in Android (this kernel contains su binary only giving su access without any policy settings!);
- enter download mode and plug the tablet via USB...
- ...select provided file in PDA section (and NOT touch anything except that)...
- ...and flash with Odin in a same way as CF-Root or like anything else...
- enjoy.
DOWNLOAD HERE:
Current version - STOCK RELOADED v1 fix 1
http://www63.zippyshare.com/v/87557346/file.html
FIXED: file name changed so it can be flashed directly by Odin without renaming! Sorry for this silly mistake!
=======
Changelog:
v1 fix1:
- fixed permissive mode due to trivial error;
- delayed init.d execution to a moment AFTER init process set cfq scheduler so it is not overriding mmcblk0 tweaks (if put in init.d) anymore;
- minor code cleanups
v1:
- initial release
- init.d support
- SELinux permissive
- unsecure ADB
- ext4 delayed commit for /data
=======
Stock XXUANC3 kernel (to revert changes)
http://www65.zippyshare.com/v/32441894/file.html
Revert using Odin, in the same way you've installed a Reloaded Version....
Awww man,...I wish i could flash this, but I'm on the exynos =(
Sent from my SM-P900 using Tapatalk
rgolnazarian said:
Awww man,...I wish i could flash this, but I'm on the exynos =(
Sent from my SM-P900 using Tapatalk
Click to expand...
Click to collapse
Sorry pal, Qualcomm only, not even a chance to run this same way as the devices (and mostly important: provided software, ie. system structure) DIFFER A LOT between themselves.
Update 1: uploaded fix #1 which is resolving some trivial issues found in initial version; sorry for that, now we can say that every described feature has been included hope for some feedback... thank you...
Update 2: FIX FOR NOT WORKING SCREEN MIRRORING CAN BE DOWNLOADED HERE:
http://www67.zippyshare.com/v/25492738/file.html
I have personally modified a library that is being used by screen mirroring feature, which forces video encryption using keys from stock kernel, and which prevents to run mirroring at all . This is an issue of any modified kernel, on any Samsung device. Attached library fixes this, by disabling HDCP at all. It has been reported that the library resolves the issue for any Qualcomm based Samsung device running 4.4.2 KitKat and for any custom kernel. It will NOT work for Exynos devices...
Installation:
- download attached libwfdsm.so file
- overwrite genuine one in/system/vendor/lib (important! NOT /system/lib!!!!)
- chmod 644 libwfdsm.so ||| chown 0.0 libwfdsm.so ||| restorecon -R /system/vendor/lib
- mirroring will work again after reboot!!
YAY!
Beautiful, absolutely beautiful. You made ma a very happy man with this. I'll flash this as soon as I get home from work. Can't wait to try it out, the stock kernel is giving me SOD and frozen wifi issues sometimes.
esgie said:
Sorry pal, Qualcomm only, not even a chance to run this same way as the devices (and mostly important: provided software, ie. system structure) DIFFER A LOT between themselves.
Update 1: uploaded fix #1 which is resolving some trivial issues found in initial version; sorry for that, now we can say that every described feature has been included hope for some feedback... thank you...
Update 2: FIX FOR NOT WORKING SCREEN MIRRORING CAN BE DOWNLOADED HERE:
http://www67.zippyshare.com/v/25492738/file.html
I have personally modified a library that is being used by screen mirroring feature, which forces video encryption using keys from stock kernel, and which prevents to run mirroring at all . This is an issue of any modified kernel, on any Samsung device. Attached library fixes this, by disabling HDCP at all. It has been reported that the library resolves the issue for any Qualcomm based Samsung device running 4.4.2 KitKat and for any custom kernel. It will NOT work for Exynos devices...
Installation:
- download attached libwfdsm.so file
- overwrite genuine one in/system/vendor/lib (important! NOT /system/lib!!!!)
- chmod 644 libwfdsm.so ||| chown 0.0 libwfdsm.so ||| restorecon -R /system/vendor/lib
- mirroring will work again after reboot!!
Click to expand...
Click to collapse
I was literally just about to post in the old thread with bad news about the modified "libwfdsm.so" file & screen mirroring with a custom kernel...if u remember i confirmed that the file u altered would work with a custom recovery on the 8.4 lte & i just assumed that it would work with an altered boot.img as well but unfortunately thats not the case after testing the other night (unless something else is wrong with my setup). So...my question is have u changed something else since then to allow it to work again & have u personally tested this yourself?
sorry to hijack the thread...didnt know if i should pm or post in the older thread
THEDEVIOUS1 said:
I was literally just about to post in the old thread with bad news about the modified "libwfdsm.so" file & screen mirroring with a custom kernel...if u remember i confirmed that the file u altered would work with a custom recovery on the 8.4 lte & i just assumed that it would work with an altered boot.img as well but unfortunately thats not the case after testing the other night (unless something else is wrong with my setup). So...my question is have u changed something else since then to allow it to work again & have u personally tested this yourself?
sorry to hijack the thread...didnt know if i should pm or post in the older thread
Click to expand...
Click to collapse
No problem, anyway, thanks for pointing the issue out! This may be an important information for mirroring users!
Since then I didn't change anything, yet. Really, I am also not sure if I have tested it with modified kernel, as the one posted here is the first kernel for P905 at all, and it's not even "fully" customized, as the kernel binary base was left unchanged.
So, I'd like to be sure: you are saying that modded lib:
- fixed the problem for custom recovery, but...
- ...didn't fix it for custom kernel
right?
I was looking for a solution to persistent enforcing mode since some time, so I was flashing test boot.imgs from time to time, then reverting to stock again, meanwhile I created above lib, I can't really be sure about if it is working when both bootimg and kernel are customized (this would also be an opposite to previous Sammy's Android releases, where a single fix was solving all the issues related to customizations of both kernel and recovery!).
We also have to be aware that the issues may not be a result of flashing different kernel at all, but a result of the changes themselves, ie. disabled knox, disabled encryption of i-dont-really-know-what, etc, etc.
And the most important thing! Since I have heard of AllShareCast/Screen Mirroring for the first time (it probably appeared for the first time in S3/Note2/Note10.1), it always required resetting the flash counter - which could be viewed in download mode and which is NOT the same as Knox flag - to ZERO and that requirement AFAIR remained totally independent from the requirement of having stock boot/kernel (or lib patch). Have you checked the counter state? Did you reset it to zero again using Chainfire's Triangle Away after flashing non-stock kernel (which, obviously, TRIPPED the counter)? Can you check if it is working? Note that at least on my P905, Triangle Away still works flawlessly and resets the counter without any problems and even without a need of reboot!
Please check above info and try if the issue is fixed after running Triangle Away. I am leaving for a short business trip soon, so I'll perform my own tests with AllShare cast until next of the week, however, neither today nor tomorrow...
I get an "md5 error! binary is invalid" when I choosse the file in Odin. I downloaded the file 6 times, and every time I get the md5 error.
What do I do?
EDIT: Renaming the file to "boot.tar.md5" seemed to solve the problem.
cavkic said:
I get an "md5 error! binary is invalid" when I choosse the file in Odin. I downloaded the file 6 times, and every time I get the md5 error.
What do I do?
EDIT: Renaming the file to "boot.tar.md5" seemed to solve the problem.
Click to expand...
Click to collapse
Argh possibly too many dots in filename... will correct it tomorrow.
cavkic said:
I get an "md5 error! binary is invalid" when I choosse the file in Odin. I downloaded the file 6 times, and every time I get the md5 error.
What do I do?
EDIT: Renaming the file to "boot.tar.md5" seemed to solve the problem.
Click to expand...
Click to collapse
same here...
Hi,
I have a problem with screen mirroring.
Installed the patch and mirroring connects to the dongle, but the TV screen turns just black.
The dongle works perfect with HTC One M8, it must be a softwareproblem?
Thanks for help!!!
Will this work on the P905V (Verizon Variant)? I need to downgrade the permissions in my Security in order to use Towelroot, because they're set to Medium and I believe that prevents Towelroot to work properly. Most of the other Note 12.2 variants have been rooted....except the Verizon version.
Can anyone give me some advice please. When I enter the command in terminal emulator I get an error saying "Unable to open chown. No such file or directory". Am I missing something obvious lol.
Will this work on p907a AT&T version of note pro 12.2?
Sent from my SAMSUNG-SM-P907A using XDA Premium 4 mobile app
cnote74 said:
Will this work on p907a AT&T version of note pro 12.2?
Sent from my SAMSUNG-SM-P907A using XDA Premium 4 mobile app
Click to expand...
Click to collapse
On the topic name it says [P905 LTE ONLY], and your device is some different..
tdetroit said:
Will this work on the P905V (Verizon Variant)? I need to downgrade the permissions in my Security in order to use Towelroot, because they're set to Medium and I believe that prevents Towelroot to work properly. Most of the other Note 12.2 variants have been rooted....except the Verizon version.
Click to expand...
Click to collapse
I would like this answered as well. I also have the "v" variant. Maybe saying LTE includes many? See my link I attached, found while investigating this specific question.
http://www.usatoday.com/story/tech/2013/07/07/sprint-att-verizon-phones-network-carriers/2486813/
Ever since I rooted my tablet it goes on random reboot kicks. I want to start over. Also TWRP will not stick when I try to flash it.
I have many issues which I'm currently posing in their appropriate forums. It would be nice to wipe to a rooted stock.
Guys!
I have probably found another solution for non-working Screen Mirroring / AllShare Cast when custom kernel is flashed (again, LTE devices only).
No need of modded lib
Seems that the only thing we need is to
1) run Terminal Emulator and type:
Code:
su -c setprop wlan.wfd.hdcp disable
(will work immediately; won't stick between reboots!), OR...
2) edit /system/build.prop file with any root file manager/text editor and add a line (no matter where):
Code:
wlan.wfd.hdcp=disable
(will work only after reboot; will stick between reboots).
Try this using kernel from op waiting for feedback!
Thanks. The Galaxy is connecting to theTV, but the screen is only turning black - no Display...
Any idea?
Thank you.
esgie said:
Guys!
I have probably found another solution for non-working Screen Mirroring / AllShare Cast when custom kernel is flashed (again, LTE devices only).
No need of modded lib
Seems that the only thing we need is to
1) run Terminal Emulator and type:
Code:
su -c setprop wlan.wfd.hdcp disable
(will work immediately; won't stick between reboots!), OR...
2) edit /system/build.prop file with any root file manager/text editor and add a line (no matter where):
Code:
wlan.wfd.hdcp=disable
(will work only after reboot; will stick between reboots).
Try this using kernel from op waiting for feedback!
Click to expand...
Click to collapse
esgie said:
Guys!
I have probably found another solution for non-working Screen Mirroring / AllShare Cast when custom kernel is flashed (again, LTE devices only).
No need of modded lib
Seems that the only thing we need is to
1) run Terminal Emulator and type:
Code:
su -c setprop wlan.wfd.hdcp disable
(will work immediately; won't stick between reboots!), OR...
2) edit /system/build.prop file with any root file manager/text editor and add a line (no matter where):
Code:
wlan.wfd.hdcp=disable
(will work only after reboot; will stick between reboots).
Try this using kernel from op waiting for feedback!
Click to expand...
Click to collapse
I tried both methods and still get no devices found when I turn on screen mirroring.
ColBill said:
I tried both methods and still get no devices found when I turn on screen mirroring.
Click to expand...
Click to collapse
Hm.
This is weird, as the problems with allshare cast + custom kernels is not that "no devices are found" but that devices ARE found without any problem but the connection process fails after a few secs. This solution may help with the issue i described, but it will surely not solve the problem with no peers detected at all.
No peers detected = problems with wifi direct (are you able to send files between wifi direct between devices?)
Can you tell me what is your exact device config? And are you using allsharecast dongle or other third party hardware?
@fokus
Only one: also reset flash counter with Triangle Away and then try again. And make sure you spell the value in the command as "disable" not "disabled" - it's tricky and one can miss it...
Well, there are two additional things to add.
Guys, make sure you have updated Samsung's ScreenMirroring firmware update app to the latest version. And check out the samsung mirroring fix app in google play, which solves some issues for various devices (dunno which ones exactly as i have never been in need of using it).
The fix half worked for me lol. The tablet now connects fine to the Netgear PTV3000 but all I get is black screen. Step in the right direction though as at least it connects now. Just need to get a picture to show lol.
After a bit of tinkering and some insight from Chainfire and imoseyon i was finally able to get SuperSU working on AOSP roms without being permissive or having to use Chainfire's prebuilt sepolicy
sepolicy patch is here: https://github.com/PureNexusProject...mmit/0f5072de4580a5db7348917e77e4c1c35d3e3c1a
Stickied.
sorry to be that guy, but how does this affect the average joe?
does it mean theres going to be a new version of supersu with this or does this mean that custom rom makers can use this patch to make there roms not need the the custom boot.img?
WarningHPB said:
sorry to be that guy, but how does this affect the average joe?
Click to expand...
Click to collapse
It doesn't, this is for ROM devs only, they know what to do with this.
Chainfire said:
It doesn't, this is for ROM devs only, they know what to do with this.
Click to expand...
Click to collapse
Welcome back! Hope you had a good break.
Chainfire said:
Stickied.
Click to expand...
Click to collapse
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
BeansTown106 said:
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
Click to expand...
Click to collapse
There is no such thing now as "all current root apps working".
If SuperSU's deamon can be launched, and it can in turn launch the supolicy tool, most of the rules from the diff will be modified by SuperSU as needed.
What your patch needs to do (and you have already done) is make sure SuperSU can be launched in the right context, and can modify the sepolicy. You do not need to implement those 300+ additions - it will be done at boot automagically.
As for those additions themselves, they are primarily needed to:
- make sure SuperSU can work, internal communications between the different processes and such
- make processes running as the "init" context (where root apps run by default) as powerful as possible
- specifically "allow" a number of things that would otherwise still work, but would be logged (everything that starts with "allow init" or "allow recovery")
Now, even with the above, still not everything works out of the box. Everything that goes from "init" to "non-init" context should already work, but going from "non-init" context to "init" may not. In your example case, we go from "logd" to "init", which isn't specifically allowed. Often apps can be fixed to work around an issue such as this.
Generally speaking, the solution is not to fix the source sepolicy or the supolicy tool, the solution is for the "logcat extreme" app to run the following at launch (as documented in How-To SU):
Code:
supolicy --live "allow logd init fifo_file { read write }"
In this specific case, maybe it could be added to supolicy, it depends on what exactly generates the audit. If it's a simple logcat command, it's a candidate for inclusion. The problem might even be solved by switching contexts rather than modifying any SELinux policies. But that is something for the app developer to figure out.
In either case, it is not something you need to fix in the AOSP patches. Those already do what they need to do.
Since they started doing SELinux Enforcing though, the policies in AOSP have generally been a tad stricter than on retail devices (this was specifically the case during 4.4 days). This may lead to you sometimes having to add/remove a rule manually somewhere that was not added to SuperSU yet. It could happen, but it's unlikely, probably temporary, and it probably should not go into this AOSP patch.
A note on pof's sediff, I'm not sure it was done cleanly, as I see some modifications in there that are not done by supolicy. Either way, such a post is informative, not leading, as supolicy may do more or less modifications depending on various runtime variables (such as Android version). Additionally, due to context names and availabilities changing between Android versions, any rule modification referencing a context not available in the to-be-patched sepolicy will not be applied, and thus will not show up in an sediff.
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Chainfire said:
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Click to expand...
Click to collapse
thanks for the description above now i understand. have never developed a root app so i had not read that part of how to su, but it makes perfect sense that the root apps would handle the denials live via your supolicy
as for system less root i have not tried that yet but i will give it a shot tonight, and report back, i know some people in my ROM thread have used system less root. but i am not sure if you had packaged your sepolicy in the install script for 2.61+ and if it is overwriting mine in the kernel, if that is the case i will modify the installation to not patch the sepolicy and see if it works with my pre compiled one based on the source above
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Chainfire said:
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
Click to expand...
Click to collapse
will build and test with only load policy enabled, is this for system, and systemless root?
danieldmm said:
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Click to expand...
Click to collapse
updated link, so your saying systemless supersu works with no selinux modifications?
BeansTown106 said:
updated link, so your saying systemless supersu works with no selinux modifications?
Click to expand...
Click to collapse
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
danieldmm said:
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
Click to expand...
Click to collapse
that is why, these patchs are to allow you to run in enforcing
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Garzla said:
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Click to expand...
Click to collapse
Try the following. It works for me when needed...
http://forum.xda-developers.com/showthread.php?t=3574688
Thank you for your work!
Link in OP its no longer working...
Is there any actual guide how to add SU directly to AOSP build. I have found bits and pieces but those are mainly 4.x releases.
I'm using Android M release and quite much struggling to get it working.
I have tried to make SU default on AOSP 6.0 by using this guide.
http://forum.khadas.com/t/gapps-and-su-on-soc/118/3
I'm using user build and enabled selinux permissive on that.
i have made also ro.secure=0 ro.debuggable=1 and security.perf_harden=0 (Not sure if needed)
I have also modified to change the su permissions in fs_config.c
I managed to get this work so that when flashing rom SuperSu ask for updating su binary and after that su works.
but i then cleaned work area to verify build by deleting out dir and recompiled. No go anymore.
Why it's so hard to add su by default on AOSP rom. I woud like to have it by default so i would not need to do any tricks everytime i flash new rom.
It reminds me of Korean dramas ,
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.
Working ebuild for installing postmarketos on the Amazon Fire 7 HD (2017) codename Austin
Amazon Fire 7 (2017) postmarketOS Armv7l Mediatek MT8127 Mali-450MP4 600x1024 display 1GB RAM Linux 3.10.54
What seems to work:
Boot Touch screen Battery percentage Usb internet OTG usb Wayland, Mate, Xfce4, Lxde, Sxmo, i3wm
Does NOT work:
Wifi & Bluetooth (no drivers) GPU acceleration (drivers do not work) Audio Sleep and fully turning off the display Screen rotation Wifi adapter does not work even with drivers and kernel support, mobo support issue(?) FDE Cameras You tell me
Special options: *Must be flashed to USERDATA partition as system partition is too small
msm-fb-refresher packaged is added to the depends to make the screen refresh. After flashing the device must be booted into recovery once. From the recovery it is to be powered off and booted and then as normal. This is because the device depends on the AMONET exploit which is applied by twrp after every flash.
Flashing Instructions
This assumes that you already have linux installed and the bootloader on the tablet is unlocked. Don't worry if it looks complicated. If you are unsure of something ask on the postmarketos matrix or leave a comment for help.
Install pmbootstrap as stated in the postmarketos wiki, does not matter which options or device you pick.
Once that is done download and drag the two folders in the git repo into "/home/YOURUSER/.local/var/pmbootstrap/cache_git/pmaports/device/testing/" also displayed as "~/.local/var/pmbootstrap/cache_git/pmaports/device/testing".
Run pmbootstrap init and select amazon as manufacture and austin as the device, mate, lxde, xfde, are confirmed working.
Run pmbootstrap install
Boot into twrp and wipe all partitions including data
Boot into the hacked bootloader from the twrp options
Run pmbootstrap pmbootstrap flasher flash_rootfs --partition userdata (system partion is too small to flash!) and once it is done flashing run pmbootstrap flasher flash_kernel
Unplug the device, wait 10 seconds and then hold the power button. Once it is powered on YOU MUST boot it into twrp at least once as it needs to restore the AMONET exploit, until you do that the device will not boot.
Issues
If something does not work such as the display rotated wrong or device not booting just comment or open an issue, I changed the rotation of the display in the kernel options to horizontal but i did not test the effects as I already have android with books on it.
Reinstall android/lineage
Simple as cake, just boot into twrp wipe all partions(some will fail), you may need to resize and fix until it starts working. You just need the system and data partitions to be reformated to ext4 even if they already are. Then just flash the lineageos zip file and reboot the device normally(amonet is fine)
GitHub - GjergjiFloychi/amazon-austin-pmaports: Working ebuild for installing postmarketos on the Amazon Fire 7 HD (2017) codename Austin
Working ebuild for installing postmarketos on the Amazon Fire 7 HD (2017) codename Austin - GitHub - GjergjiFloychi/amazon-austin-pmaports: Working ebuild for installing postmarketos on the Amazon ...
github.com
This looks promising, nice job. I will try installing it on my Austin during the next days.
Rortiz2 said:
This looks promising, nice job. I will try installing it on my Austin during the next days.
Click to expand...
Click to collapse
Good luck. Tell me if the display works if you do install it. Thanks
hexdump0815 cleaned up the config file, use his fork if you are going to install.
Is it wifi working? It'll awesome
Baonks81 said:
Is it wifi working? It'll awesome
Click to expand...
Click to collapse
Unfortunately the drivers for this SOC are nonexistent so nothing works. WIfi and hdmi adapters don't work, but OTG does. Hexdump made a Debian and Ubuntu image for this tablet, it is great but the tablet is mostly useless without WiFi and GPU support. You can also flash the main image to the userdata partition instead of using an SD Card, but if I remember correctly the rootfs won't auto extend. It would have been great to use this as a linux tablet, however this SOC is uncommon and is not supported by any Linux maintainer. https://github.com/hexdump0815/imagebuilder/releases/tag/211101-02
Fandroid Tech said:
Unfortunately the drivers for this SOC are nonexistent so nothing works. WIfi and hdmi adapters don't work, but OTG does. Hexdump made a Debian and Ubuntu image for this tablet, it is great but the tablet is mostly useless without WiFi and GPU support. You can also flash the main image to the userdata partition instead of using an SD Card, but if I remember correctly the rootfs won't auto extend. It would have been great to use this as a linux tablet, however this SOC is uncommon and is not supported by any Linux maintainer. https://github.com/hexdump0815/imagebuilder/releases/tag/211101-02
Click to expand...
Click to collapse
Thanks for new information. I'll searching around
I think we can find firmware it out on /dev/mmcblk---
Baonks81 said:
Thanks for new information. I'll searching around
I think we can find firmware it out on /dev/mmcblk---
Click to expand...
Click to collapse
I looked at the firmware dump on github, it is all proprietary and seems to be compatible only on android. The closest I got to getting working wifi was moving the original libs and networkmanager bin to linux however it only showed wifi working for a few seconds without detecting anything.
I'm working on this device right now. I just downloaded the repository below, and I will make a pull/merge request upstream soon.
Fandroid Tech said:
GitHub - GjergjiFloychi/amazon-austin-pmaports: Working ebuild for installing postmarketos on the Amazon Fire 7 HD (2017) codename Austin
Working ebuild for installing postmarketos on the Amazon Fire 7 HD (2017) codename Austin - GitHub - GjergjiFloychi/amazon-austin-pmaports: Working ebuild for installing postmarketos on the Amazon ...
github.com
Click to expand...
Click to collapse
I have my own fork of the pmaports repository at https://gitlab.com/Worldblender/pmaports, where I will push your files (eventually with my changes) to. Maybe we can work together on getting this tablet supported upstream, if you still want to (anything else that isn't working, like the Wi-Fi/Bluetooth, will have to come later).
UPDATE: Well, I'm going to use https://github.com/hexdump0815/pmaports-amazon for the config now, didn't notice it the first time around. I also noticethat it's possible to get Wi-Fi working with https://github.com/hexdump0815/imagebuilder-firmware/blob/main/tablet_amazon_austin-firmware.tar.gz, that I will try out with my builds soon.
From https://github.com/hexdump0815/imagebuilder/tree/main/systems/tablet_amazon_austin:
wifi seems to work by using the android firmware and tools in a minimal android bionic chroot env
wifi can be stated via /scripts/start-wifi.sh
uncomment the start of this script in /etc/rc.local in case wifi should be enabled by default
wifi support was added in february 2022, so all images from before do not have it yet but it can be added easily afterwards
Click to expand...
Click to collapse
Worldblender said:
I'm working on this device right now. I just downloaded the repository below, and I will make a pull/merge request upstream soon.
I have my own fork of the pmaports repository at https://gitlab.com/Worldblender/pmaports, where I will push your files (eventually with my changes) to. Maybe we can work together on getting this tablet supported upstream, if you still want to (anything else that isn't working, like the Wi-Fi/Bluetooth, will have to come later).
UPDATE: Well, I'm going to use https://github.com/hexdump0815/pmaports-amazon for the config now, didn't notice it the first time around. I also noticethat it's possible to get Wi-Fi working with https://github.com/hexdump0815/imagebuilder-firmware/blob/main/tablet_amazon_austin-firmware.tar.gz, that I will try out with my builds soon.
From https://github.com/hexdump0815/imagebuilder/tree/main/systems/tablet_amazon_austin:
Click to expand...
Click to collapse
You could package the wifi hack into an Alpine Linux for firmware package if you want. Debian 11 runs really well, to bad we can't get everything working.
Fandroid Tech said:
You could package the wifi hack into an Alpine Linux for firmware package if you want. Debian 11 runs really well, to bad we can't get everything working.
Click to expand...
Click to collapse
Will work on that soon. I just got a build to boot today, and basic functionality seems to be working. I'm going to try a different distro for accessing more functionality (likely Ubuntu 20.04 or 22.04) I just opened up a merge request at https://gitlab.com/postmarketOS/pmaports/-/merge_requests/3251 for the progress on upstreaming.
I'm thinking about using the exact same kernel that the LineageOS image uses:
https://github.com/cm14-mt8127/device_amazon_mt8127-common
https://github.com/cm14-mt8127/kernel_amazon_mt8127-common
This kernel has been updated to 3.10.108, and it's the last one for the 3.10 branch. I'm going to try creating a new build using this kernel, and see how it goes.
Worldblender said:
I'm thinking about using the exact same kernel that the LineageOS image uses:
https://github.com/cm14-mt8127/device_amazon_mt8127-common
https://github.com/cm14-mt8127/kernel_amazon_mt8127-common
This kernel has been updated to 3.10.108, and it's the last one for the 3.10 branch. I'm going to try creating a new build using this kernel, and see how it goes.
UPDATE: Three patches would not apply successfully for this kernel:
fix-host-card-inserted.patch
silence-power-logspam.patch
silence-thermal-logspam.patch
After building without these patches, the kernel boots, but it stays stuck without being able to process further, with some kernel messages displayed. I wonder what I should do to get this kernel working, or if this one shouldn't be used.
Click to expand...
Click to collapse
Use any kernel you want. It literally does not matter as it cannot be mainliner in the future anyways. It makes no difference what you use.
Fandroid Tech said:
Use any kernel you want. It literally does not matter as it cannot be mainliner in the future anyways. It makes no difference what you use.
Click to expand...
Click to collapse
Here's my results after building and boot it:
There are some kernel messages that pop up, and the splash screen never appears. It doesn't matter whether there is a microSD card inserted or not; there seems to be too many changes made to it from 3.10.54 to 3.10.108, along with additional changes that are designed more for Android/LineageOS usage. Finding every one of them is too much work for me.
Three patches would not apply successfully for this kernel:
fix-host-card-inserted.patch (will apply successfully once the entry for line 271 is removed)
silence-power-logspam.patch
silence-thermal-logspam.patch
Again, after building without these patches, the kernel boots, but it stays stuck without being able to proceed further, with some kernel messages displayed. I tried building without any of the patches shipped, but the end result is still the same. I need some help as to what what I should do to get this kernel working, or else I will go back to the 3.10.54 kernel that I know is actually booting to the splash screen. Here, I don't care whether I use a mainline kernel here, since I know the SOC is not supported by mainline. I simply care that I can get a newer kernel version working (from 3.10.54 to 3.10.108), unless there's too many changes for me to go through.
Worldblender said:
Here's my results after building and boot it:
There are some kernel messages that pop up, and the splash screen never appears. It doesn't matter whether there is a microSD card inserted or not; there seems to be too many changes made to it from 3.10.54 to 3.10.108, along with additional changes that are designed more for Android/LineageOS usage. Finding every one of them is too much work for me.
Three patches would not apply successfully for this kernel:
fix-host-card-inserted.patch (will apply successfully once the entry for line 271 is removed)
silence-power-logspam.patch
silence-thermal-logspam.patch
Again, after building without these patches, the kernel boots, but it stays stuck without being able to proceed further, with some kernel messages displayed. I tried building without any of the patches shipped, but the end result is still the same. I need some help as to what what I should do to get this kernel working, or else I will go back to the 3.10.54 kernel that I know is actually booting to the splash screen. Here, I don't care whether I use a mainline kernel here, since I know the SOC is not supported by mainline. I simply care that I can get a newer kernel version working (from 3.10.54 to 3.10.108), unless there's too many changes for me to go through.
Click to expand...
Click to collapse
Just use the stock 3.10.54 kernel. Both versions have long since been EOL. It does not matter what is used as functionality will still the same, both now and any future development. I would not bother upgrading the kernel to 3.10.108. Hexdump told me a while back that somebody else maintaining a similar soc on the mainline branch told him that mainlining the device is almost impossible due to some proprietary components by Amazon. I am not entirely sure as to the validity of this claim but I think that it is not worth the effort of upgrading the kernel of this device. Check this page for more info, I found it to be very helpful to my port. https://wiki.postmarketos.org/wiki/Amazon_Fire_7_2015_(amazon-ford)
[waits eagerly nonetheless]
This is a solid old device in a lot of ways. I'd love to see it supported by PMOS.