yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] theq86:
unlocked bootloader is insufficient for flashing hboots. there is a tutrorial in this forum how to downgrade hboot with an s-on phone, but I could not make it work.

so in theory you need a RUU with a lower hboot (to find in the stock rom collection in dev area) and have to flash it. the "main version is older" issue can maybe solved with this: http://xdaforums.com/showthread.php?t=1162971

But as I said, I could not get it to work. Even you will have to flash the whole RUU. so without s-off no way to just flash a new hboot.
[HTC Wildfire S] no.human.being:
Hey guys. Still busy with the exams, so just a few words.

IF the Radio resides inside a memory area that is accessible via the mtd devices, I'd suggest we dump the Radio of a stock and xtc-clipped phone, compare them, then put the right offsets/values inside the exploit and make it patch the Radio. Would have the same effect as xtc-clipping the phone. The problem is that Revolutionary have not found a way to access the Radio and if I take a look at the contents of "/proc/mtd", it seems that the Radio is in fact not accessible via mtd so it seems that this method is a dead end.

The other method was disassembling HBOOT and replacing all calls to the "check secu_flag"-function of the Radio with a call to a function that writes a zero into register 0, then returns. The problem with that method is that we're accessing the raw NAND device from within our exploit and, according to BeciMaster, the HBOOT is stored compressed on the NAND, so after dumping the NAND contents, we'll first have to uncompress them, then apply the "patch", then recompress them and finally erase the NAND and write them back. To achieve this, we have to figure out how the compression works. Not exactly easy, but it would essentially give us the same kind of S-OFF that Revolutionary gives us.

EDIT: I've come to yet another idea. HBOOT can disable the "secu_flag". This is how xtc-clip is doing it. The xtc-clip generates a Goldcard, then "authenticates" as an HTC special SIM and HBOOT turns "secu_flag" off. HBOOT will likely need to talk to the Radio for doing so, but it can do it. Can't we make the exploit NOP out the code that checks for the special SIM in HBOOT? Then you'd just have to perform the exploit, reboot into HBOOT with a Goldcard inserted and be S-OFF. Advantage is that you could install a stock HBOOT afterwards and still be S-OFF and that SIM unlock and SuperCID come "for free" with this method (the special SIM causes HBOOT to "open" all three). We would not NOP out the code that checks for the Goldcard, but only the one that checks for the special SIM so that you can still enter the HBOOT in a "normal" fasion by simply not having a Goldcard inserted.
[HTC Wildfire S] *se-nsei.:
First post updated... kinda. Tell me if anything else.
[HTC Wildfire S] theq86:
Great idea. But if it had the same effect as XTC-Clip the S-OFF would be permanent, though. I read, that the phone keeps S-OFF after hboot downgrade.

next, we have to find the offset for the ENG SIM check, too.

But I see the advantage in HBOOT making us S-OFF.

still, we need to crack the compression. (if there is one)

another idea in case, HBOOT is really stored on the nand compressed. Logically, on bootup it has to be decompressed in RAM or any kind of cache. If we could for example get access to the RAM content we could influence the hboot without having to write to nand at all.
[HTC Wildfire S] heavy_metal_man:
How can I help? Just let me know :-)
[HTC Wildfire S] hahahafr:
As far as I recall, our only way to access the RAM is via a hardware method. Meaning using a JTAG interface, but the connector on the WFS is not standard.
[HTC Wildfire S] BeciMester:
Hi guys,

Looks like I was talking out of my ass. :eek::o The hboot is NOT accessible to the OS and is not mapped to any of the mtd devices. It sits on the NVRAM together with the radio. Looks like the only way to access hboot is via hboot itself: it contains the command "saveprt2sd" that can dump most any partition to sdcard (with exceptions of course: radio cannot be dumped). I've found the info here, thanks guys!

fastboot oem saveprt2sd hboot -n hbootpart.img -a

This should create a file called hbootpart.img on the sdcard, IF the command is not disabled on stock hboots. (I can't test now as she's away with the phone until Sunday evening. :() It's also mentioned that the dump should be around 768K even though the hboot image is just 512K. I have high hopes that it'll solve the problem I'm seeing with the hboot code referencing memory locations outside the hboot's 512K. Alternatively, we might have to look at the "misc" partition, see below. The upside is, the hboot is raw partition data and it's not compressed. Should've known from the fact that the hboot image in the RUU isn't compressed either. :o

If anyone manage to get the above command work, please upload the resulting file somewhere and post a link, and please include your hboot version and whether you're S-ON or S-OFF. And whatever you do, DO NOT attempt to flash the dumped file back onto your phone or anyone else's, it WILL kill the phone, stone dead, ende, finito, kaputt. Images dumped with the -a switch contain everything from the partition, even empty blocks and raw data; in our case it's interesting but it's not meant to be flashed back like that. Thanks.

Very interesting stuff mentioned in this conversation (if you ignore the name calling, haha :D). The important bit is the function of the mounted devices:

So the "boot" device doesn't contain the hboot as I thought. As stated above, the "misc" partition has something to do with the SPL (=hboot) as well, we might have to look into that too.

I'll report back with more once I get the phone back in my hands.
[HTC Wildfire S] meanmug:
I already made a mention of that http://xdaforums.com/showpost.php?p=20960853&postcount=376
[HTC Wildfire S] heavy_metal_man:
how to obtain infomation?

i think this should not be a problem as most people seem to have trouble with not being able to get root, but this phone is on the htcdev bootloader so root is already possible. this should in theory work and hopefully will be able to flash the whole ruu. even if i can only flash the hboot, then the phone should be back to a pre-htcdev one and if i run the ruu again without modifying it i should be able to fix the rom and radio and recovery ect.

ok so how would i attempt to find this information? over at the wildfire forum i have tried to run a logcat while the phone runs the diag file from the xtc clip and it just cuts out and says waiting for the device to be ready. also we think we may have discovered that the diag file can give supercid without the xtc clip after revolutionary s-off.i am currently waiting on a reply back now about it to see if it has effected the secureflag and the simlock. so far we`ve had one possible hit and one miss, so we will just have to wait. link here http://xdaforums.com/showthread.php?t=1448972&page=16

is there a way to moniter what the device does when the xtc clip is plugged into it? also i dont know how long i will have access to my friends marvel but if all goes well i will be seeing him on the 1st of feb to fight with his phone. will would there be any other information worth trying to take from before i use the xtc clip, for comparitive reasons or anything? just want to make sure we can get the most out of the phone with what little time i will have with it.:D

also i only have android skd on my laptop which is on windows7 64bit. if possible could you guys put together a step by step guide on how you want me to take any of this information and with what programs to use on my windows. i have a basic understanding of the skd and using command prompts but i am a quick learner ;)

keep me posted :)

Heavy_Metal_Man:cool:
[HTC Wildfire S] no.human.being:
Well the xtc-clip method is probably a dead end as well. The SD card that xtc-clip generates is not a standard goldcard, but contains some kind of a leaked HTC diagnostic utility. This diagnostic utility checks for the SIM to be present and if the people at HTC aren't damn dumb then the code of this utility is signed, like anything else that HBOOT executes in the S-ON state. This means that we cannot change the code of the diagnostic utility to disable this check or HBOOT will refuse to execute it on an S-ON phone. Damn.

Oh damn, that sounds bad! This means that the read-write access to the mtd devices we obtained isn't worth that much as all components that are related to security cannot be accessed at all? We can literally modify anything that the OS can ever access under normal circumstances and now you're telling me that this is not enough? :D
[HTC Wildfire S] theq86:
C:\Users\####\Desktop\MarvelDev\fastboot>fastboot oem saveprt2sd hboot -n hboot
part.img -a
...
(bootloader) [ERR] Command error !!!
OKAY [ 0.000s]
finished. total time: 0.000s

C:\Users\####\Desktop\MarvelDev\fastboot>

Using HBOOT 1.08.099 (the one from htcdev)

device is bl unlocked.
[HTC Wildfire S] no.human.being:
# fastboot oem saveprt2sd hboot -n hbootpart.img -a
< waiting for device >
... INFO[ERR] Command error !!!
OKAY [ 0.008s]
finished. total time: 0.008s

#

MARVEL PVT SHIP S-ON RL
HBOOT-1.08.0099
MICROP-0451
RADIO-7.53.39.03M
Nov 28 3011,19:09:21

Seems HBOOT-1.08.0099 does not support this command any more.
[HTC Wildfire S] Lt.Win:
To the level of what I understand (:P) (which is very low) I think it's getting harder.

But I'm sure I read on a site that HBOOT can disable the secu_flag....

Seems its a different case for us.
[HTC Wildfire S] no.human.being:
The Radio controls the secu_flag. Can we talk to the Radio from a UID 0 (root) process from within Android or can only the kernel talk to the Radio? I'm not so much into modifying the kernel, as this would be really messy.

From what I know we can obtain read/write access to the Recovery partition via my exploit. I think this will enable us to flash CWM onto the Recovery partition of the S-ON device. Will this be of any use? Will CWM be able to flash a Custom ROM on an S-ON device? Remember, the main problem is that HBOOT won't flash CWM as there is a signature verification when the phone is S-ON. However, we could flash CWM from within Android using my exploit. Should be quite straight-forward actually. The question is: Will CWM flash a Custom ROM on an S-ON device? I know this is not S-OFF, but at least it would enable the people that cannot unlock via HTCdev due to carrier restrictions to flash a Custom ROM.

However, remember that the secu_flag resides at offset 0x000a00 on partition 7 on the Desire S. There is a known exploit that flicks it exactly in that place. I find it very strange that it is said to reside inside a totally non-accessible "Radio NVRAM" special memory area on our phone while it is on a standard block device on the DS. Perhaps we have simply given up too early. Just because Revolutionary said the secu_flag was inaccessible doesn't mean that it really is. Sure they're great Android hackers, but that fact doesn't prevent them from overlooking a thing. Is there any way how we could find out where the flag actually resides (say it's physical memory address) and then check whether that address lies inside or outside the memory areas that are mapped to the block devices that Android has access to?
[HTC Wildfire S] heavy_metal_man:
Damn right :-p Is there no way we can do a before and after dump from use with the xtc clip to compair and show us the location of all 3 things?(I know its already been said:-))
[HTC Wildfire S] no.human.being:
When I have time, I'll modify my exploit to make it dump an arbitrary device (at the moment it only dumps the "system" partition). Then we'll "only" have to find one that has an S-ON WFS and an xtc-clip and wants to contribute to this. He could dump everything but his user data (I really don't want anyone to have his gmail account and WLAN key exposed :D ) both before and after the unlock process and either do the comparison on his own and publish the diffs here (if he is knowledgeable enough and doesn't want to upload his memory contents) or decide to upload the dumps for us to do the comparison.
[HTC Wildfire S] BeciMester:
That's precisely the reason I want to dump the hboot partition: to see what's AFTER the area covered by the hboot.nb0 file I'm disassembling. Let me show you what I mean with an example. The following subroutine is called every time the @secu_flag status has to be checked:

9d04ce00:	e52d4004	push	{r4}	; (str r4, [sp, #-4]!)
9d04ce04:	e59f3018	ldr	r3, [pc, #24]	; 9d04ce24 <_binary_hboot090_nb0_start+0x4ce24>
9d04ce08:	e5934000	ldr	r4, [r3]
9d04ce0c:	e284493f	add	r4, r4, #1032192	; 0xfc000
9d04ce10:	e28440a0	add	r4, r4, #160	; 0xa0
9d04ce14:	e5940000	ldr	r0, [r4]
9d04ce18:	e2000001	and	r0, r0, #1
9d04ce1c:	e8bd0010	pop	{r4}
9d04ce20:	e12fff1e	bx	lr
9d04ce24:	9d086a8c

Let's see what it does, for those not familiar with assembly. ;)

9d04ce00: save the contents of register4 in the stack

9d04ce04: load a 32-bit number into register3 from the memory location 0x9d04ce24 -> the result is 0x9d086a8c as we can see from the last line

9d04ce08: load into register4 the contents of the memory location that register3 is pointing at (!!)

9d04ce0c: add 0xfc000 to the contents of register4

9d04ce10: add another 0xa0 to the contents of register4

9d04ce14: load into register0 the contents of the memory location register4 is pointing at

9d04ce18: discard the value of register0 except for the very last bit

9d04ce1c: load the contents of register4 back from the stack

9d04ce20: return

9d04ce24: (4 bytes of data)

As we can see, the ldr statement at 9d04ce08 is reading something from the memory location 0x9d086a8c. The last useful address in the hboot.nb0 image (before the wall of 0xff) is 0x9d0798cf, so that statement above reads from the memory that's filled with 0xff in the hboot image -> no useful data. I suspect either when the hboot is flashed the flasher knows where to stop not to overwrite those addresses, OR it's updated from somewhere else when the hboot is loaded into memory for execution ("misc" partition maybe?). The rest of the code just adds an offset to that address read from 0x9d086a8c, which I believe to be the location of the @secu_flag, then keeps the last bit in register0 and returns. Incidentally, the callers of this subroutine checks whether r0 is 0 or 1... So I'm pretty confident that once we find out the value stored at 0x9d086a8c, we'll know exactly where the @secu_flag is. :D

NB: all of the above refers to the 0.90 hboot which I'm more familiar with (and which is a LOT less obfuscated than the new one), but the principle is the same in 1.08. I've already found the same code in the new hboot, it's just the old one is simpler for demonstration.

As a side note: "patching the hboot" would mean replacing this subroutine with

ldr r0, #0
bx lr
[HTC Wildfire S] heavy_metal_man:
I have access to a xtc clip and a wildfire s, which I intend to downgrade from htcdev to an older hboot and radio. If you can make it so I wont dump personal data then I'm sure I can post the info to you guys for analysis, but if not I can search through myself allowing someone can explain what I'm looking for, or a program that can cross check for differences :D also I think there is a .exe program somewhere around here of the xtc clip software for making the goldcard. Keep me posted. Also I will only have access to the wildfire s from the 1st of Feb to the 7th of Feb.( as I will be going on holiday to see my friend who owns it :-p)
[HTC Wildfire S] no.human.being:
Wow! I thought you weren't able to find the code that checks the flag as it lies outside the image, but it seems it's only the flag's value itself that's outside the image. Is the image executed directly from the NAND (some controllers can do that, I think ARMs can do it as well) or is it loaded into RAM?

If it's loaded into RAM well then we will only have the location of the secu_flag in RAM, but what we need is the location of the secu_flag in NAND, as our exploit relies on changing NAND content, not RAM content, as only the former is persistent, but the latter is not.

Well I'm actually familiar with "gas" (GNU Assembler) on x86, but this looks quite different so thanks for your explanations. :D

... and possibly a lot of "mov r0, r0" which is 0x01a00000 as opcode (basically a no-op, ARM doesn't seem to have a true no-op in their instruction set) to keep the size of the code the same.
[HTC Wildfire S] sythe179:
Glad xda doesent care about this anymore......not that its one of the main functions of these forums....
[HTC Wildfire S] Lt.Win:
Ikr
[HTC Wildfire S] ash98:
I agree with d33ps1x , there's nothing we can do right now...

Plus, XTC Clip rental for 2 days is only £10 on eBay, just search for XTC Clip. All the feedback says it works, and if you really can't afford it ask for some cash this christmas :)
[HTC Wildfire S] Lt.Win:
I don't have a shop nearby to get it unlocked. I'm ready to pay.

Has anyone seen a shop in Mumbai or atleast a site where I can buy it for not more than 20 pounds or something?
[HTC Wildfire S] akshayf:
Best of luck bro....more than half of mumbai shopkeepers wont know what xtc clip or s-off is...
[HTC Wildfire S] Lt.Win:
I know, half of them asked me what it was instead of saying 'No, I don't have it.' Lol xD
[HTC Wildfire S] qiuness:
ah dammit...only uk :(((

any chance to do it remotely?
[HTC Wildfire S] aparici:
I need it on spain...
[HTC Wildfire S] mla123:
@SomeDudeOnTheNet

have you tried the shop in mumbai mentioned in this thread? Even I want to s-off my wfs but dont have the time to go there..

http://xdaforums.com/showthread.php?t=1385047
[HTC Wildfire S] Tectas:
Nice thread, but one question, did you try to pay together for one wfs and donated it to the revolutionary team that they can play around with it? I think that could be less money with big impact, maybe they gave up that fast cause that got no device to try and test.

Swyped from my desire s running damn sweet ice cream
[HTC Wildfire S] nowhat?:
Thats a good idea!!
[HTC Wildfire S] Nightshadow931:
We would need a lot of money for that.

And plus, everyone would rather spend that money on XTC clip.
[HTC Wildfire S] matt5eo:
Please look here.:

http://xdaforums.com/showthread.php?t=1386547&page=2

trying to get the hole virgin ROM onto your device, maybe it works. O.o

Sent from my HTC Wildfire S A510e
[HTC Wildfire S] aparici:
Have you tryed? Look at says the partner in the other post. It could work.

Enviado desde mi HTC Wildfire S A510e usando Tapatalk
[HTC Wildfire S] Tectas:
Not as much and if everyone here would join, it's sure cheaper than unlocking with xtc and everyone gets something out of it. But however, was just an idea, what you do with it is in your hands.

Swyped from my desire s running damn sweet ice cream
[HTC Wildfire S] aparici:
I think that we should do that. Anyone who organize it?

Enviado desde mi HTC Wildfire S A510e usando Tapatalk
[HTC Wildfire S] no.human.being:
Greetings to all WFS users out there.

I am currently on track of developing a software S-OFF for the WFS (or possibly even a generic S-OFF solution). I would like to ask anyone, who has a clue about the internals of the MSM7227 processor, that is used on this phone model, the Android 2.3.7 OS and/or experience with JTAG, to provide me with their knowledge in order to support my efforts.

I am not the worst at breaking security systems. However, I am not having much knowledge about embedded systems development (especially I currently do not know much about JTAG/OpenOCD, which I would like to use in order to develop my S-OFF method). :)

So any embedded experts, please move to "my" thread here on xda-devs and let's try to get this project off the ground.

Thank you very very much.

PS: To all Revolutionary fans. I'd love to try porting the Revolutionary exploit over to the MSM7227. However, I don't think that the Revolutionary devs will open up their exploit to me, so I might have to develop one on my own.
[HTC Wildfire S] No.12:
I have suscribed to your thread,hope you find some solution (I don't want to say fast).
[HTC Wildfire S] ONeill123:
hope too, that u find a olution to make our devices s-off! :D
[HTC Wildfire S] No.12:
I can't believe that HTCdev.com support HTC Explorer (crippled version of WS).

http://xdaforums.com/showthread.php?p=20197444

I am so disappointed. :mad:

Sent from HTC
[HTC Wildfire S] heavy_metal_man:
so is getting a dump of the hboot the plan then? sort of follow the path and hope we can find the code?

im game :D
[HTC Wildfire S] no.human.being:
The code at 0x9d04ce08 basically reads a value from address 0x9d086a8c. This address lies outside the HBOOT image so we don't know which value is there. The value that was read will then be "offset" by adding 0x000fc0a0 to it and the result will be interpreted as an address again (!!), from which the secu_flag is read (actually the secu_flag is only the least significant bit of that value).

So at 0x9d086a8c there's probably a pointer to the beginning of a data structure and at offset 0x00fc0a0 inside that data structure lies a value which has the secu_flag as its least significant bit. So there are two layers of indirection here. 0x9d086a8c is not the address of the secu_flag, it's the address where the pointer to the data structure that contains the secu_flag (among other stuff) lies. Think of the content of 0x9d086a8c as some kind of "a pointer to the Radio NVRAM". It tells us where the NVRAM lies and when we know that, then we add that offset of 0x000fc0a0 to the address and then we have the address of the word which contains the secu_flag as the least significant bit.

Then the next question is: Is that address that we finally get a pointer into the volatile (RAM) or the persistent (NAND) memory? If it's a pointer into the volatile (RAM) memory, then we will only have the address of "a copy of the data structure that contains the secu_flag" and we'll have to find the code that crafts this copy, as the original definitely resides inside the persistent (NAND) storage and we need to find the address of the original, not the copy, as the copy is volatile and will be recreated from the persistent original at each reboot.

And finally, once we have the address of the original value in the persistent (NAND) storage, we will need to find out exactly how the mtd devices are laid out, which mtd device covers the area of persistent storage where the flag resides and at which physical address this area begins. Then we can map the physical address to an offset into an mtd device and finally finish our exploit. The exploit will do a "full S-OFF", just as xtc-clip does. It will stay S-OFF even when HBOOT is up-/downgraded and everything.
[HTC Wildfire S] heavy_metal_man:
ok, i think i know what you mean.;) so does this mean you will need any info from me or should i take a step back and let you guys work your magic?also if we get this method working successfully could it be ported to the old wildfire, obviously the code might not be in the same place but would the theory work?
[HTC Wildfire S] no.human.being:
I'll see if I can modify my exploit to dump any mtd device, then you could do a dump on the "non-sensitive" information in the WFS before and after you applying the xtc-clip. I'm not sure if we'll need this information or not, but it's always better to have more information than to have less, so it's probably better to have the dumps just in case. :D

The working principle of the exploit is from an existing exploit for the Desire S (this is why I had this 0x00000a00 offset in in the first place, it was the offset of the secu_flag on the Desire S :D ) so yes. The principle should be the same on almost every HTC phone. Desire S and Wildfire S actually have more in common than Wildfire S and Wildfire have, as the former two have the same release date and are as such based on relatively "recent" technology, while the original Wildfire is way older, but probably it'll work. Of course you'd need to disassemble the HBOOT of the original Wildfire and figure out the location of the flag again.