yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] theq86:
We though would first have to find a way to write the blocks which the mtdtools now refuse to write. Then we could maybe flash the 0.90.0000 hboot. Because as I have said, just downgrading with the tricks already known is impossible.

Well, no. We then (after the dumps) could only find out why hboot 0.90.0000 then reports S-OFF. We will have no general knowledge of the secu_flag. But understanding why this combination does S-OFF will help us to investigate further.

Well, I did not mean the basic fastboot functions. But all the useful functions like boot, flash etc. will not work with 0.90.0000. Integrating 2 HBOOTS is impossible. What we could do is build a completely new hboot but that would mean complete disassembling and recoding using assembly. What we may be able to do once we gained S-OFF is to port UBOOT, a generic bootloader which can be adapted to android. but this is also a step far away.

If we succees patching the htcdev hboots we are probably done. If the exploit does not work we can pursue the hboot 0.90.0000 way again.
[HTC Wildfire S] :
Ok. And will my exotic memory be a problem?

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] Lt.Win:
Same here,no time. :-( I need to convince my dad somehow, he's not quite confident to go and get it done... :-(
[HTC Wildfire S] Schnello:
The clip need a internet connection but only for 1. updates and 2. for unlock the sw on the Clip (registration).

Both thinks you can do without the phone on the dummy.

Step B.4: attach the battery or the usb cable. The XTC Forum says: Recommended is the Battery for a stable power supply

A ohter idea from my side:

Maybe it’s easier to go the same way as unrevoked on the desire.

Unrevoke pushed only a custom Recovery on the device and over the recovery you get full access to all partitions (via the adb shell)
[HTC Wildfire S] ONeill123:
Hmm, is a nice idea, but not s-off, but if it funct . i'm happy :D
[HTC Wildfire S] no.human.being:
Do you have an idea how Revolutionary is doing it on the Desire S? This might be helpful, as Desire S and Wildfire S are exceptionally similar in both, hardware and firmware.

WFS has a slower processor and lower resolution display, but apart from clock frequencies and memory size, the processors are nearly identical. Both are from the Qualcomm Snapdragon MSM series, while the original Desire still has a dated Quallcomm Snapdragon QSD8250. The WFS and Desire S also look almost identical, with the WFS looking like a "small Desire S" due to its reduced display size.

I also think that both were delivered with Android 2.3.3 and updated to 2.3.5 recently. Only major differences are in the "peripherals" (resolution of display, camera, etc.), but that shouldn't matter for the S-OFF effort. If we had the source of an S-OFF exploit for the Desire S, porting it over to the Wildfire S shouldn't be too complicated.
[HTC Wildfire S] Lt.Win:
Nice thinking. Some devs could try porting.
[HTC Wildfire S] ONeill123:
I do not understand why the revolutionary team doesn't port his exploit to our great Wildfire S!
[HTC Wildfire S] no.human.being:
Seems not to be considered widespread enough to be worth the effort. There are almost no ROMs available for it (there is CM7 but it's still Beta), so why try hard? They said they tried and it "didn't work".

I'm pretty sure this means "it didn't work out of the box". I imagine that they probably tried smacking an existing exploit for some other phone on it and the stock Android builds of this one will probably expose slightly different memory layout, so the buffer overflows, heapsprays or whatever exploits they are using failed. You can expect this to be the case with any phone. In principle, the WFS should be vulnerable to the same exploits as the DS, but some tweaking may be needed to adjust it to the particular stock Android build they're using on the WFS. The people behind Revolutionary probably considered this too much effort given the "small user/modder/whatever base" of the WFS.

Their devs said they had a problem with the chipset (processor), but I expect it was more of a problem with the stock Android build for the chipset, than with the hardware itself. The MSM7227 seems to be a clone of the ARM11 36EJS from the ARM v6 series (even though Wikipedia states that it is rather an ARM v7 than an ARM v6). Fairly straight-forward design, so don't expect any surprises here. Maybe there's something "gone wild" in the stock Android build of this phone and caused the Revolutionary code to fail. I hope that JTAG access will enable us to have a look at all these details.
[HTC Wildfire S] *se-nsei.:
The CyanogenMod7 is now stable for the Wildfire S. :)

Also, here's the info from the DESIRE S forum on how to gain S-OFF. They are very similar devices. Hope it helps.
[HTC Wildfire S] FiCoo:
anyone tried the above tut?
[HTC Wildfire S] *se-nsei.:
No, because it's the revolutionary method for the Desire S.
[HTC Wildfire S] Lt.Win:
I tried it with 2.3.3, no luck. Let me try 2.3.5 hboot 1.08.

It's for desire s, but what the heck. Lemme give it a go.

Update: Does not work. Doesn't even let me use it, says its unsupported. (I knew it)
[HTC Wildfire S] ONeill123:
One question:

how we can realize the privileges escalation on the device?

Can everyone explain how does it funct?
[HTC Wildfire S] MindBurn010:
From: http://xdaforums.com/showpost.php?p=20377460&postcount=19
[HTC Wildfire S] ONeill123:
Thanks for answer. Step 1 we have, i use temproot for a long time. The reboot into fastboot is no problem too i think. But why get temproot and then reboot? Then temproot is away?

Have we an eng hboot?

And how flash an eng hboot with s-on
[HTC Wildfire S] Lt.Win:
Afaik, the s-off is in the radio.img.

Can't we try flashing the s-off radio file? Also, if we had some older version of this phone which could be rooted, we could spoof the software to get root access. Maybe some devs could use this as a guideline?
[HTC Wildfire S] ONeill123:
I have one more question:

how we can flash another radio file as the original s-on without s-off?
[HTC Wildfire S] Lt.Win:
We could try to spoof it...
[HTC Wildfire S] matt5eo:
Hey to all,

So we know the s-on is in the radio.img. who said that and why do we believe that? Ok. It makes no big differents for us. We have to rewrite the radio/hboot.img. and than we can flash it with the ruu (there's no other way to get those files on you device.

Sent from my nearly brilliant HTC Wildfire S
[HTC Wildfire S] ONeill123:
?

We can not flash with ruu?! The phone will check the signature of the rom.zip and denied the access, then the ruu give an error?!
[HTC Wildfire S] chiragkedia:
WFS S-off

Hey!! got WFS s-off using xtc clip in delhi gafar market. One person named kulminder have xtc clip who charges below 1000 bugs to s-off HTC Devices. If someone urgently needs to s-off his/her device can visit him at 5/9, saraswati marg, karol bagh, delhi. Happy :D;);)
[HTC Wildfire S] theq86:
Well, we still have no discovered why those "exotic" memory layouts exist. n.h.b. thinks it is because of a wrong mapping. But we can check if it is right.

However, yes, it is a problem.

Let's say nhb is right (we can investigate this step by step, if you want)

then you'd only need to change the mapping values and if we got the right memory area you'd be ok.

If there really is an exotic variant (which would be very suspicious) then we'd probably have to get behind it first.
[HTC Wildfire S] :
Ok. I think that I got it while playing with ROM 01. I bricked my phone. how would I go about fixing it? It seems like a lot of trouble, because if the others have exotic memory and try an exploit, their phone might be long gone. Perhaps it was put there by HTC. By the way, if you need help with the kernel, have you asked drowningchild?

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] theq86:
Well, what do you mean by bricked?

What is working, what does not?

btw it's not about the kernel anymore.
[HTC Wildfire S] no.human.being:
@Bad-Wolf: Just do a "cat /proc/mtd" while booted into your ROM and post the output here. And tell us your RADIO and HBOOT versions please. We'll check whether the partition mapping matches anything we've seen so far.

If the partition mapping is "exotic", we could build a different set of kernel parameters for you with which you could check out the exploit again. It's currently available for downloading again here, but it could really brick (well, most likely not, since the mtdutils won't erase, but you never know :D ) when run with the "--disengage-the-safety" parameter supplied, so this not for the faint of heart.

If the partition mapping is "stock" and you provided the correct kernel parameters, but the exploit doesn't get through to "Done!" on your phone (you can also check this without the "--disengage-the-safety" parameter supplied, which will do the patching in "RAM" only and then discard it, so it's a good check whether it would work that doesn't write to NAND and as such shouldn't brick), then the only reasonable explanation is that the HBOOT has "moved" within the Radio partition for some reason. To find the correct offset for your handset, we would then need a full dump of your Radio partition to search where the HBOOT starts inside the partition. However, as the Radio contains sensitive information (IMEI, etc.) this is just some kind of a last resort.

Btw, I have taken care to "safely dispose" of the Radio dumps that some of you provided in the early development phase. Thank you very much so far.
[HTC Wildfire S] theq86:
thanks, nhb. I was planning to investigate what's up with bad-wolf's phone. including get him a partition mapping and if it fails maybe clearing and reinstalling everything new and check again.
[HTC Wildfire S] :
My phone isn't bricked anymore. Unfortunately, I can't run those commands now. supposed to be asleep, plus I got a serious pain. Can I run the cat proc mtd thing from terminal emulator?

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] theq86:
yes, you can use android's terminal emulator or adb. But just get some sleep and cure. Get well.
[HTC Wildfire S] no.human.being:
Yes you can. However, adb shell is more comfortable for copying the numbers out, especially since they usually contain a large amount of zeroes and you can't accidentally "drop" one when using copy/paste from adb. :D

EDIT: Damn, someone was faster! :D
[HTC Wildfire S] :
Thank you. Never had a pain like this last this long. It's around the heart region. Gimme a sec, just need to do what nhb said.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] :
sh-3.2$ export PATH=/data/local/bin:$PATH

sh-3.2$ cat /proc/mtd

dev: size erasesize name

mtd0: 000a0000 00020000 "misc"

mtd1: 00500000 00020000 "recovery"

mtd2: 00340000 00020000 "boot"

mtd3: 10d60000 00020000 "system"

mtd4: 02300000 00020000 "cache"

mtd5: 09600000 00020000 "userdata"

mtd6: 00a00000 00020000 "devlog"

sh-3.2$

Mtd7 seems to have disappeared. Just need to get version numbers now.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] no.human.being:
Looks like a normal RADIO-7.54.39 / HBOOT-1.09.0099 partitioning. "mtd7" is only available when booting with a custom mapping, which we didn't do here since we wanted to have "stock" mapping.

So exploit should get through (claiming "Done!") when booted into recovery with the command line for RADIO-7.54.39 / HBOOT-1.09.0099 (the lower one on this post). If it doesn't, it means your HBOOT has "wandered" inside the Radio partition for some reason.
[HTC Wildfire S] theq86:
confirmed.

bad-wolf: try the following:

fastboot -c "mtdparts=msm_nand:0x000a0000@0x1FF60000(misc),0x00500000@0x026C0000(recovery),0x00340000@0x02BC0000(boot),0x10d60000@0x02F00000(system),0x02300000@0x13C60000(cache),0x09600000@0x16960000(userdata),0x00a00000@0x15F60000(devlog),0x00080000@0x02400000(hboot)" boot recovery.img

with recovery.img (cwm 5.0.2.8)

mount /sdcard in recovery

this would map your hboot (only hboot) to mtd7

then adb shell again,

then

cat /proc/mtd

then

dump_image hboot /sdcard/hboot.nb0

then upload.
[HTC Wildfire S] :
Hboot

1.08.0099

Radio

7.53.39.03M

Something is wrong. I haven't applied the OTA update. Don't think I want to.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] theq86:
if you have 1.08.0099 and 7.53.39.03M but the mapping of RADIO-7.54.39 / HBOOT-1.09.0099 then it surely produced bull**** when mapping for 1.08.0099.

but what the hell? old versions but new partitioning?
[HTC Wildfire S] :
Old man with plastic surgery.

You see, that's what makes it exotic. If it helps, I got the phone unbranded and new from eBay.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] :
I'll do it tomorrow. What are the possible causes of this. If it helps, I've used the old exploit that eoghan2t7 made, that only mucked up the camera. Btw, am I the only one who saw the xtc clip site was down?

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] no.human.being:
Ok new partitioning. When you supply the kernel parameters for the new Radio and run the exploit on them, does it claim "Done!"?

Do so without the "--disengage-the-safety" parameter supplied, so just "./inject /dev/mtd/mtd7", as we don't want to write to NAND (yet).

The exploit doesn't "see" the partition layout, only the kernel does. So as long as the HBOOT itself is original code of the 1.08.0099 the exploit might get through. If it does, we're probably already supporting your phone.
[HTC Wildfire S] theq86:
no possible cause. it's just reading operations.

---------- Post added at 11:54 PM ---------- Previous post was at 11:52 PM ----------

So in future we will have to distinct the devices on their partitioning itself and not on the software versions. Good to know.
[HTC Wildfire S] :
I'll do it 2moro. Can one of you guys round up what I should do. :confused:

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] no.human.being:
Might consider building a "partition helper" app that reads and parses "/proc/mtd" and does all the calculation on its own, then generates a suitable Fastboot command line. Would improve usability a lot. :D

But of course we'll get it "done" first and then "polish". :D
[HTC Wildfire S] :
Cool. I thought you didn't know how to write Android Native apps. LOL. I'm moving on to JOptionPanes. I've got an awful lot to learn.

Anyway, I've got to sleep now. Busy school day. Work, extreme thinking, headaches, running with doctor who music in my head, nervously talking to a girl, silently screaming at Movie Maker, thanks to our school project. The sort.

I'll do all the cool stuff tomorrow. Must rest. Perhaps it will stop hurting.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] theq86:
Do the same what stands here: http://xdaforums.com/showpost.php?p=23269580&postcount=1541

But don't forget. You have the 1.09.0099 layout. So use the second fastboot command even if you are on 1.08.0099.

DO NOT disable safety (not use --disengage-the-safety in the inject command)

Then report what is printed to the screen.
[HTC Wildfire S] :
Ok. Thank you. Got a lot to look forward to.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] theq86:
Yes. I have some nice ideas. Playing with the reboot commands and adb should enable us to provide a One-Click solution. :D

Gonna sleep, too now.
[HTC Wildfire S] :
That sounds nice!

Good night theq86. Sleep tight! Don't let the Daleks bite!

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] no.human.being:
Mind that we should not run code on the host. Once we start doing that, we'll become platform-dependant and then we'll have not only all combinations of HBOOT and partition mapping, but also of host CPU [i386 / IA64 / x86-64 / SPARC / PowerPC] and host OS [Win32 / Win64 / Linux / BSD / OSX] to support. Total combinatoric explosion. This would probably require us to maintain hundreds of versions of our tool. Unless we're ultra and get it all done in Java. :D
[HTC Wildfire S] theq86:
Yes. Because a SPARK user on bsd is found so many times wanting to s-off his wfs with it.

No, really. We won't need to execute architecture-dependent stuff. Just fastboot and adb. Both are supported on Win/Lin/Mac using x86, x86-64 and IA64. We use them to get our native linux apps to the phone, execute it and reboot when neccessary. The fb and adb commands can be done into batch or shellscript files.
[HTC Wildfire S] :
So basically we have to run it on the phone and not on the computer because then you'd have to build hundreds of versions? So how far are we now? When I come back from school, I'll start doing all those things.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] MrTaco505:
im just getting ready to try out nbh's inject exploit but when i try to cd into my sd card and list my current items, it doesnt show any of them. I went to mount /sdcard and still nothing happened:confused:
[HTC Wildfire S] theq86:
are you sure you mounted the sdcard ? cwm mounts it to /sdcard. if it's empty your sdcard is not mounted, or it is really empty.
[HTC Wildfire S] MrTaco505:
im mounted and my sd card is not empty
[HTC Wildfire S] theq86:
what exactly did you do? step by step please.
[HTC Wildfire S] MrTaco505:
ohk now im getting this

adb server is out of date. killing...

* daemon started successfully *

~ # cat /proc/mtd

cat /proc/mtd

dev: size erasesize name

mtd0: 00100000 00040000 "misc"

mtd1: 00500000 00040000 "recovery"

mtd2: 00340000 00040000 "boot"

mtd3: 10400000 00040000 "system"

mtd4: 02300000 00040000 "cache"

mtd5: 09600000 00040000 "userdata"

mtd6: 00a00000 00040000 "devlog"

mtd7: 00080000 00040000 "hboot"

~ # cd /sdcard

cd /sdcard

/sdcard # ls -l

ls -l

drwxrwxrwx 3 root root 4096 Mar 12 22:40 Android

drwxrwxrwx 4 root root 4096 Mar 14 08:52 clockworkmod

drwxrwxrwx 3 root root 4096 Mar 12 22:42 dcim

drwxrwxrwx 3 root root 4096 Mar 14 08:47 download

drwxrwxrwx 3 root root 4096 Mar 13 00:17 gameloft

-rwxrwxrwx 1 root root 676534 Mar 13 13:04 inject

drwxrwxrwx 2 root root 4096 Mar 4 20:13 mtdutils

/sdcard # inject --disengage-the-safety /dev/mtd/mtd7

inject --disengage-the-safety /dev/mtd/mtd7

/sbin/sh: inject: not found

/sdcard # inject --disengage-the-safety /dev/mtd/mtd7

inject --disengage-the-safety /dev/mtd/mtd7

/sbin/sh: inject: not found

/sdcard #
[HTC Wildfire S] theq86:
you have to write

./inject --disengage-the-safety /dev/mtd/mtd7

not

inject --disengage-the-safety /dev/mtd/mtd7
[HTC Wildfire S] MrTaco505:
oh thanks, i feel retarded not putting everything :D

/sbin/sh: inject: not found

/sdcard # inject --disengage-the-safety /dev/mtd/mtd7

inject --disengage-the-safety /dev/mtd/mtd7

/sbin/sh: inject: not found

/sdcard # ./inject --disengage-the-safety /dev/mtd/mtd7

./inject --disengage-the-safety /dev/mtd/mtd7

*************************

* Cold opcode injection *

*************************

An S-OFF exploit for HBOOT: 1.08.0099, 1.09.0099

(C) 2012 no.human.being

Project coordination, Fastboot and Radio analysis, exploit development and boot

image integration.

Thanks to the all the contributors from xda-developers, especially ...

... *se-nsei. for initiating the quest and keeping the community informed.

... heavy_metal_man for the '/system' dumps.

... seaskyways, MrTaco505, mstfkaratas and pihug12 for the Radio image.

... theq86 for the mtd tools analysis and Radio image.

... BeciMester for the HBOOT analysis and Radio image.

Other contributors and fellows from xda: d33ps1x, Bad-Wolf, benjamingwynn

Thanks to Cyanogen, Alquez and Drowningchild for their work on the kernel.

Thanks to the bands Kampfar (Fredrikstad, Norway) and Trivium (Orlando, Florida)

for their inspiring music!

[ LOG ] Step 1: Reading from mtd ...

[ LOG ] Step 2: HBOOT analysis ...

[ LOG ] Incorrect version string for HBOOT-1.09.0099

[ LOG ] HBOOT-1.08.0099 detected.

[ LOG ] Step 3: Patching ...

[ LOG ] Step 4: NAND unlocking ...

[DEBUG] ./mtdutils/flash_unlock /dev/mtd/mtd7

[ LOG ] Step 5: NAND erasure ...

[DEBUG] ./mtdutils/flash_erase -q -u 0 0 /dev/mtd/mtd7

[ LOG ] Step 6: Writeback ...

[ OK ] Done!

/sdcard # exit

exit
[HTC Wildfire S] einstein.frat:
did it s-off? or not.
[HTC Wildfire S] no.human.being:
It probably didn't since step 5 (NAND erasure) will fail silently. The mtdutils refuse to erase the NAND pages because they think they're "bad" (they're marked as such). And (luckily) the mtd kernel driver won't write to "bad" pages. If it did, we'd have quite some bricks by now, since writing to pages that weren't erased results in garbage in these pages.
[HTC Wildfire S] *se-nsei.:
well, what happened?
[HTC Wildfire S] MrTaco505:
no s-off :( but my phone has a side effect that it take way to long to reboot
[HTC Wildfire S] no.human.being:
Nothing happened. It shouldn't have left any traces on his phone.

Currently the Radio partition (which the HBOOT is a subset of) is made up of "bad" pages that cannot be erased or written to using unmodified mtdutils and mtd drivers, so nothing is changed. But the tool's output is proof that his HBOOT would get patched if we got the mtdutils to erase the pages.

I think the mtd drivers not writing to pages marked as "bad" is no problem at all, as the erasure should clear the "bad" marking as well, so once we can erase "bad" pages, we're through.
[HTC Wildfire S] einstein.frat:
@ Mr.Taco

if it didnt work, your just a script kiddie, lol. try to paste it in browser url. :D joke.
[HTC Wildfire S] MrTaco505:
lol :D

Im on my phone.....
[HTC Wildfire S] seaskyways:
Well guys , I just read what happened , you didn't need all of this re-testing , cuz i tested and gave the results without the long time to boot thing that Mrtaco got ...

Currently we need some sort of linux expert to remove this bad page checking before the process , or any of you guys can do it ??
[HTC Wildfire S] theq86:
You did not read properly!

The re-testings brought us the insight, that the partitioning is not dependent on the radio/hboot version. We can not assume fixed memory addresses for the several radio versions. we will have to decide directly upon the device partitioning.

And, currently, we have several linux "experts" working on it.
[HTC Wildfire S] seaskyways:
Well , i just wish you guys good luck since i am outta hope of my phone :( i feel it is worse than my old x10 mini pro :( all because of my weird case which i couldn't fix :(
[HTC Wildfire S] no.human.being:
I cannot really do it, at least not yet. I expect us to hit a kernel-level restriction though when we modify the mtdutils to erase bad pages. It's some sort of a "security feature" and security that's just in the userspace libraries and not in the kernel hasn't got "teeth", since any process may ship with its own set of userspace libraries.

Therefore, my bet is that we're ultimately gonna build a "vanilla Linux" (or at least "custom Android") kernel in the end. So sure we'll get the userspace libraries right first, since we already know we're gonna need those modified. But keep in mind that I say it's not gonna be enough.
[HTC Wildfire S] :
Well, as I promised, I ran the exploit.

Here are my results:

[ LOG ] Step 1: Reading from mtd ...
[ LOG ] Step 2: HBOOT analysis ...
[ LOG ] Incorrect version string for HBOOT-1.09.0099

[ LOG ] HBOOT-1.08.0099 detected.
[ LOG ] Step 3: Patching ...
[ LOG ] NAND unlocking, erasure and writeback skipped for safety reasons, supply
'--help' parameter for more information.
[ OK ] Done!

And allow me to check if I got S-OFF, despite the fact I probably haven't.

Nope, we haven't got a girl, we've got a SON. Damn it! None of the other stuff has changed.
[HTC Wildfire S] no.human.being:
You didn't supply the "--disengage-the-safety" parameter so nothing was written to NAND. So of course you are still S-ON. This is on purpose.
[HTC Wildfire S] MrTaco505:
If we are able to write/read/erase to the nand, we can surely get what we needed?