Develop Bugs

[Tool] dd Flasher Minimal - Update your device without losing root access

Update: unfortunately the Marshmallow firmware for Xperia M5 enabled verified boot (dm-verity) so the phone will refuse to boot if you use dd Flasher Minimal to root. If you want root on Marshmallow firmware and also have an unlockable bootloader, I recommend flashing the stock Marshmallow firmware then using this kernel to get root access again...
This tool is a fork of the main dd Flasher made especially for Xperia M5 family, which allows updating to latest firmware version while maintaining root access, assuming your device is currently rooted...
How it works?
Sony updates are packed in .sin files, generally stored in FTF packages. Using Androxyde's FlashTool, you can get an image of the system partition (system.ext4) of the latest firmware available, which is sideloaded into your device by this tool. Next, it'll mount the update image (system.ext4) in a loop device, place SuperSU binaries and after that, stop all running processes and "flash" the modified image back into your device by using dd binary.
After using dd Flasher Minimal, all you need to do is rebooting your device into flash mode in order to flash the rest of the FTF file (excluding system partition, of course) with FlashTool. In the end, your device will be running the firmware from the FTF file you used with full root access, which makes dd Flasher Minimal extremely useful (especially to locked bootloader users) to update to the latest firmware where there's generally no root exploit available.
Requirements
• Your device must already have root access. You can downgrade to an older firmware and root it with iovySU, if needed.
• You will need Androxyde's FlashTool and an FTF file of the firmware version you want to upgrade your device to. Also, if you crossflashed your device to another firmware region/variant in order to get root (e.g. E5653 HK crossflashed with E5603 CE1 firmware or E5633 FR crossflashed with E5643 BR), it's your chance to return to your original variant/region by using a matching FTF file.
• Your device should have enough free space to store system partition image of the update temporarily (around 2.6 GB, depending of the firmware). You can store the image either on its Internal Storage or in external SD Card (if available).
• If storing the system image into SD Card, make sure your phone is connected in MTP mode (in Mass Storage mode only Internal Storage is accessible on device side and dd Flasher Minimal will fail)
• USB Debugging must be enabled on the phone (available in Settings => Developer Settings -- if you can't see it, go to Settings => About Phone and tap 7 times on Android Build).
• ADB drivers should be installed on the computer, otherwise this tool won't see it (you can install Xperia Companion to get the drivers or use any ADB installer you prefer).
• Your computer should be running Windows or Linux (you can probably use the Linux script on Mac, but that's completely untested and not guaranteed to work at all).
Instructions
I've splitted the instructions into three smaller sections. Follow all of them:
Getting system partition image
FTF files are just normal .zip files with a different extension and lots of .sin files inside, format commonly used by Sony in their firmwares for Xperia devices. We are interested in system.sin (it's the one with the partition image), to use it with dd Flasher Minimal, so:
• Open the FTF file with WinRAR or 7-Zip (or any other program compatible with .zip files);
• Extract system.sin somewhere you have easy access;
• Open FlashTool and go to Tools => SIN editor;
• A new window will open. Locate system.sin you extracted before, click in "Extract Data" and wait until FlashTool finishes extracting it;
• If everything went well, now you should have a system.ext4 file in the same place you extracted system.sin before (you can also delete system.sin -- it's not needed anymore at this step).
Using dd Flasher Minimal
Now that you got the system partition image, we can move on to dd Flasher Minimal:
• Download the attached ZIP and unzip its contents somewhere (make sure FlashTool is closed as well -- it's known to hijack ADB interface in order to provide some of its features and thus may cause issues with dd Flasher Minimal if it's running at the same time);
• Copy system.ext4 extracted previously to the root of the Internal Storage or SD Card of your phone;
• Open ddf_min.bat (or start ddf_min.sh from Terminal if you're on Linux) and select the same location where you've copied system.ext4 (Intenal Storage/SD Card) and wait while dd Flasher Minimal do its work;
• Please note that it'll take a while to finish and your device will look like it's dead or completely frozen during the process. Don't worry, it's normal;
• If everything went well, dd Flasher Minimal will notify you. Press any key and dd Flasher Minimal will reboot your phone into fastboot mode. When the LED becomes blue, disconnect the USB cable. Your phone should power off now, don't turn it on yet;
• On some cases, it may not be possible to reboot into fastboot or the phone may not automatically turn off after unplugging the USB cable, if that occurs, make sure the USB cable is disconnected and power off your phone manually by pressing the "OFF" microswitch present next to the microSD card slot. Remember, don't turn your device on yet.
Flashing the remaining FTF contents with FlashTool
At this stage, your device have the system partition with full root access of the firmware from the FTF you used but still have the kernel, baseband, etc., from the previous firmware you were running on your phone, so, trying to start your device now will probably result in a boot loop. To correct this:
• Open FlashTool again and flash the same FTF you used to extract system.ext4 through flash mode, however, make sure you exclude SYSTEM partition. If you forget to do so, you'll lose root access and you'll need to restart from the beginning.
• Make sure that you're using FlashTool 0.9.20 or newer and answer Yes when it asks if you want to use the .fsc script! Using an older version or not using the provided .fsc script will hard brick your Xperia M5 and only Service Center will be able to repair it.
• After flashing ends, disconnect the USB cable and start your phone. The first boot may take several minutes but if everything went well you should be now running the same firmware from the FTF file you used, with full root access!
Frequently Asked Questions
Q: Help! I've enabled USB Debugging on my phone but dd Flasher Minimal keeps stuck at "Waiting for device" message!
A: This means ADB isn't "seeing" your phone, either because you didn't install ADB drivers (you can use this stand-alone driver) or because you didn't authorize the connection on your phone. If dd Flasher Minimal still can't see your phone, make sure you don't have another Android device with USB Debugging enabled plugged on your computer at the same time or emulators like BlueStacks or Genymotion running.
Q: This whole thread looks familiar. Why?
A: Most of this is copy/paste from the dd Flasher thread. I made this version aimed directly at Xperia M5 because the main dd Flasher needs to take other details in consideration like devices of different architectures, different Android versions, different write protections and so on. In fact, my plans are rewriting the next version of the main dd Flasher in a more robust language than a simple Windows/UNIX script, that's also why it's pretty much abandoned and why I haven't updated the main tool besides the current beta release yet.
Q: Why should I do this complicated procedure to update my phone instead of using KingRoot which is a one-click tool?
A: Because there's no guarantees that KingRoot will work on later firmwares. With this tool, if you currently have root access or an older firmware version which is exploitable, you can update to any new firmware version*, even if there's no exploit available. Also, this tool uses SuperSU instead of the dubious root managing app with bloat stuff built-in that KingRoot provides.
* as long as the newer firmwares don't include protections at kernel level, like dm-verity. On those cases you'll need an unlocked bootloader
Q: Is there any difference between dd Flasher Minimal and PRFCreator?
A: The concept behind both tools are exactly the same (modify the system partition image in order to include SuperSU on it). The main difference is that PRFCreator produces flashable ZIPs to be used in custom recovery and also has more features, while dd Flasher Minimal do the same but through ADB brigde, which means it can also work on devices without custom recovery available.
Q: Can I use dd Flasher Minimal with <insert device here>?
A: You can try, but there's no guarantees. Also, the target firmware should be an ARM64 version of Lollipop or newer, otherwise don't even bother trying as it'll probably result in a bootloop.
Credits
I'm the author of this script, which is based on dd Flasher (which I'm the author too). This tool uses some pieces of code written originally by @zxz0O0 and @Chainfire, so, credits (and thanks) to them.

Nice work

Thanks for you hard work, look forward to trying this soon.

Thank you very much for this amazing work. I tried it yesterday and worked perfect!!!

I tried and it works good! But I have one question: will it be possible update to android 6 by using this tool?

As long as the newer firmwares don't include protections at kernel level, like dm-verity, yes, you can use this tool with any future upate...

got my phone back from Sony, they did not change anything, even though it appears the front camera has a fixed focus. When you are at that distance the picture is razor sharp, else it is poor.
So anyway, given I have to live with it, I thought I would finally get around to rooting and getting a more up-to-date firmware than available in the UK. So used this and now on .55 on generic Spain.

Perfect!! Only we need recovery

Some good (and bad) news: first the good news, Sony started rolling out 30.2.A.0.100 firmware for single SIM variants, the long-awaited Marshmallow update, and it should come soon to dual SIM variants too (probably under 30.2.B.0.100 if Sony keeps the same naming scheme of previous updates). And now the bad news, from a preliminary look I did in the boot image of the update, it now have dm-verity enabled on the kernel, and so, by using dd Flasher Minimal to update to a Marshmallow-based firmware while maintaining root access, the phone will refuse to boot unless you unlock the boot loader and flash a modified kernel with dm-verity disabled...

mbc07 said:
Some good (and bad) news: first the good news, Sony started rolling out 30.2.A.0.100 firmware for single SIM variants, the long-awaited Marshmallow update, and it should come soon to dual SIM variants too (probably under 30.2.B.0.100 if Sony keeps the same naming scheme of previous updates). And now the bad news, from a preliminary look I did in the boot image of the update, it now have dm-verity enabled on the kernel, and so, by using dd Flasher Minimal to update to a Marshmallow-based firmware while maintaining root access, the phone will refuse to boot unless you unlock the boot loader and flash a modified kernel with dm-verity disabled...
Click to expand...
Click to collapse
That really is bad news that dm-verity is enabled on the kernel. Have you actually tested it yet? I don't suppose there's a chance that Sony complies with Google's requirement that the user must be notified of verification failure and given the option of continuing to boot despite the failure?

I haven't actually flashed the update because it's not available yet for my variant (E5643) and at the moment I want to avoid cross flashing because it's my main phone (and I had issues with cross flashing it on the past).
What I did was downloading the update for E5603 and then taking a look on the RAM Disk of the kernel image; the verity keystore is present and it's also present in the fstab, so, dm-verity is definitely enabled. Also, from the dm-verity issues in recent Xperia flagships regarding root (Z3+/Z4, Z5, Z5c, Z5p) I really don't believe Sony just set dm-verity in "warning" mode rather than enforcing it, making the phone refuse to boot if the system partition was tampered...
In other words, permanently locked bootloader owners are currently screwed if they want root in Marshmallow update for Xperia M5 series

mbc07 said:
I haven't actually flashed the update because it's not available yet for my variant (E5643) and at the moment I want to avoid cross flashing because it's my main phone (and I had issues with cross flashing it on the past).
What I did was downloading the update for E5603 and then taking a look on the RAM Disk of the kernel image; the verity keystore is present and it's also present in the fstab, so, dm-verity is definitely enabled. Also, from the dm-verity issues in recent Xperia flagships regarding root (Z3+/Z4, Z5, Z5c, Z5p) I really don't believe Sony just set dm-verity in "warning" mode rather than enforcing it, making the phone refuse to boot if the system partition was tampered...
In other words, permanently locked bootloader owners are currently screwed if they want root in Marshmallow update for Xperia M5 series
Click to expand...
Click to collapse
Do you have UB your M5?

Rootability news for marshmallow?

Silly idea : just disable the dm-verity?
Else have to unlock bootloader... Is that even work?

knight84 said:
Silly idea : just disable the dm-verity?
Click to expand...
Click to collapse
You need an unlocked bootloader to do that.

Just curiosity, i know that it will not work but i don't know why...
What prevent unzip ftf and to change boot.img with one dm_verity off ?

Nothing. But locked bootloader devices only accepts kernels signed by Sony, modify a single byte on the boot image and the signature is not valid anymore. In other words, a bootloader locked phone would refuse to boot with a modified boot image.

mbc07 said:
Nothing. But locked bootloader devices only accepts kernels signed by Sony, modify a single byte on the boot image and the signature is not valid anymore. In other words, a bootloader locked phone would refuse to boot with a modified boot image.
Click to expand...
Click to collapse
Clear! I read something now in Wikipedia.

I have an idea. But I am not an expert, so I am not sure about this.
I think, we can downgrade the firmware with Flash Tools. Then, we can gain root access with kingroot. We can get a backup of TA partition and drm keys and then we will unlock the bootloader, change the dm-verity thing and use this dd flasher to keep root access with mm update. So If we have root again, we can lock the bootloader and restore the drm keys.
Am I correct about this idea. Can it be successful?

As soon as you restore your TA backup (thus relocking the bootloader) the phone would refuse to boot the modified image. Like I said before, only signed boot images can be loaded with a locked bootloader (modify the image to disable dm-verity => its signature is not valid anymore). Also, even if it worked, it would be of no use for users with permanently locked bootloader (e.g. devices bought through carriers)...

Unbrick device: missing files?

Hi
Weeks ago I started a thread at a more general level, and got no answer, so I presume my question/request should have been more device-focused.
My problem: unlock pattern is not accepted, at boot stage, after having fastboot flash_all_except_storage.sh, so it cannot decrypt userdata, therefore it doesn't boot. Not to say I cannot access my data.
Device: Xiaomi MiA2 Lite. Bootloader unlocked. Magisk rooted
What I did:
- "Justification": I just came from a trip with no connectivity, too tired (without giving a second thought), resolved several family tech issues, and as I've had not problem upgrading the same device from a relative with the same configuration, I made no backup of mine.
- I was trying to upgrade from 10.0.10.0 to 10 10.0.12.0, but OTA was sistematically failing, despite I'd followed the same recommended procedure than in my relatives':
the Magisk uninstall - OTA_update - Magisk install_on_empty_slot procedure.
- I first tried flashing stock boot, in order to override the OTA error. What I got is the system destroy message!
- At that moment I only new about the fastboot file from xiaomi, that only shows 10.0.9.0.
Downloaded it, and ran (downgraded) the flash_all_except_storage.sh of this version.
It seemed to work well until I got stuck in "incorrect pattern" (previous to the full boot)
What I tried:
- I repeated the flashing, just in case, with no success.
- Also tried to access userdata with twrp-3.3.0-0 and 3.3.1-dees_troy. No success.
- Then, too late (don't know why this xiaomi doesn't upload the latest), I found at xda-dev newer fastboots images (10.0.10.0 and 10.0.12.0). Tried to flash_all_except_storage, but not changes at all.
- I have no doubt on my pattern
- Important: I got the warning of 9 attempts left (hope that the ones within TWRP do not count).
So my "request":
- The most important: any help on how could I regain access to my userdata partition?
Let me add that I have a previous unencrypted TWRP userdata backup (only that partition), from a few months before. It contains a /persist/data directory
Could I get any file from it that is part of the encryption process? (I can see, for instance, keymaster64)
In this case, what should I do?
- and, secondly, (I guess some of you have a good level, obviously not me): what could have broken the access to the userdata? In my previous mobiles, flashing boot, system or vendor caused not problems to me. I ask it because it's not my first problem rooting this 2 slot device.
Thanks in advance

ZTE Axon M research

I decided to do some digging since I just purchased one of these devices.
fastboot binary is emmc_appsboot.mbn from an update zip.
fastboot oem commands in the CN ROM: unlock, unlock-go, lock, device-info, enable-charger-screen, disable-charger-screen, off-mode-charge, select-display-panel, run-tests
fastboot oem commands in the US ROM: unlock, unlock-go, lock, device-info. US rom is older, which is probably why some commands are missing.
You may be able to find more using a disassembler or with abootool https://github.com/alephsecurity/abootool
First step to getting more research done would probably be to get EDL working for the US variant. Or someone seeing what "unlock-go" does (probably nothing).
After getting EDL working, getting Firehorse functional would be beneficial. However I don't know how the rawprogram.xml is generated. I believe it has to be generated using the partition table somehow, but I do not know how to find the partition table.
I don't know how the bootloader images are signed, but my guess is that flashing CN over US will just leave your phone permanently bricked if they are signed differently. Downgrading the bootloader will also not work if qfuses are implemented correctly (although sometimes they aren't). Checking 16C7 in emmc_appsboot.mbn, US bootloader has the same string across versions and CN has a different one so I'm guessing they are in fact signed differently.

Hello! I have US variant and EDL is working, you can type in adb: reboot edl

So I didn't find out "adb reboot fastboot" doesn't work until now.
Since EDL can read/write partitions, it might be possible to
1. Unlock the bootloader by dumping devinfo, writing unlock bit, then writing it back to the device
2. Upload a su binary to the system partition after the bootloader has been unlocked. (It's not that simple these days, unfortunately)
Additionally there is a flag in build.prop that seems to enable download mode but in reality it does nothing at all. the prop is "persist.sys.dlctrl" with setting of 1. But maybe it's for development devices only.
Unsurprisingly, Factory Test Mode does not give you a root shell. It's the same privilege level as normal boot.
Using the firehose elf from the TWRP thread, I was able to dump the devinfo partition, but the partition is all zeroes. I'm not sure what's missing.

Recently discovered zero-day exploit in Android could possibly help us with an alternative way to achieve root? Anyone with the skills to use this knowledge to get us "no bootloader" owners any closer to our goal?
https://www.helpnetsecurity.com/2019/10/17/android-root-cve-2019-2215/

ZeroTheSavior said:
So I didn't find out "adb reboot fastboot" doesn't work until now.
Since EDL can read/write partitions, it might be possible to
1. Unlock the bootloader by dumping devinfo, writing unlock bit, then writing it back to the device
2. Upload a su binary to the system partition after the bootloader has been unlocked. (It's not that simple these days, unfortunately)
Additionally there is a flag in build.prop that seems to enable download mode but in reality it does nothing at all. the prop is "persist.sys.dlctrl" with setting of 1. But maybe it's for development devices only.
Unsurprisingly, Factory Test Mode does not give you a root shell. It's the same privilege level as normal boot.
Using the firehose elf from the TWRP thread, I was able to dump the devinfo partition, but the partition is all zeroes. I'm not sure what's missing.
Click to expand...
Click to collapse
It doesn't use devinfo to store bootloader bit it's stored in the rpm partition and cannot be modified. As you can see the bootloader does not have to be unlocked to boot non zte signed images, but if it could be unlocked we would be able to run newer devices firmware. Zte played it smart and signed every variant different so aboot from a another variant will brick you.
Sent from my ZTE A2020U Pro using Tapatalk

I see.
Unfortunately I think most of this is beyond my ability and knowledge, this is my first time trying to "exploit" a device (if you can honestly call it that, I don't even know what I'm doing half the time).
But since bootloader does not need to be unlocked to run unsigned images, is it possible to run a custom kernel?

ZeroTheSavior said:
I see.
Unfortunately I think most of this is beyond my ability and knowledge, this is my first time trying to "exploit" a device (if you can honestly call it that, I don't even know what I'm doing half the time).
But since bootloader does not need to be unlocked to run unsigned images, is it possible to run a custom kernel?
Click to expand...
Click to collapse
Yes, I ported Lineage to the device. But trying to modify stock and change the kernel or flash magisk I had no luck. Not sure what the f**k ,is all I can say is, stopping it. I'm doing a lot of security studying and programming I'm sure I'll figure it out sooner or later my goal is to get a custom lk running with fastboot and run oem unlock then switch to CN updated firmware.
Sent from my ZTE A2020U Pro using Tapatalk

Brief Guide of Emergent Non-Booting Troubleshooting Road Map

This thread is for those who have troubles but have no idea what to try. If you're new in playing with Android Roms, you'd better read this. No exact operation would be introduced here, because only directions are provided and further work should be searched by yourself as I'm not Mr. Knowall.
Here, trouble means problems except the cases you can boot to system (they're issues) or hardware damage. Make sure your phone has been charged or any battery related problem is considered to hardware side.
Besides, if you are holding a T-Mobile H932, you should be extremely careful with anything below, because any mistake may push your phone into hell. Especially, there is currently no usable 9008 firehose file for it even you ask a professional repairman.
First, backup everything important regularly to a secure place instead of phone storage, especially private files and EFS partition which contains IMEI, MEID, etc. If possible, write down the IMEI, MEID, S/N, WiFi MAC address, Bluetooth MAC address of your phone for potential future need of restoration.
Then I assume you have unlocked bootloader. If not, go to (WTF...!) LG V30/V30+/V30S Bootloader Unlock & Root Method (With Clear Instructions) when you can still boot to system. If you cannot boot to system already with bootloader locked and cannot perform unlocking introduced there, maybe you can jump to the section of download mode or 9008 mode and give it a trial, BUT I CANNOT ensure your phone would return normal.
There are four important modes related to our topic: Recovery, Fastboot, Download and Qualcomm 9008 (Preload for MTK). Risky and inconvenience is increasing in order. Read this: Collection of mode entries with hardware key combination (maybe for most LG models) to learn how to enter them without booting to system.
Recovery is stored in the partition with the same name. You need custom builds like TWRP or OrangeFOX to flash in, or you only have a stock one with the single function of master reset. For most cases, if you can enter all the four modes, use this first. Make a backup before flashing anything with Rec, and if the thing you flashed in leads to bootloop or anything abnormal, you can easily get the original partitions back. But if you performed incorrect operations and such a restoration doesn't work, you should consider wipe cache, dalvik cache and data (backup if not yet). If not work still, try to flash in fresh rom packages. If not work again, go to the section of download mode.
Fastboot is mainly used to flash in some partitions like recovery, boot and unlock. There is some limitations that many partitions cannot be flashed in here. If you have never used this mode before, you may need to manually update the corresponding driver on your computer (caution that if you're facing the problem of "waiting for device", it's usually driver issue). Some firmwares miss this function, so it's often recommended to switch firmware for custom rec installing.
Download mode is mostly used to deal with kdz files. You need LG phone driver and dev patched LGUP (or some other tools with similar functions). If LGUP cannot recognize a phone already in download mode, it's usually the problem of driver or LGUP patcher. Be careful when using LGUP. If any interrupt during the process of downloading firmware, you need go to 9008 mode. Do not use chiperase unless you know what to do after that. Here again dump can backup partitions. Refurbish and partition dl are most widely used. This mode can solve most troubles unless you cannot enter here. If that really happens, move on to the ultimate mode, 9008.
9008 is the last chance before sending your phone to repair. Only recommend to recover other modes, but if you're familiar with it, you can do almost everything in this mode as in other modes. Again driver and tool are needed. Recommend QPST since it's made by Qualcomm, but it's not released publicly. Search and download from some reliable sources. The driver needed should be contained in the package with the tool. Somebody may tell to use QFIL, but if you have not installed it please install QPST and use the built-in QFIL instead of a standalone one, or problems would probably find you. To use this mode, you need the corresponding firehose file. See this: LG V30 Unbrick guide (Qualcomm EDL 9008 Mode, Hardbirck, with no download mode) for file download (none for H932 yet). You do not need XML file if the partition table is not broken. To verify it, open QFIL built in QPST, set configuration to UFS mode, open Tools -> Partition Manage and see if it's correctly displayed. If yes, only flash in partitions related to bootloader and recovery to get other modes back. The partitions can be found in twrp flashable stock firmware or early backups, or you can extract from kdz using LG firmware extractor. Only the worst damage to storage needs full download with XML generated from kdz using extracting tools.
If all modes above cannot save your phone, you may consider hardware damage and that needs professional knowledge, so our forum cannot help.
Good luck.

[INFO] Understanding and troubleshooting bootloops

Since this device tends to bootloop easily and because I've seen lots of questions about it and information is spread across many threads and posts, I'm writing this guide to help you guys troubleshoot bootloops before asking generic "help me" questions.
I) Terminology
1) BROM - A readonly memory on the SoC that runs right when the device boots. Loads the preloader. SPFT talks to it after authentication.
2) Preloader - MTK firmware that resides on flash. It is loaded on the chip's SRAM. It is responsible for initializing DRAM, and is one way of authenticating SPFT (the other is authenticating directly with the BROM, but I believe the way thi is done is known only to MTK and OEM engineers, and not even to authorized service centers). It also loads LK. Its source is distributed to OEMs, but is otherwise unavailable. Plenty of leaks for other devices can be found on the internet (some from the OEMs themselves).
3) LK - Little Kernel. This seems to be the most common platform for Android bootloaders. Mediatek has its own proprietary branch. Same source status as preloader. As an android bootloader, it is responsible for loading recovery or usual kernel image, as well as fastboot flashing.
4) Kernel - If you're on these forums, you should know what it is. You can find it in boot.img
5) DTBO - The device tree for the linux kernel. It specifies which hardware is available on the device. On usual (x86) PC platforms, the BIOS and Option ROMs store device information and offer it to the kernel (through UEFI/ACPI). As arm boards do not have such those, the linux kernel uses dtbos which play the same role.
II) Boot process
1) The ARM cores on the SoC start and jump to the address of the BROM.
2) (I'm not very sure of this, there's too little information) BROM puts the cores into a known state, should listen on the in-build UART for some time (half a decade ago, some leaks said something about 150ms), and if it doesn't receive anything, it loads the preloader.
3) The preloader initializes basic stuff like DRAM (phone's ram), watchdog, USB, etc. If the phone is connected to SPFT, it talks to it and authenticates it (the (in)famous "Account not authorized for this operation" should come from a check in here). I believe it also turns on the charging light. On a normal boot, it further loads lk. I belive that it also shows the chinese menu on pressing the Vol- button on factory preloader, but I did not check this.
4) LK (the one that comes with factory preloader) checks if Vol+ is pressed, and displays the bootloader menu (the one with the 4 english entries). When selecting recovery, it loads recovery. If normal boot is selected, it loads boot.img and dtbo.img and I believe it makes some checks on them (possibly of signatures, see the kernel trees). It then loads the proper image from the logo.bin partition and displays it (note: I've checked Logo Builder; rebuilding the logo.bin partition with it makes LK reboot before showing any image - this is done after the boot menu); examples are the one where it shows "Unlocked" or the Fastboot background. It also checks vbmeta for verified boot. Then it boots the selected entry.
5) The linux kernel does some hardware init, mounts system and starts Android's init.
6) Android does its usual init, mounting vendor, loading modules and firmware, turning on stuff like wifi, bluetooth, gnss, etc.
III) Tips for diagnosing bootloops
1) When bootlooping, plug your phone in a computer and check for the following (this is from my experience):
a) Charging light turning on
b) Vol+ menu showing up
c) Redmi logo showing up
d) Charging light turning off
e) Boot animation showing up
2) Things to do based on where things didn't work as in (1):
If (a) doesn't turn on, you're most likely in deep ****, and I'm not sure who can help you. Edit: Try pressing Vol+ and see if a device with VIDID 0x0e8d:0x0003 shows up. That would be the BROM. If it shows up, try using SPFT (most likely won't work, but you have nothing to lose anyway).
If (b), try SPFT. If it shows "Account not authorized", you have the stock preloader. There's a couple threads here with some methods that may or may not work. Otherwise, ATM you'll quite literally have to pay for your mistake. Grab your wallet and your Windows VM. You'll need them. Be prepared to search for the least shady guy that can help you and have your usb passthrough (on the upstream hub) ready.
If (c) - i.e. you have the menu but no logo, this means you've got LK. Since the Redmi logo doesn't show up, it means something is not quite how lk likes it (and lk is very picky on this phone). If you can, you'll probably want to use fastboot and flash a known good image for whatever you changed. If not, use SPFT.
If (d) - i.e. you have the logo but the charging light doesn't turn off, this means LK didn't boot the linux kernel. Flash a different (working) kernel.
If (e) - the charging light turns off, but you have no boot animation, this means either the kernel panics before it can start Android or that Android failed to boot properly.
From here on, you can use /sys/fs/pstore/console-ramoops to diagnose the problem.
If you do get a boot animation or are close to it, you might also want to try using adb logcat (especially if you've turned on adb debugging, and your ROM can do it on boot).
3) /sys/fs/pstore/console-ramoops
You can access it on a normal boot on some roms (or mount it manually if you've got root), or it's usually mounted automatically on TWRP. This is the kernel log from the last boot and is theoretically stored in RAM (I have reasons to doubt that). Basically, it works like dmesg, but for the last boot.
While it is polluted by zealous MTK debugging info, scrolling through it can often show where the problem is. If you can figure it out yourself, great. If not, post it here, and I (or somebody else) might try to figure out what went wrong and put it on a list of known bootloop reasons and fixes below.
4) Recommendations on posting about bootloop problems:
I think it would help a lot specifying which step from above fails. Also, if the charging light turns off, please, please provide /sys/fs/pstore/console-ramoops. You can easily get it with adb pull from TWRP and it helps *a lot* in figuring out what went wrong.
Hope this info will help you guys getting your devices working again faster (and provide more accurate info when asking for help).
P.S.: Another reference on MTK boot, also around 5 years old.

Reserved for List of bootloop problems:

Reserved

i have:
dm-verity error
Android system on your device is corrupted.
Device will boot in 5s
Click to expand...
Click to collapse
can't boot to my mobile in past week
just i can see my device with "fastboot devices" but not found with adb devices
and in device manager "Android ADB Interface" it's not recognize ( yellow question marks).
also have "adb server version (41) doesn't match this client (39); killing"

hello..
So... /sys/fs/pstore/dmesg-ramoops .. is not there .... /pstore do not exist :-\
and /proc/last_kmsg.. neither :-(
i have.. lineage-14.1-20190213-nightly-asanti-signed install it....
He will be generating them elsewhere???

OP, please add the infamous soft brick symptoms in detail, this maybe help someone in the future.
It shows redmi logo, it can enter vol + menu with some messages (I forgot the message), and it can enter vol - (bootloader), and it will ask for authorization when hooked to SPFT. And also link to that telegram post for work around.
And also, this is crucial info I found. Anything prior global 12.0.7 can be dirty flashed to anything prior that (even A10 to A9). 12.0.7 onward, 12.0.7 is the lowest you can get for dirty flash. I don't know for clean flash. Maybe work, maybe not.
fla5 said:
i have:
can't boot to my mobile in past week
just i can see my device with "fastboot devices" but not found with adb devices
and in device manager "Android ADB Interface" it's not recognize ( yellow question marks).
also have "adb server version (41) doesn't match this client (39); killing"
Click to expand...
Click to collapse
What have you done prior brick? Do you do something like flashing global rom in a locked bootloader chinese flavor phone? If yes, do the unbrick with SPFT. If not, and you have unlocked your bootloader and access to fastboot, I think dirty flash will do the trick.

Sorry for being a lil' off-topic but I would love to ask how to prevent a bootloop after flashing back to stock recovery or/and boot. It happened twice - I used magisk+twrp, an update rolled out, I flashed the stock recovery for my official from (extracted from the official package) and ended up with a loop, did the mi authorized acc unbrick and it worked perfectly, now with the 12.5 rolling out I am preety sure i'll end with a loop again when I'll flash the stock boot or/and recovery.

luq90 said:
Sorry for being a lil' off-topic but I would love to ask how to prevent a bootloop after flashing back to stock recovery or/and boot. It happened twice - I used magisk+twrp, an update rolled out, I flashed the stock recovery for my official from (extracted from the official package) and ended up with a loop, did the mi authorized acc unbrick and it worked perfectly, now with the 12.5 rolling out I am preety sure i'll end with a loop again when I'll flash the stock boot or/and recovery.
Click to expand...
Click to collapse
you need to restore stock recovery and boot. and you can't install the update via updater nor twrp. install full rom via fastboot update or via mi flash (dirty flash is ok). but for 12.5 update, do it in twrp
from 12.0.7 onwards, downgrade without erasing data will lead to bootloop (just flash the correct build for remedy)

Thank you for your answer kekesed97.
Sorry, I made a small mistake. By saying that I used twrp means I had it installed not used for the flash. When the update came out, I thought that installing via ADB the stock recovery and boot will let me update the device like a completly unmodded model. Tried this Twice and always ended with a loop. Afterwards the only solution was updating via flashtools (it's bricked anyway so let's update manually hehe).