yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] timboeve:
Hey guys,

Any news? I would love to have a custom rom on my wildfire s this christmas;-)

Thanks fo the hard work:)

EDIT:

I study information sciences, I'm a noob so I don't know anything about how to crack the HBOOT to S-Off, I tested some things though on this forum, but obviously nothing was succesfull. If you need help though, I'm willing to learn. And I wil test all the new things everyone posts out here (unless I know it will brick my devicexD)

---------- Post added at 12:01 PM ---------- Previous post was at 11:48 AM ----------

If you still need a tester/ someone to work with, then I can join you! I don't have the cdma version though, just the gsm.

Details of my Wildfire S version:

Marvel PVT SHIP S-ON RL

HBOOT-1.08.0000
[HTC Wildfire S] ONeill123:
Hmm, anyone test to flash cmda version. And the ruu says false phone or something else.
[HTC Wildfire S] no.human.being:
Stock recovery will prevent CDMA version from being flashed. If you'd somehow get the CDMA version flashed, it'd brick the phone.
[HTC Wildfire S] N8falke:
What about this tool:

http://xdaforums.com/showthread.php?t=1343114

Anyone tested with european Wildfire S?

thx in advance.. and merry xmas to all of u
[HTC Wildfire S] ctt812:
I've tried it, not work for Wildfire S.
[HTC Wildfire S] ONeill123:
Gfree require emmc memory. Htc marvel alias wildfire s has nand memory, standart.

So all solutions using gfree are impossible
[HTC Wildfire S] sythe179:
Ok....new idea.

Somebody set up a irc server, and send a link to everybody that is working on this.
[HTC Wildfire S] d33ps1x:
Why not just open a channel on an existing IRC network but I kind of think this forum is a fine place to discuss and share work on this project. Why rebuild the wheel?
[HTC Wildfire S] *se-nsei.:
First post updated.
[HTC Wildfire S] breaky9973:
Just to clear up some things: eMMC = NAND memory with MMC controller in one package.

So basically it is a difference in controller what we are talking about.

I wonder which other HTC (GSM) phones just use NAND memory for their ROM and how did they get s-off.
[HTC Wildfire S] Lt.Win:
Should I go on to the Salsa forum to ask if their devs are ready to work with us? The Salsa has the same problem, S-OFF via XTC Clip only. Just tell me which devs are going to work with them if they agree.
[HTC Wildfire S] ONeill123:
Its a good idea, hope that we find a way to set s-off very fast ;)
[HTC Wildfire S] effendi9:
I'd be willing to donate for this cause if a group of devs come together to help do this.
[HTC Wildfire S] ONeill123:
Maybe you can ask someone of this devs:

http://xdaforums.com/showthread.php?t=1375040

Maybe with a xtc clip for an snapshoot before and after set s-off.
[HTC Wildfire S] no.human.being:
Got a bit further, but running into problems now. Security flag seems to be located 2560 bytes into some of the block devices and it seems to be a single-byte value with either all of its bits reset or only its least significant bit set. Not sure though which state is S-OFF and which is S-ON, but probably the least significant bit set is S-ON so we'd probably have to clear it.

So I opened a root shell on my WFS and wanted to read that exact location from the "/dev/block/mtdblock*" devices, so I did:

# dd bs=1 skip=2560 count=1 if=/dev/block/mtdblock6 of=/data/local/read.bin
/dev/block/mtdblock6: read error: I/O error
0+0 records in
0+0 records out
0 bytes transferred in 0.002 secs (0 bytes/sec)
#

It's the same with all the other "mtdblock*" devices. What am I doing wrong here? Even "cat /dev/block/mtdblock6" won't work, complaining about "mtdblock6: invalid length". The same with all the other "mtdblock*" devices here as well.

Are these devices somehow "broken" in Android? If they are, how come they can be mounted as file system?
[HTC Wildfire S] ONeill123:
So, you think the secruity flag is in 2560 memory adress?

Maybe you can try to go through qll possible values, but this is a work with takes long time.

Maybe you must mount this /dev as rw. But idk how :S
[HTC Wildfire S] :
I used the config from HTC's developer kernel. the one that lets carriers decide how to develop there roms radios ect
[HTC Wildfire S] theq86:
Well, you could attach it. Maybe the mtd driver of the dev kernel is more powerful.

Or give it to no.human-being. I only have a low mobile connection atm :D
[HTC Wildfire S] :
http://goo.im/devs/simonsimons34/marvelc/boot.img

Here you go everyone, i cant make any recovery utilizing it atm so everyone else give it a go
[HTC Wildfire S] theq86:
we don't need recovery. bootimage is enough. kernel loads and boots up. will test the exploit in a few mins
[HTC Wildfire S] :
Thanks. Let us know
[HTC Wildfire S] theq86:
okay, same errors as with normal kernels. the dev kernel has no special mtd drivers.
[HTC Wildfire S] :
Worth a shot though right. Humm, just an idea. We are writing to radio right? well, could we use QPST or QDXM to read/write something there? the Open Sesame door works on this device
[HTC Wildfire S] theq86:
I'm not familiar with those terms. are those qualcomm specific interfaces?
[HTC Wildfire S] no.human.being:
QDXM I didn't find.
[HTC Wildfire S] :
Yes they are, both are windows programs. Try looking for the basics here http://xdaforums.com/showthread.php?t=1404270
[HTC Wildfire S] BeciMester:
Lookie here. ;) In the thread linked above the download links are dead.
[HTC Wildfire S] Antagonist42:
QPST QXDM

Here's QPST v2.7 build 366 - it may be a little out of date so I'm looking for another if I can find one lol

Here's QXDM v3.11.36 - same goes for this but no others with a more recent date :(
[HTC Wildfire S] :
Don't worry bout newness. You'll be surprised.

Ps qxdm is warez
[HTC Wildfire S] :
Don't take too many pictures once you get one. There's a bug that causes all your pics to disappear. It's happened on my dad's G2.

---------- Post added at 09:12 PM ---------- Previous post was at 09:03 PM ----------

Warez is bad round here. If you want to post it, I'd suggest to arrange via PM for theq86 to download it from a private source (like FTP). Or you could contact shenye and say it's for development, and defines the future, or you could make another account and post it from there, or you could post it from your account and take the risk.

Also, sorry if this doesn't help, but I thought of something. We all know, that after providing the unlock token bin file to the phone it shows a screen saying stuff about warranty and all that. That basically another OS booted by HBOOT, like a HBOOT GUI or something. Can't this be used to help. For example you could upgrade the system. Like NHB said, a HTCU thing is written to HBOOT, so can't you write other stuff to HBOOT from this, if you do some tweaks. You could also try changing the unlock token bin file, like sneaking in extra stuff, or supplying extra parameters that HBOOT can't ignore. You could also try tweaking this "HBOOT GUI" so that when it reads the extra parameters it performs some cool stuff (the exploit could be sneaked/embedded through/in the bin file). Hope you like my ideas!!
[HTC Wildfire S] theq86:
the unlock token is no os that can be changed. it is a cryptographic signature/hash/key etc.

the GUI is probably part of hboot 1.08.0099/1.09.0099 and we can not change it or exploit it. remember, all it does is to change the misc partition.

and please do not send me the qxdm things or so, I have really no clue about that :-D
[HTC Wildfire S] :
If you're right about the HBOOT GUI thing, then what about the fact it is heavily like Android, just without a status bar. :D

Maybe it "runs off" Android. For example, it accesses the Android partition, takes asome stuff, and does it's thing, only doing some low level stuff. HBOOT could contain another Android process, resource, driver, application (software in general).
[HTC Wildfire S] Antagonist42:
warez!!!

Well in that case you'd better tell Qualcomm then as they're selling the latest program, these are from 2007 and unless you know what to set up in it you'll get as much out of it as I have .... my phone isn't there unless it's in fastboot, then you can't do anything as it's in a download state lol
[HTC Wildfire S] theq86:
Bootstraping the whole android kernel just to display a one page gui with 3 elements? Come on, that's rubbish. Also the gui pops up quicker than a kernel loads up.

Presenting a simple gui is not that complicated. See the hboot gui. Only difference: it is not sense styled.
[HTC Wildfire S] :
But it has a green glass button! Lol. :D
[HTC Wildfire S] theq86:
you could draw whatever UI you want. It's just 2d drawing on the framebuffer :D
[HTC Wildfire S] :
I have no idea what a framebuffer is, but I understood the rest. True. Any news, NHB?

Can sum1 sum up what we're trying to do and all that. I need the information so I can get us some fresh blood.
[HTC Wildfire S] *se-nsei.:
I have a bad feeling that development has come to a halt. :/
[HTC Wildfire S] no.human.being:
We're all waiting for some genius to appear, who is able to modify a kernel in such a way that the mtd driver does not check the out-of-band area of blocks before passing "erase" commands to them and can subsequently build this kernel for our device. As long as you know what you're doing, I do not expect it to be exactly a "big thing". However, kernel devs seem to be at a premium. :D
[HTC Wildfire S] :
Now that you explained that, Im going to look at the C coding for the sense kernel... Maybe i can erase all precautions
[HTC Wildfire S] no.human.being:
Sense kernel? We're currently running off a CWM image. I expect it to be based on the Alquez/Drowningchild kernel. It's good because it's self-contained and seems quite "unrestricted". It lets us map the Radio area via the mtd driver. This is a requirement for our exploit to function and I'm not sure whether an arbitrary kernel will let us do this.
[HTC Wildfire S] :
Well the recovery alquez has uses the sense kernel
[HTC Wildfire S] einstein.frat:
showp-1984 is a good kernel dev, I was trying sleep2wake to wildfire s kernel, if I have time I'll redo it.
[HTC Wildfire S] :
Oh, it's you.
[HTC Wildfire S] Antagonist42:
I need to know...

Right (after a few days file trashing and pc repair after blue screening with all i've been doing :D) I need to know which RUU/EUU/ROM/UPDATE you guys are using?

In my digging I've come across something rather odd - obvious - and makes too much sense!:( It takes stripping files down and running/unpacking then stripping out and reforming but I think I've found the 32 keys for the NAND (or at least for my ACER C6) so if I can check with a ROM/UPDATE you guys are using I'll strip it down and have a peek ;)

If they are the keys then I think I know what they generate them with (roughly) and it's so simple it's TOOOOOO obvious!

It may also mean that the phones are not exactly 'secured' but put in a secure state to remove human error or you have to 'know what you're doing' to alter the system

----XX EDIT XX----

could still do with getting hold of your rom in use (must include all 7 mtd's or all .hex files) keys I found may be something else but want to start checking them as I found 3 more although they could be updated with subsequent updates as it may be tied to specific files/times/dates
[HTC Wildfire S] no.human.being:
Why would you need all 7 mtds? Some of them may contain sensitive data. You certainly won't need what's on the "userdata" and "cache" partitions.

And for the "locked/unlocked state in misc instead of radio partition". The reason for this is probably quite simple. The Radio firmware is not developed by or for HTC. It's been developed by University Karlsruhe, Germany, with customizations by NICTA (Australia) and Qualcomm to adapt it to their chipsets, licensed from NICTA by Google to ship with Android, with Android in turn licensed from Google by HTC. It's a completely foreign firmware component that HTC just "deploys" as part of Google's Android distribution. I expect HTC's engineers to be unable (due to lack of knowledge about internals or simply due to licensing restrictions) to customize this firmware component, so they probably had to put it elsewhere.
[HTC Wildfire S] :
I understood most of what you said, but if finding the keys were too simple, then it's probably already been found. These guys said themselves that they've tried every simple and obvious approach. But, we all know these guys take it TOO far (technical) so they might have missed the obvious. So you might be onto something. You know what they say. The answer is right under your nose.
[HTC Wildfire S] :
Can someone give me an update of what's going on and stuff. I need to go and try to get some new soldiers on the job (armed with a PP90M1 and an AK-57/FMG Akimbo, all capable of getting a MOAB; Call of Duty Modern Warfare 3 talk).

My 500th post. Awesome. Never thought I'd make it to 500. LOL.
[HTC Wildfire S] Caspertje19:
Deleted

never mind
[HTC Wildfire S] MrTaco505:
So basically we need a kernel dev
[HTC Wildfire S] csoulr666:
So basically you are thinking of finding HTC's Encryption keys????

Would'nt that be copyright infringment??
[HTC Wildfire S] Antagonist42:
Depends how you look at it really....

If these phones are ours and if the android system running on it falls under the GNU/GLP etc, etc, shouldn't you be able to alter aspects of the system as you do with your system say on your pc at home?

Not really interested in encryption but having access to NAND and be able to flash whatever we wanted without initially altering the phone, this is essentially in Qualcomm's domain and not HTC, as we will never know if Qualcomm or HTC set the Q-Fuses but this then restricts your usage of your phone.

Do we want to alter the modem/radio/amss part of the sytem? No

But you can access your pc's BIOS and alter it to suit so why is there no access here as that's even lower-level than what we wish to alter, there is nothing stopping you wiping your system at home and installing afresh without there being 'a key' or as we have for NAND 'Q-FUSES', these are permanent and essentially act as a serial number which 'WE' are not given :mad:

So if you manage to work out what is used for the Q-FUSE key and subsequently manage to access your NAND are you breaking copyright or adhering to it by not 'breaking in' but 'using the key' as the last thing we wish to do is break the phone ;)

**this is why I'd never have an iphone or windows phone, you 'HAVE' to break them to make them work the way they should lol**
[HTC Wildfire S] :
I honestly don't care. They could be so useful.
[HTC Wildfire S] :
Good work people! 2222nd post!
[HTC Wildfire S] no.human.being:
I don't understand what "keys" you have found. They probably aren't the keys they use for signing their firmware images. If I understand correctly, you can use them to "authenticate" with the Radio for gaining NAND access, right?

Now the question I have is, since the aARM already has exclusive control over the NAND, what will the Radio do after you pass it those keys? Will it take NAND control from you, remove the "locked" flag from its pages, then give you NAND control back?

If so, what's the benefit of versus passing "unlock" command to the NAND directly from the aARM? Ok, we'll have to modify the kernel for this, but we already have a rough idea where this modification takes place (mtd driver). Compare this to "passing keys". The kernel probably can't do this yet (why should it, it never needs to when operating regularly, it seems to be just for "hacks" so it's probably completely unsupported :D ), so we'd have to implement the entire mechanism. What protocol do we talk with the Radio? Lots of question you see.

I'm not saying it's not a way that could work and I also don't claim that this is the inferior solution, I would just like to understand exactly what you plan doing and what you know about how it can be realized. I really think it's great that we might have found another possibility of bypassing security. Having more options is always good. :D
[HTC Wildfire S] csoulr666:
Have you ever looked what apple does in such matters ?????

---------- Post added at 06:58 PM ---------- Previous post was at 06:57 PM ----------

This was meant for bad-wolf
[HTC Wildfire S] sythe179:
off topic?...

thought we where trying not to post those..

maybe PM him?..
[HTC Wildfire S] corrsea:
Ive followed this thread for a few months since my friend and me to unlock his wildfire s and I discovered it was not that straightforward:(

I just wondered if anything in the construction off the clk bootloader for the hd2 would be helpful in building the kernel you need?

http://xdaforums.com/showthread.php?p=14426749

Apologies in advance of this its not useful.
[HTC Wildfire S] Antagonist42:
I don't think aARM has 'Total' control as signature keys and security for NAND access is loaded into IMEM from PBL setup by mARM, there is not seemingly direct access to this as mARM is protecting from Jtag, aARM or outside or non-signed access, can only be done 'indirectly' as I understand it as the following:

aARM requests access to NAND, NAND verifies aARM is authentic, authenticity resides in mARM IMEM and mARM does the same passing a request externally as mARM is protected itself from exposing security in IMEM.... This is where I think partitions or whole sections of NAND are either flashable AND protected, flashing to NAND seems to be done as eg. /root/system/ etc flashed then the NAND is spin locked then the AMSS is flashed, power up/down can be instigated normally from aARM but can also be done from mARM as with FOTA update, the write enable is either 'hard wired' so software had to instruct the PM7540 or NAND MMU to enable write (as I cannot see write being left enabled anymore). This is why I think mapping and writing to areas outsite the accessable sections of the spinlocked area could be lost or blocked if not done as an update and writing may be returned as 'successful' but ignored as NAND still spinlocked.

If this is way off the mark I appologise in advance but you can only go off what is out there and this is what seems to me the Qualcomm docs point to.

ROOTED ACER E320/C6 ;-)
[HTC Wildfire S] Antagonist42:
Another reason being now with Near Field Connectivity they will have to make phones even more secure so bank details etc cannot be accessed through hacked phone, they'd never live it down, and I'm guessing that NFC is run through the mARM as with MODEM, BREW, RX/TX SMS BLUETOOTH,etc all the peripheral devices the system uses that would be strongly protected, as in what seems an oob on the NAND the protected spinlock section.

ROOTED ACER E320/C6 ;-)
[HTC Wildfire S] Antagonist42:
Have you managed to flash anything from a cold boot? No battery etc then flash, as i've mentioned before flashing 'blindly' produces nothing, no flash etc, flashing from an update though gives a result but how does the phone boot to fastboot/recovery unless either told to in a register in either IMEM (or where it stores it, i'm no Boffin at this lol) that could be where the difference in my malez flash didn't work and almost worked with EUU cold boot nothing as not authentic as in say IMEM register EUU authenticated the running and flashing of NAND and mARM sees this and opens NAND for flash as is Authenticated before and after boot.

ROOTED ACER E320/C6 ;-)
[HTC Wildfire S] no.human.being:
Ok, so you claim that mARM's IO is connected to the memory bus, not aARM's, so that mARM has control over NAND and aARM needs to ask, e. g. via RPC, firmware running on mARM to access NAND on its behalf, which would put the Radio in a position where it could intervene our NAND access, essentially blocking us from writing to the unmapped (Radio) NAND area, right?

Now that would actually be quite a strong security system. I've just got two points that indicate that this is not how it's done.

First, there has been a (reverse engineering) analysis of the HTC Vision's boot process, which features an MSM7230 processor (quite similar to an MSM7227), and this phone was found to have this "handover" step. So hardware-wise both mARM and aARM can talk to the NAND. Radio boots first and reads from NAND for initializing. Then it comes to a point where it will never need to access the NAND again. Only after it reaches that point, aARM will start booting and will now have, by convention, exclusive control over NAND.

Secondly, the Radio running on mARM will only need NAND access while initializing, while the aARM will need NAND access during regular operation. Always asking another operating system for memory access would result in quite some overhead, potentially harming device performance.

Last but not least, we know how it's done on the MSM8255 chipset, since the GFree exploit that can S-OFF devices with this chipset is open-source and with the MSM8255, there also does not seem to be any security system in place, that would intervene writes to the Radio area from the aARM. It does this strange "needle and haystack"-algorithm, then patches around in partition 7. I think that this "needle and haystack"-algorithm is there for mapping the Radio area while the phone is booted, while we do it by "cold booting" the phone with a custom kernel featuring a custom partition mapping. However, the principle is probably the same. They even use the same partition number for mapping the protected area. :D
[HTC Wildfire S] csoulr666:
Anybody took a look here???

It might be possible that it could be ported to our WFS
[HTC Wildfire S] schlund:
this will be the solution
[HTC Wildfire S] sythe179:
They use old revolutionary code for a hboot that can write to the nand.
[HTC Wildfire S] csoulr666:
but the point is that there doing it with phones which have their bootloaders unlocked via HTCdev................that's the main point
[HTC Wildfire S] schlund:
watch the wire trick!
[HTC Wildfire S] no.human.being:
How can they "base something" on Revolutionary? Afaik, apart from the zergRush exploit, Revolutionary have not disclosed anything and their exploit code is heavily obfuscated.

That's the main problem we have. All the Android hackers are b*tching around and not disclosing what they did, so whenever there's a new exploit to be developed by someone else in the scene, they all have to figure it out again and again. Not very productive.

I understand that they want to get credit for their work, but they would still get that if they opened up their stuff. And the thing about "if we disclose the exploit the vulnerability will get fixed" is pure bullsh*t. The firmware is so vulnerable (e. g. the "HTCU" in "misc") and basically we're now at a point where we know how it's done, but we have to build all the kernel-level device driver stuff again. It's a shame!
[HTC Wildfire S] einstein.frat:
it just needs some scary cake and a wire to s-off.
[HTC Wildfire S] no.human.being:
Well it needs their software to S-OFF as well. Looks like they're pulling one of the lines of the processor's JTAG interface down to ground (expect the SIM card slot holder to be connected to AGND) for whetever reason.

And well, they also seem to be patching the HBOOT, since it says "JoupunutBear" on the top when booted into HBOOT mode, just like it says "Revolutionary" when S-OFFed via Revolutionary. So basically we're all doing the same, just with slightly different methods.