yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] pjakma:
Device files are for user-space programmes to open and communicate to the kernel, and so have the kernel do something on their behalf (e.g. "write this to disk there, please"). The wpthis module doesn't use this - it runs in kernel at module-init time and it sends MMC host controller commands pretty directly to the hardware. (ICBW: I know nothing about MMC and I'm just following the wpthis and Linux kernel code ;) ).
[HTC Wildfire S] BeciMester:
This guy has a disassembled hboot, albeit for a Desire S, but it should be handy to see what's happening in general.

Also: I'm ready to get my WFS clipped, so if someone can show me how to do a memory dump RELIABLY I'd be happy to do a 'before-after' comparison. By reliably I mean I get the real data and not random gibberish/RAM contents/SD card contents etc. you get the picture. I'm in no hurry, whenever I have the dumps I'll go. Anyone?
[HTC Wildfire S] mansmith:
Here is a small tutorial to compile your program with the codesourcery toolchain. I used the linux version.

http://benno.id.au/blog/2007/11/13/android-native-apps

Here is a tutorial to install the EABI toolchain on ubuntu.

http://ironwoodlabs.com/blog/codesourcery-for-arm-on-ubuntu/

I had some problems with the installing because the bash shell wasn't setup in ubuntu.

Also if you are running a 64bit version of linux, make sure you have the 32bit libraries for your distro.

sudo apt-get install ia32-libs
[HTC Wildfire S] humzaahmed155:
I Read some where that the xtc clip " is an automatic GOLD CARD Generator. It Automatically generates GOLD CARD for unlocking All hTC Android phones" if thats so then why doesnt anyone download the easy goldcard generator all you have to do is put your sd card in a sd card reader and generate one.
[HTC Wildfire S] ONeill123:
LOLOLOL

if it is so easy, then we all had s-off ;)

The xtc clip generate an goldcard, right, but then pushing the DIAG Files, and this DIAG file unlock the phone if the clip is inserted.

---------- Post added at 06:37 PM ---------- Previous post was at 06:10 PM ----------

Can anyone tell me, how to send AT commands to the phone?

Or can anyone execute these command and post the result and if u are s-on or s-off?

AT@SIMLOCK=9,%x

Found in hboot on offset 0x78440 after @secu_flag
[HTC Wildfire S] no.human.being:
I'm running on Fedora 16 (x86-64) and used the "non-install" tarball version, as I didn't want to run the installer as root (I'm a bit paranoid, as the system I'm on is used for mission-critical stuff).

Of course I could set up a virtual machine and install a Debian based distro inside for use with apt, but shouldn't the tarball version be sufficient?
[HTC Wildfire S] wildfiresuser:
How did you come to conclusion that the command should be used with 9? I assume you took this from a C file, right? Because %x should be either 0 or 1. 0 for s-off and 1 for s-on.
[HTC Wildfire S] ONeill123:
Bc this is in the actual hboot (1.08) after the @secu_flag in 0x78440 as a variable i think. SO if we change this value to 0 then i think we have an shipped s-off hboot, but i'm not sure.

And idk how to flash these hacked hboot :(
[HTC Wildfire S] wildfiresuser:
I already tried this AT command with 7,0 and 8,0 but it didn't work. Should I try with 9 too, what do you think :) I cannot be sure that it is safe or not.

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

Tried AT@SIMLOCK=9,0 without luck. Also it didn't restart the phone as it does with 7,0. It just returned an error I think, I only saw 4 under the cursor :)
[HTC Wildfire S] sythe179:
ok, so if adb errors when it trys to run the xtc scripts, does that other method error if you run them at hboot?
[HTC Wildfire S] Lt.Win:
I contacted the Salsa guys, and it seems we've got company! :D
[HTC Wildfire S] sythe179:
wild, what about 7,1?

what does that 0 stand for?..
[HTC Wildfire S] InFamousD147:
S-Off

Hey guyz , I have been working on my friends HTC wildfire s, trying many methods to get her fully rooted and S-OFF.

Tried :

Goldcard, loading different boot.img's and sizes 2gb/6gb/8gb

Tried old flashing methods from Rev, Alpha, SuperTool, even tried to unlock bootloader directly from HTC using sdk threw adb method.

I know about the XTC clip, and I dont want to get in to that. I am here cause I am trying to get full access and help out everyone else in the S-On club. Again this is for my friend I personally still run a OG, waiting on that d4. Anyways...

I have tried to flash RUU signed roms, and done every trick in the book that I am capable of atleast. Its to my belief the reason so many of us are having problems is simply because region and the carriers were on. I have read many forums about this phone similar to the one I am working on but not many people who are running it on T-Mobile, I was wondering when the droid 2 came out they developed a apk bootloader. Is this possiable? I understand the superone click methods but perhaps this isnt the route to take?> Perhaps to gain shell root access is to create an apk file that pushes a superuser boot.img that is triggered when the phone is booted up. Meanwhile running a program like HTC Supertool to catch the phones device driver as its loading and push the files it needs to override the S-on. I know its easier said then done, but if someone was willing to work with me I would be willing to beta test.

So far the only idea I have managed to fester similar to this is use the fastboot flasher with a custom boot.img and have the sd card formatted into a goldcard, and hope the exploit works. I am going to try this 2nite and will let you know how it goes. If anyone wants to brainstorm and has any suggestions please email me and we can vent or skype. Thanks all.... good luck trying to get this stupid S-ON, OFF, I have read in some post that this is the unhackable phone....I hope we can put a end to that chatter soon. PZ

InFamousD

Sithcoders.

T-Mobile

Marvel PVT SHIP S-ON RL

HBOOT - 1.08.0000

Radio - 7.53.39.11M
[HTC Wildfire S] sythe179:
tried that....

read the hole thread from around page 35 onwards...

well..dont see the point of giving a system dump now...

page back made me think that what i post is useless...even if it may be relevant..
[HTC Wildfire S] no.human.being:
I finally got a compiler to work inside a virtual machine. As it is very frustrating to always copy the binaries from the VM to the host to flash them, I try to get this working on the host as well. Stay tuned. We're finally making some progress again. :D

EDIT: Got the compiler to work on the host as well. It seems to produce ELF files for ARM, but they won't run on Android. I just tested a simple "hello world" program in C.

#include <stdio.h>

int main()
{
printf("Hello world");
return(0);
}

So nothing fancy here.

[developer@development ~]$ cd ~/my\ source/
[developer@development my source]$ arm-none-eabi-gcc -o hello hello.c -T ~/Downloads/arm/arm-2011.09/arm-none-eabi/lib/generic-hosted.ld
[developer@development my source]$ cd ~/Downloads/arm/android-sdk-linux/platform-tools
[developer@development platform-tools]$ sudo ./adb server-start
[developer@development platform-tools]$ ./adb push ~/my\ source/hello /data/local/hello
1114 KB/s (99033 bytes in 0.086s)
[developer@development platform-tools]$ ./adb shell
# cd /data/local
# ls
hello
tmp
rights
zergRush
# ./hello
[1] Killed ./hello
# exit
[developer@development platform-tools]$ sudo ./adb kill-server
[developer@development platform-tools]$

Anyone knows what's going on here? When I'm using "generic.ld" instead of "generic-hosted.ld", I will get additional warnings during the compile, but the same result when running the code on the phone.
[HTC Wildfire S] Mazer.one:
that the force be with you no.human.being
[HTC Wildfire S] theq86:
maybe we could get over compilation by using assembler. I know, it is much harder to program, but a simple program like this should be done very easily ?!?
[HTC Wildfire S] no.human.being:
I tried the arm-none-linux-gnueabi version of CodeSourcery now instead of the arm-none-eabi and this one works. The code is now as follows:

Code removed. Outdated.

It's just running on my mobile device. I'll probably publish the binary for you to try out when I consider it "safe" and when the license of the compiler permits it (not sure about that yet).
[HTC Wildfire S] roussela2:
@no.human.being

You've got an error (Seg Fault) because "/dev/block/mtdblock3" is not readable and writable as is.

I think you should use /dev/mtd/mtd3 instead, which works when I make dumps with adb.

Example :

cat /dev/block/mtdblock3>/sdcard/dump.img ==> doesn't work

cat /dev/mtd/mtd3>/sdcard/dump.img ==> work !

But I can always be wrong.

PS : sorry if I make spelling mistakes, i'm French.
[HTC Wildfire S] no.human.being:
Nope, I already got it. I tried opening "/media/sdcard/dump.img" for dumping, but the correct path is "/mnt/sdcard", so the fopen returned NULL and I was working on a null pointer. It's working now. It's dumping my "/dev/block/mtdblock3" to SD card currently. Let's see whether it gets through.
[HTC Wildfire S] sythe179:
dont know C# or java myself, but im sure you could write the zergrush file and run it with your script....not sure if it needs to be run at boot-complete or not....

(adb cmd code for zergrush)

adb shell "cd /data/local/tmp/; rm *"
adb push files\zergRush /data/local/tmp/.
adb shell "chmod 777 /data/local/tmp/zergRush"
adb shell "./data/local/tmp/zergRush"

also, when its finished, is it going to be an apk,

is there going to be a tutorial for running if it needs to be through that other method,

or is it going to be a adb script?

just wondering is all.
[HTC Wildfire S] hanynemesis:
I wish u guys get s-off soon
[HTC Wildfire S] no.human.being:
I'm not sure yet, whether I may publish the code I compiled using CodeSourcery as it is the "free" (as in beer?) license and I'm unsure about the license terms. Might have to check that again.

I will certainly publish the following:

- Source code for the exploit

- Instructions how to build it

- Instructions how to apply it

When I may redistribute binaries created by CodeSourcery, I will probably also publish a compiled version so that you don't have to register for a CodeSourcery license for building the exploit, set the toolchain up and build it all yourself.

The zergRush exploit itself is "Copyright (c) 2011, The Revolutionary development team.", so I will not bundle it. You will always have to grab this one yourself and execute it on your phone before executing mine, at least if the Revolutionary team does not give me explicit permission to redistribute it with my application.

Maybe I'll give Revolutionary the permission to incorporate it in their software (if they're willing to) to make it support the WFS too, so that we're getting closer to a true "all in one" solution for S-OFFing the HTC phones, I'm not sure about that yet. However, the exploit source will definitely be published under a GPL license (probably GPLv3) in the end so that you may feel free to use it if you're making a "Free Software" (as in free speech) S-OFF tool and can always grab the source and build it yourself should Revolutionary become "pay to use". You see Revolutionary is closed-source, they state on their website that they are unwilling to open it up and you need to obtain a key for each phone you're unlocking, so I suspect they're going commercial when it moves out of the "beta" phase, so I'll definitely license my exploit separately, so that you may still use it even when Revolutionary goes commercial.
[HTC Wildfire S] sythe179:
sounds like a smart idea.

wait...so adb or is that the hboot method?
[HTC Wildfire S] no.human.being:
HBOOT is not involved at all. You ...

1. put the phone into debug mode

2. connect it to your computer via USB

3. start the adb server on your computer

4. push zergRush exploit onto your phone when you haven't done that before

5. open an adb shell and delete the temporary zergRush files (boomsh and sh) if you haven't done that before, then run zergRush

6. do adb remount

7. open adb shell again to obtain a root shell on the phone and run my exploit inside (*)

9. disconnect from the root shell

10. stop adb server on your computer

11. reboot your phone and be S-OFF (**)

(*) The exploit literally takes ages to complete. It's running on my phone for 3 hours straight, still at Step 1 (Offset: 3ff000). NAND access seems to be painfully slow. No idea how big "/dev/block/mtdblock3" is so no idea how long this will take. Probably not the fastest method to bulk-dump it, then patch it, then put it all back in, but who cares if it gives you S-OFF?

(**) We're not here yet, as my exploit currently only dumps and creates a patch, but not write the patched image back to the phone memory, as this is too risky. The offsets where I'm patching are probably still wrong. Might be quite some amount of work to figure out the correct ones.
[HTC Wildfire S] sythe179:
how do you make an image?....might as well start looking through myself...

and what hex/file reader are you using?...
[HTC Wildfire S] no.human.being:
The exploit is doing the following:

1. Dump the contents of the "/dev/block/mtdblock3" device to a file called "dump.img" on the SD card.

2. Patch that file to obtain S-OFF. (*)

3. Flash the image back from the SD card to the phone NAND. (**)

(*) This one is probably still faulty as the offsets are probably incorrect as they're from a Desire S, not from a Wildfire S.

(**) This one is currently commented out so that you don't brick your phone by writing a lot of nonsense to the NAND device.

After step 1 is finished, you may basically terminate the program to obtain the dumped image from the SD card or you may let step 2 run through also to obtain the image and the patch from the SD card. However, each step literally takes ages to complete so don't do this if you're in a hurry. You probably have to run this overnight. :D

For viewing the files, just grab them from the SD card after completion and view them with whatever software you're having on your host. Disassembler for ARM might come in handy, but I haven't found a suitable one yet.
[HTC Wildfire S] bonesy:
Well this "may" Help, It's the file used in the XTC Clip, If you can manage to bypass the secure flag this has the diag file used to Clean S58 Data.

Please please please please DO NOT FLASH THIS! You will have to extract the file from inside the zip
[HTC Wildfire S] sythe179:
thats a 0.81.2000 hboot?..

think its been posted about a page or two back, and a few times before that,

but thanks anyway.

and..like the others....

vendid=0x14e4
devid=0x432f
boardtype=0x4b9
boardrev=0x36
boardflags=0x200
ofdmpo=0xAAAAAAAA
mcs2gpo0=0xCCCC
mcs2gpo1=0xCCCC
rcal_flag=0x61
[HTC Wildfire S] humzaahmed155:
Im not saying i will flash the file from the clip, but just out of a matter of interest:confused:, what could be the result in flashing this to my WFS
[HTC Wildfire S] trampi:
Just as a short info:

HTC has officially unlocked the Bootloader for HTC Wildfire S now, see on htcdev DOT com SLASH bootloader

Wishing you still all the best!

(I am a programmer myself and i know that you probably won't stop until you've got a s-off developed yourself. Just keep posting what you do and how it works, it is really interesting for me, as i am new to android!)
[HTC Wildfire S] intel007:
Yes bootloader unlockable woohooo

They finally gave in to customer demand!

Nice.
[HTC Wildfire S] no.human.being:
Lol, YES! :D

They have realized how close we have come and given in. :D

Shall we continue for "true" S-OFF or do you say that's sufficient?
[HTC Wildfire S] d33ps1x:
Is that even a question?

Forward march... ;)
[HTC Wildfire S] trampi:
As i've already posted: DO IT! DO IT! DO IT! :D

I love to read what you do, i am a programmer myself and i think it is very exciting to read about your progress, what you do, the source codes, ...

Don't you want to finish it, now that you are so close? ;-)

Greetings fro Germany,

trampi
[HTC Wildfire S] qzfive:
I would probably recommend you still try and find an S-OFF exploit. The HTC-Dev method (afaik) just removes the protection on the boot, recovery and system partitions, so you can't flash radios, bootloaders, etc.
[HTC Wildfire S] BeciMester:
Now, if this below is true...

(It's from another thread here)

...where does it leave us? I don't think we should stop developing full S-OFF as we still can't do whatever we want.

It'd be interesting to look at the changes in the new hboot that's flashed with the RUU.

Desire-Oxygen2.3.2 | WFS-stock
[HTC Wildfire S] humzaahmed155:
Its funny because i tried this yesterday and it wasnt listed, but today has probably been the best day for me n my wfs:)

*The only drawback i have now is my battery life lol

** i just started, does anyone know if this enables over-clocking and if this takes the sim lock off?

*** My Android version isnt 2.3.5 because my Service Provider (TMO-UK) has not released it Yet, so this was a massive FAIL for me. And yes, you have to be on 2.3.5!
[HTC Wildfire S] no.human.being:
Nice to read that bro. If you're a programmer yourself, don't you think that you're able to contribute code to this?

And I don't think they have given in to customer demand. They probably had to unlock due to copyright reasons.

Android is based on Linux. Linux is GPLv2 licensed. And even though I'm not exactly sure whether GPLv2 already states that technical means to prevent modification are a violation of the license (GPLv3 explicitely states that), it is common sense that such measures are against the very nature of that license agreement.

They had to give in sooner or later, or the FSF would have sued the hell out of em.
[HTC Wildfire S] b02:
after unlocking bootloader, u can unlock sim ofc.... also u can put overclock kernel and overclock it .. =)

funny thing is that i payed 10 euros 2 days ago to unlock my phone via xtc clip =D
[HTC Wildfire S] *se-nsei.:
I TOLD YOU SO DIDNT I?!? I TOLD YOU ALL :D

now go run along and unlock your bootloaders and play. :D

@no.human.being - I'd suggest that your hard work is not gone lost, it's still needed as I believe this HTCDev unlock will still keep some restrictions in place.

It's a good day.
[HTC Wildfire S] KaJI9gyH:
no.human.being,

Only Linux Kernel is licensed under GPL and HTC had published its sources. But bootloader isn't. So there are no violations.
[HTC Wildfire S] no.human.being:
18 MB dumped so far. Exploit still up and running for a bit more than four hours straight. What's the capacity of that block device? This takes ages, but it's not locked, it's still alive and making progress. The memory is just soooo incredibly slow.

The problem is that you must not protect a device against modification when deploying GPL software on it. The GPL actually requires you to do more than just open up the source.
[HTC Wildfire S] No.12:
Great day for us,WS users.:D

@no.human.being : please,we are still counting on you for the full S-OFF !!!
[HTC Wildfire S] ONeill123:
Maybe now with unlocked bootloader it is easier to set s-off?
[HTC Wildfire S] BeciMester:
Hold your horses guys

The update pushes a new radio image as well. In fact, two radio images. I don't know how the program decides which one to flash. There are 2 ROM.zip files in the package, and only one of them has a hboot image:

rom_01.zip:

--Radio_special_MARVEL_MR_47.23b.35.3035_7.54.39.08M_Signed_20111208.img (23.3 MB)

rom_02.zip:

--hboot_1.08.0099_6e20b6fac09.nb0 (512 KB)

--radio_47.23a.35.3035H_7.53.39.03M_MR.img (23.3 MB)

Does it depend on the phone being SIM-locked? But all phones need a new hboot, so why the other one doesn't have it?

Edit: the important question is: are they patching something up with the new radio?
[HTC Wildfire S] no.human.being:
I have optimized the code a bit to read multiples of the MTD's native block size. It's MUCH faster now. Steps 1 and 2 go through within minutes. Please check back here.

So "only" challenge left is finding the correct offsets for the WFS. Anyone got an idea how we might accomplish this?
[HTC Wildfire S] *se-nsei.:
Great news.
[HTC Wildfire S] d33ps1x:
Anyway to dump my S-OFF'd info and compare with an S-ON for changes?
[HTC Wildfire S] sythe179:
Link a hex editor, and upload the image.

Let's all start looking?
[HTC Wildfire S] no.human.being:
Of course, the exploit makes a full dump of partition 3 onto the SD card. The patching stuff still seems to be bugged, but the original image should be fine.
[HTC Wildfire S] No.12:
One noob question?

If we are able to install custom recovery,custom roms and kernels,do we need actualy s-off?

What is the difference?
[HTC Wildfire S] sythe179:
Please dont stop your progress,

australian users, and the australian companys have yet to make the 2.3.5 software update avalible, and htcdev.com has yet to do it aswell.....kinda stuck...

basicly, where (us in australia) are still no better off atm...

and no.human, i would help code, but i only know the useless language of vb.net.....

(and about 9 months of studying ms-dos)....
[HTC Wildfire S] no.human.being:
Custom bootloader, custom radio, SIM unlock, SuperCID.

HTC doesn't know that you S-OFFed when you return it to S-ON afterwards, while they will know for sure when you signed up at their site (warrenty loss), HTC may take their offering back at a later point in time, while an exploit will always work (until the vulnerability is patched).
[HTC Wildfire S] No.12:
Keep it going,feel that you are close.;)
[HTC Wildfire S] d33ps1x:
Just let me know what to dump and how and it's yours.
[HTC Wildfire S] no.human.being:
What do you have? Stock with Android 2.3.5 OTA, but S-OFF via xtc-clip?

I have attached the compiled exploit as "patch.zip". Just extract it and you will find a file named "patch" (no extension). It is the compiled source from here. Download and build Android SDK, download zergRush binary, enable USB debugging on the phone, then do the following:

[your computer]$ sudo ./adb start-server
[your computer]$ ./adb push zergRush /data/local/zergRush
[your computer]$ ./adb shell
$ cd /data/local

If you still have to remove the temp files from an earlier temproot, do the following:

$ cd tmp
$ rm *
$ cd /data/local

Now run zergRush exploit:

$ ./zergRush

Wait until exploit is finished, you will be disconnected from adb shell. Remount and open adb shell again.

[your computer]$ ./adb remount
[your computer]$ ./adb shell

You should now have a root shell (note the "#" sign):

# exit

Now push my exploit onto the device, open the root shell again and run it.

[your computer]$ ./adb push patch /data/local/patch
# cd /data/local
# ./patch

This will take approximately 6 minutes. When finished you will be returned to adb shell. Quit and stop the adb server.

# exit
[your computer]$ sudo ./adb kill-server

Now disable USB debugging on the phone and either shut down the device, remove the SD card and put it into a card reader to read the dumps from it or reboot the device and, after it is rebooted, select "Hard drive" as USB feature so that the SD card is exposed to your computer, then pull the files via USB.

That's basically it. "dump.img" is the original dump of your "/dev/mtd/mtd3", "patch.img" is the patched dump that the exploit would flash back to NAND when the third section was not commented out (which it is, so don't be afraid :D ).

After we got the offsets right the only thing that's left should be commenting in the last section of the code, compiling again and wh00ps, S-OFF.

Code removed. Outdated!
[HTC Wildfire S] bond66:
i can obtain a dump of my WFS if that helps

thank you all for your effort, it's really great! :)

I own a WFS with 2.3.3, s-on , HTC sense 2.1

kernel 2.6.35.10-gb162d16

htc-kernel@and18-2 #1

baseband 47.10.35.3029H_7.46.35.08

If that helps, i can try whatever utility or script to refine it (to see if offset is correct).

to HTC: ok, if i unlock the bootloader i void my warranty, simply provide a way to load an HTC firmware via the HTC Sync in case of problems ( maybe like APPLE or a PC ? )

Up!
[HTC Wildfire S] eoghan2t7:
just reflash the stock RUU it might get warranty back lol
[HTC Wildfire S] theq86:
there's a command on htcdev site which re-enables bootloader lock
[HTC Wildfire S] hanynemesis:
why should we (normal users )or devs need Custom bootloader, custom radio, SIM unlock, SuperCID ?

sry its newbie question