Related
Hi everybody,
unfortunately I couldn't find a final answer to my question:
I know (or I think I know from your excellent forum):
- I can extract a stock ROM (and modify it)
But:
- can I resign the whole ROM using my own signature key, flash it back on the device and then use this to build an app (and sign/add/install it) running with e.g. android:sharedUserId="android.uid.phone" and androidrocess="com.android.phone" ?
In other words: can I replace the system signature key of a stock ROM with my own one, being able to sign my own apps with it? Or is that only possible by building the whole (custom) ROM myself?
I don't need a detailled description, a 'Give it a try!' or 'Wouldn't work because of...' however would be great!
Thanks,
deep blue
ps: any legal advice or warning is welcome, too, although I only want to dig a little deeper into my own phone.
yes you can
go to /system
and look for the build.prop
open it and
ro.build.display.id= Put Your rom name here
Thanks for your answer, locomain!
Maybe I didn't explain that correctly:
I don't mean the signature you can see when checking the phone-info. I'm thinking about the key, the ROM is signed with. If you sign your app with the same key, you can do much more stuff. As an example, my old HTC Desire came with a hidden app that displayed a lot of low-level radio-stuff (Field-Test-Monitor). This is only possible because this app is signed with the same key as the system itself.
My idea was to take a stock HTC-ROM and resign it with my own key, so I could build an app with extraordinary privileges for my own phone (like the app described above).
BR,
deep blue
Please use the Q&A Forum for questions Thanks
Moving to Q&A
[Q+A] [ROM] Resign stock ROM with my own signature key
For those who are interested:
using a downloaded CyanogenMod-signed-zip it worked, I just removed all signatures (from zip and all included apks) and re-signed everything using my own key. Afterwards I was able to create a small app that is allowed to run in the com.android.phone-process.
So I think it should work with stock-ROMs also, as long as I root them by the way.
What all goes into signing a ROM, and why can't someone take CM and sign it as if it was from Samsung? I'm guessing it's more than copying and pasting a few files, but why can't this be done? In concept it sounds easier than unlocking the bootloader. Is it known where the files that contain the keys are? Are the keys for each device different?
PetersDrue said:
I'm not an Android developer. I'm learning C++, and I have decided to put off learning Java, although some of the syntax looks similar (except for the 100,000,000 classes required for a Java program. I do know Android is run from a virtual machine and is based off of Java and other basic knowledge.
Anyway, I love my Cyanogen Mod and I didn't pay attention to unlocking the bootloader when I first got my phone. Now I'm really missing CM 11.
I know the bootloader checks to see if the ROM is signed by Samsungnd only then will it allow the ROM to be installed. (I'm a computer and Android enthusiast, some more technical info would be appreciated with these processes).
What all goes into signing a ROM, and why can't someone take CM and sign it as if it was from Samsung? I'm guessing it's more than copying and pasting a few files, but why can't this be done? In concept it sounds easier than unlocking the bootloader.
Click to expand...
Click to collapse
Do you have the encrypted key sets available that it checks against? No? Well then...
lycwolf said:
Do you have the encrypted key sets available that it checks against? No? Well then...
Click to expand...
Click to collapse
Are the keys unique to each device?
PetersDrue said:
Are the keys unique to each device?
Click to expand...
Click to collapse
This has been asked and answered over and over again.
It's a digital signature, which means that all of the binaries are signed using the same private key, which I'm sure Samsung has well locked down.
It's a sufficiently secure methodology that the only way we could sign custom binaries would be for someone at Samsung to leak the key.
Please don't suggest brute forcing it (it'd take several thousand years), removing it (won't work), copying it from one file to another, etc.
All of these have already been suggested by those unfamiliar with the technology being used.
k1mu said:
This has been asked and answered over and over again.
It's a digital signature, which means that all of the binaries are signed using the same private key, which I'm sure Samsung has well locked down.
It's a sufficiently secure methodology that the only way we could sign custom binaries would be for someone at Samsung to leak the key.
Please don't suggest brute forcing it (it'd take several thousand years), removing it (won't work), copying it from one file to another, etc.
All of these have already been suggested by those unfamiliar with the technology being used.
Click to expand...
Click to collapse
I normally do research before I ask a question; this is an exception. I understand what ii is in general. I wouldn't suggest brute forcing. Several thousand years is most likely an understatement. The length of time exponentially increases for each added character. Removing it obviously won't work because then there is no signature to verify.
I was asking about the location because I thought it might be possible to port the key to a different ROM but I am unfamiliar with this technology.
Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
oxiroxt said:
Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
Click to expand...
Click to collapse
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
synesthete said:
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
Click to expand...
Click to collapse
OMG Finally some light! THANK YOU, THANK YOU, THANK YOU for all the info. I didn't get much right now, I'll need to read through your post a few times before I get it all, haha. I'll be sure to check the links too. Thank you!
Hi folks.
I'm an Android firmware developer (you can see my posts here in xda) that got a yoga book yesterday. For me it works at it should (by now) but my hacker soul speak to me and said: "at least take a look to see what you can get from this device". I don't have many time, so I can't spend time doing roms or fixing things by myself, but I can share with you some info I get and help you with my knowledge if someone is interested in "play" with this device.
First of all, I'm not responsable of anything that you can break following these steps. Almost all of them are tested and with some common sense you will not break anything, and if you break anything I will try to help you to fix it (if you are polite), but this is a work in progress and hacking and the possibility of brick the device is always there.
I only have the Android version without LTE, so I only tested in my Book.
So, here we go:
1) Secret codes:
I get this codes decompiling EngineeringCode.apk with apktool. Be carefull with them:
####0000# - Display version info
####7599# - Display hardware info
####8375# - Display baseband info
####1111# - Factory test
####2222# - Display SN
####7777# - Factory Reset???
####5993# - Display internal frameWork version
####7642# - Cut the power off to reload the PMIC - This command shutdowns the device. Just press the power button to reboot.
####5236# - Display LCD name
####2834# - ES close test
####8899# - open the ums mode default for debug
####3333# - offline log
####3334# - offline modem log
####9527# - Mediaplayer setting
####78646# - RunIn test
####6020# - switch country code
####59930# - Display current country code
####8746# - Enter engineering mode
####4227# - Enter engineer test
####357# - DLP_TEST
To use these codes, open the contacts app, press the search button and enter the code in the search bar.
2) OTA Images
You can get OTA images directly from lenovo servers. Just open your browser and paste this url:
http://fus.lenovomm.com/firmware/3....WW06_BP_ROW&action=querynewfirmware&locale=en
Change device model if needed (LenovoYB1-X90F or LenovoYB1-X90L)
Change curfirmwarever to a valid OLD firmware, this way you will get the next one in age.
Change locale if needed.
With this url you will get a download url at the end of the result page. In this case: http://tabdl.ota.lenovomm.com/dls/v...S000426_1705080316_WW06_BP_ROW_WC80C2A0F2.zip
These images are not full ota images, they are diff versions. This means that we can't use them to mod the image, or recover a bricked device, but this is a first step
3) Custom images
We don't have real sources to build a custom image (the lenovo's open source files are useless), but this doesn't mean that we couldn't modify stock images to take out useless apks or get better performance.
We can get this using an Android Kitchen and a full update image for the device.
As Android kitchen you can use SuperR kitchen (https://forum.xda-developers.com/ap...chen-superr-s-kitchen-v1-1-50-v2-1-6-t3597434)
As full image, I only tested the one here (https://easy-firmware.com/index.php?a=browse&b=category&id=19521) because I can't download any newer one.
I tested uncompressing it, deodexing the apks and doing a new image. But I don't test it in the device because I need to install twrp to flash the new image and I don't have time to test. But this should work, I did it many times so if someone is interested I can give steps to do it and support for testing.
If someone can get the latest full images, send then to me and maybe I can get some time to do some tests.
PD: Probably we could use this as a base to get LineageOS 14.1 working: https://github.com/latte-dev/android_device_xiaomi_latte/tree/cm-14.1
So, if you are interested in some hacking with the Yoga Book, contact me and we could team to get the most of this device.
First of all thank you for your post, it´s really useful
if you could somehow manage to boot windows on this machine it´s by far the greatest war we have right now.
Il promise you a lunch or dinner on Lisbon whenevere you want!
joao1979 said:
First of all thank you for your post, it´s really useful
if you could somehow manage to boot windows on this machine it´s by far the greatest war we have right now.
Il promise you a lunch or dinner on Lisbon whenevere you want!
Click to expand...
Click to collapse
Sorry, my knowledge of Windows is only user level . Install it in personal computer to play games .
But I really don't know why people wants to run Windows there, it will go slowly than Android and its less touch oriented... but I suppose that this is a chat for another thread
corvus said:
Sorry, my knowledge of Windows is only user level . Install it in personal computer to play games .
But I really don't know why people wants to run Windows there, it will go slowly than Android and its less touch oriented... but I suppose that this is a chat for another thread
Click to expand...
Click to collapse
in my particular case, i´l admit that is for football manager the touch version
joao1979 said:
in my particular case, i´l admit that is for football manager the touch version
Click to expand...
Click to collapse
Have you tried running it through Crossover? It may be in its infancy but i have got a few apps running OK with it.
I have the full "YB1-X90F_USR_S000196_1611040312_WW06_BP_ROW" I can upload somewhere if anyone can suggest a good site to do so without signing up? The file is about 2.5gb
It will be great if we could get the latest version, because maybe these older versions have older files that we have updated in our tablets.
Mixing files could give unknown problems
The current TWRP is based on the new Yoga Tab 3
I am starting to think they do not do full roms for this in the same way they do for a lot of their other devices.
We know the otas are available from tabdl.ota.lenovomm.com/dls/v6/ and are named according to the 2 builds that it bridges. As easy-firmware had the december full rom under the file name B1-X90F_USR_S000196_1611040312_WW06_BP_ROW-flashfiles.zip I had hoped that I could work out the file path to pull it down.
There were some interesting ideas here, https://forum.xda-developers.com/android/help/how-download-stock-roms-lenovos-ota-t3109507 but it seems there is a difference between phonedl.ota and tabdl.ota
Queries to full roms that work for phones, don't seem to work for the yoga book.
Anyone with more web knowledge able to pick this up? I am not sure the files are there but I feel they should be.
Good luck
Update: the downloads seem to be hosted via CloudFront. An Amazon service, but I can not find out a way of listing the available files. The latest full rom would be
http://tabdl.ota.lenovomm.com/dls/v6/YB1-X90F_USR_S000426_1705080316_WW06_BP_ROW_WC80C2A0F2.zip
But the Last 8 chars are random and we do not know what they are.
So we have two hopes. First work out the right query to the link from fus.lenovomm.com or two find a way of listing files available in tabdl.ota.lenovomm.com/dls/v6
Not sure I have got much further but ill keep trying when I can.
Hey, I should mention that I have some files that you may find helpful; I got them from the easy firmware website. They're all the .img files for each partition in Android (ie. boot.img, cache.img, config.img, factory.img, recovery.img, system.img) as well as: biosupdate.fv, bootloader, firmware.bin and gpt.bin. However, these of course aren't in the normal "flashable .zip ROM" format. So unless you know how to take apart these .img files they aren't very useful. If you need any more help or have any other questions about how far we've come on our own, feel free to ask. danjac also has great knowledge of our efforts.
Yes, I know how to use them, unpack, modify, etc. But what I want is the latest version, no a old version (I hav these files too). If you have them I can do some changes, debloat, etc.
Anyway, I see little interest in custom roms in this forum ( probably because it's not a device with a lot of users or the users are not the techy kind), so I prefer to help others with info than do a custom rom that only 2 or 3 people will use. Doing custom roms is a time hungry task and probably it doesnt worth the effort. Anyway this device is not full of bloatware like samsung ones, so it useable as it is.
As I said in my first post if anyone is interested I can give some hints and support to modify the full image (but only the latest one).
It's so sad that there are only a few interested owners of this tab - it's such a nice device but i fear the day lenovo decides to end their support for it. There will be no custom roms to switch to and keep the device alive - it will be a soon to be bit of old tech garbage BTW. I still use my Asus Transformer Prime because of the nice community
@NiffStipples I fully agree. This device is so powerful and its a suprise that it is invisible to the "market". In my humple opinion the normal ROMs aren't that bad besides missing updates but I would love to see all the power served through a custom rom. unfortunately programming is not my business
Stefan
Broomfundel said:
Have you tried running it through Crossover? It may be in its infancy but i have got a few apps running OK with it.
Click to expand...
Click to collapse
Interesting - is Crossover good (and does it require factory reset)?
Hi, It works well with some things and not others. Often the why and where are not obvious. It is basically "wine" the layer that allows some windows apps to run on a linux install. Tweeked to work with android. Just an install to put crossover on. Then another install (Within crossover), to put you app on crossover. If it doesn't work out of the box, there windows libraries you can switch out and dependencies you can install. (Eg: directx , .net) Even if your not technical. I would say get on the beta program and give it a try.
Hi! what do you mean by "lenovo's open source files are useless"? do you refer to this packet on lenovo's suppport site? download.lenovo.com/consumer/open_source_code/lenovo_yb1_x90f_l_osc_201608.zip
I've entered the Android YogaBook's BIOS and noticed that VT-X is enabled by default! With Limbo x86 we could get a fully working virtualized Windows or Linux, if it wasn't for... KVM. It seems like it's not enabled in Lenovo's default kernel. Could we get to recompile the kernel with this option on? i'm not a big android/ROM expert but i surfed the open_source_code folder from Lenovo and it seemed, to me, that we could rebuild the Kernel at least.
This could really change things!
morrolinux said:
Hi! what do you mean by "lenovo's open source files are useless"? do you refer to this packet on lenovo's suppport site? download.lenovo.com/consumer/open_source_code/lenovo_yb1_x90f_l_osc_201608.zip
I've entered the Android YogaBook's BIOS and noticed that VT-X is enabled by default! With Limbo x86 we could get a fully working virtualized Windows or Linux, if it wasn't for... KVM. It seems like it's not enabled in Lenovo's default kernel. Could we get to recompile the kernel with this option on? i'm not a big android/ROM expert but i surfed the open_source_code folder from Lenovo and it seemed, to me, that we could rebuild the Kernel at least.
This could really change things!
Click to expand...
Click to collapse
How did you enter the bios? Can you boot from usb?
anyone managed to use swiftkey keyboard?
I published a script that can automatically resign GrapheneOS OTAs with your own keys, and also optionally apply a few modifications like enabling ADB root (without turning on ro.debuggable), ignoring allowbackup and changing the update URL.
You can use it if you like GrapheneOS (I think it's the Android OS with the best engineering, security and privacy), but would also like to have full control of your device, by controlling the verified boot keys of your device and applying modifications that make the OS do what you want regardless of what upstream OS developers, app developers, or anyone else might want.
Note that, on the other hand, GrapheneOS follows the Google Android security model which says that the OS will not perform an action you want it to perform if it may result in something that "application developers, content producers, service providers, and employers" do not consent to (which means not letting you have root, or ignore app wishes regarding backups and other settings, or send arbitrary responses to app requests, etc.), while this script will let you do what you want with your own device regardless of whether it's in anyone else's interest or not, including things that this script does not itself support since you control the verified boot keys of the device and can thus sign anything; all this while still taking advantage of all the security and privacy features in GrapheneOS, including verified boot.
You can find it at https://github.com/chriswoope/resign-android-image
Currently it's intended for people with good technical knowledge, although once you set it up (if you run Qubes a lot of steps are automated) it should continue working with no or minimal intervention.
Thank you very much for this
Hi, do you still update your tools? I've changed quite some things while traing to get this running for a Pixel 7....
I had to adept quite some changes (e.g. for init_boot on A13 shipped device, incresed HeapSize for Java, as SmailPatcher crashes, problems while generating keys with signify-openbsd and also missing tools like zip and unzip on a fresh installed debian), but in the end I received a nice zip which I've flahsed to the device, but I ended up in a Bootloop (Google Logo, Graphene Logo, some seconds and then.. reboot).
So, did someone got this running with A13 (and at best also on a Pixel 7)?
pmatj said:
Hi, do you still update your tools? I've changed quite some things while traing to get this running for a Pixel 7....
I had to adept quite some changes (e.g. for init_boot on A13 shipped device, incresed HeapSize for Java, as SmailPatcher crashes, problems while generating keys with signify-openbsd and also missing tools like zip and unzip on a fresh installed debian), but in the end I received a nice zip which I've flahsed to the device, but I ended up in a Bootloop (Google Logo, Graphene Logo, some seconds and then.. reboot).
So, did someone got this running with A13 (and at best also on a Pixel 7)?
Click to expand...
Click to collapse
I was not able to get this working myself unfortunately
but using a different script called AVBRoot and using it on a self built build of GrapheneOS I am able to lock the bootloader with Magisk Root
I have created this guide to help people https://forum.xda-developers.com/t/...-using-rooted-grapheneos-magisk-root.4510295/
pmatj said:
Hi, do you still update your tools? I've changed quite some things while traing to get this running for a Pixel 7....
I had to adept quite some changes (e.g. for init_boot on A13 shipped device, incresed HeapSize for Java, as SmailPatcher crashes, problems while generating keys with signify-openbsd and also missing tools like zip and unzip on a fresh installed debian), but in the end I received a nice zip which I've flahsed to the device, but I ended up in a Bootloop (Google Logo, Graphene Logo, some seconds and then.. reboot).
So, did someone got this running with A13 (and at best also on a Pixel 7)?
Click to expand...
Click to collapse
Hey, did you ever get this working on Pixel 7?
User.Hemlock said:
Hey, did you ever get this working on Pixel 7?
Click to expand...
Click to collapse
You can use AVBRoot to patch and sign roms to get root with a locked boot loader using GrapheneOS
I wrote a guide here https://forum.xda-developers.com/t/...-using-rooted-grapheneos-magisk-root.4510295/
FireRattus said:
You can use AVBRoot to patch and sign roms
Click to expand...
Click to collapse
Thanks! Haven't had a chance to dig into AVBroot yet, but I'm guessing the patching capability would include things like ignoring allowbackup? (that was one of OP's features that I was interested in)
User.Hemlock said:
Thanks! Haven't had a chance to dig into AVBroot yet, but I'm guessing the patching capability would include things like ignoring allowbackup? (that was one of OP's features that I was interested in)
Click to expand...
Click to collapse
The main purpose of AVBRoot is to root and sign an image so that with pixel devices for example you can lock the bootloader and have root
With root you can achieve ignoring the allowbackup, I believe you could do this with xposed
I also just use root apps like Swift Backup to backup everything on my device