yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
For the JTAG interface, you usually want to ensure that it's supported by OpenOCD (that's the debugging software). Many interfaces do not support actual "debugging" but merely "programming". This will be sufficient if you want to dump and modify NAND content, but with "debugging" capable interfaces you'll also be able to, well, debug the system code, which, while not absolutely neccessary under all circumstances, will of course be very nice to track what's actually going on inside the phone. :D

With a "debug capable" interface you can e. g. "trap" Iguana when it reaches a specific instruction (breakpoint) and then single-step it, etc. It's like the entire system was running inside a debugger. The interface I have is based on an FTDI FT2232 UART chip. It's capable of "debug mode", but, well, the voltages don't match. :D

Yeah, kinda. Say around 60 € for interface + adapter. And MAY you also need additional equipment (cables, clamps, resistors, regulated DC supply, ...) to get the device to boot. I don't think it's neccessary for programming, but it's almost certainly for debugging.

But probably the biggest problem is that, unless there is an interface that can work with 0.9 V targets and does support debugging (I found none) your only chance seems to be "handcrafted" circuitry. However, doing it all with discrete FETs will be a mess (end relatively expensive). It'd be much easier (and cheaper) if there was an "integrated" (IC) solution one could use, but none seems suitable. It's really strange, as I think there have to be a bunch of people that want to debug a low-voltage ARM11, but you really don't find anything about it. It's all for, say, 2.0 - 3.3 V.

Of course apart from a few that appearently work but may not support debugging. :D
[HTC Wildfire S] heavy_metal_man:
so are we stuck atm without being able to debug? so shall we hunt for a jtag that is up to the challenge or find an electrician to wire us up a "rig" capable to do the voltage changes?
[HTC Wildfire S] Antagonist42:
Maybe we should harass Lauterbach as Qualcomm use them ;)

GT540 - E320 is poorly
[HTC Wildfire S] no.human.being:
OpenOCD supports these. Lauterbach is not among them. Like I said, most are based on the FTDI FT2232 or FT2232H (mine is based on the latter) UART.

Note that this is only a list of interfaces that OpenOCD supports for debugging. First, you'll only be interested in the USB variants, since practically no computer still features a parallel port these days. :D

The interfaces listed are all sorts of interfaces for all sorts of processors, so not all of them are for ARM. Some are only for specific versions of ARM. E. g. the STM32 is an ARM-clone, but JTAG interfaces that are specifically for STM32 will probably not support other types of ARM, otherwise they would be labelled interfaces for ARM.

Some of the interfaces (e. g. Segger JLINK) are processors themselves, since JTAG can also be used for inter-processor communication. This is of course a bit "overkill" though, since you have an entire processor (with its own firmware) in the box. They may be more prone to failure than the "simpler" UART-based interfaces and they're probably more expensive.

The list will shrink very rapidly based on our needs. Also the 0.9 V voltage is extremely low. The lowest that the site mentions is 1.8 V which is still TWICE AS MUCH as what the MSM7227 uses.

Last, but not least, note that the site mentions the following.

So at least it does not appear to be uncommon to require level conversion between the processor and the interface, however, I haven't found a suitable converter yet. Of course 3.3 V (interface) <--> 0.9 V (processor/target) would be ideal, then you could use an FTDI2232H-based interface. They are high-speed UARTS and cost around 45 €.
[HTC Wildfire S] Antagonist42:
No they must be (or just not publicly available yet) or Qualcomm wouldn't mention Lauterbach in their documents (why would they if they're not sticking to say 'standards'?)........ OOOOH! ..... thought just struck me, as MSM7227 is a dual core but cores operate separately would you not have to debug each core separately?

Hmmm Lauterbach cover the cores separately although not sure which 'CORE' (if any) MSM7227 comes under but if you know more then i'd have a looksie here under Products>JTAG Debugger - then under support chips
[HTC Wildfire S] no.human.being:
Following that logic it's not a "dual core", but more of a "quad core", as there are two DSPs inside as well. No, technically it's not a "multi core". The term "multi core" usually refers to chips having multiple identical cores. It's a single core (ARM11/aARM is the "main processor" and it's a single core) supported by three coprocessors (ARM9/mARM, DSP4/mDSP, DSP5/aDSP). The OMAP4460 has at least 6 cores (two ARM Cortex A9 main processors, four ARM Cortex M3 that are used for application digital signal processing) and on the Galaxy Nexus (which uses OMAP4460) there's also a discrete ARM926 from Infineon on the board for the baseband. Still, the Galaxy Nexus that has the OMAP4460 and the ARM926 is not announced as a "hepta core phone" for its (at least) 7 cores total (lol), but as "dual core". Two Cortex A9 and the rest is just coprocessors.

However, having a single JTAG port, even for multiple chips on a board, is not unusual. The debugger accessses any of the chips (preferably the fastest) and then JTAG can issue commands to the chip to talk to another chip and so on. This is called a "daisy chain" and the MSM appears to use this, not on the board, but on the IC level.
[HTC Wildfire S] davidang:
Should we post this thread to the XDA news so that more developers come join us to get s-off love
[HTC Wildfire S] heavy_metal_man:
i believe his thread has already been in the xda news :/
[HTC Wildfire S] no.human.being:
Indeed, it is in the news. The problem is simply that the phone is not widely used. And now that HTC has discontinued the model, more and more will migrate away from it.
[HTC Wildfire S] Lt.Win:
Off-topic warning

That's one of your shortest posts! :D

End of ot.

So the problem is still about letting the hboot not fall back? And suppose we do get this s-off, it will be a permanent one or will it be like revolutionary?
[HTC Wildfire S] heavy_metal_man:
Here is a question, has anyone attempted the fast boot hacked boot loader of a s-off phone to see if it still rolls back? If we used a different numbered hboot as a test medium it would be interesting to see the results.
[HTC Wildfire S] theq86:
in some thread about downgrading, rezo stated, that, if hboot is allowed to be installed or not, is depending on the text file inside the PG76IMG.zip.

There's a number indicating if hboot can be overwritten.
[HTC Wildfire S] Lt.Win:
So what you're saying is that if we change that text, we can downgrade to 0.90 and gain S-OFF with the rom_01.zip?
[HTC Wildfire S] beaups:
No because if you change any of the the text you break the signature in the zip file.
[HTC Wildfire S] no.human.being:
That means that you could downgrade to HBOOT-0.90.0000 while running the "injected" bootloader, as that one won't check signatures.
[HTC Wildfire S] akestrel1987:
That makes sense to me... and if you do push in an older hboot that doesnt check for issues then i would think it would be able to be permanent and not overwritten (so long as you change the text file for the overwriting part)
[HTC Wildfire S] theq86:
http://xdaforums.com/showpost.php?p=22721704&postcount=10
[HTC Wildfire S] :
Hi guys,

sorry for the OT, but remember me? I was the annoying troll in the forums. My phone was stolen and then I was slowly forgotten. I "donated" a radio image, and I got my name mentioned in the first exploit. *sighs* Good times.
[HTC Wildfire S] heavy_metal_man:
at this point would nand dumps from before and after a xtc clipping herald anything useful to use or are we just stuck?
[HTC Wildfire S] theq86:
we are stuck with nhb and me having no wfs anymore :crying:

so the active testing part must be done from someone different.

we do not need dumps anymore. the hboot part making s-off is found and patched. the only remaining thing is to get the chainloader exploit working.

this needs however experience with hboot to find out why is always restores itself before we can do the precious logics.
[HTC Wildfire S] no.human.being:
All "normal" HBOOTs "revert" ("fix themselves") when loaded via "chainload" exploit. ENG HBOOT cannot be directly loaded via "chainload" exploit, since it runs from the address where normally the kernel lies. Executing the exploit code two times in a row with the "outer" exploit running the "inner" exploit as shellcode and then the "inner" exploit running the ENG HBOOT as shellcode might work somehow, but I didn't get it working yet. ENG HBOOT is very old. It might need an older Radio in order to work properly, I don't know.

The interesting thing is that HBOOTs even "revert" if they're unmodified (stock) HBOOTs. This means that they probably don't check against a hash in their own image executing from memory (as that would be matching on an unmodified HBOOT), but probably indeed compare against the HBOOT image that Iguana provides to aARM via this mysterious "unmapped" (and probably virtual) NAND area as this is guaranteed to be "stock" (as long as Iguana is stock).

Like theq86 says, testing is hard without a device available. Since the device was discontinued (gets no longer produced) by HTC it might not be worth the effort either. For those of you who want to tinker around with everything, grab yourselves an OMAP-based device (OMAP = ARM processors by TI). They're technically superior to Qualcomm chips (some people say that Samsung Exynos is still higher spec than OMAP, but I'd say that depends on to which OMAP chip you're comparing them - the newer OMAP chips are very nice :) ) and have at least partially (though not entirely) open firmware (first-stage bootloader is open source, second-stage bootloader and Radio firmware are proprietary) and no protection on the eMMC Flash memory, which means that you can literally modify the entire firmware using "dd" on a rooted device while the device is normally booted into the ROM. The downside is that you can, of course, easily brick the device if you're not careful what you're flashing or an app runs havoc with root permissions and damages critical parts of the firmware.
[HTC Wildfire S] heavy_metal_man:
damn. feels like we were so close too.

if we managed to fastboot a marvelc hboot to the gsm version and got it to stick do you think it would allow the flash the diag without the flexy cable?
[HTC Wildfire S] no.human.being:
This would not help a lot. Security is disabled by Iguana, not DIAG (DIAG mainly "requests" Iguana to disable security) and the engineering SIM (emulated by xtc-clip) is queried by Iguana as well, since Iguana (mARM) can talk to the SIM card slot, DIAG (aARM) cannot. You'd have to run a CDMA Radio in order to be able to disable security without the engineering SIM. However, a CDMA Radio will not work on a GSM chipset.
[HTC Wildfire S] #define:
Is this thread dead?? I am trying to achieve S-OFF for the HTC Explorer, which is basically a stripped down(memory wise) version of the HTC Desire C.. And this thread has helped me a lot.. A lot a lot..

The last big thing that happened was NHB achieved S-OFF, but the phone gets rebooted into the ROM, right??

I am gonna try something like this on the Explorer too..

And I count on this thread for help..

Sorry if its spam.. Will remove it if it is..
[HTC Wildfire S] artturnip:
What happened was that whilst he was able to chainload an alternative hboot on top of the original, it insisted on restoring itself. If he/we could find what was causing this restore, we'd have temporary s off! :D
[HTC Wildfire S] #define:
Ok.. So then the temporary S-OFF could be used to further achieve true S-OFF... Right??
[HTC Wildfire S] artturnip:
Yes, I think so... but NHB thought that temporary would be more useful. As it poses none of the security risks (your device is only s off for a short while...) but you can still flash the radio if you wish! :D
[HTC Wildfire S] heavy_metal_man:
ok so i have a htc wildfire cdma (bee) and i was trying to use fastboot to s-off via AT@SIMLOCK=7,0 command to the radio via fastboot oem rtask c, as theorised in this post but i am getting the error: FAILED (status read fialed (too many links)). any ideas what may be the cause of this? i have an unlocked bootloader from htcdev should it change things :)

bearing in mind that this is an older device i am not sure if this will work, but i am allowed to unlock the bootloader via htcdev, so i hold out hope :)

additional info:

BEE DVT2 SHIP S-ON RL

HBOOT-1.40.000

MICROP-0422

RADIO 1.00.00.0216

Dec 14 2011, 20:02:16

using windows 7 64bit and adb from android skd platform tools.
[HTC Wildfire S] no.human.being:
Well, technically it wasn't "on top". I let the "original" HBOOT from the phone load the exploit and this in turn loaded another HBOOT image which replaced (overwrote) the HBOOT code in volatile memory. So after the exploit was through, there's only one (the modified) HBOOT running on the phone. You can't run them "on top of each other", they're not operating systems. :)

However, either the system "below" (Iguana) or the (chainloaded) HBOOT itself somehow recognizes that the boot code has been tampered with and restores a "clean boot image" from the "unmapped area". If it's Iguana, we're most likely out of luck since we can't tamper with that (it's running on mARM and there's an MMU between "our code" running on aARM and Iguana running on mARM that's shielding us off), but chances are that it's actually the HBOOT code performing the restore (you can build an infinite loop into the boot code and then it will no longer restore but freeze the device) and then we could prevent it by removing the "restore logic" from the HBOOT image we load via the exploit.

Yes, most likely.

Also true. The exploit must be performed from the host and while the device is in Fastboot mode. If you chose to make S-OFF permanent by flashing modified boot code, your NAND protection is permanently disabled and apps with root privileges might tamper with your Radio and boot code (if they manage to map the "unmapped area" in, which is not simple, though probably not impossible). However, the exploit alone, without flashing boot code, would already give you the ability to, say, flash the Radio. The phone will be S-OFF, but only beginning from the point where the exploit was performed and until a "cold reboot" (probably the next OS reboot) is issued. I find this option very tempting.
[HTC Wildfire S] #define:
Actually now that I know whats really happening "behind the scenes", I agree with no.human.being...

With a temporary S-OFF, the user and user alone has access to the "forbidden" areas.. No other apps or anything..
[HTC Wildfire S] artturnip:
Did I actually get stuff right??!! :eek:
[HTC Wildfire S] heavy_metal_man:
But we still need to try work out why the hboot rolls back, and without a dev with the device and/or a JTAG debugger this will be damn hard.
[HTC Wildfire S] artturnip:
How much does JTAG apparatus cost? I've got the device... but would probably need some kind of 'step by step' things... :eek:
[HTC Wildfire S] powerfull777:
Umm I have s-off a wildfire s a while ago I can't even remember how. it was with the gsm version without an xtc clip
[HTC Wildfire S] surma:
GSM-version is S-OFF-able if it has 0.90 HBOOT. I've done it to my wifes WFS and I still have the file needed for it.
[HTC Wildfire S] heavy_metal_man:
Are there no JTAG specific to the wildfire s alone? Do you think it would be possible to find a professional to build the custom circuitry?

---------- Post added at 03:51 PM ---------- Previous post was at 03:42 PM ----------

http://gsmserver.com/shop/gsm/riff_box_jtag.php

What about this JTAG? It claims nand control And one nand control for the marvel chip set, and I believe it comes with its own software?
[HTC Wildfire S] :
Why not just connect the lithium cell to the board?

Sent from my Baconator Over-9000
[HTC Wildfire S] no.human.being:
It's hard to contact. It only has four small copper plates that are contacted by spring-loaded copper contacts in the phone. You cannot e. g. put a clamp onto them since there are no "pins" on the cell that you could use to get a grip on. Your only chance is pressing something against the contacts (but what would provide the mechanical tension that's required for doing this?) or solder some wires onto the cell (not good if you want to use the cell again in a "regular fasion", also Lithium cells should not be heated as this may lead to explosion).

It'll probably work. It's expensive as hell though.

Yes, that's the problem. It requires its own software since it's not supported by OpenOCD. When using custom software, you usually don't know what features it has beforehand. OpenOCD is pretty much "standard software" in on-chip debugging, so when an interface is supported by OpenOCD, you know exactly what you get.
[HTC Wildfire S] artturnip:
Hmm... I'm not gonna be able to get involved in this JTAG malarky :mad: But I'm able to help any other way possible! :D
[HTC Wildfire S] heavy_metal_man:
http://www.youtube.com/watch?feature=player_embedded&v=7yNQeSG3yn4 this is its jtag read write halt ect functions. would they suffice?
[HTC Wildfire S] no.human.being:
Debugging (viewing disassembly of code in memory and single-stepping when halted while seeing processor state) would be useful for what we'd do.
[HTC Wildfire S] #define:
Guys, is it okay for people from other devices' forums to use the exploit NHB created?? I'm trying to achieve S-OFF on HTC Explorer..

So I am asking for permission to use the exploit.. Granted??
[HTC Wildfire S] no.human.being:
What he wants to ask is, whether we'd give him the code for the "chainloader" exploit to test it on an HTC Explorer (MSM7225A). I told him that from my point of view he may have it for testing (as long as he doesn't publish it for everyone to see unless e. g. he has a working S-OFF method that's worth publishing), but I first wanted to ask if it's alright from the other contributor's point of view that we're handing the exploit code over to another dev team.

What the exploit does is replace the boot code (APSBL) in RAM via software while the device is booting. This allows you to execute an unsigned APSBL (HBOOT) on the phone even if you don't have permission to flash the HBOOT partition. I expect every device that can load "supervisor mode" (kernel) code via Fastboot ("fastboot boot ...") to be vulnerable to this exploit category.

Since I don't have access to a device for testing anyway, it's probably not too bad when another dev team on a more "active" device "takes the lead". When they are successful, we may try "backporting" some of their ideas to the WFS.
[HTC Wildfire S] heavy_metal_man:
well at this point we are totally stuck without the debugger, or any of the "main players" having the phone. maybe their could be cross team communication to help us all get s-off?
[HTC Wildfire S] #define:
Exactly!! The devs over at Explorer forum are trying to port the 3.x.xx kernel for Explorer, from HTC Golfu.. That ought to have more features and functions to achieve the S-OFF..

So may be we could join forces..

If you guys remember munjeni, he's told me what changes I have to make in the HBOOT.. So I already have a heading..

Also, I can assure you that I am not a spy from HTC.. :P

And the exploit will be published, if at all, only AFTER successfully testing on atleast 5 devices..
[HTC Wildfire S] #define:
Guys, one last question before doing this :

What are the worst case scenarios here??

I need to know the risks involved.. Because a JTAG riffbox is highly expensive when converted in my currency..
[HTC Wildfire S] heavy_metal_man:
AFAIK all "the exploits" operations happen in the ram/ virtual memory so all changed can be reversed by rebooting the phone. But if you are successful in gaining temp s-off and then load the tampered s-off hboot to that and allow it to flash you would have permanent hboot s-off that would not be wiped after reboot. So just be smart and careful and you will hopefully be fine :p
[HTC Wildfire S] no.human.being:
As long as you don't instruct the "hacked" HBOOT to perform writing operation to a critical part of the phone (have a file on the SD card that it would flash or do a "fastboot flash radio", "fastboot flash hboot" or any flash with an HBOOT that has a partition table that doesn't match the memory layout of the phone - be sure to always take an HBOOT as payload that was designed for the exact phone model and this won't happen) things should not go terribly wrong.

Writes that occur in the "guest" are either non-critical (user data or operating system might be damaged - take a NANDroid backup in case something goes wrong) or restored by the host on reboot. Writes that occur on the "host" (Iguana) side are potentially dangerous. The exploit will not (intentionally) perform any requests to Iguana, but of course the "shell code" could. Generally, all partitions that are not "visible" from within Android live on the "host". The "relatively uncritical" partitions on the "guest" are called "boot", "recovery", "system", "cache", "devlog", "userdata" and "misc". The "misc" partition is partially dangerous as it contains firmware for the phone's SD card and USB controller that appears to be used by the host as well, so if you damage "misc", you MIGHT have a hard time talking to the phone. Restoring a proper "misc" image is hard when you cannot transfer any data to the phone via USB and cannot access the SD card anymore (munjenji had once damaged his "misc" while tampering around with the device and had a VERY HARD TIME to recover from it). The VERY critical partitions are the ones that belong to Iguana though. They are called "radio", "hboot", "sp1", "sp2", "wifi" and so on, but this may vary on different phone models. Like I said, I don't even know whether the MSM7225A firmware is based on Iguana at all.

When you damage Iguana (or whatever "low level firmware" the MSM7225A uses), you'll usually have to resort to hardware means (JTAG) to restore the clean firmware image, that you hopefully took via the same "hardware method" before the damage occured.

All in all, it should be quite "low risk". I've tried and tested so much stuff on my WFS and I never damaged it. It died because the hardware buttons wore out. :)

But again, MAKE A NANDROID BACKUP. The "normal" partitions are formatted for all sorts of reason when you start messing with the phone's firmware. E. g. if you have the "DIAG file" on the SD card, it will run on the next reboot and the utility will immediately format "userdata" without any further request or confirmation. I've lost all my contacts because I didn't know this was going to happen.
[HTC Wildfire S] #define:
Okay.. So I'll be testing it within a few days and will keep posting the results here..

The bad news is that all the "devs" are busy porting the 3.x.x kernel, so I'm gonna have to do it on my own.. With very little help..

So it may take some time(a week or so).. Please bear with me..

I'm no expert(yet), so I'm gonna have to "investigate" it as I go along..

I've downloaded the RUU according to my radio and HBOOT version..

Tomorrow I'll be extracting it, for 'hboot.img'..

Will see how tight things are locked down, and then try the exploit..
[HTC Wildfire S] akestrel1987:
Does anyone know of a way to push the newest update to the phone.... my brother in law wants to get the update to fix what ever bugs its fixing
[HTC Wildfire S] rezo609:
Is the campaign dead?
[HTC Wildfire S] #define:
No.. Its not dead, just stalled, because the "main players"(not my words) do not have the WFS anymore.. So they cant do the debugging..
[HTC Wildfire S] no.human.being:
I've passed on the "chainloader" exploit code to a dev team striving for S-OFF on the HTC Explorer. I'm gonna support them as much as I can. The knowledge they gain may prove valuable for the WFS as well.
[HTC Wildfire S] #define:
Actually there's no team.. Its just me... Turns out people are not as interested in S-OFF as I thought they'd be.. Not yet atleast..