Database Info

[TUT] iPAQ 512/514 SKU ID ROM Update Hack

I managed to crack the ROMupdate.dll of the hpRUU primarily because there is no RUU for iPAQ 512 with SKU ID #UUF. It has ROM Revision 1.08 and the rest of the iPAQ 512/514s out there have an update with ROM Revision 2.05.0X
This will also work if you want to update your iPAQ 512/514 to another language. Here are the steps:
1. Download your desired iPAQ 512/514 ROM update
2. Unpack the RUU files by executing the SPXXXXX.exe file
3. Click next until you see green screen with 'iPAQ Update Utility'
4. Cancel the 'iPAQ Update Utility'
5. goto C:\iPAQ\SPXXXXX and change ROMupdate.dll with the attached file
6. Run hpRUU.exe from the same folder and proceed with updating your iPAQ 512/514
Enjoy!
EDIT: Flash at your own risk.

Very nice...
By the way, I've seen you've patched it...
What exactly did you patch? Does it skip the SKU check? Or did you do something else?

TryOG said:
Very nice...
By the way, I've seen you've patched it...
What exactly did you patch? Does it skip the SKU check? Or did you do something else?
Click to expand...
Click to collapse
I just made it skip SKU check.
I was doing some reading and plan to develop a tool to un-encrypt and encrypt the HP ROM file. Since you mentioned earlier that our HP device is manufactured by CMCS, I was looking at CMCSIMG tool. BUT, I think there is an additional encryption by HP like what he did for other IPAQs.
It would be nice if we have this tool working; so, we can start working on cooking for this device.

Plz Man Make the tool
tjlabais said:
I just made it skip SKU check.
I was doing some reading and plan to develop a tool to un-encrypt and encrypt the HP ROM file. Since you mentioned earlier that our HP device is manufactured by CMCS, I was looking at CMCSIMG tool. BUT, I think there is an additional encryption by HP like what he did for other IPAQs.
It would be nice if we have this tool working; so, we can start working on cooking for this device.
Click to expand...
Click to collapse
Yo Man Please do that man by the way whats that CMCSIMG supposed to do .
when i use pdocread.exe to get part02.raw and viewimgfs i get 70mb but i use imgfstodump i get 107mb dump folder with all the rom contents then i use imgfsfromdump to get Part02.bin can this bin be flashed to device like htc typhoon using MiTTy and DBSloader ?
and Decrypting The Nbf What tool do you use and as for the password wouldnt it be CMCS or Debussy or yssubed just like htc did with xda2nbf the himalayas nbf pass was himalaya in reverse
if u compare hp ipaq 514 with cmcs the specs are identicle

maybe the difference of 107mb vs 70mb is due to the processing of recmod.exe (its that file responsible for generating the actual files from modules with corrected PE headers)
I didn't use imgfsfromdump tool, I just use the ordinary mamaich tool because it does the job.
we have a very slight problem of flashing using pdocwrite. When you change the content of IMGFS and XIP, their overall size changes thereby causing them to be written to supposedly different ROM addresses respectively. which calls for an additional step of computing and modifying their location and references.
that's why we need the encryption and decryption tool, BUT i'm really swamped with work right now. can't find time to sit and look at it.
you just can't switch one ROM from a device to another device because it contains drivers specific to a device. You need to cook ROM (combine ipaq 510 series drivers with new OS files)
cmcsimg tool is from manufacturer cmcs. It's their own encryption tool used in most devices they manufacture, not necessarily HP. HP have their own encryption tool as well... I haven't recognized the format yet.

Thankz
The HP IPAQ 514 is The CMCS if you open The Part01.raw with win winrar file viewer at the bottom seems to be a log written by the development it has diffrent dates and what changes where made etc i will try and log later and it says the debussy is the codename for the ipaq Voice Messanger Series The Header for Part01.raw is the same as smarphone.nb0 emulator image im going to google mayb the debussy goes under another brand name.
Firmware 2.05 vs 2.08 its Wierd Because the 2.08 Dump Part01.raw seems to have an older log dat which is march 2007 whilst 2.05 is July 2007

The Log
i Attached a text file when i try cmcsimg i get header not b000ff

debussey
http://www.phonescoop.com/news/item.php?n=1780
{
"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"
}

Thats it
If you compare both device its the same Just The DBS has a diffrent Look. After Googling i Check They Say the CMCS has WM5.0 so it was originaly wm2003 in 2006 and then wm5.0 then wm6 it was ment for T-Mobile but ended up being modified for hp no wonder it had a resololution of 176x220 because back in the wm2003 days QQVGA was the standard So it Quite an Old Device in Design

can you get hold of a ROM encrypted using CMCSIMG tool? that would be the first step to see if our ROM update really uses CMCSIMG for encryption.

CMCSIMG.exe is fore *.img files
The main ROM file's formats.
CMCS Image. Files with *.img extension. That's the format of the upper level. Actually used while flashing. It's a coded BIN (B00FF) format version (see below). Another possible extension is *.rom - the same *.img but additionally coded with the special utility. It can not be used for flash procedure with the standard flash utility because it should be decoded before or the special flashing utility is to be used.
CMCS RSA Image. That's the format of the "upper" level. Actually used while flashing MPx220. It's a coded the ROM IMAGE format.
BIN (B00FF). Files with *.bin extension. This format is generated while creating the ROM with M$ Platform Builder. It contains the data blocks, the destination address of each data block in the ROM and the checksum of the data block.
RAW, ROM IMAGE. Files with *.img, .bin, .raw, .hex, .dmp. extension. It's memory image in FLASH/ROM as the CPU interprets it. You need to know the exact address of each image. The info about it is usually contained in the file name, attended text file or nowhere at all...
Very often the FLASH/ROM file is distributed as a built into installer file. Usually you can find a flash file by itself in the Temp folder straight after starting such kind of distribution file. The flash rom file has a size from 20 to 32 Mb (with new devices - up to 64 Mb) and it has .nbf, .bin or .img. extension. In each case you should define your own way of work with the file.
More INFo HERE

a few bootup keys
Power up with these keys pressed:
vol up: loads bootloader from ROM (not flashrom)
vol down: boots into updater, install modem driver to issue AT commands.
I did not jet figured out what you can do here...
Middle joypad button: hard reset to factory settings.
* + # : enable debugging! (but where can we play???)

Intesting
sony66 said:
Power up with these keys pressed:
vol up: loads bootloader from ROM (not flashrom)
vol down: boots into updater, install modem driver to issue AT commands.
I did not jet figured out what you can do here...
Middle joypad button: hard reset to factory settings.
* + # : enable debugging! (but where can we play???)
Click to expand...
Click to collapse
Volume Down + Power Key I Get DBS Loader
+ Mitty u Get
XKLLT-0-2050-4017-0.XKL As on The Pic is also used in RoverPC N1 -> C:\N Rover\boot\cmcsimg\cmcsimg.exe" DVD-3-0430-0080-0.xkl DVD-3-0430-0080-0.bin Check Here
sony66 said:
Power up with these keys pressed:
vol up: loads bootloader from ROM (not flashrom)
Click to expand...
Click to collapse
When i Press Vol Up + Power i Get 0.00.00 instead of 2.05.00

S
sp38077.exe
Files Contained In PLT_2.05.00_1007.BLOSGSM.nbf Are:
*PLT-0-2050-1007-0-A01.mlf
*DBS-FL-0760.m0
*PLT-0-2050-1007-0.MAX
*DBS-XL-0760.xl
*DBS-YL-0760.yl
*DBS-BL-0760.bl
*DBS-1-1080-000.gsm
*PLT-0-2050-1007-0.MBR
*PLT-0-2050-1007-0.ULD
*PLT-0-2050-1007-0.XKL
*PLT-0-2050-1007-0.OS0
*PLT-0-2050-1007-0.OS1
*PLT-0-2050-1007-0.OS2
*PLT-0-2050-1007-0.OS3
*PLT-0-2050-1007-0.OS4
*PLT-0-2050-1007-0.OS5
*PLT-0-2050-1007-0.OS6
[Package Download Profile]
PROFILE VER = 1.0
MODEL = DBS
VERSION = 2.050
PACKAGE NUMBER = 14
NEW PACKAGE INFO = 0
[Package Info Main Body]
IMAGE FILE = SKIP THIS SETTING BUT DO NOT MODIFY THIS SECTION
[Package Info Main]
IMAGE FILE = PLT-0-2050-1007-0.MAX
[Package Info 1]
IMAGE FILE = DBS-XL-0760.xl
START ADDRESS = 0
INDEX = 1
[Package Info 2]
IMAGE FILE = DBS-YL-0760.yl
START ADDRESS = 0
INDEX = 2
[Package Info 3]
IMAGE FILE = DBS-BL-0760.bl
START ADDRESS = 0
INDEX = 3
[Package Info 4]
IMAGE FILE = DBS-1-1080-000.gsm
START ADDRESS = 0
INDEX = 4
[Package Info 5]
IMAGE FILE = PLT-0-2050-1007-0.MBR
START ADDRESS = 0
INDEX = 5
[Package Info 6]
IMAGE FILE = PLT-0-2050-1007-0.ULD
START ADDRESS = 0
INDEX = 6
[Package Info 7]
IMAGE FILE = PLT-0-2050-1007-0.XKL
START ADDRESS = 0
INDEX = 7
[Package Info 8]
IMAGE FILE = PLT-0-2050-1007-0.OS0
START ADDRESS = 0
INDEX = 8
[Package Info 9]
IMAGE FILE = PLT-0-2050-1007-0.OS1
START ADDRESS = 0
INDEX = 9
[Package Info 10]
IMAGE FILE = PLT-0-2050-1007-0.OS2
START ADDRESS = 0
INDEX = 10
[Package Info 11]
IMAGE FILE = PLT-0-2050-1007-0.OS3
START ADDRESS = 0
INDEX = 11
[Package Info 12]
IMAGE FILE = PLT-0-2050-1007-0.OS4
START ADDRESS = 0
INDEX = 12
[Package Info 13]
IMAGE FILE = PLT-0-2050-1007-0.OS5
START ADDRESS = 0
INDEX = 13
[Package Info 14]
IMAGE FILE = PLT-0-2050-1007-0.OS6
START ADDRESS = 0
INDEX = 14
Ver2.20 CMCS Download Firmware Image. Build Date : 2007 November 21
The NBF Contains Lots Of Data Sections With The Above As The Header For Each Section
Section 1 offset DC7520
Section 2 offset 8EF2EE
Section 3 offset 8EF986
Section 4 offset BA407E
Section 5 offset E79D56
Section 6 offset 16C23BE

The ipaq514 is the same as the RoverPC M5 (sold with WM5)
Somewere I read that someone cooked a wm6 rom for the RoverPC M5 but faled to find any details of this.
What command did you type to get that output?

Yeah Progress
sony66 said:
The ipaq514 is the same as the RoverPC M5 (sold with WM5)
Somewere I read that someone cooked a wm6 rom for the RoverPC M5 but faled to find any details of this.
What command did you type to get that output?
Click to expand...
Click to collapse
At + L was the command
you right its the rover pc m5 here is the cooked wm6 rom http://translate.google.co.za/trans...overPC+M5+wm6&hl=en&client=ms-opera-mini&sa=G

hmmm.... hp has sometimes its own encryption. For example, the hp rw6828 has the same hardware as xda atom, but it formatted its ROM in a different way so it can't interchange it's updates with xda atom. Then hp encrypts it with its own too; so, you won't go unpacking all the goodies it has included in its ROM.
But for rw6828, the encryption was a mere alteration of the main file header and the header of each section; thus, by removing it you can already unpack the hp ROM pretty much like the xda atom.
hp never uses a file convention. It uses nbf interchangeably with a variety of formats it can think of.

THE RoverPC
The RoverPC M5 USES WMIPL.DIP + WMUPDAT.DIP To Flash the phone The Same as IMATE SPL IF You Open Rover M5 WMIPL.DIP You Can See its ment for the IMATE SPL Because its Got Omap 730 text blah blah here are ROVERPC M5 Official Roms FTP
Im going to try use IMATE SPL Cooking Tools.
Can Some Translate That Russian Text In the FLASH.txt it contains information on how to Flash with SD

Tool To Create DIp
http://rapidshare.com/files/96517662/Constructor_M5.7zThis is the tool that was used to create WM6 Rom for RoverPC M5

defcomg said:
The RoverPC M5 USES WMIPL.DIP + WMUPDAT.DIP To Flash the phone The Same as IMATE SPL IF You Open Rover M5 WMIPL.DIP You Can See its ment for the IMATE SPL Because its Got Omap 730 text blah blah here are ROVERPC M5 Official Roms FTP
Im going to try use IMATE SPL Cooking Tools.
Can Some Translate That Russian Text In the FLASH.txt it contains information on how to Flash with SD
Click to expand...
Click to collapse
Roverpc m5
this site says roverpc m5 using omap 850 and all specs are same as ipaq514

[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.

[DEV] Huawei Honor Bee (Y541 - U02) Spreadtrum Secure Boot

Introduction
The System-On-a-Chip the device runs on is enforced with a proprietary secure-boot. Nothing but official images and binaries are accepted to be flashed.​
Background
Booting goes through three stages: bootrom, bootloader and kernel. According to documents about secure boot on these chips is that there is a root certificate existing on the hardware with a chain-of-trust security protocol. Each phase checks the binaries the other contains.
To generate a header, we need a key pair. A key pair consist of a password of exactly eight ASCII characters together with a key of not more than forty-nine characters. In the Spreadtrum document referenced below the key is treated as the product name.
The signing process needs three key pairs found in sig_keys.ini that will be read by RSAKeyGen and generate keys.db. The generated keys.db will always be referenced by the signing tools along with sig_bins.ini which contains the filename inputs and outputs.
Now the first and second key pairs are used to sign fdl1.bin and u-boot-spl-16k.bin with BscGen. Second and third key pairs are used to sign fdl2.bin and u-boot.bin with VLRSign. The last one is used alone to sign boot.img and recovery.img with VLRSign. The RSA + hash of the file is prepended and appended to the first two sets of boot files, and the rest have it only prepended.
In the Spreadtrum document, it stated that only the hash value of the first boot binary, in this case fdl1.bin should match the hash stored in the chip.
Reading through the document some more, it has come to my attention that apparently the hash of the signed boot binary is what the chip holds. It emphasized protection of the key.db because it contains randomly generated RSA for the key pair. I've compared two identical key pair sets and it does what it stated. Losing the key.db means the board is scrapped if it were in manufacturing.
That closes our brute force attack option sad to say.​
Digging Around The Binaries
Having the u-boot binaries on hand I managed to extract two oem commands:
Code:
oem get-psid
oem get-bootinfo
oem get-psid:
Code:
(bootloader) SN:Y541XXXXXXXXXXXX-XXXXX
OKAY [ 0.007s]
Finished. Total time: 0.007s
oem get-bootinfo:
Code:
(bootloader) INFO:unlocked
OKAY [ 0.015s]
Finished. Total time: 0.015s
As you can see its just information commands and yes, the bootloader is unlocked, which is bogus. There was never an unlock code given by Huawei upon contacting them. They said the device isn't supported in the database, which funny enough is true, because there was no oem unlock command to begin with.
I hope I'm wrong, though a few related documents about security itself is that companies do either allow or deny you of control to unlocking. Unless Huawei gives us the key.db we will be going nowhere with brute force method.​
Engineering Mode
One can open the engineering application to debug and show more information about the device by dialing:
Code:
*#*#83781#*#*
The documents stated something about checking if the hash is written on the chip by going to HARDWARETEST tab. My device just says hash value written. Kept our hopes up I know.
Navigating to DEBUG&LOG you will find System Info. Click on that and then click on Version Info.
My device:
Code:
Platform Version: MOCORTM_14B_TSHARK28_HUAWEI_W15.34_P5_Debug
Project Version: sc7731g_CP0_modem
BASE Version: TM_BASE_MP_II_HUAWEI_W16.06
HW Version: sc7731g_CP0_modem
Release Date: 02-18-2016 10:02:37
This might come in handy for finding source codes, and also possibly prevent flashing the wrong firmware.​
Entrypoint
Our only option right now is finding exploits on the bootloader since we do have some of the source codes to base off on. Check the relevant repository link below.​
Final Thoughts
This device is a headache to be honest. I've been scouring everything I could find about it since 2016. Much appreciated if an able body can proceed to help, or just go to Huawei Support and ask them through e-mail.
The instructions for using the signing tool is in the GitHub repository linked below and a related paper for the interested.
In any case this post will continue to be updated.​
Resources
Spreadtrum Secure Boot Tools
Spreadtrum Secure Boot Document (Chinese)
Other Spreadtrum Secure Boot Document (Chinese)
Chipram Repository

Apparently the libefuse shared library in /system/lib displays the hash:
Code:
ef9b361fa1cb9ddbece00c60c5736b8de65f2be8
This accounts for all Y541-U02 variants.

How To Guide [ADVANCED] [UNTESTED] Possible Fix - MSM Errors (Sahara, Param info, etc)

WARNING: THE FOLLOWING IS FOR INFORMATIONAL PURPOSES ONLY AND MAY FURTHER DAMAGE YOUR DEVICE. EXERCISE EXTREME CAUTION. USE ONLY AS A LAST RESORT.​
This was tested with a Global OnePlus 9 LE2115
Overview​
So I was encountering an error with MSM Download Tool that would show "Sahara communication failed" after about 18 seconds. This resulted in me being 100% unable to recover my device with MSM as it was continuously rebooting into EDL mode with no possibility of entering fastboot.
After much research, I stumbled upon a solution completely by accident. I was able to fix the issue by utilizing the following tools:
Qualcomm Sahara Tools - https://github.com/bkerler/edl
Oppo/OnePlus Decryption Tools - https://github.com/bkerler/oppo_decrypt
You need:
- Latest version of Python 3
- C/C++ build tools (gcc, Visual Studio, XCode) to build pip dependencies
- Dependencies installed using pip as specified in README.md of each repo
- Linux or macOS (Windows untested)
- *.ops file from your corresponding MSM Download Tool package
Process​
Follow the instructions contained within the README of the above repos to download all files and install dependencies before continuing.​
Spoiler: Extract ops package
Use opscrypto.py to extract the ops file you obtained earlier.
This results in a directory full of the decrypted contents of the update image (a collection of bin, img, and other files):
Code:
$ ./opscrypto.py decrypt lemonade_xxxx.ops
This creates an extract directory containing the decrypted files
Spoiler: Flash using edl.py
The wl subcommand for edl.py can then be used to write the aforementioned partitions.
The documentation describes the command thusly:
Code:
./edl.py wl dumps --memory=ufs >> to write all files from "dumps" folder to according partitions to flash and try to autodetect lun
I ran the command on the extract directory that was previously decrypted.
Additionally, I had to explicitly specify the OP9 EDL loader as well as specify that the flash memory was UFS and not EMMC:
Code:
$ sudo ./edl.py wl extract --memory=ufs --loader=Loaders/oneplus/0000000000514d67_a26bc25799770106_fhprg_op9.bin
This output was produced:
Code:
main - Using loader Loaders/oneplus/0000000000514d67_a26bc25799770106_fhprg_op9.bin ...
main - Waiting for the device
...............
.main - Device detected :)
main - Mode detected: sahara
Device is in EDL mode .. continuing.
sahara -
------------------------
HWID: <CLIPPED>
CPU detected: "lahaina"
PK_HASH: <CLIPPED>
Serial: <CLIPPED>
sahara - Uploading loader Loaders/oneplus/0000000000514d67_a26bc25799770106_fhprg_op9.bin ...
Successfully uploaded programmer :)
firehose - Chip serial num: <CLIPPED>
firehose - Supported Functions: program,read,nop,patch,configure,setbootablestoragedrive,erase,power,firmwarewrite,getstorageinfo,benchmark,emmc,ufs,fixgpt,getsha256digest
firehose -
firehose_client - Target detected: lahaina
firehose - TargetName=
firehose - MemoryName=UFS
firehose - Version=
firehose_client - Supported functions:
-----------------
program,read,nop,patch,configure,setbootablestoragedrive,erase,power,firmwarewrite,getstorageinfo,benchmark,emmc,ufs,fixgpt,getsha256digest
firehose -
Reading from physical partition 0, sector 8, sectors 1
Progress: |██████████████████████████████████████████████████| 100.0% Complete
Progress: |██████████████████████████████████████████████████| 100.0% Complete
oneplus - Oneplus protection with prjid 19825 detected
Writing ./param.bin to partition param.
firehose -
Writing to physical partition 0, sector 8, sectors 256
Writing ./persist.img to partition persist.
firehose -
Writing to physical partition 0, sector 2056, sectors 8192
Writing ./misc.bin to partition misc.
firehose -
Writing to physical partition 0, sector 10248, sectors 256
Writing ./frp.bin to partition frp.
firehose -
Writing to physical partition 0, sector 10632, sectors 128
Writing ./carrier.img to partition carrier.
QCSparse - Sparse Format detected. Using unpacked image.
firehose -
Writing to physical partition 0, sector 18440, sectors 12288
Writing ./opluslog.img to partition opluslog.
QCSparse - Sparse Format detected. Using unpacked image.
firehose -
Writing to physical partition 0, sector 34824, sectors 65536
Writing ./metadata.img to partition metadata.
firehose -
Writing to physical partition 0, sector 108616, sectors 4096
Writing ./super.img to partition super.
QCSparse - Sparse Format detected. Using unpacked image.
firehose -
Writing to physical partition 0, sector 145480, sectors 1
Writing ./userdata.img to partition userdata.
QCSparse - Sparse Format detected. Using unpacked image.
firehose -
Writing to physical partition 0, sector 2877512, sectors 2105
Writing ./ocdt.bin to partition ocdt.
firehose -
Writing to physical partition 3, sector 576, sectors 32
Writing ./oplusreserve2.img to partition oplusreserve2.
QCSparse - Sparse Format detected. Using unpacked image.
firehose -
Writing to physical partition 4, sector 6, sectors 32768
Writing ./devinfo.bin to partition devinfo.
firehose -
Writing to physical partition 4, sector 722224, sectors 1
Writing ./apdp.mbn to partition apdp.
firehose -
Writing to physical partition 4, sector 722481, sectors 4
Writing ./storsec.mbn to partition storsec.
firehose -
Writing to physical partition 4, sector 817779, sectors 6
Writing ./mdcompress.mbn to partition mdcompress.
firehose -
Writing to physical partition 4, sector 826302, sectors 12
Writing ./spunvm.bin to partition spunvm.
firehose -
Writing to physical partition 4, sector 831486, sectors 87
Writing ./rtice.mbn to partition rtice.
firehose -
Writing to physical partition 4, sector 839678, sectors 65
Writing ./abl_log.bin to partition abl_log.
firehose -
Writing to physical partition 4, sector 839870, sectors 4048
Writing ./android_log.bin to partition android_log.
firehose -
Writing to physical partition 4, sector 847966, sectors 4048
Writing ./qsee_log.bin to partition qsee_log.
firehose -
Writing to physical partition 4, sector 852014, sectors 4048
Writing ./hyp_log.bin to partition hyp_log.
firehose -
Writing to physical partition 4, sector 856062, sectors 4048
Conclusion​After performing the above on a macOS device, the device successfully flashed in MSM on Windows 11.
I rebooted the device prior to attempting to flash after performing the above steps.
Addendum​This isn't a foolproof guide and may not even work for your device or may even damage it further.​The process described above is somewhat advanced and very much undocumented and unsupported/unofficial/hacky.​
I cannot vouch for the quality, security or effectiveness of the tools linked above.
I'm putting this out there in hopes it helps others and to gather more information about how MSM Download Tool and EDL mode actually work.
Please let me know if this solves any issues with MSM and I can potentially produce a guide if this method is proven safe.
Spoiler: Speculation / Thoughts
Firehose appears to be an executable elf file that is ran on the device, which then parses settings.xml and provision_*.xml contained within the ops file.
These files appear to contain the directives that allow MSM to recover bricked devices.
MSM appears to transmit these XML files to the firehose executable after loading it on the device.
These files reference the stock images, partition sizes, names, and extents that firehose then uses to provision the device.
Since firehose is simply an elf file that appears to rely on some preexisting data to be present on the device, some bricks may cause firehose to fail due to corruption of certain partitions.
Producing errors such as:
- Device mismatch
- Param preload error
- Sahara communication failure
- Waiting for device
- Waiting for COM port
The partitions shown in the output log appear to not be touched by MSM prior to sending firehose to the device, suggesting that it assumes they have been untouched.
Therefore, firehose may throw an error or fail to run entirely when attempting to recover some devices, even when using the correct MSM tool and drivers.
Despite being contained in the ops file, MSM doesn't appear to touch these partitions in its default Upgrade Mode.
That functionality may be locked behind more advanced modes such as SMT Download Mode, however, that mode is well known for causing more issues than it solves.
The tools above are open source reverse engineering tools that can do some rudimentary communication with OnePlus devices in EDL mode by utilizing a custom firehose binary (known as the "loader").
These appear to permit operations not possible with MSM's default behavior.
Spoiler: Observations
I was only able to get the edl.py tool to work on macOS.
I was unable to get this tool (edl.py) to work in Windows. It threw various libusb related errors despite using zadig as directed.
I observed that writing to any partition that was part of A/B dynamic partitioning would report that it was written successfully but in reality would only write 1 sector of the provided file.
However, a handful of other partitions appear to be writable, ones that typically can't be written to/aren't written with fastbootd or OTA side loading.
My IMEI and Serial Number were fully intact after flashing.

Bruh my pro was in that constant reboot state. Buss laugh if this is a Tually a fix for that
Click to expand...
Click to collapse
Hopefully it is. I'm curious to see if it works for others. I stumbled upon this right as I had given up and submitted a ticket to OnePlus.
At which point they said there's nothing to do and the device needed repaired.
So hopefully this is a reliable fix for devices that are super-bricked, because it saved me from having to send my device in.

Op9 was there all except I could always get to fastboot by pressing all buttons and hold until off and back on fb ,also several times monfrios all in one would read it dump and could reboot to fastboot .lol thanks again mon ,and I do some dumb junk to mine trying to get 5g on att all the time eventually I may need this .thanks in advanced for your efforts and interest .

Jessp4046 said:
Op9 was there all except I could always get to fastboot by pressing all buttons and hold until off and back on fb ,also several times monfrios all in one would read it dump and could reboot to fastboot .lol thanks again mon ,and I do some dumb junk to mine trying to get 5g on att all the time eventually I may need this .thanks in advanced for your efforts and interest .
Click to expand...
Click to collapse
This may be a solution to a problem that isn't all that widespread.
I found myself in this situation after flashing an Android 12 GSI to my device which involved mucking around with stuff I probably shouldn't have touched.
I've used MSM many times while experimenting but this time I really messed up and was out of options.
Amazingly, I stumbled across the tools above and was able to bumble my way to a solution. This took me about 4 days to resolve as the device refused to enter fastboot.

GlitterFartzz said:
This may be a solution to a problem that isn't all that widespread.
I found myself in this situation after flashing an Android 12 GSI to my device which involved mucking around with stuff I probably shouldn't have touched.
I've used MSM many times while experimenting but this time I really messed up and was out of options.
Amazingly, I stumbled across the tools above and was able to bumble my way to a solution. This took me about 4 days to resolve as the device refused to enter fastboot.
Click to expand...
Click to collapse
This is exactly what cause mine to loop. I tried flashing a 12 GSI lol

Jhoopes517 said:
This is exactly what cause mine to loop. I tried flashing a 12 GSI lol
Click to expand...
Click to collapse
I was actually able to get the GSI to boot, albeit with no cellular, fingerprint, etc. OP9 claims to be treble-compliant in the props but methinks that's a total lie.

I m waiting here
{
"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"
}

flameteam said:
I m waiting here
View attachment 5364413
Click to expand...
Click to collapse
Looks like you're trying to do a full dump of LUN 0 into a single bin file. LUN 0 contains a large chunk of data as it houses the super partition and the userdata partition.
I would recommend using the r subcommand to dump individual partitions or just use rl which will dump your whole device while neatly separating each partition into individual files.
To see exactly what each LUN is comprised of, you can use the printgpt command:
Code:
./edl.py printgpt --memory=ufs
Given that you're running in a VM, your I/O speeds are likely much lower.
I recommend at least booting into a Linux Live USB to do this.
If security is a concern, at a minimum I would recommend vfio passthrough via QEMU to pass your entire USB controller through from a Linux host.
IMO, virtualizing the USB connection will kill your throughput and put you at risk of data corruption.

GlitterFartzz said:
I was actually able to get the GSI to boot, albeit with no cellular, fingerprint, etc. OP9 claims to be treble-compliant in the props but methinks that's a total lie.
Click to expand...
Click to collapse
I couldn't this time. I was able to prior but no go.

my one plus 8t is completely hard bricked, black screen, no logo, no vibration, nothing. Now i cant use msm cuz always got sahara communication failed. This seems like the way to go, will update you if it works

Help me guys. I can't access anything and it's saying Sahara Comm. error at 18 sec. I tried this on Windows and Linux but it does not work........ It gives me this:
File "opscrypto.py", line 160
self.info = print
^
SyntaxError: invalid syntax

_MartyMan_ said:
Help me guys. I can't access anything and it's saying Sahara Comm. error at 18 sec. I tried this on Windows and Linux but it does not work........ It gives me this:
File "opscrypto.py", line 160
self.info = print
^
SyntaxError: invalid syntax
Click to expand...
Click to collapse
same here! oneplu 9 chinese version model 2110, screen its just black, but computer detects it.
thanks in advance

Kind of progress but still does not work... I get this error message:
Somebody help pls.......
@GlitterFartzz do you have any idea what this could be?

I have tried everything to get my Global one plus 9 back up and running again … monster what I do with drivers I get this error on msm tool . As you can see my phone is detected in tool but can put go past this point . I do not have access to download or fast or mode . Last steps I took was through this thread ——https://forum.xda-developers.com/t/fastboot-rom-pc-required-op9-stock-oos-11-2-2-2aa.4275727/—— and reached 1/2 way point (waiting on device) and now I can’t get oos back on phone .. does anyone have any tips or knowledge they can guide me to get my phone working with msm tool ? Much appreciated

Toggle on "Use lite Firehose" before running

Thanks shooter7889 , got past the SMT error by setting date back 2 years on laptop and turning Wi-Fi off. Now i am getting the Sahara error after 18 sec and if I toggle use lite firehouse i get the PARAM error after 8 sec. I have tried to follow steps on the READ ME section (advanced GitHub page )but i dont have any experience with the process as shown. Is it possible to get a easy step guide that can be put together to get past the Sahara error? for us less advanced members? Anything helps at this point. phone is a brick , only thing i can get into is EDL mode .

Justingaribay7 said:
Thanks shooter7889 , got past the SMT error by setting date back 2 years on laptop and turning Wi-Fi off. Now i am getting the Sahara error after 18 sec and if I toggle use lite firehouse i get the PARAM error after 8 sec. I have tried to follow steps on the READ ME section (advanced GitHub page )but i dont have any experience with the process as shown. Is it possible to get a easy step guide that can be put together to get past the Sahara error? for us less advanced members? Anything helps at this point. phone is a brick , only thing i can get into is EDL mode .
Click to expand...
Click to collapse
Mate what's your device model ? If you device model LE2113 flash https://androidfilehost.com/?fid=2188818919693804750 9pro eu msm rom. and after ınstallation flash op9 https://drive.google.com/drive/folders/1R_j8sML_46YrTp1HGfpS6zrAUeFl8uJU?usp=sharing

This is a great resource to have, nice work. I'll give it a go if I ever hit that state again. I've only had success using the pro msm tools up to this point for some reason with lite firehose when I get the Sahara or param info device not match error. Once I've lite msmed with the pro tool, I can normal msm with the nonpro tool, just like flame team mentioned

flameteam said:
Mate what's your device model ? If you device model LE2113 flash https://androidfilehost.com/?fid=2188818919693804750 9pro eu msm rom. and after ınstallation flash op9 https://drive.google.com/drive/folders/1R_j8sML_46YrTp1HGfpS6zrAUeFl8uJU?usp=sharing
Click to expand...
Click to collapse
Thanks for the reply flameteam . My device is LE2115 Global . Would this method still work on this Version?

I tried running the Eu tool . No luck . Same errors as the O2 tool . Tried different flash options such as light firehouse on and off .. Sahara error and Parameters error still present

Identifying EDL (Firehose) loaders

Maybe you already have a loader for Qualcomm "Emergency DownLoad" (EDL) mode.
Maybe you're looking for one.
You know what? A single loader is for more than one device. But it gets hairy with signing and manufacturers and stuff.
So, I've got a beta release utility here. It can (in most cases) identify which model Qualcomm processors a "Firehose" loader is designed for.
First, it's currently a Windows release.
Second, it doesn't work with the older .mbn style loader (since they don't include that information).
So, just go to My EDL page and go to the bottom and download qcomview.exe
Code:
C:\>qcomview.exe poke3.bin
APQ8096
APQ8098
MDM9250
MDM9255
MDM9350
MDM9650
MDM9655
MSM8996
MSM8997
MSM8998
QDF2432
SDA630
SDA636
SDA658
SDA660
SDM636
SDM658
SDM660
You can see the SDM 636 (which is the actual processor on a Poke3.
Obviously, you have to select your own loader.
I've scanned through 200 loaders and I recognize all the processors.
If you see a "???" please quote it.
Edit: Maybe you're saying, "That ain't nothing but a "string" script!" Eh, mostly, but it is more clever and it sorts things.

Thanks for the tool. I have a small feature request, since xbl and elf firehorse programmer use similar structure(I guess), it would be useful if you add a way to check if xbl and programmer are compatible(by comparing cert hashes?).

HemanthJabalpuri said:
It would be useful if you add a way to check if xbl and programmer are compatible...
Click to expand...
Click to collapse
It would be.
On your device you already have a ton of ELF images that have compatible signing.
The problem is, the certs are not identical since the lowest level (farthest away from the root authority) has things like dates and annotations and the bit fields are not the same.
I've not yet figured out how to generate from an ELF file the 256 bit "Hash" that EDL gets out of the device.
To those who don't know yet, I've added more things to this utility. It can check the regular hashes in the ELF files. If your device is not SecureBoot this can be handy if you want to patch. The hashes on the program segments in an ELF file are always checked, the signing is only checked if SecureBoot is on. So, if your SecureBoot is off, you can patch a file, run qcomview /h whatever.elf. As of now it won't can correct wrong hashes but you can simply hexedit in the bigendian values and then double-check with the same command.
Code:
C:\>qcomview /h xbl
64 bit ELF, SHA384
0 00000000 000003f8 8a46a864b9bec352 69b1dadfcac64bfa a388f7bea37d855e 50f55170277c043c 87c862e23709fd96 34bb545ac49a3d64 OK
1 00001000 00001cd8
2 0005cd10 00002ab0 3d2e7c505458e1e7 9070b1957a8f2520 3bbcf288674548f1 7db146a86b314499 5890e1432dbac635 2bad53bfd2960908 OK
3 0005f7c0 00000d64 ac556708059a1315 41e774e34310b89f 3c3f13183b43fda9 9e3a34bd0899da4b bb43c1080a43925f fd8d6a2ecd864e29 OK
4 00076d70 00000000
5 0005cd10 00000000
6 00003000 0004cd04 a81ab8ec59e2dfb1 f2f98e3ac0a9a396 1cd9f0dfb5a5daa5 2cda2f52d4df97c8 bc398b24528fd10f cd47ced08596f61c OK
7 0004fd10 00000000
8 0004fd10 0000d000 e7d03abb34361774 e030039e096b3e25 64519024c5c15666 efecbd8006deaaae b87884e2bdab52cb e06a4a7a4873e1c5 OK
9 0005cd10 00000000
10 00060530 00016838 2ca0423b6e745b5f c69544b947556ff1 9d04792c579d2f53 d480d2fa738cac82 1674ddaab8078071 648cc10f384ec25a OK
11 00376d70 00022000 18bdbbdeac3e92c0 6f3e5f06f5aa91ae d0daa757a375bab6 5e90d4e2a52d8e95 2255d80c76637316 b24736223e0a0bd2 OK
12 0005cd10 00000000
13 00398d70 00048ded 794528234b46757a 3017481198fa8fd6 c9578e6565ec301a f0ab28fbe105c460 c7cc855f93576767 29302c26357a00bb OK
14 003e8490 00000000
15 003e1b60 0000692d 1354b9b55447ffb8 54ea17d1d9f1ea88 c84bd1045a6bd106 3b38df93fa049fa9 c1b245dc6106098a 0450a75bf7e5ce3f OK
16 00076d70 00300000 7341f2cde09d6a5f 53bcb90714f779a5 53c3ffeeff1824e5 437464f4bfcc545f 6719370d5d6c656d df96e81382315405 OK
For you Motorola users running into "range restricted" you can dump the ranges by:
Code:
C:\>qcomview /r motog.bin
Addr LUN Start Count
------ --- -------- --------
008220 0 0 32
008238 0 -5 5
008250 1 0 32
008268 1 -5 5
008280 2 0 32
008298 2 -5 5
0082b0 3 0 32
0082c8 3 -5 5
0082e0 4 0 32
0082f8 4 -5 5
008310 5 0 32
008328 5 -5 5
008340 1 0 2048
008358 2 0 2048
008370 3 0 2356
008388 5 0 2356
0083a0 0 2080 512
0083b8 0 0 256
0083d0 0 -33 33
0083e8 0 131072 284992
008400 0 416064 2048
008418 1 1 1
The UFS table is on top, followed my the eMMC table.

HemanthJabalpuri said:
It would be useful if you add a way to check if xbl and programmer are compatible (by comparing cert hashes?).
Click to expand...
Click to collapse
I've just added SHA256 fingerprint of the root CA to qcomview.
Code:
C:\>qcomview /f loader.bin
5adc6039 dcb297d4 0c55df73 1580248d a9e18b31 ccc43b45 36795313 f82fd430
If SecureBoot is enabled xbl/abl/Firehose must all have the same fingerprint.
(This also goes for the other two dozen ELF files in flash.)
For most devices this SHA256 will be the same that your EDL client prints out as "Hash".
There appears to sometimes be (on newer devices?) a discrepancy between root CA fingerprint and EDL "Hash".
Possibly the EDL "Hash" is the encrypted version?
In any case, all the fingerprints should agree.

Renate said:
Maybe you already have a loader for Qualcomm "Emergency DownLoad" (EDL) mode.
Maybe you're looking for one.
You know what? A single loader is for more than one device. But it gets hairy with signing and manufacturers and stuff.
So, I've got a beta release utility here. It can (in most cases) identify which model Qualcomm processors a "Firehose" loader is designed for.
First, it's currently a Windows release.
Second, it doesn't work with the older .mbn style loader (since they don't include that information).
So, just go to My EDL page and go to the bottom and download qcomview.exe
Code:
C:\>qcomview.exe poke3.bin
APQ8096
APQ8098
MDM9250
MDM9255
MDM9350
MDM9650
MDM9655
MSM8996
MSM8997
MSM8998
QDF2432
SDA630
SDA636
SDA658
SDA660
SDM636
SDM658
SDM660
You can see the SDM 636 (which is the actual processor on a Poke3.
Obviously, you have to select your own loader.
I've scanned through 200 loaders and I recognize all the processors.
If you see a "???" please quote it.
Edit: Maybe you're saying, "That ain't nothing but a "string" script!" Eh, mostly, but it is more clever and it sorts things.
Click to expand...
Click to collapse
Hello , Renate
I am using you edl.exe programme. it work fine but i would like to know that the tool has any features to flash using xml file or not ? and it is support ufs provisioning or not ? Please confirm

noob9t2 said:
Please confirm
Click to expand...
Click to collapse
Yes, it does UFS (with the /u flag).
No, it doesn't do these XML files. I find the whole idea a bit overblown.
If you're in the habit of overwriting every partition on your device often, simply:
Take the XML file and delete all the redundant stuff besides 1) partition name, 2) image filename.
Add in edl /w /p on each line.
Execute it as a batch file.

Thank You Renate for reply. we flash ufs chip using qfil after flashing on qfil, we need to flash patch file and check ufs provisioning to boot the device properly. On your tool, anything need to do after writing a partition. if i write a single partition, phone will boot normally ?

noob9t2 said:
If i write a single partition, phone will boot normally?
Click to expand...
Click to collapse
Sure, if you didn't break anything.
The reboot command is edl /z
Ha! You motivated me to track down why some devices need you to do that command twice.
I just fixed it.
Download the special Valentine's Day release of edl.exe (from the usual place).

noob9t2 said:
We flash ufs chip using qfil after flashing on qfil?
Click to expand...
Click to collapse
So, if you're using QFIL there's a loader somewhere that you're using. Find it.

Please can you explain how the patch for the loader works

roulo said:
Please can you explain how the patch for the loader works
Click to expand...
Click to collapse
Loaders are made by phone manufacturers from standard editions of xbl (the secondary loader) released by Qualcomm.
Sometimes they put in restrictions (like Lenovo/Motorola), sometimes they put in authorization (like OnePlus).
Sometimes there are two different versions, one with full capabilities, one without.
The word "patched" gets used often for the full capabilities loader.
Patching a loader yourself is not that difficult, the problem is that loaders must be signed and you can't do that.
Many components on Qualcomm SoC phones are signed.
This ensures a "chain of trust".
The only way that you can patch something is if your device does not have SecureBoot enabled.
If you know of a phone without SecureBoot, tell me and I'll buy a case of them.

I never had time but here is a starting point.
https://forum.xda-developers.com/t/k40-bricked.4538285/post-87978383

alecxs said:
I never had time but here is a starting point.
https://forum.xda-developers.com/t/k40-bricked.4538285/post-87978383
Click to expand...
Click to collapse
What I could read of that was talking about analyzing Firehose loaders for vulnerabilities, which you can.
I've largely disassembled a "restricted" Motorola Firehose loader and could patch it easily.
Still, unless some Motorola employee goes rogue I don't see how I could sign it.