Database Info

[INFO] BOOT PROCESS: ANDROID vs. LINUX

NOTE:
I'm not a developer or Android expert. All information provided here is copied from different internet sources and is to the best of my knowledge. I'll not be responsible for any harm to you or your device resulting from this.
1. PC BOOT PROCESS
Before diving into Android boot process, let's have a look at Linux PC first.
Power Button Pressed
Power On Self Test (POST); identify the devices present and to report any problems
BIOS / UEFI
Necessary hardware initialization (keyboard, disk etc.)
Disk (MBR)
DOS Compatibility Region code (optional)
Bootloader
Active/boot partition (Boot sector)
Kernel
Initrd / initramfs (init)
Services/daemons/processes
BIOS / UEFI is the first software code that is hard-coded on board and runs after we press power button. BIOS runs in real (16 bit) mode of processor, thus it can not address more than 2^20 bytes of RAM i.e. routines can't access more than 1 MiB of RAM, which is a strict limitation and a major inconvenience.
When creating partitions, MBR is saved in LBA0, GPT header in LBA1 and primary GPT in LBA2-33, LBA34 (35th) is the first usable sector. Backup or secondary GPT is saved in last 33 LBAs, last usable sector by OS is ( Total LBAs - 33 ). Partitioning software aligns GPT partitions at larger boundaries, e.g. at LBAs that are multiple of 2,048 to align to 1,048,576 bytes (512 bytes * 2048 = 1 MiB) boundaries. So first sector of first partition is LBA 2048 and so on.
When a system boots, driver of a filesystem is to be loaded in RAM in order to use that filesystem, but driver is itself a file, inside some filesystem. It's like a chicken and egg scenario. So the solution is to always load (as a BIOS/UEFI standard) the first sector on the bootable storage (0/0/1 C/H/S in older schemes and LBA0 in newer), which is (legacy or protective) MBR. This communication between BIOS/UEFI and storage media is through commands which are specific to host controller e.g. ATA commands for devices with SATA/AHCI interface on PC.
Master Boot Record (MBR)
1st 512 bytes (1 sector) at the start of 1st valid disk
Bootstrap code (446 bytes) + Partition Table (64 bytes)
Executable code: Bootloader 1st stage scans partition table and finds 1st sector of active partition (or may point towards intermediate stage)
Partition table provides information about active/bootable partition (and all others as well)
Small size of 64 bytes limits the number of maximum (primary) partitions to 4
Since bootloader unable to understand filesystem (inodes etc.) yet, so MBR is itself executable
Last 2 bytes are boot signatures i.e. to find immediately if disk/drive is bootable or not and hence switch to the next
DOS Compatibility Region
This stage is specific to legacy GRUB, GRUB 2 (default bootloader on most of modern Linux ditros) splits this stage to stage 2 and 3
31.5 KiB / 63 sectors next to MBR, contains filesystem utilities
Still loaded by BIOS routines (or bootloader may use it's own drivers)
Required by certain hardware, or if "/boot" partition (sector containing stage 2) is above 1024 cylinder heads of disk, or if using LBA mode
Volume Boot Record (VBR) / Partition Boot Record (PBR)
Sector no. 63 (64th sector) and above may contain Volume Boot Record or Partition BR, very similar to MBR
Also called Volume Boor Sector, it may be the first boot sector on any partition
NTFS saves VBR as metadata file name $Boot at first clusters, which also contains cluster number of file $MFT. $MFT describes all files on the volume; file names, timestamps, stream names, lists of cluster numbers where data streams reside, indexes, security identifiers (SID's), and file attributes like "read only", "compressed", "encrypted", etc.
If disk isn't partitioned, it's the first boot sector of disk
Boot Partition (if exists)
In MBR scheme, a partition can be marked bootable / active using a flag, usually the first partition of disk
Windows stage 1 bootloader reads and loads only the "Active Partition" from MBR Partition Table
Bootsector or VBR/PBR is read by stage 1 or 1.5 (2 or 3 on GRUB2) bootloader which loads stage 2 (4 on GRUB2) or actual bootloader
MBR / VBR Contains:
Jump instruction (first 3 bytes) i.e. "goto boot code" command
Filesystem header
Executable boot code, usually contains jump instruction for next adjacent sector(s) containing stage 2 bootloader
End of sector (similar to boot signature)
Stage 1 or 1.5 (or 3 on GRUB2) bootloader reads the filesystem table (like MFT / FAT) on partition and loads actual bootloader as a regular file
Bootloader (Actual)
Loaded by previous bootloader from the filesystem of same partition
Loads all necessary filesystem drivers (if any further required)
Configuration is read from database e.g. /boot/grub/ on Linux (GRUB) and <"System Reserved" Partition>/Boot/BCD on Windows (BOOTMGR)
Windows:
BCD is binary file, can be read and modified by commandline tool bcdedit.exe or GUI tool EasyBCD
NTLDR on XP simply used C:\ as active partition reading C:\Boot.ini
Linux:
GRUB makes use of modules to offer extra functionality for complex boot processes
It can show a boot menu to user if needed or configured e.g. for multi-booting or in safe/recovery mode or boot from USB/Network etc.
Locates and loads the kernel of desired OS and ramdisk in RAM
If GRUB is unable to handle the kernel of an OS like Windows, it can be configured for CHAINLOADING i.e. read and execute bootsector of the partition containing Windows bootloader
'os-prober' helps 'grub-install' and 'grub-update' finding Windows boot partition (System Reserved) by reading bootloader configuration in that partition
Kernel
1st MB of kernel from same partition (/boot) loaded in RAM by bootlader in read mode, then switch to protected mode (32-bit) and move 1MB ahead clearing 1st MB
Then swith back to real mode and do same with initrd (if it's separate from kernel)
Kernel contain ramfs drivers to read rootfs from initrd and mount it
Initramfs
Contains minimal filesystem and modules (required drivers which aren't carried by kernel) to access real rootfs (hard driver, NFS etc.)
udev or specific scripts load required modules
<ramdisk>/init is usually a script which loads necessary drivers and mounts real rootfs
finally init switch_root's to real rootfs and executes <real rootfs>/sbin/init; sysV (traditional), upstart (Ubuntu's initiative) or systemD (the latest widely accepted)
init > getty (on virtual terminals) > login (program) > motd > login shell > bashrc / bash_profile​Read more about LINUX CONSOLE & VIRTUAL TERMINALS
UEFI
UEFI can understand filesystem contrary to BIOS, hence no limitation of MBR code (446 bytes)
Needs an EFI System Partition (ESP), preferrably of minimum 550MB
ESP partition is formatted as FAT32 but can understand other filesystems such as FAT12 (floppy), FAT16, ISO9660 (CD/DVD), UDF etc.
EFI firmware reads directly <ESP_Partition>/EFI/<vendor>/<boot_programs> as configured in boot manager (which disk, which partition, which program)
Boot programs make use of EFI firmware or EFI shell or GUI Boot Manager to load kernel
If boot program is just the disk, (no partition and no program configured), then fallback program <disk>/<ESP partition>/BOOT/BOOTX64.EFI is executed
Secure boot feature verifies signature of boot program before loading
Multi-booting is easy, just read different entry from ESP partition unlike relying on single bootloader to chain load all available OS's
EFISTUB feature of Linux kernel allows booting kernel directly as a boot_program
UEFI works better with GPT than MBR
Must read:
ANDROID PARTITIONS & FILESYSTEMS
2. ANDROID BOOT SEQUENCE
There might be a single or multiple bootloaders (to give directions how to boot). For a typical android device (most common Qualcomm SoC / ARM processor), boot sequence is as follows:
BootROM (like BIOS on PC). It's integrated with SoC.
Processors, bootloaders
POST
SBL
Parallel loading related stuff from different partitions.
Application BootLoader (aboot)
Primary Boot Mode (if no Kernel detected or if bootloader/download mode key combination applied)
Bootloader/Download Mode
Secondary boot
Kernel (hardware detection and populating /sys, /dev/ and /proc directories as the processes start) and initramfs (creating rootfs and other pseudo filesystems on rootfs)
Init (first process with PID "1". It initiates further loading of processes and daemons)
System / OS (ROM)
Recovery (if recovery mode key combination applied. It's a kernel with UI to perform basic troubleshooting operations)
3. BOOTLOADERS
Bootloader(s) facilitate the the initial starting up of device by taking control from SoC, performing necessary checks, loading required components and then hand over the charge of booting to kernel. RAM is detected at first stage to start loading configuration of other hardware (like keypad, display etc.) in it.
There exist(ed) multiple bootloaders which are executed by different processors, on different devices with different (partition) names like RPM (PBL), DBL (Device Boot Loader; CFG_DATA or sbl1), SBL2, SBL3 (QCSBL) and OSBL (Operating System Boot Loader) etc.
In a nutshell, on modern ARM devices (Qualcomm SoC):
BootROM / iROM and PBL
iROM run by CPU0 on power button press, loaded in iRAM (before RAM is initialized)
It may set up RAM and execute PBL in RAM or leave this for SBL. iROM/PBL is hard-coded on SoC, written during CPU production process and it's closed source.
On devices (such as open boards or some tablets) which support booting from multiple sources like eMMC/sdcard/USB/UART/Network like a PC BIOS, there is an extra stage between iROM and PBL:
IBL (Initial BL)
It's also loaded in iRAM. Depending on CPU pin settings (hidden and soldered or exposed for manual switching) informed by iROM, IBL passes boot mode selection to PBL and optionally checks PBL integrity if itself e-signed by iROM.
SBL or XBL (Preloader)
IBL calls SBL from eMMC/SDCard which supports LCD output. SBL initializes the DDR RAM, loads the trusted firmware (TZ) and the RPM firmware if not loaded by BootROM. SBL calls the final bootloader after self testing the device.
Uboot is open-source secondary bootloader for embedded devices. However sources of SBL can also be obtained from Qualcomm.
ABOOT (APPSBL; predecessor of Little Kernel)
ABOOT loads Partition Table, kernel, splash screen (logo) and modem. It's also responsible for charging mode and fastboot mode. Memory addresses in RAM for boot/recovery partitions are hard-coded in aboot.
Other examples of final (i.e. just before kernel) bootloaders are uboot (traditional Linux bootloader for embedded devices) or manufacturers' developed BL's like hboot (used by HTC) and redboot etc.
Manufacturers put their limitations (say of network carrier i.e. SIM lock and others) at this stage. USB protocol isn't enough and communication with bootloader to hack such restrictions require special devices (called Flashing Box or Service Box in common language), even sometimes a protocol like JTAG i.e. talk directly to microprocessor.
As a norm, all of these stage-1,2,3... bootloaders are simply called BOOTLOADER. While on some devices there is no bootloader partition at all and bootloader(s) resides on SoC.
Coming back to the booting process, after initializing boot process, bootloader (if it's locked) checks the integrity of boot.img (normal boot) or recovery.img (recovery boot), loads them in RAM and transfers control to kernel offering it with "phys_initrd_start" address of compressed (cpio, gzipped) initramfs.
4. KERNEL & INITRAMFS
Once the kernel is loaded and extracted in RAM by bootloader along with parameters, kernel starts executing. Kernel is in fact a self-contained (static) executable binary, made up of many object files (.o) linked together at compile time. Once the architecture and CPU are identified, architecture-dependent code is executed as per parameters passed from bootloader. Then arch-independent stage is executed which includes setting up drivers (display, touch etc.), filesystems like rootfs, tmpfs, proc, ext4 etc. and initializing console as well (if configured). Here the kernel-space ends and user-space begins (what they call it).
Kernel extracts compressed initramfs in rootfs (which itself is ramfs or tmpfs) and executes /init binary which subsequently reads its configuration files /init.rc and other /*.rc files written in Android specific init language. With the help of kernel, init mounts pseudo filesystems /sys and /proc and populates /dev directory containing device node files. Then it mounts /system and all other partitions including /data (also decrypts it if encrypted) and sets (SELinux security) policies, system properties and environment variables (PATH, EXTERNAL_STORAGE etc.). Additionally init also look after any hardware changes (ueventd) and started services changes (watchdog) occurring dynamically.
Finally init starts the runtime located on the system partition. One of the major last processes started by init is Zygote (Java virtual machine) which compiles apps to run for specific architecture (mostly arm / arm64).
DEVICE TREE BLOB
Device Tree Blob (DTB) - created by DT Compiler (DTC) from DT Source (DTS) text - is a mapping of hardware components on a board/SoC and usually a part of kernel source.
PC hardware usually support hardware enumeration through ACPI i.e. kernel may enquire (probe) the buses - PCI (internal devices), USB (external devices), SCSI (storage devices), HDMI/DVI/VGA (display devices) etc. - which device is connected to it.
Buses on embedded devices (including Android devices) mostly don't support enumeration (hardware discovery) because there are usually fixed set of devices and no option for a different OS to be loaded on device. Therefore OS needs to be informed of all connected devices and this is done by providing a standard DTB to kernel. DTB is provided by SoC / motherboard vendor and is usually a part of kernel source. During boot process, DTB is loaded by bootloader at boot time and passed to kernel so that it can discover hardware and create node points accordingly.
We can view device tree on Adroid device by:
Code:
~# ls /sys/firmware/devicetree/base
~# ls /proc/device-tree
DTB may live on a separate dtb/odm partition as specified by AOSP (and was the proposed solution for ARM based embedded Linux devices before Android's birth) but that isn't widely practiced. Usually DTB is appended to kernel zImage/Image.gz or placed at second stage inside boot.img.
VERIFIED / SECURE BOOT
Ensuring a chain of trust from Power ON up to loading of kernel is with the domain of SoC vendor (Qualcomm, Intel etc.) and OEM's. Injecting some malicious or harmful code at any point during booting is made harder to the extent of impossibility.
To ensure a secure booting chain, PBL verifies authenticity of SBL which subsequently verifies integrity of bootloaders (TZ, RPM, DSP, HYP and aboot) so that to avoid loading of unsigned images (boot, recovery, system and others). TZ, after being loaded by SBL also verifies ABOOT using a hardware-based root certificate.
A bootloader with Verified/Secure Boot implementation verifies boot.img or recovery.img (kernel, initramfs and DTB appended to kernel or on second stage of boot.img) by matching their signature with key(s) stored in "OEM keystore" (some partition like CMNLIB, KEYMASTER or with some other name) which itself is signed by OEM. Some vendors allow replacing/appending this keystore with custom one so that custom signed images can be flashed followed by re-locking of bootloader. A simple detail is given here.
At this stage, the chain of trust is handed over to "dm-verity" key stored in boot image initramfs, responsible for "Verified Boot" process of Google/AOSP. Dm-verity (a part of Verified Boot implementing Linux Device Mapper by Google) is a kernel feature i.e. it comes into action after boot image (kernel and ramdisk) is loaded in RAM. It verifies subsequently loading block devices; /system, (/vendor if it exists) and optionally others.
For details see this, this and this.
Google suggests integrating libavb (native code to verify integrity of boot.img) in bootloaders starting from Verified Boot 2.
Unlocking Bootloader
Read here to know about the risks of BL unlocking.
Unsigned kernel or recovery cannot be loaded unless bootloader is unlocked. To make any modification to OS, a critical piece of process is disabling a security system built into the Android's bootloader (aboot) that protects the read-only partitions from accidental (or intentional) modification for privacy, security and DRM. This is what's referred to as "unlocking NAND" or "unlocking bootloader." You have to firstly unlock bootloader to modify partitions "boot" or "recovery" and to gain root access on /system. If bootloader is locked, you only have write access to /cache and /data partitions. Everything else is read-only on device and bootloader will prevent unsigned images from being flashed to the phone. Unlocked bootloader ignores signature verification check which was initiated by BootROM and then transferred to "SBL" and then to "ABOOT" while loading kernel or recovery.
Some newer devices don't allow unlocking of bootloader directly (FRP) without permission from manufacturer to ensure more security i.e. contents of partition "devinfo" are signed by the OEM and can't be modified without their approval. After having permission, an official method is provided to unlock BL using PC. Still some functions related to Proprietary Content might be lost due to bootloader unlocking.
DRM is used to protect content from being copied.
Certain pre-loaded content on your device may also be inaccessible due to the removal of DRM security keys.
Click to expand...
Click to collapse
Android Rooting
Must Read: Root User and Linux Capabilities: Linux vs. Android
Note: Unlocking Bootloader and Rooting breaks "Verified Boot". It can be dangerous.
In order to perform some privileged task on Android, we need to "root" the device first. Since it's impossible to start a process with elevated privelages from within running Android OS, rooting usually involves running a root process (su-daemon) from boot with all capabilities. Superuser requests are made by any non-privelaged programs by executing "su" binary and permissions are managed by an app.
In early days, rooting usually involved booting into a custom recovery which in turn mounted and modified /system files. Usually some daemon's executable binary was replaced with a custom script. In order to address the OTA and other issues caused by improving security features (SELinux, Verfied Boot, SafetyNet etc.), systemless root method was introduced which is used by latest apps like Magisk. It involves modifying /boot image and putting some files on /data as well. So a new init service is injected fulfilling all necessary requirements of new security mechanisms.
In both cases, a locked bootloader won't boot custom recovery or modifed kernel (boot.img). See Verified Boot. Therefore bootloader needs to be unlocked for rooting.
However it is possible to gain root sometimes without unlocked bootloader but not always.
Other methods of rooting a phone from within a running ROM using some sort of One-Click rooting solution (KingRoot, Z4Root, KingoRoot etc.) depend on some vulnerability or exploit in Android OS. Making such security breaches is getting harder and harder with every new release of Android and with improved defense mechanisms, though it varies for different vendors too. The most prominent was with the release of Lollipop and Marshmallow when systemless method had to be introduced beacuse the previous methods failed to work. When phone is rooted using one of such improper root methods, there is a high probability to face "incomplete root" like messages at some point. If such a rooting method works for your device, it's alarming. This exploit is also a way for malware to enter your device. For examples, see Magisk Installation - Exploits, this and this. A very popular exploit dirty cow was patched later.
In addition to that, there are some hacks for certain devices to flash custom recovery without unlocking bootloader using some kind of Firmware Flasher tool (SPFlasher, MiFlasher etc.) in Download Mode because Download Mode provides access to device even before bootloader/fastboot is loaded. Or if you are expert in coding, you can mimic the custom recovery image look like the factory signed firmware and flash it through stock recovery. But this exploit isn't a universal solution either.
So the proper way to rooting which doesn't need any vulnerability, goes through unlocked bootloader. While buying a new phone this must be considered. Keeping you away from root access and unlocked bootloader goes in favor of vendors. By forcing you to use their ROMs (with bundle of useless bloatware apps), they earn a lot from you - money as well as forced loyalty - by collecting data, showing ads and using a lot of other tactics. Go for a brand that provides kernel source and ability to unlock bootloader (on customer's responsibility and with voided warranty obviously).
FIRMWARE UPDATE PROTOCOLS (BOOTLOADER MODE)
Likewise BL, on every device there might be a single or multiple BL modes with different names like bootloader mode, download mode, emergency mode (EDL), ODIN (Samsung), nvFlash tool etc. When we boot in BL mode, device is stuck on boot logo. Some factory flashers work in these modes such as MiFlasher (Xiaomi) and SP Flash Tool (for MTK devices). Bootloader or Download Mode is accessible even if device is soft bricked i.e. if Recovery and/or ROM isn't accessible.
Download Mode
Download Mode (certain button combination while powering on device; usually Vol. Up + Vol. Down or Vol. Down for longer duration + Power) is an official method used by many vendors to flash factory firmware / updates using Flasher (software). Emergency Download Mode (EDL), as it's called on Xiaomi Devices, can also be accessed through fastboot/adb commands or by using some jigs/jumpers. However, to ensure more security, EDL is disabled on some newer devices.
Download Mode is primary to bootloader mode (at PBL or SBL stage) and can be used without unlocking bootloader.
Odin (Samsung), QPST/QFIL work in Download mode (Qualcomm HS-USB QDloader 9008).
When we boot in Download mode, device is stuck on blank screen.
Fastboot Mode
Fastboot - provided by ABOOT - is a software development tool and a standard communication protocol for Android bootloader. It's an alternate of recovery flashing that works in BootLoader mode (aboot) and comes bundled on most of the recent ARM Qualcomm devices. It's a minimal UI through commandline to interact with device in case of failure or to modify / flash partitions. Some OEM's provide fastboot with limited functionality e.g. 'fastboot oem' commands not working and some devices haven't at all. It's up to the discretion of mobile phone vendor.
Fastboot mode is used to perform operations through commands when device is connected to PC through USB. It works even when phone is not switched on in Recovery or ROM or even if android isn't installed on phone. You can read here what operations we can perform through fastboot mode.
Only NAND (eMMC) and USB modules (drivers) are activated at this stage.
INIT PROCESSES & SERVICES: ANDROID vs. LINUX
FILESYSTEM TREE MOUNTED BY INIT: ANDROID vs. LINUX
RESOURCES:
From the bootloader to the kernel

RESERVED

RESERVED

RESERVED

RESERVED

You have to firstly unlock bootloader to modify partitions "boot" or "recovery" and to gain root access on /system. If bootloader is locked, you only have write access to /cache and /data partitions. Everything else is read-only on device and bootloader will prevent unsigned images from being flashed to the phone.
Click to expand...
Click to collapse
I'm under the impression that unlocking the bootloader is not mandatory for rooting the device.
You can root the device with a locked bootloader and gain full access to /system partition.

NikosD said:
I'm under the impression that unlocking the bootloader is not mandatory for rooting the device.
You can root the device with a locked bootloader and gain full access to /system partition.
Click to expand...
Click to collapse
Yeah I think my brief statement is a bit misleading because rooting is out of the scope of this thread. I have added some details to first post.

Thank you very much for all this useful info.
Some more comments.
A locked bootloader won't boot custom recovery or modified kernel (boot.img)
Click to expand...
Click to collapse
It happens to have a budget Chinese tablet with Oreo 8.0 and MediaTek SoC, which I can root using a modified/patched boot.img with Magisk v17.1 inside of course - I mean full root without problems - keeping the bootloader locked before and after rooting.
In addition to that, there are some hacks for certain devices to flash custom recovery without unlocking bootloader using some kind of Firmware Flasher tool (SPFlasher, MiFlasher etc.) in Download Mode because Download Mode provides access to device even before bootloader/fastboot is loaded
Click to expand...
Click to collapse
The tablet mentioned above, belongs to this category too.
Using SPFT (Smart Phone Flash Tool), I can flash custom recovery TWRP for my device without unlocking the bootloader.
So, I have two questions:
1) Is it rare to have such a device or is it common nowadays to be able to root and flash custom recovery TWRP with locked bootloader ?
2) How is technically possible to patch boot.img for rooting and flash TWRP using SPFlashTool (even in download mode before bootloader) without complains afterwards from bootloader, verified boot, dm-verity and all these safety checks that validate digital signature of Vendor ?
I mean you can do whatever you want before bootloader starts, but how can you escape from security traps after the initialization of bootloader verifications ?
Thank you.

NikosD said:
1) Is it rare to have such a device or is it common nowadays to be able to root and flash custom recovery TWRP with locked bootloader ?
Click to expand...
Click to collapse
I'm not sure how common it is but I must say these are exploits. Developers are making use of these vulnerabilities for positive and negative purposes. But these are not a "long-term" solution for rooting.
2) How is technically possible to patch boot.img for rooting and flash TWRP using SPFlashTool (even in download mode before bootloader) without complains afterwards from bootloader, verified boot, dm-verity and all these safety checks that validate digital signature of Vendor ?
I mean you can do whatever you want before bootloader starts, but how can you escape from security traps after the initialization of bootloader verifications ?
Click to expand...
Click to collapse
That's what my point is. Fastboot code verifies signatures/hashes only when flashing the image and doesn't verify or fails to verify integrity if image is already flashed. This is not the desired behavior so it's an exploit and it should be closed. Letting unsigned images be flashed in Download Mode is another exploit which is common with Chinese vendors as far as I have come across some instances. They don't address "loopholes" seriously. Failure to stop security breaches at or after bootloader level is definitely on SoC Vendor or OEM's part. I have added a paragraph in first post with some useful details and links.
This link explains:
The Qualcomm SoC is analyzed in the previous chapter dload / edl mode, the mode in the firmware image download process does not do any verification, can be directly written into the brush.
Click to expand...
Click to collapse
It's badly translated from Chinese but is informative.
Exploiting Qualcomm EDL Programmers is a complete series on this subject summarized here.

mirfatif said:
Only NAND (eMMC) and USB modules (drivers) are activated at this stage.
Click to expand...
Click to collapse
Hey pal, I'd like to know if you could help me with an issue I'm facing. I have a Moto G5 that isn't booting to any ROM (it either bootloops in bootlogo or in boot animation), and also on TWRP and during the boot animations the device is slow as hell (like 0.5 FPS on TWRP and even less on boot animation; on TWRP the device also takes a few seconds to complete even the simplest tasks - like the press of a button or the swipe of a slider - here's a video that shows differences between how stuff works on fastboot and how slow things are on TWRP, it takes like 2 hours to completely flash a custom ROM, i.e.).
I know much of the issue will be device-specific, but my point (and the reason I quoted that specific part of your OP) is that, on fastboot mode, the device is snappy and responsive. When I press a button it completes the corresponding task immediately, frames don't stutter (not that there are any animations to be rendered in fastboot, but when I switch from one option to another using the volume keys, it does so on screen as it should, with no lag), and so on. Stock recovery also seems to be ok with speed, but it's even harder to measure than fastboot because, in almost 10 years meddling with android devices, I have always found stock recoveries (and CWM in the pre-TWRP times) to be somewhat slow. Stock recovery definitely looks snappier than TWRP, though. Tried several ROMs, both custom and stock, and the issues remain on all of them.
I got to this post by researching if fastboot mode was stored on the same NAND chip as recovery, OS and so on (found out that yes, it's all on the same chip). If it wasn't, I could just assume it was a hardware fault on the NAND chip, and that would be the reason that fastboot was running fine but recovery and OS weren't, but since they're all on the same cell, I can only think that some part of the system (I mean as in every single code that runs on the device, not only the OS) that loads on TWRP and on normal boot, but not on fastboot (and possibly not on stock recovery) are faulty, thus being a software issue (either solvable with just a normal USB cable or needing a flash box).
So, my question is: which are the differences in the parts of system loaded by fastboot and by TWRP? Are there any parts that are loaded by TWRP that aren't loaded by the stock recoveries on most devices?
I know it's a rather complicated question and some stuff might be device-specific, but if there is anything you could tell me that are more generic to every Android device, it would help me a lot. Thanks in advance.

Fire HD 8 (2018 ONLY) unbrick, downgrade, unlock & root

{
"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"
}
Changelog:
v2 - Fixed the issue with the screen
Make sure to read this guide completely before starting. It requires you to open the tablet, however you don't need to solder or use any advanced tools.
This is only for Fire HD 8, 8th generation, also known as karnak or KFKAWI. It's now confirmed to work on both 16GB and 32GB models.
You will lose all data on the tablet, make a backup of important data before you start. If you've enabled encryption, it's probably a good idea to disable it before you proceed with the guide.
What you need:
- a Linux installation. Since I had to rush it, this guide is only for Linux. Once I get a chance to test it on Windows I'll update the guide.
- microusb cable to connect your tablet to the PC
- some way to open the tablet (pry tool, opening picks, etc)
- something conductive (metal tweezers, a paper clip, a piece of wire, etc)
- amonet.tar.gz
- 6300.zip: https://mega.nz/#!FI1HSI5T!2zUAeiW9I-eH3Ph0Ar10_2nioNIm0ilSnNYgOG9YPNE
- Magisk-v18.0.zip: https://github.com/topjohnwu/Magisk/releases/download/v18.0/Magisk-v18.0.zip
- finalize.zip
Install python3, PySerial, adb and fastboot. For Debian/Ubuntu something like this should work "sudo apt install python3 python3-serial android-tools-adb android-tools-fastboot".
Extract amonet.tar.gz, open a terminal and navigate to it.
You might need to run the scripts on your PC under sudo if you're getting permission errors.
0. Shut your device down and disconnect it from USB! Also, disconnect all other Android devices you might have connected from your PC. Also, if you have ModemManager installed, you MUST disable or uninstall it before you begin
1. Use a pry tool to remove the back shell from the tablet. Start at the bottom and work your way up. There are no cables between the back shell and the motherboard.
2. On the left side of the board there are 4 test points labeled DAT0, RST, CMD, CLK. We only care about the bottom one, CLK.
3. Plug in one end of the microusb cable, either to the PC or to the tablet, whatever's more convenient.
4. On your PC, run `./bootrom-step.sh`. It should print "Waiting for the bootrom".
5. Using your conductive apparatus, short the CLK test point to the ground. This means you should connect one side of your paperclip to the CLK pin and the other to the metallic shield or a side of the PCB. Firmly hold it in place so that there is connection. (See https://i.imgur.com/7BXIb2y.jpg)
6. Plug in the other end of the microusb cable.
7. You should see a new device appear on your PC
Code:
[10894.058045] usb 3-2.4.1: new full-speed USB device number 9 using xhci_hcd
[10894.239684] usb 3-2.4.1: New USB device found, idVendor=0e8d, idProduct=0003
[10894.239690] usb 3-2.4.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[10894.241330] cdc_acm 3-2.4.1:1.0: ttyACM0: USB ACM device
This *must* be the device you see. If you see a "preloader" device instead, you didn't hold the paperclip strong enough. Unplug it, shut down your Fire (pull out USB cord and wait; if it doesn't shut down, you might have to disconnect the battery) and try again starting at step 4.
8. The script you ran in step 4 should now tell you to remove the short. Remove the paperclip and press Enter as instructed.
9. The script will now proceed to downgrade your device and flash some essential files. Just let it be, it will take about 4 minutes. You should see the following output:
Code:
[2019-01-26 23:30:02.157670] Waiting for bootrom
[2019-01-26 23:30:20.438333] Found port = /dev/ttyACM0
[2019-01-26 23:30:20.439362] Handshake
[2019-01-26 23:30:20.441693] Disable watchdog
* * * Remove the short and press Enter * * *
[2019-01-26 23:30:22.636037] Init crypto engine
[2019-01-26 23:30:22.661832] Disable caches
[2019-01-26 23:30:22.662505] Disable bootrom range checks
[2019-01-26 23:30:22.685773] Load payload from ../brom-payload/build/payload.bin = 0x4690 bytes
[2019-01-26 23:30:22.693170] Send payload
[2019-01-26 23:30:23.527965] Let's rock
[2019-01-26 23:30:23.528832] Wait for the payload to come online...
[2019-01-26 23:30:24.260602] all good
[2019-01-26 23:30:24.261069] Check GPT
[2019-01-26 23:30:24.596346] gpt_parsed = {'proinfo': (1024, 6144), 'PMT': (7168, 9216), 'kb': (16384, 2048), 'dkb': (18432, 2048), 'lk': (20480, 2048), 'tee1': (22528, 10240), 'tee2': (32768, 10240), 'metadata': (43008, 80896), 'MISC': (123904, 1024), 'reserved': (124928, 16384), 'boot': (141312, 32768), 'recovery': (174080, 40960), 'system': (215040, 6354944), 'vendor': (6569984, 460800), 'cache': (7030784, 1024000), 'userdata': (8054784, 22722527)}
[2019-01-26 23:30:24.596619] Check boot0
[2019-01-26 23:30:24.841858] Check rpmb
[2019-01-26 23:30:25.051079] Downgrade rpmb
[2019-01-26 23:30:25.052924] Recheck rpmb
[2019-01-26 23:30:25.949978] rpmb downgrade ok
[2019-01-26 23:30:25.950284] Flash lk-payload
[5 / 5]
[2019-01-26 23:30:26.471797] Flash preloader
[288 / 288]
[2019-01-26 23:30:44.845804] Flash tz
[6732 / 6732]
[2019-01-26 23:33:08.502134] Flash lk
[685 / 685]
[2019-01-26 23:33:23.337460] Inject microloader
[4 / 4]
[2019-01-26 23:33:23.667547] Reboot to unlocked fastboot
If the script freezes at some point, you will have to restart it. Terminate the script, unplug USB, and try again starting at step 4. If after unplugging USB cable the device doesn't shut down, you might have to disconnect the battery. You can keep it disconnected until the script succeeds, but once it's done you must reconnect it before booting to fastboot.
9. You should see a success message: "Reboot to unlocked fastboot". Only proceed if you see the message.
10. Once the device boots to fastboot (check with "fastboot devices". You should see amazon logo on the screen.), you can run "./fastboot-step.sh". Then, flip the device over so that you can see the display.
11. At this point the device should boot into recovery, however it's possible that the screen will be off by default. Just press the power button twice and the screen should turn on.
12. We'll now upload required files to the recovery. On your PC, do:
adb push 6300.zip /sdcard
adb push Magisk-v18.0.zip /sdcard
adb push finalize.zip /sdcard
13. In the recovery, go to "Install", navigate to "/sdcard" and flash 6300.zip
14. Go to "Wipe" and do the default wipe, then reboot
15. At the Fire setup screen, select your language. On the next screen, Wifi setup, select any password-protected network, then instead of entering the password press "cancel". Now, back at the wifi setup screen, press "skip" and "skip" in the dialog pop-up again
16. Hold down the power button, press Restart and hold volume down to boot into recovery.
17. In the recovery, go to "Install", navigate to "/sdcard" and flash Magisk-v18.0.zip
18. Press back, select finalize.zip and flash it
19. Once finalize.zip is flashed, press "Reboot System"
20. Done. The device should now boot into a rooted 6.3.0.0 firmware. You should have Magisk manager installed, and root working. You will be able to boot into recovery by holding volume down.
21. At this point it should be safe to connect to wifi. If everything works okay, assemble your device.
Your device is now unlocked. You can flash a custom boot image, system image, etc. However, if you ever brick the device so bad the recovery does not boot, you will have to repeat these steps starting from the first one. Read below for what you should not do.
VERY IMPORTANT STUFF:
Only ever flash boot images from TWRP. Since nothing but TWRP is aware of the exploit, if you try to flash a boot image from Android, it won't have the exploit integrated into it! This includes Magisk as well, so do NOT install or uninstall it from Magisk Manager (However, installing modules should be fine; although it depends on the specific module).
Due to how the exploit works, it takes over the first 0x400 bytes of boot.img/recovery.img. When flashing zips from the recovery, it will transparently remove and then reinstall the exploit when needed. So long as you flash zips from the recovery, you should treat the boot image normally. However, this means that you cannot use any other apps (e.g. FlashFire) to flash the boot or recovery partitions.
To revert back to stock:
- download update package from amazon https://fireos-tablet-src.s3.amazon...ate-kindle-NS6301_user_1611_0001309035396.bin to your PC
- flash 6300.zip from twrp
- flash revert-stock.zip from twrp
- wipe data
- reboot to recovery; you should see amazon recovery now
- select "apply update from ADB" in the recovery menu
- run "adb sideload update-kindle-NS6301_user_1611_0001309035396.bin" on your PC
Another way to fix a brick:
- Download update package from amazon https://fireos-tablet-src.s3.amazon...ate-kindle-NS6301_user_1611_0001309035396.bin to your PC
- Download and unzip revert-stock.zip
- Do steps 0 to 9 from this guide (so everything until fastboot-step.sh)
- Wait for device to boot into fastboot mode (check with "fastboot devices")
- Run "fastboot flash boot boot.img" using boot.img from the revert-stock.zip
- Run "fastboot flash recovery recovery.img" using recovery.img from the from the revert-stock.zip
- Run "fastboot reboot recovery"
- Select "apply update from ADB" in the recovery menu
- Run "adb sideload update-kindle-NS6301_user_1611_0001309035396.bin" on your PC
Other misc information / troubleshooting:
- If you need to disconnect the battery, use a pair of tweezers to grab the wires and gently pull towards yourself. You can do bootrom-step.sh either with or without the battery connected, however fastboot-step.sh should be done with the battery connected.
- If your device is bricked (e.g. from a downgrade), just follow the steps as-is.
- If you're getting an error like "Serial protocol mismatch", or any other error in bootrom-step, try disabling or temporarily uninstalling ModemManager from your Linux
- To remount /system as rw use "mount -o rw,remount /system". ("mount -o remount,rw /system" will not work)
Thanks to: @hwmod @firetablethelp for testing different versions of the payload.
Special thanks to: aftv2-tools contributors https://gitlab.com/zeroepoch/aftv2-tools; the bootrom download protocol scripts are largely based on their work

GPL Notice:
- Source code for modified TWRP is available from https://github.com/xyzz/android_bootable_recovery
- Source code for amonet/brom-payload is available from https://github.com/xyzz/amonet/tree/master/brom-payload
Device tree to build TWRP: https://github.com/xyzz/android_device_amazon_karnak
Additionally, source code of the full exploit chain is available from https://github.com/xyzz/amonet
When I finish the writeup for this vulnerability, I'll update this post with a URL to the writeup.

You sir, are a marvelous wizard leet haxor ?. Thanks for this. Will this ever lead to any software solution for root on this tablet. Parden my noob questions?

beanaman said:
You sir, are a marvelous wizard leet haxor . Thanks for this. Will this ever lead to any software solution for root on this tablet. Parden my noob questions?
Click to expand...
Click to collapse
The only reason you have to open the tablet is to put the bootrom into download mode. If somebody figures out another way to do that, then yes it can be done completely in software. One way is to brick the tablet by erasing the preloader completely (both copies). However, this would require root (temporarily), and is more dangerous. Ultimately, I figured that the difficulty level here is about as much as replacing a battery (even lower) so I haven't investigated this further.

Thank you for explaining that further. It's nice to have this capability in our toolbox.

Wow! @xyz` you are a genius!
This exploit can be applied to fire 7 7th gen?

xyz` said:
Make sure to read this guide completely before starting. It requires you to open the tablet, however you don't need to solder or use any advanced tools.
This is only for Fire HD 8, 8th generation, also known as karnak or KFKAWI. I've also only tested this on the 16GB version, though the 32GB one should work the same.
You will lose all data on the tablet, make a backup of important data before you start. If you've enabled encryption, it's probably a good idea to disable it before you proceed with the guide.
What you need:
- a Linux installation. Since I had to rush it, this guide is only for Linux. Once I get a chance to test it on Windows I'll update the guide.
- microusb cable to connect your tablet to the PC
- some way to open the tablet (pry tool, opening picks, etc)
- something conductive (metal tweezers, a paper clip, a piece of wire, etc)
- amonet.tar.gz
- 6300.zip: https://mega.nz/#!FI1HSI5T!2zUAeiW9I-eH3Ph0Ar10_2nioNIm0ilSnNYgOG9YPNE
- Magisk-v18.0.zip: https://github.com/topjohnwu/Magisk/releases/download/v18.0/Magisk-v18.0.zip
- finalize.zip
Install python3, PySerial, adb and fastboot. For Debian/Ubuntu something like this should work "sudo apt install python3 python3-serial android-tools-adb android-tools-fastboot".
Extract amonet.tar.gz, open a terminal and navigate to it.
You might need to run the scripts on your PC under sudo if you're getting permission errors.
0. Shut your device down and disconnect it from USB! Also, disconnect all other Android devices you might have connected from your PC.
1. Use a pry tool to remove the back shell from the tablet. Start at the bottom and work your way up. There are no cables between the back shell and the motherboard.
2. On the left side of the board there are 4 test points labeled DAT0, RST, CMD, CLK. We only care about the bottom one, CLK.
3. Plug in one end of the microusb cable, either to the PC or to the tablet, whatever's more convenient.
4. On your PC, run `./bootrom-step.sh`. It should print "Waiting for the bootrom".
5. Using your conductive apparatus, short the CLK test point to the ground. This means you should connect one side of your paperclip to the CLK pin and the other to the metallic shield or a side of the PCB. Firmly hold it in place so that there is connection. (See https://i.imgur.com/7BXIb2y.jpg)
6. Plug in the other end of the microusb cable.
7. You should see a new device appear on your PC
This *must* be the device you see. If you see a "preloader" device instead, you didn't hold the paperclip strong enough. Unplug it, shut down your Fire (pull out USB cord and wait; if it doesn't shut down, you might have to disconnect the battery) and try again starting at step 4.
8. The script you ran in step 4 should now tell you to remove the short. Remove the paperclip and press Enter as instructed.
9. The script will now proceed to downgrade your device and flash some essential files. Just let it be, it will take about 4 minutes. You should see the following output:
If the script freezes at some point, you will have to restart it. Terminate the script, unplug USB, and try again starting at step 4. If after unplugging USB cable the device doesn't shut down, you might have to disconnect the battery. You can keep it disconnected until the script succeeds, but once it's done you must reconnect it before booting to fastboot.
9. You should see a success message: "Reboot to unlocked fastboot". Only proceed if you see the message.
10. Once the device boots to fastboot (check with "fastboot devices"), you can run "./fastboot-step.sh". Then, flip the device over so that you can see the display.
11. At this point the device should boot into recovery, however it's possible that the screen will be off by default. Just press the power button twice and the screen should turn on.
13. We'll now upload required files to the recovery. On your PC, do:
adb push 6300.zip /sdcard
adb push Magisk-v18.0.zip /sdcard
adb push finalize.zip /sdcard
14. In the recovery, go to "Install", navigate to "/sdcard" and flash 6300.zip
15. Go to "Wipe" and do the default wipe, then reboot
16. At the Fire setup screen, select your language. On the next screen, Wifi setup, select any password-protected network, then instead of entering the password press "cancel". Now, back at the wifi setup screen, press "skip" and "skip" in the dialog pop-up again
17. Hold down the power button, press Restart and hold volume down to boot into recovery.
18. In the recovery, go to "Install", navigate to "/sdcard" and flash Magisk-v18.0.zip, finalize.zip, in that order.
15. Press "Reboot System" once the latest zip, finalize.zip, is installed.
16. Done. The device should now boot into a rooted 6.3.0.0 firmware. You should have Magisk manager installed, and root working. You will be able to boot into recovery by holding volume down.
17. At this point it should be safe to connect to wifi. If everything works okay, assemble your device.
Your device is now unlocked. You can flash a custom boot image, system image, etc. However, if you ever brick the device so bad the recovery does not boot, you will have to repeat these steps starting from the first one. Read below for what you should not do.
VERY IMPORTANT STUFF:
Only ever flash boot images from TWRP. Since nothing but TWRP is aware of the exploit, if you try to flash a boot image from Android, it won't have the exploit integrated into it! This includes Magisk as well, so do NOT install or uninstall it from Magisk Manager (However, installing modules should be fine; although it depends on the specific module).
Due to how the exploit works, it takes over the first 0x400 bytes of boot.img/recovery.img. When flashing zips from the recovery, it will transparently remove and then reinstall the exploit when needed. So long as you flash zips from the recovery, you should treat the boot image normally. However, this means that you cannot use any other apps (e.g. FlashFire) to flash the boot or recovery partitions.
To revert back to stock:
- download update package from amazon https://fireos-tablet-src.s3.amazon...ate-kindle-NS6301_user_1611_0001309035396.bin to your PC
- flash 6300.zip from twrp
- flash revert-stock.zip from twrp
- wipe data
- reboot to recovery; you should see amazon recovery now
- select "apply update from ADB" in the recovery menu
- run "adb sideload update-kindle-NS6301_user_1611_0001309035396.bin" on your PC
Special thanks to: aftv2-tools contributors https://gitlab.com/zeroepoch/aftv2-tools; the bootrom download protocol scripts are largely based on their work
Click to expand...
Click to collapse
LMFAO I can't ****ing believe this. I'm almost certain this will work on the HD 10 too. You found it before me. Absolutely brilliant. You've just proved many weeks and or months of my hard research that I've posted in more than a few threads between the fire 7 forums and here. You just happened to be a lot quicker at this and probably smarter. ACM I discovered a few weeks or months ago on the HD 10. There is a build file that has many ways to set ACM props. doing this made everything light up on my PC...new drivers were installed and being used including the preloader drivers. I set my test HD 10 to persist ACM since then, convinced it was one of the possible keys to the puzzle. If you've read anything I've done in the past several weeks and months you may have been the only one who truly believed anything I had been saying. I don't know who you are or where you came from but I can only thank you. You've made my day, my week and my year. At least now I can say I'm not crazy, hallucinating or 'don't know what I'm doing or talking about.' it will take me a few days to get started, but I'll get right to testing my test HD 10 in the next few days or so.
Edit: I was convinced it had to do with fos_flags too, which I believe is another way to unlock.
Sent from my MotoG3 using XDA Labs

Rortiz2 said:
Wow! @xyz` you are a genius!
This exploit can be applied to fire 7 7th gen?
Click to expand...
Click to collapse
The vulnerability is present on every mediatek device, so yeah. It will not work as-is because of different addresses (for the crypto device and offsets for LK). Additionally, on Fire 7 7th gen the eMMC test point is hidden behind the shield that you need to desolder, so you will probably want to find a different way to enter the bootrom download mode.

Great work!
xyz` said:
The vulnerability is present on every mediatek device, so yeah. It will not work as-is because of different addresses (for the crypto device and offsets for LK). Additionally, on Fire 7 7th gen the eMMC test point is hidden behind the shield that you need to desolder, so you will probably want to find a different way to enter the bootrom download mode.
Click to expand...
Click to collapse
This is very promising could you please elaborate, what exactly needs to be modified to port this to other MTK-hardware.
I have a fire 5th gen here and I can access brom-mode by pressing left mute button while pluging in.
tried your scripts as is (commenting out the parts that change rpmb or flash partitions) and it get's stuck at
Code:
[2019-01-28 00:01:40.973289] Disable bootrom range checks
Does the hash in load_payload.py (4dd12bdf0ec7d26c482490b3482a1b1f) need to be modified?
I do have the kernel-sources for the device and am willing to investigate correct addressing etc.
Also since this is a boot-rom exploit wouldn't it allow flashing a hacked preloader + lk which just ignore boot-signatures so we can just run a standard twrp?

k4y0z said:
This is very promising could you please elaborate, what exactly needs to be modified to port this to other MTK-hardware.
I have a fire 5th gen here and I can access brom-mode by pressing left mute button while pluging in.
tried your scripts as is (commenting out the parts that change rpmb or flash partitions) and it get's stuck at
Code:
[2019-01-28 00:01:40.973289] Disable bootrom range checks
Does the hash in load_payload.py (4dd12bdf0ec7d26c482490b3482a1b1f) need to be modified?
I do have the kernel-sources for the device and am willing to investigate correct addressing etc.
Also since this is a boot-rom exploit wouldn't it allow flashing a hacked preloader + lk which just ignore boot-signatures so we can just run a standard twrp?
Click to expand...
Click to collapse
So first of all make sure you're accessing bootrom mode and not preloader mode (Although if the preloader supports read/write, the exploit should work there as well, I just haven't tested it since on hd 8 8th gen none of preloaders support these). I suggest soldering on a UART adapter, then use 115200 baud rate. When in bootrom dl mode, you should see "[DL] 00000BB8 444C0005 010701" (basically, the "[DL]" part is the important one)
If it's a different soc, you will have to dump the bootrom and find the offset where range check data is stored (in my case, 0x102868). You might have to modify the 4dd12bdf0ec7d26c482490b3482a1b1f part as well, it's basically calculated as a xor of expected data and actual data it's written. Then, you'll also need to update the pointer I'm overwriting (0x1028A8 in my case, called ptr_send in brom-payload). Again, if executing under preloader it's gonna be completely different way to exploit it.
Once all this is done, you should be able to load binary payloads and execute them in bootrom mode. You'll also need to edit brom-payload and set up proper pointers to send_dword/recv_dword/etc, these can be found by reversing your bootrom dump. At this point it should be possible to get emmc read/write.
Finally, if you want a persistent unlock (and not just the ability to modify /system) you'll need to port lk exploit as well. So you'll have to figure if your lk is vulnerable to the same bug, port microloader, inject_microloader.py and lk-payload to use the proper offsets. It's a lot of work.
I'll hopefully finish my writeup in the next weeks and post a link to it, that should be easier to understand since I'll explain the whole process from start to finish.
You're right about being able to load a custom preloader/lk, however the bootrom exploit requires a PC connection and a bunch of USB commands (so in a way, it's "tethered"). The actual unlock exploit isn't using any bootrom bugs, but rather the lk bug, since that one works without a PC. In fact, the bootrom exploit is only used to flash stuff to eMMC (but, of course you could probably do more fun stuff with it) in my chain.

Thanks for your quick reply.
xyz` said:
So first of all make sure you're accessing bootrom mode and not preloader mode (Although if the preloader supports read/write, the exploit should work there as well, I just haven't tested it since on hd 8 8th gen none of preloaders support these). I suggest soldering on a UART adapter, then use 115200 baud rate. When in bootrom dl mode, you should see "[DL] 00000BB8 444C0005 010701" (basically, the "[DL]" part is the important one)
Click to expand...
Click to collapse
I'm pretty sure I'm in boot-rom, my preloader actually has direct read/write using read_mmc.py but that has been fixed in newer preloaders, so I would rather go the boot-rom route.
Have you tried if pressing left (or both) volume buttons while pluging in brings you to brom-mode as well, like it does on my device?
I'll attach a serial to check for the output.
xyz` said:
If it's a different soc, you will have to dump the bootrom and find the offset where range check data is stored (in my case, 0x102868). You might have to modify the 4dd12bdf0ec7d26c482490b3482a1b1f part as well, it's basically calculated as a xor of expected data and actual data it's written. Then, you'll also need to update the pointer I'm overwriting (0x1028A8 in my case, called ptr_send in brom-payload). Again, if executing under preloader it's gonna be completely different way to exploit it.
Click to expand...
Click to collapse
Any hint on how i would dump the bootrom? Also could you upload your boot-rom so I can compare once i got mine?
xyz` said:
Finally, if you want a persistent unlock (and not just the ability to modify /system) you'll need to port lk exploit as well. So you'll have to figure if your lk is vulnerable to the same bug, port microloader, inject_microloader.py and lk-payload to use the proper offsets. It's a lot of work.
Click to expand...
Click to collapse
Willing to put that work in
xyz` said:
I'll hopefully finish my writeup in the next weeks and post a link to it, that should be easier to understand since I'll explain the whole process from start to finish.
Click to expand...
Click to collapse
looking forward to your writeup.
xyz` said:
You're right about being able to load a custom preloader/lk, however the bootrom exploit requires a PC connection and a bunch of USB commands (so in a way, it's "tethered"). The actual unlock exploit isn't using any bootrom bugs, but rather the lk bug, since that one works without a PC. In fact, the bootrom exploit is only used to flash stuff to eMMC (but, of course you could probably do more fun stuff with it) in my chain.
Click to expand...
Click to collapse
I thought it might be possible to flash a preloader that exploits the same vulnerability, but from your explanation I assume that won't be possible.
For this device it would already be great to be able to overwrite RPMB to downgrade, since there was an LK that allowed booting into unsigned TWRP.

k4y0z said:
Thanks for your quick reply.
I'm pretty sure I'm in boot-rom, my preloader actually has direct read/write using read_mmc.py but that has been fixed in newer preloaders, so I would rather go the boot-rom route.
Have you tried if pressing left (or both) volume buttons while pluging in brings you to brom-mode as well, like it does on my device?
I'll attach a serial to check for the output.
Click to expand...
Click to collapse
Yep, I've tried and it didn't work, though it could be device-specific. There are several additional ways preloader can force you into bootrom download mode, for example if preloader has an assertion and you hold volume down, it just deletes itself from emmc and next boot you'd be in bootrom mode (this doesn't work on hd 8 though as there's a bug in how it's set up); then there's some button checks that sets up a SRAMROM_USBDL which bootrom checks (but the code for the button check isn't present on Fire preloader). So unfortunately the only option that worked for me is shorting eMMC to ground.
k4y0z said:
Any hint on how i would dump the bootrom? Also could you upload your boot-rom so I can compare once i got mine?
Click to expand...
Click to collapse
This will be in the writeup, it's too long to explain here. I'm not sure if I can share my dump since technically it's copyrighted code.
k4y0z said:
I thought it might be possible to flash a preloader that exploits the same vulnerability, but from your explanation I assume that won't be possible.
For this device it would already be great to be able to overwrite RPMB to downgrade, since there was an LK that allowed booting into unsigned TWRP.
Click to expand...
Click to collapse
Well, we only can flash preloaders signed by amazon. If you have a preloader/LK combination that doesn't have signature checks that's great, you can use that.

k4y0z said:
Any hint on how i would dump the bootrom? Also could you upload your boot-rom so I can compare once i got mine?
Click to expand...
Click to collapse
Also, here's what I used on my Fire 7:
Code:
def call_func(func):
sdr_write32(0x11010804, 3)
sdr_write32(0x11010808, 3)
sdr_write32(0x11010C00, func)
sdr_write32(0x11010400, 0)
while (not sdr_read32(0x11010800)):
pass
if (sdr_read32(0x11010800) & 2):
if ( not (sdr_read32(0x11010800) & 1) ):
while ( not sdr_read32(0x11010800) ):
pass
result = -1;
sdr_write32(0x11010804, 3)
else:
while ( not (sdr_read32(0x11010418) & 1) ):
pass
result = 0;
sdr_write32(0x11010804, 3)
return result
def hw_acquire():
sdr_write32(0x11010000, sdr_read32(0x11010000) & 0xFFFFFFF0)
sdr_write32(0x11010000, sdr_read32(0x11010000) | 0xF)
sdr_write32(0x11010004, sdr_read32(0x11010004) & 0xFFFFDFFF)
def hw_release():
sdr_write32(0x11010000, sdr_read32(0x11010000) & 0xFFFFFFF0)
sdr_write32(0x11010000, sdr_read32(0x11010000) | 0xF)
def init():
sdr_write32(0x11010C0C, 0)
sdr_write32(0x11010C10, 0)
sdr_write32(0x11010C14, 0)
sdr_write32(0x11010C18, 0)
sdr_write32(0x11010C1C, 0)
sdr_write32(0x11010C20, 0)
sdr_write32(0x11010C24, 0)
sdr_write32(0x11010C28, 0)
sdr_write32(0x11010C2C, 0)
sdr_write32(0x11010C00 + 18 * 4, [0] * 4)
sdr_write32(0x11010C00 + 22 * 4, [0] * 4)
sdr_write32(0x11010C00 + 26 * 4, [0] * 8)
def aes_read16(addr):
sdr_write32(0x11010C04, addr)
sdr_write32(0x11010C08, 0) # dst to invalid pointer
sdr_write32(0x11010C0C, 1)
sdr_write32(0x11010C14, 18)
sdr_write32(0x11010C18, 26)
sdr_write32(0x11010C1C, 26)
if call_func(126) != 0: # aes decrypt
raise Exception("failed to call the function!")
words = sdr_read32(0x11010C00 + 26 * 4, 4) # read out of the IV
data = b""
for word in words:
data += struct.pack("<I", word)
return data
def aes_write16(addr, data):
if len(data) != 16:
raise RuntimeError("data must be 16 bytes")
pattern = bytes.fromhex("6c38d88958fd0cf51efd9debe8c265a5")
# iv-xor
words = []
for x in range(4):
word = data[x*4:(x+1)*4]
word = struct.unpack("<I", word)[0]
pat = struct.unpack("<I", pattern[x*4:(x+1)*4])[0]
words.append(word ^ pat)
sdr_write32(0x11010C00 + 18 * 4, [0] * 4)
sdr_write32(0x11010C00 + 22 * 4, [0] * 4)
sdr_write32(0x11010C00 + 26 * 4, [0] * 8)
sdr_write32(0x11010C00 + 26 * 4, words)
sdr_write32(0x11010C04, 0xE680) # src to VALID address which has all zeroes (otherwise, update pattern)
sdr_write32(0x11010C08, addr) # dst to our destination
sdr_write32(0x11010C0C, 1)
sdr_write32(0x11010C14, 18)
sdr_write32(0x11010C18, 26)
sdr_write32(0x11010C1C, 26)
if call_func(126) != 0: # aes decrypt
raise Exception("failed to call the function!")
Try calling aes_read16(0) and see if it returns valid looking data (should start with "07 00 00 EA FE FF FF EA FE FF FF EA FE FF FF EA")

xyz` said:
Also, here's what I used on my Fire 7:
Try calling aes_read16(0) and see if it returns valid looking data (should start with "07 00 00 EA FE FF FF EA FE FF FF EA FE FF FF EA")
Click to expand...
Click to collapse
It seems to just hang with both aes_read16 and aes_write16.
It is probably related to the CRYPTO_BASE.
I tried finding the correct one here: https://github.com/chaosmaster/andr...ch/arm/mach-mt8127/include/mach/mt_reg_base.h
but didn't seem to find anything usefull (I tried CRYPTO_BASE = 0x1101B000, but that doesn't work either)

k4y0z said:
It seems to just hang with both aes_read16 and aes_write16.
It is probably related to the CRYPTO_BASE.
I tried finding the correct one here: https://github.com/chaosmaster/andr...ch/arm/mach-mt8127/include/mach/mt_reg_base.h
but didn't seem to find anything usefull (I tried CRYPTO_BASE = 0x1101B000, but that doesn't work either)
Click to expand...
Click to collapse
So what you can do is download a firmware update for your device, load up the preloader in IDA (or a disassembler of your choice) and search for "hw sha". You should see it used like this: https://i.imgur.com/1PcObV7.png. Then inside that function https://i.imgur.com/wvpq5Qm.png the first call is essentially hw_acquire, then hash, then hw_release. Going further https://i.imgur.com/D5Z9UoM.png. So the base in my case is 0x10210000. You should figure out at which point it hangs, if it's inside one of the while loops, make sure you call init() and hw_acquire() first (it's not always required, seems to be hw-dependent)

Porting the hack to Fire 7" 7th Generation
xyz` said:
So first of all make sure you're accessing bootrom mode and not preloader mode (Although if the preloader supports read/write, the exploit should work there as well, I just haven't tested it since on hd 8 8th gen none of preloaders support these). I suggest soldering on a UART adapter, then use 115200 baud rate. When in bootrom dl mode, you should see "[DL] 00000BB8 444C0005 010701" (basically, the "[DL]" part is the important one)
If it's a different soc, you will have to dump the bootrom and find the offset where range check data is stored (in my case, 0x102868). You might have to modify the 4dd12bdf0ec7d26c482490b3482a1b1f part as well, it's basically calculated as a xor of expected data and actual data it's written. Then, you'll also need to update the pointer I'm overwriting (0x1028A8 in my case, called ptr_send in brom-payload). Again, if executing under preloader it's gonna be completely different way to exploit it.
Once all this is done, you should be able to load binary payloads and execute them in bootrom mode. You'll also need to edit brom-payload and set up proper pointers to send_dword/recv_dword/etc, these can be found by reversing your bootrom dump. At this point it should be possible to get emmc read/write.
Finally, if you want a persistent unlock (and not just the ability to modify /system) you'll need to port lk exploit as well. So you'll have to figure if your lk is vulnerable to the same bug, port microloader, inject_microloader.py and lk-payload to use the proper offsets. It's a lot of work.
I'll hopefully finish my writeup in the next weeks and post a link to it, that should be easier to understand since I'll explain the whole process from start to finish.
You're right about being able to load a custom preloader/lk, however the bootrom exploit requires a PC connection and a bunch of USB commands (so in a way, it's "tethered"). The actual unlock exploit isn't using any bootrom bugs, but rather the lk bug, since that one works without a PC. In fact, the bootrom exploit is only used to flash stuff to eMMC (but, of course you could probably do more fun stuff with it) in my chain.
Click to expand...
Click to collapse
That was smart of you @xyz a genial solution.
You have proven that the "chain of trust" was a joke.
Many have said that what we were trying was impossible.
Did you realize on the 7" 7th Gen there are RST and EINT pads on the back of the photo I sent ?
Can we port your method to the 7th Gen by using RST instead of CLK to stop the MCU accessing the EMMC ?
Also the "watchdog" you disabled is on the RTC device of the MT6323 PMIC chip which in turn is on the I2C bus.
I can write to the I2C bus using a Bus Pirate v4, I already tried some write and seems I can do that too as an alternative.
Again the pads for accessing the I2C bus are on the back of the PCB of 7th Gen. tablets, they are labelled SCL2 and SDA2.
In a couple of week, or less, you have shown that Lab126 didn't deserve all that money for such a fake security mechanism.
I confirm that zeroing the "preloader" in "mmcblk0boot0" also forces the MCU to enter [DL] mode.
I was sure that investing time on the the [DL] mode would have paid back.
Again congratulation for the achievement and thank you for the time you have put on this.
.:HWMOD:.

hwmod said:
Did you realize on the 7" 7th Gen there are RST and EINT pads on the back of the photo I sent ?
Can we port your method to the 7th Gen by using RST instead of CLK to stop the MCU accessing the EMMC ?
Click to expand...
Click to collapse
I haven't tried with RST. Try it and see if you get a "[DL]" message on uart, if you do then it should work.
hwmod said:
Also the "watchdog" you disabled is on the RTC device of the MT6323 PMIC chip which in turn is on the I2C bus.
I can write to the I2C bus using a Bus Pirate v4, I already tried some write and seems I can do that too as an alternative.
Again the pads for accessing the I2C bus are on the back of the PCB of 7th Gen. tablets, they are labelled SCL2 and SDA2.
Click to expand...
Click to collapse
Yeah, I haven't investigated the watchdog too much. I don't think there's anything interesting you can do with it though.
hwmod said:
In a couple of week, or less, you have shown that Lab126 didn't deserve all that money for such a fake security mechanism.
I confirm that zeroing the "preloader" in "mmcblk0boot0" also forces the MCU to enter [DL] mode.
I was sure that investing time on the the [DL] mode would have paid back.
Click to expand...
Click to collapse
To be fair to lab126 all of the fail lies solely on mediatek. The bootrom code amazon probably doesn't even have access to, and LK is likely based on mediatek sources (although, it's a really obvious bug in image loading, come on). The boot chain is reasonably secure in its design, it's only the implementation that's flawed.

xyz` said:
So what you can do is download a firmware update for your device, load up the preloader in IDA (or a disassembler of your choice) and search for "hw sha". You should see it used like this: https://i.imgur.com/1PcObV7.png. Then inside that function https://i.imgur.com/wvpq5Qm.png the first call is essentially hw_acquire, then hash, then hw_release. Going further https://i.imgur.com/D5Z9UoM.png. So the base in my case is 0x10210000. You should figure out at which point it hangs, if it's inside one of the while loops, make sure you call init() and hw_acquire() first (it's not always required, seems to be hw-dependent)
Click to expand...
Click to collapse
Sadly i don't have the IDA decompiler, so just assembler it is :/
I did however find the correct CRYPTO_BASE I believe:
Code:
CRYPTO_BASE = 0x11010000
that gives the following output with aes_read16:
Code:
b'\x07\x00\x00\xea\xfe\xff\xff\xea\xfe\xff\xff\xea\xfe\xff\xff\xea'
aes_write16 now fails with "RuntimeError: ERROR: Serial protocol mismatch".
Can i dump the boot-rom with this now?

First of all, congrats and big thanks!
So, any hope for the 2017 HD8?

k4y0z said:
Sadly i don't have the IDA decompiler, so just assembler it is :/
I did however find the correct CRYPTO_BASE I believe:
Code:
CRYPTO_BASE = 0x11010000
that gives the following output with aes_read16:
Code:
b'\x07\x00\x00\xea\xfe\xff\xff\xea\xfe\xff\xff\xea\xfe\xff\xff\xea'
aes_write16 now fails with "RuntimeError: ERROR: Serial protocol mismatch".
Can i dump the boot-rom with this now?
Click to expand...
Click to collapse
Yeah, just go through all of the bootrom memory (0 to 0x20000, just to be sure, in 16 byte increments), call aes_read16 on it, concatenate everything and you'll get your bootrom dumped. It should end with a bunch of FF bytes so that's how you can tell the actual size.

[GUIDE][ROOT] QLink Scepter 8 Tablet (Gen 1 & Gen 2) | Bootloader Unlocking & Rooting Guide

QLink Scepter 8 Tablet​By Hot Pepper Mobile
{
"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"
}
Bootloader Unlocking
& Rooting Guide
For Gen 1 & Gen 2 Models​
TABLET MODELS & VARIANTS:
For those members familiar with the firmware restoration thread, there are a total of four model variants of the QLink Scepter 8 tablet: two variants of the Gen 1 model, and two variants of the latest Gen 2 model. Determining which Scepter 8 you have is a very simple two-part check. First, if you don't already know your Android OS version, go to device Settings> About tablet, and locate your Android version. If you are running Android 11 (Go Edition), you have the original Gen 1 model. If you are running Android 12 (Go Edition), your tablet is the latest Gen 2 model. Secondly, you will need to locate the device S/N in order to determine your tablet variant. Your S/N is printed on the manufacturer's label affixed to the exterior of the tablet's rear housing. From the Android OS, you can also locate your S/N by opening device Settings>About tablet>Model. Regardless of whether you have the Gen 1 or the Gen 2, the first two letters of your S/N will be either CF or MD. This is the codification of your tablet variant. To alleviate some of the legwork of rooting, and to keep this thread simple to follow, I have provided boot images pre-patched for Magisk v25.2 systemless root support. I have categorized the download links for each of the boot images in accordance with the respective model and S/N variant. To avoid potential bugs, instabilities, boot loops and the like, it is crucial that you download the boot image that corresponds with your model & variant. ​​OVERVIEW:
This guide outlines step-by-step instructions for unlocking the bootloader and rooting all variants of the Gen 1 & Gen 2 QLink Scepter 8 tablet. This guide also includes a detailed section on properly installing the ADB, fastboot, & USB device drivers on your Windows PC or laptop, as well as steps to troubleshoot & manually update these drivers in the event the tablet is not being recognized while in fastboot mode.
DISCLAIMER:
Unlocking your bootloader and rooting your device are both procedures that carry inherent risks. Because these procedures involve modifying the device from it's stock factory configuration, it is possible to corrupt, damage, or even render your tablet completely inoperable. By proceeding further, you are assuming sole responsibility for the integrity and operability of your device, therefore absolving me of any liability in the event something goes south. I have, however, tested these guides and feel confident that things will go smoothly as long as you follow the instructions carefully. Moreover, I encourage all members to read the instructions fully before starting the steps, in order to first gain a fundamental understanding of the concepts and methods involved.
PLEASE PLAY NICE & FOLLOW XDA RULES:
This thread was created with the intent of being a noob-friendly forum. This simply means that new and inexperienced members are fully welcome here, and will be provided with extra guidance and assistance if needed. Please keep in mind that XDA is a global community of developers, enthusiasts and device users. As such, and although English is the only permitted language in the forums & threads, not all members speak English as their first language, and often rely on text translation tools when asking questions & posting. Accordingly, it is very common for words to be misconstrued, meanings to be misinterpreted, and the context as a whole lost in translation. I ask members to be patient, compassionate and respectful to others on this thread. Those members with the knowledge to do so are urged and asked to help newer members, and recall back when you were new here and others helped you.
Please help me with keeping this thread on point by ensuring that all subject matter herein be kept relevant to the topics of rooting and OEM unlocking the QLink Scepter 8. Any posts about other devices or subject matter run afoul of XDA rules and are subject to removal by moderators -- and potential sanctions imposed upon the offending member. Moreover, an on-topic thread keeps things organized and easier to follow. Thank you for your consideration.
PREREQUISITES:
To unlock the bootloader and root the QLink Scepter 8 tablet, you will need a laptop or PC running on Windows 7/8.1/10/11. (A Mac or Linux machine can also be used. For purposes of this guide, however, I am focusing on a Windows setup.) You will also need the OEM-supplied or a quality equivalent micro USB to USB-A data sync cable. Last but not least, you will need to install compatible USB device drivers for ADB & Fastboot on your PC/laptop. I have included the 15-Second ADB Driver Installer below, under the DOWNLOADS section. This Installer will configure ADB & Fastboot system-wide, and installs the universal Google USB device drivers. I would encourage members to first read the instructions in their entirety prior to actually starting the guide.
•INSTALLING USB DEVICE DRIVERS•
This section is included to install and configure ADB, Fastboot and the proper USB device drivers on your Windows computer. This section can also be used to troubleshoot and fix issues involving your tablet not being recognized by Windows while connected in fastboot mode. If you have already installed the ADB & Fastboot tools (& the proper USB device drivers), and you are not experiencing fastboot recognition issues, you may skip this section and proceed to the bootloader unlocking section.
Many members have reported issues with device recognition while in fastboot mode. I have also noticed a persistence problem with Windows drivers on this tablet. I can manually update the driver using Windows Device Manager, enabling fastboot recognition; yet, once the tablet is disconnected from my PC the updated driver does not always persist, requiring a manual driver update each time fastboot mode is needed. Follow these steps to enable fastboot recognition of your device.
• 1. If you have not yet done so, install the 15-Second ADB Installer from the link below on your Windows PC or laptop. Open the utility and follow the prompts to install the ADB & Fastboot drivers. Next, opt to install ADB system-wide. Lastly, you will be prompted to install the Google USB device drivers. Select Y and install them. You should see an interface informing you that the drivers were successfully installed. NOTE: If you get a warning notification that the drivers are unsigned, select the option to install anyway;
• 2. With your tablet powered off, hold the Power and Volume Down buttons simultaneously until the QLink logo appears, at which time you release the Power button but continue holding Volume Down. When a green Android graphic appears on your display, you are in fastboot mode;
• 3. Connect your tablet to your Windows machine using the OEM-supplied or a quality equivalent micro USB to USB-A data sync cable;
• 4. Open a command window in the path of your ADB/Fastboot directory. Execute this command:
Code:
fastboot devices
If properly connected, the command window will return an alphanumeric string which is synonymous with your tablet serial number. If this occurs, you are finished with this section and may proceed to the instructions for unlocking the bootloader/rooting. If the command window displays Waiting on Any Device, or if your serial number is not displayed, continue with the following steps;
• 5. Keeping your device connected to your Windows PC/laptop, right click your Windows Start icon and select Device Manager. Locate your tablet in the menu. It will likely be located under either the Portable Devices or Android Device heading;
• 6. Right click your device and select Update Driver. Next, select Browse My Computer for Drivers. On the next screen choose the option for Let Me Pick From a List... Now you will see a list of drivers to select from. Depending on the manner in which Windows recognized your tablet in the Device Manager menu, the driver selection menu can vary. If you see an option for Android Device, select that option and then select Android Composite ADB Interface. Or, you may be directly presented with options for Android Bootloader Interface, Android ADB Interface and Android Composite ADB Interface. In any event, choose Android Composite ADB Interface and then click Next. Click Yes in the Update Driver Warning dialogue screen, at which time the drivers will be installed.
• 7. Return to your command window and again execute the fastboot devices command. If your serial number is displayed, your drivers are now properly installed. If you are still experiencing fastboot recognition issues, try using another data sync cable, change USB ports on your computer, and/or reinstall the drivers using the 15-Second ADB Installer.
I. UNLOCKING THE BOOTLOADER:
If you plan on rooting your tablet, this step is mandatory. If your bootloader is already unlocked and you only wish to root your device, skip down to the rooting instructions in the next section below.
WARNING: Unlocking your bootloader forces the device into a factory data reset, which will effectively wipe all saved user data from the device. Make a backup at this point if there are files and media on your tablet that you wish to keep.
INSTRUCTIONS:
1. Enable Developer Options on your tablet by going to device Settings>About tablet and tap Build number approximately seven times. Android will notify you that Developer Options are enabled; this menu will appear under device Settings>System>Advanced.
2. Enable USB Debugging and OEM Unlocking in the Developer Options menu. NOTE: Users have reported the OEM Unlocking option being greyed-out unless you are signed in to your Google account.
3. Now to boot into fastboot mode, and this particular step is extremely important. Android 10 introduced a new fastboot mode for dynamic partitions, known as FASTBOOTD, which is relocated from the bootloader to userspace. This particular fastboot mode supports resizeable partitions within the dynamic scheme, and enables the user to create, resize and delete various logical partitions. However, FASTBOOTD mode cannot be utilized to unlock the bootloader, and will not recognize the unlock command. As such, the user must rely upon legacy fastboot mode in order to unlock the bootloader. From stock recovery mode, you may simply choose the option to reboot to bootloader. DO NOT CHOOSE THE OPTION TO ENTER FASTBOOT, as this option will boot to FASTBOOTD. From the Android OS, you can boot into legacy fastboot mode by executing:
Code:
adb reboot bootloader
Once you see a green Android graphic appear in the center of your display, you are in the correct fastboot mode.
4. Connect your tablet to your PC/laptop using the OEM-supplied or a quality equivalent micro USB to USB-A data sync cable. Next, open a command window in the path of your ADB/Fastboot directory. Check your connection by executing this command:
Code:
fastboot devices
If you are properly connected, the command window will return an alphanumeric string synonymous with your device's serial number. If you do not see this, there is a problem with communications between your tablet and PC/laptop. To troubleshoot the issue, switch to another USB port, try another data sync cable, and/or reinstall the ADB/Fastboot drivers on your PC or laptop. Also, see my instructions above on installing USB device drivers on your Windows computer;
5. Once a proper connection has been verified, execute this command:
Code:
fastboot oem unlock
Once you see the Okay notification in the command window, your bootloader is now unlocked. Execute this command:
Code:
fastboot reboot
Your tablet will now initiate a factory data reset and then reboot into the initial setup for the Android OS.
II. ROOTING THE QLINK SCEPTER 8
Now that the bootloader has been unlocked, rooting this tablet is very straightforward. Again, I have provided pre-rooted boot image files in the DOWNLOADS section for all four models & variants.
INSTRUCTIONS:
A. Gen 1 QLink Scepter 8​Android 11 (Go Edition)​
NOTE: If your tablet is running Android 12 Go Edition, you're in the wrong place. Skip down to the next section.
1. Download the Gen 1 patched boot image that matches your S/N variant using the links below, and save the file on your PC/laptop in the ADB/Fastboot directory. Note that the file is named patched_boot.img. The flashing command below assumes that you leave this file name unchanged;
2. Go to device Settings>About tablet and tap Build number 7 times or until Developer Options are enabled. (This step is necessary if you unlocked your bootloader using the previous section, due to the factory data reset.) Enable USB Debugging in the Developer Options menu;
3. Power your tablet off. Hold the Power and Volume Down keys simultaneously until the QLink logo appears, at which time you release Power but continue holding Volume Down. The green Android will appear on the display to indicate fastboot mode;
4. Connect your tablet to your PC or laptop using a quality data sync cable. Verify your connection using the instructions in Step 4 of the bootloader unlocking section above;;
5. Once a solid connection is verified, execute these commands:​
Code:
fastboot flash boot patched_boot.img
fastboot reboot
NOTE: Your active boot slot should be boot_a. Regardless, the above command flashes your active slot by default, without having to specify slot _a or _b.
Upon reboot, your tablet will be rooted with the latest Magisk systemless root strategy. If you do not see the Magisk app or the placeholder stub in your app drawer, go ahead and download the latest version from the link below and install the APK on your tablet. Open the Magisk app, grant the prompted permissions, and follow any prompts to complete setting up the root environment.
B. Gen 2 QLink Scepter 8​Android 12 (Go Edition)​
NOTE: If your tablet is running Android 11 Go Edition, you're in the wrong place. Go back to the previous section. .
1.Download the Gen 2 patched boot image that matches your S/N variant and the empty vbmeta.img using the links below, and save the files on your PC/laptop in the ADB/Fastboot directory. Note that the boot image file is named patched_boot.img, and the vbmeta image is named vbmeta.img. The flashing commands below assume that you leave these file names unchanged;
2. Go to device Settings>About tablet and tap Build number 7 times or until Developer Options are enabled. (This step is necessary if you unlocked your bootloader using the previous section, due to the factory data reset.) Enable USB Debugging in the Developer Options menu;
3. Power your tablet off. Hold the Power and Volume Down keys simultaneously until the QLink logo appears, at which time you release Power but continue holding Volume Down. The green Android will appear on the display to indicate fastboot mode;
4. Connect your tablet to your PC or laptop using a quality data sync cable. Verify your connection using the instructions in Step 4 of the bootloader unlocking section above;;
5. Once a solid connection is verified, execute this command:
Code:
fastboot flash boot patched_boot.img
Now, continuing in fastboot mode, you will need to disable dm-verity/Android Verified Boot (AVB) by flashing an empty vbmeta.img via executing the following command:​
Code:
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
Next, execute this command to reboot your device:
Code:
fastboot reboot
Upon reboot, your tablet should now be rooted with the Magisk systemless root strategy. If you do not see the Magisk app or the stub placeholder in your app drawer, go ahead and download the latest version from the link below and install it on your tablet. Open the Magisk app, grant the prompted permissions, and follow any prompts to update Magisk and/or complete setting up the root environment.
IMPORTANT NOTE:
In the unfortunate event you have a mishap with rooting your tablet and get stuck in a boot loop, or if your tablet will not otherwise boot into the Android OS, have no worries. My tutorial on firmware restoration for the QLink Scepter 8 will revert your device back to its original stock factory state. You can then return here and give it another try.
QLink Scepter 8 Firmware Restoration Guide
DOWNLOADS:
• 15-Second ADB Installer
• Gen 1 (CF) Patched Boot Image
• Gen 1 (MD) Patched Boot Image
• Gen 2 (CF) Patched Boot Image
• Gen 2 (MD) Patched Boot Image
• Empty vbmeta.img
• Official Magisk Releases / GitHub Repo
THANKS & MENTIONS:
Thanks goes out to Hot Pepper Mobile CEO Shawn Sun and Support Specialist Joshua G for providing stock firmware images for this device.
Also, I wish to recognize and thank @13lack13ox for being a huge help to thread members at times when I was not able.
​

For some reason, I'm stuck on the part where you have to use the fastboot option. So basically, I got my tablet in fastboot mode (the secondary one with the green android graphic), but when I tried to use the adb function, it doesn't detect my tablet. And also, the command, "fastboot devices" doesn't do anything, and when I try to use "fastboot device" it just says waiting for any device and just... stays there, not detecting my tablet. I tried multiple computers, tried both PowerShell and the command prompt with admin privileges, to no avail. For information, it worked when my tablet was on my tablet is the V9 firmware, but it slightly newer since I just updated to V9_20220224... so maybe that might have something to do with it...

64Star said:
For some reason, I'm stuck on the part where you have to use the fastboot option. So basically, I got my tablet in fastboot mode (the secondary one with the green android graphic), but when I tried to use the adb function, it doesn't detect my tablet. And also, the command, "fastboot devices" doesn't do anything, and when I try to use "fastboot device" it just says waiting for any device and just... stays there, not detecting my tablet. I tried multiple computers, tried both PowerShell and the command prompt with admin privileges, to no avail. For information, it worked when my tablet was on my tablet is the V9 firmware, but it slightly newer since I just updated to V9_20220224... so maybe that might have something to do with it...
Click to expand...
Click to collapse
Sounds like you have a common driver issue. Do this: with your device connected to your PC in fastboot mode, right click your Windows start button and open Device Manager. What is your tablet showing up as? We will need to update your driver. I can walk you through it. Did you install the Google driver from the 15-Second ADB Installer? I am nearly finished writing a guide on properly installing the device drivers. I will link it here when posted. It will give you a detailed step-by,-step outline. I don't think it's an issue with the firmware builds. Fastboot detection issues are common with this tablet due to some type of instability with driver persistence. For example, I often need to update my driver every time I use fastboot mode because, for some odd reason, the updated driver doesn't persist once the tablet is disconnected from the PC and then reconnected.

i dont have this tablet but another hot pepper device called the poblano. with that i was able to boot into ffbm from the bootloader and have root adb access. then i ran dd on my boot partition and patched it with magisk and flashed it back
wondering if hot pepper still makes their devices like that or they patched it. either way props to you for getting the fw straight from the oem

luridphantom said:
i dont have this tablet but another hot pepper device called the poblano. with that i was able to boot into ffbm from the bootloader and have root adb access. then i ran dd on my boot partition and patched it with magisk and flashed it back
wondering if hot pepper still makes their devices like that or they patched it. either way props to you for getting the fw straight from the oem
Click to expand...
Click to collapse
The Scepter 8 does not ship with adb root shell (adbd) enabled. In fact, the bootloader was not even intended to be unlocked. The unlock command is disabled in standard fastboot mode. Luckily, the Scepter 8 is integrated with a second fallback fastboot mode, which we were able to use to to the oem unlock.
Many AllWinner tablets and other Chinese devices do, as you pointed out on your Hot Pepper device. When the Scepter 8 was first released I was able to pull a boot image using a Phoenix Suite tool that had been reverse engineered and modded. As luck would have it, I got rid of the tablet and lost my files along with access to the Phoenix Suite tool. So I've been weeks quarreling with Hot Pepper Mobile to provide firmware and the kernel source code. To their credit, the Hot Pepper CEO and support team were very helpful once they understood what I needed. Hot Pepper's software developers are in China, so a language translation issue hindered my request for some time.
Anyway thank you for your kind words and it is a pleasure making your acquaintance.

@64Star I have updated the thread above with some detailed instructions on updating your device drivers. Hope this helps.

Viva La Android said:
@64Star I have updated the thread above with some detailed instructions on updating your device drivers. Hope this helps.
Click to expand...
Click to collapse
It does, I've unlocked the bootloader and now i'm gonna go root it. Thanks for your help!

I have an unfortunate update: When I went to turn on my tablet, I've noticed there was a noticeable crack on the top left corner of the screen... and then when I tried to use it... the touchscreen no longer functions. I have no clue where that crack came from, cause that wasn't there yesterday, and I've kept it safe in a drawer until now, so I have no clue how it's possible. Guess the software isn't the only thing that's cheap, cause my 2020 Moto G Power survived way worse without even a single crack.
TL,DR: Touch screen somehow broke overnight, meaning I can't get past the setup screen, so GG no re, this $10 qlink tablet ****ing sucks.

64Star said:
I have an unfortunate update: When I went to turn on my tablet, I've noticed there was a noticeable crack on the top left corner of the screen... and then when I tried to use it... the touchscreen no longer functions. I have no clue where that crack came from, cause that wasn't there yesterday, and I've kept it safe in a drawer until now, so I have no clue how it's possible. Guess the software isn't the only thing that's cheap, cause my 2020 Moto G Power survived way worse without even a single crack.
TL,DR: Touch screen somehow broke overnight, meaning I can't get past the setup screen, so GG no re, this $10 qlink tablet ****ing sucks.
Click to expand...
Click to collapse
@64Star I hate to hear that but I know exactly how it goes. I've cracked many a screen in my day. But, on a positive note, if you have the extra funds, there are a ton of these tablets available on eBay within the $35 to $40 price range.

Viva La Android said:
@64Star I hate to hear that but I know exactly how it goes. I've cracked many a screen in my day. But, on a positive note, if you have the extra funds, there are a ton of these tablets available on eBay within the $35 to $40 price range.
Click to expand...
Click to collapse
LOL really turning a profit!

13lack13ox said:
LOL really turning a profit!
Click to expand...
Click to collapse
Haha. No doubt

Sorry about the delay on TWRP guys. My mounting issues are actually encryption issues. TWRP isn't decrypting the /userdata or /vendor partitions with the default key. I'm going to chat with one of my friends over at TeamWin and see if I can get a little guidance.

Viva La Android said:
@64Star I hate to hear that but I know exactly how it goes. I've cracked many a screen in my day. But, on a positive note, if you have the extra funds, there are a ton of these tablets available on eBay within the $35 to $40 price range.
Click to expand...
Click to collapse
You really expect me to shell out around 35$ to 40$ on a slow, laggy 10$ tablet just to experiment on? Hahahahahaha....
Spoiler
Perhaps

64Star said:
You really expect me to shell out around 35$ to 40$ on a slow, laggy 10$ tablet just to experiment on? Hahahahahaha....
Spoiler
Perhaps
Click to expand...
Click to collapse
Not really. I was only providing you info as to where they were available. I found one for $19 which is more than I really wanted to give.
As it stands now,.all the lag is gone in mine. I debloated everything that wasn't essential for normal operations. Then I edited the system/build.prop to increase responsiveness and I limited background apps & processes. Finally, I installed a kernel tuner and set the LMK to very aggressive, tweaked the I/o scheduler parameters, and increased entropy from the available pool. And set SELinux to permissive mode. I'm using Nova Launcher Premium with the launcher locked into memory. Believe it or not, the tablet is now very responsive considering the specs. I'm looking into overclocking the CPU a bit, but 1.46 GHz seems to suffice once RAM is optimized. It's a difference in night and day. It's good for a project tablet but that's about it.
There's another government tablet floating around called the Maxwest Nitro 7Q. 4G/LTE supported with a lot better specs. I think I have one located to buy for cheap.

Lots of tweaks it doesnt run too bad just removing bloatware. Would be cool to get your params on your tweaks etc. If you ever got time could you post it up? Maybe the rom you were talking about in another post has all that included? Anyways if not no biggie, this thing is just for playing around on.

13lack13ox said:
Lots of tweaks it doesnt run too bad just removing bloatware. Would be cool to get your params on your tweaks etc. If you ever got time could you post it up? Maybe the rom you were talking about in another post has all that included? Anyways if not no biggie, this thing is just for playing around on.
Click to expand...
Click to collapse
Absolutely. I'll list those for you here in just a little bit. I have a pure stock ROM built with a TWRP installer, but my TWRP has run into a snag. I've reached out to TeamWin for guidance on that.

All in good time, man. Just glad someone with knowledge is doing all this. Wish I could help more. My ability to program and compile is equivalent to stick poking. I've done it once with aosp 6 that was awhile ago.

13lack13ox said:
All in good time, man. Just glad someone with knowledge is doing all this. Wish I could help more. My ability to program and compile is equivalent to stick poking. I've done it once with aosp 6 that was awhile ago.
Click to expand...
Click to collapse
You seem to know your way around the Android OS pretty well. I'm a developer in training myself. Learning every day. Yeah AOSP 6, I still love working with the Marshmallow builds.
Ok first things first. I notice a huge performance boost from some kernel level mods. Here is a link to Kernel Toolkit. Install both APKs. https://mega.nz/folder/QYwA0QTA#O_Zg3h_iVkHOdeyU_yOmLw
First go to the CPU heading and change the scaling governor to Ondemand. Under CPU Governor Params, tap on Performance Profile and select Maximum Performance (you may personally want to scale back to Aggressive or Balanced, depending on your need for battery life). Now, close Kernel Toolkit and restart the app. Next go to the I/O heading. Choose kyber as the I/o scheduler and set the read ahead buffer to 512 KB. Go down to ZRAM and increase to the maximum of 1000 MB. Set Swappiness to 100. Go over to the Profiles heading, create a profile will all settings and give it a name recommended from the list. When complete, tap on the profile, select save settings and then apply settings.
Now go to the menu button in the upper left of the app. Go down and enable Apply Settings on Boot. Select All and set a 5 second delay.
Next, download a build.prop editor from Play Store. There are tons of free ones and any will suffice. Make a backup of your system/build.prop before you tweak anything. Open the editor and grant root permission.
For build.prop edits, locking your launcher into memory helps a lot with responsiveness. Add this line to system/build.prop
ro.HOME_APP_ADJ=1
This basically prevents the launcher from being killed by Android's native LMK.
To increase touch responsiveness, add these lines as well.
debug.performance.tuning=1
video.accelerate.hw=1
Disable the boot animation for faster boot time.
debug.sf.nobootanimation=1
Reboot to enable the tweaks.
Give these a try and let me know your feedback. I'm working on a few more mods to optimize this tablet and I'll keep you posted on those as well.

Thx great changes so far. Yeah more "snappyness" for sure. I'll have to play around and open up as much as i can swap around.
I can't change I/O scheduler though, I get a contact developer message.

13lack13ox said:
Thx great changes so far.
Click to expand...
Click to collapse
Yw. Do you notice a decent improvement?

[ROOT][GUIDE] Hyundai 7" HyTab Plus (7LB1) 4G-LTE Tablet Bootloader Unlocking & Rooting Guide

Hyundai 7" HyTab Plus
4G-LTE Android Tablet
Model No. 7LB1
{
"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"
}
Bootloader Unlocking
& Rooting Guide​OVERVIEW:
The Hyundai HyTab Plus (7LB1) is a budget 7" tablet with 4G-LTE support, manufactured by Hyundai Technology. This tablet not only supports 4G-LTE cellular data connectivity, but is also a fully functional smartphone, with integrated Radio Interface Layer (RIL) and telephony capabilities. The sister tablet to the 7LB1 is the WiFi-only HyTab Plus 7WB1. Due to substantial hardware and firmware variations between these two models, the procedures for unlocking the bootloader and achieving root access of the Android OS will be outlined in two separate guides.
SPECIFICATIONS:
• Name: Hyundai HyTab Plus 7
• Model/SKU: HT7LB1PBKNA
• Chipset: MediaTek MT6739
• CPU: Quad-core ARM Cortex-A53
• Architecture: 32-bit
• Instruction Sets: armeabi-v7a
• Lithography: 28 nm
• CPU Max Clock: 1.5 GHz
• GPU: IMG PowerVR Rogue GE8100
• GPU Max Clock: 570 MHz
• WLAN: 802.11b/g/n/ac
• Bluetooth Version: 4.2 (Low Energy)
• LTE Modem: Cat-4 DL / Cat-5 UL
• LTE Bands: 2, 4, 5, 7, 12, 14, 17, 66, 71
• Cell Tech: : GSM, WCDMA, TD-SCDMA, VoLTE, EDGE, FDD/TDD, LTE-A
• GPS: Glonass, QZSS
• Internal Storage: 32 GB eMMC 5.1 (26.4 GB Useable)
• Ext. Storage: micro SD Slot ~ 1 TB
• RAM: 2 GB LPDDR3 (667 MHz)
• Display: 7" IPS / 1024 x 600 / 240 dpi
• Aspect Ratio: 17:10
• Cameras: 5MP Main / 2MP Front
• I/O Port: USB Type-C
• Partition Scheme: Dynamic/Non-A/B
• Battery: 2,400 mAh Li-Ion
• Project Treble: Supported
FIRMWARE INFO:
• OS/Version: Android 10 (Go Edition)
• Build No. full_tb8765ap1_bsp_1g-user.
202009191923 release-keys
• Android Build ID: QP1A.190711.020
• Radio: MOLY.LR12A.R2.MP.V135.8
• Bootloader: tb8765ap1_bsp_1g-
98d83e7--2020091923253
• Kernel Version: Linux 4.14.141
• Security Patch Level: June 5, 2020
• API Level: 29
• Build Date: September 19, 2020
NOTE: The above-referenced firmware info corresponds to the most current build available for this tablet, and likewise corresponds to the build from which the patched boot image (linked in the downloads section below) originated.
DISCLAIMER:
Unlocking the bootloader and attaining root access of the Android OS are both procedures which modify the device from its stock factory configuration. This will void your warranty. Moreover, these procedures are inherently risky to the overall integrity and operability of your tablet. It is possible, for instance, to render your device completely inoperable by botching these tasks. By proceeding further, you are assuming sole responsibility for the operability, integrity and performance of your tablet. This procedure has been fully tested and confirmed viable. Follow the steps carefully, employ patience, and things should go smoothly. Nonetheless, you have been informed of the risks. In the unfortunate event you brick your device, encounter a boot loop, or otherwise corrupt the firmware, I will provide support -- to the best of my ability -- to aide you in restoring your tablet to its factory stock state.
IMPORTANT NOTE: With the release of Android 10, a new implementation of fastboot mode was introduced, known as FastbootD, or Dynamic Fastboot. This implementation of fastboot has been relocated from the bootloader to userspace, enabling the flashing code to persist in a maintainable and testable common location, with only the vendor-specific components of fastboot implemented by a hardware abstraction layer (HAL). The sole purpose of dynamic fastboot mode is grounded in support for the dynamic partitioning scheme; added fastboot commands allow for the deleting, resizing and creating of logical partitions. However, FastbootD cannot be utilized to unlock a mobile device's bootloader. This operation must still be handled by way of traditional fastboot mode. For purposes of this guide, this will be referenced as legacy fastboot mode. Thus, FastbootD does not replace legacy fastboot mode. Rather, on devices which use the dynamic partition scheme, dynamic fastboot (FastbootD) and legacy fastboot coexist. The Hyundai HyTab Plus 7" (7LB1) is one such device. Accordingly, in the instructions below (especially for bootloader unlocking), it is imperative that you are using legacy fastboot mode, and not FastbootD. Follow the instructions closely in this regard.
REQUIREMENTS:
Both procedures outlined in this guide require a PC or laptop running on Windows 7/8.1/10/11. A Linux or Mac machine may also be used to carry out these tasks; however, for purposes of this guide, we will be focusing on a Windows-based setup. Next, ensure that your Hyundai 7" HyTab Plus has a model number of 7LB1, as this guide is model specific. This tablet integrates major hardware and firmware differences in contrast to the 7WB1 WiFi only model.
You will need to install the ADB, Fastboot & USB device drivers on your computer as well. I have provided a link below for the 15-Secomd ADB Installer, which will install and configure each of these drivers. Also, you will need the factory supplied, or a quality equivalent USB Type-C to USB Type-A data syncing/charging cable. Any additional files needed for this guide have been provided in the downloads section below.
I. SETTING UP ADB & FASTBOOT:
Configuring the ADB & Fastboot tools, as well as installing the correct USB device drivers, is tantamount to successfully completing the procedures outlined in this guide. This section sets out detailed instructions for properly setting up these prerequisites. If you have previously completed these tasks, simply skip down to the next section on unlocking the bootloader. Otherwise, let us begin.
IMPORTANT NOTE: This section entails the installation of unsigned drivers on your Windows PC or laptop. If you are running Windows 11, or a 64-bit build of Windows 8.1 or 10, your system will block the installation of unsigned drivers by default. In order to install the drivers, you will need to first disable the signature enforcement feature. Follow either of the two methods in this tutorial, then return to this section.
Disabling Driver Signature Enforcement​
Download the 15-Second ADB Installer from the link below and extract the contents of the archive to your desktop or to another convenient directory;​
Right click the .exe installer and opt to run the application as an administrator;​
Select Y(es) when prompted to install ADB & Fastboot and hit Enter;​
Select Y(es) when prompted to install ADB system-wide, then hit Enter;​
Select Y(es) once again when prompted to install device drivers; press Enter. A Device Driver Installation Wizard window will be launched. Select Next to proceed. The Google USB device driver will be installed on your computer. If you receive a warning that the driver is unsigned, simply choose the option to install anyway.​
Once complete, you will be notified that the drivers were successfully installed on your computer. Select Finish. ​
II. UNLOCKING THE BOOTLOADER
This step is a mandatory prerequisite to rooting your tablet. If you have already unlocked your tablet's bootloader, skip down to the next section on rooting your device.
WARNING: Unlocking your bootloader will trigger a native Android security feature that forces your device into a factory data reset, fully wiping all user data from the tablet. Before proceeding, make a backup of any files and media that you wish to preserve. ​
Open the C-Drive directory on your computer, copy the folder labeled adb and paste it to your desktop. This step merely sets up a more convenient directory from which to utilize ADB & Fastboot;​
Boot your tablet into legacy fastboot mode. From the Android OS, ensure that USB Debugging & OEM Unlocking are enabled in the Developer Options menu. Connect your tablet to your Windows computer using a suitable data sync cable. Open a command window from your adb folder directory and execute this command:
Code:
adb reboot bootloader
​
Your display should be dark and backlit, with => FASTBOOT mode displayed in a white font at the bottom of the tablet screen;​
Check for proper fastboot device recognition by executing this command in the command window:
Code:
fastboot devices
​
If properly connected, the command window should return an alphanumeric string consistent with your device serial number, followed by the word fastboot;​
Once device recognition has been properly established, execute this command to initiate unlocking of the bootloader:
Code:
fastboot flashing unlock
​
Your tablet will now prompt you to press Volume Up to proceed with unlocking, or Volume Down to cancel the operation;​
Once the unlock has been completed, execute:
Code:
fastboot reboot
Your tablet will now initiate a mandatory factory data reset before booting into the initial setup phase of the Android OS. Your bootloader is now unlocked.​
III. ROOTING THE TABLET:
I have simplified the rooting procedure substantially by providing a boot image pre-patched for Magisk systemless root support. Once your tablet reboots following the unlocking process, complete initial setup, enable Developer Options once again, and ensure USB Debugging is toggled.​
Download the patched boot image and vbmeta.img from the links below and save both files to your adb folder;​
Boot your tablet to legacy fastboot mode using the procedure outlined in Step 2 of the previous section;​
Flash the Magisk patched boot image to the /boot partition by executing:
Code:
fastboot flash boot patched_boot.img
Next, dm-verity/verified boot needs to be disabled. Execute this command:
Code:
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
That's it. Now simply execute:
Code:
fastboot reboot
Your tablet now has the Magisk systemless root framework installed. Upon reboot into the Android OS, open the Magisk app or placeholder stub. Grant any requested permissions; follow any prompts to upgrade Magisk to the full version, and complete any steps necessary to finish setting up the root environment. To update the Magisk version when new updates are released, use the Direct Install option within the Magisk app interface.
DOWNLOADS:
15-Second ADB Installer v1.4.3
Magisk Patched Boot Image
vbmeta.img​

[GUIDE] Onn Surf 7 (1st Gen) Unbricking & Factory Firmware Restoration Guide

Onn Surf 7 (1st Gen)
Model No. 100005206
7" WiFi Android Tablet
{
"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"
}
Unbricking & Factory
Firmware Restoration Guide​
OVERVIEW:
The 1st Gen Onn Surf 7 is a 7" budget Android tablet manufactured by the Walmart owned electronics brand Onn (styled onn.). It ships with the MediaTek MT8167B chipset, which integrates an energy efficient quad-core Cortex-A35 CPU clocking at 1.3 GHz max, the Imagination PowerVR Rogue GE8300 GPU, paired with 1 GB RAM. The CPU cores are built on the 28 nm process standard. The tablet ships with Android 9 Pie (Go Edition), compiled using the armv7l (32-bit) architecture. The 7" IPS display has a resolution of 1024 x 600 @ 160 dpi (mdpi), and a 17:10 aspect ratio. This device has 16 GB internal storage (12.2 GB useable). The /userdata partition employs the f2fs file system standard, which allows for faster transfer speeds than the traditional ext4 standard. There is also a micro SD card slot for up to 1 TB additional external storage space. The Li-Ion 2100 mAh battery provides around four (4) hours of power at heavy usage, and up to seven (7) hours of juice with light to moderate usage. The main camera shoots images up to 5 MP, while the front selfie cam shoots at 2 MP.
This guide outlines detailed instructions on restoring and/or upgrading the 1st Gen Onn Surf 7 (Model No. 100005206) tablet's stock firmware. This procedure can be used to fix a tablet which is bricked, stuck in a boot loop or is otherwise unable to boot into the Android OS. This guide can likewise be used by device owners who are experiencing issues attributed to firmware corruption, those who simply wish to revert to a full stock and unmodified Android OS, or those who wish to upgrade from an older firmware build. This process will remove any system level mods, root binaries, custom kernels, recoveries, etc., reverting the Android OS and corresponding firmware to an unmodified stock state.
FIRMWARE INFO:
• OS/Version: Android 9 (Go Edition)
• Build No. PPR1.180610.011
• Build Date: September 19, 2020
• Security Patch Level: August 5, 2019
• Build Type: User
• Build Tag: release-keys
• Kernel version: Linux 4.4.146
• Custom Build: alps.mp.p0.mp6-V1.134
• API Level: 28
• Partition Scheme: GPT Legacy
PREREQUISITES: ​
A PC or laptop running on Windows 7/8.1/10/11;​
The SP Flash Tool firmware flashing software (link provided below);​
A factory firmware package for the Onn Surf 7 tablet (link provided below);​
The vCom MediaTek USB drivers installed on your Windows computer (link provided below);​
The factory supplied or a quality equivalent micro USB to USB-A data syncing cable.​
MEDIATEK vCOM USB DRIVERS:
The most common obstacle many members encounter when using the SP Flash Tool is related to device recognition. The SP Flash Tool software flashes firmware directly to the NAND/eMMC whilst the mobile device is in BROM flash mode. In other words, the flash tool is interacting directly with the MediaTek chipset during the flashing process. The user merely needs to connect the powered off mobile device to the PC or laptop using an adequate USB data syncing cable. SP Flash Tool, in turn, will initiate BROM flash mode on the mobile device and commence with the firmware restoration process. In order for your device to be properly recognized in this regard, it is crucial that the MediaTek vCom USB drivers are properly installed and configured on your Windows computer. While I will not be outlining step-by-step instructions here on installing these drivers, I have provided a link in the downloads section below for a comprehensive guide on properly installing and configuring the vCom USB drivers on your Windows machine. Once you have completed this crucial task, you may proceed with this guide. Be sure and thank the OP of that guide, @skeleton1911, if you use his work.
DISCLAIMER
This guide involves flashing the eMMC internal storage device of your tablet with a factory firmware package, thus fully restoring your tablet to its stock factory condition. The procedure outlined below is inherently risky to the overall integrity and operability of your tablet. Failure to follow the instructions properly can, for instance, render your device completely inoperable. By proceeding further, you are assuming sole responsibility for the integrity and operability of your tablet. I have fully tested this procedure on my own device. Follow the instructions carefully, employ patience, and things should go smoothly. I am not responsible if you brick or otherwise damage your tablet. Moreover, it should be emphasized that this guide is for Model 100005206 (1st Gen) only. The factory firmware package for this model is not compatible with newer generation models of the Onn Surf 7 tablet. ​
INSTRUCTIONS
This section presumes that you have properly installed & configured the latest MediaTek vCom USB drivers on your Windows PC or laptop. Again, I have linked a guide for installing these drivers in the downloads section below. Your bootloader does not need to be in an unlocked state. However, this procedure may relock your bootloader if it is presently in an unlocked state.
WARNING: This procedure will erase all saved user data from your device. Before proceeding, make a backup of any files, media or data that you wish to preserve.​
Download the Onn Surf 7 factory firmware package from the link below and extract the contents of the archive to a folder on your computer desktop, or to a folder in another convenient directory;​
Download SP Flash Tool v5.1924 from the link below and extract the archive to your desktop, or to another easily accessible directory;​
Ensure that your tablet is powered off and is not connected to your PC or laptop;. Likewise, ensure that there are no other mobile devices or USB storage devices connected to your computer;​
Open the SP Flash Tool folder that you extracted in Step 2. Click on flash_tool.exe, then right click and choose to Run as Administrator;​
Ensure that the pull-down menu, located near the mid-left region of the interface, is set to Download only. Next, click on the Choose folder icon, located to the right of the Scatter-loading file heading.​
A file explorer will be launched. Navigate to the saved location of the firmware you extracted in the first step. In the firmware directory, select MT8167_Android_scatter.txt, and then click Open;​
The SP Flash Tool will now load the factory firmware package. A violet-colored progress bar near the bottom of the interface will reflect the completion status.​
Once the firmware has been loaded, connect the USB-A end of the data syncing cable to your PC or laptop. Click the Download box located near the upper-left region of the interface;​
Now, connect the micro USB end of the data sync cable to your tablet. If the vCom drivers are properly installed and configured on your PC or laptop, SP Flash Tool will recognize your device and initiate firmware installation via BROM flash mode. A yellow progress bar located near the bottom of the interface will reflect the percentage of completion. Once completed, you will receive a notification that the procedure was successful.​
Disconnect your tablet and use the power key to boot the device. Your Onn Surf 7 should be fully restored to it's stock factory state and running on the most recent firmware build available.​
DOWNLOADS:​
SP Flash Tool v5.1924​
Factory Firmware for Onn Surf 7​
vCOM Drivers Installation Guide​
THANKS & MENTIONS:
I would like to take a moment to thank @skeleton1911 for his comprehensive tutorial on properly installing MediaTek vCom USB drivers on Windows 10 & 11. I would ask any members who use that tutorial to give the OP thanks.​

Viva La Android said:
Onn Surf 7 (1st Gen)
Model No. 100005206
7" WiFi Android Tablet
View attachment 5799181
Stock Firmware Restoration
And Upgrading Guide ​
OVERVIEW:
The 1st Gen Onn Surf 7 is a 7" budget tablet manufactured by the Walmart owned electronics brand Onn (styled onn.). It ships with the MediaTek MT8167B chipset, which integrates an energy efficient quad-core Cortex-A35 CPU clocking at 1.3 GHz max, the Imagination PowerVR Rogue GE8300 GPU, paired with 1 GB RAM. The processor cores are built on the 28 nm process standard. The tablet ships with Android 9 Pie (Go Edition), compiled using the armv7l (32-bit) architecture. The 7" IPS display has a resolution of 1024 x 600 @ 160 dpi (mdpi), and a 17:10 aspect ratio. This device has 16 GB internal storage (12.2 GB useable). The /userdata partition employs the f2fs file system standard, which allows for faster transfer speeds than the traditional ext4 standard. There is also a micro SD card slot for up to 1 TB additional external storage space. The Li-Ion 2100 mAh battery provides around four (4) hours of power at heavy usage, and up to seven (7) hours of juice with light to moderate usage. The main camera shoots images up to 5 MP, while the front selfie cam shoots at 2 MP.
This guide outlines detailed instructions on restoring and/or upgrading the 1st Gen Onn Surf 7 (Model No. 100005206) tablet's stock firmware. This procedure can be used to fix a tablet which is bricked, stuck in a boot loop or is otherwise unable to boot into the Android OS. This guide can likewise be used by device owners who are experiencing issues attributed to firmware corruption, those who simply wish to revert to a full stock and unmodified Android OS, or those who wish to upgrade from an older firmware build. This process will remove any system level mods, root binaries, custom kernels, recoveries, etc., as well as lock the bootloader if it is in an unlocked state.
FIRMWARE INFO:
• OS/Version: Android 9 (Go Edition)
• Build No. PPR1.180610.011
• Build Date: September 19, 2020
• Security Patch Level: August 5, 2019
• Build Type: User
• Build Tag: release-keys
• Kernel version: Linux 4.4.146
• Custom Build: alps.mp.p0.mp6-V1.134
• API Level: 28
• Partition Scheme: GPT Legacy
PREREQUISITES: ​
A PC or laptop running on Windows 7/8.1/10/11;​
The SP Flash Tool firmware flashing software (link provided below);​
A factory firmware package for the Onn Surf 7 tablet (link provided below);​
The vCom MediaTek USB drivers installed on your Windows computer (link provided below);​
The factory supplied or a quality equivalent micro USB to USB-A data syncing cable.​
MEDIATEK vCOM USB DRIVERS:
The most common obstacle many members encounter when using the SP Flash Tool is related to device recognition. The SP Flash Tool software flashes firmware directly to the NAND/eMMC whilst the mobile device is in BROM flash mode. In other words, the flash tool is interacting directly with the MediaTek chipset during the flashing process. The user merely needs to connect the powered off mobile device to the PC or laptop using an adequate USB data syncing cable. SP Flash Tool, in turn, will initiate BROM flash mode on the mobile device and commence with the firmware restoration process. In order for your device to be properly recognized in this regard, it is crucial that the MediaTek vCom USB drivers are properly installed and configured on your Windows computer. While I will not be outlining step-by-step instructions here on installing these drivers, I have provided a link in the downloads section below for a comprehensive guide on properly installing and configuring the vCom USB drivers on your Windows machine. Once you have completed this crucial task, you may proceed with this guide. Be sure and thank the OP of that guide, @skeleton1911, if you use his work.
DISCLAIMER
This guide involves flashing the eMMC internal storage device of your tablet with a factory firmware package, thus fully restoring your tablet to its stock factory condition. The procedure outlined below is inherently risky to the overall integrity and operability of your tablet. Failure to follow the instructions properly can, for instance, render your device completely inoperable. By proceeding further, you are assuming sole responsibility for the integrity and operability of your tablet. I have fully tested this procedure on my own device. Follow the instructions carefully, employ patience, and things should go smoothly. I am not responsible if you brick or otherwise damage your tablet. Moreover, it should be emphasized that this guide is for Model 100005206 (1st Gen) only. The factory firmware package for this model is not compatible with newer generation models of the Onn Surf 7 tablet. ​View attachment 5741703​
INSTRUCTIONS
This section presumes that you have properly installed & configured the latest MediaTek vCom USB drivers on your Windows PC or laptop. Again, I have linked a guide for installing these drivers in the downloads section below. Your bootloader does not need to be in an unlocked state. However, this procedure will relock your bootloader if it is presently in an unlocked state.
WARNING: This procedure will erase all saved user data from your device. Before proceeding, make a backup of any files, media or data that you wish to preserve.​
Download the Onn Surf 7 factory firmware package from the link below and extract the contents of the archive to a folder on your computer desktop, or to a folder in another convenient directory;​
Download SP Flash Tool v5.1924 from the link below and extract the archive to your desktop, or to another easily accessible directory;​
Ensure that your tablet is powered off and is not connected to your PC or laptop;. Likewise, ensure that there are no other mobile devices or USB storage devices connected to your computer;​
Open the SP Flash Tool folder that you extracted in Step 2. Click on flash_tool.exe, then right click and choose to Run as Administrator;​
Ensure that the pull-down menu, located near the mid-left region of the interface, is set to Download only. Next, click on the Choose folder icon, located to the right of the Scatter-loading file heading.​
A file explorer will be launched. Navigate to the saved location of the firmware you extracted in the first step. In the firmware directory, select MT8167_Android_scatter.txt, and then click Open;​
The SP Flash Tool will now load the factory firmware package. A violet-colored progress bar near the bottom of the interface will reflect the completion status.​
Once the firmware has been loaded, connect the USB-A end of the data syncing cable to your PC or laptop. Click the Download box located near the upper-left region of the interface;​
Now, connect the micro USB end of the data sync cable to your tablet. If the vCom drivers are properly installed and configured on your PC or laptop, SP Flash Tool will recognize your device and initiate firmware installation via BROM flash mode. A yellow progress bar located near the bottom of the interface will reflect the percentage of completion. Once completed, you will receive a notification that the procedure was successful.​
Disconnect your tablet and use the power key to boot the device. Your Onn Surf 7 should be fully restored to it's stock factory state and running on the most recent firmware build available.​
DOWNLOADS:​
SP Flash Tool v5.1924​
Factory Firmware for Onn Surf 7​
vCOM Drivers Installation Guide​
THANKS & MENTIONS:
I would like to take a moment to thank @skeleton1911 for his comprehensive tutorial on properly installing MediaTek vCom USB drivers on Windows 10 & 11. I would ask any members who use that tutorial to give the OP thanks.​
Click to expand...
Click to collapse
Is this a personal pulled from tablet firmware ? Or did you locate a factory firmware pkg ?

tek3195 said:
Is this a personal pulled from tablet firmware ? Or did you locate a factory firmware pkg ?
Click to expand...
Click to collapse
This is Onn factory firmware. Fully stock.

Viva La Android said:
This is Onn factory firmware. Fully stock.
Click to expand...
Click to collapse
Ok, where did you get it ?

tek3195 said:
Ok, where did you get it ?
Click to expand...
Click to collapse
It's from Onn's software support server. This isn't a dump or a homemade package. The firmware is directly from Onn. Where I got it has no relevance to the firmware's origin. Even if I'd got the file at a firmware repo, this would not change anything.
For future reference, if a thread is titled with the term factory firmware, the package originated from the manufacturer. Otherwise, the firmware will be referenced as a partition dump, firmware pull, partition images, or another similar name. The fact that it's called factory firmware infers where the package came from.

Viva La Android said:
Your thread may be titled correctly but not everyone does that. We have looked for Onn firmware for a few years now so I was wondering if you had found a site to download from. If you have it would be nice to share it. If you are getting from OTA then not factory firmware. You could be a little more forthcoming about source, and a little less with the attitude.
Click to expand...
Click to collapse

Attitude is a good thing. It encourages people to read plain print, comprehend basic grammatical structure, etc As far as source, I share all of my sources. Check any of my dozens of device threads. I always specify the origin, build type, etc. As far as how I obtain factory images, that isn't the least bit relevant to the threads and, quite frankly -- and perhaps a bit attitude coated --it's not any of your business. Indeed, OTA packages and factory firmware images are not the same. You are correct, good sir. Sort of makes my point. That's why one is called OTA while the other is called factory firmware.
By the way, Onn factory firmware is all over the internet in various repos and sources. It isn't elusive by any means.
But yes, if it's called "FACTORY FIRMWARE," guess where it came from? Most members are fairly proficient with literacy and comprehension, so I'm sorry I didn't feel the need to spell that out for the other .48% of the collective member populace. Similarly, whenever I sell baseball cards on eBay, I don't emphasize that the players depicted on those cards actually play baseball. Common sense and the like. Something about the "BASEBALL CARDS" heading perhaps?
Here are a few strikingly similar analogues to emphasize the true wonder of names, headings and titles.
•From where does the Alaskan Husky originate?
•Which galactic star causes a sunburn?
•What makes ice water cold?
•For what weather conditions was a raincoat designed?
•For which food item was pancake syrup originally created?
•When was the War of 1812?

Viva La Android said:
Attitude is a good thing. It encourages people to read plain print, comprehend basic grammatical structure, etc As far as source, I share all of my sources. Check any of my dozens of device threads. I always specify the origin, build type, etc. As far as how I obtain factory images, that isn't the least bit relevant to the threads and, quite frankly -- and perhaps a bit attitude coated --it's not any of your business. Indeed, OTA packages and factory firmware images are not the same. You are correct, good sir. Sort of makes my point. That's why one is called OTA while the other is called factory firmware.
By the way, Onn factory firmware is all over the internet in various repos and sources. It isn't elusive by any means.
But yes, if it's called "FACTORY FIRMWARE," guess where it came from? Most members are fairly proficient with literacy and comprehension, so I'm sorry I didn't feel the need to spell that out for the other .48% of the collective member populace. Similarly, whenever I sell baseball cards on eBay, I don't emphasize that the players depicted on those cards actually play baseball. Common sense and the like. Something about the "BASEBALL CARDS" heading perhaps?
Here are a few strikingly similar analogues to emphasize the true wonder of names, headings and titles.
•From where does the Alaskan Husky originate?
•Which galactic star causes a sunburn?
•What makes ice water cold?
•For what weather conditions was a raincoat designed?
•For which food item was pancake syrup originally created?
•When was the War of 1812?
Click to expand...
Click to collapse
I don't know what your problem is other than trying to be a smart a s s lacking any people skills. Why you can't provide a link is beyond me. I have installed board software and factory firmware on many devices and I have not seen factory firmware with so few files before. Provide link to official Onn firmware and stop being an a s s .

tek3195 said:
I don't know what your problem is other than trying to be a smart a s s lacking any people skills. Why you can't provide a link is beyond me. I have installed board software and factory firmware on many devices and I have not seen factory firmware with so few files before. Provide link to official Onn firmware and stop being an a s s .
Click to expand...
Click to collapse
Or, my personal favorite:
What mobile operating system platform has its basis on the Android Open Source Project? Has to be iOS; what do you think? Oh come on, I'm picking on you. Don't take it to heart.
So few files? Allwinner firmware, for instance, is released as a single image -- one .img file. With MediaTek based devices, there is no set amount of individual partition images required to constitute a complete firmware package. This is entirely up to the device manufacturer. Some device makers include all key partitions as well as all sensitive partitions -- essentially, a full partition index for the device. Manufacturers like Hyundai and Motorola are known for releasing robust firmware packages that include the full partition index of images. Other device makers like RCA -- and Onn -- release only the bare minimum of images needed to restore the device to its stock factory state. For this Surf 7 model, Onn has released images for /preloader, /lk1, /lk2, /trustzone1, /trustzone2, /dtbo, /recovery, /boot, /system, /vendor, /userdata, /logo, and /cache. Those images not included in the package are classified either as INVISIBLE or REGIONALBIN; as such, these are simply not needed for restoration purposes and, thus, this is undoubtedly why they were not included in the factory package.
Keep in mind that many images included in typical factory firmware archives are.simply not necessary for firmware restoration; indeed some files are used more for development purposes.
My advice to you, if you don't trust the integrity or legitimacy of a firmware package -- including this one -- don't use it. Get a firmware package elsewhere. I don't post links to channels. Do your own legwork and procure your own contacts with support departments at various manufacturers.

Viva La Android said:
Or, my personal favorite:
What mobile operating system platform has its basis on the Android Open Source Project? Has to be iOS; what do you think? Oh come on, I'm picking on you. Don't take it to heart.
So few files? Allwinner firmware, for instance, is released as a single image -- one .img file. With MediaTek based devices, there is no set amount of individual partition images required to constitute a complete firmware package. This is entirely up to the device manufacturer. Some device makers include all key partitions as well as all sensitive partitions -- essentially, a full partition index for the device. Manufacturers like Hyundai and Motorola are known for releasing robust firmware packages that include the full partition index of images. Other device makers like RCA -- and Onn -- release only the bare minimum of images needed to restore the device to its stock factory state. For this Surf 7 model, Onn has released images for /preloader, /lk1, /lk2, /trustzone1, /trustzone2, /dtbo, /recovery, /boot, /system, /vendor, /userdata, /logo, and /cache. Those images not included in the package are classified either as INVISIBLE or REGIONALBIN; as such, these are simply not needed for restoration purposes and, thus, this is undoubtedly why they were not included in the factory package.
Keep in mind that many images included in typical factory firmware archives are.simply not necessary for firmware restoration; indeed some files are used more for development purposes.
My advice to you, if you don't trust the integrity or legitimacy of a firmware package -- including this one -- don't use it. Get a firmware package elsewhere. I don't post links to channels. Do your own legwork and procure your own contacts with support departments at various manufacturers.
Click to expand...
Click to collapse
You are right, I guess in my mind I was seeing board software from Huawei. I wasn't thinking about Amazon .bin file or Huawei update.app either. As for legwork it's been a while since I looked hard for Onn firmware. When I first posted how to root the 8" model I was sending email to the company that manufactured the tablet for Onn and searching board serial numbers looking for it. Wow, that's been about 3 years ago now, time flies and things change. That is why I was curious as to where it came from with hopes of finding 8" and 10" firmware. I only had the 7" long enough to root it, post how-to and return it. The other thing I quit searching for was info on MTK's ultraflash, back then it was non-existent. I appreciate the decent reply, thank you.

tek3195 said:
You are right, I guess in my mind I was seeing board software from Huawei. I wasn't thinking about Amazon .bin file or Huawei update.app either. As for legwork it's been a while since I looked hard for Onn firmware. When I first posted how to root the 8" model I was sending email to the company that manufactured the tablet for Onn and searching board serial numbers looking for it. Wow, that's been about 3 years ago now, time flies and things change. That is why I was curious as to where it came from with hopes of finding 8" and 10" firmware. I only had the 7" long enough to root it, post how-to and return it. The other thing I quit searching for was info on MTK's ultraflash, back then it was non-existent. I appreciate the decent reply, thank you.
Click to expand...
Click to collapse
No problem friend. Perhaps I came across as being abrasive on my replies to your inquiry. I'm sorry if that's the case. Questions like yours are welcome and the ensuing discussion can be informative to other members.
I will give you a good tip on procuring factory firmware: send a professionally worded email to the support department of the device manufacturer. Let them know you need the firmware as a means to restore your own device, as well as for potential custom development projects here at XDA. Most manufacturers know that XDA is the largest custom Android dev community on the planet. As such, they realize that XDA is a great platform for giving exposure to particular devices, which increases overall sales. Anyway, word your email to infer this scenario. Once you get a firmware package for a particular device, make efforts to thank and give credit to the support representative who helped you. Email the representative's supervisor to give positive feedback on the person. Oftentimes, that individual will then freely assist you with future firmware requests, requests for kernel source code, etc. You will progressively gain some valuable contacts among various manufacturers for obtaining factory images.

Viva La Android said:
Onn's software support server
Click to expand...
Click to collapse
Viva La Android said:
Onn Surf 7 (1st Gen)
Model No. 100005206
7" WiFi Android Tablet
View attachment 5803029
Stock Firmware Restoration
And Upgrading Guide ​
OVERVIEW:
The 1st Gen Onn Surf 7 is a 7" budget tablet manufactured by the Walmart owned electronics brand Onn (styled onn.). It ships with the MediaTek MT8167B chipset, which integrates an energy efficient quad-core Cortex-A35 CPU clocking at 1.3 GHz max, the Imagination PowerVR Rogue GE8300 GPU, paired with 1 GB RAM. The CPU cores are built on the 28 nm process standard. The tablet ships with Android 9 Pie (Go Edition), compiled using the armv7l (32-bit) architecture. The 7" IPS display has a resolution of 1024 x 600 @ 160 dpi (mdpi), and a 17:10 aspect ratio. This device has 16 GB internal storage (12.2 GB useable). The /userdata partition employs the f2fs file system standard, which allows for faster transfer speeds than the traditional ext4 standard. There is also a micro SD card slot for up to 1 TB additional external storage space. The Li-Ion 2100 mAh battery provides around four (4) hours of power at heavy usage, and up to seven (7) hours of juice with light to moderate usage. The main camera shoots images up to 5 MP, while the front selfie cam shoots at 2 MP.
This guide outlines detailed instructions on restoring and/or upgrading the 1st Gen Onn Surf 7 (Model No. 100005206) tablet's stock firmware. This procedure can be used to fix a tablet which is bricked, stuck in a boot loop or is otherwise unable to boot into the Android OS. This guide can likewise be used by device owners who are experiencing issues attributed to firmware corruption, those who simply wish to revert to a full stock and unmodified Android OS, or those who wish to upgrade from an older firmware build. This process will remove any system level mods, root binaries, custom kernels, recoveries, etc., as well as lock the bootloader if it is in an unlocked state.
FIRMWARE INFO:
• OS/Version: Android 9 (Go Edition)
• Build No. PPR1.180610.011
• Build Date: September 19, 2020
• Security Patch Level: August 5, 2019
• Build Type: User
• Build Tag: release-keys
• Kernel version: Linux 4.4.146
• Custom Build: alps.mp.p0.mp6-V1.134
• API Level: 28
• Partition Scheme: GPT Legacy
PREREQUISITES: ​
A PC or laptop running on Windows 7/8.1/10/11;​
The SP Flash Tool firmware flashing software (link provided below);​
A factory firmware package for the Onn Surf 7 tablet (link provided below);​
The vCom MediaTek USB drivers installed on your Windows computer (link provided below);​
The factory supplied or a quality equivalent micro USB to USB-A data syncing cable.​
MEDIATEK vCOM USB DRIVERS:
The most common obstacle many members encounter when using the SP Flash Tool is related to device recognition. The SP Flash Tool software flashes firmware directly to the NAND/eMMC whilst the mobile device is in BROM flash mode. In other words, the flash tool is interacting directly with the MediaTek chipset during the flashing process. The user merely needs to connect the powered off mobile device to the PC or laptop using an adequate USB data syncing cable. SP Flash Tool, in turn, will initiate BROM flash mode on the mobile device and commence with the firmware restoration process. In order for your device to be properly recognized in this regard, it is crucial that the MediaTek vCom USB drivers are properly installed and configured on your Windows computer. While I will not be outlining step-by-step instructions here on installing these drivers, I have provided a link in the downloads section below for a comprehensive guide on properly installing and configuring the vCom USB drivers on your Windows machine. Once you have completed this crucial task, you may proceed with this guide. Be sure and thank the OP of that guide, @skeleton1911, if you use his work.
DISCLAIMER
This guide involves flashing the eMMC internal storage device of your tablet with a factory firmware package, thus fully restoring your tablet to its stock factory condition. The procedure outlined below is inherently risky to the overall integrity and operability of your tablet. Failure to follow the instructions properly can, for instance, render your device completely inoperable. By proceeding further, you are assuming sole responsibility for the integrity and operability of your tablet. I have fully tested this procedure on my own device. Follow the instructions carefully, employ patience, and things should go smoothly. I am not responsible if you brick or otherwise damage your tablet. Moreover, it should be emphasized that this guide is for Model 100005206 (1st Gen) only. The factory firmware package for this model is not compatible with newer generation models of the Onn Surf 7 tablet. ​View attachment 5741703​
INSTRUCTIONS
This section presumes that you have properly installed & configured the latest MediaTek vCom USB drivers on your Windows PC or laptop. Again, I have linked a guide for installing these drivers in the downloads section below. Your bootloader does not need to be in an unlocked state. However, this procedure will relock your bootloader if it is presently in an unlocked state.
WARNING: This procedure will erase all saved user data from your device. Before proceeding, make a backup of any files, media or data that you wish to preserve.​
Download the Onn Surf 7 factory firmware package from the link below and extract the contents of the archive to a folder on your computer desktop, or to a folder in another convenient directory;​
Download SP Flash Tool v5.1924 from the link below and extract the archive to your desktop, or to another easily accessible directory;​
Ensure that your tablet is powered off and is not connected to your PC or laptop;. Likewise, ensure that there are no other mobile devices or USB storage devices connected to your computer;​
Open the SP Flash Tool folder that you extracted in Step 2. Click on flash_tool.exe, then right click and choose to Run as Administrator;​
Ensure that the pull-down menu, located near the mid-left region of the interface, is set to Download only. Next, click on the Choose folder icon, located to the right of the Scatter-loading file heading.​
A file explorer will be launched. Navigate to the saved location of the firmware you extracted in the first step. In the firmware directory, select MT8167_Android_scatter.txt, and then click Open;​
The SP Flash Tool will now load the factory firmware package. A violet-colored progress bar near the bottom of the interface will reflect the completion status.​
Once the firmware has been loaded, connect the USB-A end of the data syncing cable to your PC or laptop. Click the Download box located near the upper-left region of the interface;​
Now, connect the micro USB end of the data sync cable to your tablet. If the vCom drivers are properly installed and configured on your PC or laptop, SP Flash Tool will recognize your device and initiate firmware installation via BROM flash mode. A yellow progress bar located near the bottom of the interface will reflect the percentage of completion. Once completed, you will receive a notification that the procedure was successful.​
Disconnect your tablet and use the power key to boot the device. Your Onn Surf 7 should be fully restored to it's stock factory state and running on the most recent firmware build available.​
DOWNLOADS:​
SP Flash Tool v5.1924​
Factory Firmware for Onn Surf 7​
vCOM Drivers Installation Guide​
THANKS & MENTIONS:
I would like to take a moment to thank @skeleton1911 for his comprehensive tutorial on properly installing MediaTek vCom USB drivers on Windows 10 & 11. I would ask any members who use that tutorial to give the OP thanks.​
Click to expand...
Click to collapse
What mediatek does the ONN 7 Gen 3 ships with

Jfuchs2007 said:
What mediatek does the ONN 7 Gen 3 ships with
Click to expand...
Click to collapse
The Gen 3 appears to have the MediaTek Helio A22 (mt6761v), accordubg to FCC cert records. But don't quote me on that. The exact specs for the Gen 3 are a bit obscure for some reason.

Viva La Android said:
Onn Surf 7 (1st Gen)
Model No. 100005206
7" WiFi Android Tablet
View attachment 5907727
Unbricking & Factory
Firmware Restoration Guide​
OVERVIEW:
The 1st Gen Onn Surf 7 is a 7" budget Android tablet manufactured by the Walmart owned electronics brand Onn (styled onn.). It ships with the MediaTek MT8167B chipset, which integrates an energy efficient quad-core Cortex-A35 CPU clocking at 1.3 GHz max, the Imagination PowerVR Rogue GE8300 GPU, paired with 1 GB RAM. The CPU cores are built on the 28 nm process standard. The tablet ships with Android 9 Pie (Go Edition), compiled using the armv7l (32-bit) architecture. The 7" IPS display has a resolution of 1024 x 600 @ 160 dpi (mdpi), and a 17:10 aspect ratio. This device has 16 GB internal storage (12.2 GB useable). The /userdata partition employs the f2fs file system standard, which allows for faster transfer speeds than the traditional ext4 standard. There is also a micro SD card slot for up to 1 TB additional external storage space. The Li-Ion 2100 mAh battery provides around four (4) hours of power at heavy usage, and up to seven (7) hours of juice with light to moderate usage. The main camera shoots images up to 5 MP, while the front selfie cam shoots at 2 MP.
This guide outlines detailed instructions on restoring and/or upgrading the 1st Gen Onn Surf 7 (Model No. 100005206) tablet's stock firmware. This procedure can be used to fix a tablet which is bricked, stuck in a boot loop or is otherwise unable to boot into the Android OS. This guide can likewise be used by device owners who are experiencing issues attributed to firmware corruption, those who simply wish to revert to a full stock and unmodified Android OS, or those who wish to upgrade from an older firmware build. This process will remove any system level mods, root binaries, custom kernels, recoveries, etc., reverting the Android OS and corresponding firmware to an unmodified stock state.
FIRMWARE INFO:
• OS/Version: Android 9 (Go Edition)
• Build No. PPR1.180610.011
• Build Date: September 19, 2020
• Security Patch Level: August 5, 2019
• Build Type: User
• Build Tag: release-keys
• Kernel version: Linux 4.4.146
• Custom Build: alps.mp.p0.mp6-V1.134
• API Level: 28
• Partition Scheme: GPT Legacy
PREREQUISITES: ​
A PC or laptop running on Windows 7/8.1/10/11;​
The SP Flash Tool firmware flashing software (link provided below);​
A factory firmware package for the Onn Surf 7 tablet (link provided below);​
The vCom MediaTek USB drivers installed on your Windows computer (link provided below);​
The factory supplied or a quality equivalent micro USB to USB-A data syncing cable.​
MEDIATEK vCOM USB DRIVERS:
The most common obstacle many members encounter when using the SP Flash Tool is related to device recognition. The SP Flash Tool software flashes firmware directly to the NAND/eMMC whilst the mobile device is in BROM flash mode. In other words, the flash tool is interacting directly with the MediaTek chipset during the flashing process. The user merely needs to connect the powered off mobile device to the PC or laptop using an adequate USB data syncing cable. SP Flash Tool, in turn, will initiate BROM flash mode on the mobile device and commence with the firmware restoration process. In order for your device to be properly recognized in this regard, it is crucial that the MediaTek vCom USB drivers are properly installed and configured on your Windows computer. While I will not be outlining step-by-step instructions here on installing these drivers, I have provided a link in the downloads section below for a comprehensive guide on properly installing and configuring the vCom USB drivers on your Windows machine. Once you have completed this crucial task, you may proceed with this guide. Be sure and thank the OP of that guide, @skeleton1911, if you use his work.
DISCLAIMER
This guide involves flashing the eMMC internal storage device of your tablet with a factory firmware package, thus fully restoring your tablet to its stock factory condition. The procedure outlined below is inherently risky to the overall integrity and operability of your tablet. Failure to follow the instructions properly can, for instance, render your device completely inoperable. By proceeding further, you are assuming sole responsibility for the integrity and operability of your tablet. I have fully tested this procedure on my own device. Follow the instructions carefully, employ patience, and things should go smoothly. I am not responsible if you brick or otherwise damage your tablet. Moreover, it should be emphasized that this guide is for Model 100005206 (1st Gen) only. The factory firmware package for this model is not compatible with newer generation models of the Onn Surf 7 tablet. ​View attachment 5907731​
INSTRUCTIONS
This section presumes that you have properly installed & configured the latest MediaTek vCom USB drivers on your Windows PC or laptop. Again, I have linked a guide for installing these drivers in the downloads section below. Your bootloader does not need to be in an unlocked state. However, this procedure may relock your bootloader if it is presently in an unlocked state.
WARNING: This procedure will erase all saved user data from your device. Before proceeding, make a backup of any files, media or data that you wish to preserve.​
Download the Onn Surf 7 factory firmware package from the link below and extract the contents of the archive to a folder on your computer desktop, or to a folder in another convenient directory;​
Download SP Flash Tool v5.1924 from the link below and extract the archive to your desktop, or to another easily accessible directory;​
Ensure that your tablet is powered off and is not connected to your PC or laptop;. Likewise, ensure that there are no other mobile devices or USB storage devices connected to your computer;​
Open the SP Flash Tool folder that you extracted in Step 2. Click on flash_tool.exe, then right click and choose to Run as Administrator;​
Ensure that the pull-down menu, located near the mid-left region of the interface, is set to Download only. Next, click on the Choose folder icon, located to the right of the Scatter-loading file heading.​
A file explorer will be launched. Navigate to the saved location of the firmware you extracted in the first step. In the firmware directory, select MT8167_Android_scatter.txt, and then click Open;​
The SP Flash Tool will now load the factory firmware package. A violet-colored progress bar near the bottom of the interface will reflect the completion status.​
Once the firmware has been loaded, connect the USB-A end of the data syncing cable to your PC or laptop. Click the Download box located near the upper-left region of the interface;​
Now, connect the micro USB end of the data sync cable to your tablet. If the vCom drivers are properly installed and configured on your PC or laptop, SP Flash Tool will recognize your device and initiate firmware installation via BROM flash mode. A yellow progress bar located near the bottom of the interface will reflect the percentage of completion. Once completed, you will receive a notification that the procedure was successful.​
Disconnect your tablet and use the power key to boot the device. Your Onn Surf 7 should be fully restored to it's stock factory state and running on the most recent firmware build available.​
DOWNLOADS:​
SP Flash Tool v5.1924​
Factory Firmware for Onn Surf 7​
vCOM Drivers Installation Guide​
THANKS & MENTIONS:
I would like to take a moment to thank @skeleton1911 for his comprehensive tutorial on properly installing MediaTek vCom USB drivers on Windows 10 & 11. I would ask any members who use that tutorial to give the OP thanks.​
Click to expand...
Click to collapse
Hello. I'm not a pro, but I decided to make a tablet firmware (due to the fact that there is not enough memory), I seem to do everything as described here .. but nothing comes out. Please tell me what I'm doing wrong?

Kavsokalivit45 said:
Hello. I'm not a pro, but I decided to make a tablet firmware (due to the fact that there is not enough memory), I seem to do everything as described here .. but nothing comes out. Please tell me what I'm doing wrong?
Click to expand...
Click to collapse
I'll research the exact nature of the error you're getting. When you say you made a tablet firmware, what images did you create? I am assuming system.img, & boot.img. is this correct?
You can install firmware images using fastboot mode as well, alleviating any need for SP Flash Tool.

Viva La Android said:
Я изучу точную природу ошибки, которую вы получаете. Когда вы говорите, что делали прошивку для планшета, какие образы вы создавали? Я предполагаю, что system.img и boot.img. это верно?
Вы также можете установить образ прошивки, используя режим быстрой загрузки, что избавит вас от необходимости использовать SP Flash Tool.
Click to expand...
Click to collapse
Привет! Я использовал прошивку здесь, заводскую. Перед этим установил все необходимые программы и драйвера. Возможно, причина проблемы в том, что я удалил не ту программу, которая написана в описании установки Драйверов. Там написано, что после установки драйверов нужно удалить ''MTK USB Port''. Но к сожалению не могу понять какой удалить. Высылаю скрин, посмотрите пожалуйста, не подскажете какой удалить? Признаюсь, я не очень разбираюсь в этом деле, я даже не "любитель".. Думал, что смогу сделать все по описанию. А прошить решил потому, что памяти под видео, музыку нет вообще, хотя написано, что минимум 12 гигов из 16 должно быть свободно, а у меня только около 1 гига.

Viva La Android said:
Я изучу точную природу ошибки, которую вы получаете. Когда вы говорите, что делали прошивку для планшета, какие образы вы создавали? Я предполагаю, что system.img и boot.img. это верно?
Вы также можете установить образ прошивки, используя режим быстрой загрузки, что избавит вас от необходимости использовать SP Flash Tool.
Click to expand...
Click to collapse
Извините, не подскажете, как прошить в режиме Fastboot?

Kavsokalivit45 said:
Извините, не подскажете, как прошить в режиме Fastboot?
Click to expand...
Click to collapse
Please post using English. Your previous two posts were composed -- I'm presuming in your native language. I will try to use a translation tool and decipher your posts. The mods here on XDA wil delete any posts or replies which are not in English.

@Kavsokalivit45, I translated your question. Okay, fastboot mode can be used to flash a firmware image file (.img, .fex, .bin, .mbn, etc.) to a specific partition on your mobile device (/boot, recovery, /vendor, /system, /secro, etc.). The following fastboot command reflects that the boot partition is being flashed by a boot.img file.
Code:
fastboot flash boot boot.img
Note that all flashing commands will begin with the word fastboot, followed by the word flash. The next value is represented by the mounting name of the partition to be flashed...in the above example the partition is boot. Lastly, the image filename to be flashed to the partition...in my example, boot.img.
So, if you wanted to flash the /system partition of the Surf 7 tablet, the location of the Android OS itself, you wouid execute:
Code:
fastboot flash system system.img
(This command presumes that the system image has a filename of system.img.)
Fastboot commands can also be used to wipe or format partitions, resize dynamic partitions, set flag values to certain props, unlock & relock your bootloader, along with dozens of other tasks.
While I don't have time to get in depth on this topic, below is a link to a detailed outline on over 2 dozen different fastboot commands and how to use them . https://technastic.com/fastboot-commands-list/

Viva La Android said:
@Kavsokalivit45, I translated your question. Okay, fastboot mode can be used to flash a firmware image file (.img, .fex, .bin, .mbn, etc.) to a specific partition on your mobile device (/boot, recovery, /vendor, /system, /secro, etc.). The following fastboot command reflects that the boot partition is being flashed by a boot.img file.
Code:
fastboot flash boot boot.img
Note that all flashing commands will begin with the word fastboot, followed by the word flash. The next value is represented by the mounting name of the partition to be flashed...in the above example the partition is boot. Lastly, the image filename to be flashed to the partition...in my example, boot.img.
So, if you wanted to flash the /system partition of the Surf 7 tablet, the location of the Android OS itself, you wouid execute:
Code:
fastboot flash system system.img
(This command presumes that the system image has a filename of system.img.)
Fastboot commands can also be used to wipe or format partitions, resize dynamic partitions, set flag values to certain props, unlock & relock your bootloader, along with dozens of other tasks.
While I don't have time to get in depth on this topic, below is a link to a detailed outline on over 2 dozen different fastboot commands and how to use them . https://technastic.com/fastboot-commands-list/
Click to expand...
Click to collapse
Hello. thanks for the explanation! very grateful to you!