yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] insink71:
Bold trailblazer... Other than being HTC, and the general linux-child similarites (both android) our devices are different. Emmc and nand devices have some differences.. his phone is actually probably harder to s-off being more advanced. It takes the following: eng hboot, appropriate eng to misc image tools, and balls of steel. As you will have to edit your radio.. Now, meanmug or someone had an eng hboot for marvel side I thought.. I couldn't get the flashable zip I found posted to work, so I put it aside... I will soon be looking at marvelc's manufacturing test rom but I lack balls of steel.. and I've had s-off. What exactly is this thread going for again? 90% of ppl will unlock hboot via htcdev (which is reverseable); those that want radio s-off have option of xtc clip or chinese exploit for marvelc. I suppose its to fully

reverse engineer the process, but given the choices out there already; risk outweighs the small benefit left to gain. But anyway, you'd need the aforementioned tools and a bullish drive (no regard to risk) to fully envelope this for our phones.

Edit: read back a few pages... These guys know more than I.. may have to come back here with mem addressing questions. If it will be figured it shall be. I do remember when clearing the secu flags it referenced s34. Mine are cleared though. I would love to communique and mem map my cleared.. they seem to have locked mem mapped.. so if I have cleared the secu flags... It makes sense to employ a s-off'er (like myself)... to attempt to write the secu flags (whatever those might be), gain s-on?, yes :) no erase same block written... Try again. However this is probably over simplified. I'm game to play.

Rob
[HTC Wildfire S] theq86:
WFS does not have eMMC. So if we brick the device we will not be able to map any part of the memory. there are, however interfaces to access the phone when it is hboot bricked. but none of them will let you flash a new hboot.
[HTC Wildfire S] BeciMester:
See, I've never understood what brings people to e.g. climb Mount Everest, or swim the Channel, or stuff like that. This undertaking might not be on the same level, but I believe the principle is the same.

It's for the challenge. :D

(I'm on my phone...)
[HTC Wildfire S] no.human.being:
I wouldn't do it. No specific reason why I wouldn't do it, it's more of a "feeling" that tells me: "It's out-of-band. You're not supposed to mess around with it in the normal case."

And the "userspace" "nand_lock" and "nand_unlock" can't do it. So this means more extremely low-level stuff that directly talks to the kernel and is difficult to program. :D
[HTC Wildfire S] benjamingwynn:
(the noobs back (thats me btw)) :)

But I thought that this could be interesting, the way it works: http://www.xda-developers.com/android/htc-sensation-is-now-unbrickable/

But idk. Feel free to knock that and carry on :P
[HTC Wildfire S] theq86:
Seems we got a new radio version with the 2.14.401.1 Update. I did not receive this update yet officially but it's around in the forums.

HBOOT-1.09.0099
RADIO-7.57.39.01M

This is the first time that an official update contains the latest HBOOT 1.09.0099 which is unlockable.

Radio version has been updated, too. (Here in germany I have noticed better signal)

Phone partitioning kept the same. It seems like there are only 2 partitioning schemes.
[HTC Wildfire S] :
Do you suggest that I get it? Maybe its better if I keep mine the same. It's just like my role model said, the older it is, the stronger it is. It probably has more "weak spots".

-----------------------

Doctor who - Fathers day, if you were wondering.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] MrTaco505:
So anyone willing to check it out?
[HTC Wildfire S] theq86:
It doesn't matter if you install the new radio or not. It doesn't change the partitioning. And it doesn't change our plan.
[HTC Wildfire S] seaskyways:
So , that's it ?? were stuck here on the kernel and mtd driver thing with no skilled dev to finish what you have started ? You just made the exploit , and there is NO kernel dev all over this forum other than alquez ?? if yes then we need him ...
[HTC Wildfire S] benjamingwynn:
Modpunk, alquez, djpc and jmz are the only kernel devs I know of for the Wildfire S.
[HTC Wildfire S] theq86:
guys, calm down.

If all works out we are just 1 step before s-off. even the devs have their own life and duties to do. atm we need to change something in the mtdtools. that needs testings and a lot of mindwork. if you can not wait just get an xtc clip, otherwise be patient. development has NOT stopped ...

edit:

we should make a whining list. everyone on that list won't get the exploit when it's ready :D :D :D
[HTC Wildfire S] seaskyways:
Not stopped , but somewhat postponed , and about the whining list , I guess I'll be the first to be included :p
[HTC Wildfire S] :
Aw, ****!!! Please don't put me!!!!

You actually could do that. Make a system so if you want to download the exploit, you must have an Exploit ID, that is calculated based on your phone. If the Exploit ID is blacklisted in the Exploit, then the Exploit won't work. Although it will brick your phone, making you smarter cos you have to fix it lol. Anyway, how is everyone?
[HTC Wildfire S] *se-nsei.:
It was a joke.

Please, stop spamming guys.
[HTC Wildfire S] :
Sorry.

Anyway, I have a way to attract more devs. All of us should click on "Submit Thread as News Tip".

This link might do the trick. Not sure, might be a one time token based system.

Submit Thread as News Tip

@se-nsei Can you please mention this on the OP. We have a way better chance of getting this done if we have new devs. Maybe you can give a basic idea to devs what we're trying to do.

Maybe, to make this more organised, people can be assigned roles. For example, we could have the Dev group (NHB, theq86, HMM, Ben, etc.), then the tester group (Bad-Wolf, rezo, MrTaco505, etc.) and so on. Just a suggestion. Maybe se-nsei can mention the group members on the OP.

How are we now?
[HTC Wildfire S] Lt.Win:
Afair we had already done the submit to portal. It got accepted, but it was of NP use.
[HTC Wildfire S] theq86:
right. we were in the news already.
[HTC Wildfire S] :
I didn't see it. Anyone got a link? Oh, and BTW, I know its off topic, but which kernel are you using? I'm planning on getting Turbo Kernel, but I don't know if its good. I don't want to get .sense kernel.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] Lt.Win:
It was submitted to portal in 2011, many months back, when we were on the .nbh files and stuff lol. It was like after we got the cdma s-off.
[HTC Wildfire S] :
What about the kernel.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] Lt.Win:
Idk I don't even have the phone now, using p500 cm7 official nightly. Just trying to help out here and there.

Sorry for offtopic.
[HTC Wildfire S] captivated1971:
hey rob any chance you may work on an htc evo design s-off?
[HTC Wildfire S] theq86:
:mad: this is what private messages are for.
[HTC Wildfire S] einstein.frat:
Rascal already cracked this so many months ago.

solution: w/o xtc clip hardware you would end up with a broken chip if you succeed with s-off. chip is more expensive than an xtc clip, cost $100 and would require soldering skills. By the time you changed the chip you will still be s-on and require xtc clip to s-off. So Im warning you s-off devs cause I already did this not so long ago.

Don't redo what is already done.
[HTC Wildfire S] bingzz:
What do you mean by chip?
[HTC Wildfire S] MrTaco505:
Any words from nhb about the mtdutuls?
[HTC Wildfire S] einstein.frat:
chip=processor

edit: I've replaced wildfire s chip 2x and no luck on achieving s-off with usb or sdcard. Only I gained S-off through rascal's xtc clip.
[HTC Wildfire S] theq86:
I can't believe that flicking a flag or patching the hboot to report S-OFF will break the cpu or whatever chip you mean. Have you sources to proove what you say?

Why then does revolutionary work by patching the hboot on other devices? Sorry but what you say sound's like a fairy tale. And it's not yet time for April fools.

I'm also sure nobody has done what we are trying to do. at least not on the wildfire s. It is VERY VERY unlikely that S-OFF without xtc clip breaks the chip. There is no reason why this should happen.

sounds for me just like subliminal advertising for the clip.
[HTC Wildfire S] :
What do you mean mtdutils? It's simply a toolchain, with utilities that have a function to do with the mtd partitions (mtd1, mtd2, mtd3, etc. (mtd7 in this case would either be the Radio or HBOOT, depending on the command you ran).

He must be very busy, with his personal life AND his XDA life.

Man, the pressure.................
[HTC Wildfire S] MrTaco505:
Yes but I thought we were working on the utils for a nand erase :confused:

Did I miss something again?
[HTC Wildfire S] theq86:
no. but it takes it's time
[HTC Wildfire S] :
Yeah. Complete and utter bull****. If it's true, then that would mean the XTC wouldn't work anyway. What's so special about the XTC Clip (don't answer that!)? My only theory to back this up is crap. The theory is that maybe there is something in the low level stuff (HBOOT, Kernel, Radio, etc.) that scans the secu_flag, to see if it's 0. If it is, then either HTC are being bad-assess and makes a script that super overclocks the CPU and burns it out, OR, the phone panics and tries a BIG bunch of stuff to rectify it, and accidently ends it's own suffering.

Stupid, I know. So, it's probably a fairy tale. Does anyone know when the WFS XTC was first made. Just curious. I have the strange feeling that it's a secret HTC operation, lol. As if......
[HTC Wildfire S] theq86:
there is no wfs xtc clip. the clip is the same device for all android models.

what it does is just to mimic a htc special sim so that the diag tool can make S-OFF and clear the sim lock.

the clip is never attached to the phone via usb, just the sim flex cable. the rest is done by the diag tool on the created gold card.

there is no mysterious magic that the clip does to protect a chip from breaking, this is really bull****.

also you are right, it is highly improbable that htc invented a self-destruction-like mechanism if you try to access the secu_flag.
[HTC Wildfire S] MrTaco505:
So how does revolutionary get past this "self-destruct" thing?
[HTC Wildfire S] theq86:
Can't you read?

There IS NO "self-destruction" thing or similar.
[HTC Wildfire S] MrTaco505:
Ok ok sorry :(
[HTC Wildfire S] humzaahmed155:
What phone do you have, do you have the CDMA Version? If not then where did you get the exploit from?
[HTC Wildfire S] :
If there was a self destruct thing, that would be COOL. BTW, considering were patching HBOOT, instead cant we follow the pointers till we find secuflag? I'd be happy to do it! :D

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] theq86:
Another useless and 34593 times already mentioned not working method :p:p:p

We would only get a memory address in ram.

every "simple" idea has been thought about already. and remember, this thread is for making progress in our plan, not suggesting new ideas :rolleyes:
[HTC Wildfire S] :
Sorry! (again, for the rest of my life) :(

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] hahahafr:
Please stop spamming this thread.

Let nhb and co. do they their awesome work here.

Thank you.
[HTC Wildfire S] AufDerAutobahn:
Been watching this for a while, want to ask some quick questions...

Is it known why the write operation doesn't succeed?

Can you control the mtd driver page table mappings? If so, can you dump that and take a look at what context it's running in? If not, what about having it create a new page table, hopefully somewhere you can modify? Basiclly, a potential problem is that of insufficient privilages.
[HTC Wildfire S] pihug12:
Kernel 3.3 got released today : http://www.engadget.com/2012/03/19/linux-kernel-3-3-merged-android-code/.

Some Android codes were merged inside. Maybe it's easier to adapt to our device now.

BTW, I lost my phone last week. I'm pissed and I don't know if I'll buy a WFS again. :(
[HTC Wildfire S] *se-nsei.:
Don't you have avast? or any phone locater app?

Sorry to hear.
[HTC Wildfire S] akshayf:
Maybe this app can be of some help https://play.google.com/store/apps/details?id=com.lookout.labs.planb&hl=en
[HTC Wildfire S] :
Now that is a good app!

The power of improvisation.
[HTC Wildfire S] MrTaco505:
Just found out that the Samsung Galaxy Ace has the same Qualcomm MSM7227 processor as the wildfire s. So maybe they can help us a little.
[HTC Wildfire S] seaskyways:
Exactly ! taka look at their kernels , and you can ask from the Wildire S sisters and brothers forums for help ! It will extremely be helpful , as of similar exploits and kernel devs could give critical help in our case !
[HTC Wildfire S] theq86:
atm we need no different kernel
[HTC Wildfire S] Divino:
wait, I think the WFS and the Ace are quite different and the WFS and the ARIA/GRATIA should be much closer! and ... my ARIA ​​is S-OFF (easily with revolutionary)!
[HTC Wildfire S] XDA_h3n:
Reply

Umm... Nearly 89.9% of samsungs have got rooted with SuperOneClick because its universal. After rooting their unrooted phone, they can then flash recovery.

The steps where it differs is Step 2, 3/4.

In step 2; If your using stock without any updates you dont need to downgrade, this would be diffrent on a diffrent HTC mobile like the WildFire S, since there isnt a s-off patch :(

In step 3/4: Other HTC mobile phones can use revolutionary,revoked,Paul's Visionary+, Very rarely; mount a iso file to the phone.

In step 5: Eng-soff, This means in n00b terms; the *developer*/*Ultimate* Hboot, you can install radios thats the diffrence (Theres more diffrences :3)

In step 1: Not quite sure if theres another way other than SuperOneTool, since I helped a friend on Xfire, who need rooted for a application on his galaxy.

But this just to help some people who asked that the Samsung Galaxy Ace has the same processor as the HTC Wildfire S.

___________________________________

Offtopic:p:

XTC Should be sued.

___________________________________

Now I'm going to see why I get a BSOD :mad: Probably a startup virus. I'm going to use msconfig to fix it up, untill then "Im All Linux :cool:"
[HTC Wildfire S] pihug12:
I had Prey installed on my phone, but it never got the SMS signal to active it. Neither my phone, nor my SIM card were used since I lost them, last wednesday.

Next time, I'll give a try at Avast if you tell me it's effective. Also, I heard that a phone can be retrieved with htcsense.com if the user registered before loosing it. But I didn't know of this website. :(

Sorry for the sad off-topic. :p

I thought mtd-utils were part of the kernel. Can you modify these tools without having to rebuild the entier kernel ?
[HTC Wildfire S] theq86:
yes. the mtd driver is part of the kernel. the mtd-tools are normal programs. we can modify them. first when that does not work out we have to change the drivers. the drivers are kernel modules. so it is unlikely that we must build a custom kernel either. unless we find no mtd drivers for our kernel version.
[HTC Wildfire S] XDA_h3n:
I should mention development takes time?
[HTC Wildfire S] no.human.being:
Sorry for violating what benjamingwynn just said, but just wanted to mention that I'm still alive and well. (Well, mostly. :D )

My last post was 5 days ago, on the 16th of March. I've been visiting my best friend from 16th till 18th of March (both inclusive). He lives approximately 100 miles away from my location, so I stay at his domicile when visiting him.

Of course I'm having internet access from anywhere, but I didn't take my notebook with me and my data is not in the cloud, so I'm not having access to my development ressources from his computer. In addition, I'm not exactly willing to spend my time developing when I'm hanging out with friends. :D

Last but not least, I've recently taken up an employment at a research facility.

Like I said, this WFS thing is not my full-time job, so please stop panicking when I'm inactive for some time. :p
[HTC Wildfire S] no.human.being:
It is f*cking close! This one basically works. I think that the only remaining problem is with "mtdutils/flash_erase" that we call from our code. We will have won as soon as it will erase the 4 blocks that hold the HBOOT. (Yes, the entire HBOOT is only 4 blocks, it's so incredibly small. :D ) Unfortunately, we're quite "blocked" as long as we haven't found a way of successfully erasing the NAND. There's no way to "bypass" this. As long as we haven't got a way to erase NAND blocks, we're doomed.

Our exploit works perfectly on a file, since the file system handles all the nasty details then, giving us the impression that we could "overwrite without erasing", while internally it is of course not overwriting, but redirecting our writes to different pages. On the actual NAND of course we can't do this. The HBOOT doesn't live inside a file system and has to stay at the same physical address, so we really have to find a way of erasing it there.

I don't see any other options. Either we get "mtdutils/flash_erase" to work, which in my opinion looks really screwed, even though this is "Embedded Linux" code, not "Android" code, so it's certainly not "intentionally crippled", but it's extremely "unclean" at least and in my opinion it's even plain incorrect. Or we get a kernel built that has a functional "mtdblock" driver. This driver simulates "in place overwriting", enabling the userspace code to successfully write to mtd devices without erasing them first, doing the "read-modify-erase-write"-cycle on its own. Unfortunately, the CWM kernel we're using doesn't have a functional "mtdblock" driver. There are "/dev/block/mtdblock*" device files, but each of them returns I/O error on fopen(...), so there's probably no actual driver behind them which could handle the requests. Only the lower level "/dev/mtd/mtd*" devices work. So the kernel was probably built without "mtdblock" support.

So if you can do one of the following ...

1. Get "mtdutils/flash_erase" to erase the mtd.

2. Get a kernel built with "mtdblock" support, that is otherwise at least as unrestricted as CWM kernel (Android kernels designed for "ROMs" probably won't work).

... you can probably slam the exploit onto it and get S-OFF. Now what we need is someone who can do either 1 or 2 or can advise us how to do it.
[HTC Wildfire S] no.human.being:
*se-nsei has always kept the community informed. He's probably the one who draws the most attention towards this place. :rolleyes:
[HTC Wildfire S] heavy_metal_man:
possible solution to all our problems

http://xdaforums.com/showthread.php?t=1240008 Ive been busy ;) i found this guy on the htc hd mini forum who built a custom mtd_utils so that he could write to the nand of his device:D:D and from what has been said on his thread he seems to have succeeded :cool::cool::cool:

have i done good sirs :p
[HTC Wildfire S] ratafak_plachta:
Did you just try to run flash_erase with -N or -u switches? At least Fedora's mtd-utils-1.4.3 has it.

The -N switch skippes check for bad blocks and -u does unlock (I have no idea what it is).
[HTC Wildfire S] hahahafr:
I'm not sure but I think this is awesome.
[HTC Wildfire S] :
This actually looks useful

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] SeeKai:
I've extracted the mtdutils from munjeni into the mtdutils on my sdcard and followed the steps as described in the top-post. Before executing the inject I adding LD_LIBRARY=/sdcard/mtdutils/lib (where a placed the lib folder from the tar file) to the environment and exported the variable. Unfortunately after running the inject my phone is still S-ON.

My bootloader screen details:

MARVEL PVT SHIP S-ON RL

HBOOT-1.08.0099

MICROP-0451

RADIO-7.53.39.03M

Nov 28 2011,19:09:21

EDIT: Using LD_LIBRARY_PATH didn't do the trick either...
[HTC Wildfire S] heavy_metal_man:
Are you using the *remove the safety * command?
[HTC Wildfire S] SeeKai:
Well, no since the parameters for the flash programs come from the inject program. I have neither the source code nor the compile environment to alter this.

@Antagonist42: You mean the write routines in the (recovery) kernel aren't able to alter the NAND flash in the WFS? In that case we need a new recovery image...

(I'm still a noob as far as phone hacking is concerned)
[HTC Wildfire S] :
Oh, about that. I know this is a bit stupid, but by using that RAM address, can't we get something like "tempSOFF" or something? LOL. Maybe then we can make it permanent!

Oh wait, that's already been thought, hasn't it?

Oh well, maybe we should start experimenting with those mtd_utils that HMM found. It looks very important, from my point of view.
[HTC Wildfire S] no.human.being:
The exploit can also be used on image files. So something like this should work:

# cd /sdcard
# ./mtdutils/nanddump -nf hboot.img /dev/mtd/mtd7
# ./exploit-inject --disengage-the-safety hboot.img
# ./mtdutils/flash_erase -u 0 0 /dev/mtd/mtd7
# ./mtdutils/nandwrite -n /dev/mtd/mtd7 hboot.img

This way you can tinker around with the erasure/writeback procedure.

Btw, what's so special about the "nanddump" and "nandwrite" utilities? I think that one should also be able to do it without them.

# cd /sdcard
# cat /dev/mtd/mtd7 > hboot.img
# ./exploit-inject --disengage-the-safety hboot.img
# ./mtdutils/flash_erase -u 0 0 /dev/mtd/mtd7
# cat hboot.img > /dev/mtd/mtd7

Should also work, right?

The exploit itself doesn't use any utility (neither "nanddump"/"nandwrite", nor "cat") for dumping and programming. It simply opens a file handle (this is why it works on both devices and images, all it needs is a file handle), reads the content into a buffer in RAM, patches in RAM, then performs an erase via "flash_erase" (this is the only program from "mtdutils" that it really uses, on a device this should erase the NAND, on a file this will just do nothing) and finally writes the content of the buffer back via the file handle.
[HTC Wildfire S] no.human.being:
The "file not found" errors appears, when the application is not statically linked against the glibc (standard C library).

Normally, you don't link it statically, since the operating system contains a "shared" glibc and this saves space in memory (have it one time for the entire system, instead of one time for every executable).

However, Android doesn't seem to have a shared glibc or is unable to dynamically link against it, so you have to compile each executable with statically linked glibc ("arm-none-linux-gnueabi-gcc --static -o myexec mysource.c" instead of just "arm-none-linux-gnueabi-gcc -o myexec mysource.c", as in the former case the "file not found" error will appear).

The "mtdutils" are built using the "automake" build system, so you have to edit the Makefiles so that the "--static" flag is set during compilation (had to do this for the standard "mtdutils" as well).