yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
No. The input/output voltage stuff was for JTAG. JTAG is hardware-based debug. You can single-step each instruction on a processor. You can't do this via a serial UART. It's a much higher level.

JTAG = control over the processor.

Serial UART = remote console to REX.

The serial UART is no replacement for JTAG access. It can get you access to some logging features and whatnot, but it doesn't yield anything too useful.

No. We already know EXACTLY where it is stored. The problem is that on Qualcomm chips there are two "domains" and each runs its own operating system. One domain is called mARM (Iguana/REX is running here) and the other domain is called aARM (HBOOT/Android is running here). Each domain has its own address space. All Google/HTC code runs on aARM. On mARM there's only low-level Qualcomm code (low-level I/O and stuff). The secu_flag is in a memory region that belongs to mARM. An MMU (memory management unit) prevents all access to this region (even read access!) from aARM. Communication between mARM and aARM is possible via shared memory. When HBOOT (running on aARM) wants to know about the secu_flag (stored on mARM), it needs to query REX, which then reads the flag and stores a result in a memory region that is shared between mARM and aARM. Then, HBOOT can read it from there.

Yes. We have found a way to temporarily replace aARM's boot code. The major weakness is that all verification (signature checks, etc.) on the MSM7227 are performed on aARM and aARM is "untrusted land", because you can run custom code there. Whenever aARM needs to know about the secu_flag, it queries a special function. This function then does the inter-processor communication etc. and returns a single number telling whether security is off (returns zero) or on (everything other than zero, normally one). What we do is patch this routine with a version that does no inter-processor communication but always returns zero. When we do this, we achieve S-OFF (it's displayed and signature checks are disabled).

However, the problem is that the boot code on aARM "recognizes" that it's been modified and then triggers a "revert" to a "known-good" status. There has to be some condition in the boot code that, when met, triggers this revert. If we can ensure that this condition is never met, we can prevent the revert. Then we have won. So far we haven't found that conditional branch yet. The code base is too large to find it just by inspecting the code. If we had a debug facility (JTAG) we could single-step through the code and see where the revert happens. However, we don't have a working JTAG since the processor runs on a voltage that's too low for common JTAG interfaces.
[HTC Wildfire S] :
Ah. I tried to understand that to the best of my ability. However, you could check where it accesses when it reverts to a known good status. When you know that, you could change the known good status manually and then when it realises the device is modified when ran, it'll go to the known good place and then just restore S-Off again.

Secondly, can't you boost the voltage? With a transformer or something. Not sure. I suppose you could cut power from certain outputs on the mobo. Like the touch keys, screen, stuff like that.

Finally, single stepping is when it freezes the program at every next line of code, right? So if I made a program that says Hello World and then adds a full stop and then closes, single stepping would let me see the code for printing Hello world to the screen, then after that is allowed to run, it shows the code that adds a full stop, and etc... Sorry for questions.

Sent with my Sonic Screwdriver
[HTC Wildfire S] hell_lock:
Read all the techie stuff above and I gotta commend Qualcomm for the security system!

Btw can we increase the amount of voltage provided to jtag? Afaik there is something in the board files that regulates this voltage. We can try increase it.
[HTC Wildfire S] #define:
This is much deeper than kernel level..

What [MENTION=4318347]no.human.being[/MENTION] said relates directly to the processor...

Just "raw" hardware...

ғг๏๓ ҭђє ғเรђ™
[HTC Wildfire S] no.human.being:
The SoC (MSM7227) runs on an I/O voltage of 0.9 V. Most JTAG interfaces are built for 3.3 V logic. It just doesn't "fit together" on the electrical layer.

Data is going from JTAG interface to SoC without any problem. The SoC just accepts the higher logic voltage that the JTAG interface provides. But the other way round is problematic, since the 3.3 V inputs on the JTAG interface will regard the 0.9 V "logical high" level as a "logical low". OpenOCD will then claim that "processor returns all zeroes".

It might be sufficient to shift only the JTAG lines that go from the SoC to the JTAG interface, not the other way round. And it might even be sufficient to only shift the TDO data line, as the other lines are optional. But that is just a guess, I've never tried. The cleanest solution would of course be to shift everything from the JTAG interface to the SoC down from 3.3 V to 0.9 V and shift everything from the SoC to the JTAG interface up from 0.9 V to 3.3 V.
[HTC Wildfire S] :
If you ever get the JTAG running, then you could try and single step so that when you use the exploit, you can stop it from reverting or something.

Sorry for late reply. Forgot to finish in morning.

Sent with my Sonic Screwdriver
[HTC Wildfire S] no.human.being:
Yes, theoretically. In practice it's a bit more complicated. Say for example there's a routine that draws an image to the framebuffer. The HTC Wildfire S screen is 480x320 pixels large and I think it has 16 bits (2 bytes) of color depth. So redrawing the screen a single time would take 480x320x2 = 307.2k memory writes. Or a quarter of that in case they were smart enough to process two entire pixels with each write and use the full ARM word size (32 bits) for processing. Have fun single-stepping through this.

Instead what you would do is, you would see that it stays in the loop for some time, look at the instruction that breaks the loop (a conditional jump), see where it goes when the loop is left, set a new breakpoint there and then let the processor run until it hits that breakpoint.

I guess it gets even more complicated. For example, the processor does interrupt handling. Interrupt handling works like this. When a certain signal comes in, the processor branches to a special location (the interrupt handler) immediately. Now let's say the processor has a timer interrupt that is fired every 10 milliseconds. When you halt the processor, you will always end up in this interrupt handler since a few thousands of timer interrupts have come in during the time you spent for stepping/continuing/whatever the processor.

Of course you could somehow disable interrupts, but then you effectively alter the control flow from normal operation, so you might end up with different behaviour. So even with JTAG, it's probably not THAT simple, but without it's next to impossible.
[HTC Wildfire S] no.human.being:
Exploit development for the HTC Butterfly (APQ8064) has stopped. The exploit had the same problems as here (reverted). Devs then found out that firmware is not installed by HBOOT at all, but by TrustZone (a hardware virtualization layer by ARM - it's not a Qualcomm thing, all newer ARM cores have it), so this exploit won't work.

The HTC Butterfly is an eMMC-based device, so the MPU is embedded into the memory, not the processor. For this reason, a hardware-based attack (shorting out the power supply to the memory) might work. There is also a vulnerability in TrustZone, which might be exploited by software means, but it has nothing to do with loading a hacked APSBL.

Sorry. :(

This doesn't mean that the exploit won't work on the HTC Wildfire S (MSM7227) however. That chip is NAND-based and doesn't have TrustZone yet. Any ideas on what causes the HBOOT to revert so we might patch that out?

Does anyone even still own the device?
[HTC Wildfire S] csoulr666:
I still have it......But I am thinking of changing when I see a phone that suits my needs...The Xperia SP is in line for that :D

Well we can work it out with an unlocked bootloader.....Thanks for your hard work...Threads like these have taught me a heck lot about mobile technology....I guess I can take that as a consolation :good:
[HTC Wildfire S] :
I'm sorry, but, NHB, just let it go... It's been 2 years, we can't do it, and real life has taken away our WFSs. Not many people here have the phone anymore.

I thank you for your hard work though. I really, really have respect for you.

If you take my advice and leave it for now, then, I suppose you could make a ZIP containing all your exploits for the WFS, files that contributed, code, text files explaining things, links, etc... So all the work is there packed up and made public for anyone who wants to see.

It's almost making me feel guilty that you're still working hard for the phone and stuff.

Sent with my Sonic Screwdriver
[HTC Wildfire S] no.human.being:
Thanks man! It's a pity that we have to quit, but you're right, it's not worth it for a device that has been discontinued. I really thank you, as well as all other contributors, for the time and effort you've put into this project. Collaborating with you has been fun and a huge pleasure for me.

Please leave this thread open. If anyone has news, feel free to post. I'm probably gonna continue checking back at regular intervals for some months (if not years ;) ) to come so be assured that I'll always be around. Thanks to each and everyone of you for the great time.

And "congratulations" to the Qualcomm engineers. Even though your system is clearly "security through obscurity", you've successfully prevented us from breaking it in a concentrated global effort by making it incredibly complicated and hard to understand. :laugh: :laugh:

Of course I'm not gonna quit. I got a lot on my list, so I'm just gonna move on to my next big project. I've been planning this out since October 2012, together with a close friend of mine, who is also an IT expert, and the first big steps are gonna follow soon. We've mutually agreed to keep it top-secret, so I'm not gonna tell anything about it yet. Just so much, it's got nothing to do with Android development (at least not so far).

So long and keep up the great art, guys! :good:

EDIT: Yeah, just got 1024 = 2^10 thanks. ;)
[HTC Wildfire S] :
Thanks. Tbh, all I did was contribute my radio.img.

Really sad though. I'll be checking back here too.

Sent with my Sonic Screwdriver
[HTC Wildfire S] :
Dangit I still didn't get a jtag interface lol :o sad to see this project die :( oh well, i guess it's better this way. . Thanks for all your efforts everyone :)
[HTC Wildfire S] :
The only way we can get SOFF now is either XTC or downgrading HBOOT and flashing a zip.

Sent with my Sonic Screwdriver
[HTC Wildfire S] heavy_metal_man:
I feared this would be the case. :/ any word on the other dev project?

Also, I have an xtc clip in scotland. Anyone wanting use of it pm me :)
[HTC Wildfire S] #define:
No man..

Its pretty much dead on our side as well..

I'll try to research some more when i find some time...

I'm under a heavy load right now.. Studies and all..

ғг๏๓ ҭђє ғเรђ™
[HTC Wildfire S] heavy_metal_man:
Its such a pity, this showed such promise :(
[HTC Wildfire S] #define:
To be really honest, i'm real happy we came this far...

ғг๏๓ ҭђє ғเรђ™
[HTC Wildfire S] :
Same

Sent with my Sonic Screwdriver
[HTC Wildfire S] ScardracS:
You have take lots of time in this project and you have make lots of progress but qualcomm's engining are very hard to breack. Good luck mans
[HTC Wildfire S] ScardracS:
Hey man!! http://xdaforums.com/showthread.php?p=37589247
[HTC Wildfire S] no.human.being:
It only unlocks the bootloader. Developer "theq86" from our rows wrote a tool to do it without the token from HTCdev some time ago.

However, unlocked bootloader and S-OFF are not the same thing. Unlocked bootloader allows you to flash unsigned images to "boot", "recovery", "system", etc. so you can flash a custom recovery (e. g. CWM) and then a custom ROM (e. g. CyanogenMod) from within the custom recovery. S-OFF also allows you to flash custom bootloaders and Radios, change CID, simlock, repartition the device and do a lot of other cool stuff.

Basically you can say that unlocking the bootloader gives you control over the application subsystem (aARM), while S-OFF will give you control over the modem subsystem (mARM) as well.
[HTC Wildfire S] simonsickle:
Yea. Thanks to theq86 I was able to unlock this phone with only temp root. I have been translating to Java to release an apk to do it all (minus root of course). Now, on newer devices the flag is still present but its only on a write protected partition. Hboot talks to the emmc firmware that tells it what partitions to protect. So if you were able to somehow reset the emmc chip on newer phones, you would be able to write anywhere on the phone. So maybe the same logic can go in reverse. The write protection is far more modest then the totally obscure stuff the S3/4 processor phones have
[HTC Wildfire S] no.human.being:
Which phone are you talking about when you say "this phone"? WFS? Well the WFS is a NAND device, which works differently from an eMMC device.

On an eMMC device, protection of the persistent memory is enforced by the eMMC chip itself ("eMMC protection"). It can be configured once (on old devices by APSBL, on newer devices only by SBL, which is why our exploit can't work there) and is then fixed unless the eMMC is reset (which means not cleared, but just - well - "reset" - its internal state machine put into the initial state again if you like). The eMMC protection is an MPU (memory protection unit) only. It can block or allow write access to certain pages on the eMMC.

On a NAND device, protection of the persistent memory is enforced by a dedicated "NAND MMU" in the SoC (MSM7227), which sits between the processing cores and the EBI2 bus. It can be reconfigured at any time by a bus master (processor). The NAND MMU is a full-blown MMU. It can translate "virtual" (what the processing cores see) to "physical" (what the NAND device sees) addresses by means of a TLB (translation lookaside buffer), allow or block read and/or write access, trigger interrupts on processors when a certain access happens, etc.

The stuff that happens on a NAND device is far more sophisticated, BUT, and that is the important point, it can be reconfigured at any time. The only way to disable eMMC protection is to reset the eMMC. On some older devices you could do this via software, since the reset is linked to one of the processor's GPIOs. On newer devices, TrustZone (a virtualization layer) blocks access to this GPIO. However, if you can get access to the eMMC's power line on the board, you may just short it out to ground and then the eMMC is unprotected. This is probably how Juopunutbear works. On a NAND device, all we have to do is understand how to configure the MMU. We cannot reset it, since it sits inside the SoC and not inside the memory (like on an eMMC device), but we can program it to make the address space entirely "flat" with no restrictions imposed upon read/write access. We could try writing code which does this and then "boot" from this code. However, what to do after the NAND MMU is basically "disabled" (or "flat")? We either have to write a modified HBOOT to NAND (hard to do in assembly code - I don't even know how to handle NAND in assembler code - remember you somehow have to write "one page at a time", but ARM can only write a word at a time - you probably have to write to some buffer in RAM and then tell the SoC to write it to NAND atomically - no idea at all how this works) or we have to boot Android and then write our patched HBOOT (or even the secu_flag directly - the MMU is disabled so we may access it) to NAND. However, have fun booting Android on the assembly level.

You understand the problem? We either have full control over the system or we have an operating system running, but we won't have both at the same time. So we need to do whatever we want to do with our elevated privileges right on the machine level. And that's what we don't manage to do and so we don't get S-OFF.
[HTC Wildfire S] :
Sorry for OT, but did theq86 leave or something?

Sent with my Sonic Screwdriver
[HTC Wildfire S] ScardracS:
Oooh schit.. i have hoped this help you but nothing :(
[HTC Wildfire S] BeciMester:
Hi guys, I still have my WFS and it still works, obviously we don't use it as a daily driver anymore. I'm sorry I couldn't contribute more to this project but unfortunately I was unable to work on it since my last post on this thread. Final year at college, coupled with the final year project work, is taking all my time. However, it's on my (ever growing) list of things to do for when I get my free evenings back, and I hate giving up on anything, so I plan to (eventually) continue disassembling the hboot and one day I'll hopefully figure it out completely. I realize it will be too late for everyone else because people are moving on to other phones, but I look at it as a fascinating challenge. This is not a promise though - it's just a plan. We'll see how it turns out. But I certainly learned a lot and I'd like to thank all the contributors for that. :)

(I'm on my phone...)
[HTC Wildfire S] theq86:
Since I had no WFS anymore and the project reached a level at where system engineers were needed which goes far beyond my knowledge I could not contribute anything relevant anymore :(
[HTC Wildfire S] :
Ah OK. Real shame. But, you did good work.

Sent with my Sonic Screwdriver
[HTC Wildfire S] rezo609:
You guys put amazing effort and time in your life to S-OFF the Wildfire S. It is very sad to see this thread die off after 2 years. You guys are amazing, just remember that. :)
[HTC Wildfire S] Vipul Modak:
help

cmd showing error it says nt a valid command plz help noob here :silly:
[HTC Wildfire S] pihug12:
Do you think the new Revolutionary tool for HTC One can be useful ? (I know it's a eMMC device...)

I remembered [MENTION=4120742]munjeni[/MENTION] successfully reverse engineered the first Revolutionary utility, and we found out nothing can be useful for our Wildfire S.
[HTC Wildfire S] no.human.being:
I remember that Revolutionary was said to be based on GFree and GFree is an eMMC-only exploit (most likely not for the new eMMC devices though). The Wildfire S is based on an MSM7227 SoC, which is a NAND device. Different memory-controllers and firmware.

eMMC devices have an MPU (memory protection unit) on "slow bus" only, which is integrated into the memory chip itself. MPUs can block access to pages only.

NAND devices have a full-blown MMU (memory management unit) on "slow bus", which is integrated into the SoC. MMUs can translate virtual to physical addresses and trigger interrupts on access, that mARM can then capture and handle. This allows mARM to create an entire "virtual address space" for aARM, which is the reason why what you see in NAND via JTAG is so radically different to what you see in NAND via software.
[HTC Wildfire S] *se-nsei.:
It was lovely working, helping and exploring this device with you all. I've moved on to the Galaxy Nexus, so a goodbye from me! :D
[HTC Wildfire S] :
I got a galaxy nexus too a week ago :) :high-five:
[HTC Wildfire S] :
Sweet new phone guys!

Sent through the Time Vortex!
[HTC Wildfire S] Olivier:
I got my Xperia S about 2-3 months ago but I'm still active in the WFS fora :D
[HTC Wildfire S] :
Hehe, hopefully in two weeks I can pick up my Xiaomi MI2 :)
[HTC Wildfire S] Olivier:
I thought you'd move on to an iPhone 6? :p
[HTC Wildfire S] csoulr666:
I'll stick to this device for atleast a year.........then look for a good mid-ranger,probably from HTC
[HTC Wildfire S] :
I'm done with htc. It's all nexus from now on :)

Sent from my Wildfire S A510e
[HTC Wildfire S] Olivier:
I might go back to HTC after 2 years with my Xperia S...

Envoyé depuis mon ONDA MID en utilisant Tapatalk 4 Beta
[HTC Wildfire S] :
Nah, mate, get the latest nexus :p they're consistently amazing phones :D
[HTC Wildfire S] cyb3r.pr3dat0r:
they are great phones but not as awesome as htc one , the best phone ever built by humans till today :victory:
[HTC Wildfire S] Olivier:
No way, if I want AOSP, I can flash it myself! :p

Maybe I'll switch to Samsung again, who knows. :p

However, this is not the right thread for this topic so let's quit spamming. :)

Envoyé depuis mon ONDA MID en utilisant Tapatalk 4 Beta
[HTC Wildfire S] izi501:
This thread isn't really alive so it isn't spam :P

But the Wiko Cink is the best!

Envoyé depuis mon HTC FeuSauvage S avec CM10.1 et Tapatalk 4 ;)
[HTC Wildfire S] kalaker:
It most definitely is spam. It's spam to anyone who subscribes to this thread to learn about S-OFFing the WFS. Please, respect the rules and have a discussion about this in another thread in general.
[HTC Wildfire S] izi501:
Okay :) sorry.

But wouldn't it be better to close the thread then?

Envoyé depuis mon HTC FeuSauvage S avec CM10.1 et Tapatalk 4 ;)
[HTC Wildfire S] no.human.being:
Wise decision guys. Congratulations!
[HTC Wildfire S] simonsickle:
Has anyone tried the firewater method to soff?
[HTC Wildfire S] Olivier:
Doesn't work for NAND devices either...

Gesendet von meinem Xperia S mit Tapatalk
[HTC Wildfire S] izi501:
I tried but it failed and the dev told me it wouldn't work.

Envoyé depuis mon LG Marteau avec Tapatalk
[HTC Wildfire S] :
Guys, if you want to continue this then I think you should make a fresh thread. Me and some others, including the main hackers and OP decided this thread is finished. Nobody will be updating the OP either.

- Amp Milk
[HTC Wildfire S] artturnip:
Agreed. Most of the developers from the 'good ol' days' of WFS modding when no roms worked and you were lucky to have mobile connection have moved on... (I've had mine two and a half years, now on an N5)

I think maybe some fresh eyes on this conundrum might lead to some new discoveries. Even if a new one is started, this thread does still have a hell of a lot of stuff in it, so should definitely be kept. Even if only for old times sake.
[HTC Wildfire S] Antagonist42:
If there's a new thread started please drop a link on this thread ;)

Time away, new devices and a bit more knowledge will always help ;)

I may use my not-so-useful ACER E320 as a testing ground as I can't find anything or anyone recent I can get the mmcblk details from! ....makes it a candidate for hacking abuse :D

Bashing away at my HTC Desire C
[HTC Wildfire S] Atlantic777:
Anything interesting happening with WFS hacking these days?
[HTC Wildfire S] roseboss:
1307

Where i can downlosd all these files?
[HTC Wildfire S] csoulr666:
You can't. This thread hasn't had any activity regarding any development in like months.......... PLEASE stop bumping up old threads
[HTC Wildfire S] ONeill123:
hmm, right, but i hope, that both ways work for a solution and someone (i hope) find a way to set s-off with software or/and HTCDev unlock the bootloader.

Maybe after unlocking the bootloader someone can set s-off the phone easier.
[HTC Wildfire S] sythe179:
HTC have denied any development towards helping with the bootloader, and any further development to the wildfire s, then they say something about unlocking all pre-2012 phones.....don't trust HTC..

Better to find our own method...or to a greater extent, help rev, or another group to extend there focus to the WFS.

But, the new temproot seems like q step in the right direction, as long as it becomes combatable and more stable.
[HTC Wildfire S] ONeill123:
Maybe with the tacoroot exploit it is easier to set s-off or to install cwm or fake flash.

Ot can't be so difficult to set the wildfire s s-off if the desire s is s-off, or?
[HTC Wildfire S] *se-nsei.:
Gobsmacking fact: 91%+ of the XDA Wildfire S forum members don't own/used an XTC Clip.
[HTC Wildfire S] Lt.Win:
Ikr, I hate that it's so costly. I especially hate it when its in foreign currency. Damn you XTC Clip! It's available in my city, but it's in a rather unsafe place where I have no guarantee whether it will work or not. My dad's not ready to go there. If I had S-OFF, I would help as much as possible. Let's get our wishes and job done.

Gogogo!