yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] munjeni:
I allso think that (there is some security checks before s-off is gained - mean we can not pass s-off without modifying subroutine that check for "if all pass than set s-off" ...). Same as diag file - mean (we can not use an diag file for all devices to gain s-off without special sim card (htc clip emulate that sim card in combination with diag file)... so gaining s-off without htc clip (using only diag file) is very naive to be true :)

But guys, again I say, whats use of s-off without true unlocked hboot? :) Remember, I had s-off (true s-off) but was unable to do something without hacked hboot!!!! So s-off mean nothing without hacked hboot :) But true s-on + hacked hboot mean you can install whatewer you want (signed or unsigned) :) So s-OFF mean nothing for us now!

Allso search here for my post when I tried to install htc hd mini jtag nand backup trought hacked hboot to my htc aria (when I increased recovery partition and moved to offset 0 with size 0x2820000 and isued comand fastboot erase recovery and sucesfully formated whole nand from 0 to 0x282000 but had s-on... verified sucesfully erasure by jtag!)...

If you open hboot and disasemble you can see string "not allowed" in radio part routine, hboot part routine, diag part routine...etc but bypass that for example bypass "fastboot erase radio" and subroutine "partition is not allowed to be flushed" you can erase radio without problem!!!!!!! You can do same for hboot, for diag, for misc, for ...etc...etc. You can say its not true but I tried that and I can say its true!
[HTC Wildfire S] no.human.being:
The SD was a gold card, but it was 2 GiB capacity.

Lol @ "htc clip". It's called xtc-clip ("xtc" is a homophonic to the drug "ecstasy") has nothing to do with HTC. :D :D :D

By "chainloading" the "injected" HBOOT you gain "HBOOT S-OFF" (or "true unlocked" like you call it). The Radio secu_flag isn't even touched it's pure "HBOOT S-OFF".

BeciMester has reverse-engineered the HBOOT code and basically told me what code to patch. Later he verified that Revolutionary is basically patching the same subroutine. Of course in other HBOOT images since Wildfire S is not supported by Revolutionary, but the routines we patch and the routines Revolutionary patches on other phones look EXTREMELY similar. So while we haven't "stolen" from them (he hasn't looked at a Revolutionary HBOOT, he has just found it by reverse-engineering the WFS HBOOT), it just "turned out that he has 'incidentally' done the same" at some later point in time. So in a sense the "injected" HBOOT is basically "Revolutionary HBOOT for the Wildfire S", so when we talk about "injected HBOOT", think "Revolutionary HBOOT for Wildfire S". It will be "HBOOT S-OFF" or "true unlocked" as you call it, but without doing further stuff to the phone of course it won't give you "Radio S-OFF", so when you decide to flash a "stock" HBOOT image, you're gonna lose S-OFF just like with Revolutionary.

But erasure from 0 to 0x2820000 from within HBOOT is not erasure from 0 to 0x2820000 in physical NAND (as seen via JTAG) right? Remember that you have found out that the actual physical NAND contents (seen via JTAG) are not the same as "virtual" NAND contents (seen from firmware running on aARM) because there's "memory virtualization" happening in between so I'd expect the erase command to perform erasure of the NAND pages that appear as 0 to 0x280000 to aARM, which are in fact "virtual" and will probably not be equivalent to 0 to 0x280000 physical (otherwise you wouldn't see different content when reading NAND "physically" via JTAG and reading it from aARM).

Or do you want to tell that in HBOOT mode, NAND virtualization is disabled and it's only enabled when the actual operating system is running?
[HTC Wildfire S] munjeni:
If you follow what I said you can see that phys offset was set in hboot for "recovery partition" from the begining of the phys nand (offset 0x0) to 0x2820000 - mean I patched recovery partition table inside hboot by increasing table from 0 to 0x2820000 - so that mean "phys" nand ofset was the same like offset seen from jtag! So yes hboot see phys nand from 0 to etc and can perform erasure from begining on the phys nand including radio...etc :) and yes I verified erasure by jtag because had hard brick when I performed "fastboot erase recovery" :) Than I tried to install jtag dump by command "fastboot flash recovery jtagdump.img" but unsucesfull - mean wrong patched hboot routines or mean not posible (need radio s-off ? Or wrong patched routine that check for "ANDROID" header that is inside an *.img?)...

---------- Post added at 12:27 PM ---------- Previous post was at 12:19 PM ----------

Yes thats happend only by dump method by "android side" but I don't understand how hboot have access to phys nand (radio parts...etc). Do not forget, hboot can install radio firmware...etc, so that mean hboot (runing from aarm) for surre have full access to phys nand because is abble to install radio firmware!!! What is radio.img? Radio.img is an "pack" and contain: sbl, radio, amss...etc, radio image is installed directly to phys nand offset 0x0...etc. Why android kernel have no access to offsets "trusted and secure offsets" or have access but see data as a 0xff is an mistery... i have no idea :)
[HTC Wildfire S] no.human.being:
MSM7227 has a dedicated NAND MMU. It's rather a mystery why Android has access to the "Radio area" at all, since normally it shouldn't have any reason to access it as normally you don't have a visible partition there. Why don't they configure the MMU to block access to entire "Radio area" (excluding HBOOT since that runs on aARM)? Why do they let us access most of it but not all?
[HTC Wildfire S] beaups:
Do s-off phones normally sig-check PJXXX.zip files before flashing? I assume not, so why not get your hacked hboot properly loaded into a PJXXX.zip file so your chainloaded hboot causes it to be flashed. Of course, this only works if your bootloader doesn't check sig on hboot at each reboot, which you've stated it doesn't. (This wouldn't work on newer eMMC devices).
[HTC Wildfire S] no.human.being:
Yes this should work in principle. Issuing a "fastboot flash hboot ..." against the chainloaded HBOOT in Fastboot mode should also work though. The problem is that the HBOOT currently doesn't run stable when "chainloaded". I didn't try what happens when I put a PG78IMG.zip (that's the name the file has to have for the WFS) into the root of the SD card, since I don't want to risk aborting it half-way through and bricking my phone (I do not have working JTAG so I couldn't restore if I damaged the bootloader). I assume it will restore "stock" HBOOT from NAND before it even starts writing, but it's not something I want to try out. I don't want it to begin "restoring" after it has flashed new HBOOT half-way since that will most likely cause a brick.

We HAVE to get rid of this restore behaviour. Does ANYONE have an idea how we could find the code that does the restore? HBOOT is more than a hundred thousand lines of assembler code so we can only analyze it if we have at least a rough idea (say an area of a thousand instructions) where it happens.
[HTC Wildfire S] beaups:
Why don't you just try loading a relatively harmless image into the zip file to test it? Such as a system.img? It would at least confirm for you whether or not you are able to flash from this mode. And if/when you have the confidence, you can go for hboot.
[HTC Wildfire S] munjeni:
Yes, without real tests that s-off+custom hboot will never be installed in wfs! So guys you need to test it! I have ready patched hboot + only waiting an tester to give me his misc partition = I will give him all needed files + instructions! ...waiting! :)
[HTC Wildfire S] no.human.being:
How does such a ZIP look like? What files does it have to contain and what must be in them? (Sorry, I only flashed using Fastboot so far.)

My idea was to achieve temporary S-OFF by performing only modifications to RAM (as opposed to Flash). This would allow you to run the "temp-S-OFF-utility", then your phone is S-OFF, you boot into Fastboot mode and do whatever you want to do with the S-OFF (e. g. flash a Radio) and as soon as you reboot the phone, you're back S-ON.

This way all our fears about "does SBL check APSBL signature?" and stuff would be moot, since you could have S-OFF without changing APSBL in NAND. In addition you would have additional security because on an S-ON phone, the operating system cannot write to NAND, so you can be sure that, say, even a faulty (or even malicious) kernel could never brick your phone to the point where you could no longer restore it using software methods. I find this a very nice solution. I mean how often do you require S-OFF? You only require it for doing extremely critical stuff to the system. So I think "temp S-OFF" is a very nice idea. It's a bit like the "sudo" command under Linux that lets you perform a single command with root privileges, as opposed to plain old "su" that elevates privileges on your entire session. It will enable you to perform stuff that requires S-OFF (e. g. flash the Radio) without compromising overall system security, since you need physical access to the phone to disable security and it will automatically be re-enabled on next reboot.

We're so close. We "only" have to find the code that "reverts" HBOOT and either overwrite it with no-operations or make sure it never gets called.

So now we have two S-OFF methods that are (almost) finished? Why didn't we concentrate our effort on one? :rolleyes:
[HTC Wildfire S] munjeni:
You can download for example RUU_Marvel_S_HTC_Europe_2.13.401.3_Radio_47.23c.35.3037_7.54.39.28M_release_236989_signed.exe, than run ruu, than pause (do nothing and do not close installer), than open winrar and search folder "C:\Documents and Settings\your_user_name\Local Settings\Temp\* for rom.zip, than copy that rom.zip to your sdcard and rename to xxxxxxx.zip where xxxxxxx is ..., than reboot to hboot and you will see confirmation window...etc. Just for info, an zip like that zip extracted from an ruu contain full instalation (radio, pbl, sbl, amss,boot,system,userdata...etc - so everything!). First to be sure if you need gold card, open zip and open cid.txt and search if that txt file contain cid that is like cid in your phone, if cid exist than you no need gold card,but if cid not exist than you need gold card! Do not modify zip or signature check will fail! If you have htcdev unlocked bootloader you need first to relock hboot: "fastboot oem lock"! If zip fail to install because main version installed in your phone is biger than mainversion in zip, than you need to change version string in misc partition!
[HTC Wildfire S] csoulr666:
Two methods are better than one :D

I'd say we keep one of them as a backup,preferably the one that is 'Noob Friendly' so that we dont get "My phone's bricked!!! &%!@ You" from Non-readers
[HTC Wildfire S] mstfkaratas:
I think l know why it reverts to original hboot after scanning for diag files. It first loads hboot and checks if sdcard is there. if sdcard is there checks diag files and loads hboot again with flashing mode, else it just sits on hboot doesn't load again. this is why it locks up when there is no sdcard.

This is my theory about hboot.
[HTC Wildfire S] joelgsmst:
I've been following this thread for about a week or so now, and I've been reading through what you guys have been writing, even though I only understand about 10% of it myself. I know I'm not exactly contributing to this thread with this, but with two methods under your belt now, how long will it be until a guide to S-OFF is released? Perhaps a week or 2?
[HTC Wildfire S] csoulr666:
Thumb rule of Android development.....

Do not ask for ETAs
[HTC Wildfire S] munjeni:
Without testers it will not! :) First you need to test if RUU (with diferent partition layout) is instalable to phone (that have another partition layout), than we can test exploit! Another thing. How you expect that s-off will be finished when no one want to test an simple ruu thing? Do not forget, wfs phone have two versions, one version is diferent than another version, there diference is only in two diferent nand partition layout... did you ever tried to install that diferent ruu that have diferent partition layout than your curent rom installed... etc? I just waiting that info first!
[HTC Wildfire S] theq86:
munjeni, which hboot should i have installed to test your exploit?

btw: misc attached
[HTC Wildfire S] munjeni:
Forgot which one ruu I extracted but you must to have/find and install ruu that contain hboot_1.03.0001_181386c9.nb0
[HTC Wildfire S] theq86:
then unfortunately I can not help you and test it. 1.03.0001 is a cdma variant hboot.

gsm only has 1.03.0000
[HTC Wildfire S] munjeni:
Ok, found here unbranded rom http://xdaforums.com/showpost.php?p=19094201&postcount=45 that contain hboot 1.03.0000 so I must to patch that hboot :( but ok I will do it for you if you are ready to test! First try to install that rom and let me know if you have success! If you have allready an rom that you tested allready (contain hboot 1.03.0000 than you no need to install http://xdaforums.com/showpost.php?p=19094201&postcount=45) please let me know
[HTC Wildfire S] theq86:
I have the RUU on my disk. so just patch the ***** and I can test ;)
[HTC Wildfire S] munjeni:
Give me right name of the ruu... going to download
[HTC Wildfire S] theq86:
RUU_Marvel_HTC_Europe_1.66.401.1_Radio_47.10g.35.3032H_7.49.36.01M_release_209754_signed

attached new misc according to above RUU
[HTC Wildfire S] artturnip:
C'mon... if this works I'll have a go...

@munjeni could this brick my phone??? My mum would kill me... :eek:
[HTC Wildfire S] theq86:
Yes it may be possible. So that's no kid's game. I also just do it for the sake of science and because WFS is not my main phone ;)
[HTC Wildfire S] artturnip:
Haha... so funny... I would if it wasn't main phone...

But haven't I risked a bit with custom roms etc... or are HTC just being over cautious (when you unlock bootloader)
[HTC Wildfire S] theq86:
Unlocking the bootloader the htc way has a low risk of bricking the phone. also installing custom roms. you can always restore everything you changed if you just have unlocked bootloader. well, basically

S-OFF is the real risky thing. because then you can also change things that you are not supposed to by htc.
[HTC Wildfire S] munjeni:
Well, I patched misc.img just for test (without risk for brick) but before I continue to prepare hboot, first I want to be sure if misc exploit working! What you need to test now? You need to install this patched misc.img! Best way to do that is:

- reboot to recovery

- adb push misc.img /

- adb shell erase_image misc

- adb shell flash_image misc /misc.img

Than (this step is very needed, just you need to dump misc again and you need to be sure if patched misc is installed to nand!!!). If is installed sucesfully than:

- adb shell reboot bootloader

- fastboot getvar mainver

If your screen going black after command "fastboot getvar mainver" that we are ready for misc exploit! :) Please let me know! Password for archive I will send you by pm!
[HTC Wildfire S] theq86:
Screen turns black after issuing command. then hboot is reloaded.
[HTC Wildfire S] munjeni:
Great! Ok, I will patch hboot today (not surre) but tomorow for surre! I think today we will test it :) Do you want to upload hboot to an server and send me a link (no need whole ruu just hboot only)?
[HTC Wildfire S] theq86:
same password as in PM
[HTC Wildfire S] Nightshadow931:
I don't really believe that.

They used to tell someone that bootloader is going to be unlocked, and then they would tell totally different story to other user.

So, no, I don't believe them anymore.

They were acting non-professional in the past already.
[HTC Wildfire S] djpc:
we will know if they are going to unlock our bootloader as they will release a new OTA to add the oem command to fastboot
[HTC Wildfire S] Lt.Win:
Let's just keep doing what we do best, get that damn software S-OFF.
[HTC Wildfire S] sythe179:
Why not dump the partition 3 of a rooted WFS and a stock WFS instead of a desire s? Then you could get a true comparison.
[HTC Wildfire S] logout20:
that comparing thing .....

---------- Post added at 06:20 AM ---------- Previous post was at 05:59 AM ----------

http://xdaforums.com/report.php?p=19657946 ..........
[HTC Wildfire S] sythe179:
And that is relevant how?....Wrong device for one, wrong Rom secondly, and third, we haven't even got a fake s-off...

If you dump the files, you can run a comparison through cmd if you can't find any tools to...
[HTC Wildfire S] ONeill123:
Now i have a question:

Where is the secuflag stored? Is in the mdtblock3, or in the radio.img, or where is it stored. Maybe alpharev team can say us, how to locate the flasg.
[HTC Wildfire S] csoulr666:
One of the Revolutionary team members wrote a post around here about the location of the secure flag....You should check it out
[HTC Wildfire S] *se-nsei.:
Here it is. ^^^
[HTC Wildfire S] ONeill123:
Thanks ;)

So the secuflag is in the radio, if i'm right. But how a user can write into the NVRAM? I have seen today first ever how revolutionary unlock a Sensation XE. The program strat the phone into fastboot mode, right?

Then the phone restarts 3x into the fastboot and after this is it s-off. What revolutionary do at this time, flash with fastboot? But then the hboot will give an signaturerror, or not?

So what they do?
[HTC Wildfire S] Nightshadow931:
Maybe someone could send him an PM asking him for help, in the name of us all.. ?
[HTC Wildfire S] ONeill123:
I have write a PM, now we must wait for an answer.

------Last dev-question------

So the secuflag is in the radio, if i'm right. But how a user can write into the NVRAM? I have seen today first ever how revolutionary unlock a Sensation XE. The program strat the phone into fastboot mode, right?

Then the phone restarts 3x into the fastboot and after this is it s-off. What revolutionary do at this time, flash with fastboot? But then the hboot will give an signaturerror, or not?

So what they do?
[HTC Wildfire S] *se-nsei.:
Just an idea guys -- but what if we managed to find a way to get the identifier token for our device without using adb/fastboot?

Like with a root app or something? Because I mean, to get the token during the HTCdev process, it doesn't really do anything except connect to phone using android SDK tools to get the token out.. so don't we just need a way of getting the token?

Tell me if it's a stupid idea.. :p
[HTC Wildfire S] bingzz:
Maybe something like this?

http://stackoverflow.com/questions/...id-device-identifier-from-adb-and-android-sdk
[HTC Wildfire S] djpc:
AFAIK you would still need an updated bootloader that supports the unlocking process, as you do not gain s-off with the htc unlock, it just unlocks system and recovery. This is why a proper s-off is still important as then we can remove things like simlocks
[HTC Wildfire S] ONeill123:
Right, we must work on a way for s-off.

------Last dev-question------

So the secuflag is in the radio, if i'm right. But how a user can write into the NVRAM? I have seen today first ever how revolutionary unlock a Sensation XE. The program strat the phone into fastboot mode, right?

Then the phone restarts 3x into the fastboot and after this is it s-off. What revolutionary do at this time, flash with fastboot? But then the hboot will give an signaturerror, or not?

So what they do?
[HTC Wildfire S] humzaahmed155:
Wait a minute, so the XTC Clip creates a gold card right, but there's an program on my computer that creates gold cards, but I don't think thats enough to s-off this phone.
[HTC Wildfire S] ONeill123:
With the goldcard alone you can't get s-off, what u will try?

------Last dev-question------

So the secuflag is in the radio, if i'm right. But how a user can write into the NVRAM? I have seen today first ever how revolutionary unlock a Sensation XE. The program strat the phone into fastboot mode, right?

Then the phone restarts 3x into the fastboot and after this is it s-off. What revolutionary do at this time, flash with fastboot? But then the hboot will give an signaturerror, or not?

So what they do?
[HTC Wildfire S] XDA_h3n:
So we need to find where the security flag is in the radio?
[HTC Wildfire S] no.human.being:
Aah, the "WFS_SOFF_hboot_1.03.0001_181386c9.nb0" was for CDMA. That's why it locked up when attached to "chainload"-exploit as payload.

Does CDMA have a different processor or did it just lock up because of different Radio firmware?
[HTC Wildfire S] theq86:
I guess radio firmware. processor is the same
[HTC Wildfire S] no.human.being:
Does that mean you could turn a GSM phone into a CDMA phone by flashing a CDMA Radio to it?
[HTC Wildfire S] artturnip:
I don't think so... the operating frequencies are different. Maybe the different variants are locked to certain frequencies. Just a guess... :p
[HTC Wildfire S] munjeni:
Done! Dude, everything is carefully patched, but please "BIG SORRY" if misc exploit brick your phone... I double checked every code and its ready for test! Procedure:

- install new misc.img and "double" check if is installed corectly!

- adb shell reboot bootloader (phone must be in fastboot mode!)

Next command will give an error or something other, so do not care:

- fastboot flash hboot hboot_6.03.0000_cdf32d1_R2.nb0

This command will update hboot:

- fastboot getvar mainver

After some moments (if exploit done) you "will" see version string changed on your screen to *** Munjeni ***, if string not changed try to reboot manualy to fastboot mode, if string is munjeni than you have s-off ! ...Waiting :)
[HTC Wildfire S] theq86:
going to test now. stay tuned

---------- Post added at 09:59 PM ---------- Previous post was at 09:36 PM ----------

Good news and bad news.

Bad news: No S-OFF, no different version string :(

Good news: No brick.

It seems as if it had no effect at all.
[HTC Wildfire S] munjeni:
Damn :( but its not end! :) Problem is only in misc.img: Only I not understand is this part of asembly in misc.img:

What is this? :

ROM:0000003C DCD 0x4040404 ; R4
ROM:00000040 DCD 0x5050505 ; R5
ROM:00000044 DCD 0x6060606 ; R6
ROM:00000048 DCD 0x7070707 ; R7
ROM:0000004C DCD 0x8080808 ; R8
ROM:00000050 DCD 0x9090909 ; R9
ROM:00000054 DCD 0xA0A0A0A ; R10
ROM:00000058 DCD 0xB0B0B0B ; R11
ROM:0000005C DCD 0x60302104 ; PC

registers??? And what is:

ROM:00000060 DCD 0x4030201

Everything other is correct and match new hboot! Just only need help to set our part of asembly corectly!

No.human.being, please disasemble unpatched hboot and please verify if I had set all offsets corectly (I checked twice)... "main" exploit that is "concatenated" with hboot (begin of the hboot image) is:

ROM:00000000 LDR R1, =0x60302000
ROM:00000004 LDR R2, =off_A0
ROM:00000008 ADD R1, R1, R2
ROM:0000000C
ROM:0000000C loop_until_ff ; CODE XREF: ROM:00000018j
ROM:0000000C ADD R1, R1, #1
ROM:00000010 LDRB R2, [R1]
ROM:00000014 CMP R2, #0xFF
ROM:00000018 BNE loop_until_ff
ROM:0000001C
ROM:0000001C zero_until_00 ; CODE XREF: ROM:00000030j
ROM:0000001C MOV R3, #0
ROM:00000020 LDRB R2, [R1]
ROM:00000024 STRB R3, [R1]
ROM:00000028 ADD R1, R1, #1
ROM:0000002C CMP R2, R3
ROM:00000030 BNE zero_until_00
ROM:00000034 MOV LR, PC
ROM:00000038 LDR PC, =0x9D0088BC @ get_battery_status
ROM:0000003C CMP R0, #0
ROM:00000040 BEQ loc_80
ROM:00000044 MOV R0, #0
ROM:00000048 ADR R1, dword_B4
ROM:0000004C ADD R1, R1, #4 @ appended hboot
ROM:00000050 LDR R2, =0x80000
ROM:00000054 MOV LR, PC
ROM:00000058 LDR PC, =0x9D0308E4 @ crc32(0, buf, 0x80000)
ROM:0000005C LDR R1, =0x37CD7F95 @ this is crc32 for new hboot(without this exploit code!)
ROM:00000060 CMP R0, R1
ROM:00000064 BNE cleanup
ROM:00000068 LDR R0, =0x9D0551D7 @ bbbbbbbbbb <-> offset to "hboot" string
ROM:0000006C ADR R1, dword_B4
ROM:00000070 ADD R1, R1, #4
ROM:00000074 LDR R2, =0x80000
ROM:00000078 MOV LR, PC
ROM:0000007C LDR PC, =0x9D0073C8 @ partition_update(bbbbbbbbbb, buf, 0x80000)
ROM:00000080
ROM:00000080 cleanup ; CODE XREF: ROM:00000040j
ROM:00000080 ; ROM:00000064j
ROM:00000080 MOV R0, #2
ROM:00000084 MOV LR, PC
ROM:00000088 LDR PC, =0x9D0085DC @ set boot mode "fastboot"
ROM:0000008C LDR PC, =0x9D00A864 @ reboot

dword_B4 is address to hboot apended to exploit.