yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] heavy_metal_man:
excellent :cool:i`ll be happy to help:cool: also if this works will it be the equilivant of nand-s-off radio s-off? like would we then be able to flash .nbh diag files ect? and, since the wildfire has been rev. s-offed, would it be easier to write to this information or would we stick to our guns with this system?
[HTC Wildfire S] theq86:
the original wildfire (buzz) by the way is supported by revolutionary.
[HTC Wildfire S] heavy_metal_man:
i know man :) im trying to find a way to get a software sim unlock for the buzz, and if we get perminant nand unlock we should be able to flash the xtc clip diag file and gain supercid and simlock removed (i hope :P ):cool:
[HTC Wildfire S] no.human.being:
1. If the secu_flag itself is accessible via mtd (remember, it is accessible on the Desire S) then it will be a full Radio S-OFF, like if you applied the xtc-clip. However, xtc-clip also sets SuperCID and does a SIM unlock. Probably when we find the secu_flag by comparing stock vs. xtc-clipped phone, we will also find the CID and the SIM lock information and can patch that as well. Then we'll have exactly the same effect as xtc-clip, just without hardware involvement.

2. If the secu_flag is not accessible via mtd (unlikely), we probably have to patch the HBOOT. The HBOOT is also not accessible via mtd, but there must be a way of patching it nonetheless as this is what Revolutionary is doing and it will give the same effect as Revolutionary does (which means that the S-OFF will probably go away when you flash the HBOOT). However, this will be a totally different exploit and I'm currently having no idea how it is performed. The HBOOT doesn't seem to be visible from within Android at all, its memory is probably "mapped out" as soon as Android is loaded. We first have to find a way to "map it back in" before we can patch it. This is probably gonna be damn hard, so I really hope that method 1 will bring us success.
[HTC Wildfire S] heavy_metal_man:
that sounds epic man :cool:i hope for senario 1 as well :) also this exploit, as it stands currently would it work on a wildfire? like to perform system dumps with s-on an stuff?

also keep me posted about the modified program. i will be over to see my friend on wednesday;)
[HTC Wildfire S] BeciMester:
Guys, I have browser tabs open at home for stuff related to dumping NAND memory, I'll look into that tonight, I can't remember a thing of it now.

Also, a few thoughts:

1) why is it that the WFS, a relatively low-end phone, is so hard to S-OFF while newer and more 'upmarket' phones are done already? Is it just the lack of dev effort so far?

2) The secu_flag is probably (hopefully) at somewhere accessible like on the Desire S, it's just that the way there is obfuscated so it's not easy to find. I have high hopes of something similar to the DS. :)

(I'm on my phone...)
[HTC Wildfire S] no.human.being:
Yes, lack of effort and newer handsets are often not secured at all and can either be "officially" unlocked using Android SDK or have unlocking/flashing utilities "leaked" from their manufacturers, e. g. the Samsung Galaxy S2 can be unlocked using a software named "Heimdall" which is a reverse-engineered version of an internal Samsung utility called "Odin". Locking handsets is "old practice", the newest handsets are either shipped unlocked or provided with an official unlocking method.

The problem with the WFS is probably also that there were almost no Custom ROMs available. There's a version of CM7.2, but it's not around for that long and it's an "inofficial" port. No one is interested in unlocking a handset for which no alternative firmware exists.
[HTC Wildfire S] heavy_metal_man:
you forgot something

i will definatly get this done asap. also you didnt post the attachment...... and if i cannot downgrade the hboot and radio to pre htc dev will it really matter?? i will do my best, and im pretty sure i can but if not will it do?
[HTC Wildfire S] no.human.being:
No no no, stop! Don't downgrade! Afaik, you can only downgrade HBOOT AFTER obtaining S-OFF and then there would be two modifications between the dumps. Do the dumping directly BEFORE and AFTER xtc-clipping the phone. I only want to see the changes that the xtc-clip did, not changes that result from an HBOOT downgrade or other firmware modification. So between the two dumps all that's done to the phone should be xtc-clip. Do as least modification to the phone between the dumps as is possible. It's hacker's lore: "The quieter you become, the more you are able to hear." :D

Also please remove my quote from your post, it's REALLY verbose. :D

EDIT: Well and the attachment is here...
[HTC Wildfire S] heavy_metal_man:
ok man groovy. shall not downgrade and will do dump, xtc clip, dump:cool:

also verbose? never heard this word before lol what does it mean?
[HTC Wildfire S] no.human.being:
"verbose" is synonymous for "wordy", "long-winded". Many utilities have a "-v" or "--verbose" command line switch which makes them output debug messages and stuff users normally don't want to see, but sometimes might be helpful. :D
[HTC Wildfire S] heavy_metal_man:
excellent :D you learn something new every day :P well i will let you guys know when i get my hands on this phone and i will post my results asap. wish me luck :cool:
[HTC Wildfire S] heavy_metal_man:
also, what size sd card should i use? will a 2gb one be to small?
[HTC Wildfire S] d33ps1x:
My original posts from ages ago...

http://xdaforums.com/showpost.php?p=19859558&postcount=146

http://xdaforums.com/showpost.php?p=19865599&postcount=149

The Image link:

http://www.4shared.com/file/AxKdO5ql/XTC-Clip_V2_All_Hboot_Ver_HTC_.html
[HTC Wildfire S] m1ndh4x8r:
will this contain a milworm exploit?
[HTC Wildfire S] no.human.being:
No, it's ok. The entire on-chip NAND of the WFS is 512 MiB in size. This includes all the areas reserved for internal use by the processor (initialization code, etc.) so the "accessible" address range will be smaller. Then we don't want to dump all the user data and cache anyways, so they'll also go away.

When you have one set of dumps (e. g. pre-S-OFF) peformed, you can move the files from the SD card to your computer to free up more space on the card should this be required. Otherwise, if you don't remove the dumps, please choose distinct names (e. g. "mtd0son.img" and "mtd0soff.img") for the S-ON/S-OFF dumps so that you don't overwrite the former with the latter.

In fact you could actually dump each mtd device independantly, then move the file to the PC, if you are on extreme space constraints, but I'd suggest you to dump them all in a row, then move them all over, as this results in much less work.

Err .. not sure what you mean but I don't think so. It's zergRush exploit to obtain root privileges and then it just dumps all information from the device you specify as <SOURCE> into the file you specify as <TARGET> as a series of 4096 byte chunks.
[HTC Wildfire S] humzaahmed155:
Some one did mention that ICS (Android 4.0) is being worked on http://blog.cryptomilk.org/2012/01/23/cyanogenmod-9-for-htc-wildfire-s/
[HTC Wildfire S] no.human.being:
Yep that's right. I'm also waiting for this one, obviously. But it's all been "recently" and most of it is still in the "alpha" stadium, e. g. Android 4 barely manages to "boot" on the handset, but nothing works. The audio drivers don't work so you cannot use it as a telephone. Not even the touchscreen or the buttons work so at the moment you have no means of providing any input whatsoever.
[HTC Wildfire S] d33ps1x:
Any use in that Goldcard image no.human?
[HTC Wildfire S] b02:
one question, is it possible to revert to s-on now when i unlocked with xtc clip ?

and will this process that you are trying to make be revertible, and also change back to s-on when needed ?

sorry if the question is allredy answered on some of the previous pages, since i didn't read everything ... :P
[HTC Wildfire S] no.human.being:
As far as I know it's not possible.

Returning to S-ON should be possible. Basically it's just a binary flag you flip. However, restoring the original CID and restoring a potantial SIM-lock that was enabled on the phone would probably be much more difficult as there is actual information being overwritten by the patching process and you'd need to create a backup of the original data to restore the previous state. It's probably not worth it.

Interesting questions would be:

- If you gained S-OFF via xtc-clip, will my software be able to revert the phone to S-ON?

- What will happen when you have CWM and a custom ROM installed and then go back to S-ON without restoring the phone firmware from a stock RUU?

I really don't know the answer to both questions. Could anyone make an educated guess what would happen?
[HTC Wildfire S] theq86:
Your exploit would change the flag itself. As we know, after updating to 2.3.5 every S-OFFed stayed S-OFF. This is covered by the fact, that the flag lies outside of the hboot or radio flashed area. (so htc never touches the secure area, which is actually understandable)

That means: Logically the clip and your exploit would s-off the phone at the same address. and not in bootloader.

Therefore I think a clipped s-off will definately be changeable by your exploit.

what we can NOT do is restoring old CID oder sim-lock, as the xtc clip does not back up the values - in opposite your exploit could do a backup. so clipped S-OFFed will have a little inconvenience.

If you are S-ON again, (and not bl unlocked) the bootloader will be locked again. write protection to recovery and system are thus restored. It will not make your device unusable.

Now disadvantages:

Custom Recoveries are not able to bypass write protection (I've tested it) So you will have a booting but unfunctional custom recovery, which is not able to wipe ANYTHING.

As HBOOT is connected with HTC recovery, the factory reset option will not work anymore.

Means: You can S-ON it again, but won't be able to factory reset or wipe userdata , unless you have flashed stock recovery in advance.

Hope I could help you
[HTC Wildfire S] heavy_metal_man:
Ok guys today is the day. I am on my way to get the plane now. I will update hopefully with the files asap. Nobeinghuman, could you be on hand, or check into this thread from time to time just incase I run into any problems? Wish me luck guys ;-)
[HTC Wildfire S] heavy_metal_man:
hey guys, running into some trouble here.

when i type start-server nothing happens.

i`ve managed to push the files to data/local but i cant cd to data local. it says patch not found. also tried sudo but i am on a windows terminal so i tried to run it with admin permissions to no avail. help
[HTC Wildfire S] b02:
maybe just visually make it say in hboot s-on, simple letters... since as i know how workers from my service provider behave here, they know exactly nothing, and such thing would be enough to fool them :-D
[HTC Wildfire S] BeciMester:
Do you have all the files for adb in your folder? It's not just adb.exe, there are 2 more, I can't remember the names. If everything is working, even if the server couldn't be started it should say so. Also I could never get adb work on windows 64bit, only on x86. hth

edit: make sure your phone's drivers are installed. You should see 'adb composite interface' in Device Manager.

(I'm on my phone...)
[HTC Wildfire S] ONeill123:
you can run adb in 64 bit architecture as well.

sudo is a linux only command but not implemented in android, the reason is NOT windows terminal.

Adb nèds no admin rights, it must be run or not. if u dont know how to setup your pc for adb, then please read the topics here and gögle to know more about adb.
[HTC Wildfire S] no.human.being:
So the "adb push ..." worked? It's "/data/local" though. It's an absolute path.

Make sure you're on a remote shell with the handset (adb shell), not on your Windows cmd shell. Then do "cd /data/local" (make sure it starts with a "/" as it's an absolute path). Should work.

We're not talking about "sudo" on Android, we're talking about "sudo" on the host machine that's running the Android debugger (adb). On a Linux machine you need to start the adb "server" (this is a daemon process that talks to the adb cli "frontent" one one side and to the handset on the other side) as root, otherwise it will not find the handset.

So you need to do: "sudo ./adb start-server" so that the adb server runs as root, then you can do "./adb push ...", "./adb pull ...", "./adb shell ..." etc. from your local (unprivileged) user to interact with the handset and then you'll need to "sudo ./adb kill-server" to stop the adb server again.

When you start the adb server from your unprivileged user account, it will not find the handset. I think unprivileged processes cannot access the hardware (USB port) so it cannot talk to the handset while run from an unprivileged UID.

I don't know how adb will do this on a Windows machine. I'm not having a "physical" Windows installation on this machine, so I can't test it. I'm doing all the development on my Linux host. But probably you can just do "adb start-server" and "adb kill-server" on Windows. Perhaps run the cmd.exe as Administrator. Not sure. Tinker around a bit, you should get it to work.
[HTC Wildfire S] heavy_metal_man:
we have success.

ok guys, after a LOT of hassle and rage i have the files.:D

now, things didnt go as well as i would have like to but we got there in the end. firstly i couldnt get the adb stuff to work, i had all the files in the folder as needed.so i used a combination of root explorer, to move the files to data/local and to change the permissions. i then used terminal emulator to run the dump command which had success! i then s-off the phone with xtc clip. i then installed superuser by .zip from recovery(i know you said not to install anything but i couldnt do it the other way, and the clockworkmod was already still on the phone.) then i installed root explorer and terminal emulator and repeated the process. my friend who owns the phone would like to be mentioned as well so these dump files are proudly dumped by Heavy_metal_man and christopher mullan.

also my dropbox is taking a while :P no.being.human should i send you the link directly or just post it up here?
[HTC Wildfire S] no.human.being:
As long as there's nothing in it that is in any way "confidential", just post it here. Other people might want to take a look at the dumps as well. Thank you very much for your efforts. I hope that these files will shed light on what the xtc-clip is doing to obtain S-OFF.
[HTC Wildfire S] heavy_metal_man:
i hane no idea if there is anything confidental in them, i dont know how to open them :P
[HTC Wildfire S] no.human.being:
Well it's a raw dump ("forensic image") of the mtd devices you specified on the command line. As long as you didn't dump the mtd4/5/6 devices, there should not be any confidential information contained. I'll open them with "dhex", which is a binary comparison tool. It's the equivalent of "diff" for binary files ("diff" will only handle text files).
[HTC Wildfire S] heavy_metal_man:
ok as soon as this file as loaded to my dropbox i will post the link :)
[HTC Wildfire S] hahahafr:
I'm also curious to compare them myself. Keep us updated when both files finish uploading.
[HTC Wildfire S] no.human.being:
"Both"? I expect it to be a ZIP archive that contains 8 *.img files. 4 pre-S-OFF and 4 post-S-OFF, both sets containing images of mtd0 to mtd3.
[HTC Wildfire S] heavy_metal_man:
proudly brought to you by Heavy_metal_man and christopher mullan

as promised ladys and gentleman here are the files. in a zip which contains two folders labled s-on and s-off and a .txt file which breifly explains what i did and how i got them.

keep me posted as to if they are any use, and let me know if there is any personal stuff on it please :)

http://dl.dropbox.com/u/57829552/dump files.zip

:D
[HTC Wildfire S] no.human.being:
Ok, so first I want to mention that, fortunately, on most partitions, there's none or little difference.

On the "mtd0", there's the string "HTC__001" at the beginning on the stock image, followed by 24 bytes of 0x00 for a total size of 32 bytes. This is changed to 32 bytes of 0xff from the beginning. Might be CID-related as there's a CID called "HTC__001". Afterwards, there are some strings with lots of empty space between them. This is all untouched.

"mtd1" contains an Android kernel (no file system, the kernel IS the content of the block device) and is completely untouched (S-ON = S-OFF).

"mtd2" contains an Android kernel (no file system, the kernel IS the content of the block device) and is completely untouched (S-ON = S-OFF).

"mtd3" contains a file system and there are significant differences starting around offset 0x04f60000.

It's interesting that there seems to be a CID on the "mtd0" ("misc") partition. From the Desire S we know that there are three areas that are patched for secu_flag, CID and SIM-lock and they are all on the same partition there. From the HBOOT we know that the secu_flag is the least significant bit of a machine word. It's good to know that the kernels are untouched. The contents of "mtd3" are difficult to analyze as it contains a file system. However, I don't think that the secu_flag resides on a partition that contains a file system, so we can probably ignore "mtd3".

Conclusion? I'd say the security-relevant information is indeed not accessible via the mtd devices, what do you think? Can we check which areas of memory (physical areas) are mapped to which mtd devices? We could check for "gaps" in the partitioning where such information could have been "hidden" by the HTC engineers.

Thank you very much for the dumps, heavy_metal_man.
[HTC Wildfire S] heavy_metal_man:
its cool man. pity they were not as good as we were hoping for.is there no way to reverse engineer the xtc clip diag file so it could tell us where its writing to? also something to note, while i was using the xtc clip. it said it was looking for the software version, and then failed to find it and it said to check the security flag. so i turned off the phone and it was still s-on. so i had a bit of a look on google and it said to just carry on anyway and clear the s58 data. so i reconnected the xtc clip, it said software version failed again, i continued on to the clear s58 data. an it did so successfully. i then rebooted into bootloader and i was s-off. so im beginning to think that the diag file does all the work and the flexy cable is just for confirming that it can do it.

any good information?
[HTC Wildfire S] BeciMester:
I'll post info regarding just that, once I get home from college. There seems to be a way to manually override the partitioning (temporarily anyway) and assign mtd devices to all the hidden partitions so they can be mounted. ;)

(I'm on my phone...)
[HTC Wildfire S] heavy_metal_man:
How would we do that?
[HTC Wildfire S] theq86:
rational? no, just some thoughts.

if a phone like desire s was so hard to crack as the wfs, it may decrease selling numbers. maybe therefore they just changed the secure address.

a cheap phone like ours, would other way round be a too "powerful" device after unlocking (for that price), so that it may be a political decision.

sometimes manufacturer build a phone and do experiments with them. maybe wfs is kinda prototype device with a securer lock

so whatever the reason is, I guess it's no technical reason, but a reason of policy
[HTC Wildfire S] no.human.being:
Well "cheap". When I bought it, it was one of the few devices already featuring Android 2.3.3 and it cost more than 280 € for an unbranded original. This is the price I paid and it was pretty "standard" for a phone with this feature set back then. It's only cheap as it's obsolete now with newer devices featuring display resolutions of 800x480 or even 720p, AMOLED, FullHD video recording, multi-core processors, NFC, etc.

Almost all manufacturers go towards shipping the devices unlocked or to implement an official way of unlocking them (e. g. via fastboot commands) so the trend is exactly the other way round. Locking devices is considered "obsolete practice", especially as Android is GPLed software and implementing technical measures to hinder modifications is against the license terms. If the FSF was starting to sue phone manufacturers, they'd probably earn a fortune of "compensation fees" for the license violation that every single manufacturer that ships locked phones is committing. This is why phone manufacturers are gradually moving away from bootloader locks and similar stuff.

Yes probably.

EDIT: I've just compared heavy_metal_man's S-ON dumps against my own. Remember my phone is S-ON, but has CWM and Custom ROM installed. The "mtd1" partitions (which holds the kernel of CWM) of both phones are exactly identical. "mtd0" is larger on my phone (1.048.576 bytes vs. 655.360 bytes at heavy_metal_man's), my CID is different and the strings have more "space" in between them at mine. Of course the "mtd2" (Android kernel) and "mtd3" ("/system") images differ extremely because I'm having CyanogenMod 7.2 installed. So the real interesting stuff is definitely not on the "mtd" devies. It's likely in some kind of "unmapped memory". Let's see if we have any chance of finding out where it is and getting there.
[HTC Wildfire S] hahahafr:
@no.human.being;

I just gave a look at the dumps given by heavy_metal_man, everything you said about mtd0 to mtd2 is true. My question is, are we sure mtd3 contains nothing relevant to the secu_flag or anything. Why file(s) have been modified? deleted? or written? in mtd3. Logs?
[HTC Wildfire S] no.human.being:
He said he permarooted the phone via recovery after xtc-clipping. I suspect permarooting the phone causes modifications to system files. And no, I'm not sure. The Radio checks the secu_flag and the Radio is an RTOS. RTOSes are much more primitive than a "full blown" operating system such as Linux is so I'm very sure that the Radio can't really "understand" the YAFFS2 file system that's on "mtd3". However, YAFFS2 seems to have a facility to "lock" information in a specific place so that it doesn't get relocated over time due to wear levelling constraints. There's the very remote possibility that they decided to hide the secu_flag in such a "reserved" area inside the "/system" partition (which is on the "mtd3" device) and hardcode the location inside the Radio so that it can find the flag without "understanding" the YAFFS2 structure, but I find this really remote. Furthermore, Revolutionary said that they decided to patch the HBOOT since they found no way whatsoever to access the secu_flag. If the flag was to reside on an mtd device, don't you think they would have found it?

So no I'm not certain, but there are indications that it is not on the "mtd3" device so I'd suggest checking for "unpartitioned" memory regions first. I'm very certain that there are such regions. The controller is shipped from Quallcomm containing some code which "initializes" it and which executes before any "user" code (so code that was flashed by HTC) is run. I couldn't find any Quallcomm code on any of the partitions, so what we're currently seeing isn't all that's there.
[HTC Wildfire S] BeciMester:
OK, sorry lads for posting so late, had to pick out the relevant bits from the ~60 tabs I have open. :eek:

NAND stuff:

Partition info and how to access 'inaccessible' partitions. It's for the Desire, needs to be adapted to the WFS by re-calculating that partition table towards the middle. I'm pretty sure it needs S-OFF though. EDIT: the necessary command 'fastboot oem listpartition' doesn't work on my stock hboot, I dunno if it's because of S-ON or it needs an engineering hboot. :(

General information about flash devices, very important and interesting! Here is how to compile MTDutils from source code (just in case...). This tool should be able to read/erase/write NAND devices directly. We could use it to dump the hboot image.

Some interesting bits about the ARM Linux boot process here and here. I dunno, might be relevant.

Hope this helps a bit.
[HTC Wildfire S] hahahafr:
Is there a way to retrieve the dumped files without permarouting the phone?

Someone knows how to see the unseen?

Edit: @BeciMester Circling in rounds aren't we?