yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
When doing certificates/digital-signatures right, you do the following.

1. You create an RSA key pair consisting of one "public key" and one "private key". They are both created from the same "seed values", which are then destroyed. You can only derive the public and private key from the seed. There is no (efficient) way to derive the private key from the public key. This is an important property of an asymmetric cryptosystem. There's also no (efficient) way to do it the other way round, but this property is not that important. Information which has been encrypted with one of the keys can only be decrypted with the other. This is also a key property of asymmetric cryptography.

2. You create a hash-value (e. g. SHA-1 hash) from the data you want to sign (e. g. a ROM image).

3. You encrypt that hash-value using your private key. This encrypted hash-value is called the "signature" and you append it to the data you want to sign (e. g. the ROM image).

4. You deploy the signed data and the public key. The private key is kept secret (that's why it's called private).

5. The software checking the signature (e. g. HBOOT) also creates a hash-value (e. g. SHA-1 hash) from the data it wants to verify (e. g. a ROM image). When the ROM image is the same as it was when the signing was performed, the software will generate the same hash-value as the signer did in step 2. When the ROM image has been altered, the software will very likely generate a different hash-value.

6. The software decrypts the signature that the signer created in step 3 with the public key the signer deployed, obtaining the SHA-1 hash of the original image.

7. The software compares the SHA-1 hash derived from the signature with the one it has created from the signed data itself. When both hashes match, the data most likely has not been tampered with. When they don't, the data has been tampered with and is discarded.

So the information that is neccessary to create a valid signature is HTC's private signature key. For verification purposes, this key is never required, so it will not be included in the original HBOOT for example. Verification only needs the public key and the private key cannot efficiently be derived from the public key. When you modify a signed image, the signature obviously invalidates, as the hash value of the image changes and you cannot sign the hash of the modified ROM as you haven't got a signature key to do so. After all that's the purpose of signatures. If they stayed valid when the signed data changes, they wouldn't be of any use.
[HTC Wildfire S] sythe179:
Change the key on the hboot to the Sig that is generated when you put an s-off version in?
[HTC Wildfire S] ONeill123:
You can't change the key without the original sign rom.

An RUU will Update the signature database of the phone, but the RUU has an sign rom ;)
[HTC Wildfire S] no.human.being:
@*se-nsei.: You can take out the top quote of the "LATEST CONCLUSIONS" section. It's quite .. erm .. outdated. We are moving closer. There's already C code here for software S-OFF. It does the "variation 1" mentioned in the post you quoted below. However, I'm still looking for a suitable toolchain to compile it for Android/ARMv6. I'm not sure if I got all the offsets right and I couldn't test it yet, as I haven't found a suitable compiler yet, so this is not for the faint-hearted and I do not take any responsibility if this bricks the phone. You must run zergRush first and get a root shell open before the S-OFF can be applied, otherwise I'd expect you'd get some permissions problem.
[HTC Wildfire S] *se-nsei.:
No problem, I'l update it in a bit. :)

Do you want me to change the thread title also?
[HTC Wildfire S] m1ndh4x8r:
sorry invalid link. you need ndk.
[HTC Wildfire S] no.human.being:
I used Android NDK r7 and this AGCC script. Modified the "my $DROID" variable inside the script to reflect the location of my Android NDK install, and added "~/Downloads/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin" to the $PATH.

Getting lots of compile errors.

arm-linux-androideabi-gcc: /home/x/android-ndk-r7/platforms/android-3/arch-arm/usr/lib/crtend_android.o: No such file or directory
arm-linux-androideabi-gcc: /home/x/android-ndk-r7/platforms/android-3/arch-arm/usr/lib/crtbegin_dynamic.o: No such file or directory
arm-linux-androideabi-gcc: /home/x/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/lib/gcc/arm-linux-androideabi/4.4.3/libgcc.a: No such file or directory
In file included from test.c:1:
/home/x/Downloads/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/stdio.h:50:23: error: sys/cdefs.h: No such file or directory
/home/x/Downloads/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/stdio.h:51:24: error: sys/_types.h: No such file or directory
In file included from test.c:1:
/home/x/Downloads/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/stdio.h:163: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'extern'
/home/x/Downloads/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/stdio.h:232: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__BEGIN_DECLS'
/home/x/Downloads/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/stdio.h:382: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__BEGIN_DECLS'
/home/x/Downloads/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/stdio.h:393: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'static'

It's not that there is something wrong with the code. "Standard" GCC perfectly compiles the code. Why do we need this agcc wrapper around it anyways? Isn't there a standard "one-command" compiler for ARM that does "cc source.c -o binary" like any standard C compiler does?
[HTC Wildfire S] breaky9973:
I honestly only have little experience with programming (HTML, Javascript) but I do know I test with as little as code as possible first.

So if you feel some code is not needed...take it out and see what it does...

Also (but I assume you already did) I would find as many examples of code for other HTC phones for gaining S-OFF.
[HTC Wildfire S] BeciMester:
@being: check your output, most of your errors are path related, it seems that some paths are included twice. You can set them at lines 50-55 in the script. I'm looking at the same stuff on windows, will post results this afternoon.
[HTC Wildfire S] breaky9973:
http://android-tricks.blogspot.com/2009/02/hello-world-c-program-on-using-android.html

A link explaining a little about the use of AGCC, maybe could be handy.
[HTC Wildfire S] :
I just want to clear up some misconseption here, Virgin Mobile is in fact CDMA. It is owned and opperated by Sprint PCS and uses their towers. The reason CDMA phones can be soffed is because there is no port for the xtc clip to interface with, so when the files look for simcard it just skips and keeps going. This actually caused some corruption in the misc.img but 2fast4u88 fixed that. Its seeming like development is getting there on the GSM varient, but still no software support. I am a learning dev, im still quite new here, but i have a theory. We should take the files from the CDMA process and modify them to not check for the clip, this will in turn Soff the devices, but not unlock like xtc clip will. Next after that we will just have to make a goldcard. First, of course we should temp root and pull the misc.img, as that will get rid of weird errors well encounter later on.
[HTC Wildfire S] ash98:
Hey guys, we need to try this out ASAP if we havent already!

http://m.lifehacker.com/5871759/htc...-old?utm_medium=referral&utm_source=pulsenews
[HTC Wildfire S] Lt.Win:
Afaik, the cmd to get the identifier token is not supported by our phone. WFS was released PRIOR TO September 2011. So, unlocking chances are close to 0. However, trying it out isn't a problem. I can't try it out now, I'm on my phone. Good luck.
[HTC Wildfire S] AmberLynn:
Will this give s-off in the end?

http://androidcommunity.com/all-new...bootloaders-dont-ask-verizon-or-att-20111228/

Thanks,

best regards

Richard
[HTC Wildfire S] Lt.Win:
It will remain s-on, but custom Roms and root will be available.
[HTC Wildfire S] ONeill123:
I have one question:

How i can flash the eng hboot?
[HTC Wildfire S] no.human.being:
Host is a Fedora 17 (x86_64) on Linux 3.4.0 kernel.

OpenOCD is version 0.5.0 pulled from their repository ("yum install openocd").

JTAG interface is an ARMUSBTINYH from Olimex. It's a very simple box with USB connector on one side, 20-pin JTAG on other side. Inside is just a circuit board with an FT2232H UART from FTDI.

From the box I use a standard 20-pin ribbon cable to the JTAG adapter and adapter contacts the board. I use two clothes-pegs for pressing the pogo needles of the JTAG adapter against the phone's circuit board.
[HTC Wildfire S] tacromx:
Thank you.

Try

ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID

you might also want to try this

you can do a scan on the chain just to make sure your connections etc are all good.....just a thought ; )
[HTC Wildfire S] digital_sarma:
so, does installing custom roms and firewall help preventing this things to happen at all? (tapping, malware injection etc)

mine (wildfire s) is s-on, unlocked bootloader, su privileges, cm7 on it...:confused::D

anyways, great work
[HTC Wildfire S] Antagonist42:
Are you sure? I would have thought that result means you have 1 of the 3 needed, UNEXPECTED kinda wasn't expecting to get 00000000 whereas expected 1 of 1, well it's got 1 right it's just not gonna say which of the 3! :mad:
[HTC Wildfire S] no.human.being:
So we have to connect the phone via USB to the computer while using JTAG on it? I expected the JTAG interface to power the CPU.

I'm not sure, it's just that the error message disappears when setting it to 00000000.
[HTC Wildfire S] Antagonist42:
>>>THIS HERE<<< could be a problem not seen with a simple change of one opt/cmd

This does not work and complains bout the line "reset init"
Note that I am using the new target/stm32.cfg renamed to target/stm32_tp.cfg . The "tp" denotes transport.

If I change to using target/stm32.cfg from the stable version of openocd it downloads successfully and flashes the led.

I am attaching a versaloon_test.zip of everything that I am using which includes a -d3 log. There are three -d3 .txt files for
swd works, jtag fails and jtag works.

Not sure if we're getting to that but if it is a 'transport' code out but we just wanted to see it, would that make a difference?

=============================================================================

Oooh this... searched googlies for 'tap device found' so here's a wiki for it
[HTC Wildfire S] no.human.being:
Not our processor and not our board. We're not on an STM32.

Munjeni got JTAG working with his phone. I think he can give us more insights.

Do you think we need to power the phone while we have the JTAG on? It seems like the chip is somehow responding, since you get an error earlier in the JTAG initialization process if you disconnect the interface from the board, which would indicate that power is provided via JTAG, but your source says you should put the battery in or supply power to the USB connector.
[HTC Wildfire S] tacromx:
silly question....have you power up the Phone?... to hboot?
[HTC Wildfire S] Antagonist42:
USB you could just be using it for power not connected to a PC etc I guess then JTAG doesn't pick up the PC connection

I would have thought the phone provides it's own power or how would you test the 7540 is working correctly, that eliminated you could maybe use JTAG to power the phone.

Rooted Xakep E320/C6 EUU Hacked Update
[HTC Wildfire S] no.human.being:
Well we have to provide power to the board, right? :D

USB alone doesn't seem to be sufficient. Try taking the battery out of the phone and connect USB, then press power button. The phone won't boot.

So it seems we need to provide the correct supply voltage to the battery pins of the board.
[HTC Wildfire S] tacromx:
im sure it will work with the settings once you attach the power to the battery terminals
[HTC Wildfire S] no.human.being:
Leftmost terminal is positive, rightmost is negative. The two in the middle seem to be connected to a temperature sensor inside the battery cell. I guess these can be left open during debugging, right?

Battery is rated for 3.7 V. Tomorrow I'll try supplying that voltage with a benchtop power supply. Does anyone see a problem with that solution?
[HTC Wildfire S] tacromx:
confirmed....dont see a problem ; )

have a look at this ....it confirms the tap id if look closely and the battery connection too

---------- Post added at 09:48 PM ---------- Previous post was at 09:30 PM ----------

Good place for nand info
[HTC Wildfire S] Antagonist42:
Pin1 VBATT (positive)

Pin2 VBATT_TEMP

Pin3 VBATT_ID

Pin4 GND (negative)

From schematic on my docs page ;)

Rooted Xakep E320/C6 EUU Hacked Update
[HTC Wildfire S] munjeni:
No.human.being, I have allso problem while connecting to board using jtag. I have missing v+ pin on board (dont know pin position), so my device can not be halted with jtag interface. Seccond problem is making connection to board. But my steps to get jtag connected is:

- because missing v+, I connected v+ (pin 1 from jtag interface) to board connector v+ for battery

- than connect phone to usb without battery

- than run application (if app fail to initialise board, I click button disconnect, than place battery for one seccond to phone and remove battery again, than when I pres button connect I have comunication with board)

My battery is all time out of phone and phone is all time connected to usb, I dot know why but I have problems with jtag comunication when battery is in phone, maybe because missing v+...

---------- Post added at 12:59 AM ---------- Previous post was at 12:49 AM ----------

Please upload that pdf that contain a lot of the info for nand to an server like 2shared or whatewer, Im not able to dowload from link provided in your post
[HTC Wildfire S] Antagonist42:
http://www.2shared.com/document/hLymB7K2/1_3152094__2__80-VA736-2_RevB_.html?

Think that's it lol it is 2am and not nearly anywhere near enough sleep in 2 days :D

Rooted Xakep E320/C6 EUU Hacked Update
[HTC Wildfire S] kantry123:
itsworking to some extent but not s-off ing..
[HTC Wildfire S] Antagonist42:
@kantry123

If you're trying the exploit it's not complete and tests the system if enabling S-OFF would be possible without bricking your phone, unfortunately I think you may not have read the thread as this has been noted several times ;)

Rooted Xakep E320/C6 EUU Hacked Update
[HTC Wildfire S] no.human.being:
At the moment you can only use the exploit for patching an image of HBOOT that you dumped to a file (e. g. on SD card) to S-OFF. We currently have no way of getting that modified HBOOT written to NAND. This is why we're currently messing with this JTAG stuff. We want to know how the thing that is preventing us from writing a modified HBOOT to NAND is implemented, so that we can develop a method for bypassing it.
[HTC Wildfire S] munjeni:
Antagonist42, great document !

nand_addr = 0xa0a00000;

nand_mpu_addr = 0xa0b00000;

block_start and block_end that is controled by mpu/ or not controled by mpu and a lot of other things is in nand_mpu_addr + specific_offset ... I shortly readed document, but I must to say that document is great... there is a lot of interested things how protection is set to nand and nand specific offset :D... theres a lot of read/write registers that we can set to break nand protection for specific offset that we need to erase/write, but first we need to write it to "paper" in order to understand how to do it (of course, in comparation with msm_nand.c msm_nand.h). Allso first we need to dump whole block(nand_mpu_addr+nand_mpu_size) and analyse every offset that is defined in document and than analyse what is curently set in our phone...

Maybe simple dumper:

uint8_t i, u=0x20000, offset=0xa0b00000;
printk("NAND MPU DUMP\n======================\n");
for (i=0; i<u; i++)
printk("%02x ", readb(offset+i));
printk("\n===============\n");

than dmesg, than analyse dump using hex editor comparing with document...

edit:

I not have time now to detaily analuse document, but my first opinion is: spl, radio...etc is configured with nand mpu RE (read only) flag, so that preventing us to write to that offset ? Android partitions is configured in nand mpu with read and write flag...
[HTC Wildfire S] no.human.being:
Ok, I found out how to power the board without the Lithium battery. This is not trivial, since the battery has thermistors embedded for monitoring temperature and you need to recreate those for the board to boot properly.

The terminals are (when looking into the battery casing of the phone):

T1 (right) - GND

T2

T3

T4 (left) - V+

First connect the rightmost terminal T1 to ground. Then put a 10k resistor between T2 and ground. Then put a 120k resistor between T2 and T3. Have your power supply output +4 V DC at sufficient current. Then connect T4 to V+. Hold Vol-, then press Power button. Phone will boot into HBOOT mode.

The board draws quite an amount of peak current. If you have your current limiting too low, the phone might show the HBOOT screen for a short moment, then power down again. If you supply enough current, the phone will operate normally.

If you don't provide the correct resistances between the terminals to emulate the thermistors in the Li cell, the board will think that the battery is overheating and cease to boot.

I think it's missing ground. The pin on the JTAG adapter that's contacting the board's ground plane is not sharp like the others and won't penetrate the PCB's insulating coating. I grinded the coating off where the adapter is contacting the ground plane and verified that it's now having a good ground connection, but I still can't get the JTAG to work properly. I suspect that the electrical interface from the JTAG adapter to the circuit board is too unreliable. I either get "all zeroes" or "all ones". I think I'm giving it up. I need the phone, can't always have it disassembled.
[HTC Wildfire S] Antagonist42:
An old dog trying to learn new tricks :D if I could get my head around linux enough and a machine that doesn't threaten to break down every five mins I'd be writing it and dumping the NAND already :o but happy to wait for those who know ;)

n.h.b. you may only need something simple like credit card sized plastic cut to shape, if it's the same as the youtube and the boards sit together it could be generating interference, most basic would be tin foil between two sheets of paper ;) just make sure it's decent paper not 80gm :p and maybe if you can a couple of feet between you and any PC - Laptop etc as it'll pick frequencies up no problem having no case to protect it.
[HTC Wildfire S] tacromx:
Wat do you think?.... Jtag-breakout
[HTC Wildfire S] munjeni:
no.human.being, why you don't buy an segger jlink, its about 50eur, I think these jtag box or whatewer you have is maybe not compatible with this procesor... or at least maybe I am wrong, but I'm surre you will have problems to connect to nand controler after all because you need nand controler specific configuration in order to comunicate with nand ! So I think you need an trusted hardware to get started ! For example Seger Jlink Edu and great www.revskills.de software for writing to nand or Ice software for debuging or gdb...

---------- Post added at 10:40 PM ---------- Previous post was at 10:35 PM ----------

I think these big/thick wires will broke your pins on board when you try to move him :)... wires need to be like a hair...
[HTC Wildfire S] no.human.being:
It's said to support "all ARM7/9/11 targets working in 2 - 5 V range", which sounds like what we're having here.

I'd like to use OpenOCD. It's pretty much of a de-facto standard for on-chip debugging and of course you'll be able to program the NAND with it. OpenOCD is as flexible as it gets. Basically, you describe your entire target using TCL scripts. The only drawback is that it doesn't support debugging multi core processors yet (which means actual multi-core processors like from the Cortex A9 series - multi-processor setups and SoCs with separate baseband and DSP cores are of course supported) but even this can often be bypassed by booting an SMP-disabled kernel, which will disable all but one core and then you can debug the target again. Luckily, we're on an ARM11, so multi-core is not a concern for us.

Two resistors are sufficient as I mentioned here.

The 3.7 V are the nominal voltage of the cell. A fully charged Lithium cell may put out slightly more than 4 V when not under load, so 4 V seems ok. Basically we just have to "fake" the Lithium cell just good enough to have the phone operate reliably and 4 V seemed reasonable and did the trick. The phone read the battery as 66 % charged, even though it probably doesn't simply measure voltage, since on a real battery cell, voltage will change with load, so pushing the voltage until it reads 100 % is probably not a good idea. :D
[HTC Wildfire S] :
For the record........
[HTC Wildfire S] munjeni:
Anyone tried ? https://github.com/CyanogenModXT720/xt720_modules_eclair/tree/master/mtdhack
[HTC Wildfire S] akestrel1987:
Has any one......

Not realized that the MSM7227 is the same chip inside the HTC Aria and that that chip has already had the s-off completely done by revolutionary?

Why not ask them for some input if no one hasn't yet?

dont feel like deleting what i typed already so here

http://www.phonearena.com/phones/compare/HTC-Aria,HTC-Wildfire-S-CDMA/phones/4606,5641

view that and then hopefully we all realize its a different chip all together

its the 8227 not the 7227
[HTC Wildfire S] csoulr666:
The CDMA wildfire S has the MSM8227 chipset,and it has been S-Offed using the diag files from the XTC-Clip

While the GSM variant of the Wildfire S has the MSM7227 chipset,the same in HTC Aria
[HTC Wildfire S] no.human.being:
They were unwilling to port their exploit to our phone and they're not disclosing it either, so we don't know what they're doing.
[HTC Wildfire S] :
Well sure! They have got the XDA spirit! May I suggest reverse engineering.
[HTC Wildfire S] no.human.being:
Too heavily obfuscated.
[HTC Wildfire S] :
Damn.... Well at least we have the moral highground..... They don't....
[HTC Wildfire S] munjeni:
http://xdaforums.com/showthread.php?t=1489031 I am one step forward :D There inside revolutionary is zergrush, bumsh and Arx-helper(only one that I not understand for what use is. I think arx-helper is used to patch hboot or at least to open the dors for patching!). There is all dumped binaries from revolutionary, only arx-helper need to be reverse-enginered because htc aria revolutionary only working with hbot 1.02.0000 (arx-helper expect string/comand from revolutionary... for example command /data/local/arx-helper liberty 1.02.0000)...zergrush and bumsh is ussed only to gain root access... Guys, I want to say now, do not try to run these dumped binaries from revolutionary, only if you have jtag ready! I'm not responsible if you brick your device! Its reason why I never published hacked revolutionary!