Related
I need help I saw this bloghttp://bcmon.blogspot.com/2012/10/new-firmware-for-bcm4329.html
And I was wondering how do I get this to work, I downloaded the file they said to download (in attachments). I don't know what to do with it. Thanks for reading.
Most likely its to flash in recovery (only if rooted). HOWEVER, unzip it first and check to make sure theres an "updater-script" file in there somewhere
Those files are used to patch the Linux Kernel when you're booted into the Backtrack 5 mobile ARM virtual enviroment.
The changes are not done to the ROM on the phone but Linux image on the SD card.
The patch has an install script run setup.sh from the directory in a terminal in bt5.
Then reboot and modprobe the new wireless module.
Ok so I have a Deb. Currently running 5.0 rooted. I have successfully used MultiRom and have installed Kali PwnPad on a secondary. However, the whole reason I bought this tablet was to get some of the functionality and ease of use that Pwnie offers. It is currently stuck on 4.3.1 for the foreseeable future. I had it running perfect and did a nandroid of it. However, when I restored the nandroid in multirom after installing Lollipop, none of the Pwnie apps work anymore.
If any of you are unfamiliar with the install process for PwnieExpress PwnPad the instructions are here:
https://www.pwnieexpress.com/wp-con...on-FactoryImageInstallationGuide-Detailed.pdf
My question is, given those instructions, is there a way to follow the same process using ADB Sideload within the MultiRom menu to sideload the imagev2.sh file to a new ROM slot in MultiRom? Currently when I load ADB Sideload in MultiRom it just says "starting ADB sideload feature" and never works. Any thoughts?
I figured it out...I was able to untar the file and decompile it. Once I did that I found that they were using a TWRP backup as part of their script! I combined it with another TWRP backup from my device and was successfully able to get it working!
So now I have Lollipop as the primary with Kali PwnPad and PwnieExpress PwnPad as alternates. Rock on!
pwnpad community edition wugfresh toolkit install
HI slashdot when you say decompile do i need a special program?
also if possible could you please post step by step how to do what you say you did so everyone can install pwnpad CE without having to use linux or ubuntu or mac
plus mine the 2013 2nd gen lte model of nexus 7 32gb with sim card so i have the 2014 pwnpad that is for my tablet just need your instructions..
Didn't even see this...I apologize. What you need is to untar the file...on Mac the stock archive utility can do this but I believe 7zip and others will do it. Once you unzip it, you'll see several folders and scripts, one of which is a regular folder for a nandroid backup. Pull that folder out and copy it to your sd card inside the folder for your device, and add that ROM in twrp from a backup. Easy as that!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
MultiROM is a one-of-a-kind multi-boot mod. It can boot any Android ROM as well as other systems like Ubuntu Touch, once they are ported to that device. Besides booting from device's internal memory, MultiROM can boot from USB drive connected to the device via OTG cable. The main part of MultiROM is a boot manager, which appears every time your device starts and lets you choose ROM to boot. You can see how it looks on the left image below and in gallery. ROMs are installed and managed via modified TWRP recovery. You can use standard ZIP files to install secondary Android ROMs and MultiROM even has its own installer system, which can be used to ship other Linux-based systems.
Features:
* Multiboot any number of Android ROMs
* Restore nandroid backup as secondary ROM
* Boot from USB drive attached via OTG cable
You can also watch a video which shows it in action.
WARNING
It is dangerous. This whole thing is basically one giant hack - none of these systems are made with multibooting in mind. It is no longer messing with data partition or boot sector, but it is possible that something goes wrong and you will have to flash factory images again. Make backups. Always.
IMPORTANT
I'm not responsible for anything, you do all this on your own risk.
Once you have flashed and set up MultiROM, don't flash another boot.img using fastboot or normally. Always go to TheMultiROM Menu (3 bars in the top right corner) to flash ROMs/kernels or other mods.
If you want to uninstall MultiROM, just flash the MultiROM uninstaller.
Your device must not be encrypted.
When booting another ROM, you'll notice that in some cases, you can enter the recovery of the boot.img of the ROM. Please don't use it, flash everything using MultiROM TWRP.
INSTALLATION
Make sure you are on a Rom compatible with one of these kernels and flash it or use the non-kexec workaround. (See important Notices)
Reboot into MultiROM TWRP and flash the MultiROM installer
That's it. You can now go to TheMultiROM Menu (3 bars in the top right corner) to start flashing other ROMs.
Adding ROMs
Go to recovery, select TheMultiROM Menu (3 bars in the top right corner) -> Add ROM. Select the ROM's zip file and confirm.
Using USB drive
During installation, recovery lets you select install location. Plug in the USB drive, wait a while and press "refresh" so that it shows partitions on the USB drive. You just select the location (extX, NTFS and FAT32 partitions are supported) and proceed with the installation.
If you wanna use other than default FAT32 partition, just format it in PC. If you don't know how/don't know where to find out how, you probably should not try installing MultiROM.
If you are installing to NTFS or FAT32 partition, recovery asks you to set image size for all the partitions - this cannot be easilly changed afterward, so choose carefully. FAT32 is limited to maximum of 4095MB per image - it is limitation of the filesystem, I can do nothing about that.
Installation to USB drives takes a bit longer, because the flash drive is (usually) slower and it needs to create the images, so installation of Ubuntu to 4Gb image on my pretty fast USB drive takes about 20 minutes.
Enumerating USB drive can take a while in MultiROM menu, so when you press the "USB" button in MultiROM, wait a while (max. 30-45s) until it searches the USB drive. It does it by itself, no need to press something, just wait.
Updating/changing ROMs
1. Primary ROM (Internal)
Flash ROM's ZIP file as usual, do factory reset if needed (it won't erase secondary ROMs)
Go to TheMultiROM Menu (3 bars in the top right corner) in recovery and do Inject curr. boot sector.
2. Secondary Android ROMs
If you want to change the ROM, delete it and add new one. To update ROM, follow these steps:
Go to TheMultiROM Menu (3 bars in the top right corner) -> List ROMs and select the ROM you want to update.
Select "Flash ZIP" and flash ROM's ZIP file.
SOURCEs
MultiROM - https://github.com/XperiaMultiROM/multirom/ (branch master)
Modified TWRP - https://github.com/multirom-htc/Team-Win-Recovery-Project (branch android-6.0)
Kernel w/ kexec-hardboot patch - https://github.com/Myself5/kernel/ (branch aosp/LA.BF64.1.2.2_rb4.7)
FAQs can be found here.
CREDITs
Tasssadar
Olivier
nkk71
Garcia98
Thunder07
skin1980
Envious_Data
[NUT]
Panic Brothers
You might want to consider a Donation to Tasssadar, who is the Mastermind behind MultiROM
As well as a Donation to nkk71, who wrote the kexec-workaround and helped me a lot
Thanks a lot to those who have donated! The 2 really deserve it!
XDA:DevDB Information
MultiROM for Sony Xperia Z5, Tool/Utility for the Sony Xperia Z5
Contributors
Myself5
Source Code: https://github.com/XperiaMultiROM/multirom/tree/master
Version Information
Status: Testing
Created 2016-05-08
Last Updated 2016-06-25
Important Notice
This Posts includes Important Notices you need to read if you want to use MultiROM on your Z5.
You need to a kexec-hardboot supporting kernel or the non-kexec workaround as described perfectly by @nkk71 here: http://forum.xda-developers.com/showpost.php?p=64248526&postcount=4 (Be sure to leave him a like!)
Recovery Notice: The Recovery is working with init_sony. If your Kernel is using a older way to load recoverys, then it wont work. Talk to your Kernel dev about using init_sony.
MOST IMPORTANT: When installing MultiROM on Stock, USB Connections will be broken (Charging is fine). It's caused by MultiROM screwing up the permissions of a init file which is responsible for USB. There are Kernels where USB is fixed already. A list of them is in post 3. For intrested Devs, this is how to fix it:
Just add
Code:
chmod 750 /init.usbmode.sh
to the on init step inside of init.sony.usb.rc. It will fixup the permissions MultiROM screwes up.
CHANGELOGs
General MultiROM Changelog can be found here:
Changelog
XperiaMultiROM Specific Changelog is here:
Recovery Changelog
MultiROM Changelog
DOWNLOAD
https://dl.myself5.de
The recovery.img is Tassadars modified TWRP to flash secondary Roms. It is needed to flash the secondary Roms.
SUPPORTED KERNELs
Basically you can use any Kernel you want, if you can live without Touch Support in MultiROM and use the no-kexec workaround.
However, if you want Touch Support as well as fixed USB and kexec-hardboot, use one of these kernels:
OM5Z Kernel
AndroPlus Kernel (not sure if AP Kernel has fixed USB)
If you want your favorite kernel to support kexec or at least working touch and USB, tell the dev to merge my commits.
Nice work mate :good::good:
Though every effort has been made to ensure some form of safeguards and redundancy, MultiROM has always been a "hack", and the no-kexec-workaround is as well.
The no-kexec-workaround is working nicely on HTCs (well at least M7, M8, and M9) and I've seen some other devices using it successfully as well.
As always, have your backups safely tucked away somewhere fully safe.
Happy testing, and feel free to mention me (easiest way for me to get notified), if you think there's an issue to be addressed with the workaround.... I've personally only used it on HTC M7, M8 and M9, so there may be device specific issues, which I cannot account for.
Special thanks to @Captain_Throwback , @ljjehl and @MassStash for all the help and encouragement
And a very special thanks to @z31s1g not only for the official TWRP theme, but all the help he provided bringing it to MultiROM in a very quick way, thanks :good:
Wow this is so nice I was waiting for this! I still have a few questions tho:
-Will this work with stock 6.0 with the modified stock kernel (DM-Verity disabled/ Sony RIC disabled / DRM-FIX) ? I'm worried if it will brick my device since you wrote you have a hard time with stock.
-What is no-kexec? Why do I need it?
-About the USB connection bug on stock so if I install your dirty fix everything will work as before? If I uninstall multiROM I assume the USB bug will go away right?
Thank you for your time sorry I'm a noob
zate27 said:
Wow this is so nice I was waiting for this! I still have a few questions tho:
-Will this work with stock 6.0 with the modified stock kernel (DM-Verity disabled/ Sony RIC disabled / DRM-FIX) ? I'm worried if it will brick my device since you wrote you have a hard time with stock.
-What is no-kexec? Why do I need it?
-About the USB connection bug on stock so if I install your dirty fix everything will work as before? If I uninstall multiROM I assume the USB bug will go away right?
Thank you for your time sorry I'm a noob
Click to expand...
Click to collapse
1. Yes, it will work (You just won't have touch in the MultiROM menu (don't worry, you can setup the kexec workaround to work automatically in TWRP, as well as navigate with the volume buttons inside the MRom Menu). The hard time I get is with porting kexec to the stock kernel.
2. The No-kexec workaround is a (ha, who tought that ) workaround to not use kexec-hardboot. Kexec hardboot is a technology to load a kernel into the RAM using an other kernel. This is how MultiROM usually works. Read more about that here if you're intrested: http://forum.xda-developers.com/showthread.php?t=2104706 . Now, the no-kexec workaround is doing it on a rather dirty (but nicely working) way. It flashes the secondary ROMs boot.img to your boot partition, and then modifies the mount points to link to the ROM files in your internal/external storage (whereever you installed your secondary ROMs). It is needed, because of (1.), and because stock will probably not able to load a AOSP Kernel once kexec is working (so stock can only load stock, and AOSP can only load AOSP. For everything else, you need the no-kexec workaround).
3. Yes. USB is not working, because a script (which is responsible to start the USB Service) has the wrong permissions after booting from the MultiROM Menu (I was not able to include a proper fix for it inside the MultiROM code itself, maybe I will be some day). My App just fixes the permissions and executes the script (which else would be done by the system automatically) (It's basically just executing these 2 commands when pressing the button (or at boot when you turn the autofix on) https://github.com/Myself5/andoid_p...ava/de/myself5/stockusbfix/FixIt.java#L31-L34). Once you remove MultiROM, the script will get its proper permissions back as its a ramdisk file, inside the ramdisk it actually has its proper permissions, it just doesnt when getting extracted from the ramdisk at boot and MultiROM follows (MultiROM messes up the permissions).
I hope that answers your questions, if not, feel free to ask again
P.S. Be sure to read nkk71s Info about how to enable the kexec-workaround in the post I linked in the important notices post, it might shed some more light on what is the non-kexec workaround.
Myself5 said:
SNIP
Click to expand...
Click to collapse
Thank you very much for your quick answer!
So if I understood this right the detailed instructions would be:
Flash TWRP-Multirom-20160507-00-sumire.img or the recovery.img or both(?) with fastboot(?) to get the modified TWRP w/ MultiROM support
Now with this Modded TWRP I need to enable that no-kexec workaround in the settings?
Flash the actual multiROM: multirom-20160507-v33x-UNOFFICIAL-sumire.zip in TWRP
Flash e.g. CM13 (Finally ) from here: http://forum.xda-developers.com/xperia-z5/development/rom-cyanogenmod-13-sony-xperia-z5-t3356163" via the MultiROM menu.
Install the usbfix.
Does the CM13 Rom need to be modified to work with MultiROM or will it work as it is?
Thank you in advance
zate27 said:
Thank you very much for your quick answer!
So if I understood this right the detailed instructions would be:
Flash TWRP-Multirom-20160507-00-sumire.img or the recovery.img or both(?) with fastboot(?) to get the modified TWRP w/ MultiROM support
Now with this Modded TWRP I need to enable that no-kexec workaround in the settings?
Flash the actual multiROM: multirom-20160507-v33x-UNOFFICIAL-sumire.zip in TWRP
Flash e.g. CM13 (Finally ) from here: http://forum.xda-developers.com/xperia-z5/development/rom-cyanogenmod-13-sony-xperia-z5-t3356163" via the MultiROM menu.
Install the usbfix.
Does the CM13 Rom need to be modified to work with MultiROM or will it work as it is?
Thank you in advance
Click to expand...
Click to collapse
1. TWRP-Multirom-Stock-20160507-00-sumire.img is the recovery you need. Flash it via
Code:
fastboot flash recovery TWRP-Multirom-Stock-20160507-00-sumire.img
(If the Stock is not working, use the other one, I don't know which of the 2 existing recovery loading tools your kernel is using).
2. First flash multirom, then enable it in the MultiROM Settings Tab inside TWRP (see important notices on how to do that, nkk71 describes it in the thread)
3. yes.
4. Exactly.
5. Yes, only needed for stock roms, don't forget that. Oh, and it requires root, so depending if you have root already, you also need to install SuperSU (use 2.71 beta, it worked fine for me)
6. No, the secondary Roms don't need any changes at all.
BTW, your questions seem to be common, do you mind if I copy them together with my answers to a little FAQ in post 2?
Myself5 said:
1. TWRP-Multirom-Stock-20160507-00-sumire.img is the recovery you need. Flash it via
Code:
fastboot flash recovery TWRP-Multirom-Stock-20160507-00-sumire.img
(If the Stock is not working, use the other one, I don't know which of the 2 existing recovery loading tools your kernel is using).
2. First flash multirom, then enable it in the MultiROM Settings Tab inside TWRP (see important notices on how to do that, nkk71 describes it in the thread)
3. yes.
4. Exactly.
5. Yes, only needed for stock roms, don't forget that. Oh, and it requires root, so depending if you have root already, you also need to install SuperSU (use 2.71 beta, it worked fine for me)
6. No, the secondary Roms don't need any changes at all.
BTW, your questions seem to be common, do you mind if I copy them together with my answers to a little FAQ in post 2?
Click to expand...
Click to collapse
Thanks for answering all my questions. That should have cleared it up for noobs like me
The instructions seem a bit summarily written so your answers help a lot.
Yes sure go ahead FAQ is always nice
noob flasher here not quite got this fully working with a secondary rom yet still trying, but one scenario I can't get my head around.
If your primary rom is stock no root. How can you install the usbfix? Is this scenario possible?
bongo1 said:
noob flasher here not quite got this fully working with a secondary rom yet still trying, but one scenario I can't get my head around.
If your primary rom is stock no root. How can you install the usbfix? Is this scenario possible?
Click to expand...
Click to collapse
Nope. USB Fix needs root to work. I am still working on a different workaround for it (maybe inside MultiROM), but thats lower priority.
Sent from my Xperia Z3 using Tapatalk
@Myself5 , hey.
Could you extend support to the z5 premium too maybe ?
Thanks
Regards
AVK
Ashray_Vk said:
@Myself5 , hey.
Could you extend support to the z5 premium too maybe ?
Thanks
Regards
AVK
Click to expand...
Click to collapse
I don't develop for devices I don't own, as I then can't guarantee that everything does work nor that it won't break someones device. If there is a developer working on satsuki who wants to port it and comes across problems, I'll gladly help, but I'm not going to blind-port it on my own, I hope you understand that
Hey I have the E6653 and I'm getting error 7 while flashing multirom. Recovery flashing was successful tho. Why am I getting the error the codename of my phone should be "sumire" or is there something I've missed?
zate27 said:
Hey I have the E6653 and I'm getting error 7 while flashing multirom. Recovery flashing was successful tho. Why am I getting the error the codename of my phone should be "sumire" or is there something I've missed?
Click to expand...
Click to collapse
hum, 6653 is what I have too. What did you flash it on? Which recovery did you use? The Stock or the other one?
Sent from my Xperia Z3 using Tapatalk
Damn man you answer fast
I flashed it via TWRP, TWRP 3.0.2-0 (wrong I guess), I tried to flash the stock recovery one
Here is my fastboot output:
C:\Program Files (x86)\Minimal ADB and Fastboot>fastboot flash recovery C:\Users
\Pein\Downloads\TWRP-Multirom-Stock-20160507-00-sumire.img
target reported max download size of 536870912 bytes
sending 'recovery' (33988 KB)...
OKAY [ 1.118s]
writing 'recovery'...
OKAY [ 0.464s]
finished. total time: 1.584s
Seems like it wasn't successfull because TWRP seems like the same as before :/ Should I try the other recovery? (Without stock)
zate27 said:
Damn man you answer fast [emoji14]
I flashed it via TWRP, TWRP 3.0.2-0 (wrong I guess), I tried to flash the stock recovery one
Here is my fastboot output:
C:\Program Files (x86)\Minimal ADB and Fastboot>fastboot flash recovery C:\Users
\Pein\Downloads\TWRP-Multirom-Stock-20160507-00-sumire.img
target reported max download size of 536870912 bytes
sending 'recovery' (33988 KB)...
OKAY [ 1.118s]
writing 'recovery'...
OKAY [ 0.464s]
finished. total time: 1.584s
Seems like it wasn't successfull because TWRP seems like the same as before :/ Should I try the other recovery? (Without stock)
Click to expand...
Click to collapse
which kernel are you using?
BTW: MROM TWRP looks pretty similiar to the default TWRP, it just has 3 bars in the upper right corner which opens the Mrom Menu.
Sent from my Xperia Z3 using Tapatalk
kexec and Stock!
All right. I finally managed to get kexec-hardboot working on stock. I ported it to @AndroPlus Kernel at a first, because it seems to be the kernel you people use. I also uploaded a flashable zip (I used AndroPlus' flashable zip as a base), you can find it here:
Boot.img: http://dl.myself5.de/sumire/MultiROM/boot_E6653_M5_AP.img
Flashable ZIP: http://dl.myself5.de/sumire/MultiROM/Z5_AndroPlusKernel_M5_ModZ_Edit_Permissive_v27.zip
Source for it would be here: https://github.com/Myself5/android_kernel_sony_msm8994_kitakami_r2
I also send a PR for it to @AndroPlus (https://github.com/AndroPlus-org/android_kernel_sony_msm8994_kitakami_r2/pull/3)
(Ramdisk is from AndroPlus Kernel v27, with the fix below)
Oh, and because I am badass, I also fixed up USB on Stock with that Kernel.
For every Stock Kernel Developer who's intrested how I did that (looking at you @AndroPlus and @zacharias.maladroit), I simply adjusted the USB files permissions in the ramdisk.
Just add
Code:
chmod 750 /init.usbmode.sh
to the on init step inside of init.sony.usb.rc. I know it's dirty.. but hey. It surely is less dirty than my hacky App (which therefore is no longer needed BTW).
Will suzuran devices work
killedbyghost58 said:
Will suzuran devices work
Click to expand...
Click to collapse
No.
Regarding porting requests its the same as for Z5 Premium. If I don't own the device, I'm not going to port Mrom to it.
HOWEVER: For suzuran specifically, @oshmoun is working on porting MultiROM to it, based on my device trees which means MultiROM for Z5C is coming in the nearish future.
Please also read the additional notes in post #2, as they are critical to getting Magisk working.
I decided to do some tinkering around with Magisk, and it actually DOES work on the kindles (at least the 8.9"). The problem is, Magisk's patcher just isolates the ramdisk part of the boot.img and doesn't add the boot signature or other magic back to the image when it's time to reflash the patched boot image. By dd'ing the signature (and other files) back to the image, I can get Magisk to successfully boot.
As part of the working POC (because it's exciting to actually see this!), I've uploaded the patched "Magiskified" boot image (which originally comes from the 20180319 LineageOS 14.1 ROM that was built about a week ago). For reference, this is patched by Magisk v16.0, and the setup is basically the same as the official boot.img makefile directions from CM12.1. (It was the most arbitrary source I found, and I doubt the magic used to create the boot images has changed, so I'm just using that script as a reference.) Try to stick to that ROM if you can - no telling what different ROM versions/variants might do if you're not careful.
I plan on releasing a flashable .zip soon (probably in a month? I have college to work through) to automate the patching process, and possibly even extract the official installer zips to work through Magisk's patching scripts manually so the required boot magic can be patched back into the image before it's ever flashed. (I'll try to take requests to manually patch other ROM boot.imgs if asked to in the meantime though.)
As a friendly reminder, please do NOT flash the official Magisk installer zips or any patched boot images that the app produces as is - they need to be "repatched" with the boot magic, or you'll have to fastboot flash your ROM's boot.img manually because the kindle will hang at the bootloader screen.
Important notes
The official Magisk v16.0 zip must be flashed on first install/reinstall in order to properly construct the environment. Flash the boot image attached in the OP immediately after without rebooting in between, or the image Magisk flashed will prevent the kindle from booting normally without advanced intervention.
SafetyNet does NOT pass the basic integrity OR advanced checks. At least, v16 doesn't. Maybe an earlier Magisk build does - feel free to try it once I get the automated patcher zip up and running.
For now, because you're flashing on LineageOS, you may want to flash the LOS 14.1 arm-based su removal zip from Lineage's downloads site. Verify you're downloading arm and not arm64.
How does one go about patching the boot image thats modified by magisk so it's able to be flashed?
kn0wbodh1 said:
How does one go about patching the boot image thats modified by magisk so it's able to be flashed?
Click to expand...
Click to collapse
It's complicated. I recommend not doing this unless you're willing to follow it to the letter - when I get to creating the automated patcher, this won't be necessary.
Make backups!!
extract the boot.img from your ROM .zip, copy it to the device internal storage
install the Magisk Manager app, download the Magisk .zip and choose "patch boot image"; navigate to said boot image file
copy the modified image to a computer (preferably one running a Linux OS like Ubuntu)
download the boot_cert and u-boot.bin files from the official LineageOS/CM device repo; place these files in the same directory as the boot.img file
open a Linux terminal pointed to the same directory as the boot.img file
run for i in $(seq 1024); do echo -ne "\x00\x50\x7c\x80" >> stack.tmp; done to create the remaining file
run cat boot_cert patched_boot.img > boot.img (assuming the Magisk image produced is named patched_boot.img); this is the boot "signature"
run dd if=u-boot.img of=boot.img bs=8117072 seek=1 conv=notrunc to tag the second bootloader on
finally, run dd if=stack.tmp of=boot.img bs=6519488 seek=1 conv=notrunc to add the stack file; copy the new boot.img back to the kindle
reboot into recovery, flash the Magisk .zip to build the environment, but do NOT reboot yet
choose "Flash .img" within TWRP, select the boot.img, and select "Boot" to flash to the boot partition; reboot to system once complete
profit!
monster1612 said:
It's complicated. I recommend not doing this unless you're willing to follow it to the letter - when I get to creating the automated patcher, this won't be necessary.
Make backups!!
extract the boot.img from your ROM .zip, copy it to the device internal storage
install the Magisk Manager app, download the Magisk .zip and choose "patch boot image"; navigate to said boot image file
copy the modified image to a computer (preferably one running a Linux OS like Ubuntu)
download the boot_cert and u-boot.bin files from the official LineageOS/CM device repo; place these files in the same directory as the boot.img file
open a Linux terminal pointed to the same directory as the boot.img file
run for i in $(seq 1024); do echo -ne "\x00\x50\x7c\x80" >> stack.tmp; done to create the remaining file
run cat boot_cert patched_boot.img > boot.img (assuming the Magisk image produced is named patched_boot.img); this is the boot "signature"
run dd if=u-boot.img of=boot.img bs=8117072 seek=1 conv=notrunc to tag the second bootloader on
finally, run dd if=stack.tmp of=boot.img bs=6519488 seek=1 conv=notrunc to add the stack file; copy the new boot.img back to the kindle
reboot into recovery, flash the Magisk .zip to build the environment, but do NOT reboot yet
choose "Flash .img" within TWRP, select the boot.img, and select "Boot" to flash to the boot partition; reboot to system once complete
profit!
Click to expand...
Click to collapse
Thank you very much for the detailed instructions. I'll be keeping an eye out for the automated patcher you mentioned. Would love to try out magisk on my 2015 fire.
kn0wbodh1 said:
Thank you very much for the detailed instructions. I'll be keeping an eye out for the automated patcher you mentioned. Would love to try out magisk on my 2015 fire.
Click to expand...
Click to collapse
The instructions only work against the 2012 fire (HD 8.9", 2nd generation). They will more than likely brick any other device. I don't recommend trying the instructions unless you're 100% sure your device is that specific model.
Hi, a month ago i flashed oifficial magisk 16 zip on a 8.9 kindle fire hd, and as you said, dont boot anymore, just satys on the kindle fire logo, please can you tell me how can i restore my device?, i havent used it in almost 3 years and i dont have a clue on what to do, i just wanted to install viper4android and now is dead.
erick_gc said:
Hi, a month ago i flashed oifficial magisk 16 zip on a 8.9 kindle fire hd, and as you said, dont boot anymore, just satys on the kindle fire logo, please can you tell me how can i restore my device?, i havent used it in almost 3 years and i dont have a clue on what to do, i just wanted to install viper4android and now is dead.
Click to expand...
Click to collapse
https://forum.xda-developers.com/showthread.php?t=2128848&p=75525760
I know it's not for the 8.9" but I was able to get my 7" working by repeating the procedure in step 5. Magisk messes up the kernel on the Kindle so all you have to do is reflash the kernel. You'll need a fastboot cable to get in fastboot mode though.
Take a look at the few posts before the one I linked to.
just wondering if you've had any luck with the flashable zip for magisk? Not confident enough to try it manually. Thanks in advance.
monster1612 said:
Please also read the additional notes in post #2, as they are critical to getting Magisk working.
I decided to do some tinkering around with Magisk, and it actually DOES work on the kindles (at least the 8.9"). The problem is, Magisk's patcher just isolates the ramdisk part of the boot.img and doesn't add the boot signature or other magic back to the image when it's time to reflash the patched boot image. By dd'ing the signature (and other files) back to the image, I can get Magisk to successfully boot.
As part of the working POC (because it's exciting to actually see this!), I've uploaded the patched "Magiskified" boot image (which originally comes from the 20180319 LineageOS 14.1 ROM that was built about a week ago). For reference, this is patched by Magisk v16.0, and the setup is basically the same as the official boot.img makefile directions from CM12.1. (It was the most arbitrary source I found, and I doubt the magic used to create the boot images has changed, so I'm just using that script as a reference.) Try to stick to that ROM if you can - no telling what different ROM versions/variants might do if you're not careful.
I plan on releasing a flashable .zip soon (probably in a month? I have college to work through) to automate the patching process, and possibly even extract the official installer zips to work through Magisk's patching scripts manually so the required boot magic can be patched back into the image before it's ever flashed. (I'll try to take requests to manually patch other ROM boot.imgs if asked to in the meantime though.)
As a friendly reminder, please do NOT flash the official Magisk installer zips or any patched boot images that the app produces as is - they need to be "repatched" with the boot magic, or you'll have to fastboot flash your ROM's boot.img manually because the kindle will hang at the bootloader screen.
Click to expand...
Click to collapse
barcia99 said:
just wondering if you've had any luck with the flashable zip for magisk? Not confident enough to try it manually. Thanks in advance.
Click to expand...
Click to collapse
You can't directly flash the official installer zips onto the Kindle - they currently bork the boot image "signature" (causing the bootloader exploit to break) and require reflashing the boot image from your ROM via fastboot to get things working again.
What I've thought of is adding some device detection logic to the installer script and then having it run through the process of properly repatching the boot image after the main Magisk install finishes in order to get things to work (as opposed to having a supplementary zip file work through that after an official build is flashed).
I forked the official Magisk repo a while ago and honestly forgot about it, but since v17 hit stable since then, I'm going to rebase those proposed changes against that version. No ETA on that as of yet - I've started back at college, so time is already kind of a rarity; in addition, given the age of the Kindles already (5+ years!), it may not be a thing to sustain long term. I still have my 8.9", so testing isn't an issue, but I don't expect Magisk running on these specific devices to function as expected (so more than likely SafetyNet will fall, probably Magisk Hide as well). I'm not 100% sure how it'll turn out, but these are pretty much going to be unofficial builds for as long as I/anyone else willing to run builds sees a benefit to doing so. When a build works to my satisfaction, I promise it'll go up on XDA.
monster1612 said:
You can't directly flash the official installer zips onto the Kindle - they currently bork the boot image "signature" (causing the bootloader exploit to break) and require reflashing the boot image from your ROM via fastboot to get things working again.
What I've thought of is adding some device detection logic to the installer script and then having it run through the process of properly repatching the boot image after the main Magisk install finishes in order to get things to work (as opposed to having a supplementary zip file work through that after an official build is flashed).
I forked the official Magisk repo a while ago and honestly forgot about it, but since v17 hit stable since then, I'm going to rebase those proposed changes against that version. No ETA on that as of yet - I've started back at college, so time is already kind of a rarity; in addition, given the age of the Kindles already (5+ years!), it may not be a thing to sustain long term. I still have my 8.9", so testing isn't an issue, but I don't expect Magisk running on these specific devices to function as expected (so more than likely SafetyNet will fall, probably Magisk Hide as well). I'm not 100% sure how it'll turn out, but these are pretty much going to be unofficial builds for as long as I/anyone else willing to run builds sees a benefit to doing so. When a build works to my satisfaction, I promise it'll go up on XDA.
Click to expand...
Click to collapse
thank's much. i'll continue to do some research also. i've had this kindle since it came out and remains stable with root and twrp. runs smooth and just plain like it. only negative is no sd card slot. again thanks for your hard work.
Hoping for the automated package
Here's hoping you get time to finish the automated flash package. I am not confident enough to attempt this even with your detailed instructions.
monster1612 said:
You can't directly flash the official installer zips onto the Kindle - they currently bork the boot image "signature" (causing the bootloader exploit to break) and require reflashing the boot image from your ROM via fastboot to get things working again.
What I've thought of is adding some device detection logic to the installer script and then having it run through the process of properly repatching the boot image after the main Magisk install finishes in order to get things to work (as opposed to having a supplementary zip file work through that after an official build is flashed).
I forked the official Magisk repo a while ago and honestly forgot about it, but since v17 hit stable since then, I'm going to rebase those proposed changes against that version. No ETA on that as of yet - I've started back at college, so time is already kind of a rarity; in addition, given the age of the Kindles already (5+ years!), it may not be a thing to sustain long term. I still have my 8.9", so testing isn't an issue, but I don't expect Magisk running on these specific devices to function as expected (so more than likely SafetyNet will fall, probably Magisk Hide as well). I'm not 100% sure how it'll turn out, but these are pretty much going to be unofficial builds for as long as I/anyone else willing to run builds sees a benefit to doing so. When a build works to my satisfaction, I promise it'll go up on XDA.
Click to expand...
Click to collapse
Successfully patched the boot image and installed magisk 18 and installed some modules and they work
Trey n said:
Successfully patched the boot image and installed magisk 18 and installed some modules and they work
Click to expand...
Click to collapse
Great! Will you post the boot image? What modules have you tried? Is Wifi, Bluetooth, and LTE working?
kgiesselman said:
Great! Will you post the boot image? What modules have you tried? Is Wifi, Bluetooth, and LTE working?
Click to expand...
Click to collapse
took me a while but also finally got it all working. Thanks for this guide. It may help us in the 7, 8 and 10 tablets. I also note my Jem is currently on CM13
monster1612 said:
It's complicated. I recommend not doing this unless you're willing to follow it to the letter - when I get to creating the automated patcher, this won't be necessary.
Make backups!!
extract the boot.img from your ROM .zip, copy it to the device internal storage
install the Magisk Manager app, download the Magisk .zip and choose "patch boot image"; navigate to said boot image file
copy the modified image to a computer (preferably one running a Linux OS like Ubuntu)
download the boot_cert and u-boot.bin files from the official LineageOS/CM device repo; place these files in the same directory as the boot.img file
open a Linux terminal pointed to the same directory as the boot.img file
run for i in $(seq 1024); do echo -ne "\x00\x50\x7c\x80" >> stack.tmp; done to create the remaining file
run cat boot_cert patched_boot.img > boot.img (assuming the Magisk image produced is named patched_boot.img); this is the boot "signature"
run dd if=u-boot.img of=boot.img bs=8117072 seek=1 conv=notrunc to tag the second bootloader on
finally, run dd if=stack.tmp of=boot.img bs=6519488 seek=1 conv=notrunc to add the stack file; copy the new boot.img back to the kindle
reboot into recovery, flash the Magisk .zip to build the environment, but do NOT reboot yet
choose "Flash .img" within TWRP, select the boot.img, and select "Boot" to flash to the boot partition; reboot to system once complete
profit!
Click to expand...
Click to collapse
This works on the Kindle Fire HD 7 as well, just use the files from the Tate repository.
Devo7v said:
https://forum.xda-developers.com/showthread.php?t=2128848&p=75525760
I know it's not for the 8.9" but I was able to get my 7" working by repeating the procedure in step 5. Magisk messes up the kernel on the Kindle so all you have to do is reflash the kernel. You'll need a fastboot cable to get in fastboot mode though.
Take a look at the few posts before the one I linked to.
Click to expand...
Click to collapse
I also have the same issue, but I'm confused as to your referencing for Step 5, because the guide says specifically not to flash the freedom-boot image if you already have a custom ROM present. Can you reiterate on what to do, please, or can I ignore this warning?
BrianSamsungTab said:
I also have the same issue, but I'm confused as to your referencing for Step 5, because the guide says specifically not to flash the freedom-boot image if you already have a custom ROM present. Can you reiterate on what to do, please, or can I ignore this warning?
Click to expand...
Click to collapse
I reflashed the freedom-boot and got everything working properly. It's been a few months so I don't remember if i had to continue anything when it finally booted, but I do know that I didn't lose any data. I still don't know if you need to flash freedom-boot, but it works if you do.
a little late to the party but-
i recently made the mistake of installing magisk and it put the kindle in a bootloop. is there a way to push the stock boot.img with this method or is that too quick and dirty
any advice is appreciated. im tempted to just do a full wipe via the stock recovery but if theres a more surgical method id go for it. i also have a linux debian machine available.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Preamble
When TWRP first appeared for the S10 range of devices, it quickly became clear that there were some major issues with the initial builds.
Many users were understandably frustrated at losing the ability to boot their device after shutting it down, and at being unable to update Magisk after installing TWRP.
A number of users took to contacting me privately for support. I answered their questions and even shared fixed images in a few cases, but the number of support requests was rising daily and I could not keep pace with the demand.
Given that the poster of the original images (Geiti94) was evidently unable to offer fixed TWRP images in a timely fashion, I ultimately took the liberty of doing so myself in a posting to the original TWRP thread as a service to the community.
Whilst this served to relieve the immediate pressure, the ongoing need to fix bugs and make further enhancements to the software made a fork of the original project inevitable, so I have taken the step of promoting it to its own DevDB project and thread here on XDA.
Credit goes to Geiti94 for conducting the time-consuming initial legwork and releasing the original builds. His is the foundation on which this work now builds. This fork in no way implies any disrespect to him, but does strongly acknowledge the need of the S10 user base to be supplied with proper, working images and timely updates.
Samsung system-as-root devices
All new devices launched with Android 9 are required to be factory-configured as system-as-root devices. The ramdisk image formerly found in boot.img is now merged with system.img.
For Samsung devices such as the Galaxy S10 series, this means that boot.img can no longer be used to root the device. Instead, Magisk is installed to the recovery partition and the user must subsequently always boot from that partition, regardless of whether TWRP or Android is desired. The device's hardware keys are used at boot time to select between Magisk-rooted Android and TWRP.
This configuration dictates that TWRP and Android share a common recovery kernel. However, because TWRP cannot function with a stock kernel, a modified kernel must be compiled from Samsung's source code. Unfortunately, this kernel is sensitive to changes in Samsung's firmware releases from one month to the next, meaning that problems can arise if a given kernel is used with firmware newer than the version the kernel was intended for.
This unfortunate situation necessitates semi-regular maintenance releases of TWRP to keep the kernel in step with the latest version of the S10 series firmware. This requirement is further complicated by the fact that any given release of Samsung's modified kernel source code typically trails the associated firmware release by anything from a few days to a few weeks.
TWRP without Magisk
If your device is currently still unrooted and running stock firmware, you are strongly advised not to proceed with installing TWRP. First root your device with Magisk, using John Wu's excellent Samsung system-as-root-instructions for patching the firmware's AP file. Only when you have completed that procedure should you return here and continue from the Image Preparation section.
If you insist on proceeding with installing TWRP to a stock device without Magisk, you will need — at a minimum — to flash a vbmeta.img with verity disabled or you will render your device unable to boot. You can construct such an image using the following command:
Code:
$ avbtool make_vbmeta_image --out vbmeta.img
Alternatively, if you don't have a copy of avbtool at hand, the following piece of shell code will do the trick on the device itself:
Code:
h=$(printf '4156423%08d1%0240d617662746f6f6c20312e312e3%0230d')
d=''
i=0
while [ $i -lt ${#h} ]; do
d="$dx${h:$i:2}"
i=$((i+2))
done
printf "$d" > vbmeta.img
Next, flash this to the vbmeta partition, using either Heimdall or Odin.
Code:
# heimdall flash --VBMETA vbmeta.img
You may then proceed with installing TWRP according to the instructions below.
Image preparation
In contrast to the original Geit94 release, these and subsequent TWRP images will not be supplied pre-rooted with Magisk. Whilst it would be trivial to offer them in this format, this kind of binary distribution of Magisk is against the terms of use laid out by Magisk's developer, John Wu.
To root the TWRP image yourself, simply use Magisk Manager to Select and Patch a File. Provide your freshly downloaded TWRP image file as the input.
Installation
You are now ready to flash the resulting magisk_patched.img image file to your device's recovery partition.
One quick and easy way to do this on an already rooted device is from a root shell:
Code:
# f=/storage/emulated/0/Download/magisk_patched.img; dd if=$f of=/dev/block/sda15 bs=$(stat -c%s $f)
1+0 records in
1+0 records out
61734912 bytes transferred in 0.426 secs (144917633 bytes/sec)
If TWRP is already installed and you are merely updating it, you may, of course, use TWRP itself to flash the new version.
If the device is not yet rooted (or even if it is), you may use Odin in Windows, but you will need to rename and tar the image first. Otherwise, Odin will not understand what to do with the image.
For example:
Code:
$ mv twrp-beyond[012]lte.img recovery.img
$ tar cf twrp-beyond[012]lte.img.tar recovery.img
And if rebooting to Windows is too disruptive, there's always Heimdall:
Code:
$ sudo heimdall flash --RECOVERY twrp-beyond[012]lte.img
Download
The latest unofficial local builds currently available are:
Android 10
G970F (S10e): twrp-beyond0lte-3.4.0-4_ianmacd.img
G973F (S10): twrp-beyond1lte-3.4.0-4_ianmacd.img
G975F (S10+): twrp-beyond2lte-3.4.0-4_ianmacd.img
G977B (S10 5G): twrp-beyondx-3.3.1-100_ianmacd.img
Android 9
G970F (S10e): twrp-beyond0lte-3.3.1-13_ianmacd.img
G973F (S10): twrp-beyond1lte-3.3.1-13_ianmacd.img
G975F (S10+): twrp-beyond2lte-3.3.1-13_ianmacd.img
G977B (S10 5G): twrp-beyondx-3.3.1-7_ianmacd.img
Official builds were also offered by me until the release of Android 10 for the S10 series, but have been discontinued. They offered no practical advantage over the unofficial builds, yet added considerably to the administrative burden. Any build for Android 10 and tagged official has not been built by me.
These builds are based on the latest version of TWRP and include a kernel compiled from Samsung's latest available source code. The kernel runs in SELinux enforcing mode and its configuration has intentionally been kept as close to stock as possible in order to provide maximum compatibility with both Android and TWRP.
The builds have been well-tested and are known to work as intended on supported firmware versions. See posting #2 of this thread for details of which TWRP builds work with which versions of Samsung's firmware.
If you later find yourself running on updated firmware that is incompatible with this kernel, you have the option of flashing and rebooting to TWRP on demand. When you are finished in TWRP, you can replace your recovery image with Magisk-rooted stock recovery and reboot back to Android.
If installing TWRP on your device for the first time or reinstalling it following a firmware upgrade, do not forget to disable file-based encryption (FBE) immediately after flashing TWRP or you won't be able to read files on /data in TWRP. To achieve this (and to protect yourself against various anti-root protection mechanisms that Samsung have booby-trapped the device with), flash the latest version of the multidisabler as soon as you have installed TWRP.
Device firmware updates
When it comes time to update your device's firmware, please follow John Wu's excellent instructions for patching the firmware's AP file. Do not skip any of the steps.
Next, use Odin to flash the patched AP file, together with the stock BL, CP and HOME_CSC files. Never leave the CSC slot empty when flashing an AP file, or your /data partition may be shrunk and your data damaged during the flash.
When finished, immediately reboot back to download mode and reflash your Magisk-patched TWRP image. Alternatively, you may replace recovery.img in the patched AP file with your rooted TWRP image, thereby avoiding the need to separately reflash TWRP afterwards:
Code:
$ tar f magisk_patched_twrp.tar --delete recovery.img && tar rf magisk_patched_twrp.tar recovery.img
Lastly, boot to TWRP and reflash the latest version of the multidisabler. Note that your first boot to TWRP after installing new firmware may just run a post-installation recovery script that wipes /cache, so you may need to trap the automatic reboot that follows and boot to TWRP a second time.
Do not skip rerunning the multidisabler, as flashing new firmware will have re-enabled critical security features that you must now re-disable.
Frequently Asked Questions
Q. I've just updated my G97[035]F device to ASIG firmware and now I can no longer boot to TWRP, which means I also can't flash the multidisabler to keep encryption disabled. What can I do?
Samsung's new ASIG firmware for the S10 series has proven to be incompatible with any kernel compiled for an earlier version of the firmware. You are urged to upgrade to TWRP version 3.3.1-10_ianmacd or later to avoid problems with this firmware.
If you are unable or unwilling to do this, the following procedure should be observed:
If you simply upgrade to this new firmware as usual, by patching the AP file with Magisk Manager, you will find yourself unable to boot TWRP afterwards, and therefore also unable to flash the multidisabler. This is a potentially dangerous situation, as it can lead to data loss if not properly tackled.
1. When flashing the new full firmware in Odin, use the BL file from the previous ASH6 firmware, not the one from ASIG. Include the latest version of TWRP as recovery.img in the AP file, as per usual.
2. After flashing the firmware, reboot to TWRP as usual. Flash the multidisabler and any other files you usually flash as part of the post-upgrade process.
3. Make a copy of the ASIG BL tar file. From this copy, either remove vbmeta.img or replace it with a benign copy constructed as per the #vbmeta note in this group.
4. Use Odin to flash your modified BL file, together with a Magisk-patched copy of the stock ASIG recovery image in the AP slot.
5. Reboot to rooted Android.
If you follow these instructions, you will successfully upgrade your device to ASIG firmware, whilst retaining a decrypted /data file-system, etc.
TWRP can still be used on demand, but you will need to add the swapping of the bootloader to your existing procedure for switching between stock and custom recovery. Or you can simply wait a couple of weeks for Samsung to release updated kernel source code for ASIG, at which time I will issue new builds of TWRP.
Lastly, there are apparently some new TWRP builds currently doing the rounds that deal with the ASIG incompaibility issue by including a kernel hacked together from a mixture of S10 and Note10 source code. Approach such hybrids with due caution.
Q. I don't want to dual-boot Android using the custom kernel from my TWRP image. The latest TWRP kernel is often compiled for older firmware. Even if there are no visible issues using this older kernel, I'm probably missing out on improvements and fixes made in the latest kernel. Is there really no other way to run TWRP on these devices?
A. Actually, there is another way and it's actually simpler than and therefore preferable to dual-booting. You can opt to simply flash and boot TWRP on demand, leaving a Magisk-rooted stock recovery on your device the rest of the time.
For example, the following simple script could be used to toggle your recovery partition between stock and TWRP images.
Copy the following (not as the superuser) into a file, for example /storage/emulated/0/switch-recovery:
Code:
#!/bin/sh
twrp_img=/storage/9C33-6BBD/twrp-3.3.1-4.img
# Path to ext. SD is different in TWRP.
stock_img=/external_sd/recovery-asf3-magisk.img
if [ -f /sbin/magisk ]; then
# We're in Android: Switch to TWRP.
#
infile=$twrp_img
su='su -c'
else
# We're in TWRP: Switch to Android.
#
infile=$stock_img
fi
$su dd if=$infile of=/dev/block/sda15 bs=$(stat -c%s $infile) && reboot recovery
Then run it in Android in a terminal session:
Code:
# sh /storage/emulated/0/switch-recovery
It will flash your TWRP image and reboot the device to recovery. If the TWRP image is rooted, you'll still need to press the usual key combo to force pass-through to TWRP.
Do your work in TWRP and then run the script again from the TWRP terminal. This time, it will reflash your stock recovery image and reboot again to recovery. There's no need to press the hardware keys this time, because you are booting to Magisk-rooted Android.
Obviously, you must change the paths in the script to match where your own images are stored.
Q. Somewhere in upgrading my firmware, rooting and installing TWRP, my /data file-system mysteriously shrank to a fraction of its former size and appears to have been wiped. What happened? Is TWRP responsible for this?
A. No. This appears to be a side-effect of using Odin to flash an AP file to these devices with the CSC slots left empty. Never flash a full AP file on this range of devices without also filling at least the HOME_CSC slot. It is safe, however, to flash only a recovery image in the AP slot.
To attempt to repair the damage, you need to boot to TWRP, select Advanced Wipe, tick Data, select Repair or Change File System followed by Resize File System. Your /data will return to its former size, but you will probably find you have lost some data. Restore a /data back-up afterwards to be sure of having all your data.
Q. When I mount /system and execute commands in the TWRP terminal or over adb, I get a lot of noise about problems with the dynamic linker.
A. This problem is fixed as of version 3.3.1-1_ianmacd.
It is caused by /etc/system becoming a symlink to itself when /system is mounted, resulting in infinite recursion when followed.
The screen on your text is just a warning, not an error. Your commands are still being executed.
Nevertheless, noise annoys, so you can silence the warning by pasting the following commands into the terminal (with thanks to John Wu):
Code:
# mount --move /system /system_root && mount -o bind /system_root/system /system
Q. My favourite zip doesn't flash properly using this TWRP. Someone said these TWRP builds are to blame, because they don't include BusyBox. Why don't you fix them?
A. Because there's actually nothing wrong with them. It's the installer code of your favourite zip that is broken. TWRP is merely exposing that fact. Don't shoot the messenger.
A lot of poorly written legacy installer code lazily assumes the presence of certain binaries, in particular BusyBox. However, the inclusion of BusyBox in TWRP is a compile-time option entirely at the discretion of the builder. It is not a requirement.
Not only that, but the inclusion of BusyBox in builds of TWRP targeting Android 9.0 and later is officially deprecated. Maintainers of such devices are instead advised by the TWRP team to use Toybox, and these builds for the S10 series comply with that advice. Furthermore, it's actually currently impossible to even build an official TWRP image for these devices with BusyBox included. Compilation of TWRP on the official build server will fail if this is attempted.
In short, the assuming BusyBox's presence on the device is unsafe and your favourite zip's author should fix his installer code. Supply him with an installation log and politely ask him to rewrite the installer code to be independent of this historical TWRP implementation detail.
Anyone who maintains that TWRP is broken without the inclusion of BusyBox is simply either unwilling or unable to grasp the facts.
Q. When I boot to Android, I can no longer log in. Why?
:victory:
A. Probably because of a mechanism called rollback protection. What has most likely happened here is that you have previously booted the device from a boot image with a later security patch level than the one from which you are trying to boot now.
As an example, let's say you are currently booting your device from a TWRP image with a security patch level of 2019-06. Then, Samsung issues a firmware update with a patch level of 2019-07. You update to that firmware, but immediately replace the stock recovery image with your trusty TWRP image and keep booting from that. Everything continues to work as it did before.
However, one day, you accidentally boot the device from the boot partition instead of the recovery partition. The device predictably comes up unrooted, but more significantly, it has now been booted from a (stock) boot image with a patch level of 2019-07, a fact that the device has now also committed to memory.
If you now reboot from the recovery partition, you will find that Android will no longer allow you to log in when the lock screen appears. This is because you are attempting to boot from an image with a patch level (2019-06) that is now earlier than the latest one previously used to boot the device (2019-07). Android considers this insecure and will not allow it. This mechanism is called rollback protection.
The simplest solution and the one with the least negative impact is to update the security patch level of the TWRP image to match that of the latest image used to boot the device. You can achieve this using magiskboot unpack -h or with AIK.
Links
TWRP source code for Android 9.0
Unofficial device tree for the G970F
Unofficial device tree for the G973F
Unofficial device tree for the G975F
Unofficial device tree for the G977B
Combined kernel source code for the G97[035]F
Kernel source code for the G977B
Telegram group
XDA:DevDB Information
TWRP for Galaxy S10 Exynos series, Tool/Utility for the Samsung Galaxy S10+
Contributors
ianmacd, Geiti94
Version Information
Status: Stable
Current Stable Version: 3.4.0-4_ianmacd
Stable Release Date: 2020-11-17
Created 2019-04-25
Last Updated 2020-11-17
Changelog
v3.4.0-4_ianmacd for G97[035]F [inc. DTJA kernel] (2020-11-17)
Rebase kernel on Samsung's DTJA source code.
Merge all outstanding fixes and enhancements from the TWRP source tree.
This version is intended for use only with Android 10.
v3.4.0-3_ianmacd for G97[035]F [inc. DTH7 kernel] (2020-09-11)
Rebase kernel on Samsung's DTH7 source code.
This version is intended for use only with Android 10.
v3.4.0-2_ianmacd for G97[035]F [inc. CTG4 kernel] (2020-08-14)
Rebase kernel on Samsung's CTG4 source code.
This version is intended for use only with Android 10.
v3.4.0-1_ianmacd for G97[035]F [inc. CTF1 kernel] (2020-06-30)
Update TWRP to version 3.4.0.
This version is intended for use only with Android 10.
v3.3.1-105_ianmacd for G97[035]F [inc. CTF1 kernel] (2020-06-18)
Rebase kernel on Samsung's CTF1 source code.
This version is intended for use only with Android 10.
v3.3.1-104_ianmacd for G97[035]F [inc. CTD1 kernel] (2020-05-31)
Rebase kernel on Samsung's CTD1 source code.
This version is intended for use only with Android 10.
v3.3.1-103_ianmacd for G97[035]F [inc. CTC9 kernel] (2020-03-31)
Rebase kernel on Samsung's CTC9 source code.
This version is intended for use only with Android 10.
v3.3.1-102_ianmacd for G97[035]F [inc. BTA8 kernel] (2020-02-08)
Rebase kernel on Samsung's BTA8 source code.
This version is intended for use only with Android 10.
v3.3.1-101_ianmacd for G97[035]F [inc. BSKO kernel] (2019-12-20)
Fix for cosmetic Unable to decrypt FBE device message that was sometimes displayed in the previous Android 10 release (-100).
This version is intended for use only with Android 10.
v3.3.1-13_ianmacd for G97[035]F [inc. ASJG kernel] (2019-12-20)
Fix for cosmetic Unable to decrypt FBE device message that was sometimes displayed in the previous Android Pie release (-12).
This version is intended for use only with Android 9.
v3.3.1-100_ianmacd for G977B [inc. BSL2 kernel] (2019-12-20)
Rebase kernel on Samsung's BSL2 source code.
This version is intended for use only with Android 10.
v3.3.1-7_ianmacd for G977B [inc. ASJ7 kernel] (2019-12-19)
Rebase kernel on Samsung's ASJ7/ASK1 source code.
Merge latest upstream TWRP commits.
v3.3.1-100_ianmacd for G97[035]F [inc. BSKO kernel] (2019-12-07)
Rebase kernel on Samsung's BSKO source code.
This version is intended for use only with Android 10.
v3.3.1-12_ianmacd for G97[035]F [inc. ASJG kernel] (2019-12-03)
Rebase kernel on Samsung's ASJG source code.
v3.3.1-11_ianmacd for G97[035]F [inc. ASIG kernel] (2019-10-11)
Add support for Samsung DeX for PC.
v3.3.1-10_ianmacd for G97[035]F [inc. ASIG kernel] (2019-10-07)
Rebase kernel on Samsung's ASIG source code.
Merge latest upstream TWRP commits.
v3.3.1-9_ianmacd for G97[035]F [inc. ASH6 kernel (which also works with ASH1 firmware)] (2019-09-17)
Restore working MTP functionality to TWRP. With thanks to bigbiff for the reference and to Geiti for his commit embodying the same fix.
v3.3.1-8_ianmacd for G97[035]F [inc. ASH6 kernel (which also works with ASH1 firmware)] (2019-09-06)
Kernel rebased on Samsung's ASH6 source code.
v3.3.1-7_ianmacd for G97[035]F [inc. ASG8 kernel (which also works with ASH1 firmware)] and v3.3.1-6_ianmacd for G977B [inc. ASF5 kernel] (2019-08-20)
File-based System back-up option was missing in v3.3.1-6_ianmacd.
v3.3.1-6_ianmacd for G97[035]F [inc. ASG8 kernel (which also works with ASH1 firmware)] and v3.3.1-5_ianmacd for G977B [inc. ASF5 kernel] (2019-08-18)
Use $ANDROID_ROOT to set the mount point for the system block device to /system_root on these system-as-root devices.
This change renders this and future TWRP releases incompatible with previous versions. Any existing zip file installer code that attempts to mount /system or expects the system block device to be mounted on /system will now fail under this new version and will require modification.
Solved infinite recursion of symbolic links when resolving /system paths.
v3.3.1-5_ianmacd for G97[035]F [inc. ASG8 kernel (which also works with ASH1 firmware)] (2019-08-07)
Kernel rebased on Samsung's ASG8 source code.
v3.3.1-4_ianmacd for G977B [inc. ASF5 kernel] (2019-07-06)
Kernel rebased on Samsung's ASF5 source code.
Hugely improved Dutch translation.
v3.3.1-4_ianmacd for G97[035]F [inc. ASF3 kernel] (2019-07-05)
Kernel rebased on Samsung's ASF3 source code.
Hugely improved Dutch translation.
v3.3.1-3.1_ianmacd for G977B [inc. ASEC kernel] (2019-06-21)
First production release for the G977B (beyondx).
v3.3.1-3.1_ianmacd for G97[035]F [inc. ASE7 kernel] (2019-06-12)
Removed an experimental patch that was accidentally included in v3.3.1-3_ianmacd.
Previous releases were for the G97[035]F only:
v3.3.1-3_ianmacd [inc. ASE7 kernel] (2019-06-12)
Kernel rebased on Samsung's ASE7 source code.
v3.3.1-2_ianmacd [inc. ASD5 kernel] (2019-05-21)
Image back-ups of /product now possible.
v3.3.1-1_ianmacd [inc. ASD5 kernel] (2019-05-17)
Updated to upstream v3.3.1-0.
Fix linker warnings when binaries are executed while /system is mounted.
v3.3.0-2_ianmacd [inc. ASD5 kernel] (2019-05-11)
Kernel rebased on Samsung's ASD5 source code.
v3.3.0-1_ianmacd [inc. ASCA kernel] (2019-04-26)
Add support for mounting, backing up and restoring /product.
Add support for backing up and restoring /vendor.
Partitions now listed alphabetically.
Default brightness now 66% of maximum brightness (was 50%) to aid reading.
v3.3.0-0 [inc. ASCA kernel] (2019-04-21)
First ianmacd release.
TWRP updated to 3.3.0-0.
Fixes death on power-off issue, which left device unable to boot when turned back on.
Fixes inability to upgrade Magisk via Magisk Manager.
Replaces SELinux permissive kernel with enforcing kernel.
Reserved
Well done sir, well done!
Thank you for your continued work and support for TWRP.
Just to confirm the process if we want root and are already rooted -
follow your steps to root the new TWRP Image you posted today and zip it as a tar file in 7Zip
Flash rooted twrp in Odin
Reboot to Recovery
Format Data
Flash New Disabeler Script
Format Data again
Reboot in recovery (to reboot into magisk
Is that correct? (I read somewhere the other day that we needed to wipe again AFTER flashing the Disabler script and I didn't know if that was really necessary or if someone had mispoke?
Sorry to bother you but I have been trying to do as your OP outlines - but everytime I create a TAR File using the TWRP you provided patched with Magisk, when I try to flash in ODIN - nothing happens. The file won't flash. I have started over 5 times - created new Patched images in Magisk each time - but for some reason I am not having any luck getting this to flash in odin.
Can I flash the MAgisk patched Recovery Image in TWRP ?
EDIT - I answered my own question - I went ahead and tried to flash in TWRP and it flashed perfectly. All is good. But still curoiuos why I couldn't get the Patched Twrp File to fliash via odin - ?
Geekser said:
Sorry to bother you but I have been trying to do as your OP outlines - but everytime I create a TAR File using the TWRP you provided patched with Magisk, when I try to flash in ODIN - nothing happens. The file won't flash. I have started over 5 times - created new Patched images in Magisk each time - but for some reason I am not having any luck getting this to flash in odin.
+1
Click to expand...
Click to collapse
Great thread @ianmacd
By clicking on the button below you will get a set of instructions, step-by-step, on how to install Ians excellent work with TWRP as a recovery for your device and John Wu's root via Magisk.
This is not the fastest or most uncomplicated tutorial to do this. It is, however, made to make sure as many as possible succeed. So if you feel that a step or two is uncessesary, this tutorial is probably not for you since you most likely already know enough to just go by Ians more direct instructions. So dont PM me with tips on how to simplify these steps, I already know about that and that is not the point of the tutorial.
The instructions are intended for:
The user that either is completely new to this world but have managed to get an unlocked bootloader beforehand
The user that just want to have some instructions to follow to not forget a step in the process
Please note that the tutorial should work just fine for the S10E-device, but there might be another set of key combinations for your device, please take care to understand what you need to do in specifics to do the same presses of buttons.
It is strongly encourage to flash lates stock firmware and do a complete clean system install before using this tutorial. However, if you know what you are doing, it will work fine with an already rooted system as long as you have the latest Canary build (both magisk and magisk manager) on your device when patching the TWRP-image and the firmware AP-file per instructions below.
Where ever you decide to start, know that your device will be wiped and you need backups for your relevant data before you begin.
These instructions are ...
.. an "add-on" till John Wu's Magisk solution that will make your device rooted with Magisk and having Ian Macdonalds TWRP-recovery
.. for those who have already an unlocked bootloader - DO NOT attempt this without first making sure you have "OEM Unlocked" enabled
Step-by-step guide:
A) Follow John's instructions HERE until you get to step 5, then return here
B) Download latest TWRP-image by Ian Macdonald for your type of device in the first post in this thread
C) Download latest multidisabler-zip by Ian Macdonald and copy it to your SD-CARD - download here
D) Copy the TWRP-image to your device and do the same as you did with the AP-file in Magisk Manager (Install->Install->Patch file and choose the TWRP-image)
E) Copy the patched TWRP-image and magisk_patched.tar to your computer
F) Rename the patched TWRP-image to "recovery.img" on your computer
G) With your own choice of program on your computer, open the "magisk_patched.tar"-file, remove the existing recovery.img and replace it with your newly patched recovery.img and save the tar-file
H) Boot your device to download mode
I) Go back to John's instructions and IGNORE step 6 and DO step 7 and come back here!
J) We now need to factory reset our device:
-> Press Power + VolDown for a few seconds to get out of download mode
-> AS SOON AS THE SCREEN GOES BLACK: Press Power + Bixby + VolUP and HOLD THESE KEYS FOR A LONG TIME until you see the bootlogo of TWRP, then release the keys
K) In TWRP, install your downloaded multidisabler-zip from your SD-CARD and DO NOT REBOOT
L) In TWRP, format data (not only wipe, choose specifically "Format data" and write "yes" and go ahead and after DO NOT REBOOT
M) In TWRP, go back to the start screen - choose "Reboot" and choose "Recovery" AND NOTHING ELSE - DONT touch any keys on the device
N) Go back to John's instructions and begin from step 12
O) All done - you know have a rooted device by Magisk, with TWRP as recovery - enjoy and be sure to thank Ian Macdonald for the help with TWRP and John Wu for Magisk root!
hanspampel said:
Here are the magisk patched files for all devices. Only tried my s10+, but all the others should work too with odin.
Click to expand...
Click to collapse
Did you not read the OP?
John Wu does not allow the distribution of Magisk binaries in this way. If he did, I would have supplied pre-patched images myself. Post reported for removal.
Ian, does it matter the MM version when patching the AP and twrp img or all MM versions are doing the same job?
Thanks you.
starbucks2010 said:
Ian, does it matter the MM version when patching the AP and twrp img or all MM versions are doing the same job?
Click to expand...
Click to collapse
You need a recent Canary or ianmacd build, certainly from April. I would upgrade to the most recent build if I were you.
Great work Ian greatly appreciated that your placing your time into the community.
Don't copy me (got lazy) but I currently had twrp, so I just patched (the new img) flashed in Odin, and all appears to be good.....
ianmacd said:
changelog
v3.3.0-1_ianmacd (2019-04-26)
Add support for mounting, backing up and restoring /product.
Add support for backing up and restoring /vendor.
Partitions now listed alphabetically.
Default brightness now 66% of maximum brightness (was 50%) to aid reading.
Click to expand...
Click to collapse
Thank you for the decision to do this.
I made some backups on v3.3.0-0 and I believe /vendor was also included. Would there be anything wrong with these backups made on v3.3.0-0 now that I see such a line in the changelog? Did /vendor not backup correctly on TWRP 3.3.0-0?
So it is /vendor and /vendor image like with with system and system image. I flashed the latest TWRP and saw this..
But my Magisk manager patches my recoveries. badly
This is the 3rd time this happens to me.
After patching v3.3.0-1 i used the dd command to flash it. Then booted in TWRP, confirmed it was v3.3.0-1 and even made me a backup.
But I rebooting to rooted system isn't possible. The phone only boots to recovery no matter what. So I flashed patched v3.3.0-0 back. Things worked and booted to system. There I found that this latest "magisk_patched.img" is ~6 mb less than the raw "twrp-beyond2lte-3.3.0-1_ianmacd.img"
So I patched again. And again the produced "magisk_patched.img" was the same as the first one. How can I help myself here?
My Magisk Manager is 7.1.1 -54d1207f (207)
I am attaching the log file from MM for patching process .
tiho5 said:
So it is /vendor and /vendor image like with with system and system image. I flashed the latest TWRP and saw this..
But my Magisk manager patches my recoveries. badly
This is the 3rd time this happens to me.
After patching v3.3.0-1 i used the dd command to flash it. Then booted in TWRP, confirmed it was v3.3.0-1 and even made me a backup.
But I rebooting to rooted system isn't possible. The phone only boots to recovery no matter what. So I flashed patched v3.3.0-0 back. Things worked and booted to system. There I found that this latest "magisk_patched.img" is ~6 mb less than the raw "twrp-beyond2lte-3.3.0-1_ianmacd.img"
So I patched again. And again the produced "magisk_patched.img" was the same as the first one. How can I help myself here?
My Magisk Manager is 7.1.1 -54d1207f (207)
I am attaching the log file from MM for patching process .
Click to expand...
Click to collapse
When that symptom shows, only booting to recovery no matter what, it is always a sign that the recovery you flashed wasn't patched with Magisk.
Are you sure you are flashing the right file? I don't use dd but if you have Odin available, try instead to tar that magisk_patched.img and flash that tar in Odin instead.
Because if you are sure that the IMG is patched alright, then something with dd is not working.
/P
Edit: The shrinking you observe is normal and is as expected.. so it should be patched and then I suspect something in the process of using dd.
PiCkLeS said:
When that symptom shows, only booting to recovery no matter what, it is always a sign that the recovery you flashed wasn't patched with Magisk.
Are you sure you are flashing the right file? I don't use dd but if you have Odin available, try instead to tar that magisk_patched.img and flash that tar in Odin instead.
Because if you are sure that the IMG is patched alright, then something with dd is not working.
/P
Edit: The shrinking you observe is normal and is as expected.. so it should be patched and then I suspect something in the process of using dd.
Click to expand...
Click to collapse
No mate... The patching process is done right, I'm sure. And I also tried with Odin before I posted although I was sure it was not going to help. The recovery simply doesn't get patched right for some reason. This happened to me a few times before.
There is a log attached and one can see what happened and if I'm doing anything wrong (which indeed I doubt).
And also the patched files that I had done successfuly were more or less the same size as the raw file, only slightly bigger. This time it's not like that at all.
I was sure there's no working Magisk in that package.
The dd commands work and they're very convenient. I've used them for years. After I dd'd it, I indeed booted to the new recovery, saw that it's the new version, saw the changed things, the alphabetic order, even made a backup.
I didn't look much at the log file as it doesn't make too much sense to me, but I sure hope that Ian could investigate it.
Thanks anyway, mate.
I just ordered an S10e SM-G9700 with the unlocked Snapdragon bootloader (unlike the locked North American version). Will this work on that or is this purely for Exynos-based devices?
tiho5 said:
No mate... The patching process is done right, I'm sure. The recovery simply doesn't get patched right for some reason. This happened to me a few times before.
There is a log attached and one can see what happened and if I'm doing anything wrong (which indeed I doubt).
I didn't look much at the log file as it doesn't make too much sense to me, but I sure hope that Ian could investigate it.
Click to expand...
Click to collapse
Your log file shows this:
Code:
- Unpacking boot image
Parsing boot image: [/data/user_de/0/com.topjohnwu.magisk/install/boot.img]
It appears you patched a boot image, not a recovery image. Further output in the log show that it was, indeed, treated as a boot image, not a recovery image.
ianmacd said:
Your log file shows this:
It appears you patched a boot image, not a recovery image. Further output in the log show that it was, indeed, treated as a boot image, not a recovery image.
Click to expand...
Click to collapse
Why did Magisk Manager take the twrp-beyond2lte-3.3.0-1_ianmacd.img for a boot image? How can we avoid that.
There am I in need of a prepatched TWRP file, which is against the rules.
Do you have any idea how could I help my situation.