yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] dudeman1996:
Well I've found this: http://unlimited.io/juopunutbear-public-beta-0-1/instructions/htc-sensation/

Looking at it, I've found those same 2 holes on our Wildfire S, at the top right-hand corner of the battery. Could we use the same method to achieve S-OFF?
[HTC Wildfire S] *se-nsei.:
Interesting.
[HTC Wildfire S] no.human.being:
Some pages back theq86 told that it will only work on eMMC based devices since they have a special "download mode" in their firmware that NAND based devices lack.
[HTC Wildfire S] ONeill123:
But possible?!
[HTC Wildfire S] einstein.frat:
Just buy an S-on Sensation. nuf said. or wait for the end of the world on Dec 2012 according to the Mayans.
[HTC Wildfire S] sythe179:
please dear sir, could you look into it a bit more?.

would make a fair number of us a great deal brighter knowing a kernel dev is helping.
[HTC Wildfire S] no.human.being:
I've just taken a look at the sources of the mtd driver in the kernel, but haven't actually found a lot that would be of interest to us. The actual communication with the NAND seems not to take place here. It's probably handled by an even lower level, perhaps some I/O layer that sits beneath, don't know. The kernel is simply too huge, this will turn into a search for a needle in the haystack.
[HTC Wildfire S] einstein.frat:
Your success on this s-off will be an hboot editor, but will have a broken phone, like a 10-15 sec. delay before phone powers up I mean lcd turns on, but at least your s-offed. xtc clip ftw btw :D .nuff said.
[HTC Wildfire S] *se-nsei.:
If alquez says it's a hard task. It must be too difficult for many of us to comprehend. :p
[HTC Wildfire S] :
Well, I got Linus Torvald's number, if that helps. LOL. :D
[HTC Wildfire S] :
Well, if there is no other way, and we have to pin it down, then we either have to look through the kernel or the radio. If we do the radio, and find secu_flag then we have a "pure" S-OFF, if we do the kernel, I suspect it will take longer and we will have a "patchwork" S-OFF. At least we will have S-OFF. But we also need to think timewise. Don't want to finish this when this phone is not sold anymore and when we are the only people left. By the way, Samsung Android phones have a "Download Mode". I've used it many times. Also, once you are in download mode, you use a GUI program called ODIN, like a RUU, it assists you in "downloading" the file to the phone and flashing it.
[HTC Wildfire S] heavy_metal_man:
In order to do either we need to be able to write to the nand so both will need us to **** with the kernal in the hope it works. Nbh what would we be looking for in general? We might have some luck if get a small army of us to go hunting through it.

sent from my android powered beast!
[HTC Wildfire S] alc027:
The Nexus One's QSD8250 is much more powerful than MSM7227. Both have Adreno 200 graphics and are Snapdragon S1s but QSD has a Scorpion (Cortex A8) core with 1GHz native clock, vs MSM7227s ARM11 w 600MHz native clock. I wouldn't hold my breath for official CM9 on WFS sadly.

https://developer.qualcomm.com/sites/default/files/snapdragon-specs.pdf
[HTC Wildfire S] :
Well there could be a small army, made from only the best, and we could all have private training and mission briefing. I'll manage the weapons (2 AK-47S and 2 PP90M1, Air Support, Care Packages, UAV, and the other stuff)
[HTC Wildfire S] no.human.being:
Well, in fact the QSD8250 is built around a newer IP-core. However, "much more powerful" is quite a bit of an exaggeration. QSD8250 was released Q4 2008, is ARMv7 on 65 nm manufacturing process and "Adreno 200" GPU.

The MSM7227 has an older IP-core, namely the ARM1136EJS, which is an ARMv6, so the QSD8250 might have a bit more compute. Indeed, I didn't find lots of details about this SoC. Actually I didn't even find an official release date. However, you can find specification of close relatives, like the MSM7227A and MSM7230, which were released 36 / 9 months later than the QSD8250 respectively. Both feature a 45 nm (more recent) manufacturing process and either an "Adreno 200 enhanced" or "Adreno 205" GPU.

The QSD series is effectively retired and superseded by the MSM series. So yes, the design of the QSD8250's IP core is newer than that of the MSM7227, but the latter seems to be the more recent System-on-Chip. Also, the Nexus One was released on the 5th of January 2010 and shipped with Android 2.1 (Eclair), while the Wildfire S was released on the 15th of May 2011 and shipped with Android 2.3.3 (Gingerbread).

Not so sure what that means for CM9 support, since I don't know whether the MSM7227's older IP-core might be a hindrance "instruction-set wise". It certainly won't be a hindrance "performance wise" or "I/O- and peripheral-wise", so as long as CM9 will run a chip with ARMv6 instruction set I don't see any reason for not supporting the MSM7227.

Yes, Odin is a leaked Samsung-internal utility. There's a clean-room implementation of it that is called Heimdall and is licensed under MIT license.
[HTC Wildfire S] csoulr666:
@nhb A thought just occurred to me.......if you're trying to boot a linux kernel.......why not try it via a different linux based OS on the phone......Tizen for example?????
[HTC Wildfire S] heavy_metal_man:
I've also had an idea, have we tried to do this to an s-off device? I know it sounds strange but it would hopefully yeild some useful information. Like if it works with no arguments then we would know that the s-on is still ****ing with us and that the kernals works. Just an idea :D

sent from my android powered beast!
[HTC Wildfire S] theq86:
it doesn't matter what sits "on top" of the kernel. we need do grab deeper. probably that deep, that not even a kernel would be required. we just use the kernel to bootstrap in a "familiar environment"

It's not proven the exploit works as we hope to. and we know nothing of the side effects that may come up using this exploit on an s-off phone.
[HTC Wildfire S] no.human.being:
As far as I know the Radio is protected even on an S-OFF phone. It's just that signatures are not checked by HBOOT so you can use HBOOT to flash whatever Radio you want, but I don't think you'll be able to write from within Android. At least not without the modifications to the kernel that would also enable you to write to the Radio partition on an S-ON phone.
[HTC Wildfire S] MrTaco505:
Well I did have a longer reboot
[HTC Wildfire S] Antagonist42:
CM seems to me to be more to do with the 'most widely used' phones and not down to chip or Android version as vendors can add/change boot up to Android and each vendor can be different even down to mtd partition order/naming.

I've been trying to figure out what exactly the 0:MIBIB means (as I haven't found anything relevant towards what it stands for or what it does do via googling it, the closest thing I have come across is two separate acronyms, they being:

MI - Machine Instruction .... Which will be slightly obvious although would separate it from other machine code instructions for operation.

BIB - Backwards Indicator Bits ....

from this...

To me thinking about it, what if the option to edit this FIB/BIB would now be locked for greater security whereas before those Bits may have been ignored or unset?. Looking at the diagram on the linked page I can see to a certain degree the block layout of the systems partitions used on Android, seeing as we may have to delve deeper to attain S-OFF may as well find out all we can from whatever we can even if it seems odd :D

---------- Post added 3rd May 2012 at 12:01 AM ---------- Previous post was 2nd May 2012 at 11:56 PM ----------

Could the longer reboot times be down to verifying the installed hboot because maybe a pointer/signature/whatever wasn't set before it was installed whereas the original and official updates may be verified before installing therefore no check so shorter boot time?

Added this as well to the found docs
[HTC Wildfire S] Antagonist42:
S-OFF - can or can't?

I don't think we will directly alter the state of S-OFF whilst the system is running, I believe it is Software Implemented either during OS Factory Install or from Vendor Update - my reason being:

Now if as with this phone we had all the access open, then the S-ON came with the update as my phone was updated before I had a chance to run anything (hence my uncertainty as to gaining S-OFF on the ACER E320/C6), so my line of thinking is still that we can gain S-OFF with an update, I think trying to make the mtd drivers may be a long and arduous route to take if we don't know what we're looking for with trying to access maybe 2. 3. or 4 (Android/yaffs/ext3-4/L4 and possiblyOKL-L4) different operating file systems (that doesn't mean we shouldn't still try if needs be ;)).
[HTC Wildfire S] theq86:
HTC OTA updates are normal flashable edify update-zip files (the ones installable by the recovery)

one difference is, that they can only be installed using a stock recovery.

second is, the zip contains another zip, called framework.zip.

That framework.zip is a renamed PG76IMG.zip - and guess - signed.

it is handed to hboot which proceeds as if it was uploaded by a ruu or manually loaded at hboot load when PG76IMG.zip is available.

the update thing is not the right way, since we really would need a tool which could sign our custom update with htc keys.
[HTC Wildfire S] :
Wasn't Antagonist 42 onto something about some NAND keys? Or the HTC cryptographic keys?
[HTC Wildfire S] :
Who got invited to the Windows 8 App Dev camp? I know I did! Just need to do some partitioning on my hard drive, finish installing Windows 8 and then I'm ready to go!
[HTC Wildfire S] :
Also invited. Ps guys, I have an idea. Can someone decompile the stock recovery. I have an idea but don't have hex arrays or anything of the such
[HTC Wildfire S] theq86:
A recovery image is basically a concatenated file consisting of

* an android kernel image

* an initrd image

* additional metadata

the initrd is a gzipped filesystem containing a very basic gnu/linux system in where the recovery executable is.

so that means a recovery works on an android context.

There is nothing the recovery can do to enforce flashing of a file or disabling signature check. I don't believe a stock recovery will help us.
[HTC Wildfire S] csoulr666:
why don't you just help him out.......let him implement his plan....
[HTC Wildfire S] :
Yeah., we're kind of stuck, let's do what we can.
[HTC Wildfire S] Antagonist42:
Well OTA and EUU are able to change a rootable phone to none rootable ie DoomLords root, which did work previously, so in that case I can only assume that zergrush etc should still work after an update by how I understand how you say what is in an update unless S-ON can be turned off to allow an update to take place as I flashed in an edited EUU from original release whilst prior to that it wouldn't accept anything I tried to flash after the OTA update :confused:

Rooted Xakep E320/C6 EUU Hacked Update
[HTC Wildfire S] MrTaco505:
Where is everybody?
[HTC Wildfire S] sythe179:
coming up with ideas?

had an idea but read the last 3 pages, found what i wanted to know.
[HTC Wildfire S] inconn:
Guys, I give up.

I've paid 20$ to have my wf S hardware broken and sim ulocked. It's been fun following this thread, but I need to move on.

Good luck everyone, and godspeed ;)
[HTC Wildfire S] MrTaco505:
If we need kernel developers, we can't just sit here and do nothing. It's been almost a week since there was a REAL development post. :(
[HTC Wildfire S] akshayf:
Finally after reading this post... I sold my wildlife s and sweared to myself never to touch an htc again...

Goodluck to all
[HTC Wildfire S] heavy_metal_man:
indeed so. could we possibly try a linux forum and see if they could share some light on the matter. their is bound to be somebody who has attempted to do something like this before to a linux kernel. we just might have some luck.:D
[HTC Wildfire S] paul.robo:
Wildfire exploit.

Hi all, Im a programmer from swindon. i was before working on a exploit to s-off the Sensation XL. i got so close to the point where i got the Sensation XL s-off. but after reboot it was lost. the devs in the sensation xl forum didnt want my help. But i had a PM from a wildfire s user who asked me to start a exploit for your device. I accepted. I am now going to get to work on a NEW exploit for the Wildfire S. This wont take days , It is hard i will have long nights ahead of me . i can get the exploit but first i need to look at the wildfire s. i need to know what i can chuck at it i need to know EXACTLY how your devices hboot works. Until then. Im offering ONLY to your device. FREE S-OFF thats right FREE. i live in SWINDON,England. i offer to you guys free unlock and s-off and super cid . the only catch is u have to drive or come to me. i will in NO way travel to you. if u wish to have your device s-off faster than every1 else come to me :) IF you want this done then JUST PM me and ill get back to you. Many thanks. just 1 more thing. UNLIKE all other people i can PROMISE you i will give your device s-off

Kind Regards

Paul.Robo
[HTC Wildfire S] jimhed:
Where is the package?

"Download the package I've attached to this post and extract the contents into the root of your phone's SD card."

Update - now found on the original post here: http://xdaforums.com/showpost.php?p=23269580&postcount=1541
[HTC Wildfire S] theq86:
@paul.robo:

The best way to learn about the WFS internals is to read through this thread. There will be many things unfamiliar to you if you come over from Sensation XL.

The Wildfire S A510e (codename Marvel) which we try to unlock has a NAND chip employing the MTD driver to get access to. Our progress is that we made it untill mapping the radio partition, extracting and finding the hboot and eventually wrote an exploit making the hboot think it's S-OFF.

We are stuck now, because we are not able to erase the radio / hboot pages because they are marked locked. The normal ioctl functions seem not to be able to change the oob data successfully, thus we lack wite access.

details can all be found in this thread.
[HTC Wildfire S] paul.robo:
ill read thru it now. i think your all familiar to the xtc clip, well im trying to incorporate how it works into a windows exe application. it will do EVERYTHING the xtc clip does. create goldcard for marvel and putting it into hboot mode for you then it will s-off and sim unlock your device. im trying now to create that. then i will start building a exploit and put it all together, i will be trying to get hold of a second hand wildfire s 2morrow. obviously once i have this fully working i willl release to xda community. then hopefully i can recoup the money i spend on this device back in donations :) i cannot afford to go out and buy a wildfire s as im supposed to be saving every penny as me and my wife are having baby number 2. but i wil get this done okay :)
[HTC Wildfire S] theq86:
Sorry, I may disappoint you, but we are already behind the stage of reverse engineer xtc clip. The reason is because we know how it works.

See, the marvelc (CDMA Wildfire S) can be s-offed with the xtc clip files only (goldcard+diagnostic tool)

We are trying to tame the GSM Wildfire S. This one is more protected, since it has a SIM slot. We already have all xtc clip files for our device, but these are not enough.

You know the xtc-clip has a SIM connector cable. and the clip itself does somehow mimic a special htc sim containing cryptographic keys and algorithms. Only if this sim is inserted, the goldcard will work on our Wildfire S.

Beside the SIM emulator, there is nothing special about the xtc clip. The software downloads diag tool and goldcard software, the clip makes the goldcard and the sim cable mimics the engineering sim. Without it, the software is useless.

This has been tested already one year ago and several times.
[HTC Wildfire S] :
Congratulations! I know the feeling! I'm about to have another sibling to! Already got a sister. Do you currently own a clip?

I live in the UK too, in London.

It's good to see that you're so passionate. We were all like you in the beginning, but then after a year and a half, we got worn down, this thread died, people got rid of their phones, or got it clipped, and some people like me, who still had hope in their hearts and believed in the XDA spirit, stayed and waited. Man, I can't take this wait anymore! I think I'm going to get a feud if I wait longer!

Help us Paul! I beg you!
[HTC Wildfire S] paul.robo:
like i said. im working on software. as the person said before. yes the xtc clip works. and he thinks its useless BUT its not, im building software that uses the same principle as the clip. AND uses the sim emulation. the software is EXACTLY the same as the clip, just on a PC. and if your asking yourself if this can actually be done. the answer is YES it can. im a programmer in my eye's EVERYTHING can be done. some people over look things or just don't look in the right place.
[HTC Wildfire S] *se-nsei.:
Good to hear :) ! Well all the information you need to help out is throughout this thread, especially no.human.being's posts.
[HTC Wildfire S] paul.robo:
i have got just about all the info i need. i will start building the program as soon as i can. but please remember this wont take days. this is very hard task and will probably take at least a month to complete and then i have to test it out atleast 20 times just to be sure its good for release. but i have made my promise and i will deliver.
[HTC Wildfire S] heavy_metal_man:
those are strong words good sir. i just hope your up to the challange;), but even if you do come up with a xtc usb type solution we should not forget the many years of hard effort put in by others to try to free this device. hopefully, as a team we can work together, pool our collective knowledge and unlock this basturd!:cool: as a programmer what experience do you have may i ask? do you have any kernel experience?? as it may be faster to work with our current solution. also if you do come up with a xtc usb type solution would it then be portable to all xtc clip-able phones? anyway welcome to our nightmare :p always good to have fresh blood:D
[HTC Wildfire S] *se-nsei.:
We've waited ages for a solution. Just look at ho many pages this thread has haha. I'm sure wfs community is already used to waiting things out. Good luck ;)
[HTC Wildfire S] paul.robo:
First of all. Thanks for all the comments and questions. please let me stress. my method is NOT a usb solution. it uses the SIM SLOT the same as the clip. this Sim emulation is being made by my friend. he is going to modify the Sim slot flex cable to make it plug into your Sim slot then straight into the PC instead of going into the clip. As a programmer i have had much work with android devices. Ive made a flash player for Sony Ericsson x8 devices. i have worked with kernel's i do like working with them as they are very challenging. if you think your kernel is the answer go ahead and email me the kernel at paulroberts759@gmail.com i will download the kernel and take a look at it.
[HTC Wildfire S] MrTaco505:
But is it possible for a wired usb version instead of the sim slot :confused:
[HTC Wildfire S] paul.robo:
nope wouldn't work. this software only works with the Sim emulation. BUT the leads WILL be just $1 i cant do free otherwise i will be losing money as for every lead made i pay 50p they take just 30p to be made so i think that's a VERY good price. and at the moment this IS the ONLY way that's going to work. But if people are more willing to wait for other dev's to finish then that's okay. ill carry on doing what im doing anyways because there's many devices without proper s-off so SOME1 will need my software :)
[HTC Wildfire S] heavy_metal_man:
So would your solution work for all the devices the xtc clip does without issue? And we need the kernel edited so that ignores the don't write to bad blocks command. Once we have that I believe we are done :D
[HTC Wildfire S] paul.robo:
No my software will be an EXACT replica of the xtc clip, i will NOT be editing the software i will be mearly transforming the xtc clip into a portible PC application. everything the xtc clip does. My software does. I'm the one making the software i have no help. only with the flex cable. I have already said if some1 sends me the kernel i will have a look :)
[HTC Wildfire S] csoulr666:
If you are asking of the stock kernel of the wildfire s then you can download it via HTCDev.com
[HTC Wildfire S] no.human.being:
A SIM card is a microcontroller with an 8-pin interface and single-ended signalling.

1: Vcc

2: RST

3: CLK

4: N/C

5: GND

6: Vpp

7: IO

8: N/C

USB has 4 pins and differential signalling.

1: Vcc

2: D+

3: D-

4: GND

Also I don't think that signal voltages and clocks will match. So at the very least you need a small controller that adjusts the interfaces. A simple (passive) cable won't do the trick.

Our exploit works differently. We use the Fastboot protocol for booting a custom operating system image (kernel + initrd) on the phone. Currently we just use a CWM recovery image for this, since the kernel allows us to bypass some security that the kernel of say a CM image won't bypass. Via Fastboot we also pass modified page tables to the kernel for mapping (part of) the protected Radio area of the phone. We then dump this protected area and run an automated analysis on it which finds the subroutine that checks device security on the aARM (application processor) side (we didn't manage to find the secu_flag itself - it might be hidden in some dedicated off-chip memory that's not part of the "normal" address space). Then we substitute the first 3 machine instructions of that subroutine with a machine code sequence that will always return zero (which means "Security OFF") when called using C calling convention. Then we erase the NAND and write our patched firmware back. We are confident that the phone will be S-OFF afterwards.

The only problem that's still left is that the erasure will not get executed by the kernel we run upon, because the out-of-band section of the pages of the protected area are in a format that our kernel does not understand and then does not perform the erasure.

What we're unsure about is whether aARM will directly talk to NAND, so an erasure request sent by our kernel will ultimately reach the NAND chip and take effect, or if the NAND memory is connected to mARM and we need to talk to the Radio firmware for accessing NAND. In the former case, a kernel modification to ignore the corruption of the out-of-band area of the NAND pages holding the Radio firmware will ultimately bring us victory. In the latter case, even when we set off valid erase requests, the Radio might intervene. But at this point we just don't know what will actually be the case.
[HTC Wildfire S] paul.robo:
i do not KNOW enough of your device nor do i have 1. i am currently looking into my bank to see if i got enough cash to spare to get 1. however yes i can agree with you aARM will directly talk to NAND. i will download the kernel now and get back to you

Edit: I'm now download marvel-s-gb-mr-2.6.35-696f19b.tar.gz i will give more light on this issue once i have looked at the kernel
[HTC Wildfire S] no.human.being:
Let's hope that you find the code that talks to the NAND. Obviously the mtd driver might be a good starting point, however, I get lost quite easily when it comes to kernel sources. Just too extensive code base. Good luck! :D
[HTC Wildfire S] paul.robo:
yes i have now un packed it and ill have a look at the mtd driver now
[HTC Wildfire S] gordo79:
Looks like game on again. Good luck guys
[HTC Wildfire S] paul.robo:
as far as i can see there is 2 that talk to the nand. ezx-pcap.c and asic3.c if I'm right then your VERY VERY close to getting s-off Now im not 100% on this but as far as i can see they DO talk to the nand. be aware i do NOT deal with wildfire s. This is the 1st time ive looked at this device. but it puzzles me on why this device hasnt got s-off sooner :S is there not many devs working with this device then ?