SnooperStopper
Android device ecryption password manager and failed unlock attempts monitor
SnooperStopper allows you to have different device encryption password than
screen unlock pattern/PIN/password. You can have strong device encryption
password (which you only need to enter once after booting your device) but
simple pattern/PIN/password for unlocking your screen.
If attacker tries to guess your simple pattern/PIN/password, he has only
few tries (default is 3) after which the device is rebooted and he needs
to enter your strong device encryption password again.
Where to get it:
Google Play
Eutopia.cz F-Droid Repository
Project on GitHub
Why is it needed:
Android always sets device encryption password same as screen unlock pattern/PIN/password.
This is very unfortunate, because you should have encryption password as strong
as possible, but nobody wants to enter long password all the time just to unlock screen.
There is Android issue #29468
requesting different passwords for encryption and screen lock, but it seems to be
ignored by Google (it is there from 2012 and recently marked Obsolete by Google).
How to use it:
After installation, start SnooperStopper and grant it superuser permissions. Then
enable device admin in app, which allows SnooperStopper to monitor failed screen
unlock attempts and reboot device if maximum number is exceeded.
Whenever you change your screen unlock pattern/PIN/password, Android also changes
your device encryption password, so you have to set your strong encryption
password again. SnooperStopper automatically opens window where you can change it
right after you change your screen unlock pattern/PIN/password, so you should never
forget about it.
Requirements:
Android >= 4.0.3
enabled device encryption (Settings => Security => Encrypt phone )
root (Android doesn't allow apps to change device encryption password or reboot your device without root access)
Credits:
Whole device encryption password changing code is taken from Nikolay Elenkov's
Cryptfs Password Manager.
XDA:DevDB Information
SnooperStopper, App for all devices (see above for details)
Contributors
Mikos, Nikolay Elenkov
Source Code: https://github.com/xmikos/SnooperStopper
Version Information
Status: Stable
Current Stable Version: 1.3
Stable Release Date: 2016-03-21
Created 2015-07-13
Last Updated 2016-03-21
Hello,
Thanks for your great tool, this really fills the gap between a safe encrypted and a everyday easy to use device.
Unfortunately I can't change the encryption password on my maguro galaxy nexus device.
When I try to change my encryption password I get the message cannot get super access
For a short time the root access symbol lights up and disappears.
Snooper Stopper is listed in the device admin list. My nexus (which runs on slim rom lollipop ) asked me whether I would like to give root access to snooper stopper and I agreed.
I'd really like to help to fix this bug so I can use your tool.
Many greetings
Michael
P.S. Already opened a issue at github before I found this thread on xda
mischasworld said:
Unfortunately I can't change the encryption password on my maguro galaxy nexus device.
When I try to change my encryption password I get the message cannot get super access
For a short time the root access symbol lights up and disappears.
Snooper Stopper is listed in the device admin list. My nexus (which runs on slim rom lollipop ) asked me whether I would like to give root access to snooper stopper and I agreed.
Click to expand...
Click to collapse
Like I said on GitHub (writing it also here for reference):
It is problem with SELinux policy. if you have Android >= 5.0, you also need sepolicy-inject utility (you can find it here: setools-android with sepolicy-inject) or supolicy (part of SuperSU - but SuperSU is not opensource, so I highly discourage it).
New version 1.3 is compatible with Android 6 and CyanogenMod 13. Also starting from version 1.1 sepolicy-inject tool is included into SnooperStopper, so you don't need to install any external utility.
Hello,
I've tested the full verified boot stack of Nexus 5X, to better understand the various implications, especially for my SuperUser project ( http://forum.xda-developers.com/android/software-hacking/wip-selinux-capable-superuser-t3216394/ ).
First of all, I'd like to say that they took time, but with this bootloader, Google did a really nice piece of security, without excluding alternate ROMs. (No doubt they got their inspiration from Chrome project, which are(were?) ahead on the matter).
This means that we can have alternate ROMs, even possibly roots, without compromising our devices! (of course assuming root/ROMs do their part of the job)
Everything is explained in https://source.android.com/security/verifiedboot/verified-boot.html and https://source.android.com/security/encryption/index.html
For users who haven't got their hand on a Nexus 5X/6P yet, here are the various screens you might see on boot when booting a non official ROM: https://source.android.com/security/verifiedboot/verified-boot.html#user_experience
The bootloader has two states: locked or unlocked, nothing new here. locked won't let you flash, unlocked will.
But then, there are 4 boot state that can be shown (or not to the user):
- Green boot state: the device is locked and running Google's ROM. It's the only boot state which is not displayed by bootloader
- Orange boot state: the device is unlocked.
- Yellow boot state: the device is locked, running an alternate ROM
- Red state: This shouldn't happen, it means the boot.img has been badly signed. Could mean an attack is undergoing.
Yellow state has two different possible screens depending on if the boot.img is signed. The difference is, if it is signed, an ID is displayed: this is the fingerprint of the public key used to signed the boot.img.
This means that we, the users, have a way to always be sure we booted the boot.img made by the ROM developer.
The same way we know we are on a Google ROM when there is no warning screen, we know that we are indeed on the ROM we are expecting.
But wait, there is more! The bootloader gives to the TEE/Trustzone the public key of the boot.img, and the TEE/Trustzone changes its answers based on the public key.
The TEE/Trustzone answers are used to generate the key of the /data encryption.
This means that in locked mode, with a signed boot.img, a trusted keystore-owner (doesn't have to be Google), full disk encryption enabled, and dm-verity enabled, even if an attacker is capable of overwriting any part of eMMC through either a privilege escalation, or physical attempt, trying to phish you to prompt your password, then the attacker won't get access to your data!
The TL;DR is, it is now possible to be as secure as original Google's ROM with a custom ROM (you still have to trust Google though) thanks to verified boot features.
Here are my advices to fully benefit from this feature:
- KEEP Full Disk Encryption (forceencrypt)
- KEEP keystore/keymaster/qseecomd
- Lock bootloader back
- Use custom security keys, including verity key, and keep them safe.
- Sign boot.img (this is default AOSP behaviour I think)
- Use a different security key for recovery (so recovery won't ever access to your userdata)
- Untick "OEM unlocking" if you feel safe about your ROM, to have Factory Reset Protection working (ie anti-theft feature)
For unknown quality ROMs:
- When first booting a new ROM/security key, try to memorize the fingerprint. If you don't memorize it all, try to memorize characters are random position, not the beginning.
- When the device asks for you deciphering password, check you booted the proper fingerprint. Do that especially if you have unexpected reboots.
Even though I consider this is a really great step forward to having secure alternate ROMs, there are some downsides:
- There is no "verified" mode where you can flash anything, but it does apply the security policy. This makes TWRP/Flashfire/CWM/a proper OTA system needed to be able to flash again without erasing all data
- The fingerprint is 6bytes/48bits, this is by far lower than most security standards. Also, some algorithms make ascii-art from fingerprints to help user recognize matching fingerprint.
- Changing ROM is complicated: you either need to resign all ROMs with your own key, to factory reset or "transmit" in clear the cipher key
Despite the the downsides, I hope to convince some ROM devs, and users to go to lock mode and check they implemented my various advices.
Please note that this security works only on Nexus 5X/6P, it doesn't work on N6 or N9.
Next step is to add ability for the end user to create a chain of trust in bootloader area.
User must have the way to blow it's own public key to the SoC Qfuses/Qfprom and to sign a chain of bootloaders and activate a Secure Boot after that.
---
Sony Xperia A2 SO-04F (Japan version of Z1 Compact)
Did someone check the second public key emplacement in Qfuses is locked?
New piece of information about this feature, this should become widespread amongst devices.
The Android comformity document for Android M ( https://static.googleusercontent.co...com/fr//compatibility/6.0/android-6.0-cdd.pdf section 9.10) states that verified boot is mandatory.
It is/was unclear whether this document refers to https://source.android.com/security/verifiedboot/verified-boot.html, or just requires any verified boot.
But a commit in Qualcomm's bootloader gives some signs:
https://www.codeaurora.org/cgit/qui...3&id=3b6a87e4556587b3cc0c652ada680b7284d2fae7
"platform: msm_shared: update for bootloader's requirements."
It could be some overthinking, but anyway this means that all Android M-native devices will have this feature (OR be fully locked, this is allowed as well :/)
This is IMO a really great news as this means we will be able to have secure ROMs on all devices!
How could you have a secure custom ROM if you don't have ability to blow your own key (with wich partition's hashes is signed) to a SoC Qfuses/Qfprom?
---
Sony Xperia A2 SO-04F (Japan version of Z1 Compact)
I said it in my post. The encryption of /data is computed by the TZ and based on the public key of boot.img
I even think FRP is kept, though I don't really want to play with that
phhusson said:
Hello,
I've tested the full verified boot stack of Nexus 5X, to better understand the various implications, especially for my SuperUser project on N6 or N9.
Click to expand...
Click to collapse
Thanks for this.
Just a few questions (with respect to the nexus 6P):
1. Do you upload a custom keystore via "fastboot flash keystore" (nexus 6P)?
2. Will changing the key store as per (1) affect the OEM keystore (i.e. is that separate)?
3. Would you mind sharing how you made your own keystore?
- edit: found your repo https://github.com/phhusson/super-bootimg/tree/master/scripts
4. After you relock the bootloader, how are you supposed to flash a custom recovery given that there is no verified mode? My undestanding is that the stock recovery has to be in place before locking the bootloader (for data wipe to occur). Or does the locked state also use the custom keystore?
5. On a somewhat related matter, say you have no custom keystore and the boot chain is compromised so that the phone boots into the red state. Are you still able to access the android OS? I've seen conflicting information on this.
ceribik said:
1. Do you upload a custom keystore via "fastboot flash keystore" (nexus 6P)?
5. On a somewhat related matter, say you have no custom keystore and the boot chain is compromised so that the phone boots into the red state. Are you still able to access the android OS? I've seen conflicting information on this.
Click to expand...
Click to collapse
Although the keystore partition is flashable, it is useless.
The only thing checked is the public key with which is signed the boot.img
Thus the only red state possible is because of dm-verity.
The anti-signature change is provided by the fact that data are encrypted with a key based on the public key of the boot.img
2. Will changing the key store as per (1) affect the OEM keystore (i.e. is that separate)?
Click to expand...
Click to collapse
Nope. Even in CAF implementation which handles keystore, the state is different between OEM keystore and user keystore.
(Yellow in user keystore, green in oem keystore)
3. Would you mind sharing how you made your own keystore?
- edit: found your repo https://github.com/phhusson/super-bootimg/tree/master/scripts
Click to expand...
Click to collapse
Though it is mostly useless. The only use is for CAF devices, with verified mode.
4. After you relock the bootloader, how are you supposed to flash a custom recovery given that there is no verified mode? My undestanding is that the stock recovery has to be in place before locking the bootloader (for data wipe to occur). Or does the locked state also use the custom keystore?
Click to expand...
Click to collapse
I haven't checked that part yet, but I don't think you need original recovery.
But yes, the no-reflashing annoys me a lot, it means a custom ROM MUST provide an OTA system.
5. On a somewhat related matter, say you have no custom keystore and the boot chain is compromised so that the phone boots into the red state. Are you still able to access the android OS? I've seen conflicting information on this.
Click to expand...
Click to collapse
As mentioned earlier, I'm only aware of dm-verity-based red state, which can indeed be bypassed.
I hope this answers your questions, don't hesitate to ask for more
Dude I really wanna pick your brain on this. It's sad I arrive late to these parties Anyways I have a Pixel and believe this is more relevant than ever now because verified boot is strictly enforced. I want to have a modified phone with custom ROM & locked bootloader but after flashing super TWRP/SU/EX to kernel I'm positive it breaks signing.
So my question is how can I re-sign the kernel after it had been modified by SuperSU/TWRP/EX Kernel etc? I would like to flash my own keystore.img and sign the boot.img so my phone will boot with yellow warning. Can it only be done with a full build environment at compile time or can I grab some tools, generate the keystore & sign an image that pull with dd? This is something that is very new to me & there is really no step-by-step for this that I've found.
Please forgive me for my lack of knowledge on this subject but I am desperate to have a modified kernel /system and the ability to re-lock my boatloader. I can live without the dm-verity since I have a tendency to modify system files on a regular basis anyways. I sent you a PM cause I had lost this page. If I can figure out a step by-syep process to do this that didn't require a whole build env I can probably script a tool once I know necessary commands and tools.
So far I've generated my keystore keys
1.
Code:
/make_key keystore '/C=US/ST=California/L=Long Beach/O=Android/OU=Android/CN=Android/[email protected]'
now I am trying to figure out the keystore image.
2.
Code:
java -Xmx512M -jar BootKeystoreSigner.jar keystore.pk8 keystore.x509.pem keystore.img
Geofferey said:
Dude I really wanna pick your brain on this. It's sad I arrive late to these parties Anyways I have a Pixel and believe this is more relevant than ever now because verified boot is strictly enforced. I want to have a modified phone with custom ROM & locked bootloader but after flashing super TWRP/SU/EX to kernel I'm positive it breaks signing.
So my question is how can I re-sign the kernel after it had been modified by SuperSU/TWRP/EX Kernel etc? I would like to flash my own keystore.img and sign the boot.img so my phone will boot with yellow warning. Can it only be done with a full build environment at compile time or can I grab some tools, generate the keystore & sign an image that pull with dd? This is something that is very new to me & there is really no step-by-step for this that I've found.
Please forgive me for my lack of knowledge on this subject but I am desperate to have a modified kernel /system and the ability to re-lock my boatloader. I can live without the dm-verity since I have a tendency to modify system files on a regular basis anyways. I sent you a PM cause I had lost this page. If I can figure out a step by-syep process to do this that didn't require a whole build env I can probably script a tool once I know necessary commands and tools.
So far I've generated my keystore keys
1.
Code:
/make_key keystore '/C=US/ST=California/L=Long Beach/O=Android/OU=Android/CN=Android/[email protected]'
now I am trying to figure out the keystore image.
2.
Code:
java -Xmx512M -jar BootKeystoreSigner.jar keystore.pk8 keystore.x509.pem keystore.img
Click to expand...
Click to collapse
Off the top of my head, you have to add the public signing keys to the root directory of the ramdisk in the boot.img, and then sign the boot.img with the private keys.
I think the image is signed with the verity keys, and the public key has a special form for nougat/7.1/14.1, with some rounding. I think marshmallow was different. From the android build environment, you can use "make generate_verity_key". The actual source is here system/extras/verity if you just want to compile the pieces parts.. The script will be in the out/host directory if you use the make command. Use the convert option "generate_verity_key -convert <path-to-x509-pem> <path-to-key>" to convert the keystore.x509.pem cert that you made. This script will generate the public key in the just the right form that android is looking for. This is what goes into the root of the ramdisk. I think it has to be named verity_key. Yes, I know you aren't turning on dm-verity for the system image, but the boot is signed with the same key.
There is probably a script in one of the aosp repos that will make and sign the boot image. You want to find that and figure out what it is doing.
The finger print will be the first 6 words from the sha1 fingerprint:
Code:
openssl x509 -noout -in keystore.x509.pem -fingerprint -sha1
Hope that helps.
Edit: In the system/extra/verity dir, there is a boot_signer script that references a bootsignature.jar that might do what you are looking for. You'll probably have to build it since it will be in the out/host/ directory somewhere. or just hotwire the java yourself.
Off the top of my head, you have to add the public signing keys to the root directory of the ramdisk in the boot.img, and then sign the boot.img with the private keys.
I think the image is signed with the verity keys, and the public key has a special form for nougat/7.1/14.1, with some rounding. I think marshmallow was different.
There is probably a script in one of the aosp repos that will make and sign the boot image. You want to find that and figure out what it is doing.
The finger print will be the first 6 words from the sha1 fingerprint:
Hope that helps.
Click to expand...
Click to collapse
I'm slowly starting to figure this out, but I have one problem. On the Pixel there is no keystore partition so I can't flash my keystore.img. Do I need to flash a keystore for my signed images to boot? If not I will continue and sign but it was my understanding that I would need that. I suppose I should also grab the verity tools from a 7.0 tree instead of phhussons repo?
Geofferey said:
I'm slowly starting to figure this out, but I have one problem. On the Pixel there is no keystore partition so I can't flash my keystore.img. Do I need to flash a keystore for my signed images to boot? If not I will continue and sign but it was my understanding that I would need that. I suppose I should also grab the verity tools from a 7.0 tree instead of phhussons repo?
Click to expand...
Click to collapse
The pixel night be different, but I think the signature is appended to the boot.img. i don't think you need the keystore partition? I could be wrong. The fingerprint lets you know that it wasn't re-signed by a different key.
I think you want to use a nougat branch for sure.
Pixel Locked Bootloader Custom ROM / Kernel
Okay so I got this whole thing figured out. Just had to read stuff all over the place. Everything we need is in phhussons repo under the keystore_tools and the 6.0 CAF tree will suffice. I knew I was close.
BTW: I only recommend this for flawless ROMs with no major issues. Once re-locked DO NOT disable Allow OEM Unlock in the developer options menu unless you are 100% sure your phone will boot especially after /data wipes etc. Do not make modifications of any kind in a locked state with OEM unlock off. I learned the hard way with a 5X when I tried to dd a vendor.img via adb on a locked bootloader without TWRP. Don't do anything crazy! You have been warned!
Here is how you can re-sign after mods beofore re-locking a Pixel.
Grab boot images from android (needs root or twrp):
I actually used Android Terminal Emulator for this step
Code:
sailfish:/ # cd /dev/block/platform/soc/624000.ufshc/by-name
sailfish:/dev/block/platform/soc/624000.ufshc # dd if=boot_a of=/sdcard/boot_a.img
sailfish:/dev/block/platform/soc/624000.ufshc # dd if=boot_b of=/sdcard/boot_b.img
Generate Keystore:
Code:
./make_key keystore '/C=US/ST=California/L=Long Beach/O=Android/OU=Android/CN=Android/[email protected]'
openssl rsa -in keystore.pk8 -inform der -outform der -pubout -out keystore.pub.pk8
Sign the boot Images:
Code:
java -jar BootSignature.jar /boot boot_a..img keystore.pk8 keystore.x509.pem boot_a_signed.img
java -jar BootSignature.jar /boot boot_b..img keystore.pk8 keystore.x509.pem boot_b_signed.img
Reflash with fastboot:
Code:
fastboot flash boot_a boot_a_signed.img
fastboot flash boot_b boot_b_signed.img
Relock the bootloader (will erase device)
Code:
fastboot oem lock
One thing I have noticed is the fingerprint isn't displayed on boot, yet still starts up fine. Maybe it's because I didn't place the .pub key in ramdisk before signing? It could also be due to the use of CAF & not AOSP tools. In any case I got the pixel to boot yellow in a locked state after modifying the kernel.
I'm a newbie compared to you guys and I had problems running Java. I've unpacked the boot image and repacked it after modifications. I have also generated keys and I'm wondering if there is a script (Python?) that I can run to sign the boot image? Also, where should I copy the public key inside the ramdisk? This is for a 7.0.1 Nougat boot image of OnePlus 3. Thanks,
Unfortunately there is no other method that I have found to sign boot images with besides the BootSignature.jar in phhusson's repo. You could also setup a build environment but the method I described is magnitudes simpler. Both methods require java there is no python script to perform this. You put the .pub key at root of RAM disk renamed as verity_key. I think that's only required if you are using dm-verity and a generated tree for your system image.
What OS are you running? I did my signing in Ubuntu.
Was this tested on OnePlus 5 by anyone before?
Geofferey said:
Okay so I got this whole thing figured out. Just had to read stuff all over the place. Everything we need is in phhussons repo under the keystore_tools and the 6.0 CAF tree will suffice. I knew I was close.
BTW: I only recommend this for flawless ROMs with no major issues. Once re-locked DO NOT disable Allow OEM Unlock in the developer options menu unless you are 100% sure your phone will boot especially after /data wipes etc. Do not make modifications of any kind in a locked state with OEM unlock off. I learned the hard way with a 5X when I tried to dd a vendor.img via adb on a locked bootloader without TWRP. Don't do anything crazy! You have been warned!
Here is how you can re-sign after mods beofore re-locking a Pixel.
Grab boot images from android (needs root or twrp):
I actually used Android Terminal Emulator for this step
Code:
sailfish:/ # cd /dev/block/platform/soc/624000.ufshc/by-name
sailfish:/dev/block/platform/soc/624000.ufshc # dd if=boot_a of=/sdcard/boot_a.img
sailfish:/dev/block/platform/soc/624000.ufshc # dd if=boot_b of=/sdcard/boot_b.img
Generate Keystore:
Code:
./make_key keystore '/C=US/ST=California/L=Long Beach/O=Android/OU=Android/CN=Android/[email protected]'
openssl rsa -in keystore.pk8 -inform der -outform der -pubout -out keystore.pub.pk8
Sign the boot Images:
Code:
java -jar BootSignature.jar /boot boot_a..img keystore.pk8 keystore.x509.pem boot_a_signed.img
java -jar BootSignature.jar /boot boot_b..img keystore.pk8 keystore.x509.pem boot_b_signed.img
Reflash with fastboot:
Code:
fastboot flash boot_a boot_a_signed.img
fastboot flash boot_b boot_b_signed.img
Relock the bootloader (will erase device)
Code:
fastboot oem lock
One thing I have noticed is the fingerprint isn't displayed on boot, yet still starts up fine. Maybe it's because I didn't place the .pub key in ramdisk before signing? It could also be due to the use of CAF & not AOSP tools. In any case I got the pixel to boot yellow in a locked state after modifying the kernel.
Click to expand...
Click to collapse
Signing the boot image.
What does it actually do? From the semantics, it looks like it is signing the boot image with the generated private key.
How does the bootloader in the device know to trust the images(like recovery, system or roms) signed with this private key?
praveenkv1988 said:
Signing the boot image.
What does it actually do? From the semantics, it looks like it is signing the boot image with the generated private key.
How does the bootloader in the device know to trust the images(like recovery, system or roms) signed with this private key?
Click to expand...
Click to collapse
See the class B implementation of verified boot.
https://source.android.com/security/verifiedboot/verified-boot
The boot is signed with the key and it is verified against the included certificate. Yes, someone else could just sign the boot image with their key, but you can verify the fingerprint when the device boots to make sure it was signed with the correct key. This makes it tamper evident, not tamper proof.
The rom itself should use dm-verity to check the integrity at the block level. The boot image, which is signed, has the dm-verity public key so that the rom can be verified. Similar verification process can apply to recovery if it is signed and has dm-verity. Most don't, but it is certainly possible to do.
Since lineageos builds are signed by their private key, Can we just lock the bootloader after installing lineageos? Will it boot in yellow state?
praveenkv1988 said:
Since lineageos builds are signed by their private key, Can we just lock the bootloader after installing lineageos? Will it boot in yellow state?
Click to expand...
Click to collapse
On 14.1- the locked bootloader will show the yellow state and the LOS key fingerprint. But, if you don't lock down the recovery, there's little point in locking the bootloader. It also seems risky to lock the bootloader with a rom that is signed with a private key that you don't control. Depending on the phone, you night not be able to decrypt data in recovery (think backups).
On 15.1, I think things are more complex and this or related parts in LOS might not be working yet.
My bootloader is locked and I was trying to upgrade my n5x to 15.1 yesterday and all I got were bootloops. I reverted to 14.1 and recovered, but there are no guarantees.
Lastly, the way you asked the question makes me think you shouldn't lock you bootloader. Not trying to be mean or rude, but I am trying to prevent you from losing your data or being locked out of your phone. The hard part about locking the bootloader is that you can't use fastboot to flash things like radios, vendor images, etc.
If you don't have a Linux device or don't have enough storage space to compile Custom Recovery, then maybe the following link can help you.
- Visit my GitHub repository and Fork it
(https://github.com/VThang51/ROM_Recovery-Builder)
-(Don't forget to read the README.md)
- Custom Recovery versions are supported:
+ OrangeFox-RP Builder (Fixing Bug)
+ PitchBlack-RP Builder
+ RedWolf-RP Builder
+ SkyHawk-RP Builder
+ TeamWin-RP Builder
- If the compilation is successful, please comment below. Just like TWRP, I also want to hear your story
Nice but i need to learn how to build twrp first haha
Guan Yu said:
Nice but i need to learn how to build twrp first haha
Click to expand...
Click to collapse
Nice, If you have a device tree and make sure it doesn't fail. I will guide you haha
I'm trying this out right now with the oneplus 7 pro 5g since there's like no development active on this specific model
TechX1991 said:
I'm trying this out right now with the oneplus 7 pro 5g since there's like no development active on this specific model
Click to expand...
Click to collapse
Make sure your Device tree is not corrupted. Because when it fails, it will have to start over and it takes at least 20-60 minutes
VThang0511 said:
Make sure your Device tree is not corrupted. Because when it fails, it will have to start over and it takes at least 20-60 minutes
Click to expand...
Click to collapse
I was using device trees from Lineage's github, but seems 3 devices i've tried so far all fail with
fatal: Remote branch master not found in upstream origin, error exit code 128
TechX1991 said:
I was using device trees from Lineage's github, but seems 3 devices i've tried so far all fail with
fatal: Remote branch master not found in upstream origin, error exit code 128
Click to expand...
Click to collapse
Haha, This error is quite rare if you double check the options. This error says your Branch is not "master" (It's just the Branch name on my URL). Double check the Branch name on GitHub.If you don't know, send me the device tree link and I'll compile it for you
VThang0511 said:
Haha, This error is quite rare if you double check the options. This error says your Branch is not "master" (It's just the Branch name on my URL). Double check the Branch name on GitHub.If you don't know, send me the device tree link and I'll compile it for you
Click to expand...
Click to collapse
just my luck, I get the "rare" error multiple times lol it was more for the learning of it that I was doing this. TWRP is available for the 3 devices I tried (op 7 pro 5g, op 8t and op 6t), but wanted to learn to do it so I can try it on lesser known devices like asus zenphone 1 or razer phone 2