Android Encryption, SafetyNet, Verified Boot 2.0 and the Boot Process

Android Encryption, SafetyNet, Verified Boot 2.0 and the Boot Process - General Questions and Answers

I'm trying to understand the Android Boot Process and the new additional security measures/restrictions put in place by the device manufacturers.
So far I've read through these posts on XDA, Lineage OS Blog and some others. I've understood some and still confused about others.
[INFO] ANDROID DEVICE PARTITIONS and FILESYSTEMS
[INFO] BOOT PROCESS: ANDROID vs. LINUX
Qualcomm’s Chain of Trust
Android Boot and Recovery Images
Dissecting the Android OTA Update System
I've flashed custom ROM and TWRP on my old phone but it didn't have the new security measures in place and I didn't bother about encryption then (The entire files on the device is accessible from the recovery).
I have some doubts about the encryption and other stuff.
1) When we are running with the stock recoveries, user files are inaccessible(because those stock recoveries don't provide that function).
How can I keep my files safe while using TWRP or similar recoveries?
ie How does FDE work with the custom recoveries?
2) I've read about some users complain that FDE got triggered after firmware upgrade. In such cases what key does it use?
3) I've read on Google's website that it allows users to boot with custom keys. Is that enough for 'Certified Status' on Google Play.
4) What all modifications trigger SafetyNet?
I understand that modifying /system triggers it, so using custom kernels would trigger it Right?
Kindly help me out. I'm sorry for any mistakes.

Bump
Bump

Bumped

Related

New to all of this

What's the difference between flashing and rooting? Thinking of android after 3 years of apple

to quote sado1 from:
http://androidforums.com/i7500-all-things-root/31737-difference-between-flashing-rooting.html
Rooting - process that enables superuser account (root) on your Android device, which gives you more control over the system. It's a bit similar to jailbreaking: you get write access to all of the system files.
Flashing - it could refer to flashing your phone with firmware - then it means that you install another (usually newer) version of software provided by producer for your phone.
Flashing could also mean flashing a non-official/custom ROM - then it means installing non-official ROM (modified system files package) to achieve better performance, more features etc.
When you flash your phone with custom ROM you usually get root automatically. Flashing with custom ROM will affect directly what you see/feel from a user's perspective. Root is about underlying system changes.

Kernal Source Released

The Kernal Source has been released by Razer.
Links to the source is at the bottom of this page:
http://support.razerzone.com/mobile/razer-phone
Here are the links to the source just in case:
MR1 Releases:
Build 853
Build 851
Production Releases:
Build 822
Build 813

It has been talked about already but not in this section. This is where it belongs and nice job posting direct links to it.
https://forum.xda-developers.com/razer-phone/how-to/source-code-posted-t3719665

MedicStuder said:
Surprised no one else posted in the section with this. The Kernal Source has been released by Razer which means modding can start.
https://www.xda-developers.com/razer-phone-kernel-source-code/
http://www.androidpolice.com/2017/12/15/kernel-source-code-just-released-razer-phone/
https://www.gizchina.com/2017/12/16/razer-releases-kernel-source-files-razer-phone/
Links to the source is at the bottom of this page:
http://support.razerzone.com/mobile/razer-phone
Here are the links to the source just in case:
MR1 Releases:
Build 853
Build 851
Production Releases:
Build 822
Build 813
Click to expand...
Click to collapse
I mentioned it in the factory image thread 5 days ago

Mods, can we pin this in the dev section since it contains the links to the needed source code for development purposes. Seems appropriate to have it pinned in this thread. thanks.

I've also got the kernel source going with CAF history included (based on LA.UM.5.7.r1) at https://github.com/jcadduono/android_kernel_razer_msm8998/tree/android-7.1
Fixed a minor bug and added some build scripts to simplify the process of configuring and building.
Added qcacld-3.0 sources into the kernel build for WiFi drivers but I appear to be missing something so it doesn't build. :/
I'm sure someone here can figure that out!
For TWRP support, essentially you'll need to build the stock kernel with additional options like f2fs and exFAT if desired. The OS and TWRP will be sharing the same kernel binaries due to the A/B setup so you *will* need to build the WiFi driver, even for recovery.
If someone is daring enough, they can simply build TWRP normally (ex. for a non-A/B device), flash it to boot_b or boot_a partition (depending what's active), boot up TWRP, and make backups of the opposite A/B partitions.
This can't actually be too hard to do, Dees_Troy has already done most of the work by supporting A/B on Pixel devices already.
I suppose I'm willing to give it a try if anyone is willing to possibly lose the ability to get into the OS until Razer releases factory images.
The chance of that happening is pretty slim, as long as we're only flashing the *active* boot partition (we'll check that in OS using mount command), we should be able to simply grab a copy of the opposite boot partition and restore it to how it was.
YOU CAN simply use fastboot to swap to the other boot partition, restoring your OS to bootable even if TWRP fails to work. (we will test this first to make sure Razer has enabled this option...)
Probably safe, but there's just that risk.
As I'm unsure exactly how to compile the WiFi drivers right now, I'll do this:
Create a normal TWRP image, which you can flash to your *active* boot partition.
Create a TWRP flashable zip that will take the ramdisk from the active boot partition and flash it to the inactive boot partition's boot image, then flash the inactive boot partition's image to your active boot partition.
Result: Both partitions contain the original stock kernel image with TWRP support and a fully working OS.
Slight issue: F2FS won't be supported because the stock kernel will have module signing enabled and TWRP won't be able to load it.
I'm also fairly certain I'll never get decryption working myself for this device...it looks like the vendor partition may be required and it is already encrypted itself? (not encrypted on the Pixel 2 so this is new)

Dees_Troy will be getting his Razer Phone next week. If anyone can get TWRP working it's him. No need to worry ?

MishaalRahman said:
Dees_Troy will be getting his Razer Phone next week. If anyone can get TWRP working it's him. No need to worry ?
Click to expand...
Click to collapse
No way! :victory:
That's the best news I've heard yet
---------- Post added at 04:44 AM ---------- Previous post was at 04:30 AM ----------
jcadduono said:
I've also got the kernel source going with CAF history included (based on LA.UM.5.7.r1) at https://github.com/jcadduono/android_kernel_razer_msm8998/tree/android-7.1
Fixed a minor bug and added some build scripts to simplify the process of configuring and building.
Added qcacld-3.0 sources into the kernel build for WiFi drivers but I appear to be missing something so it doesn't build. :/
I'm sure someone here can figure that out!
For TWRP support, essentially you'll need to build the stock kernel with additional options like f2fs and exFAT if desired. The OS and TWRP will be sharing the same kernel binaries due to the A/B setup so you *will* need to build the WiFi driver, even for recovery.
If someone is daring enough, they can simply build TWRP normally (ex. for a non-A/B device), flash it to boot_b or boot_a partition (depending what's active), boot up TWRP, and make backups of the opposite A/B partitions.
This can't actually be too hard to do, Dees_Troy has already done most of the work by supporting A/B on Pixel devices already.
I suppose I'm willing to give it a try if anyone is willing to possibly lose the ability to get into the OS until Razer releases factory images.
The chance of that happening is pretty slim, as long as we're only flashing the *active* boot partition (we'll check that in OS using mount command), we should be able to simply grab a copy of the opposite boot partition and restore it to how it was.
YOU CAN simply use fastboot to swap to the other boot partition, restoring your OS to bootable even if TWRP fails to work. (we will test this first to make sure Razer has enabled this option...)
Probably safe, but there's just that risk.
As I'm unsure exactly how to compile the WiFi drivers right now, I'll do this:
Create a normal TWRP image, which you can flash to your *active* boot partition.
Create a TWRP flashable zip that will take the ramdisk from the active boot partition and flash it to the inactive boot partition's boot image, then flash the inactive boot partition's image to your active boot partition.
Result: Both partitions contain the original stock kernel image with TWRP support and a fully working OS.
Slight issue: F2FS won't be supported because the stock kernel will have module signing enabled and TWRP won't be able to load it.
I'm also fairly certain I'll never get decryption working myself for this device...it looks like the vendor partition may be required and it is already encrypted itself? (not encrypted on the Pixel 2 so this is new)
Click to expand...
Click to collapse
I'm willing to temporarily sacarfic my device for this. I will message you tomorrow morning and we can give it a shot.

We have lift off! @jcadduono you were right :highfive:
Waiting on you for further instructions on how to proceed.
Even if this leads to no where it sure feels damn good to see the twrp logo.

Everything is going well, we're getting copies of each partition and I'm working on making factory restorable images right now.
I am fairly certain I can even support encryption on this device with no issues.
The device itself actually supports hardware Qualcomm full-disk encryption like most non-Google Qualcomm devices so it's nothing new!
However, the Razer Phone supports HW encrypted SDcards like LG does, so TWRP needs support in the actual crypto code used in the project to work with encryptable sdcards. Maybe Dees_Troy will be up to that task when he gets his phone.
TWRP images will be distributed like so:
- A twrp.img file that you flash to your active boot partition
- A zip file that copies the TWRP ramdisk from your active boot partition into your inactive boot partition, then copies your inactive boot partition to your active boot partition
The zip file will effectively install TWRP and the next time you boot TWRP it will be relying on your ROM's kernel instead of the TWRP kernel.

jcadduono said:
Legend!
Mad props to you, can't wait to see more! :good: This will be a good Christmas, can I ask whether being carrier or not will matter for installation?
Click to expand...
Click to collapse

@jcadduono Legend!
Mad props to you, can't wait to see more! :good: This will be a good Christmas, can I ask whether being carrier or not will matter for installation?
P.s I'll take a pop if you want a second test

thread stuck like Chuck for now, hopefully we can get some dev going for this device.

yeahh !!!!!!! wake up dev teams !!

Any information regarding Franco kernel?

Android Terminology You Must Know Before Toying with Your Android

Firmware & ROMFirmware is the skeleton of ROM, kinda tells ROM what to do, when to do, how to do. So, they refer to the firmware of the phone as ROM, because in theory you, as a normal user, can't alter the area where the firmware is (it's in the Read Only Memory). On older phone, this was true, it wasn't easy to alter a phone software without special equipment. In nowadays, the firmware is not stored in real ROM, it's stored in the internal flash memory of the phone, which is not Read Only, so you can flash another firmware. The 2 terms are interchangeable. In general, people refer to modified firmware's as ROMs.
Again the ROM on the phone contains the phone's firmware. By replacing the firmware, the ROM of the phone is useless and if you flash a new firmware, the new firmware has complete control over it, which is why the two terms are seen as synonymous.
DRM & WIDEVINE SECURITY:DRM = Digital Rights Management, googles security for paid streaming service, divided into L1,L2,L3 SECURITY LEVEL. If your device has widevine security level L1, you can stream netflix, amazon tv etc in full HD, if L3, you can only in 480p or 540p.
Widevine CDM (content decryption module)
Widevine Media Optimizer (typically when Widevine is both the protection and content player)
if you want to check widevine security of your phone, download DRM INFO APP.
WHERE WIDEVINE SECURITY IS STORED:
PERSIST.IMG contains widevine security information. Once widevine L1 security is lost, there is little possibility of getting it back. You might get it back if you have taken your persist.img backup, that's why, in my MIUI Unlocking Bootloader, Flashing Recovery & Rooting Process thread, I put utter importance taking the persist.img partition backup. Persist also contains your sensor information, like bluetooth, wifi etc.
How do you loose it: By rolling back your android version. Never do it. If you do it, you may break your sensors, in that case, you may fix them by flashing the persist.img of your device, hope you took the backup of it, if you don't , you may flash the persist.img of same device model of other person's device but you will loose your WIDEVINE SECURITY LEVEL L1 forever. My suggestion, never roll back.
TERMINOLOGIES:gApps = Google Apps
SuperSU = another rooting app like Magisk. With simpler interface & no root hiding opportunity.
DTO = Device Tree Overlays (DTOs)
OEM = Original Equipment Manufacturer. (such as, MIUI is a OEM skin/ROM)
OEM Skin = like MIUI luncher, notification toggle like this. Custom OEM skin: customizing them using others skin.
Slot Services = it refers to partition related services in recovery mood.
Treble ROM = Treble supported rom supports ota(over the air) (in simple terms : System Updates)
non-Treble ROM = While non treble roms doesnt support ota.
BB = most probably BASEBAND
GMS, API, AOSP & PRE-LOADED APPS:GOOGLE MOBILE SERVICES (GMS) is a collection of proprietary applications and APPLICATION PROGRAMMING INTERFACES (APIs) services from Google. GMS is used by manufacturers of Android devices, such as smartphones, tablets, and smart TVs. GMS are the Android Applications developed by Google for manufacturers of Android that often come pre−installed on Android devices. GMS is not a part of the ANDROID OPEN SOURCE PROJECT(AOSP), which means an Android manufacturer needs to obtain a license from Google in order to legally pre−install GMS on an Android device. This license is provided by Google without any license fees. GMS consists of two parts; a popular bundle package and an other bundle package. In order to gain a license for GMS, the popular bundle package needs to be pre−installed by Android device manufactures, which are usually called PRE-LOADED APPS.
What is force encryption?Encryption is the process of encoding all user data on an Android device using symmetric encryption keys. Encryption ensures that even if an unauthorized party tries to access the data, they won't be able to read it. Android has two methods for device encryption: file-based encryption and full-disk encryption.
What is Dmverify?Android verified boot: As dm-verity is a kernel feature, in order for the integrity protection it provides to be effective, the kernel which the device boots needs to be trusted. On Android, this means verifying the boot partition, which also includes the root file system RAM disk and the verity public key.
What is DM-Verity?Android 4.4 and higher supports Verified Boot through the optional DEVICE-MAPPER-VERITY (dm-verity) kernel feature, which provides transparent integrity checking of block devices. dm-verity helps prevent persistent rootkits that can hold onto root privileges and compromise devices.
What is DM-verity and force encryption disabler?Many Android ROMs have become more and more secure. Many devices have been equipped with new system security mechanism to protect any advanced modification to the system itself. One of the known mechanism is Device Mapper Verity, also known as dm-verity. This security mechanism is basically developed to help prevent persistent rootkits that can hold onto root privileges and compromise devices. Most of the recent Android devices need to do a verified boot through the optional dm-verity kernel. This is sure can prevent malware to hide from detection programs and otherwise mask themselves. Unfortunately, for advanced Android users, it can be troublesome to a certain extent because it prevents the device to boot properly once custom recovery like TWRP is flashed. Previously, in order to flash TWRP on a device protected with dm-verity feature, you’ll need to first cook your own ROM modifying original ROM to disable dm-verity in its kernel. This could be so arduous for novice users. Luckily, there is a patch-like package allows you to disable dm-verity and forced encryption feature. Download the package from the link below and flash it from TWRP. (Force disabler may not be different for every phone, maybe same) Article Link
What does Vbmeta do?
The vbmeta image is cryptographically signed and contains verification data (e.g. cryptographic digests) for verifying boot. The vbmeta image can also contain references to other partitions where verification data is stored as well as a public key indicating who should sign the verification data. Also Check this link you are interested.
Dirty flashing v/s clean flashing | What's the difference, also what is OTA Update: (CLEAN FLASH AFTER ERROR)Almost every android geek has heard about "flashing" a custom ROM on their device. And digging a bit deeper reveals that flashing also has two types. "clean" flashing and "dirty flashing" But what's the difference and which one should you choose? To find out, read ahead.
The difference
A clean flash is what you do when, you install a ROM after wiping all your device partitions (System, data, ART/Davlik, and cache)
A dirty flash is done when you flash a ROM over an existing one, without erasing the system partition. (at times, only the ART partition is erased). A dirty flash keeps system data from the previous ROM. If the ROMs are not compatible with each other, you'll run into problems. A flash of rom over existing rom without wipe is known as dirty flash, generally followed for nightly or daily builds. You also need a set of gapps with backup script to survive dirty flash.
Dirty Flash = Flashing over current ROM
Clean Flash = Wiping EVERYTHING to make way for a new ROM.
Dirty flash - wipe cache and dalvik, flash ROM and gapps
Clean flash - wipe cache, dalvik, data and system, flash ROM and gapps
What should you choose?
It isn't quite difficult to choose. It depends on the similarity between the ROM you have and the ROM you want to install. If you're installing a completely different one than the one you have (like Touchwiz to Cyanogenmod or Lineage to AOSP) you better go for a clean flash.If you're updating your ROM (from the source provided by the developer of the original ROM), a dirty flash would work, although you should check what the developers says about changing and updating.
Risks
Although flashing comes with it's own risks, going dirty is a lot more unsafe than doing a clean flash. A clean flash removes everything giving the ROM enough room to be installed, minimizing chances of bricking. Whereas, a dirty flash is a lot more likely to brick your device, and if it gets hard bricked.. you don't have any option other than going to the nearest authorized service center and getting your phone fixed. Basically, if you do a clean flash where you can go dirty, nothing will go wrong. But if you go dirty where you're supposed to do a clean flash, you'll end up with a non functional device.
OTA UPDATE:
OTA = OVER THE AIR UPDATE. For example, you are updating from eu rom 12.5 to 12.6. It may not require clean flash, you just dirty flash the rom because it's basically a version update of the same ROM. Your phones auto update or MIUI update is an OTA update. An over-the-air (OTA) update is the wireless delivery of new software, firmware, or other data to mobile devices. Wireless carriers and original equipment manufacturers (OEMs) typically use over-the-air updates to deploy firmware and configure phones for use on their networks over Wi-Fi or mobile broadband. The initialization of a newly purchased phone, for example, requires an over-the-air update. With the rise of smartphones, tablets and internet of things (IoT) devices, carriers and manufacturers have turned to different over-the-air update architecture methods for deploying new operating systems (OSes) to these devices.
Clean Flash : if your device has problem, is not booting, rom is not opening, passward is asking but after entering password, it's not working, all this problem has this clean flash solution. Go to wipe, do a "Fomat Data". advance wipe of system & others is not necessary. Then , flash your new rom. (may use backup rom of your previous working/stable rom).
Disk Quota:A disk quota is a limit set by a system administrator that restricts certain aspects of file system usage on modern operating systems. The function of using disk quotas is to allocate limited disk space in a reasonable way. "This quota feature also improves system stability by preventing any single app from using more than 90% of disk space or 50% of inodes."
fstab:In Android 9 and lower, devices can specify fstab entries for early mounted partitions using device tree overlays (DTOs). In Android 10 and higher, devices must specify fstab entries for early mounted partitions using an fstab file in the first stage ramdisk. logical indicates that this is a dynamic partition.
STILL THIRSTY? WANT TO KNOW MORE ? READ THIS THREAD IN XDA
My Other Threads according to "how should you read them" serial:
1. MIUI 12.5 Chinese ROM Google PlayStore Stopped Working
2. MIUI Unlocking Bootloader, Flashing Recovery & Rooting Process
3. Android Terminology You Must Know Before Toying with Your Android (This Thread)
4. ROM Naming & CUSTOM ROM, AOSP ROM, TREBLE ROM, GSI ROM, PORTED ROM

@shafi1885 Thanks very much for your great terminology guide that is really appreciated. However, I've removed the link to Telegram from your OP.
As an excemption from the last bullet of rule no. 5 of the XDA Forum Rules, we grant only developers the privilege to provide links to their social media in their own development threads. These conditions obviously don't apply to you or your thread.
Stay safe and stay healthy!
Regards
Oswald Boelcke
Senior Moderator

How To Guide [OUTDATED - PLEASE USE UNOFFICIAL LINEAGEOS INSTEAD] Installing a GSI on Samsung M12/A12.

I am deleting this guide since M12 will soon recieve an unofficial build of LineageOS 19.1. Don't ask when, as I'm not the lead developer but I helped with it

Update 1: I figured out how to make script run on boot. Instructions revised. If you followed earlier check them again
Update 2: Magisk 24.1 is now stable. Instructions revised.
Update 3: I contacted phh and he implemented the script inside his trebleapp. Instructions revised and modified trebleapp is attached. NOTE: GSIs newer than 7/Feb/2022 will include this workaround by default.
Update 4: This guide is now unnecessary now that unofficial LineageOS is very close to release

Achievement unlocked: flashed GSI with FBE enabled!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
In short, I've successfully done flashing of @phhusson's latest version of Android 12 GSI (which is v402 as of today). To do this, I needed to modify the multidisabler script so it won't disable FBE, format the userdata using the stock recovery, flash TWRP, resize tmpfs to proper size, push GSI image into tmpfs and flash it using TWRP. I used the securized image with vndklite variant, since there was no securized images for regular vndk releases (but it seemed that vndk was working better for me, at least I have no USB connection anymore where with VNDK I was able to have USB debugging). Maybe I'll try re-flashing it once I'll patch the regular images and securize them (since I'm on *nix, I can just mount them and modify their contents) and take an approach of finding how Samsung ROMs are working OK. For now, I need to take a break from all bootloops I had in the process of FBE flashing .
Anyway, the goal of this experiment was to use GSI ROMs as a daily driver and having FBE disabled could otherwise cause a serious problem on device loss.
So, onto the list what's been tested (that wasn't noted before):
Screen locking – it seems that the workaround for the screen is not applied before unlocking the phone, probably because the app is not running yet. This might work with the script used as postfs module.
EDIT: I've found some notes in the Magisk documentation that both post-fs data and late_start services are run after data is decrypted, which basically means applying this workaround using Magisk seems to be pointless for now (maybe not after PPH app will stop providing the workaround)... Probably the best option would be patching the ROM itself, either with flashable ZIPs or directly before flashing it (most GSIs can be mounted under Linux and tweaked).
Adaptive brightness – not working, since all virtual sensors are not working for now. Might be easy to fix through as I've found some stuff in the official ROM that I had an idea to experiment with putting them into GSIs (as a Magisk module, to avoid a breakage).
USB – as I said, a data transfer via USB is not working for me for some reason. It worked for me once I had VNDK Android 12 GSI installed (same version).
Booting with stock kernel – I had some successful attempts doing that, but it further was a cause of a bootloop, at least once I had installed Magisk. Therefore, I'll recommend patching the Magisk the way as in tutorial (after patching the kernel) to have everything working for now.
For people who wants to play with stock images but don't know how: you can use simg2img, lpunpack and Linux to extract and mount the official ROM image in approach of finding there some tips like in initrc services why some stuff is working fine on Samsung while it doesn't on GSIs. Maybe I would tinker with it a bit, trying to export a few services and libraries in an approach to create a Magisk module with all stuff needed to have a fully functional GSI, but I'm tired of modding for now, especially when this is my first Samsung phone I had to deal with.
Edit: Typo fixes, added additional text formatting.

Amazing work. If you need testers feel free to PM me. As a sidenote, poking in sysfs led me to believe that android is sending the info needed to read the proximity but the kernel is sending garbage which gets interpreted as the sensor not being triggered. Also phh should have added the workaround into his trebleapp starting from phh AOSP 12 v401, so aside from installing magisk no post install workarounds should be needed.
Attached is a photo of what cmd_result reads when a whatsapp voice message is played which reads proximity to play the message in the earpiece and turn screen off when proximity is triggered

ap4ss3rby said:
Also phh should have added the workaround into his trebleapp starting from phh AOSP 12 v401, so aside from installing magisk no post install workarounds should be needed.
Click to expand...
Click to collapse
Unfortunately, the commit was reverted as of master branch, so we should prepare for it to stop to work unless phh will work on it before releasing an another version. Also I wrote that the workaround didn't seem to apply itself before unlocking the phone (FBE encrypted) the first time and therefore decrypting sensitive data after boot. For now this makes it an requirement when using PHH app to unlock the phone before it sleeps so the touch is going to be responsive.
Anyway, it seems that even Magisk (v24.1) is not capable of running the services before data is decrypted, so now I have no idea how to bypass that in other way than patching the ROM itself and creating the `initrc` service... Anyway, this is also a hint that what samsung is doing starts before basically everything, so no APK file nor script is going to really fix it since they are meant to start after data is decrypted...

SB3P said:
Unfortunately, the commit was reverted as of master repo, so we should prepare for it to stop to work unless phh will work on it before releasing an another version. Also I wrote that the workaround didn't seem to apply itself before unlocking the phone (FBE encrypted) the first time and therefore decrypting sensitive data after boot. For now this makes it an requirement when using PHH app to unlock the phone before it sleeps so the touch is going to be responsive.
Anyway, it seems that even Magisk (v24.1) is not capable of running the services before data is decrypted, so now I have no idea how to bypass that in other way than patching the ROM itself and creating the `initrc` service... Anyway, this is also a hint that what samsung is doing starts before basically everything, so no APK file nor script is going to really fix it since they are meant to start after data is decrypted...
Click to expand...
Click to collapse
I guess for now we have two options:
A: Build custom kernel/vendor specifically for GSIs that correctly reports sensors as GSIs expect them to
B: Fix GSI issues through Magisk services implementing various workarounds in scripts. (an example is the touchscreen sleep/wake issue)

ap4ss3rby said:
Attached is a photo of what cmd_result reads when a whatsapp voice message is played which reads proximity to play the message in the earpiece and turn screen off when proximity is triggered
Click to expand...
Click to collapse
Also that's interesting those virtual sensors are still present, I personally thought that Samsung made it the way there's an virtual device create as on Linux and there's their proprietary software running somewhere in the system that uses the camera as an input and calculates it to provide the data... On the other hand, when I think about that logic, even some (if not all) virtual devices on Linux (e.g. v4l2loopback) needs to have their module loaded with the kernel to work. I'm glad at least there's no need to reinvent the wheel and no one really needs to recreate the entire algorithm for it if it's going to be in the kernel sources...
ap4ss3rby said:
I guess for now we have two options (...)
Click to expand...
Click to collapse
I feel like the B option is worse than patching the GSI ROMs, either via flashable ZIPs or on your own... This is because I couldn't find anything in docs that would let me run services before /data is going to be decrypted... Personally, I've made myself a such service using the statically-compiled Linux ARM binary (non-NDK, using GNU libs – yes, it is still runnable on Android as well) – it applies the workaround for now both when screen is turned on and off (I had no idea on which event it should really run, so I made it to run on both just to be safe) by watching the file changes based on (AFAIK) filesystem events – so it has a major advantage over your script, as it won't run in endless loop, yet watch the file responsible for brightness to change and then do its job. But even with that, TSP doesn't seem to make touch available immediately and it is still expected to be revived after 1-2 seconds.
Also, as of the methods of applying these workarounds, the other way could be modifying the ramdisk (maybe with the help of Magisk, which I believe has documented how it's actually doing it itself and how others could modify the root and init as Magisk does to load files before the OS will properly initalize itself. Yet I don't like an idea of messing myself with the boot partition, at least for now...

Debug info: I tried flashing stock to grab logs from the touchscreen driver. The logs attached here do not appear at all on an unpatched GSI (I.E flashing the GSI as is without any touch workaround).

ap4ss3rby said:
Hi, I installed LineageOS 18.1 GSI on my M127F. I want to share my guide to installing this GSI.
Code:
DISCLAIMER:
By following this guide you accept that you
may do irreversible damage to your phone.
If something breaks the responsibility is
yours only. If you want stable software that
is guaranteed to work 100% don't follow
this guide.
I assume you are running a fully stock system and and locked bootloader and firmware U3/U4.
Installing TWRP and custom kernel
Enable Developer Options by tapping on software information > build number 7 times
Enter developer options then toggle OEM Unlocking on.
Power off your phone.
Hold Vol Up + Vol Down then plug in your phone to enter download mode
THIS WILL ERASE ALL YOUR DATA AND VOID YOUR WARRANTY. Follow on screen instructions to unlock your bootloader. THIS WILL ERASE ALL YOUR DATA AND VOID YOUR WARRANTY
After this you want to download and install attached Orangefox recovery using odin. After odin is done flashing enter recovery
Format data (not wipe) in recovery
Enter terminal and type multidisabler twice
Reboot to system and verify that under security encryption is disabled
Download TWRP and custom kernel for your phone
Reboot into recovery and locate the downloaded twrp image
Select recovery.
Reboot into recovery
Install kernel, then wipe cache and reboot. You should now see that it is complaining about some internal issue. This is normal.
Installing the GSI
Download your favorite ROM from the list provided below. You want to install an arm64 a/b image.
Extract the image file
Reboot to recovery.
Select install then install image
Locate the GSI image
Select install system
After that is done return to recovery and select factory reset.
Reboot then do setup (if applicable) then download attached magisk and phh trebleapp. If your phone is stuck on bootanimation check under to fix it.
IMPORTANT: DO NOT LET THE SCREEN TURN OFF OR YOU WILL HAVE TO REBOOT TO MAKE TOUCH WORK AGAIN.
Install attached magisk
Open magisk and click on install then direct install
Download and install the attached phh-treble app apk.
Touch should now work. Enjoy your GSI.
Extras
Magisk 24.1
Open Magisk
Go to settings
Update Magisk Manager app to version 24.1
Relaunch Magisk then install magisk
Choose direct instal
Migrating to patched trebleapp
Download and install attached trebleapp
Open your root file manager
go to /data/adb/service.d
Delete the script you added earlier
Tips in case things don't work
In case after rebooting to the GSI the phone bootloops:
Download stock image from wherever you download your firmware (I use a python program called samloader)
Extract the AP of the downloaded firmware
Find userdata.img.lz4 and create a .tar archive only containing this file
Reboot to download mode
In odin select AP then locate the newly created .tar archive Then click on flash
Reboot
Continue from step 7 under the "Installing the GSI" portion of the guide
To revive the touchscreen using ADB:
In case you didn't grant adb root access but installed magisk, run adb shell then su. A root access for the app shell will appear. Grant root permission
Plug in phone to a computer with ADB
adb shell
su
cat /sys/class/sec/tsp/cmd_result
echo check_connection > /sys/class/sec/tsp/cmd
What works:
Boots
RIL
Fingerprint
Main rear camera
Front camera
Sleep/Wake (workaround in steps above, may need to sleep wake several times before it works)
WiFi
Flashlight
Rotation
Magisk 24
90Hz (M12 only. A12 doesn't have 90Hz refresh rate)
LineageOS 18.1
LineageOS 19
CAOS (GApps variant available)
phh AOSP 11 v313
phh AOSP 12 v400h
Untested
GPS
Flashing GApps. (I use fdroid and aurora store on LineageOS and CAOS has built in GApps)
USB-OTG
A127F
M127G
If I didn't list it under broken or working I didn't try it or forgot to test it.
Broken
Double tap to wake. Touchscreen turns off and I have no idea how to keep it alive while lcd is off
MTP
Virtual Proximity. Screen will stay on in phone calls and WhatsApp will always play voice messages through speaker
Flashlight brightness. Flashlight will always stay on weakest brightness with no way to adjust.
Adaptive refresh. The framerate you set in phh addons is what you get. Be prepared for slightly reduced battery.
You tell me (even though I probably don't have the solution)
Bugs
You may need to wait a little bit before touchscreen responds or sleep/wake several times before screen responds after turning the screen off
Credits
@physwizz for kernel, TWRP and orangefox
@phhusson for implementing workaround in trebleapp as well as GSI list
me for touch workaround
Links
Kernels and recoveries: https://t.me/a127f_res/113
GSIs: https://github.com/phhusson/treble_experimentations/wiki/Generic-System-Image-(GSI)-list
Click to expand...
Click to collapse
Great guide.
Well done

Thanks for the great guide. Unfortunately, I don't know how to resize tmpfs. Can anybody tell me how to do that? I only have 4 GB or less on my Samsung Galaxy A12 with 64 GB of Storage (it should have, it only shows something like 3 or 4 gigabytes like I mentioned)

matahbeyz said:
Thanks for the great guide. Unfortunately, I don't know how to resize tmpfs. Can anybody tell me how to do that? I only have 4 GB or less on my Samsung Galaxy A12 with 64 GB of Storage (it should have, it only shows something like 3 or 4 gigabytes like I mentioned)
Click to expand...
Click to collapse
You don't have to resize TMPFS if you don't want to have FBE encryption or have the external SD card (you can use microSD for flashing, which might be a better choice if you need to flash a larger devices). Also you can't resize TMPFS to 64 GB, it uses your RAM to store regular data instead of storage (this is basically the concept of TMPFS). What I was mentioning is that /data won't work under FBE and custom recoveries for now, so you need to use your RAM instead if you don't have any external storage device to save images somewhere via ADB.
As of resizing the TMPFS, you should be able to find some Linux tutorial how to do that, on Android this is works basically the same (even on both Linux and Android you have /tmp directory with TMPFS by default).
Anyway, I've decided to share some stuff that you may need for that. Here's the multidisabler script I was using for flashing GSIs with FBE encryption preserved. I was also working on the native binary that would work as the workaround for the touchscreen so it can be used instead of the script. The advantages are that it actually listens to filesystem events and therefore does not need to read file in loop in order to get the information if brightness has changed. Maybe I'll share it with you once I find it to be ready, right now I'll just share my multidisabler script with patches.
BTW, I've tested LineageOS GSIs (both 11 and 12) and noticed they behave completely different, no matter of variant (the USB actually uses some driver, which is not fully compatible with M12 but close enough to provide basic communication through ADB). I guess pphusson just changed something and now these drivers aren't applied by default, yet I think I've noticed the issues with Bluetooth's HSP/HFP profiles which as I remember was not the case with latest stable pphusson's vanilla Android 12 GSIs. Now I just hope these problems are going to be resolved in the next builds of Android's GSIs with phhusson's patches and with the knowledge that MTP just worked fine on TWRP I used, there's a little hope that we will gain the proper combination of drivers/firmware to have both USB and Bluetooth functional at the same time someday.
I've also approached patching the kernel under newer kernel base 4.19.112, yet I gave up on properly resolving its conflicts. I may work on that as well in order to patch some vulnerabilities, with a hope that I'll succeed updating kernel as closest to the latest patch as possible. The 4.19.112 is going to be just a test if Samsung is capable of actually booting from it and if I may be able to use git with common human logic and my limited programming skills to actually patch it the way it would do so (without much understanding about the code itself, yet basic knowledge about C syntax). For now I've only succeed reproducing the upstream Linux kernel commit structure from 4.19.111, with a single additional commit for Samsung changes and another one for physwizz ones.

can anyone guide me how to unlock bootloader on Samsung Galaxy M12G ?

@SB3P Thanks so much. Sorry for my late reply, but thank you!

SB3P said:
Achievement unlocked: flashed GSI with FBE enabled! View attachment 5533799In short, I've successfully done flashing of @phhusson's latest version of Android 12 GSI (which is v402 as of today). To do this, I needed to modify the multidisabler script so it won't disable FBE, format the userdata using the stock recovery, flash TWRP, resize tmpfs to proper size, push GSI image into tmpfs and flash it using TWRP. I used the securized image with vndklite variant, since there was no securized images for regular vndk releases (but it seemed that vndk was working better for me, at least I have no USB connection anymore where with VNDK I was able to have USB debugging). Maybe I'll try re-flashing it once I'll patch the regular images and securize them (since I'm on *nix, I can just mount them and modify their contents) and take an approach of finding how Samsung ROMs are working OK. For now, I need to take a break from all bootloops I had in the process of FBE flashing .
Anyway, the goal of this experiment was to use GSI ROMs as a daily driver and having FBE disabled could otherwise cause a serious problem on device loss.
So, onto the list what's been tested (that wasn't noted before):
Screen locking – it seems that the workaround for the screen is not applied before unlocking the phone, probably because the app is not running yet. This might work with the script used as postfs module.
EDIT: I've found some notes in the Magisk documentation that both post-fs data and late_start services are run after data is decrypted, which basically means applying this workaround using Magisk seems to be pointless for now (maybe not after PPH app will stop providing the workaround)... Probably the best option would be patching the ROM itself, either with flashable ZIPs or directly before flashing it (most GSIs can be mounted under Linux and tweaked).
Adaptive brightness – not working, since all virtual sensors are not working for now. Might be easy to fix through as I've found some stuff in the official ROM that I had an idea to experiment with putting them into GSIs (as a Magisk module, to avoid a breakage).
USB – as I said, a data transfer via USB is not working for me for some reason. It worked for me once I had VNDK Android 12 GSI installed (same version).
Booting with stock kernel – I had some successful attempts doing that, but it further was a cause of a bootloop, at least once I had installed Magisk. Therefore, I'll recommend patching the Magisk the way as in tutorial (after patching the kernel) to have everything working for now.
For people who wants to play with stock images but don't know how: you can use simg2img, lpunpack and Linux to extract and mount the official ROM image in approach of finding there some tips like in initrc services why some stuff is working fine on Samsung while it doesn't on GSIs. Maybe I would tinker with it a bit, trying to export a few services and libraries in an approach to create a Magisk module with all stuff needed to have a fully functional GSI, but I'm tired of modding for now, especially when this is my first Samsung phone I had to deal with.
Edit: Typo fixes, added additional text formatting.
Click to expand...
Click to collapse
Could you explain how you done this.... i mean please explain step by step... i am using Galaxy M12G Varient....thanks in advance

milindbhaliwade said:
Could you explain how you done this.... i mean please explain step by step... i am using Galaxy M12G Varient....thanks in advance
Click to expand...
Click to collapse
If you would see the *untested* section at the initial post of this thread, it is unknown whetever this works or not for M127G phones (if it bootloops it might not work at all). Anyway, here's how I did it on M127F (at least how I remember this):
1. I did steps from 1-6, I believe I skipped 7 since I was aware it will mess something up with the data partition.
2. I modified the multidisabler script and pushed it to my phone via the ADB (to TMPFS). You can find this script pushed as xz compressed file. Before executing multidisabler script I have done a backup of the recovery and system partitions (using dd tool) which I am going to reflash later.
3. I rebooted to download mode and flashed TWRP image.
4. After TWRP ended flashing, I booted into the recovery. I flashed the physwizz kernel and then my own GSI image as it was described in the instructions at the initial post. Just remember that /data partition is not functional with FBE and TWRP so you need to push your images somewhere else like microSD card or TMPFS partition. OTG might work here as well, this is something I haven't tested yet through...
5. Once you are done with flashing you need to restore the original recovery partition via the download mode. TWRP won't boot the GSIs with FBE encryption enabled actually it does boot now for me, yet I still recommend switching to stock recovery if your phone bootloops or you need to format/wipe userdata partition. You can then safely format your /data partition with the stock recovery.

For anyone who has starred this thread, I and other devs have released a proper build of LineageOS with /vendor. Aside from VoLTE (which I don't think worked in GSIs anyways) everything should work. Moderators, please close this thread

ap4ss3rby said:
For anyone who has starred this thread, I and other devs have released a proper build of LineageOS with /vendor. Aside from VoLTE (which I don't think worked in GSIs anyways) everything should work. Moderators, please close this thread
Click to expand...
Click to collapse
LineageOS is not only GSI available, I think someone might still find it useful if they want to flash another ROMs. Also Phhuson's GSI also contains some features that unofficial GSI release don't have (i.e. flashlight control in Phhusson's app), so they still might be useful for someone.
This is why I think it is better to not close this thread and maybe revive original guide.

SB3P said:
LineageOS is not only GSI available, I think someone might still find it useful if they want to flash another ROMs. Also Phhuson's GSI also contains some features that unofficial GSI release don't have (i.e. flashlight control in Phhusson's app), so they still might be useful for someone.
This is why I think it is better to not close this thread and maybe revive original guide.
Click to expand...
Click to collapse
Our rom is built completely from source, not a GSI, and it is more or less a complete replacement of stock firmware. If you want you can use a GSI over that instead, and it should function much better than just replacing stock firmware

ap4ss3rby said:
Our rom is built completely from source, not a GSI, and it is more or less a complete replacement of stock firmware. If you want you can use a GSI over that instead, and it should function much better than just replacing stock firmware
Click to expand...
Click to collapse
I haven't said GSI are better, I personally use this unofficial LineageOS build. But what I've said, GSI brings much more variety of picking the OS you can install. Even Linux can be installed on phones nowadays using GSI with only Halium-patched kernel as an requirement. This is why I think leaving this tutorial archived (no updates, interest on fixing bugs etc.) is better than removing it.

[WIP][EXYNOS][ROM][UNOFFICIAL][12]LineageOS 19.1 for Galaxy S20 FE

LineageOS is a free, community built, aftermarket firmware distribution of Android 12, which is designed to increase performance and reliability over stock Android for your device.
LineageOS is based on the Android Open Source Project with extra contributions from many people within the Android community. It can be used without any need to have any Google application installed. Linked below is a package that has come from another Android project that restore the Google parts. LineageOS does still include various hardware-specific code, which is also slowly being open-sourced anyway.
All the source code for LineageOS is available in the LineageOS Github repo. And if you would like to contribute to LineageOS, please visit out Gerrit Code Review. You can also view the Changelog for a full list of changes & features.
Instructions:
Unlock bootloader
Boot into download mode
Flash recovery using heimdall or odin
Boot into recovery right as it finishes flashing
Flash ROM using adb sideload path_to_ROM.zip command
Optionally flash GAPPS the same way you flashed ROM
Format data in recovery
Reboot to system.
Downloads:
RECOVERY
ROM
GAPPS
Reporting Bugs
DO NOT Report bugs if you're running a custom kernel or you installed Xposed
DO NOT Report bugs if you're using TWRP
Grab a logcat right after the problem has occurred. (Please include at least a few pages of the log, not just the last few lines, unless you know what you're doing.)
If it is a random reboot, grab /proc/last_kmsg. (Do not bother getting a logcat unless you can get it just before the reboot. A logcat after a reboot is useless)
If the problem disappears after running "setenforce 0" from a root shell, grab /data/misc/audit/audit.log
Remember to provide as much info as possible. The more info you provide, the more likely that the bug will be solved. Please also do not report known issues. Any bug not reported in the bug report format below may be ignored.
Code:
What is your--
LineageOS version:
LineageOS Download url:
Gapps version:
Did you--
wipe:
restore with titanium backup:
reboot after having the issue:
Are you using--
a task killer:
a non-stock kernel:
other modifications:
Provide any additional information (observations/frequency of problem/last version it worked on/etc) as needed:
Support
Telegram group
Credits
Doomer231
A2L5E0X1
DeHuMaNiZeD
Linux4
Device tree and kernel source code:
R8S-OSS

Issues:
voLTE[wont fix, unless any samsung gets voLTE fixed]
fingerprint scanner might not work
overlays might need some tweaking
no encryption
permissive SELinux

Steps I followed from @Gully.Moy that worked perfectly:
Unlocked bootloader as per guides no problem
Downloaded latest stock firmware from Frija and extract
Copy the AP_xxxxxxxxxxx.tar.md5 file to phone storage
Copy Magisk manager on your phone https://github.com/topjohnwu/Magisk/releases/tag/v25.2
Open Magisk manager, select 'install' next to Magisk, select the .tar.md5 file and patch it
Copy newly created magisk.tar file from phone download folder to computer
Flash via Odin 3.13.3 with standard BL CP and CSC from Frija download, but the magisk .tar file in AP slot.
Boot into android and reenable USB debugging (not sure if necessary).
(Recovery mode combination is volume up + side button with USB plugged in)
I am now in the first boot of the ROM that I copied to the internal storage and flashed with TWRP (as my device is not recogised in fastboot and doesn´t let me sideload via adb it closes) but seems to be in an endless startup loop and it failed to install the gapps also when I tried to, the provided recovery cannot be flashed with Odin @Doomvrr thank you.

BraskOviedo said:
Steps I followed from @Gully.Moy that worked perfectly:
Unlocked bootloader as per guides no problem
Downloaded latest stock firmware from Frija and extract
Copy the AP_xxxxxxxxxxx.tar.md5 file to phone storage
Copy Magisk manager on your phone https://github.com/topjohnwu/Magisk/releases/tag/v25.2
Open Magisk manager, select 'install' next to Magisk, select the .tar.md5 file and patch it
Copy newly created magisk.tar file from phone download folder to computer
Flash via Odin 3.13.3 with standard BL CP and CSC from Frija download, but the magisk .tar file in AP slot.
Boot into android and reenable USB debugging (not sure if necessary).
(Recovery mode combination is volume up + side button with USB plugged in)
I am now in the first boot of the ROM that I copied to the internal storage and flashed with TWRP (as my device is not recogised in fastboot and doesn´t let me sideload via adb it closes) but seems to be in an endless startup loop and it failed to install the gapps also when I tried to, the provided recovery cannot be flashed with Odin @Doomvrr thank you.
Click to expand...
Click to collapse
I need to update the ROM to boot on latest firmware, because samsung updated bootloader. So for now it won't boot unless you're on august firmware, don't try to downgrade firmware. Just wait.

Doomvrr said:
I need to update the ROM to boot on latest firmware, because samsung updated bootloader. So for now it won't boot unless you're on august firmware, don't try to downgrade firmware. Just wait.
Click to expand...
Click to collapse
Thank you for the ROM and the quick answer, if I can help out with something please let me know, thank you.

Doomvrr said:
I need to update the ROM to boot on latest firmware, because samsung updated bootloader. So for now it won't boot unless you're on august firmware, don't try to downgrade firmware. Just wait.
Click to expand...
Click to collapse
Forgot to ask, is there an ETA? Is it LineageOS 20? Thank you

Doomvrr said:
I need to update the ROM to boot on latest firmware, because samsung updated bootloader. So for now it won't boot unless you're on august firmware, don't try to downgrade firmware. Just wait.
Click to expand...
Click to collapse
It´s the October 2022 patch

Doomvrr said:
Reporting Bugs
DO NOT Report bugs if you're running a custom kernel or you installed Xposed
DO NOT Report bugs if you're using TWRP
Click to expand...
Click to collapse
What is the context of the above statments, I ask because -
One of the primary reason for running a custom ROM is for rooting, and the primary reason for rooting for a LOT of users is the ability to run Magisk and EdXposed/Riru.
This one is exspecially confusing, the vast majority of users flash custom ROMs with TWRP. Does the recovery that needs to be flashed with this ROM as comprehensive as TWRP..?

b1k3rdude said:
What is the context of the above statments, I ask because -
One of the primary reason for running a custom ROM is for rooting, and the primary reason for rooting for a LOT of users is the ability to run Magisk and EdXposed/Riru.
This one is exspecially confusing, the vast majority of users flash custom ROMs with TWRP. Does the recovery that needs to be flashed with this ROM as comprehensive as TWRP..?
Click to expand...
Click to collapse
Agreed.

b1k3rdude said:
What is the context of the above statments, I ask because -
One of the primary reason for running a custom ROM is for rooting, and the primary reason for rooting for a LOT of users is the ability to run Magisk and EdXposed/Riru.
This one is exspecially confusing, the vast majority of users flash custom ROMs with TWRP. Does the recovery that needs to be flashed with this ROM as comprehensive as TWRP..?
Click to expand...
Click to collapse
Xposed modules may cause stability issues on the system due to their nature. Debugging the issue becomes a hard task because there can be a ton of reasons as to why it happens, and you'll be most certainly reaching out to the ROM maintainer to help you fix something not even related to his work.
I can't say for sure but I guess it's because TWRP has had some problems to keep up with the changes made to Android on recent years due to the maintainers' private life and the fact that some changes were groundbreaking, like moving the recovery to the boot partition instead of having its dedicated partition, as it used to be until a couple of Android versions.
TL;DR: maintainers post these statements so users can discard possible known causes of issues beforehand, and to avoid complaints about pieces of work that aren't their responsibility at all.

All-In-One said:
Xposed modules may cause stability issues on the system due to their nature. Debugging the issue becomes a hard task because there can be a ton of reasons as to why it happens, and you'll be most certainly reaching out to the ROM maintainer to help you fix something not even related to his work.
I can't say for sure but I guess it's because TWRP has had some problems to keep up with the changes made to Android on recent years due to the maintainers' private life and the fact that some changes were groundbreaking, like moving the recovery to the boot partition instead of having its dedicated partition, as it used to be until a couple of Android versions.
TL;DR: maintainers post these statements so users can discard possible known causes of issues beforehand, and to avoid complaints about pieces of work that aren't their responsibility at all.
Click to expand...
Click to collapse
Imho and experience this nearly always down to the Xposed modules not xposed itself. I have been using xposed since my Galaxy S and its been reliable and solid enough that after 10 Samsung devices later (S, S2, S4, S5, Note5, S6, S7, S7edge, Note9, S20FE) I will always install it. And the Xposed modules I run ar XpirvacyLua, Firefds kit [Q], GravityBox [Q] which are then Managed by EdXposed. I tend not to update the modules unless there is a specific issue that an update will fix.
Nope, check the twrp thread i the section we are upto 3.7.x which supports Android 12 (and should support 13 due to it being an incrmental update on 12).
Thats a fair comment.

Hello, is there a possibility to release this also for snapdragon?

Database Info

welcome