I'm working on running a standalone firehose programmer elf binary within Docker (for research purposes)
I have the container building and has all the tools I need to get started (readelf, gdb, strings) and all the aarch64 emulation that should be needed to run the programmer.
When I do run the binary I get:
# ./prog_firehose_lite.elf
./prog_firehose_lite.elf: Invalid argument
The binary itself is expecting some flags at launch time. I would not be surprised if there is a certificate as part of that handshake. Any idea what these flags may be?
I'll likely be publishing some of my findings to GitHub. I can't tell you how much theory I've learned about the sahara/firehose setup and how each OEM does things differently. Pretty fascinating...
One thing that I'm not sure of is the chainloading that I believe that happens from the PBL (stored on the hardware ROM) to the loading of the firehose programmer.
A few useful articles for this research:
Qualcomm’s Chain of Trust
Covering Qualcomm bootloader’s up to the point of Android being loaded
lineageos.org
GitHub - bkerler/edl: Inofficial Qualcomm Firehose / Sahara / Streaming / Diag Tools :)
Inofficial Qualcomm Firehose / Sahara / Streaming / Diag Tools :) - GitHub - bkerler/edl: Inofficial Qualcomm Firehose / Sahara / Streaming / Diag Tools :)
github.com
GitHub - alephsecurity/firehorse: Research & Exploitation framework for Qualcomm EDL Firehose programmers
Research & Exploitation framework for Qualcomm EDL Firehose programmers - GitHub - alephsecurity/firehorse: Research & Exploitation framework for Qualcomm EDL Firehose programmers
github.com
It’s As Easy As EDL - Oxygen Forensics, Inc.
Facebook0Tweet0LinkedIn0 The problem that has been plaguing investigators is the fact Android devices offer different mechanisms of data protection. For this reason, it is almost impossible to develop a single method of extracting and decrypting a device’s data. Of course, in many cases data...
blog.oxygen-forensic.com
Qualcomm USB flashing tool
32- and 64-bit ARM Open Platform Specifications. For software developers. For the maker community. For embedded OEMs. 64-bit ARM for $129.
www.96boards.org
Related
Hello all,
Lately I've been interested in running custom code on the *fun* processors of my phones (the modem baseband cores).
Problem: The firmware images are supposed to be signed by the OEM, and I needed to bypass this signature check.
I have developed tools to do it on instances of Qualcomm MSM8960 based phones, namely the Sony Xperia SP and the Samsung s7275r.
Here are the repositories:
tzexec : A kernel module that exploit a bug in Qualcomm TrustZone code (discovered by Dan Rosenberg and described here: Reflections on Trusting TrustZone
pymdt : A python library to unsplit/patch/split firmware images and fix the hash segments.
(This is developer-intended code, don't ask me what you can do with it.)
Msm8960? Like the Verizon s4...... Hmmm
totor48 said:
Hello all,
Lately I've been interested in running custom code on the *fun* processors of my phones (the modem baseband cores).
Problem: The firmware images are supposed to be signed by the OEM, and I needed to bypass this signature check.
I have developed tools to do it on instances of Qualcomm MSM8960 based phones, namely the Sony Xperia SP and the Samsung s7275r.
Here are the repositories:
tzexec : A kernel module that exploit a bug in Qualcomm TrustZone code (discovered by Dan Rosenberg and described here: Reflections on Trusting TrustZone
pymdt : A python library to unsplit/patch/split firmware images and fix the hash segments.
(This is developer-intended code, don't ask me what you can do with it.)
Click to expand...
Click to collapse
Thanks to you for dis. Where can one get more general information about reading, mounting modem partitions?
Welcome everyone!
This project has started, becouse we need real solution for the problem. The problem of hard bricked Moto devices. It is like a curse.
When my device bricked I have done solid research, I have gathered many informations and files essential to revive my cellphone but 5 years experience of linux, rooting, compiling kernels and roms weren't enough to make it work.
But nevermind. I am even more determinated and I am asking ALL of You guys here to help me. Together we will come to solution.
Here is what I got, happy reading :
DICTIONARY:
PBL - Primary bootloader of the chip - this is like BIOS for phone so it checks chip for damage and problems and then it tries to load SBL but if SBL is corrupted or checksum doesn't match, PBL invokes Qualcomm HS-USB QDLoader 9008 emergency mode. PBL is hard flashed into SoC and can't be corrupted by firmware.
SBL - Second stage bootloader wich is more advanced than PBL. It initializes phone hardware and ABOOT.
ABOOT - Application bootloader (HBOOT). You probably know this one well. Android botloader.
Full mmcblk0 backup - Backup of whole phone flash storage byto to byte.
blankflash - method of repairing msm phones in 9008 state
programmer.mbn - Special type of software programmer that is being sent to chip in Qualcomm 9008 emergency mode. There it comunicates with pc via firehose protocol. Each phone has set of their own programmers, they are unique to phone and other programmers don't work. These programmers are signed so tampering it results in not working one.
firehose protocol - it is used to tell programmer what operations it must do on chip.
singleimage.bin - this package contains instructions for programmer and set of files it need (for example to replace)
gpt_main0.bin - Partition layout
rawprogram0.xml - instructions for programmer
patch0.xml - I don't know yet
STAR.exe - Application for managing and editing contents of singleimage.bin aka blankflash files
QPST - Flash tool from Qualcomm it basic function is to handle blank-flashing in a better way, also it allows for in-depth debugging of the process
Qualcom Premium Tool - Program made by Mppg Myanmar that is capable of making unlocking bootloader, OEM locks, making backup/restore of chip firmware, handling blank-flashing in VERY specific way (creating instructions for programmer), reading eMMC structure from firmware (can generate gpt layout so very useful!!!), modyfing FW and removing Xiaomi account. It also contains ALL programmers
for more:
https://forum.xda-developers.com/android/general/info-android-device-partitions-basic-t3586565
https://alephsecurity.com/
https://github.com/alephsecurity/firehorse
https://github.com/aravindvnair99/Motorola-Moto-E-XT1022-condor-unbrick
INFO:
1. What causes the brick
I bet 100$ that you hard-bricked your Moto Z Play by installing OTA updates after downgrading firmware. This is only known reason for me at the time of writing this. There is most probable reason why it happens, look:
There are two most common chips on which smartphones are built - Qualcomm and Mediatek. While Mediatek chips are "modification friendly" and simple, Qualcomm chips are somewhat more advanced and have many features that can be enabled or disabled during prorammming in factory. One of them is PBL signature checking. During programming of your phone, proper signatures of SBL are written to it. When someone tries to override default SBL with the new one, it checksums are compared with that stored. If they match, new one is flashed, if not, then update does not happen.
Ok, but what it has to do with brick?!
I explain:
1. You decide to downgrade your firmware
2. During flashing, everything goes "well" (Phone boots), but trully update is partial:
FW in chip is (obviously) more recent that the one you downgrade to, and SBL signature is different (updated), so when it is compared to the signature of SBL from FW you want to flash, it don't match. That don't rise error and flashing continues. Only partition that stays untouched is bootloader, but all other partitions get replaced by those in FW zip. SBL is still compatible with the new partition offsets and partition layout overall so phone functions normally.
3 When OTA is executed, it checks the version of currently installed firware. The most reliabe way to do it is to check checksum of SBL which is pretty logical becouse it's checksum is like "fingerprint" of firmware. Normally, if it would detect the old firmware, OTA would be stopped, but newer SBL tricks it and OTA installs anyway.
4 Results are horrible, becouse OTA does not check GPT table and flashes partitions in bad sectors, corrupting FW.
This causes bootloader to go into Qualcomm HS-USB QDLoader 9008 safe mode.
5 Viola! Hard brick!
2. How to fix it?
That is jolly good question! What we have to do is to reflash full chip firmware. Suprisingly I see some solutions, but those need to be developed:
A) SD-BOOT
It turns out that our fancy chip can probably boot from SD-CARD! The procedure works like this:
- When chip starts, one of the very first things it does is loading the memory, so it can actually work. The trick, is that chip loads it from specific disk, marked with exact name (I don't remember which, but I will do research). Speccially repared SD-CARD can appear with that name, so chip boots from it, not from internal memory. (This trick is proved to work on this model)
How to do it?
- Get full dd of working phone - it must be phone with the SAME chip and very likely the same model
- flash it to SD-CARD of 32GB or more, class 10 speed or higher, directly to card, not partition
- put card in phone, turn it on and wait
- you should see HBOOT
- select fastboot and flash new FW via it
- viola!
!!!THIS IS COMPLICATED PROCEDURE, I WILL MAKE DETAILED THREAD SOON, BUT FOLLOW IT ONLY IF YOU KNOW WHAT ARE YOU DOING!!!
B) FIREHOSE/SAHARA ATTACK
This could be achieved by sending payload via Firehose programmer that would allow to break verification of SBL or somehow allow SBL to be flashed. Now, PBL blocks attempts to update SBL. I have thesis that it is becouse PBL do not allows for SBL downgrade, so it's version must be higher, but we try to flash same version of SBL so it doesn't work. That thesis needs confirmation.
C) CRAFT BLANKFLASH
This would be last resort. It will work for sure, but this method needs knowledge and I don't know if it is doable.
STEP 1: Get white-listed blankflash checksums from OTA (we would need to reverse engineer those)
STEP 2: Break hash
STEP 3: Craft blankflash with needed hash
STEP 4: Flash
NEVER USE BLANKFLASH (ATTENTION!)
DO NOT try any blankflash files. They can make situation a lot worse and even physically (!) dmage your phone.
D) JTAG
Medusa Box etc.
E) Qualcomm Premium Tool
This can even work, but it is untested and there is a slight chance that can worsen state of phone (needs confirming).
The tool is very advanced and I need to gather info about usage, so very probable to be a good solution if we will learn how to use it!
E) METHOD 7
Interesting method from this guy: (7th option, I have contacted him if it is compatibile)
https://github.com/aravindvnair99/Motorola-Moto-E-XT1022-condor-unbrick/blob/master/Unbrick%20methods.md
3. DOWNLOAD
(Links will be aded *soon*)
XDA:DevDB Information
Unbrick Developement for Moto Z Play (addison) Full-Brick, Tool/Utility for the Moto Z Play
Contributors
Bobernator, Artim_96, Camarda
Version Information
Status: Testing
Created 2019-05-03
Last Updated 2019-05-03
Hi, same problem. Did you solve it?
Hey guys,
Been working on a personal project, and came to this question, which also happens to be the first Im having to post about online..
Is it even possible to boot the kernel in EL2 mode with the sdm845 SoC ?
My end goal here being running qemu - which I'm already are - under KVM ( The tough part )
I Already tried enabling the necessary options in the kernel build, flashing them, with no success.
What I've been reading around is that since the system uses the TrustZone environment, this may not be possible.
[Kernel] Stock Android Pie kernel with KVM
I have been trying for some time now to enable KVM on the Pixel XL, by compiling the stock Google kernel and adding the KVM switches to "marlin_defconfig". Unfortunately, while the kernel with KVM compiles properly and could be flashed, /dev/kvm...
forum.xda-developers.com
On the other hand, under the chipset specifications I've been seen that only EL3 is really protected by the security implementations.
Documentation – Arm Developer
developer.arm.com
I know some exynos chipsets support booting in EL2 out of the box, but I see not much development for Qualcomm based ones.
ARM KVM (Kernel Virtual Machine) enabled Kernel for Samsung Galaxy S8
Hi. Can someone that compiles kernels for this phone compile one with KVM enabled and make it available to download? It should not be too hard. This would really make these machines appealing if you could spin up VMs on them especially...
forum.xda-developers.com
KVM
Limbo is a QEMU-based emulator for Android. It currently supports x86, ARM, PowerPC, and Sparc emulation for Intel x86 and ARM android devices. See wiki https://virtualmachinery.weebly.com for APK...
github.com
So, summing up, is it possible, and if so through what actions, to boot a kernel under LE2 mode on a snapdragon processor?
Also, side note, I'm willing to brick my device, if its worth the try, and adds to any progress of future development.
Edit1: Added links- sources
Cheers!
Sadly, with SDM845 it is impossible to enable KVM in android Linux kernels. As the kernel is booted under EL1 by the firmware. But with this firmware https://github.com/msm8916-mainline/qhypstub, msm8916/msm8935 can.
Is there a way to enable KVM for SM8450 (Snapdragon 8 gen 1) ? I would like to use Qemu on Galaxy Tab S8
linlin3309 said:
Sadly, with SDM845 it is impossible to enable KVM in android Linux kernels. As the kernel is booted under EL1 by the firmware. But with this firmware https://github.com/msm8916-mainline/qhypstub, msm8916/msm8935 can.
Click to expand...
Click to collapse
How i check my device booting with EL1 or EL2 ?
Via `dmesg` ?
Tl;dr = I have studied the boot process. I understand the Qualcomm SOC boot process PBL > SBL/XBL > And so on. I am trying to get a disassembly of the SBL. I dumped the EMMC and can view all its partitions. Now I am stuck at the 80 bytes header containing the "Loading Address". I can't figure out where and how the processor jumps to this loading address.
Greetings XDA community. This post is more relevant to the developers and power users of android and people who work as embedded developers/security researchers/reverse engineers in general.
Background - I am deeply interested in OSDev and running my own code on the hardware I own. Just like I am building my own bootloader for my PC, I had also been wanting to study the android boot processs for quite some time. In the last few days I got to it and found that the whole low level ecosystem of Android, iOS and Smartphones is really toxic and full of proprietary stuff. But I am still determined to make my own bootloader for my smartphone even if it only displays the good old "Hello World" on that little black display. I am not concerned about bricking my few phones as they are pretty much useless to me now and can be used for RE purposes.
Some Useful Links - https://blog.quarkslab.com/analysis-of-qualcomm-secure-boot-chains.html , https://alephsecurity.com/2018/01/22/qualcomm-edl-1/ , https://lineageos.org/engineering/Qualcomm-Firmware/
Technicals - I copied the whole EMMC from my rooted phone (Xiaomi Mi4) and studied the boot process. So apparently the boot process goes something like PBL --> SBL --> And so on... I found the partition labelled SBL in the dump. I am trying to get code execution at the lowest level possible but it seems I might not be able to resurrect the phone easily if I mess with the SBL (as the phone might not even go into EDL mode then). So I am first considering taking control after the SBL (and before Aboot) with my own code (even if it includes some certificate/proprietary blobs from the manufacturer). But for this I have to understand what exactly the SBL is doing in my particular processor's case. So in the SBL partition is an 80 byte header (source : http://vm1.duckdns.org/Public/Qualcomm-Secure-Boot/Qualcomm-Secure-Boot.htm). This header contains a loading address for the processor. What I can't figure out is how the processor jumps to this address. The source mentions to "remove the header and then load the file in IDA Pro" but what file are they talking about (The EMMC dump? The partition? Something else?). How does the CPU use this loading address? In my particular phone the loading address is : 00 C0 00 F8 (
https://imgur.com/a/ngfFsj5
).
Please shed some light on this issue.
I've barely read it and never dealt with qualcomm before but:
Based on the article linked they seem to be referring to SBL1... but also it should be noted according to them PBL authenticates SBL1 so unless it's unlocked or you have a private key to sign your own SBL1 probably SOL.
Also, can't you just replace kernel/rootfs and achieve the same results utilizing the built-in bootloader?
@vigilante_stark Thread closed as duplicate of
Reverse Engineering Android Boot Process - Need Help
Tl;dr = I have studied the boot process. I understand the Qualcomm SOC boot process PBL > SBL/XBL > And so on. I am trying to get a disassembly of the SBL. I dumped the EMMC and can view all its partitions. Now I am stuck at the 80 bytes header...
forum.xda-developers.com
Please review the XDA Forum Rules with special emphasis on rule no. 5 and post only ONCE! Thanks for your cooperation.
Regards
Oswald Boelcke
Hello everyone!) I accidentally deleted the partition from the system boot, etc. phone in edl now
When I try to flash through qfil, I get the error fhloader process failed, and before that Something failed. The target rejected your <configure>. Please check the log for more information
Drivers from Lenovo
There is no EDL authentication
Tried to flash device's Stock ROM via QFIL tool? It's Qualcomm SoC based device?
jwoegerbauer said:
Tried to flash device's Stock ROM via QFIL tool? It's Qualcomm SoC based device?
Click to expand...
Click to collapse
When I try to flash through qfil, I get the error fhloader process failed, and before that Something failed. The target rejected your <configure>. Please check the log for more information
You must not repeat things already told.
jwoegerbauer said:
You must not repeat things already told.
Click to expand...
Click to collapse
ok
[No auth collection] Xiaomi No Auth Firehose Files for Qualcomm based phones.
What is this file? As we all know that Xiaomi has blocked offline flashing with authentication to flash their device. This files will ultimately help you to fix the Mi Account Authorization issue and hence unbrick your Xiaomi device via EDL mode...
forum.xda-developers.com
Xiaomi Firmware Updater
The ultimate script that provides firmware packages for Xiaomi devices.
xiaomifirmwareupdater.com
GitHub - bkerler/edl: Inofficial Qualcomm Firehose / Sahara / Streaming / Diag Tools :)
Inofficial Qualcomm Firehose / Sahara / Streaming / Diag Tools :) - GitHub - bkerler/edl: Inofficial Qualcomm Firehose / Sahara / Streaming / Diag Tools :)
github.com