Related
Well I USB bricked my Desire last night.
To make things worse I was only able to apply the SD Card workaround via fastboot.
After flashing the update.zip from the modaco fix I instantly went back to the stock rom using the fastboot RUU process, without actually checking if it solved all the problems...
I know I had it coming...
Before I ship the phone out for repairs - maybe someone here knows if there is a chance to unbrick without root (nor having HBOOT version that allows to use any other method of rooting other than Unrevoked)
Code:
HBOOT 0.93
European 2.10.405 OTA
Thanks in advance
a more detailed description would help:
does your phone boot?
do you have running clockworkmod recovery?
did you do a nandroid backup before touching the system?
what modaco fix? give a link.
did you use unrevoked? thats the default root tool nowadays.
can you go to hboot/fastboot when pressing vol down while pressing power on?
Use a goldcard, it will enable you to put an unrooted Rom there. It's always a good reset option.
Sent from my HTC Desire using XDA App
mad-murdock said:
a more detailed description would help:
does your phone boot?
do you have running clockworkmod recovery?
did you do a nandroid backup before touching the system?
what modaco fix? give a link.
did you use unrevoked? thats the default root tool nowadays.
can you go to hboot/fastboot when pressing vol down while pressing power on?
Click to expand...
Click to collapse
Hi,
- the phone boots ok - It has most of the symptoms from All you need to know about USB-Bricks thread, the SD card started to work after issuing:
Code:
fastboot oem enableqxdm 0
This is the output from the fastboot oem boot command
Code:
$ fastboot-mac oem boot
... INFOsetup_tag addr=0xA0000100 cmdline add=0x8E07F9F0
INFOTAG:Ramdisk OK
INFOTAG:smi ok, size = 0
INFOTAG:hwid 0x0
INFOTAG:skuid 0x21F04
INFOTAG:hero panel = 0x0
INFOTAG:engineerid = 0x0
INFOMCP dual-die
INFOMCP dual-die
INFOTAG:mono-die = 0x0
INFODevice CID is not super CID
INFOCID is HTC__032
INFOsetting->cid::HTC__032
INFOserial number: HT057PL01634
INFOcommandline from head: no_console_suspend=1
INFOcommand line length =430
INFOactive commandline: board_bravo.disable_uart3=1 board_bravo.
INFOusb_h2w_sw=1 board_bravo.disable_sdcard=0 diag.enabled=0 boa
INFOrd_bravo.debug_uart=0 smisize=0 userdata_sel=0 androidboot.e
INFOmmc=false androidboot.baseband=5.09.05.30_2 androidboot.cid
INFO=HTC__032 androidboot.carrier=HTC-EastEurope androidboot.mid
INFO=PB9920000 androidboot.keycaps=qwerty androidboot.mode=norma
INFOl androidboot.serialno=HT057PL01634 androidboot.bootloader=0
INFO.93.0001 no_console_suspend=1
INFOaARM_Partion[0].name=misc
INFOaARM_Partion[1].name=recovery
INFOaARM_Partion[2].name=boot
INFOaARM_Partion[3].name=system
INFOaARM_Partion[4].name=cache
INFOaARM_Partion[5].name=userdata
INFOpartition number=6
INFOValid partition num=6
INFOmpu_nand_acpu_rw A1E 1000
INFOjump_to_kernel: machine_id(2457), tags_addr(0x20000100), ker
INFOnel_addr(0x20008000)
INFO-------------------hboot boot time:697447 msec
ERROR: usb_read failed with status e00002ed
FAILED (status read failed (No such file or directory))
- Sadly, I made a complete reflash using
Code:
fastboot rebootRUU;
fastboot flash zip rom.zip
... so no Clockwork recovery anymore
- Yes I have a nandroid backup but no means to put it back on the phone - the nandroid backup contains exactly the same rom I have now - just rooted
- As for the modaco fix I'm a new user I can't post external links, but it's the first link in this thread
- I did use the lastest Unrevoked3 (3.21) to root the phone
- I can use hboot / fastboot without problems but it's the stock 0.93.001 S-ON version.
Thanks
geejayoh said:
Use a goldcard, it will enable you to put an unrooted Rom there. It's always a good reset option.
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
I have an unbranded Desire so no need to use a GoldCard if I'm not mistaken.
Anyway if memory serves me right using the GoldCard / HBOOT / PB99IMG flashing, won't allow me neither to downgrade, nor to flash an unsigned rom.
An unsigned rooted rom or HBOOT downgraded do 0.80 could help me fix my problem - but with HBOOT 0.93 - dowgrading doesn't seem to be an option. I get a "Main Version Older" error when trying to downgrade, and flashing an unsigned rom is a no-no for all stock bootloaders as far as I know (I tried both HBOOT and recovery, both as expected fail at signature verification).
But thanks anyway
Whats the exact problem now? You restored rom.zip via ruu. So you got a stock firmware with stock hboot and stock recovery which can be unrevoked again?
Seams i am missing a detail ^^
Sent from my HTC Desire using Tapatalk
mad-murdock said:
Whats the exact problem now? You restored rom.zip via ruu. So you got a stock firmware with stock hboot and stock recovery which can be unrevoked again?
Seams i am missing a detail ^^
Sent from my HTC Desire using Tapatalk
Click to expand...
Click to collapse
It seems to me you're missing the main issue not a detail
The main issue being a condition called "USB Brick" (well that's only half the truth, most of the main issue is me acting without thinking )
Please read the info thread on USB Bricks here, since you have a HTC Desire - it concerns you too. Good idea to backup the MISC partition if you plan to flash the phone again
Anyyyyway - as for my case:
I screwed up, flashed the stock firmware BEFORE checking if the applied USB brick fix solved my problems. So it's true I have stock firmware, stock hboot, stock recovery - but I also have no way to connect the phone to a computer via USB - because the flashing process updates the following partitions: system, recovery, boot but not the misc partition which is now corrupt, and its corruption is the cause of the USB brick...
USB Brick = no usb connection at all while booted to the Android OS
No usb connection = no usb debug mode
no usb debug mode = no unrevoked
The usb still works from HBOOT / FASTBOOT, so If you know of a way to start Unrevoked while the phone is in HBOOT / FASTBOOT - please enlighten me, because I couldn't do It.
Unrevoked only recognized the phone while it was in USB Debug mode, which it cannot enter now because of the USB Brick. When I connect the phone while in Fastboot USB mode or HBOOT USB mode Unrevoked just states "Waiting for device".
I don't think I am able to put this in any clearer way
Thanks
Ouch. Now i see. Didnt understand you at the start. Well, i had an usb brick myself after wiping the system. At least i had a modded hboot and recovery.
Now to your problem. Wierd situation, really. But if i remember right, flashing one of the ruu.Exe files should also fix misc. Then you have stock firmware with usb working. Cant link here in tapatalk, but those ruu file are a sticky in desire dev forum... tell me, if it worked...
Sent from my HTC Desire using Tapatalk
Solved!
I was able to successfully unbrick the phone
It wouldn't be possible without rageagainstthecage, All the people writing the tutorials on USB unbricking, QuickSSHd and the Terminal Emulator app. Thanks to the authors.
I'll try to sum things up for anyone interested:
The problem
Because of acting without thinking I ended up with a stock unrooted rom and a partial USB brick. To make things worse I accepted the OTA update, installing the oh so loved HBOOT 0.93.100 S-ON.
The Solution
After some reading about rageagainstthecage, PoC code on which the Unrevoked rooting solution is based I tried to run the exploit directly on the phone.
Without having access to adb I wasn't able to find a place to put the executable, as the /data/ directory is writable only by the system user and the system group, and most tutorials suggest to place the exploit somewhere inside that directory. But all the tutorials I found mentioned using adb push to put the file on the phone, which probably operates on the phone as system:system as it is capable of writing to the /data dir. I wasn't able to write there as I had the id of the Terminal Application
Since apps storing data seem to store er... data in /data/data I had a little breakthru. Becaue I couldn't find a free telnet solution I purchased the QuickSSHd from Android Market.
This allowed me to have write access to /data/data/<package_name>/home where I created a world readable (755) directory. I scp'd the rageagaintthecage, modified misc partition image and flash_image binary to the phones filesystem, and made them executable. I could've used the Terminal Apps <data dir>/shared_prefs directory (which would be a $$$ free solution, as the ssh was not free, but not expensive either) but I'm lazy and doing stuff from a PC keyboard is easier than from a touch keyboard.
Running the exploit and flash_image from inside a ssh session seemed like a good idea but the sshd died after running the exploit, and didn't want to start untill the phone was rebooted. So next time I just started the sshd and done the rest of the stuff from a Terminal Emulator (After preparing scripts for ease of execution, and dropboxing the paths for copy paste ). After running the exploit the Terminal Emulator app stopted working correctly (as expected) but after force closing it and running it again I was greeted with a # prompt
I flashed the misc partition with an image modified with my phones CID, rebooted and voila! USB brick gone
Now I just have to beat one thing into my empty head (in the manner of "stop, drop, and roll" firedrill mantra). STOP, READ and THINK - before flashing
g'night
mad-murdock said:
Ouch. Now i see. Didnt understand you at the start. Well, i had an usb brick myself after wiping the system. At least i had a modded hboot and recovery.
Now to your problem. Wierd situation, really. But if i remember right, flashing one of the ruu.Exe files should also fix misc. Then you have stock firmware with usb working. Cant link here in tapatalk, but those ruu file are a sticky in desire dev forum... tell me, if it worked...
Sent from my HTC Desire using Tapatalk
Click to expand...
Click to collapse
Hi,
Just fyi because I was able to resolve my problem in the meantime.
Because I was foolish enough to install the OTA upgrade before it occured to me that the USB is not working, installing any RRU either in the official way (by running the exe) or by extracting the rom.zip from inside of the exe didn't work. The latest RRU was older then the firmware with OTA upgrade on my phone, and it didn't seem to allow me to downgrade.
ZIP way = Main Version Older error
EXE way = You have to install the correct firmware version or some other bla bla bla
Anyway I took a look inside the rom.zip extracted from the RRU.exe - there are img files of every partition, radio and hboot but no misc.
But thanks again anyway
How did you solve your tricky situation then?
Sent from my HTC Desire using Tapatalk
quanchi said:
I was able to successfully unbrick the phone
It wouldn't be possible without rageagainstthecage, All the people writing the tutorials on USB unbricking, QuickSSHd and the Terminal Emulator app. Thanks to the authors.
I'll try to sum things up for anyone interested:
The problem
Because of acting without thinking I ended up with a stock unrooted rom and a partial USB brick. To make things worse I accepted the OTA update, installing the oh so loved HBOOT 0.93.100 S-ON.
The Solution
After some reading about rageagainstthecage, PoC code on which the Unrevoked rooting solution is based I tried to run the exploit directly on the phone.
Without having access to adb I wasn't able to find a place to put the executable, as the /data/ directory is writable only by the system user and the system group, and most tutorials suggest to place the exploit somewhere inside that directory. But all the tutorials I found mentioned using adb push to put the file on the phone, which probably operates on the phone as system:system as it is capable of writing to the /data dir. I wasn't able to write there as I had the id of the Terminal Application
Since apps storing data seem to store er... data in /data/data I had a little breakthru. Becaue I couldn't find a free telnet solution I purchased the QuickSSHd from Android Market.
This allowed me to have write access to /data/data/<package_name>/home where I created a world readable (755) directory. I scp'd the rageagaintthecage, modified misc partition image and flash_image binary to the phones filesystem, and made them executable. I could've used the Terminal Apps <data dir>/shared_prefs directory (which would be a $$$ free solution, as the ssh was not free, but not expensive either) but I'm lazy and doing stuff from a PC keyboard is easier than from a touch keyboard.
Running the exploit and flash_image from inside a ssh session seemed like a good idea but the sshd died after running the exploit, and didn't want to start untill the phone was rebooted. So next time I just started the sshd and done the rest of the stuff from a Terminal Emulator (After preparing scripts for ease of execution, and dropboxing the paths for copy paste ). After running the exploit the Terminal Emulator app stopted working correctly (as expected) but after force closing it and running it again I was greeted with a # prompt
I flashed the misc partition with an image modified with my phones CID, rebooted and voila! USB brick gone
Now I just have to beat one thing into my empty head (in the manner of "stop, drop, and roll" firedrill mantra). STOP, READ and THINK - before flashing
g'night
Click to expand...
Click to collapse
Any chance of adding some links or actual information?
I've got exactly the same problem and you seem to have the solution.
Any chance of sharing?
Usb Brick !? This is an OLD thing I have this some Months ago. Never heard of someone who got it again! YOU did something wrong ;-)
Sure, he did something wrong.I managed this, too, when playing with a partition tool not designed for my system. Misc partition damaged, so a nice usb brick...
About the requested links : just use forum search for usb brick. First hit is your sticky solution
Sent from my S-OFF'd brain using teh internetz
CyberTech71 said:
Any chance of adding some links or actual information?
I've got exactly the same problem and you seem to have the solution.
Any chance of sharing?
Click to expand...
Click to collapse
I couldn't post external links, forum limitation for new users... Now I see I can so:
This is a specific situation - usb brick and totally stock rom, recovery and hboot. It's not required for people who have a modified recovery and a rooted rom. It's easy like 1-2-3.
Before doing anything else enable the Debug Mode in the Applications / Dev menu
1. Download the rageagainstthecage exploit from the authors site:
http://c-skills.blogspot.com/2010/08/please-hold-line.html
2. Download the flash_image and misc (mtd0.img) partition image from this thread.
http://forum.xda-developers.com/showthread.php?t=691639&highlight=usb+brick
Modify the mtd0.img according to your phones CID (how to get the CID also explained in the thread)
2. Download Android Terminal Emulator from the Market
3. Copy the exploit binary (rageagainstthecage-arm5.bin), the flash_image and modifed mtd0.img to the sdcard via an external card reader
4. Start the Terminal
5. Copy the files to the Terminal app data directory (the only place on the data partition you will have write access while running the Terminal), and make the binaries executable
Code:
cat /sdcard/rageagainstthecage-arm5.bin > /data/data/jackpal.androidterm/shared_prefs/rageagainstthecage-arm5.bin
cat /sdcard/flash_image > /data/data/jackpal.androidterm/shared_prefs/flash_image
cat /sdcard/mtd0.img > /data/data/jackpal.androidterm/shared_prefs/mtd0.img
cd /data/data/jackpal.androidterm/shared_prefs/
chmod 755 rageagainstthecage-arm5.bin flash_image
6. Run the exploit
Code:
/data/data/jackpal.androidterm/shared_prefs/rageagainstthecage-arm5.bin
After the exploit exits/finishes there should be a short system freeze, followed by inablity to issue any command from the terminal (don't worry). Exit the Terminal by long pressing HOME and force close the Terminal app from the Application Manager
7. Start the terminal again, a root prompt should be visible
8. Flash the misc partition
Code:
cd /data/data/jackpal.androidterm/shared_prefs
./flash_image misc mtd0.img
9. Reboot
Done and done
Enjoy
PS. I suck at writing tutorials, but if the details are still hazy for you after reading this - better to service the phone, because you might end up bricking the device totally - cheers
quanchi said:
I was able to successfully unbrick the phone
It wouldn't be possible without rageagainstthecage, All the people writing the tutorials on USB unbricking, QuickSSHd and the Terminal Emulator app. Thanks to the authors.
I'll try to sum things up for anyone interested:
The problem
Because of acting without thinking I ended up with a stock unrooted rom and a partial USB brick. To make things worse I accepted the OTA update, installing the oh so loved HBOOT 0.93.100 S-ON.
The Solution
After some reading about rageagainstthecage, PoC code on which the Unrevoked rooting solution is based I tried to run the exploit directly on the phone.
Without having access to adb I wasn't able to find a place to put the executable, as the /data/ directory is writable only by the system user and the system group, and most tutorials suggest to place the exploit somewhere inside that directory. But all the tutorials I found mentioned using adb push to put the file on the phone, which probably operates on the phone as system:system as it is capable of writing to the /data dir. I wasn't able to write there as I had the id of the Terminal Application
Since apps storing data seem to store er... data in /data/data I had a little breakthru. Becaue I couldn't find a free telnet solution I purchased the QuickSSHd from Android Market.
This allowed me to have write access to /data/data/<package_name>/home where I created a world readable (755) directory. I scp'd the rageagaintthecage, modified misc partition image and flash_image binary to the phones filesystem, and made them executable. I could've used the Terminal Apps <data dir>/shared_prefs directory (which would be a $$$ free solution, as the ssh was not free, but not expensive either) but I'm lazy and doing stuff from a PC keyboard is easier than from a touch keyboard.
Running the exploit and flash_image from inside a ssh session seemed like a good idea but the sshd died after running the exploit, and didn't want to start untill the phone was rebooted. So next time I just started the sshd and done the rest of the stuff from a Terminal Emulator (After preparing scripts for ease of execution, and dropboxing the paths for copy paste ). After running the exploit the Terminal Emulator app stopted working correctly (as expected) but after force closing it and running it again I was greeted with a # prompt
I flashed the misc partition with an image modified with my phones CID, rebooted and voila! USB brick gone
Now I just have to beat one thing into my empty head (in the manner of "stop, drop, and roll" firedrill mantra). STOP, READ and THINK - before flashing
g'night
Click to expand...
Click to collapse
Hello
in you problem with USB bricks for unrooted HTC desire
I have the seam problem
please explain it to me
I copy the flash_image and mtd0.img to
\data\data in my device I only need to flash them to restore my device
when I try this command in terminal Eliminator
/data/data/flash_image misc /data/data/mtd0.img
It show me
error writing misc permission denied
help me please
I can't believe it, mate, finally this tutorial solved my usb (and bluetooth, and fm radio, and...) problem!!!!!
My Desire is unrooted, I've tried so many solution in the last 3 months but they all were useless.
I was starting to pack my phone for sending it to HTC Service when... tataaaa, I found your topic. Is on your if my wonderful Android powered phone got back fully functional.
Really, thank you for sharing your solution with us.
===========;-D
Francalberto
francalberto said:
I can't believe it, mate, finally this tutorial solved my usb (and bluetooth, and fm radio, and...) problem!!!!!
My Desire is unrooted, I've tried so many solution in the last 3 months but they all were useless.
I was starting to pack my phone for sending it to HTC Service when... tataaaa, I found your topic. Is on your if my wonderful Android powered phone got back fully functional.
Really, thank you for sharing your solution with us.
===========;-D
Francalberto
Click to expand...
Click to collapse
Good for you
All the credit goes to the people responsible for the tools used, I just put some things together.
Cheers
thank you very much
I really appreciate you effort you helped me so much
you are a brilliant man
thank you
Flashb, is your problem solved now?
Swyped with my S-OFF'd brain using teh internetz
Hi there !
I just registered to this huge forum full of ressources and so many stuffs to dig in.. I own a Z1 Compact I bought last week and got into mods etc.. This is my first Android device and therefore got into it for the first time.. and what a world.. so many things over here..
As a developper, I'm getting interested in this environment so I first tried to gain access to this unix-based system called Android in order to see how this works..
Here my first steps: I needed to be root on this device..okay.. through tutos I read, I needed to unlock bootloader then I needed to install a new boot called ClockWorkMod (I believe this is a boot, according fastboot argument I supplied..) to allow me running the SuperUser script to be root. Afterwards, I backed up my TA partition..
Okay, these steps were done pretty out of the box, without Android knowledge so far.. Now, I'm about to install busybox for tools I'm used to use on every linux platforms.. but I really lack Android knowledge about Android partitioning system (I came across TA partition, /boot, /data what else ??), content, permissions management.. in few words, Android philosophophy So guys, do you know good web ressources around my questionings so that I can start properly and the right way
I'd really like to contribute in a humbly manner, I've already developped upon ARM platforms with realtime OS and many stuffs around linux kernel, so if you guys had any suggestions for low-level dev and Android in-depth ressources etc.. I'd be grateful
Thanks a lot.
PaowZ said:
Hi there !
I just registered to this huge forum full of ressources and so many stuffs to dig in.. I own a Z1 Compact I bought last week and got into mods etc.. This is my first Android device and therefore got into it for the first time.. and what a world.. so many things over here..
As a developper, I'm getting interested in this environment so I first tried to gain access to this unix-based system called Android in order to see how this works..
Here my first steps: I needed to be root on this device..okay.. through tutos I read, I needed to unlock bootloader then I needed to install a new boot called ClockWorkMod (I believe this is a boot, according fastboot argument I supplied..) to allow me running the SuperUser script to be root. Afterwards, I backed up my TA partition..
Okay, these steps were done pretty out of the box, without Android knowledge so far.. Now, I'm about to install busybox for tools I'm used to use on every linux platforms.. but I really lack Android knowledge about Android partitioning system (I came across TA partition, /boot, /data what else ??), content, permissions management.. in few words, Android philosophophy So guys, do you know good web ressources around my questionings so that I can start properly and the right way
I'd really like to contribute in a humbly manner, I've already developped upon ARM platforms with realtime OS and many stuffs around linux kernel, so if you guys had any suggestions for low-level dev and Android in-depth ressources etc.. I'd be grateful
Thanks a lot.
Click to expand...
Click to collapse
Welcome in the exciting world of Android! I am by no means a programmer, but I have been here for a while and will just explain a few things I think are helpful. If it's stuff you already know, feel free to ignore it.
Important things first: I hope you have made a Backup of your TA-Partition before unlocking the bootloader. Unlocking the bootloader modifies the TA- partition. It is not possible to undo it if you d not have a backup. Flashing someone else's TA will brick your device!
If I am not mistaken, the TA is mainly used to verify that the phone is in original condition e.g. not modified.
Unlocking the Bootloader (BL) removes Sony's DRM-Keys from the partition, because unlocking enables you to get root access and copy all the protected stuff anyways. The result is that you loose access to some of sony's services and the use of XReality engine.
Unlocking the BL breaks the Sony Update Service, but if you unlocked with Flashtool, you will be able to relock easily. Do only relock while on a stock kernel, else the phone won't boot because it detects modified firmware.
AFAIK root is a function of the kernel, as is ClockWorkMod Recovery (CWM). they come included in, for example, DooMKernel.
Superuser and SuperSU are apps that allow you to manage root acces, giving it to the apps that need it, and stopping bad apps from getting it.
Recovery and fastboot *for me* something like a secondary boot partition. I don't know if that's technically correct, but even if the system is unbootable, you can boot into CWM and work from there.
TWRP (TeamWin Recovery Project) is another custom recovery that allows you to do interesting things.
Do not mess with the BL and TA more than necessary. A broken TA, aswell as a messed-up BL, can prevent you from booting. As long as the BL is functional and you can get into Flashmode or fastboot mode, the phone can be saved.
If/when you have root, use Terminal Emulator from Google play to find partitions.
for more tecnical aspects, go over to the "Original Android Development" forum for the Z1C. Be aware that you need a minimum uf 10 posts to be able to post there. They are a little picky about the quality of your posts.
LINKS
http://forum.xda-developers.com/wiki/Android
https://developer.android.com/index.html
https://source.android.com/
http://en.wikipedia.org/wiki/Android_(operating_system)
http://www.google.com :angel:
Hi Coirpre !!
Thanks a lot for the tips
Important things first: I hope you have made a Backup of your TA-Partition before unlocking the bootloader. Unlocking the bootloader modifies the TA- partition. It is not possible to undo it if you d not have a backup. Flashing someone else's TA will brick your device!
Click to expand...
Click to collapse
Unlocking the Bootloader (BL) removes Sony's DRM-Keys from the partition, because unlocking enables you to get root access and copy all the protected stuff anyways. The result is that you loose access to some of sony's services and the use of XReality engine.
Click to expand...
Click to collapse
Well, this step is pretty confusing, since *they* indeed advise you to proceed to TA backup before any BL unlocking but before running the script that saves your TA, you need to be root.. and thus, to load CWM and guess what ? Need to unlock BL to install CWM.. Unless I missed something, it looks a bit weird..
Anyway, I unlocked through the use of FlashTool utility and apparently it hadn't compromised XReality nor TrackID either.. (I read somewhere TrackID app won't start if your DRM are broken.. true ??)
Do not mess with the BL and TA more than necessary. A broken TA, aswell as a messed-up BL, can prevent you from booting. As long as the BL is functional and you can get into Flashmode or fastboot mode, the phone can be saved.
Click to expand...
Click to collapse
This is one of my first questioning.. Usually, if you consider a mainstream PC, you have a piece of code we formerly called a BIOS before EFI system, this BIOS launchs a bootloader (GRUB/LILO whatever.. for linux or NTLDR for Win) and even if you wipe this bootloader, you can always rewrite a fresh one and the BIOS will then start it and the OS to start as well.. You just need to boot upon another medium to restore/install a bootloader, the BIOS is not altered.
But in this device, it appears one can hard-break the unit, solely by messing with BL/TA partitions.. like if there wasn't any BIOS equivalent.. When you say As long as the BL is functional [..] you can get into Flashmode/Fastboot mode I wonder how that piece of code responsible of this feature is not hard-coded in a ROM.. Powering up this device while gently pushing a hardware button is usually processed by a hard-coded system - the BIOS. Just like when you hold pressed the Power button of your running PC, this is the BIOS which interprets this command as a "Shut down right now !!" this is not the role of a bootloader.. I have to know more about Sony system
Thanks for the links, btw
There is a way to root and install CWM without unlocking the bootloader.
BTW Root is allowing us to modify /system and unlocking to change kernel.
/system partition is same as C:/WINDOWS on PC.
Only, on android this is prohibited. And you gain access by rooting it.
So, if you want to root you insert a few apps and scripts to /system. Since it's prohibited developers find exploits to insert those files to /system by various tricks.
That's how you are rooted without unlocking the bootloader. And that's how you can backup your TA before unlocking the bootloader.
And, yeah, CWM can be inserted to /system as well as in kernel. But it's better to be in kernel since it won't be easily wiped out when you screw up something.
Basically, what you did is unlock the bootloader (lost DRM?) > insert CWM to kernel > Use CWM to root.
But don't worry, one couldn't care less about DRM. You don't need that for anything. And I heard Sony fixed removing DRM issues by unlocking the bootloader on latest firmwares but I'm not sure.
And about BIOS, yeah...I was wondering about that as well. But for sure if you mess up with boot.img that you flashed phone won't be able to recover / must go to the service. That's a good question why. Anyone could tell me more about that?
PaowZ said:
Well, this step is pretty confusing, since *they* indeed advise you to proceed to TA backup before any BL unlocking but before running the script that saves your TA, you need to be root.. and thus, to load CWM and guess what ? Need to unlock BL to install CWM.. Unless I missed something, it looks a bit weird..
[...]
I have to know more about Sony system
Click to expand...
Click to collapse
As option58 said, you can root using exploits. Unlocking is the official way provided by sony. However, there are always some hacks which can get you root without unlocking. That way you can back up TA without unlocking. On this device it is quite a hassle and involves flashing japanese and english firmwares...
Some of it is Sony, mainly the TA stuff they integrated for security and modification-checking. The boot process however is probably more or less the same on all android devices.
Option58 said:
And about BIOS, yeah...I was wondering about that as well. But for sure if you mess up with boot.img that you flashed phone won't be able to recover / must go to the service. That's a good question why. Anyone could tell me more about that?
Click to expand...
Click to collapse
I agree that there must be something hardcoded that runs after the power button is pressed, but it probably is not enough. Notice that the device must be acessible (R/W) to restore a messed up BL, which is probably only the case after boot is completed. So:
Buttonpress --> BIOS --> BL (Whichever mode) --> partitions acessible. So If you can not get past the BL, you can not access the memory and thus not fix the BL.
But I am just speculating, so either we get some knowledgeable people in here, or someone has to read it up/google it.
[EDIT:] Oh, and by the way, PaowZ, can you change the topic to something more descriptive, "technical questions about boot process and partition handling" or something? maybe that will attract knowledgeable people...
Buttonpress --> BIOS --> BL (Whichever mode) --> partitions acessible. So If you can not get past the BL, you can not access the memory and thus not fix the BL.
Click to expand...
Click to collapse
I'm almost sure there must be a way to access to raw flash r/o through addressing.. at least from some pin-outs on the motherboard of the Z1C..
I don't know S1 flashing protocol, maybe there is a way to force writes at a specific address, provided we could know start addresses of each partition..
This is actually what I do when I have to deal with ARM devices through a rs232 port.. I can flash wherever I want and too bad if I make a typo in the address. The device just won't load up anything, but it won't hard-brick anything..
PaowZ said:
I'm almost sure there must be a way to access to raw flash r/o through addressing.. at least from some pin-outs on the motherboard of the Z1C..
I don't know S1 flashing protocol, maybe there is a way to force writes at a specific address, provided we could know start addresses of each partition..
This is actually what I do when I have to deal with ARM devices through a rs232 port.. I can flash wherever I want and too bad if I make a typo in the address. The device just won't load up anything, but it won't hard-brick anything..
Click to expand...
Click to collapse
well, this thread might interest you...
and I found this by chance, you were interested in the partitions:
Android-supported hardware shares some common features due to the nature of the operating system. The Android OS is organized into the following images:
Bootloader - Initiates loading of the boot image during startup
Boot image - Kernel and RAMdisk
System image - Android operating system platform and apps
Data image - User data saved across power cycles
Recovery image - Files used for rebuilding or updating the system
Radio image - Files of the radio stack
Click to expand...
Click to collapse
However: this topic is far beyond my knowledge, at the moment I have just started learning Java to start tinkering with Android on app-level. You will have to find out by yourself. However, I am VERY interested in what you find, because these thingsa are always good to know. There are a lot people from the forums which could help you. Just go read a bit in the "Original Android Development" subforum to find the good people
In the Google's YouTube channel there are quite many deep dive videos for multiple aspects of the Android system.
Use the search Luke ?
As far as I read this thread it is too late to make TA backup.
Hello all,
I thought of a possibility to remove the "Set warranty bit : %s". I allmost did it but not having the possibility and knowledge of recovering from a brick i stumbled and thought to ask you guys before i do something stupid. I remember i did a similar thing to HTC Sensation to the hboot bootloader by changing the **** UNLOCKED *** text to something i liked but i'm not sure if additional checks are being made on GT-I9195 LTE.
I searched with grep inside /dev/block/mmcblk0 and found the string "Set Warranty Bit : %s". Dumping the first 10 Mb will include the area where the text is.
Will the phone brick if i dd if=/dev/block/mmcblk0 of=/mnt/extSdcard/binary.bin, transfer it on the pc, hexedit the text and variable replacing every letter with 0x20 and flashing it back on the phone will mess up the GPT(checksum maybe?) and brick the phone or should i give it a go ?
Thanks.
raz3k said:
*text*.
Click to expand...
Click to collapse
Make a backup and give it a go.
Hi,
Thanks for the response, what kind of backup should i do because if GPT checksum fails i don't think i'll be able to unbrick without JTAG.
After some research i found that this text is in the aboot partition which is /dev/block/mmcblk0p5 - 2097152 bytes in size.
Will i brick it or not ? Does the aboot partition have a checksum on itself done by other chianloader ?
For example does TriangleAway from chainfire modify this partition?
Cheers!
raz3k said:
After some research i found that this text is in the aboot partition which is /dev/block/mmcblk0p5 - 2097152 bytes in size.
Will i brick it or not ? Does the aboot partition have a checksum on itself done by other chianloader ?
Click to expand...
Click to collapse
I'm of no help but I'd be interested in that as well.
aboot is the Knox boot loader (the master of all boot related partitions?)
Here @SilviuMik wrote some info about Knox and partitions: http://forum.xda-developers.com/showpost.php?p=48607142&postcount=19
2698
aguaz said:
I'm of no help but I'd be interested in that as well.
aboot is the Knox boot loader (the master of all boot related partitions?)
Here @SilviuMik wrote some info about Knox and partitions: http://forum.xda-developers.com/showpost.php?p=48607142&postcount=19
Click to expand...
Click to collapse
Thanks for your info, i will dig even more, on the other side my image is set up, i just need a confirmation from a guru so that i can flash without keeping my fingers crossed.
If u could do this u could remove knox, i think that u can brick ur phone. Jtag ready, but wait for a guru
In the meantime i've spoken with @SilviuMik and he has not played with a knox enabled aboot.img because he doesn't have a knox enabled phone but in his opinion it will brick.
After digging even more i found @babuk123 's post here that is in fact a solution to debrick in case of a hard brick that could result in after fiddling around with aboot.img .
Technically what you need to do is dump partitions from p0 -> p7 from a working phone ( or even better your phone while it still works ) and dd them on a sdcard. They state that the qualcomm chip will read stuff from the sdcard if the internal memory is bricked, but i can't be sure (i'm not sure if the chip priorities the sdcard in spite of the internal memory if known binary code is found on the sdcard).
Can someone confirm that they unbricked their S4 mini using this method ? Because if i can debrick i will give it a go.
L.E. : I tried a different approach, i made a backup of p0 -> p7, wrote it on the sdcard, modified it to suppress the warranty void string, booted and the phone ignored it completely which means that either this method does not work at all or it may work if the eMMC is corrupted. For now i'm stuck again.
Thanks.
Maybe @E:V:A can shed some light on how the boot chain actually works (sbl1-3,aboot,rpm,tz) and how to boot off an sdcard.
He has written some interesting Qualcomm stuff http://forum.xda-developers.com/showthread.php?t=1856327
See also http://forum.xda-developers.com/showthread.php?t=1769411
Bump.
Don't do anything stupid, but don't give up!
(not sure what thread to put it in)
I doubt this will work but i was using sony mobile flasher by androxyde and so my phone came up with root denied so I clicked on the root section and tried them all didn't work until i clicked on service menu and I got this
03/047/2016 19:47:53 - INFO - Pushing C:\Users\Myname\.flashTool\devices\busybox\1.20.2\busybox to /data/local/tmp/busybox
03/047/2016 19:47:54 - INFO - Pushing C:\Flashtool\custom\root\subin\Supersu\su to /data/local/tmp/su
03/047/2016 19:47:54 - INFO - Pushing C:\Flashtool\custom\root\subin\Supersu\Superuser.apk to /data/local/tmp/Superuser.apk
03/047/2016 19:47:54 - INFO - Pushing C:\Flashtool\custom\root\subin\Supersu\install-recovery.sh to /data/local/tmp/install-recovery.sh
03/047/2016 19:47:54 - INFO - Pushing C:\Flashtool\custom\root\subin\Supersu\99SuperSUDaemon to /data/local/tmp/99SuperSUDaemon
03/047/2016 19:47:55 - INFO - Pushing C:\Flashtool\custom\root\ServiceMenu\onload.sh to /data/local/tmp/
03/047/2016 19:47:55 - INFO - Pushing C:\Flashtool\custom\root\ServiceMenu\getroot.sh to /data/local/tmp/
03/047/2016 19:47:55 - INFO - Pushing C:\Flashtool\custom\root\ServiceMenu\install-recovery.sh to /data/local/tmp/
03/048/2016 19:48:13 - INFO - Look at your phone. Choose Service Test, then Display.
03/048/2016 19:48:13 - INFO - Waiting for uevent_helper rw
03/048/2016 19:48:15 - INFO - Device connected with USB debugging on
03/048/2016 19:48:16 - INFO - Connected device : Sony Xperia M5
03/048/2016 19:48:16 - INFO - Installed version of busybox : N/A
03/048/2016 19:48:16 - INFO - Android version : 6.0 / kernel version : 3.10.72+ / Build number : 30.2.A.1.21
03/048/2016 19:48:16 - INFO - Root access denied
03/048/2016 19:48:19 - INFO - Waiting for rooted shell
03/048/2016 19:48:20 - INFO - Root achieved. Installing root files. Device will reboot. Please wait.
03/048/2016 19:48:20 - INFO - Pushing C:\Flashtool\custom\root\ServiceMenu\installsu.sh to /data/local/tmp/
but I just hard bricked my phone and just got it back so I don't want to try it but if anyone is willing to try that would be great
It's simple: starting with Marshmallow update, Xperia M5 now have verified boot (dm-verity) enabled, just like all other Xperia devices from 2015 and onwards (some older Xperia devices also got dm-verity through a firmware update). That means it doesn't matter if you find a working exploit or not, modifying a single byte of the system partition will simply fail dm-verity checks and as result your phone won't boot (that's apparently what happened to your phone, you managed to modify the system partition and as result it refused to boot). No write access to system partition means no way to install su binary and other required files.
In other words, the ages of root with a locked bootloader are gone, unlocking the bootloader (so you can flash a modified kernel with dm-verity disabled or a systemless root solution) is the only way to get root now.
mbc07 said:
It's simple: starting with Marshmallow update, Xperia M5 now have verified boot (dm-verity) enabled, just like all other Xperia devices from 2015 and onwards (some older Xperia devices also got dm-verity through a firmware update). That means it doesn't matter if you find a working exploit or not, modifying a single byte of the system partition will simply fail dm-verity checks and as result your phone won't boot (that's apparently what happened to your phone, you managed to modify the system partition and as result it refused to boot). No write access to system partition means no way to install su binary and other required files.
In other words, the ages of root with a locked bootloader are gone, unlocking the bootloader (so you can flash a modified kernel with dm-verity disabled or a systemless root solution) is the only way to get root now.
Click to expand...
Click to collapse
I bricked my phone because I'm an idiot not because of that and I was on lollipop when I did it
"Hard bricked and got it back" - HOW?????
ih8redsn0w said:
(not sure what thread to put it in)
... but I just hard bricked my phone and just got it back ...
Click to expand...
Click to collapse
Hi there, this quote is extremely interesting!
What do you mean with "just got it back"? Got it back to booting...? Or got it back from a warranty repair?
Please let us know what we have to do to get our's back too... I hard bricked mine and don't seem to find a way to unbrick it. And more of us with the same problem are out there... THANKS indeed!
This guide is intended to help people to achieve having a Pixel 6 Pro using GrapheneOS with Root (using Magisk) and a Locked Boot Loader
Though it should be possible to do this with any device that GrapheneOS officially supports.
Do not ever disable the OEM unlocking checkbox when using a locked bootloader with root. This is critically important. With root access, it is possible to corrupt the running system, for example by zeroing out the boot partition. In this scenario, if the checkbox is turned off, both the OS and recovery mode will be made unbootable and fastboot flashing unlock will not be allowed. This effectively renders the device hard bricked.
I am not responsible for any harm you may do to your device, follow at your own risk etc etc, Rooting your device can potentially introduce security flaws, I am not claiming this to be secure.
Simple method without building from source Although I highly recommend building Graphene yourself,
All you really need to do is patch the official OTA released by graphene using AVBRoot
Simply flash the official factory graphene build, then your patched OTA, then flash the avb_pkmd.bin you created following the instructions for AVBRoot and you can lock the bootloader, with patched rooted graphene.
You will need to patch each new OTA to update and sideload the update as explained HERE Flash it to Both Slots
Better Method, But requires more time and a decent computer
Only Recommended for people with experience things building from source
The first step is to build GrapheneOS from its sources or to use AVBRoot on official builds. I will include some of the information specific for Pixel 6 Pro to help with the build process
Part one, follow this guide to build GrapheneOS from source
You will want to build a Stable Release using the TAG_NAME
Code:
TP1A.221105.002.2022111000
this an EXAMPLE Tag for the Pixel 6 Pro
Find the Latest tag on the Releases page https://grapheneos.org/releases#raven-stable
Build the Kernal for Raviole (6th generation Pixels) and follow all the instructions there
When it comes to the step of "Extracting vendor files for Pixel devices"
The DEVICE is
Code:
raven
and an Example of the BUILD_ID is
Code:
tp1a.221105.002
Check the TAG_NAME for the Latest BUILD_ID
Continue to follow the guide until completion, creating your own Keys during the process
I do recommend testing to Lock the Boot Loader, Just to see if you are able to
In my experience if the pixel does not detect a valid signed boot etc, it will not allow you to lock the bootloader
So if it brings up the screen on your phone where you can confirm the locking of the bootloader
at this stage you can just select No / Do not lock
To build with a specific BUILD_NUMBER use the command
Code:
export BUILD_NUMBER=2022112500
Replacing the number with what matches the version you are attempting to build
Remove the encryption from keys/raven/avb.pem that was created for Graphene so that you can use it with AVBRoot
Use the script
Code:
script/decrypt_keys.sh
https://grapheneos.org/build#encrypting-keys
And set a copy of the key aside for the next steps.
Use the following process to create the correct keys for AVBRoot & GrapheneOS
Use the avb.pem you decrypted in the last step
Convert the avb.pem to avb.key with the following command
Code:
openssl rsa -outform der -in avb.pem -out avb.key
Then clone the avb.key and rename it to ota.key
as it says "The boot-related components are signed with an AVB key and OTA-related components are signed with an OTA key. They can be the same RSA keypair, though the following steps show how to generate two separate keys."
Convert the public key portion of the AVB signing key to the AVB public key metadata format. This is the format that the bootloader requires when setting the custom root of trust.
Code:
PATH/TO/avbroot/external/avb/avbtool.py extract_public_key --key avb.key --output avb_pkmd.bin
Generate a self-signed certificate for the OTA signing key. This is used by recovery for verifying OTA updates.
Code:
openssl req -new -x509 -sha256 -key ota.key -out ota.crt -days 10000 -subj '/CN=OTA/'
I also edit the "CN" to match what I used earlier when I generated the keys for Graphene
I am not entirely certain what other of the keys I should use instead, I think this is the best approach for now
as it creates all the keys it requires and this process works for me
Copy the OTA (raven-ota_update-*.zip) from the folder where you have your own Factory Graphene Build and use this with AVBRoot
Then you will have all the keys and files you need to continue the guide and use the AVBRoot script
Now it's time to follow the instructions Here https://github.com/chenxiaolong/avbroot
To create a full factory installer, Intall it and lock the bootloader.
When you are done with AVBRoot and you have the boot.img, vbmeta.img and vendor_boot.img
All patched and signed by AVBRoot, Take a factory image from your Graphene Build and Extract it anywhere
Open the image-raven-*.zip with an Archive manager
Delete the existing boot.img, vbmeta.img and vendor_boot.img files and replace them the patched ones
also replace the avb_pkmd.bin with the one you have created in the previous steps for AVBRoot (might work without this step)
Finally, you are able to run the flash-all.sh and then lock the bootloader
Code:
./flash-all.sh
Code:
fastboot flashing lock
Updating is very simple, Once you use AVBRoot to create the Patched OTA.zip
you can reboot to recovery and flash the patched ota.zip with adb sideload
Code:
adb sideload raven-ota_update-*.zip.patched
https://grapheneos.org/usage#updates-sideloading
Creating the patched full factory installer is not required if you simply flash the avb custom key and the patched OTA zip before locking the bootloader, after flashing the unpatched full system install build
This for me allowed me after much struggle to achieve a Rooted, Locked Boot Loader using GrapheneOS and Magisk
Now though with this guide worked out, I think it should be quite easy for anyone with basic terminal knowledge to accomplish.
Something to note is that GrapheneOS does Not Pass the CTS Profile integrity check
and I do Not Pass the Play Integrity API Check currently, Neither the Basic or Strong check
But I can pass the Basic attestation Safety Net test when using the patched SafetyNet Fix
Further testing is needed and welcomed to try and pass SafetyNet and Play Integrity
To Be Clear, Although it already should be, This is NOT Modifying the official Graphene OS Sources, it is simply using them as a SOURCE for a GUIDE, You build it using unmodified grapheneOS source code so it is an unnofficial build according to their website
Sources: GrapheneOS, AVBRoot, Magisk
PayPal Donation Link
I highly recommend using your own build that is signed with your own keys that you can keep secure!
I make no promises to provide any updates to this rom at this time
Here more as a proof of concept that it works and updates are possible
Latest builds moved to: Unofficial GrapheneOS, Magisk Patched for Pixel 6 / 6 Pro
This really is quite cool man. Maybe I'll try this on my new P7P. This way we have everything. Well Done!
How would you update the rom? Repeat the whole process?
Spl4tt said:
This really is quite cool man. Maybe I'll try this on my new P7P. This way we have everything. Well Done!
How would you update the rom? Repeat the whole process?
Click to expand...
Click to collapse
I haven't worked out updating yet but all it requires is patching an updated OTA with AVBRoot in theory
I have been quite busy irl and haven't had much time to play around with it, if you do figure it out then please let me know
Spl4tt said:
This really is quite cool man. Maybe I'll try this on my new P7P. This way we have everything. Well Done!
How would you update the rom? Repeat the whole process?
Click to expand...
Click to collapse
now that I have had time to do it, Updating was very easy
I have also updated and improved the process for getting and creating the correct keys used for signing
After updating it booted normally, still rooted, no apparent problems or issues
New Release 2022111000
Changes since the 2022110800 release:
remove TrustCor Certificate Authority due to malicious domain squatting and ties to entites involved in surveillance which should have very little impact on web compatibility due to this CA barely being used by anyone other than a specific dynamic DNS provider
ignore wireless alert channels being marked as always-on to prevent channel configuration overriding presidential alert toggle
GmsCompatConfig: change app label from "GmsCompat config" to "GmsCompatConfig"
GmsCompatConfig: disable TelecomTaskService to resolve sandboxed Google Play services crash caused by feature flag
kernel (Pixel 4, Pixel 4 XL, Pixel 4a, Pixel 4a (5G), Pixel 5, Pixel 5a): update base kernel to Android 13 QPR1 Beta 3 to ship the December security update early
Vanadium: update Chromium base to 107.0.5304.105
Download Moved to https://forum.xda-developers.com/t/...magisk-patched-13-raven.4518953/post-87728629
Hey, thanks for the excellent guide, this is all about to be applicable to me
I have run into a small issue though, when generating the avb.key, openssl gives me an unsupported error
openssl rsa -outform der -in avb.pem -out avb.key
routines:ssl_store_handle_load_result:unsupported:crypto/store/store_result.c:151:
Unable to load certificate
I am wondering if since I didn't put a password on the keys if that caused an issue. I tried encrypted/decrypted, same issue. It's a fresh arch linux install, so packages are up to date.
Thanks!
Wouldn't rooting GrapheneOS decrease the security of the operating system, a key aspect that Graphene is designed to improve? Seems like that defeats the purpose of using it in the first place.
holofractal said:
Hey, thanks for the excellent guide, this is all about to be applicable to me
I have run into a small issue though, when generating the avb.key, openssl gives me an unsupported error
openssl rsa -outform der -in avb.pem -out avb.key
routines:ssl_store_handle_load_result:unsupported:crypto/store/store_result.c:151:
Unable to load certificate
I am wondering if since I didn't put a password on the keys if that caused an issue. I tried encrypted/decrypted, same issue. It's a fresh arch linux install, so packages are up to date.
Thanks!
Click to expand...
Click to collapse
Thank you, I am glad that it has been helpful for you, I have not encountered that error myself but I did use a password initially for the steps to create the keys for Graphene, I don't think this should matter though
If you don't mind and are able to, can you create another copy of the avb.pem, see if the problem still occurs and share it with me if it does, so I can test if I get the same error when I use your .pem
EonOfBlack said:
Wouldn't rooting GrapheneOS decrease the security of the operating system, a key aspect that Graphene is designed to improve? Seems like that defeats the purpose of using it in the first place.
Click to expand...
Click to collapse
I do clearly say in the first post
> Rooting your device can potentially introduce security flaws, I am not claiming this to be secure.
I don't believe just using magisk is really such an issue, you are able to deny root from any applications you don't want to use it
it is possible there are unknown security vulnerabilities in magisk, but that's the same with anything.
Even though it may introduce some potential security vulnerabilities that Graphene combats against
I believe it should be everyones choice to use root and lock their boot loader if they choose to do so
holofractal said:
routines:ssl_store_handle_load_result:unsupported:crypto/store/store_result.c:151:
Unable to load certificate
Click to expand...
Click to collapse
This problem appears to be related to this https://github.com/openssl/openssl/issues/14100#issuecomment-847125920
A great and helpful guide!
Thank you, dear FireRattus
FireRattus said:
This problem appears to be related to this https://github.com/openssl/openssl/issues/14100#issuecomment-847125920
Click to expand...
Click to collapse
openssl x509 -outform der -in avb.pem -out avb.crt
It was this command
Code:
openssl x509 -outform der -in avb.pem -out avb.crt
Could not read cert etc. of certificate from avb.pem
4087C8C0777F0000:error:1608010C:STORE routines:ossl_store_handle_load_result:unsupported:crypto/store/store_result.c:151:
Following grapheneos's guide, that is generated with:
openssl genrsa 4096 | openssl pkcs8 -topk8 -scrypt -out avb.pem
I think the root of this issue is that the pkcs8 avb.pem is an RSA private key, and the command you specified is expecting a certificate.
At any point in time do you use the crt made by Copy the avb.pem and convert it to .crt with this command step?
So if I read over everything right, I believe the solution here would be to use
openssl req -new -x509 -sha256 -key avb.key -out avb.crt -days 10000 -subj '/CN=AVB/'
But since avb and ota can be the same key, then presumably avb.crt and ota.crt could be the same as well? I get my pixel 7 tonight. I'll try and report back.
I may have accidentally made a mistake like that in the guide, I am not able to test it at the moment but would love to know what works for you
FireRattus said:
I may have accidentally made a mistake like that in the guide, I am not able to test it at the moment but would love to know what works for you
Click to expand...
Click to collapse
So you don't even need that last section.
There are some small differences for the pixel 7 though, but it was easy enough.
I have to say, building grapheneos was the easiest time I've ever had building a ROM. Not once did I have to go on Google fishing for answers. Flashing the ROM and relocking the bootloader took less than 10m, even with root.
This is why I switched to a pixel. I am too old and don't have the time to sit here and fiddle with my phone for hours on end anymore. I need things to just work.
This is as close as you are going to get to first party level support with aftermarket software, but I still care about privacy.
I'll do a write up later so other's don't have the same issues as me, but thanks for getting me started!
holofractal said:
So you don't even need that last section.
There are some small differences for the pixel 7 though, but it was easy enough.
I have to say, building grapheneos was the easiest time I've ever had building a ROM. Not once did I have to go on Google fishing for answers. Flashing the ROM and relocking the bootloader took less than 10m, even with root.
This is why I switched to a pixel. I am too old and don't have the time to sit here and fiddle with my phone for hours on end anymore. I need things to just work.
This is as close as you are going to get to first party level support with aftermarket software, but I still care about privacy.
I'll do a write up later so other's don't have the same issues as me, but thanks for getting me started!
Click to expand...
Click to collapse
I am really glad that the process could be made so smooth and simple for you
I did spend a long time trying to get a rooted grapheneOS with a locked boot loader before I managed to finally work it out, thanks mostly to the developer of AVBRoot, their script is the essential part which has made this so easy
with my internet troubles as well it ended up taking me a few weeks from when I initially started trying to when I was able to lock the booloader with root successfully
Now that I have it all worked out though, I can update and patch it in very little time
Although I did write this guide for the Pixel 6 I would be happy to include any additional information which could be helpful for people using other pixels, I am just not able to test and verify the information myself on other devices
and you don't need the last section? the part where I create a full patched installer ? I did think about this, just using the patched OTA to update the rom should also work to get you root with a locked bootloader if you first flash the full installer you built yourself
I think this is possibly a better way of doing it, but I like also having the patched full installer
I would like to hear peoples opinions and what works best for them.
holofractal said:
I think the root of this issue is that the pkcs8 avb.pem is an RSA private key, and the command you specified is expecting a certificate.
At any point in time do you use the crt made by Copy the avb.pem and convert it to .crt with this command step?
So if I read over everything right, I believe the solution here would be to use
openssl req -new -x509 -sha256 -key avb.key -out avb.crt -days 10000 -subj '/CN=AVB/'
But since avb and ota can be the same key, then presumably avb.crt and ota.crt could be the same as well? I get my pixel 7 tonight. I'll try and report back.
Click to expand...
Click to collapse
I have tested it now and the last command I had to create the files was an unnecessary step I left in by mistake, I have updated and corrected the guide so that now people should be able to use those commands without error to create the required files for AVBRoot
there should be no need to have an avb.crt and if there is, then the ota.crt should suffice
I believe it was this change to AVBRoot which led to me making this mistake
Merge pull request #3 from tnagorran/master · chenxiaolong/[email protected]
Update README.md
github.com
FireRattus said:
I am really glad that the process could be made so smooth and simple for you
I did spend a long time trying to get a rooted grapheneOS with a locked boot loader before I managed to finally work it out, thanks mostly to the developer of AVBRoot, their script is the essential part which has made this so easy
with my internet troubles as well it ended up taking me a few weeks from when I initially started trying to when I was able to lock the booloader with root successfully
Now that I have it all worked out though, I can update and patch it in very little time
Although I did write this guide for the Pixel 6 I would be happy to include any additional information which could be helpful for people using other pixels, I am just not able to test and verify the information myself on other devices
and you don't need the last section? the part where I create a full patched installer ? I did think about this, just using the patched OTA to update the rom should also work to get you root with a locked bootloader if you first flash the full installer you built yourself
I think this is possibly a better way of doing it, but I like also having the patched full installer
I would like to hear peoples opinions and what works best for them.
Click to expand...
Click to collapse
Oh I meant the part about avb.crt.
As for differences, if you follow the pixel 7 section on grapheneos build guide, that will suffice. Also, instead of boot.img, you flash init_boot.img.
I did also make myself an OTA and flashed it through adb, and that worked great. I want to try making my own OTA server to do away with flashing via PC. I have other family on graphene now too, so it wouldn't be all that effort just for myself.
holofractal said:
Oh I meant the part about avb.crt.
As for differences, if you follow the pixel 7 section on grapheneos build guide, that will suffice. Also, instead of boot.img, you flash init_boot.img.
I did also make myself an OTA and flashed it through adb, and that worked great. I want to try making my own OTA server to do away with flashing via PC. I have other family on graphene now too, so it wouldn't be all that effort just for myself.
Click to expand...
Click to collapse
I did end up figuring out that is what you probably meant. since the differences for the pixel 7 are essentially in the graphene build guide, I don't think any changes are really necessary for the guide, I do recommend just following the official guide for that part, I just include some information to help make that process a bit easier for peoples first time building the rom
for me, it wasn't very clear what the TAG_NAME and BUILD_ID were supposed to be as they didn't provide examples, but a little bit of trial and error helped me work it out
Although, since you flash init_boot, does that init_boot get patched by avbroot?
I would also like to setup an OTA server, although I don't really have the funds to do that at the moment
Guide has been updated with a much simpler method thanks to https://forum.xda-developers.com/m/boom15.11870611/
I haven't tested it myself but it was pointed out, that for those who want to
All you need to do is use AVBRoot to patch the official OTA's provided by Graphene following the instructions in the readme here https://github.com/chenxiaolong/avbroot
I did think this should be possible, but I still recommend building it from source yourself if you are able to