yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
In an NBH file, before the actual data, there's always a small header consisting of a 32-bit word which tells how much "payload" data follows and another 32-bit word which tells how large a signature follows. (The latter will usually be 128, since 128 byte = 1024 bit RSA is used as asymmetric cryptosystem.)

The signature is a hash of the chunk of payload to which it belongs, RSA-encrypted with HTC's private key. A simple hash would not provide security against unauthorized modifications of the payload, since you could recompute it after performing the modification. However, you won't be able to encrypt the hash to create a valid signature since you don't have HTC's private key. HBOOT has HTC's public key so he can "reverse" the RSA encryption (but not RSA-encrypt itself, since that requires the private key) obtaining the "plain text" hash. Then it compares the hash obtained from RSA-decrypting the signature against the hash it has computed from the chunk of payload on its own. The signature will only match if the payload has not been modified.

After every chunk, the next header follows, which states how much payload and signature follows and so on until the end of the image. Radio images are usually secured this way. This also applies to Radio images contained in RUUs, since they are handled by the same mechanism.

Btw: Do we know which hashing algorithm is used? SHA-256 would be a good guess, since efficient implementations for 32-bit processors exist for this hashing algorithm.
[HTC Wildfire S] munjeni:
Did you have htcdev hboot? I think cracked hboot is installable trought htcdev hboot... see this thread -> http://xdaforums.com/showthread.php?t=1528808&page=2
[HTC Wildfire S] Antagonist42:
Info I've come across when I've Bintext has had Sha-1 I think, I can't check at the moment as windows trashed my NTLDR again lol, I'll check as soon as I can ;)

Rooted Xakep E320/C6 EUU Hacked Update
[HTC Wildfire S] munjeni:
What is min and max hboot version that exist for WFS ?? For example min 1.00 and max 1.89 ?? I want to try an in htc aria, maybe it will work in htc aria. Do you have link to an jtag dump for wfs ?
[HTC Wildfire S] tacromx:
im uploading to 4shared now for you, im on slow connection.... maybe 1:30 hours

let you know when its ready.
[HTC Wildfire S] :
Don't mind me. I'm slooooowly rotting away while we try to get S-OFF.
[HTC Wildfire S] theq86:
for gsm wildfire s there exist following hboots:

HBOOT 0.81.2000 (eng hboot)

HBOOT 0.90.0000 (exploitable hboot)

HBOOT 1.03.0000

HBOOT 1.08.0000

HBOOT 1.08.0099 (first htcdev unlockable hboot)

HBOOT 1.09.0099 (current htcdev and standard hboot)
[HTC Wildfire S] tacromx:
@munjeni

here is the link or here

full dump of A510E (s-on) from nand, found via this thread
[HTC Wildfire S] vbhtt:
I have seen a few users with bricked phones i.e. they get a blank screen with a flashing backlight just after running an ruu. I believe this is because the ruu did not run properly and flashed a corrupt radio. So if it is possible to flash a corrupt radio, then it is also possible to flash a modified radio. (I may be wrong. If it is wrong, could you tell me why this happens?).
[HTC Wildfire S] meanmug:
Right and wrong sir, at the moment it is only possible to flash a signed ruu, unsigned ruu's wont pass verification.
[HTC Wildfire S] Antagonist42:
I flashed in the Malez boot to gain root, afterwards phone wouldn't boot so the installed boot doesn't pass bootloader security, as for radio if 1. It wasn't for their model like as with say xperia x10 mini and pro they can have differing internals. 2. If radio is updated but not the android system the security between them won't match (I have this but other way round so I cannot flash the latest EUU or the edited EUU that gave me root access).

Maybe some bricked phones may accept the original complete flash not any of the later updates, possibility it may work but I'm no expert lol ;)

Rooted Xakep E320/C6 EUU Hacked Update
[HTC Wildfire S] vbhtt:
A corrupt radio's md5 should not match with the original md5 right? So how did the ruu allow it to flash?
[HTC Wildfire S] meanmug:
I've followed this thread since the beginning and I don't think there ever was corrupt radios, those where people flashing gsm against cdma and vice versus. If the ruu was corrupt it would flash at all. I think everyone here would tell you that signature verification has been our enemy since the beginning.
[HTC Wildfire S] ctt812:
The S-off quest is so difficult even if we have a patched hboot by nhb. I think it's because we can't flash the hboot that cannot passed the signature verification, right?!

The HBOOT 0.90.0000 is an exploitable hboot and it's definitely signed by HTC. Is it not possible to flash this hboot to s-on wfs even it's an official one? Is that because the stock recovery don't allow flashing an hboot with outdated version number? If we can flash it, probably we can use the offical ROM1.zip to s-off the device.

Can we temp-rooted the wfs to edit the original hboot version number to an arbitrary one e.g. 0.80.0000 and let the HBOOT 0.90.0000 official hboot to be flashed?

Sorry for asking about all that silly questions, I don't know much about all that..
[HTC Wildfire S] theq86:
It's so hard because no way to flash a hboot does work for us. We can not generate a valid PG76IMG signature for flashing, we can not write the memory area where hboot is located and we can not flash it via fastboot.

No, we can't. Wether it's "official" or not. There is no way to flash an hboot nb0 file on an S-ON device unless we package it into a PG76IMG with correct signature

Stock Recovery has nothing to do with it. It is hboot or some radio part that bypasses bootloader installation. I just know that since hboot 1.03.0000 it is no more possible to downgrade below this version no. Probably HTC knew that 0.90.0000 was exploitable. So no matter how you try, as long as you are S-ON you will not be able to revert to hboot 0.90.0000. Hboot will state it "bypassed" the installation.

Yes, at least temporarily. But we will not be able to use fastboot flash and boot commands anymore. Because 0.90.0000 does not include many fastboot commands. If we were to upgrade to 1.09

.0099 i.e. we would loose S-OFF because newer hboots are aware of the "new" secu flag location. This is why we try to patch a htcdev hboot to s-off.

No, we only have access to the so calles "main version number" that makes a RUU decide wether it installs or not. Hboot version check is made by hboot itself. We have no way to change the hboot version.
[HTC Wildfire S] Antagonist42:
What you can do is run an EUU/RUU but halt it's process before it actually flashes anything to the phone (halt as in use say sysinternals process explorer on windows and suspend the updaters process once phone reaches fastboot) then flash your hboot etc, the phone has been connected using authentic software, the appropriate pid and USB ports are connected (different pid's and ports used for fastboot and recovery etc. Including qpsd & qdmx) the thing the installed item will fail on is it's own or against system signature from what I can gather.

Running the Malez exploit on it's own had no effect but interrupt the EUU it installed but failed security to boot

Rooted Xakep E320/C6 EUU Hacked Update
[HTC Wildfire S] no.human.being:
Not yet. Obviously HBOOT itself can write and it runs on aARM, just as we do. When we find out how it gets write permission, we should be able to gain write permission as well.

I don't think that HBOOT actually checks the location. The Radio has an AT command for reading the secu_flag status and I think that HBOOT calls this command. I think that the secu_flag is in one of these areas that read as "0xff" from aARM but contain valid data when read via JTAG and HBOOT won't be able to read these areas, as he's running on aARM and will just read "0xff". I think it does the AT command, the Radio will read it and return the value.

Now the question is what DIAG does. If it's DIAG itself that queries the smartcard and then somehow "authenticates" with the Radio and causes it to turn secu_flag off, then we have to figure out how the "authentication" works and be able to gain true Radio S-OFF this way.

However, if DIAG just tells the Radio "turn secu_flag off" and then the Radio queries for the smartcard to decide whether to actually disable it (which would make much more sense from the security perspective, since the Radio is much more protected than HBOOT itself running on the mARM with all the MMUs and stuff between it and the aARM) then this isn't an option either.

I think the best option is by tracing through the device's initialization. I don't know what we will see this way, whether it reveals the "chipset internal" boot code like PBL, DBL, etc. as well or whether JTAG is only enabled after these are through (after all it could be that the debugging stuff is not all in hardware but in some kind of "micro program" of the processor and requires the processor to be set up before it can operate), but we'll certainly be able to see HBOOT booting and we might be able to see the Radio booting as well and we'll be able to trap the processor, alter its state (e. g. contents of memory, registers, etc.), then resume and see how firmware "reacts".
[HTC Wildfire S] Antagonist42:
One thing I have read in Qualcomm docs is for a call to GPIO95 (or 93 check document on Q-Fuses and Security) as this is the control for enabling security either way if security is enabled via Q-fuse by vendor I think

Rooted Xakep E320/C6 EUU Hacked Update
[HTC Wildfire S] tacromx:
i agree, read the same thing and came to same conclusion
[HTC Wildfire S] munjeni:
Thanks for link to jtag dump, I will try to boot wildfire dump in my htc aria and if aria can boot I will try hboot.1.02.0000 from htc aria (only one exploatable from revolutionary tool) and will try to use revolutionary exploit... and will let you know . So if hboot from aria work in wildfire you will be able to use revolutionary tool (maybe :D)... but its not what we want ? We want to learn how to break our security:mad:
[HTC Wildfire S] heavy_metal_man:
Surely that's a really bad idea? Trying to run a different phones hboot on yours? I can see that going very wrong :confused:
[HTC Wildfire S] theq86:
With jtag he can restore his original hboot at any time. So thats no risk.
[HTC Wildfire S] no.human.being:
I'd suggest dumping the entire NAND via JTAG though. Remember that HBOOT contains the "partition tables" (even though they're not real "partition tables" in the sense you can find them on for example a hard drive on a PC, but just some addresses in HBOOT's code that then get "passed around" to every component that needs to know the partitioning, e. g. the Android kernel) and I can see other components attempting to mount partitions as read-write that aren't actual where the device's partitions are in NAND. Possibility for desaster. :D
[HTC Wildfire S] munjeni:
Do you know which offset in hboot is for partition layout? You have it in disasembly ?
[HTC Wildfire S] no.human.being:
You can disassemble the HBOOT using the "objdump" utility from the CodeSourcery "arm-none-linux-gnueabi"-toolchain or any compatible ARM disassembler.

I don't know where and how the partition layout is stored inside HBOOT. BeciMester did the bulk of the HBOOT analysis part. Don't know whether he "stumbled upon" the partition tables though.
[HTC Wildfire S] heavy_metal_man:
any updates guys?
[HTC Wildfire S] no.human.being:
Still no Torx T5 (but it's already ordered), so no JTAG access yet. Don't worry, I'll keep you updated.
[HTC Wildfire S] tacromx:
JIG

Save soldering the board, have a look at this

Just came across this too
[HTC Wildfire S] no.human.being:
Already got the exact same JTAG adapter.

MSM7227 is not mentioned.
[HTC Wildfire S] munjeni:
My adapter http://img85.imageshack.us/img85/9687/img0974z.jpg ...to Seger Jlink jtag in 5 minute :D .. just to give you idea and to give you better thing when you going to work with phone that is not need to disasemble again and again ;)... when jtag is not needed I easilly hide wires under battery :)
[HTC Wildfire S] Antagonist42:
OEM - OEM and S-ON/OFF

So to begin...

just who is making the phone you're using?

What is it that is updating and making a phone S-ON?

Why would we have an unlocked bootloader if the phone is still S-ON?

Ok I have one or two differences, my phone is the ACER C6 and not the WFS although a few things to clear up... The HTC Wildfire S is made by HTC as it is an OEM, the ACER on the other hand is a ODM made by CCI this is something I had to find out as the motherboard in the ACER is the HTC ChaCha and after using Zakep Root EUU Flash it had installed the CCI DEV TOOL which gives you allsorts to look at and give info on. After catching this post meant the ACER was at least bootloader unlocked at Acer_E320_1.008.00_EMEA_ORGUK but subsequently locked at Acer_E320_1.013.00_EMEA_ORGUK so who was it that locked it?

In my case the Service provider wouldn't be locking anything down as all they are really bothered about is you using your phone, this leaves one of two remaining, either the phone manufacturer or the parts manufacturer, seeing as it is unlikely that HTC would collaborate too closely with ACER as to how to boot a machine and secure it (I think ACER can manage that on their own) and on a public awareness front Barclay's Bank have ran TV adds for what they're calling 'Pay Tag' (essentially a TAG sticker that uses NFC) for older mobiles, not just that but if you can do >this< with NFC then it has to be locked down I guess :D until they can make it secure LMAO.

This seemingly leaves Qualcomm to do the locking down, and as they to a certain degree 'KNOW' how the chips operate seeing as they produce the basics and how the chips are programmed then where would their update be? Easy really, it must be in the AMSS/Radio update, this is the last part of the phone that Qualcomm really have any continued interest in which is the wireless/radio transmission, this would be updated to keep up with any new updates to the NETWORK OPERATORS SYSTEM and our phones make the best use of them. Seeing as NFC is transmitting through airwaves and has to be secure (system cannot influence it) it would fall under AMSS and not Android's control, we use it the same as making a phone call, the fact that it's compromised itself already the only people that really can lock it down would be Qualcomm as they (excuse the pun) hold all the keys - even the NAND Q-FUSE Keys so that they can do all the Testing that say HTC/ACER/etc would want to test (some tests I guess would give away Qualcomms info so they protect it and test it for you).

Essentially all we need to figure out is what exactly is the S-ON/OFF key, all previous posts seem to point to a location or key or possibly the right chip pulling up the correct voltage on the right chip and that would make it open house for us.

Now I just hope my basic view on this is a little helpful ;)
[HTC Wildfire S] munjeni:
Hey, after searching for htc photon rpc server for battery I found usefull kernel msm_proc_comm function with a lot of unused/mising/hiden (why?) comands... what you think when you compare kernel proc com ws https://www.codeaurora.org/gitweb/q...cd63158d09b2faffea988f;hb=refs/heads/chromium ? I think legacy bootloader proc com have more usefull infos than proc com inside kernel
[HTC Wildfire S] Antagonist42:
Hope this will come in very handy ;)

MSM7200 Software Interface Manual 80-VA736-2 Rev B Dated Aug 2 2006

6.99Mb of pdf has gotta have something useful in it :D

Find them all here > found docs <

Happy Reading ;)

munjeni, no.human.being, theq86, tacromx you may want to check out page 295 to do with EBI2 NAND controller registers :eek: :D about 124 pages just on NAND access ;)
[HTC Wildfire S] digital_sarma:
der devs, with all due respect to your attempts to s-off i only have one (stupid) question. why would we have an s-off if the phone is rootable with s-on (marvel and marvelc)? please don't get me wrong i deeply respect all the work done here, it's way beyond my knowledge, peace
[HTC Wildfire S] Antagonist42:
If I understand this right.... S-ON with an unlocked bootloader and able to give you su/superuser is all well and good although your phone is capable of more....

With S-ON and an unlocked bootloader I still don't think that at the moment you can alter the size of the partitions, you cannot alter the memory your phone uses to say give you more apps usage and minimal kernel usage, besides these you are not able to flash in and use another Android operating system that may run better on this phone or say flash in M$ Windows OS (why you would I have no idea :D ) As I have found with my phone even installing superuser via any means possible other than a seriously edited update becomes impossible so restricting your phone for your own basic usage.

I may be slightly off with what you can and can't alter on the system but if you can't even get superuser on a phone because of S-ON then it needs hacking ;)
[HTC Wildfire S] no.human.being:
My goal is to get rid of all proprietary software on the phone. I want to create an entirely open Radio build from the sources of Pistachio and Iguana and slap an entirely open bootloader, UBOOT, on. Currently, the Radio firmware can't be reviewed by the community for security vulnerabilities or deliberately placed backdoors, creating a potential security risk for private communication. I've once seen a live demonstration where someone turned an Android phone into a wiretap by connecting to it over the cellular network, injecting malware into it, which engagind hands-free mode on the device and streamed the recorded audio over the data connection to a server on the internet. On the phone, apart from higher battery drain and bandwidth use, you won't notice anything. It will just normally show the homescreen and let you interact with it. I'm quite certain that such backdoors exist in lots of proprietary firmware components for "law enforcement" purposes, and, while you can say that you're a law-abiding citizen and got nothing to hide, there's certainly potential for abuse either by authorities themselves or by third parties should the keys be leaked. With open-source software, it's so much easier for the community to review the firmware for malicious code and much harder for the developers to hide something in it.

Basically, Android itself is open-source, since it's based on Linux and the GPL license requires "derived works" to have their source published. But Android depends on proprietary components so much that, without them, it's basically completely useless. Android cannot boot without its bootloader, which is under NDA, and it cannot function without Radio firmware, which is also proprietary. And these proprietary components cannot be publicly reviewed for security or modified to suit the customer's needs.

Now what I want to do in the long run is replace all the proprietary dependencies with open-source equivalents. In particular, I want to replace Qualcomm's (and later other chip manufacturer's) Radio build with a "clean room" build from the Pistachio and Iguana sources, and replace the proprietary bootloaders with UBOOT, the bootloader of Embedded Linux, ultimately creating an entirely Free Software Android build that "hackers" and phone manufacturers alike may take and customize for their particular device without depending on Google for licensing their proprietary components to them.
[HTC Wildfire S] einstein.frat:
whats the difference of desire's hboot partitioning and Wildfire s recovery mtd partitioning Ive seen it in desire threads some need it like data2ext? can you make one? I have no idea.

edit Ive seen

cm7r and stock :confused:

also my ps3 is 4.11 do you know how to downgrade it or hack it? :(
[HTC Wildfire S] einstein.frat:
must be a hoax script, try other scripts.
[HTC Wildfire S] Antagonist42:
This may be worth a look into as is the MSM7227 (LG Optimus GT540,has one sat around as spare) it's short thread but...

In this message I will try to summarize what we have so far...

[1]
myk777 was able to establish an LTP <-> JTAG connection via the wiggler. Here are the connections he made:
i.imgur.com/vUdUV.jpg

[2]
He also identified the to be ARM1136 with the tap ID 0x203c00e1.

Think they gave up and sent it in for repair :confused:
[HTC Wildfire S] tacromx:
yes.... tap ID 0x203c00e1

PDF
[HTC Wildfire S] no.human.being:
Sure that Tap ID is not 0x00000000? If I use 0x203c00e1 I get additional error.

Warn : JTAG tap: ARM1136EJS.cpu UNEXPECTED: 0x00000000 (mfg: 0x000, part: 0x0000, ver: 0x0)
Error: JTAG tap: ARM1136EJS.cpu expected 1 of 1: 0x203c00e1 (mfg: 0x070, part: 0x03c0, ver: 0x2)
[HTC Wildfire S] Antagonist42:
May be of some help but needs translating from Russian

And another pdf grabbed of Lauterbach Dev Tools
[HTC Wildfire S] *se-nsei.:
your ps3?...
[HTC Wildfire S] tacromx:
TAP ID: 203C00E1, IR Length = 4
[HTC Wildfire S] no.human.being:
Cannot set "-irlen 4":

Error: 'target arm11' expects IR LENGTH = 5
[HTC Wildfire S] tacromx:
@nhb

can you please post specs of your setup and os, interface used etc?
[HTC Wildfire S] Antagonist42:
This site looks like it could have info needed for JTag but need to register although not sure it's same set up etc?

This could be of interest later:-

07.07.2011 HTC Wildfire S A510E (HTC Marvel), More CDMA models supported.

Resurrecting HTC WildFireS is easy. Phone is auto powered on with USB Data Cable connected to the PC. Battery presence is not required; connection can be established with detached board.
In case you have no USB cable near, make sure battery is charged enough and hold Power On button during initiation of JTAG connection.
Resurrector will reflash radio’s boot zone and will re-write PDA’s SPL to 1.01.0002 version. Additionally to SPL and Radio zones, the zone which contains Model ID is re-flashed too. Thus after resurrection phone will have Model ID = ‘PC4910000′. Additionally, you can check ‘Repair RECOVERY zones’ to reflash android BOOT and RECOVERY code.
To resurrect HTC WildFireS:

Solder JTAG cable to HTC WildFireS JTAG pads;
Insert USB Data cable into board and PC;
Make sure HTC WildFireS is selected in the list of models;
If you use battery, press Power On key;
Click Resurrect button;
Wait till software signals a successful operation completion;
Disconnect power supply, de-solder JTAG wires;
Now phone is in bootable condition, that is, even if it does not start up normally, you can flash it using known flashing methods.
To enter download mode:
Disconnect PC cable;
Insert battery;
Hold ‘Volume Down’ key and press ‘Power ON’ button. In few seconds you should see usual android boot mode screen.

from here...
[HTC Wildfire S] MindBurn010:
XTC Clip ?
[HTC Wildfire S] ONeill123:
Yes with xtc clip, its the onliest way yet to set s-off.

Thanks for that. Help the devs here find a way.

Which commands you use to create this files? I have still s-on and can create too and upload. After this the devs can look for differents in files.

To the custom ruu:

Maybe we can flash a custom recovery with that. Or a custom radio? With s-off.
[HTC Wildfire S] y0da89:
I was in a shop and it costed me 15€.

The guy used a XTC Clip but he didn't tell me how to do.

He created a Goldcard and after that I got these two files on my SD Card
[HTC Wildfire S] ONeill123:
Hmm, bad, maybe any other know the command?!