Here is the theory I want.
Given a mobile phone that has a lock on it wether pin code, pattern or password, If the mobile's bootloader was unlocked I can install a custom recovery and then boot to that recovery in which I can run the adb and have access to the data in the phone. If my hypothesis is correct then how I can build a recovery.img ??
I have been reading for the recover.img for 2 weeks and almost understood how it works and most of the files in it. However, I couldn't find a tutorial of how can I build my own recovery.img
What I decided to do it to modify on the CWM recovery.img.
So I downloaded the CWM and then I unpack it to see the kernel and the initrd. After decompressing the initrd, I found many files. I made a simple test which is to run a script from the init.rc. Inside the init.rc I added two lines. The first one to mount the /data partition and then I just echoed "test" to a file called text.txt then I rebooted my device to normal boot connected to adb and checked the /data partition, but unfortunately I didn't find anything.
I would like to know what I am missing and if my theory is correct or not and how can I build my OWN recovery and have something like adb running from the start.
Thank you
Related
So, I've picked up my replacement Xoom after bricking my first. I decided to rip my system and recovery partitions again for completeness, after discovering BeagleBoy's system.img was different from mine. I've posted my Xoom WiFi (MZ604) recovery.img in another thread. Anyway, I can confirm the WiFi recovery partition on both my old Xoom and new Xoom have an MD5 of 1f853c8636ab22b5d651a5512f0865c0. Great success! I hope others with a virgin Xoom Wi-Fi can confirm with me.
And here's something interesting... After ripping a new system.img (MD5 4b7b974a0cc8cdc00521de970b7fc611) from my new Xoom, I did a compare against my first system.img from my bricked Xoom. And also against BeagleBoy's. ALL 3 ARE DIFFERENT. I think I may have compromised my first system.img from my bricked Xoom by doing an "adb remount" before ripping the partition.
Now to confirm... With system.img having been extracted (and backed up) from my new Xoom. I performed an "adb remount" and immediately ripped the system partition again. Did a new MD5 check and... It changed... It's looking like a RW remount does compromise the "virginity" of the system.img file.
One more thing... I'm hoping someone with a factory locked WiFi Xoom can replicate BeagleBoy's boot.img file (MD5 051d1f7e150d4077adb388b5f8e53462). He flashed the Tiamat kernel onto the recovery partition instead of the boot partition (to maintain its integrity) and booted into recovery (Beagle, if you can elaborate on how to do this, please do).
I asked for expert help so I will not be doing step-by-step instructions.
Testing method 1 (retrieving system.img and recovery.img):
1. Put virgin Xoom in fastboot mode (if you can't do this, you shouldn't be helping)
2. Do a "fastboot oem unlock" and "fastboot flash boot.img" where boot.img is the Tiamat boot image to give you basic root. Reboot into normal mode.
3. With USB debugging on, do an "adb shell". Do not do a remount during test!
4. At the root (#) prompt, extract your system and recovery using the following commands (do recovery first, much faster):
dd if=/dev/block/platform/sdhci-tegra.3/by-name/recovery of=/mnt/sdcard/recovery_wifi_virgin.img
dd if=/dev/block/platform/sdhci-tegra.3/by-name/system of=/mnt/sdcard/system_wifi_virgin.img
Click to expand...
Click to collapse
5. Do an "adb pull" of the two .img files you created in /mnt/sdcard/.
6. Run a MD5 on the two files and report here.
7. ???
8. Profit
Test method 2 (install Tiamat into recovery partition and extract boot.img and system.img)
1. I will edit this section as needed. But the gist of it is to install Tiamat into recovery partition and then extract boot.img and system.img using a similar method to above...
...
8. In fastboot, reflash the recovery partition I saved on
References:
BeagleBoy's thread for his boot.img and system.img (http://forum.xda-developers.com/showthread.php?t=1017398)
My thread for the recovery.img file I first extracted (and hoping is consistant between all Xoom WiFi's of varying regions) at http://forum.xda-developers.com/showthread.php?t=1036574
Placeholder for an external link to my system.img file (when I have time to upload it somewhere for hosting)
Scourge1024's MD5 test results on old Xoom (fail?):
boot.img - (not tested)
system.img - 203465c9fb9d6bc926dd0dea9b85ebc4 (not valid as a clean image after remount)
recovery.img - 1f853c8636ab22b5d651a5512f0865c0 (matches my new Xoom; may not)
Scourge1024 new Xoom (Win?):
boot.img - (not tested)
system.img - 4b7b974a0cc8cdc00521de970b7fc611 (never RW mounted, hoping this is consistant)
recovery.img - 1f853c8636ab22b5d651a5512f0865c0 (matches my new Xoom; may not)
BeagleBoy:
boot.img - 051d1f7e150d4077adb388b5f8e53462 (trying to find out if this is consistent)
system.img - fd78a2297290c3fdc7377ded6090e2ae (does not match either of mine)
recovery.img - (not tested; overwritten)
Now to see if people can get a consistant MD5 for boot.img...
My expectation is that the kernel images (not the entire boot images) should be identical across devices and between boot and recovery.
The system image differences you're experiencing are probably expected -- remember *access* times are logged within the file system, it is ext4 after all -- and because you're pulling a system image, rather than the files themselves, you see a difference. Things like that are going to be difficult to eliminate.
ydaraishy said:
My expectation is that the kernel images (not the entire boot images) should be identical across devices and between boot and recovery.
The system image differences you're experiencing are probably expected -- remember *access* times are logged within the file system, it is ext4 after all -- and because you're pulling a system image, rather than the files themselves, you see a difference. Things like that are going to be difficult to eliminate.
Click to expand...
Click to collapse
If system is left in read-only access, would the access times be affected? I'm thinking this is possibly the reason why my "fastboot oem lock" failed. I had been able to relock my device before touching the boot, system and recovery partitions. Userdata was obviously changed the moment I booted up normally so I think that can be taken out of the equation. Plus, it gets wiped each lock/unlock anyway.
Anyway, I'm NOT going to try relocking my new Xoom... One heart attack was enough. And Best Buy might catch on I'm doing something I shouldn't be.
Can someone grab their MZ604 recovery partition? I'd like to see if they get the same MD5 I do. I doubt anyone has a modified recovery partition besides BeagleBoy. I'm trying to isolate if there's any difference between Canadian Wi-Fi Xooms (like my own) and the US ones. I already know my recovery partition is different than the MZ600 Verizon Xoom.
Think about this people... If Moto isn't going to give us Wi-Fi guys official img files, we'll have to get them ourselves.
Scourge1024 said:
If system is left in read-only access, would the access times be affected? I'm thinking this is possibly the reason why my "fastboot oem lock" failed. I had been able to relock my device before touching the boot, system and recovery partitions. Userdata was obviously changed the moment I booted up normally so I think that can be taken out of the equation. Plus, it gets wiped each lock/unlock anyway.
Anyway, I'm NOT going to try relocking my new Xoom... One heart attack was enough. And Best Buy might catch on I'm doing something I shouldn't be.
Can someone grab their MZ604 recovery partition? I'd like to see if they get the same MD5 I do. I doubt anyone has a modified recovery partition besides BeagleBoy. I'm trying to isolate if there's any difference between Canadian Wi-Fi Xooms (like my own) and the US ones. I already know my recovery partition is different than the MZ600 Verizon Xoom.
Think about this people... If Moto isn't going to give us Wi-Fi guys official img files, we'll have to get them ourselves.
Click to expand...
Click to collapse
I'd say mounting ro might help, but I'm not sure. It's possible filesystem metadata might change even if mounted read-only. I'd need to know more about ext4 to make a firm call.
One really needs to know what the "fastboot oem lock" procedure is using to validate the currently written images -- I have a feeling a signature check is being made, but I can't be sure of that. It might be fruitful to diff the Moto-provided images with ones dd'd off a running MZ600, perhaps. All just guesses though.
(let alone how cruddily designed it is to be only transitioned between lock and unlock states with correct firmware and no validation being made -- ie., it's very nicely easy to brick)
I have bricked my kyobo ereader (gingerbread 2.3.5) but still have fastboot and limited adb (no shell commands since there is no valid system) access on the device.
I have various update.zips for the device but unfortunately these are installable only on a working system (via settings->privacy->updates) and I know of no way of installing the update.zip since there does not appear to be any custom recovery for this ebook reader and booting into recovery does not install the update.zip on the sdcard.
The update.zip for the Kyobo ereader contains boot.img, recovery.img and a system folder containing files and directories for the system partition (an example of an official update.zip is available from m.kyobobook.co.kr/mirasol/update.zip )
I have extracted the system folder on a ubuntu system and need to prepare a system.img file which may be flashed using fastboot. I have also changed owner of the extracted files to root:root and chmod 777 on all the executables in the extracted system folders. A complication is that I only have the windows qualcomm hsusb drivers for fastboot or adb to connect to a pc, so I must use a windows 7 notebook to flash the device (possibly precluding pushing the system folder files to the device since they don't have permission and owner settings in windows)
I have tried various tools to make a system.img including the native linux mkcramfs and tools suggested by various google searches such as mkfs.yaffs2.x86 and make_ext4fs. All these tools could prepare a system.img but unfortunately they have different sizes and I am not sure which img is the correct one. I have tried to flash the various system.img using both fastboot flash system system.img and also by adding the system.img to the update.zip (together with placeholders for the required android-info.txt but in all cases they do not any files onto the sytem partition (although fastboot does send the system.img successfully to the device and writes the 120~180MB img files in about 50-70seconds. I have tried using both the official boot.img and the rooted boot.img. I noticed that the device reboots twice after such flashing which may be because there is some protection from the official recovery.img which checks the system partition an erases it if it does not match.
My first 2 questions are general and the third is specific to my situation:
1. What is the correct tool to generate an android system.img file from the extracted update.zip's system folder on a linux system?
2. Any suggestions on how to flash an update.zip using fastboot or adb?
3. Are there any generic recovery.img which I could try to flash over the official recovery partition on the kyobo mirasol ereader?
Any suggestions anyone?
FIRST OFF - THIS IS HIGHLY TECHINICAL AND NOT FOR NON-TECH INCLINED PEOPLE. YOU CAN REALLY MESS UP YOUR PHONE IF YOU DO IT WRONG. SO PAY ATTENTION OR FIND SOMEONE SMARTER THAN YOU WITH THIS ANDROID / LINUX STUFF. YOU DO THIS ON YOUR OWN - NO WARRANTIES EXPRESSED OR IMPLIED. IT'S FOR PEOPLE THAT DON'T WANT TO WAIT FOR THEIR VENDOR TO POST A FULL ROM AND UPDATE RIGHT WHEN AN OTA COMES.
So I wanted to update my rooted Op8T OOS version, and you CAN'T (haha) do it if you're rooted. That's kind of a misconception. I knew there had to be a way... so I found a dead repo out there that used to work on Incremental OTAs. And I read the issues - did not actually work. Why? Because you need to extract the prior firmware (full ROM) first with a Payload extraction tool (most are in Python, and most are Linux-only). Well, they got stuck because the original ROM has one signature (encryption), and the OTA update has another signature, so the program would break when they didn't match. So what did I do??? Well I have to give credit to the dev I forked this from, because he mentioned - of course the signatures don't match, they are different releases! So I did something kind of... well... let's put it this way, you aren't verifying any signatures anymore. So if you screw up and put the wrong ROM base (prior full ROM) and Payload extract the payload.bin, then apply the Incremental OTA, well, you're in for trouble. BE POSITIVE YOU ARE USING THE VERSION OF THE ROM THE OTA IS INTENTED TO INCREMENTALLY UPDATE!!!!
In this case, it was quite clear. I was trying to update an A11 Op8T from OnePlus. It was on 11.0.8.3 ROM and an OTA was posted that was for 11.0.9.9. SO I used a Windows tool to extract the first set of files (the full ROM is huge BTW). The incremental update came as a 150mb file zipped up, but it modified the BIG files. Once it finished, I found that system and system_ext are not flashable (grew in size, can't resize super on active slot, not updated), the rest are. And you MUST flash from fastbootd - this is kind of a mysterious new place with modern AB devices. It can be a pain to actually get there. The standard steps if you're on stock recovery are to enable developer options, USB debugging, install the Latest ADB and Fastboot https://github.com/fawazahmed0/Latest-adb-fastboot-installer-for-windows/releases/tag/v1.7 (this script will update it for you). Ignore the God references it's a batch file you can just modify it, and I don't judge. It will pull the latest versions (Minimal ADB and Fastboot are super outdated). Next steps...
Now, getting an incremental update off a rooted phone is not easy. 1) you have to flash a stock boot.img and recovery.img. 2) you have to basically uninstall Magisk, or at least the images 3) then you MAY be able to download with Oxygen Updater or the system app. It won't install though because root is fully exposed. Once it's downloaded, it appears in some very strange location with a random character string.zip I believe. So now you have to reinstall Magisk (to get adb shell SU access). So after I confirmed it downloaded (but wouldn't flash), I had to hook my phone up to the USB cable, go to the PC and Latest ADB and Fastboot folder, adb shell, su, then cd /; find . -name *.zip > /dev/null 2>&1; to cut out some of the garbage output and scroll until I found a logical zip stored somewhere (a folder than sounded like a OnePlus update folder). Then I did a: cp [random characters.zip] /sdcard/Download/OTA_Update.zip, which I could then transfer from my phone to PC with a USB cable. Developer options / default mode USB File Transfer FYI.
Okay that was one of the hard parts. Now next to more hard parts. You need a Linux environment (I used WSL2 Debian Buster). The easiest setup (after spending hours attempting to get the correct packages loaded) was to install the personal version of Anaconda Python x64 for AMD64 processors for Linux. Then I could use conda install [package name] for missing dependencies as the program would throw errors. Yes you have to read the errors or you won't be able to figure out what is actually not installed. Anyhow, the modded forked repo of python files is here: git clone the repo: git clone https://github.com/mrslezak/update_payload_extractor.git - now if git isn't setup on your Linux box, well, you're in for some trouble.
So once it's installed, you need to actually use python3 commands for each step - so anywhere you see "python" put "python3" instead as most machines have both 2.7 and 3.X installed. I used Python 3.8 something, so ignore the 3.6 it's not required. So here I took a payload.bin extracted with a Windows.exe file (available somewhere on XDA, there are severel, one is Go based) and copied them once extracted from the original ROM to the WSL instance on my Win10 PC. Now there come issues here. They need to go into an "old" directory you must create (in update_payload_extractor directory), and copying from Windows will make them root access only, so a: sudo chown user:user old/ is required to get it writable. I believe the program will make the rest of the files on its own. They will end up in "output." You just need to extract the payload.bin and payload.properties files from the incremental update you extracted and place them in the update_payload_extractor directory.
Now there is some strange stuff going on, this was always beta, and never working. So I took the note of the issues and blocked a Google certificate validation routine (just commented it out) so it doesn't verify anything. I say it again BE EXTREMELY CAREFUL THAT YOUR PRIOR FULL ROM AND OTA UPDATE ARE MEANT TO BE USED TOGETHER. Anyhow, run what it says if your system is setup:
Incremental OTA
Copy original images (from full OTA or dumped from devices) to old folder (with part name without file extension, ex: boot, system) - I put an .sh script here if your files are .img called remove_img_extension_old.sh - note that GitHub sometimes loses the execute permission so you may have to type: sudo chmod +x remove_img_extension_old.sh. It is meant to be run from the root of the project. ./remove_img_extension_old.sh
LD_LIBRARY_PATH=./lib64/ ./extract.py --output_dir output/ --old_dir old/ payload.bin
The above line will start the extract and combine process the OTA usually does on your phone, and output the files to the output directory. Once those are generated, then you can run another helper script I wrote to add back .img to each file called add_img_extension_output.sh again meant to be run from the root folder. Now you need to copy these output files (no guarantee all are updated, it will have all of them - on Op8T system and system_ext couldn't be flashed because they grew in size, and I don't know how to expand the super partition space to enable them to flash, so they aren't in the linked file - it still updates). The files on Op8T ending in lp5 are RAM files for the newest devices that are running LPDDR5 memory, the flash.bat script will need to be modified if you have one of these (2 flashes). The way I made the file will work in 98% of devices.
Okay I run the rest from Windows, so now it gets a little tricky. You need to get into Fastbootd, which means flash boot.img (you just extracted it), flash recovery image (same), using fastboot flash boot boot.img, fastboot flash recovery recovery.img. Now getting to fastbootd can be quite perplexing. You may just have your phone on, type adb reboot bootloader, then type fastboot reboot fastboot, and be in fastbootd (it will look like stock recovery but say fastbootd on top). The other way is to boot to recovery (developer options extended boot menu makes this much easier), then select Fastboot. Sometimes you get Fastboot and sometimes Fastbootd. It seems quite random. DON'T START THE FLASH_ALL.BAT UNTIL YOU KNOW YOU ARE IN FASTBOOTD!!!!
The fastboot command to tell you if you are in fastbootd (it will report yes if so: fastboot getvar is-userspace
Otherwise, those files will NOT be allowed to flash to your device, and you will end up with some random combination of prior and updated files. That could end badly. Once you DO get to Fastbootd, run the flash_all.bat, and DON'T SWITCH SLOTS. Yes, this is an OTA, but you already patched the files. Upon successful flashing, you can reboot to fastboot and flash a patched kernel with Magisk already enabled such as my forked Radioactive here: https://github.com/mrslezak/Radioactive_kernel_oneplus8/releases/tag/v2.2.5-MOD - the .img file is a Magisk patched custom kernel, you can also flash the twrp alpha (that seems to work in my experience, it's just slow, on OOS works fine despite warnings it doesn't). https://forum.xda-developers.com/t/recovery-11-alpha-teamwin-recovery-project-8t-kebab.4302449/ fastboot commands for the kernel: fastboot flash boot image_name.img; recovery fastboot flash recovery twrp_name.img.
I successfully updated while rooted from the prior ROM version. I'm sure it will work on many phones. Best of luck to you!!! I did find out how to install "the full ROM" unreleased on a rooted phone, there is some undocument fastboot stuff I had to figure out (temp system-cow and system_ext-cow files that use up all the space in the super partition) so I added them to my batch file. Now install for whatever device you have, and watch out for those weird temp files that aren't documented anywhere that I could find. Took literally hours to get it working, but it does now!!!
BTW if anyone knows how to resize the super partition, that would complete this project. I.e. you could flash the patched system and system_ext on an Op8T.
Your phone may have no issue or no super partition, then you don't care, it's not needed. I can't recall when dynamic (resizable) partitions came out but I think in Android 10 some devices started to use them. They are developer hell in my opinion.
Some TWRP versions allow you to just resize the partition on the fly, while on my phone, it's not an added feature yet. I'm also not sure if the resize does an auto-wipe either then you could also find yourself in trouble if you couldn't immediately get to Fastbootd. Some ROMs will boot to "Device is corrupt" if things like this change, just a warning, which I tried by switching A/B slots, but I had luckily installed TWRP on the other partition and was able to switch slots there and go back to booting.
UPDATE: I was able to eventually locate why the Super partition was getting full - there are temp files created as dynamic partitions when trying to install an OTA - I had to delete any logical partitions with the extension "-cow" which existed for system and system_ext (on the Op8T I was using), I was on slot A, so they were called system_a-cow and system_ext-cow, I deleted them like this:
fastboot delete-logical-partition system_a-cow
fastboot delete-logical-partition system_ext_a-cow
To see if you have any temp files present, you type:
fastboot getvar-all
And scroll through them and see if any of these mystery -cow files are present.
(bootloader) is-logical:system_a-cow:yes
(bootloader) is-logical:system_ext_a-cow:yes
Whew! That was a pain. But no more waiting for incremental updates to become full ROMs anymore on a rooted phone!
Oh, and I put the update for OOS here: https://forum.xda-developers.com/t/...install-from-fastbootd.4316147/#post-85441161
Hey everyone
I am working on a dual boot Ubuntu Touch, Droidian (mobian-hybris) setup without breaking either of the systems. I have figured everything out on how everything should work and modifications that need to be done to the recovery image but there is one question that i do not have an answer for but here is some information but how things work.
So right now Ubuntu Touch uses a customized version of LineageOS recovery to do OTA updates. and is when installed it replaces androids rootfs. Then we have Droidian which uses a rootfs.img file as its rootfs which is mounted at boot as a loop device. (file is placed in /data)
They use different kernels because they have different ramdisks (obviously). My plan is to write a desktop file in both OSes to create a file to let recovery know to flash the right kernel (kernels will be placed under /data aswell no space limitations). I have the recovery and desktop file code mostly ready the only remaining thing is the command to flash a kernel.img/boot.img file to the device (Redmi Note 9S)
I know that LineageOS does not have a terminal all of the flashing tasks will be done by a script which checks which kernel should be flashed.
Is there some documentation on this? Because TWRP can do the same and TWRP is just a GUI on top of the android shell with some added functionality for backups and such.
Any response is appreciated.
FakeShell said:
Hey everyone
I am working on a dual boot Ubuntu Touch, Droidian (mobian-hybris) setup without breaking either of the systems. I have figured everything out on how everything should work and modifications that need to be done to the recovery image but there is one question that i do not have an answer for but here is some information but how things work.
So right now Ubuntu Touch uses a customized version of LineageOS recovery to do OTA updates. and is when installed it replaces androids rootfs. Then we have Droidian which uses a rootfs.img file as its rootfs which is mounted at boot as a loop device. (file is placed in /data)
They use different kernels because they have different ramdisks (obviously). My plan is to write a desktop file in both OSes to create a file to let recovery know to flash the right kernel (kernels will be placed under /data aswell no space limitations). I have the recovery and desktop file code mostly ready the only remaining thing is the command to flash a kernel.img/boot.img file to the device (Redmi Note 9S)
I know that LineageOS does not have a terminal all of the flashing tasks will be done by a script which checks which kernel should be flashed.
Is there some documentation on this? Because TWRP can do the same and TWRP is just a GUI on top of the android shell with some added functionality for backups and such.
Any response is appreciated.
Click to expand...
Click to collapse
Answering my question as the answer was just too dumb but for some reason i could not figure it out.
dd can be used like a regular linux machine
dd if=/data/boot.img of=/dev/block/platform/soc/by-name/boot
Closing down
I kinda had the same issue here: https://forum.xda-developers.com/t/...wrp-openrecoveryscript.4301279/#post-85681605
I remember that I read somewhere / was told actually not to use /dev/block/platform/soc/by-name/boot (which is a symlink) but the actual device path the symlink resolves to with dd.
I'm not sure what the reasoning was though. I'd like to mention this here, maybe someone knows why.
I have been trying to root my Xperia XZs G8232. BL unlocked successfully, flashed TWRP 3.1.1 successfully, just that it wouldn't boot up. Can someone enlighten me which step I have missed out ? Managed to flash SuperSU 2.8.2 and Magisk 19 via TWRP recovery. The phone still wouldn't boot up....
Can anyone share proper comprehensive guide of rooting of G8232 ?
Usually when I offer an answer, the reply is something along the lines of "I found an answer already."
This is a quick guide in case you haven't. I suggest you have a micro-sd card inserted.
First, the stock image you are rooting is signed and verification is still active on the device. You will need to resign the boot.img. I suggest you worry about that after performing a boot into recovery to get ahold of the boot.img. Second, the TWRP you are using really isn't an ideal version. You can safely install this to the recovery parition for rooting and backup too even though it was built for the XZ (chip instruction set and partition table are near identical, it works safely with Keyaki). Go ahead and install the recovery, then once you boot into it comes the somewhat more technical approach.
You need to first mount system and the micro-sd card, by tapping Mount on the main menu and then by checking off System and Micro-SD so they can be accessed (loaded/mounted/whateveryouwannacallit). Now, go back to the main menu and tap Advanced and tap Terminal. From here you will need to copy the boot.img which can be achieved by typing:
dd if=/dev/block/by-name/boot of=sdcard1/boot.sin
You may have to search through the /dev/block directory a bit further, as I cannot recall if it is nested under platform/some number junk/etc... You can safely navigate through the directories with: cd or maybe find -name boot 2> /dev/null until you find the directory by-name that has the partitions you need and fill that path into the dd if= path I presented above. Just make sure the if (input file) is the directory you wish to copy and the of (output file) is where you want it to go.
Once you have successfully copied the boot partition (kernel) to an sd-card you can go ahead and run this tool to unsign it , from my experience you will also need to repack and sign it as AOSP with this to get the stock kernel and system running with root access available.
Both tools work similarly, read through the guides where you download each.
You will need to extract AIK and place the boot.img into the first directory that has the scripts with it. Simply type/choose ./unpackimg.sh and when that completes, choose ./repackimg.sh (depending on which OS you use the commands might be somewhat different, but the above suggestions should guide you through it). You should receive a prompt stating it was completed and packed/signed for AOSP. Copy or cut the new-Image.img out of the AIK directory back to the root directory of your sd-card.
Boot into TWRP (or maybe you attempted this with the mobile version through TWRP, idk?). Select Install, tap install .img (bottom right) and tap the new-Image.img you just created and flash it to boot.
From here you can go ahead and reboot and you should be able to access the stock system with your rooted boot.img. BTW, you don't need Magisk v19. You can install the 25.2 app and patch the new-Image through the app and then repeat the previous step above to have your kernel rooted with the latest Magisk.