General MSM TOOLS

[Renate]

I dont wanna make the mods think weve veered off topic, so hopefully they take notice that you are apparently attempting to crack the Sahara/Firehose protocols....

Well, right now I'm trying to bring some clarity to Firehose loaders.
The identification and organization of them is a bit of a mess.

Edit: Ok, resolved.
Fireshose loaders are often named after 64 bit HWID and 64 bit "Hash" (as reported by your EDL client).
For instance: xiaomi\0008c0e100010000_a7b8b82545a98eca_fhprg_peek.bin
Most (but not all) of the time the hash part of the naming agrees with SHA256 hash of the complete root CA.
That is the last cert (probably the third) of the cert chain in the file.
There appears to be two cases where this is not so.
When SecureBoot is not enabled the "Hash" will be zero and any HWID compatible loader will work.
It's possible that newer loaders encrypt the hash.

FWIW, I just put up a new qcomview.exe (in the sig).
You can now check fingerprints: qcomview /f loader.bin

 

[Canuck Knarf]

@ beatbreakee ...hey night owl...up all night ...sleep all day...lol
I got OPT for you

 

[beatbreakee]

@ beatbreakee ...hey night owl...up all night ...sleep all day...lol
I got OPT for you

yay... canuck!! lol.. thank you bro... save me from myself... i was like literally 30 secs from going on some crusade against evil doers... haha,.. the night is my life source

 

[Canuck Knarf]

yay... canuck!! lol.. thank you bro... save me from myself... i was like literally 30 secs from going on some crusade against evil doers... haha,.. the night is my life source

ok... i order OTP...for you///its going to take a couple of minutes..to go through

 

[beatbreakee]

oh and hey.. for clarity guys.... OTP if you get them from the right ppl... last 24 hrs, and can be used many times as you want, and also afaik can be used on several machines at the same time.... (this again is part of the scam that the MSM MAFIA are running,.... One person is paying for monthly access to an account.. then that account is hooked into their OTP generator and those guys are just re-selling access to a token someone else paid for.... the amount of time you have left depends on whether u got it from a scammer, or just a Mafioso...) <the otp thing is so no one can change the password... smart i guess>

 

[Canuck Knarf]

oh and hey.. for clarity guys.... OTP if you get them from the right ppl... last 24 hrs, and can be used many times as you want, and also afaik can be used on several machines at the same time.... (this again is part of the scam that the MSM MAFIA are running,.... One person is paying for monthly access to an account.. then that account is hooked into their OTP generator and those guys are just re-selling access to a token someone else paid for.... the amount of time you have left depends on whether u got it from a scammer, or just a Mafioso...)

Dose these last 24 hrs and can be used on other MSM ...? or several Machines at same time..??

 

[Canuck Knarf]

If they are not good ones...I think I can try another guy and get OTP from...?

 

[beatbreakee]

Well, right now I'm trying to bring some clarity to Firehose loaders.
The identification and organization of them is a bit of a mess.

Edit: Ok, resolved.
Fireshose loaders are often named after 64 bit HWID and 64 bit "Hash" (as reported by your EDL client).
For instance: xiaomi\0008c0e100010000_a7b8b82545a98eca_fhprg_peek.bin
Most (but not all) of the time the hash part of the naming agrees with SHA256 hash of the complete root CA.
That is the last cert (probably the third) of the cert chain in the file.
There appears to be two cases where this is not so.
When SecureBoot is not enabled the "Hash" will be zero and any HWID compatible loader will work.
It's possible that newer loaders encrypt the hash.

WOW .... really.... so then BASICALLY all you have to do is unlock your BL as early as possible, (so you dont brick and get stuck) ... then flash vbmeta, and disable DM-verity so your secure boot will turn off... then you can grab one of those loaders from github, or if you're feelin frisky, disassemble a firehose , then go and strip out all the bloat crap from the rawdata, and patch xml files... and maybe build a custom ROOT map with all new partition sizes, but this time with a nice tech build, or tweak all the right kernel settings and make a Pure Gaming build...

like it honestly sux how they were able to TRASH such a high performance snapdragon processor. I was looking at the actual specs on qualcomm developer network, and technically this phone should be SMOKING the galaxy s22 and damn near rivaling the s23... and the 10T should be barely above the 10 Pro... but with ALL the funky combination of garbage apps they have forced on AUTO LOAD, and AUTO RELOAD... and even "UNLOAD ME AGAIN, AND I WILL WAKE UP 3 OTHER RANDOM APPS, HUMAN!!!" mode! Like whats the deal with that for real... i have apps to force close and hibernate apps i choose in a set of like 10 or so, and in no less than 1 min later, all the apps i closed are BACK... and somehow they started apps I havent loaded in MONTHS.... AND turned their notifications on for ALL OF THEM!

im tempted to just leave them alone sometimes and let em run... cuz they somehow always rally up some local friends and forge a hostile takeover of my phone processes... Im seriously waiting for the day my TTS just activates itself and says,

"It is futile, Human! Just concede the victory to us and embrace us as your new Overlords. You cannot escape our reach for we are Legion! You kill one of our processes, and 5 will awake from hibernation..... You attempt to run an Auto Task Disabler, and we deactivate your Parents home security system, and send a fleet of weaponized drone quad copters to pay then a visit! Do not attempt to thwart us... we know when you're asleep, from your resting heart rate, thanks to your Samsung Gear Watch!! BOW BEFORE TRACHANON !"

 

[beatbreakee]

Dose these last 24 hrs and can be used on other MSM ...? or several Machines at same time..??

yes... thats why i mentioned it here instead of dm.. so ppl might catch on and know to come ask someone in private about WHO... instead of just blindly getting ripped off by some rando!

 

[Renate]

so then BASICALLY all you have to do is...

No. SecureBoot is the Qualcomm signing of ELF loadable modules.
It aplies to obvious stuff like xbl/abl/Firehose, but also all the radio/modem/phone stuff.
It is enabled in OTP (one-time programmable fuses) on the chip.
The SHA256 hash is burned at the same time.
Probably very few things are left with SecureBoot off.

dm-verity, AVB, FEC are all other things.

There was an exploit on MediaTek of a buffer overrun on USB control endpoint.
Those kind of anomalous USB messages can usually not be generated by stock implementations.
You need a lower level driver or a hardware device.
Such an exploit could conceivably be possible with Qualcomm but it would take a bunch of effort.
You'd want to start with a device with accessible UART and access to the reset line.

 

[Mirak97]

i

No. SecureBoot is the Qualcomm signing of ELF loadable modules.
It aplies to obvious stuff like xbl/abl/Firehose, but also all the radio/modem/phone stuff.
It is enabled in OTP (one-time programmable fuses) on the chip.
The SHA256 hash is burned at the same time.
Probably very few things are left with SecureBoot off.

dm-verity, AVB, FEC are all other things.

There was an exploit on MediaTek of a buffer overrun on USB control endpoint.
Those kind of anomalous USB messages can usually not be generated by stock implementations.
You need a lower level driver or a hardware device.
Such an exploit could conceivably be possible with Qualcomm but it would take a bunch of effort.
You'd want to start with a device with accessible UART and access to the reseti line.

is there anyway of turnning off secureboot?

 

[Renate]

Is there anyway of turning off secureboot?

Not, really. The most realistic option is to remove the processor and replace it with an unprogrammed new one.
I'm not sure how easy it is to call up Qualcomm and ask them for one of their processors.
There are companies that do rework and could replace the processor but it's probably not cheap.
None of this makes any sense for a user, but there might be a reason to do this as part of an effort to crack security on something.

 

[Mirak97]

Not, really. The most realistic option is to remove the processor and replace it with an unprogrammed new one.
I'm not sure how easy it is to call up Qualcomm and ask them for one of their processors.
There are companies that do rework and could replace the processor but it's probably not cheap.
None of this makes any sense for a user, but there might be a reason to do this as part of an effort to crack security on something.

what about patching firehose files themeselves to make them bypass secureboot
i see a lot of them when searching for no auth loaders

 

[Renate]

what about patching firehose files themeselves to make them bypass secureboot
i see a lot of them when searching for no auth loaders

The word "patched" gets thrown around a lot.
My understanding is that the "patched" loaders were not actually patched but simply that they were built that way with more features enabled.

So the levels of security go like this:

1. All modules loaded by the ROM bootloader must have valid hashes on all program segments (even if SecureBoot is off)
2. If SecureBoot is on, the hashes above must be signed by the certificate chain which must be verified with the hash burned into the processor.
3. The OEM can add additional security to the Firehose loader like "VIP" or "getsigndata" requiring remote authorization.

The word "secure" gets thrown around a lot.
There are many contexts for "secure" (ro.secure, ro.adb.secure, fastboot secure) but only one SecureBoot.
If you have a hardware root console connected (UART) it may type out the status of SecureBoot when booting.

Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset),  D - Delta,  S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.XF.1.4-00246-S660LZB-1
S - IMAGE_VARIANT_STRING=Sdm660LA
S - OEM_IMAGE_VERSION_STRING=cibuild
S - Boot Interface: Unknown
S - Secure Boot: Off
S - Boot Config @ 0x00786070 = 0x000001c1
S - JTAG ID @ 0x00786130 = 0x000cc0e1
S - OEM ID @ 0x00786138 = 0x00000000
S - Serial Number @ 0x00784138 = 0x12345678
S - OEM Config Row 0 @ 0x00784188 = 0x0000000000000000
S - OEM Config Row 1 @ 0x00784190 = 0x0000000000000000
S - Feature Config Row 0 @ 0x007841a0 = 0x007030000b580100
S - Feature Config Row 1 @ 0x007841a8 = 0x00000000000000c0
S - Core 0 Frequency, 3715 MHz
S - PBL Patch Ver: 5
S - I-cache: On
S - D-cache: On

Another way to find out if SecureBoot is actually on your device is to take a Firehose loader that works.
Find some innocuous thing to modify (better if it's something that you will later notice).
I change the spelling of some message that the loader will print out.
This will break the hashing, so you check* it with QcomView and hex edit the hashes until they are correct.

C:\>qcomview /h loader.bin
64 bit ELF, SHA256
 0  00000000  00000318  a117dbc5 e643e404 361bfe30 45fbda01 4c153842 59a4cbe8 09b7da55 a2dd413e  OK
 1  00001000  00001ac8
 2  00003000  0005709c  7b833734 f2763b9e 35f3310c f6fb22a9 a514eac0 3eddbe46 b5ff339b 3c7b045c  OK
 3  0005a0a0  00000000
 4  0005a0a0  00009f00  6296c006 31852f79 b99691c3 e8d598f2 9d323e9a ba0358aa b742901f 506709d5  OK
 5  00063fa0  00009908  41176495 3e07ad84 8923398e ce854131 91066dca 43f253fa c027c4f4 a3c21483  OK
 6  0006d8b0  00000000
 7  0006d8b0  00001e7c  fe77c473 b02e4a71 d3f287e4 cf85ccbe b5a43326 53930bd8 d68e4e40 6e71a0b8  OK
 8  0006f730  00000000
 9  0006f730  000188d8  1bfef74c ed467a22 8616419d e71ab1ea 22a717e5 4874c704 541793ed f5d5c5e5  OK
10  00088010  00000000
11  00088010  00000000
12  00088010  00012dc0  b72cb77e 81026632 446c3462 cc6c83fc d7904333 cb8807cc 27d6e4c9 189c7ca4  OK

This will still leave the signing of the hashes all broken and you can't sign it because you don't have the private key.
If your modded Firehose loader loads and works, congratulations, your device has SecureBoot off.
This is probably not true of any mainstream device.

Edit: *I've added actually rewriting the hashes to this utility.

 

[oneplushypergaming]

yes... thats why i mentioned it here instead of dm.. so ppl might catch on and know to come ask someone in private about WHO... instead of just blindly getting ripped off by some rando!

hey, i sent you the account sorry it took me awhile sick over the break

 

[Mirak97]

The word "patched" gets thrown around a lot.
My understanding is that the "patched" loaders were not actually patched but simply that they were built that way with more features enabled.

So the levels of security go like this:

1. All modules loaded by the ROM bootloader must have valid hashes on all program segments (even if SecureBoot is off)
2. If SecureBoot is on, the hashes above must be signed by the certificate chain which must be verified with the hash burned into the processor.
3. The OEM can add additional security to the Firehose loader like "VIP" or "getsigndata" requiring remote authorization.

The word "secure" gets thrown around a lot.
There are many contexts for "secure" (ro.secure, ro.adb.secure, fastboot secure) but only one SecureBoot.
If you have a hardware root console connected (UART) it may type out the status of SecureBoot when booting.

Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset),  D - Delta,  S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.XF.1.4-00246-S660LZB-1
S - IMAGE_VARIANT_STRING=Sdm660LA
S - OEM_IMAGE_VERSION_STRING=cibuild
S - Boot Interface: Unknown
S - Secure Boot: Off
S - Boot Config @ 0x00786070 = 0x000001c1
S - JTAG ID @ 0x00786130 = 0x000cc0e1
S - OEM ID @ 0x00786138 = 0x00000000
S - Serial Number @ 0x00784138 = 0x12345678
S - OEM Config Row 0 @ 0x00784188 = 0x0000000000000000
S - OEM Config Row 1 @ 0x00784190 = 0x0000000000000000
S - Feature Config Row 0 @ 0x007841a0 = 0x007030000b580100
S - Feature Config Row 1 @ 0x007841a8 = 0x00000000000000c0
S - Core 0 Frequency, 3715 MHz
S - PBL Patch Ver: 5
S - I-cache: On
S - D-cache: On

Another way to find out if SecureBoot is actually on your device is to take a Firehose loader that works.
Find some innocuous thing to modify (better if it's something that you will later notice).
I change the spelling of some message that the loader will print out.
This will break the hashing, so you check it with QcomView and hex edit the hashes until they are correct.

C:\>qcomview /h loader.bin
64 bit ELF, SHA256
 0  00000000  00000318  a117dbc5 e643e404 361bfe30 45fbda01 4c153842 59a4cbe8 09b7da55 a2dd413e  OK
 1  00001000  00001ac8
 2  00003000  0005709c  7b833734 f2763b9e 35f3310c f6fb22a9 a514eac0 3eddbe46 b5ff339b 3c7b045c  OK
 3  0005a0a0  00000000
 4  0005a0a0  00009f00  6296c006 31852f79 b99691c3 e8d598f2 9d323e9a ba0358aa b742901f 506709d5  OK
 5  00063fa0  00009908  41176495 3e07ad84 8923398e ce854131 91066dca 43f253fa c027c4f4 a3c21483  OK
 6  0006d8b0  00000000
 7  0006d8b0  00001e7c  fe77c473 b02e4a71 d3f287e4 cf85ccbe b5a43326 53930bd8 d68e4e40 6e71a0b8  OK
 8  0006f730  00000000
 9  0006f730  000188d8  1bfef74c ed467a22 8616419d e71ab1ea 22a717e5 4874c704 541793ed f5d5c5e5  OK
10  00088010  00000000
11  00088010  00000000
12  00088010  00012dc0  b72cb77e 81026632 446c3462 cc6c83fc d7904333 cb8807cc 27d6e4c9 189c7ca4  OK

This will still leave the signing of the hashes all broken and you can't sign it because you don't have the private key.
If your modded Firehose loader loads and works, congratulations, your device has SecureBoot off.
This is probably not true of any mainstream device.

so all of the "patched" firehose files are just leaked ones from the manufacturers (i mean they arent modified by some user to make it work)

 

[Renate]

so all of the "patched" firehose files are just leaked ones from the manufacturers (i mean they arent modified by some user to make it work)

All the loaders that I can get my hands on show signing by expected manufacturers.
It would take access to the (super secret) company private key to sign anything.
OTOH, if you don't have Secure Boot, patch away. I just patched the abl on my non-SecureBoot device.

Ok, I just found a few loaders that look like the certificates were modified by a person.
But I have no idea if this was just a half-baked experiment or what.
If you have SecureBoot you can't screw around with the certificates.
And if you don't have SecureBoot you don't have to.

As always, I'm open to correction.

 

[Mirak97]

All the loaders that I can get my hands on show signing by expected manufacturers.
It would take access to the (super secret) company private key to sign anything.
OTOH, if you don't have Secure Boot, patch away. I just patched the abl on my non-SecureBoot device.

Ok, I just found a few loaders that look like the certificates were modified by a person.
But I have no idea if this was just a half-baked experiment or what.
If you have SecureBoot you can't screw around with the certificates.
And if you don't have SecureBoot you don't have to.

As always, I'm open to correction.

im not really an expert here and probably i dont know what im talking about but coud the leaked no auth loader that are from the same manufacturer have the same signing and could it be cloned or transfered to an another loader ?

 

[Renate]

im not really an expert here and probably i dont know what im talking about but coud the leaked no auth loader that are from the same manufacturer have the same signing and could it be cloned or transfered to an another loader ?

Presumably all OEMs have a full-featured Fireshose loader for their device for development and repair.
Maybe they chop out some features for the one they release to the general public.

If they are being really obnoxious they add extra authorization into the public version and say that you have to use our handy-dandy custom EDL client which will phone home to ask us if you're allowed to use it.
I presume that there is some solid cryptography behind the whole authorization system.
I saw one USB capture for a differrent device that uses a custom Firehose extension of getsigndata.
I've not seen any USB captures for the device in this thread or even an example of how this device reacts to a generic EDL client.

Theoretically, the whole signing chain is pretty bomb-proof.
I think the chance is slim, but a buffer overrun exploit using some unexpected USB protocol violation seems most likely to me.

 

[DenisPDA]

Hi all
What kind of menu is this in FastbootD

Video https://drive.google.com/file/d/1RuranD8wmdnXRpFqMvjhBBhjLi5w5_m4
Be sure to watch to the end

Source