yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] djpc:
i have tried it with the latest OTA but the htcdev unlock is still not working, dont know the hboot version as it is my brothers phone but ill find out later
[HTC Wildfire S] d33ps1x:
The OTA update is the hboot in my sig...And no it doesn't work.
[HTC Wildfire S] BeciMester:
I have just tried myself, doesn't work with 0.90 hboot (command error).

By the way, the latest OTA update which brought the phone up to 2.3.5 and the new lockscreen, didn't change my hboot. It was a stock unbranded WFS bought from CPW Ireland, factory unlocked but S-ON.
[HTC Wildfire S] *se-nsei.:
Looks like it's still a no from HTC then :o
[HTC Wildfire S] ONeill123:
I have update my phone with official ruu, but no new hboot, but in the rom.zip is the new hboot. I dont know by with creteria th hboot updates :(

How i can flash the eng hboot.nb0
[HTC Wildfire S] ash98:
Anyone tried HTC Supertool? People report it working on HTC Wildfire S...Tried it myself, didn't work but I think i was doing it wrong :P
[HTC Wildfire S] *se-nsei.:
supertool does not work with s-on. It can give you temp root and no more.
[HTC Wildfire S] ONeill123:
Have anyone tried this:

http://xdaforums.com/showthread.php?t=1416015
[HTC Wildfire S] *se-nsei.:
Not reported working yet.
[HTC Wildfire S] ONeill123:
Can u test it now? I can tommorow evening :(
[HTC Wildfire S] *se-nsei.:
Sorry, my bad. It's been tested by a couple of people, not working.
[HTC Wildfire S] pihug12:
Using this method (with the given 'ndk-comp' script), the code compiled with success !

I used an "old" version (4b) of NDK : dl.google.com/android/ndk/android-ndk-r4b-windows.zip

It's the version used in the tutorial. I had problems with the most recent one.

I didn't have to change a thing in the PATH.

I attached the compiled code with this thread for proof only. I added an .apk extension to become able to share it but I don't know if it's the true extension for this file. With the right chmod, it can be launched with none.

Do

NOT

try this executable. It's too damn dangerous.

Take a look at these screenshots if you want to dig this deeper : i.imgur.com/U37no.jpg & i.imgur.com/ZPfRl.jpg
[HTC Wildfire S] sythe179:
any word on above post?

seems maybe kinda legit?...

but isent there a peoblem with setting read-write privs with a read-only sector?..
[HTC Wildfire S] :
hey guys i thought you may want to try this out. I think it looks promising, and the ruu has an exploitable hboot.

http://xdaforums.com/showthread.php?t=1416015&page=10

check my post for proper instructions that should work
[HTC Wildfire S] :
The new XDA app is awesome.
[HTC Wildfire S] heavy_metal_man:
im sorry but why? this totally off topic, again. this thread is for development man! we had this argument already......
[HTC Wildfire S] einstein.frat:
you bought the wrong hardware to S-off phone. :D this
[HTC Wildfire S] Antagonist42:
Hmmm even in info says to connect to PC to Update so I'm guessing it does just like all the others, you'll need internet access and it'll update from site like theq86 has mentioned before they need internet access so basically they're all the same thing just updated and re-packaged really. :(

I think the real thing that does it standalone would end up coming out from the warez sites to my best guess :cyclops:
[HTC Wildfire S] no.human.being:
XTC-clip schematics and firmware are already leaked, but the problem is that you will need to get the components (especially the microcontroller that's inside the black box) and manufacture the circuit board and this will only be feasible in large quantities. That's why we strive for a software-only solution (like Revolutionary).
[HTC Wildfire S] munjeni:
Done :)
[HTC Wildfire S] no.human.being:
At the WFS, there are different partition layouts, but they are not dependant on HBOOT version (wouldn't make sense, since HBOOT can be updated independantly, e. g. by the HTCdev unlock RUU and such an update must not change the partitioning of the phone or else system won't be able to boot or access data properly).

We first thought that the partition layout was dependant on RADIO version, since most phones on RADIO-7.53 had one layout and phones on RADIO-7.54 had another, but there seemed to be exceptions to this rule.

To see both layouts, check out this post. The tables on the top of the post are the layout found on most RADIO-7.53 phones, while the tables on the bottom of the post represent the layout found on most RADIO-7.54 phones. Like I said there are exceptions to this rule (no idea why) but they appear to be quite rare.
[HTC Wildfire S] *se-nsei.:
Stay away or stay on topic.
[HTC Wildfire S] munjeni:
Yes, radio expecting hboot partition offset (wfs have 2 diferent model?), so hboot offset/size can not be changed (only if you modify radio), but in hboot for sure you can define/change partition table! In hboot you can see allso all other partition tables (including hboot)! I think you need to find way how to check which phone model/partition is in hboot for diferent phones before you make custom partition patch to hboot...
[HTC Wildfire S] pihug12:
Aren't the different layouts explained in the last Antagonist42's document ?

(part "5.5 Memory configuration and usage for Modem build" - pages 43 to 45)

Some values seem familiar to me (149.252 MB, 155.176 MB...).

This document is kinda cool. Worth a check. :good:

___

It seems there are four configurations for NAND devices :

● USNEKOLYM (UMTS)

* Modem and Apps code + Const data = 149.252 MB

* Modem code + read-only data + read-write data + stack + ZI data = 31 MB

● USNEKMLYM Multimode

* Modem and Apps code + Const data = 155.176 MB

* Modem code + read-only data + read-write data + stack + ZI data = 35.527 MB

● USNEKQLYM Multimode DSDS off – EHRP

* Modem and Apps code + Const data = 154.654 MB

* Modem code + read-only data + read-write data + stack + ZI data = 35.25 MB

● USNEKPLYM 1X-only NAND

* Modem and Apps code + Const data = 141.06 MB

* Modem code + read-only data + read-write data + stack + ZI data = 25.7 MB

USNEK*LYM are for NAND devices.

USNSK*LYM are for eMMC devices.
[HTC Wildfire S] munjeni:
Anyone want to post hboot 1.09.0099 ?
[HTC Wildfire S] mstfkaratas:
http://dl.dropbox.com/u/19453567/hboot_1.09.0099_37fbb7a27f8a.nb0 here it is
[HTC Wildfire S] :
OK then.
[HTC Wildfire S] :
Also, if we develop an exploit, then how will I know which one to use? Because I have that weird memory layout, and I barely understand what stuff you guys are talking about. I'm not that smart. Will I have to examine the hex by myself? It would be an interesting challenge.
[HTC Wildfire S] VigiDroid:
To get s-off using an exploit in hboot would be hard as everyone has a different hboot based on their carrier. For example when I went to s-off my telstra wildfire alpharev-X (now known as revolutionary) would fail as my hboot was slightly different although the same version number. The Dev had to download the ruu for my phone, extract hboot then apply the exploit to it then send me a modified version of the tool so I could s-off.
[HTC Wildfire S] sythe179:
Well, after you know what you have to change depending on specific boot core versions, shouldn't be hard to make ether a script for getting your own of your phone, editing the exploit with what's needed, then finishing the process.

Well..I think anyway.

With adb, not much you can't do with a wittle vb scripting....
[HTC Wildfire S] munjeni:
Partition table in hb1.09.0099:

DCD 0x9D06411C, 0, 0x11F, 0, 5, 0
DCD 0x9D062B94, 0x120, 6, 0, 0, 0
DCD 0x9D062B88, 0x126, 5, 0, 0, 0
DCD 0x9D065CD4, 0x12B, 6, 0, 0, 0
DCD 0x9D065E2C, 0x131, 5, 0, 0, 0
DCD 0x9D0632E4, 0x136, 0x28, 0, 0, 0
DCD 0x9D0632DC, 0x15E, 0x1A, 0, 0, 0
DCD 0x9D0632F0, 0x178, 0x86B, 0, 1, 0
DCD 0x9D062B14, 0x9E3, 0x118, 0, 1, 0
DCD 0x9D06690C, 0xAFB, 0x50, 0, 1, 0
DCD 0x9D062B1C, 0xB4B, 0x4B0, 0, 1, 0
ROM:000729D0 DCD 0x9D062B8C, 0xFFB, 5, 0, 0, 0
[HTC Wildfire S] no.human.being:
Our exploit is designed not to flash an entirely new HBOOT, but instead patch the existing HBOOT that's on the phone. It will even do some (very primitive) "reverse engineering" on the HBOOT to adapt to slight changes. For example it might for example find a function that has moved, as long as the function is referenced somewhere and the reference is still in the same place. Of course this is heuristic behaviour at best and will only work with very slight variations.

When only code is changed that is outside the scope of the analysis performed (e. g. does not have to do anything with security, like different CIDs or something like that), it won't notice at all and should successfully S-OFF. In particular it doesn't check the HBOOT image against say a hash value or something like that. It will just check some version strings and some characteristic pieces of code (mostly function calls) and as long as these are in place it will try to "follow" these calls to the function that checks secu_flag and then patch it.

So say for example you run the exploit on a phone that's already S-OFF via Revolutionary, then probably the exploit will abort since security-relevant code will have been changed by Revolutionary. On the other hand, carrier-specific variations may be fine and if the HBOOT is successfully patched, the carrier-specific code will have "survived". The exploit will not remove it since it doesn't ship with an HBOOT image at all. It only grabs the HBOOT from the phone it's running on and writes a slightly modified version back.
[HTC Wildfire S] Antagonist42:
Not sure if you guys will have seen this site already but probably well worth a look as some work done to do with hboot etc may cut down our hunting time from doing some things from scratch ;)
[HTC Wildfire S] meanmug:
Nice read, should prove useful. I found a lil humor in this statement "Be careful in issuing commands since some can be destructive, such as task 29, which can start a format of critical areas of the device without awaiting further confirmation."
[HTC Wildfire S] no.human.being:
Yeah, good site (and already known). They also host similar pages about Radio firmware and the "Linux" kernel in Android.
[HTC Wildfire S] munjeni:
I thinked about that year ago but I tried many linux distros like debian, centos, live distributions...etc but I not understand how there no "/dev/ttyUSB0" when I connect device to usb port of the linux machine, do you have idea why?

About task... I allways perfom task 29 + task 28 after installing new radio or hboot
[HTC Wildfire S] munjeni:
After looking in https://www.codeaurora.org/gitweb/q...cd63158d09b2faffea988f;hb=refs/heads/chromium found this usefull, allso interested enums, but untested... so any one tried to do something from there? After searching net for release_smem_spinlock found this http://www.nuerom.com/BlogEngine/page/nueSpinLockPatcher.aspx so its allso interesting... what use is of that nueSpinLockPatcher? Maybe we can try something from there?
[HTC Wildfire S] pihug12:
sentence removed

You made great progress ! I hope you will find useful infos talking to the HBOOT or Radio and get some help from the other members of this thread. :)

EDIT :

You're right ! I just send a PM to munjeni.
[HTC Wildfire S] Antagonist42:
Thrown my ACER AMSS .img from the EUU update into IDA and it's been processing it for past 2hrs+....

2am so off to bed and see what I get in the morning ;-) anything I come across you need Munjeni i'll post asap ;-) and if there is anything specific let me know as to be honest you have an old age noob flying in fog operating at this end :laugh:

@pihug12 - better if you private message that kinda info then it def doesn't get broadcast ;)
[HTC Wildfire S] munjeni:
Imei on ubunto paste was fake... thanks in any way!
[HTC Wildfire S] munjeni:
S-off with at@ commands??? See here -> http://xdaforums.com/showthread.php?t=559806

Another one interested with gfree_verify -> http://xdaforums.com/archive/index.php/t-855764.html

If you found some other hacks using at@ please post link here... lets collect here all interesting links! Allso I need links to hboot comands (instead of fastboot... its hboot_usb_plug mode and possible commands!)
[HTC Wildfire S] sythe179:
Thought we already tried that way and failed?..

NHB, didn't we?
[HTC Wildfire S] no.human.being:
As far as I know we didn't. The post states that it requires a serial (RS232?) cable to connect to an on-board UART. I don't know where that UART lies on the Marvel board. In addition, I expect it to require some level-shifting, just like JTAG does, since RS232 works on +/- 12 V levels and I don't think there's such a high voltage anywhere on the board. So no, I don't think we have tried yet, but I could be mistaken.
[HTC Wildfire S] munjeni:
Some tests. For comunication with radio linux machine is not needed! I can do all that commands with two adb conections to device! First connection (window) I used to send special commands, and seccond connection for logging. Steps is simple:

First window:

adb shell
stop rill-daemon

Seccond window (see there all logs!):

adb shell
cat /dev/smd0 &

First window (enable verbose loging by ATV1):

echo 'ATV1' >/dev/smd0
echo 'ATE1' >/dev/smd0
echo 'AT@SIMLOCK?AA' >/dev/smd0

...etc. But I'm not abble to break security, its something like "allready patched security bug by enginers" so these comands I think can do nothing! Warning, be carefull with AT (see gobi commands manual before you going to play with it!) command because will change_radio_and_sim_settings/maybe_brick you device!!!

Other thing. Now interested thing is comunication with "hboot_usb_plug" that I not tested, for these tests I will try on linux machine when I have more time and will let you know... first will try to send "h" command to hboot (that I found in tj tutorial), maybe hboot display all commands like fastboot doing when we sending command fastboot ? or fastboot oem ? ... see page 2807 when I was in hboot mode and when I tried some AT comands, got command error, but I think definitelly hboot mode have commands something like "download" or "h" ...etc... will try again.
[HTC Wildfire S] no.human.being:
@munjeni: I don't think that the "serial over USB" and the "serial UART" connections are equivalent (would be a bit strange, wouldn't it?). Remember that the UART is not brought to the outside of the phone, therefore "less accessible to the end user" and thus more likely to be designed for "engineering purposes" than the USB connection.

EDIT: Ah, now I understand what you're doing. You don't do it via the Radio USB connection, you do it from within Android via an adb shell.

EDIT2: The commands caused the phone to lose connection to the GSM network. However, no output from "/dev/smd0" on the receiving end (apart from some "+HTCUSQ" messages). Did you do this from your ROM or from Recovery?
[HTC Wildfire S] munjeni:
I doing that from adb runing on my computer and my cm9 rom runing on phone...
[HTC Wildfire S] :
Any updates?
[HTC Wildfire S] munjeni:
Hack is possible! But I am not good/familiar with asm... but I understand more and more every day. Look here for hackspl.S, you will see how it is easy (especialy when you have asm knownledge)! Hboot is possible to patch by self! Yesterday I found loading offset (booth for aria and wfs) 0x9d000000 for hboot (is unpacked to that psychical offset on boot???), so I think we can look into hero hboot and compare with hero hack (hsplhack.S) and see how it is done on hero and what that hack doing! On first look in hack I see its loaded by fastboot command boot, than, looking in asm code found: it set arm11 bootloader in unused state, than, it remove memory protection, remove cid protection, patch hboot, enable memory protection, boot back to hboot..., and finaly hboot is patched by self in memory, than, guys use serial console to comunicate with radio in order to finaly remove s-on and to set super cid! Yesterday I played with hboot (not by asm, I use jtag), removed "hboot erase" protection, for test tried "fastboot erase hboot" I erased hboot, reboted phone, got black screen/bricked phone :), using jtag to verify if is erased, yes its erased \0/... will try to do something like htc hero guys done... if some one found which hboot version is used with hack in hero, please give me link for download, I will analyse it and learn from that! I think we can do the same hack, just for idea, we can patch hboot (add brakpoint) in memory (tnen patch hboot erase/write function), remove brakpoint, flash modified hboot... without need to comunicate with radio like htc hero guys doing...
[HTC Wildfire S] :
I read the first few sentences of the post before this. So will this help us?
[HTC Wildfire S] sythe179:
Just let NHB have a look...might have seen this before.
[HTC Wildfire S] munjeni:
Guys... please help me here:

int fixmuldiv2 (const int a, const int b)
{
int result ;
__asm__ ("smmul %0, %1, %2" : "=r" (result)
: "r" (a), "r" (b)) ;
return result ;
}

What is replacement for this code? Got error "Error: selected processor does not support `smmul r3,r2,r3"
[HTC Wildfire S] ratafak_plachta:
I would try using smull and use some dummy register for RdLo.
[HTC Wildfire S] munjeni:
Got it... __asm__ (".ALIGN\n" ".ARM\n"... but if you have better idea please let me know!
[HTC Wildfire S] thelegbra:
an offtopic question but since you guys have taken the device apart, i thought i might get the answer here pretty fast :)

what is the exact model name of the touchscreen controller? we know it's a cypress but a full model number would be awesome!

thanks in advance :)
[HTC Wildfire S] ratafak_plachta:
Just found this:

http://gumstix.8.n6.nabble.com/NAND-bad-block-regression-td559984.html

Could not be our problem, that we cannot erase flash because we use 2.6.35 kernel?
[HTC Wildfire S] :
Well. That could be a problem.. its nothing like New HTC write protected phones ill tell you that for sure.
[HTC Wildfire S] Happytobefree:
Hi guys,

I stumbled upon this via Google when looking for a means to S-off a GSM (UK) Wildfire-S.

I need to do so because my touchscreen is very unresponsive, and I located a fix that requires the phone to undergo "TP calibration".

ONLY - this process is prohibited by security! I.e. S-on!

So if anyone needed additional reasoning for this entire campaign then here is yet more motivation for the cause.

I hope you guys are close to the solution now. I don't want to fork out for an XTC clip but sadly I'm nowhere near proficient as I need to be in programming to contribute anything useful :(

Good luck :)
[HTC Wildfire S] no.human.being:
It appeared as if we were already very close, but I now have reason to believe that one of our fundamental assumptions, that the addresses that the kernel's mtd driver sets off are actual physical addresses on the NAND, was wrong. I think that the system-on-chip itself has a low-level firmware, similar to the "micro program" that was used in certain processors decades ago, running, which in turn is running the "device firmware" in some kind of "virtual machine" with at least memory virtualization and scheduling provided, but there might actually be even more trickery going on.

Unfortunately I don't know what this low-level firmware is actually doing. I think of it as some kind of "hardware-assisted Class 1 hypervisor" providing separate address spaces for exactly two operating systems (the Radio, which is an L4/Pistachio kernel and an Iguana operating system, as well as Android, which is a Linux-based kernel) running side by side on shared ressources. The hypervisor is almost completely transparent to the device firmware but is obviously very good at shielding the operating systems off from each other. I think that in order to break security, we must understand how this hypervisor operates and for this we require JTAG access to the processor.

I have JTAG equipment availble here, but the phone's processor is running on an extremely low voltage of 0.9 V. In order for the JTAG interface to talk to the processor, I think I have to "shift" logic levels from and to the processor up and down in an appropriate way. I haven't found any 0.9 V <--> 3.3 V logic level shifter for JTAG yet, so I think that it will require custom-built circuitry, which is obviously quite an effort to design and build.
[HTC Wildfire S] heavy_metal_man:
Seems like we have hit quite a wall here... Also, my friend backed down from me clipping her phone. She said she didn't want to risk her warrenty. Sorry guys :(
[HTC Wildfire S] csoulr666:
I think we might just have the wrecking ball we need for the wall.............thanks to you of course

This time i understood almost everything you were trying to say......so i hope your plan works
[HTC Wildfire S] no.human.being:
Well it doesn't boot. It downloads the boot image via Fastboot but then boots into the ROM that's on the phone. I think we have to fiddle around with the header of the boot image to get the code loaded into the right place. "Obvious" values like 0x00000000, 0x00000080, 0x8d000000, 0x8d000080 don't work. We might have to "offset" them by some amount so that execution starts at the right instruction or physical addresses coded into the HBOOT image hit the right places. Let's hope that BeciMester can shed some light on this.
[HTC Wildfire S] BeciMester:
Hboot expects to be loaded from 0x9d000000, it contains quite a few hardcoded addresses in that region. Dunno if you need the entry point too, anyway it's the same (the first few bytes of the hboot is a jump statement to its own init code inside). See if that works.

(I'm on my One X...)
[HTC Wildfire S] DarkDr0id:
Spare me if im wrong or my info is incorrect but droif incredible got s-off without xtc clip........some one could look at it coz i really don't understand what's written :p

The link
[HTC Wildfire S] no.human.being:
No, it always boots into the ROM after issuing the Fastboot command. The image that's passed via Fastboot either doesn't seem to get executed at all or it gets executed, then recognizes that something's not the way it's supposed to be and then loads the ROM. Without JTAG access we obviously can't see what's actually happening on the device other than that at some point the regular ROM gets booted in some way.
[HTC Wildfire S] heavy_metal_man:
Unless I've been linked to somewhere else this link is a Total waste of time. April fools jokes?? Come on its July, at least try. Fml
[HTC Wildfire S] artturnip:
You guys really seem to be working hard on this s off attempt.. hope you get something that works! :D