yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] munjeni:
Ok, I tried via fastboot but its not alloved, but will try via zip! I want to have posibility to install "dump" from another phone that is not aria, just want to have that posibility without needs for using jtag! I tried to flash radio from htc hd mini but its fail to install (had s-off and revolutionary, allso patched hboot to get it possible "changing model id...etc", but that was not posible, its like there is some security for radio flashing that still I not understand - maybe some radio hashes not match... :))

I can edit misc partition from recovery/android without problem when I have s-on + stock hboot too! Why you not use this misc partition method to install modified hboot ? Please see log when I performed some operations to misc partition but phone have stock hboot:

~ # erase_image misc
erase_image misc
~ # flash_image misc /mtd0
flash_image misc /mtd0
flashing misc from /mtd0
mtd: successfully wrote block at c7e9000000000
mtd: successfully wrote block at c7e9000020000
mtd: successfully wrote block at c7e9000040000
mtd: successfully wrote block at c7e9000060000
mtd: successfully wrote block at c7e9000080000
mtd: successfully wrote block at c7e9000000000

I think its not true... now I playing with gobi interface and at@simlock?aa giving me 0 but still my stock bootloader is not unlocked! So I think hboot looking for sure on an another flag!

Guyssss, I sent rtask c from linux to phone and I'm now in gobi interface (have ttyUSB0 ttyUSB1 ttyUSB2, gobi is ttyUSB2... without rebooting phone I conected phone to usb of the windows machine and my windows recognised it as a unknown interface... before all that steps I found an very interested post where guys have bricked htc evo 3d phones and he found a way to unbrick it... please read this to understand about what I say -> http://xdaforums.com/showthread.php?t=1188510 ... lets back to my process while in gobi interface... my windows asked me to install drivers for unknown interface... found drivers here -> http://xdaforums.com/showpost.php?p=14386994&postcount=14 ,installed these drivers and boom :eek: I have 2 virtual com ports (hsusb diagnostic port and hsusb nmea port) !!! QPST software maded by Qualcomm use these ports! Will download that software and will try something to do using that... I forgot where I read that qpst software is used for unbricking an htc phone (forgot which one is) but guys sucesfully flashed his bricked devices with that software !
[HTC Wildfire S] beaups:
I'm not sure why you expect this to work. Hboot itself is signature checked by SBL (SBL 3 specifically). All that will happen if you manage to write an exploited hboot to NAND is bricking your device on the next reboot.

If you change so much as ONE byte in hboot, you will brick.

Exploits you've seen that involve "special" hboots are disabling security or accomplishing s-off in another manner prior to writing the "special" hboot.
[HTC Wildfire S] munjeni:
Downloaded QPST but still its look like unsuported for msm7227 but I experimenting now with old Revskills software (PSAS) because have working usb port utils, using PSAS I can send a lot of diag commnads to usb diagnostic port of the phone that is now in gobi switch, hmmm have no idea from where to start or what can I do using diag commands :)
[HTC Wildfire S] kalaker:
With S-OFF + Unlocked Bootloader, I have many times done "fastboot flash radio radio.img" or "fastboot flash hboot hboot.nb0" or something like that. I believe HBOOT and radio are in the "unmapped memory area" you are talking about. I have done with a stock HBOOT that is S-OFF and an MFG HBOOT. Granted, I am on marvelc, but the rules of flashing to radio/HBOOT are still the same.

I have flashed many HBOOTs (stock versions, MFG, and a custom HBOOT), and I have never had an issue. nhb, you are correct. You will never brick unless the coding of the HBOOT is bad.
[HTC Wildfire S] no.human.being:
Yes with both S-OFF and bootloader unlock at the same time you can flash the Radio, HBOOT, splash, etc. via Fastboot.

Bootloader unlock allows you to use Fastboot, but without S-OFF you will only be able to flash the "visible" partitions, like "recovery", not the "unmapped" ones, like "radio".

S-OFF allows you to access the partitions that are part of the "unmapped" memory area (Radio, HBOOT, splash, etc.), but does not grant you Fastboot access, so you will have to update these partitions by providing a PG76IMG.nbh to the bootloader on the phone's SD card.

When you combine both bootloader unlock and S-OFF, you will be able to flash all partitions (like S-OFF) via Fastboot (like bootloader unlock). Of course you can still flash them via PG76IMG.nbh, but Fastboot access is also possible.

What I wanted to say is that S-OFF doesn't replace bootloader unlock or vice versa. Even though either one is sufficient for, say, installing a custom ROM, you only get the most of your device if you have both of them. ;)
[HTC Wildfire S] beaups:
Nhb: I wish you were right, but you aren't.

Sbl1, 2, and 3 are all heavily modified by HTC and signature check each other prior to execution. HTC frequently updates these sbl partitions in ruu updates as well. Sbl3 sig checks hboot before it is allowed to execute, unless, of course, the device is soff. This is FACT. Revolutonairy did not simply send a modded hboot for soff. I'm not sure why you think that.

If you need more proof, understand that us hox users can do whatever we want to hboot via dd, as HTC screwed up and didn't apply wp to it. If we go so far as to even change ONE BYTE, say, even the version number, the device is bricked and sbl3 pits the device in emmc download mode.

You are barking up the wrong tree here.
[HTC Wildfire S] no.human.being:
"I think so" because we have analyzed what Revolutionary does to the phones. What do you think we have done in the almost 3k posts that have already been exchanged in this thread?

Why won't this happen when flashing modified HBOOTs via Fastboot? People have already done this (after S-OFFing their devices via Revolutionary or xtc-clip or other means or on a shipped S-OFF device) and it does NOT brick the device. Devices that are S-OFFed via Revolutionary aren't "actually" (Radio) S-OFF still they won't enter eMMC download mode. Especially the WFS will certainly never enter eMMC download mode. I will personally guarantee this, since it's not even an eMMC device. :D

Sorry, I'm not trying to discredit you. I'll even give you thanks for these hints as soon as I have some available. Seriously. But from our current perspective they just don't fit the picture.
[HTC Wildfire S] beaups:
I've read many of the posts. Revolutionary does more than just push a hacked hboot, if you aren't finding that, then you need to look more :)

If device is soff, of course you can run any hboot you like. But unless you do "something else" in addition to installing your hacked hboot, the device will brick every time. Sbl3 will not allow it to boot unless the device is soff.
[HTC Wildfire S] Tera Tike:
Here is the Diag file for the Aria. I hope it is of use.
[HTC Wildfire S] no.human.being:
What prevents us from patching SBL3 to no longer perform this validation? Ah right, the SBL is signed and the signature is verified by the DBL. What prevents us from patching the DBL to no longer perform this validation? Ah right, the DBL is signed and the signature is verified by the PBL. What prevents us from patching the PBL to no longer perform this validation? Ah right, the PBL is stored in actual read-only-memory.

But one thing doesn't fit the picture. PBL is definitely programmed at manufacturing time of the processor, no questions there. So the signature against which it verifies the DBL, which is itself part of the PBL, is also fixed at manufacturing time of the processor (and is most likely the same for every processor Qualcomm ships). Because of this, the DBL cannot be altered either, even though it is stored in NAND, but if you were to modify it, PBL would no longer load it due to signature fail. So the signature against which DBL verifies the SBL, which is itself part of the DBL, is basically also fixed at manufacturing time of the processor (and is most likely the same for every processor Qualcomm ships). Now you say that DBL verifies SBL and that SBL is "heavily modified by HTC". Something doesn't fit here. It's not as if Qualcomm was manufacturing "special processors" specifically for HTC that will only boot "HTC code". I just can't see how this works.

The chain of trust ends at the SBL. This is also what TJworld has found out.
[HTC Wildfire S] beaups:
What prevents us from modifying sbl is the fact that they live on wp (or nand locked) partitions.

And, btw, yes the write once pbl code IS customized for the OEM.
[HTC Wildfire S] no.human.being:
If you say that SBL can be updated via RUU then aARM can obviously unlock the SBL partitions, since HBOOT is running on aARM and RUUs are basically "update.zip"s pushed to HBOOT. So patching SBL is the same as patching HBOOT, don't see any difference.

The problem is that you now claim that if we were to modify HBOOT, SBL would no longer run it and if we were to modify SBL, DBL would no longer run it and if we were to modify DBL, PBL would no longer run it and PBL is stored in write-once memory so it cannot be modified. This would be a MUCH harder problem than the NAND locks.
[HTC Wildfire S] beaups:
Ruu disable wp/nandlock in the update process. It's always been that way. Once everything is authenticated, of course. This applies to them updating sbl, hboot, etc.

And yes, it is a hard problem. But the reality is sbl is looking for son/soff flag. That is what needs updated to allow booting with unsigned code.
[HTC Wildfire S] no.human.being:
But the flag is not accessible from aARM (MSM7227 NAND MPU is protecting the pages - this is not NAND WP, it's an actual MMU, don't see how one could ever bypass that) so any software solution is doomed to fail. Revolutionary does NOT update secu_flag. Radio is still S-ON on a phone that was S-OFFed by Revolutionary.
[HTC Wildfire S] beaups:
But sbl is looking for flag stored on partition, at least in newer models. We know exactly where that lives in the HOX and evo lte.

So perhaps you have a similar flag living somewhere or perhaps you are going to need to do some pbl command or radio comm trickery.

I'm no expert here, but I'm just trying to help point out what I know WON'T work, and flashing a hacked hboot isn't going to work. Not by itself, that is.

I think this is good dialogue.
[HTC Wildfire S] no.human.being:
Dito! Dev talk!!! :D

Btw, why is this even secured so much? What does Qualcomm want to prevent us from doing? I mean they're protecting a GSM firmware stack. GSM is 20 year old technology. You can't tell me that there's anything "interesting" in GSM technology these days. Anything that's worth "protecting". It's not as if GSM were fancy cool technology that you must keep secret from the competitors. It's rather pretty dated stuff and even the "newer" protocol stacks on top, well, they're perhaps not as dated as GSM itself, but they're not worth protecting either since you can consider them to be state-of-the-art. Certainly nothing that gives you a competitive edge over anyone else. This may be different for CDMA, where Qualcomm has some sort of monopoly, but interestingly CDMA phones are already broken, while GSM phones aren't.

So what are they trying to protect? Especially since many mobile chipsets have no security at all. Think OMAP! You can buy OMAP systems that ship with completely open firmware like UBOOT. I'm thinking of stuff like BeagleBoard (OMAP3530) or the successor PandaBoard (OMAP4430) which are development and proof-of-concept boards for the OMAP processor series. So if you want to get at an "unlocked" ARM processor, anyone is basically free to do so. Of course such a board costs a lot more money than a smartphone does (currently the boards aren't even available because the demand is so high), but in principle it's available on the free market. So it's not as if ARM devices with open firmware were somehow "dangerous" and must be "kept safe". :D

OMAP on Samsung handsets is also completely broken, Heimdall anyone? So if you actually want to mess with the GSM networks you have lots of options for doing so on hardware that's readily available. So why are they still trying to protect handset firmware against modification that much? I mean it doesn't sound as if you could do much damage to anyone by bypassing this.

I just don't get it.
[HTC Wildfire S] beaups:
I think it's as simple as manufacturers trying to lower repair rates and carriers trying to block unauthorized tethering and lowering their return rates as well.

That said I'm going to backpedal a little. On older devices, you could get away with an unsigned hboot and achieve that sort off "half" soff status. On newer devices, no chance. Your device falls somewhere in the middle, so it's hard to say...

---------- Post added at 09:00 PM ---------- Previous post was at 08:54 PM ----------

Also think about the exploit implications of widespread soff. A rogue developer or even website operator could write code that literally destroys sbl1, for example, if there's no hardware security in place. The fallout could be huge.
[HTC Wildfire S] Antagonist42:
OK ok slow down a bit.... quiet on the back row please, no arguing ;)

Can you tell me if the loaded code from ROM is a COMPLETE file of data or is it an assembled file with data added from NAND or already loaded when mARM boots?

The way the data is written to ROM is Qualcomm sets up the chip, HTC makes it's changes and sets security and Q-FUSES set or not (WFS/ACER Liquid Express not set as WP is linked to GPIO95), (if I remember rightly) HTC sets a key for the whole model range and this goes to QCOM, those changes are locked in by QCOM and keys are sent to HTC, HTC can update the phone although have we come across a phone that has had an update changing partitions etc? (found this out reading this was to do with sending a phone back for testing back to Qualcomm, they hold all the keys for CPU, HTC etc has to request them for testing THEN send the phone to be tested - or along those lines) given this if HTC redid the phone from boot it would need to change the offsets etc the phone booted up with if they changed partitions etc although security keys would remain the same to update or you would need a new CPU as you can't change the ROM.

With the above in mind it makes a lot of sense about calls in data for 'Header Information' that doesn't seem to be attached to the file (I know this may be at a higher OS/language level), if Header Information is loaded from one partition and Data from another the complete file could be simply written into IMEM/RAM when both parts of mARM and aARM load up data from BL's.

Point I think I'm trying to make is the required Specifics 'may' actually be all over the place and not just in ROM......

:confused: has anybody ever got the actual DATA from the ROM? and not what is in RAM.... :eek:
[HTC Wildfire S] no.human.being:
Ok.

Doesn't xtc-clip give "true radio S-OFF without hacked HBOOT"? Or is DIAG installing some kind of ENG HBOOT or something like that along the way?

Perhaps it disables the NAND locks on boot. Try e. g. mounting "/system" as read-write from within your ROM with Radio S-OFF and stock HBOOT. It probably disables NAND locks on the Radio area as well, so while you cannot do "fastboot flash radio/hboot" without further modifications to HBOOT, it might well be that protection on the NAND pages is disabled. This shouldn't give you lots of advantages though, since you probably won't be able to map these pages anywhere without using Fastboot. Remember that in combination with bootloader unlock, you might be able to, say, overwrite HBOOT from within Android on a Radio S-OFF device.

Eerm?! You can flash unsigned recovery images with "fake htc unlocked bootloader" alone. That's how I got CWM Recovery onto my device, then used that to install CyanogenMod ROM.

It will work with an unlocked (but original, so not "hacked" in any way) HBOOT that's new enough to support is (e. g. 1.08.0099 or 1.09.0099 - of course it won't work with, say, 0.90.0000).

I think that with ROM you mean the small on-chip boot-ROM, an actual ROM which holds just the PBL, not the NAND. No I don't think that anyone has dumped this ROM yet. I don't even know if it's accessible. It might be that the processor is executing the PBL from it, but you probably have no way of addressing it afterwards.
[HTC Wildfire S] beaups:
I haven't studied Aria but that would certainly fall into the "older" device category. That said, are you guys flashing hboots without first EVER running a utility you don't understand (i.e. revolutionary or alpharev)? Again, I'm not saying you can't run modded hboots, I'm saying "something else" must be done first.

Now I know why this thread is 300 pages ;)

Humor me this, let's talk about evo 4g lte and htc one x (s4 model). HTC screwed up and didn't apply WP to hboot until recently.

How come:

1.) If we change anything in hboot (even 1 digit of version #), it bricks the device

2.) LazyPanda s-off for Evo resorts to some "magic" to get s-off, even though the hboot partition on the Evo is wide open for writing.

3.) Simply flashing the lazypanda hacked hboot bricks the Evo if you don't actually go through the process to allow the extra "magic" to happen

It's because the early bootloaders decide whether or not to boot in secure mode and thus whether or not to enforce sig checking on hboot. So there is "some other" thing that needs to happen in order to allow these unsigned hboots to execute.

Now, is that some other thing a flag in EFS/NV? Is it pbl commands while the device is bricked and stuck in QHUSB mode? These things we don't know. At least I don't ;)
[HTC Wildfire S] Antagonist42:
Most definitely on chip ROM as it's the only one on the phone ;), Check the doc Booting Qualcomm Boot VM984 - pg7. Boot Architecture - "When power is applied to MSM, mARM

executes

the Primary Boot Loader (PBL) from on-chip ROM"...to me that suggests it's RUN from MSM7227 ROM and not LOADED into IMEM/RAM, then you have "PBL loads Qualcomm Secondary Boot Loader (QCSBL) into

memory

and transitions to secondary boot stage"...which I think any changes to the system come from here as it is loaded to IMEM/RAM which would make it editable and open to change as if a system was to update. The problem is

knowing

when mARM releases aARM as further in the doc it says that -

: amss.mbn

....– Configures initial hardware config ....(TLMM GPIO Configuration)

....– Configures modem’s multiprocessor subsystem ....(SMEM, SMD, RPC)

....– Modem automatically connects to 3G network

although on the block diagram aARM is already being pointed to as though released already possibly before AMSS is up :confused:

So during boot before AMSS is running it's possible that NAND has no WP set if AMSS sets up (TLMM GPIO configuration) unless MSM chip pulls up WP as normal operation until system configures.

Follow Signature for a read ;)
[HTC Wildfire S] munjeni:
If some one have jtag dump after htc clip I will compare and let you know! Now I do not know! Hboot loking (tested!) for another flag and not for radio s-off flag in order to get unlocked!

I saying about flashing hboot and radio.... so you can not install hboot or radio without images or NBHs that is signed by htc rsa key! So s-off have no sense in this way (I can confirm that fastboot or zip or nbh or fastboot flash * not working if hboot is not totaly unlocked like revolutionary hboot, no matter if I have s-off or s-on!), only hboot like revolutionary have sense! So s-off is unusable for flashing throught hboot way! Only maybe we have a way for flashing throught diag or radio "thing" while s-off.

You think about enginering unlocked hboot? I tested all stock hboots including htcdev hboot and no one working while my device is in true s-off, radio and hboot can not be flashed, "not allowed" mean not signed by htc! But yes you can flash android partitions without problem.
[HTC Wildfire S] iuss:
This before dump is already tainted (i.e. revolutionary was run before). Looking beyond the differences between before/after, notice the 'xx xx xx Ex xx xx xx Ex xx xx xx Ex'. Familiar? Thought so.

ROM:00000000 a2_37_709_4 DCB "2.37.709.4"
ROM:0000000A DCB 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
ROM:0000000A DCB 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
ROM:0000000A DCB 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
ROM:0000000A DCB 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
ROM:0000000A DCB 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
ROM:0000000A DCB 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
ROM:0000003C DCD 0x4040404 ; R4
ROM:00000040 DCD 0x5050505 ; R5
ROM:00000044 DCD 0x6060606 ; R6
ROM:00000048 DCD 0x7070707 ; R7
ROM:0000004C DCD 0x8080808 ; R8
ROM:00000050 DCD 0x9090909 ; R9
ROM:00000054 DCD 0xA0A0A0A ; R10
ROM:00000058 DCD 0xB0B0B0B ; R11
ROM:0000005C DCD 0x60302104 ; PC
ROM:00000060 DCD 0x4030201
ROM:00000064 ; ---------------------------------------------------------------------------
ROM:00000064 LDR R1, =0x9D077938
ROM:00000068 SUB R1, R1, #4
ROM:0000006C LDR PC, [R1,#4]
ROM:0000006C ; ---------------------------------------------------------------------------
ROM:00000070 dword_70 DCD 0x9D077938

Revolutionary exploits a stack buffer overflow in the fastboot 'getvar' command handler, by extending the mainver string in the misc partition. When the variable is requested (fastboot getvar mainver) aforementioned string is sprintf'ed to a fixed-size stack buffer, overwriting saved-LR with the shellcode address on the heap (misc partition buffer, I guess).

The shellcode (at 0x64 in the disassembly above) simply grabs the usb_receive_buffer pointer and jumps to it, effectively executing the code uploaded earlier (small payload to write appended hboot to flash).
[HTC Wildfire S] munjeni:
Dude, you are genie!!! I done s-off manually without using revolutionary! :victory: Its time now for analysing everything in this steps and exploiting/trying to do the same with another hboot version :) ... will split all "things" in one "thing" and will research for that things in hboot in order to beter understand how this is done... thanksssssss!!!!
[HTC Wildfire S] beaups:
How did you do it?
[HTC Wildfire S] munjeni:
This working in htc aria only with hboot 1.02.0000 with special "extra data" and special modifications to misc partition... sorry I no want to say how I done it because its very "critical" to yours devices so this will brick for sure your phone if you try to do the same like I done, so I no want to explain now how I done it until I "understand" how this can be optimised for another phone... sorry I no want guys to have bricked phones using my explanation how I done it!
[HTC Wildfire S] beaups:
Cool. So its not as simple as flashing a hacked boot? ;)
[HTC Wildfire S] no.human.being:
I'm quite sure there is more than one solution to S-OFF as there's probably more than one vulnerability to exploit in this codebase.

This only applies to some (some means not all) devices and we haven't verified yet whether it applies to the WFS, so let's first assume the simple case, that HBOOT is not signature-checked by SPL.

I must admit that I lost track a bit. You guys are fast indeed. Need to catch up a bit. :D
[HTC Wildfire S] beaups:
It's sig checked. The post above pretty much explains how revolutionary is working around it. If I'm reading it correctly, hboot passes it's checks, is allowed to execute (because it's stock) and then is tricked into loading more code - either replacing itself of appending itself. They aren't simply flashing an unsigned hboot in place. I don't know what more proof you need?