yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
Last real "progress" was this here. Basically the exploit is correct as of itself. It works perfectly on most "ordinary" HBOOT images. There seem to be "exotic" HBOOTs around, however I think that these are rather a result of incorrect page tables, as they don't look like HBOOTs at all, they're probably just "junk" from a random partition that was mapped where the HBOOT supposed to be.

However, the testing on the actual devices didn't go so well. We're currently hitting kernel-level restrictions (imposed on us by the mtd driver). Basically, the kernel "ignores" our ioctl(...) calls to erase the "protected" (= HBOOT) memory regions in NAND, but nonetheless claims "success" for the operation we requested. However, before the memory has actually been erased, we can't write the patched HBOOT image back. This happens on a "real" mtd handle which has "physical NAND" behind. When we do the same to a file holding an image (e. g. on SD card), it works perfectly and the image gets patched. So the restriction seems to reside inside the kernel's mtd driver.

With NAND memory, you have to adhere to a strict "read --> modify --> erase --> write"-cycle. "Read" (from NAND to RAM) and "modify" (in RAM) work, then we ask the kernel to "erase" (the NAND), it "claims" success, while in fact it didn't pass the "erase" command on to the actual (NAND) memory. Of course we can't write the modified HBOOT back (from RAM to NAND) since the target (NAND) memory is not in an erased (and therefore "ready to be written") state.

What we need now is a kernel that "ignores" the "protected"-flag that's set on the memory regions and passes the "erase" on to the NAND nonetheless. Probably any "vanilla Linux" (or "non-Android") kernel will do, however, we didn't get one running. Alternative is to remove the restriction from an "Android" kernel's mtd driver, then build the kernel from source with the restrictions removed. I've asked Alquez for support on this, since I think he's very deeply involved with all the kernel-level stuff and knows best what we need to touch in order to make the kernel "unrestricted".

No problem leaving this thread open for discussion. If you open a new thread now, it'll also get "spammed all over" and not stay "clean". You can't claim "ownership" over a thread. That's the principle of a community. Anyone can mention whatever they want (basically).
[HTC Wildfire S] mhrsolanki2020:
[/QUOTE]

No problem leaving this thread open for discussion. If you open a new thread now, it'll also get "spammed all over" and not stay "clean". You can't claim "ownership" over a thread. That's the principle of a community. Anyone can mention whatever they want (basically).[/QUOTE]

wat i meant is that i cant recognise the progress. and comon it has so many pages i wont be knowing on which page did you made a progreess.. i dont mean to say taht delte this make a new thread dont allow people to coment. i just mean make a new thread in which you dont alow people to post comment only kernal devs and other who help you and let the ideas be share in this post.. so that we can see the progress without dificulty in the other thread..
[HTC Wildfire S] *se-nsei.:
Ok NHB, thanks. :D

@mhrsolanski - don't worry, another thread would turn out the same. Just read the OP whenever I update it. :)
[HTC Wildfire S] no.human.being:
One thing I forgot for the "summary" ...

We're currently focusing on a way to "escalate" the HTCdev "unlocked" bootloader to a "true S-OFF". With "true S-OFF" we mean "HBOOT S-OFF" (like Revolutionary), as we didn't find the actual secu_flag in the Radio, so currently no "Radio S-OFF" (like xtc-clip). So, like with Revolutionary, the S-OFF will stick until you flash a "stock" HBOOT (which is also the way back to S-ON should anyone want this).

What we mean by "escalating unlocked to S-OFF" is that we currently regard an unlocked bootloader as a prerequisite, since the memory region where HBOOT resides is normally "unmapped" (which means it has no "operating-system-level" address assigned and is therefore inaccessible for us) and we make use of the Fastboot protocol to "assign a mapping" (= OS-level address) for this region, therefore making it accessible. A "locked" bootloader will not allow us to use the Fastboot protocol, which means we can't "map" and therefore not access the HBOOT on such a device.

Getting "bootloader unlocked" without the unlock-token from HTCdev is an independant effort (on which I'm currently not working at all, however some people have found that one might be able to unlock the bootloader by altering the phone's "misc" partition) and once we achieved both, we can combine the two to get S-OFF without HTCdev's involvement. This means that all the HBOOT-0.90.0000 users will need to upgrade (to either HBOOT-1.08.0099 or HBOOT-1.09.0099, which are currently the HBOOT versions that are supported by the exploit), then "unlock" the bootloader (currently by requesting an unlock token from HTCdev, later the other development effort might lead to a measure to circumvent that as well), then run an OS image which maps the "protected" memory areas, run our exploit on top of that. Afterwards they'll be both, unlocked and S-OFF. They can either stick with that or "get rid of the unlock" by modifying "misc" again (personally I'd stick with it though, as it allows use of Fastboot, which is very handy for development). As soon as you're S-OFF you can flash HBOOT, therefore getting back to HBOOT-0.90.0000 should you really want that (why?). However, like with Revolutionary, you're gonna lose the S-OFF by flashing the HBOOT.
[HTC Wildfire S] theq86:
Once we have volatile S-OFF we can also install ENG HBOOT 0.81.2000 via diag tool.

The ENG hboot is a special HBOOT allowing every fastboot command without restrictions.

That would mean

* Set CID via fastboot (also SuperCID)

* Set the REAL secu_flag either On or Off via Fastboot

* and much more
[HTC Wildfire S] mstfkaratas:
you have that HBOOT? or is it in development stage? as i am s-off i wanna try it
[HTC Wildfire S] seaskyways:
Check up !

Guys , check this thing here

it shows that the device is s-on , and it should make it s-off , i tried this method and i ended finally with a CID write error , which means if you could modify "something" either the nbh file or any other "thing" to return always as s-off and then it will Truely S-OFF the phone ! so what do you say guys ?
[HTC Wildfire S] theq86:
these efforts failed months before this campaign was started ;)

yes. it is attached already in this thread. go to the thread list and click on the attachment icon of this thread. search for pg76diag.rar

unrar it, put pg76diag.nbh to /sdcard, go to the bootloader- wait

when it is started there is a menu:

Power reflash

Vol- DIAG

press button for reflash.

that's how it should work

EDIT: make nandroid backup before :D it shouldn't happen anything unless you clean S58 data but who nows :D
[HTC Wildfire S] *se-nsei.:
If anyone needs the ENG HBOOT it's uploaded here. :)

http://xdaforums.com/showpost.php?p=20232475&postcount=2
[HTC Wildfire S] theq86:
right, but it should be named .nbh instead of nb0. Otherwise hboot will not recognize it as an update.

the eng hboot is in that file along with the diag utility. you can not just flash the nb0 file.

rename it to pg76diag.nbh, go to bootloader, wait for the menu and chose reflash.
[HTC Wildfire S] seaskyways:
What is that ?? I can't get it done flashing , always a CID write error ... and also , DIAG file I spoke about earlier , did you try to modify the DIAG file and fail ?? cuz that is my main question ...
[HTC Wildfire S] theq86:
Please do read carefully in future. If you read the whole thread ( > 50 pages ) you will learn much about the wfs and it's internals. If you are really interested in you should take that time so we all do not have to write things 100 times again.

1. question: When you are not S-OFF you can not flash the ENG HBOOT. Just not possible

2. question: The ENG hboot is digitally signed. That means is contains infos about it's size, it's content digest and this information is encrypted asymmetrically with HTC keys.

If you change the file, be it just a single bit the file is corrupted and will not be loaded.
[HTC Wildfire S] mstfkaratas:
copied my sdcard, booted into bootloader, pressed power for reflash but it gives

Open File Fail!
Read ZIP File Error!
[HTC Wildfire S] theq86:
copy the diag file and name it PG76DIAG.zip so that you have PG76DIAG.nbh and PG76DIAG.zip and try again.
[HTC Wildfire S] seaskyways:
Shouldn't. You press the DIAG button when prompted to choose. ? ?
[HTC Wildfire S] :
Yeah, I think I got this when I was experimenting with ROM_01.zip. My phone got bricked and all that. Can it be fixed? And will it prevent me from using any exploits you make? Is it even a problem, or is it beneficial?

Bloody kernel!!!

What! YOU wrote 530 LOC?!?!? That's awesome!!!!

Man, if you get S-OFF, your name will burn in the stars, and the Medusa Cascade itself!

(Doctor Who stuff!!!)

Damn right I cracked your lousy bootloader!!!!

Precisely! We have the moral highground!! (As said by the Doctor)

What is your country. I know for a fact that it's in Europe.

Welcome to my world.

Already have. If you look at my threads I started, you'll see that I made one that goes by the name of "Current S-OFF Progress". It's only outdated bu one update, whuch I will use no.human.being's summary for. (Thanks no.human.being!!!)
[HTC Wildfire S] mstfkaratas:
it doesnt work, PG76DIAG.nbh doesnt contain eng hboot, it searches for PG76IMG.zip when pressing reflash, i put PG76IMG.zip myself and reflash works, but it only updates to the hboot which i placed into PG76IMG.zip
[HTC Wildfire S] heavy_metal_man:
You are supposed to clean s58 data man. Reflash if for flashing system stuff.

sent from my ice cream sandwich powered HTC WILDFIRE B-)
[HTC Wildfire S] mstfkaratas:
cleaned s58 data too, it just needs another PG76IMG.zip to update hboot
[HTC Wildfire S] :
The new XDA app is cool. Anyway, what is DIAG? And where are we now?

Sent from a Time Lord, via his TARDIS.
[HTC Wildfire S] MrTaco505:
Ok so i decided to see if the ENG HBOOT would work on my S-ON but not sure if it did, but this is everything it did when going to reflash:

GET SW VERSION

......Str not found!

Get OEMSBL time out!

Pls chk Security flag

Press VOLDN to exit

Waiting for GSM ready.....

Power=>Reflash i pressed power

Vol-Dn=> DIAG

Pls disable security first!

When pressed DIAG:

GET SW VERSION

...... Str not found!

Get OEMSBL time out!

Pls chk Security flag

Press VOLDN to exit

Waiting for GSM ready.....

Power=>Reflash

Vol-Dn=> DIAG i pressed VOL-Dn

TP Calibration......

(said something way to fast to copy here)

MAL Service HDIAG 1.00

Clean S58 Data pressed clear s58 data

Device Info

Press Power to Clean S58 data, or VOL-DN to exit

(taking too long)..........(still waiting)...........zzzzzzzzzzz......finally

Verify Str not found

CID Write Error! NG

CID Set FAIL!

Thats basicallt it just a refernece on what happened on an S-ON device.

I thought it was gonna make S-OFF :(

EDIT: F**k it formated my phone >:(
[HTC Wildfire S] gauravjuneja01:
@nhb You can try....

Remember, When you tried exploit with new phone...

You said that it successfully patched..

Now If you will try the exploit second time on same phone, it will definitely say above error... (Base Signature)... What happened wrong with our hboots??

After trying exploit.....
[HTC Wildfire S] kalaker:
So, I'm not too great with messing with bootloaders and kernels and stuff, so maybe this post is an entire piece of junk. And, if it is, feel free to ignore it.

However, it really appears that it is the kernel holding you back. Since the kernel won't allow you to do what you want to do, why not build a kernel that is used only for flashing this hboot which is replaced by the previous kernel once the changing of the kernel is done? Also, what if you incorporated the HBOOT upgrade/downgrade flash that needs to be done to access it into the utility? Kind of like an all-in-one kernel/hboot deal.

Again, I'm not too great with kernels and bootloaders so maybe that isn't feasible or maybe you've already tried it. Sorting through all 180 pages can be slightly difficult, so I apologize if this is just an annoying post that gets in your way.
[HTC Wildfire S] heavy_metal_man:
That's the plan. You guys should really read all of this stuff, would save so many comments ;)

sent from my ice cream sandwich powered HTC WILDFIRE B-)
[HTC Wildfire S] :
Uhh, that's precisely what we are doing.

Sent from a Time Lord, via his TARDIS.
[HTC Wildfire S] seaskyways:
Actually I wanted to warn you , but for me , since I knew it has to delete "data" i made a nandroid backup in case anything happened , and when all my stuff where gone , i got them back :D

---------- Post added at 07:07 PM ---------- Previous post was at 07:04 PM ----------

So what happened with Alquez ?? is he working on something , or should I take a look at other phone's kernel developers and message them ??
[HTC Wildfire S] *se-nsei.:
Please relax with the questions man, all in good time.
[HTC Wildfire S] seaskyways:
Hehe , okay okay , but i am just "hypered" to get S-off on my phone ... :D
[HTC Wildfire S] pihug12:
Who made it ? Is it a hacked one or a HTC internal tool that got leaked ?

If someone S-OFF could perform a dump of his unmapped memory after toggling on/off the secu_flag, maybe we will see where it is hiding. I know the mapping of the radio is different with HBOOT 1.08.0099 and 1.09.0099 but we would have a clue to where to look closer.

Good luck with this kernel thing ! :)
[HTC Wildfire S] :
Uhhhhh...... That's what we did, long ago.
[HTC Wildfire S] pihug12:
No, it's not. Nobody dumped a thing with this ENG HBOOT.

Don't take it offensive, but most of your posts are kinda useless here. If you just want to say "Come on guys !", "Yeah ! Let's do it this way !", "I don't get a thing of your last post", or post an "Hello world" in Java or ask questions about our personal lifes, just

don't

. Sorry if I seem mean. ;)

EDIT : And please, change this blinking signature, it gives headaches to no.human.being. :D
[HTC Wildfire S] heavy_metal_man:
well i did that, but we failed as we didnt have access to the radio at the time. we need to do it again with access to the radio to see what we can find. as i dont have a spare wildfire s i cannot test again. but, should anyone be in scotland with the htcdev bootloader willing to give the dump files i have the xtc clip and will clip for free.:D
[HTC Wildfire S] :
No I don't. Try reading every single one of my posts. You'll see how useful I am. FYI, I do do helpful things, I made the forum that NHB started his research in, have a look. And I made a ROM. I have done so many things. I didn't post an hello world in Java. And I dont ask personal questions. what is your country isn't even that personal.

-----------------------------------------------------------------------------

Anyway, since we're back to kernels, we still getting the white screen?
[HTC Wildfire S] heavy_metal_man:
ok guys lets not start fighting here, we all have a common goal in mind. lets focus on the task at hand. we need to find a kernal dev willing to help us and we need to get these s-on s-off radio dumps from the xtc clip.
[HTC Wildfire S] :
Sorry.

Like stated before, I say we work with the HTC Aria/Salsa people so we can get S-OFF.
[HTC Wildfire S] heavy_metal_man:
have you asked them?
[HTC Wildfire S] :
no. i remember on my old thread someone suggested it since they got similar specs and trying to get soff.
[HTC Wildfire S] :
Woah. It's been hours yet no posts. So, how are you doing NHB.
[HTC Wildfire S] eoghan2t7:
if you want i can dig into the kernel source and see if there is anything that repects the S-ON flag and show disable that so the expoilt can run sucessfully?
[HTC Wildfire S] *se-nsei.:
pleease :)
[HTC Wildfire S] eoghan2t7:
no problem might take me a few days to check each boot file for any secu_flag statments etc
[HTC Wildfire S] theq86:
I think the term secu_flag will not be explicitely stated in the kernel. Also you have to look at the kernel sources, especially the mtd driver - not the boot images.
[HTC Wildfire S] pihug12:
If the ENG HBOOT is working like theq86 said, it could be easier to find the real @secu_flag than with the XTC-Clip method.

The XTC-Clip mades various changes on the device (secu_flag, SuperCID and SIM unlock) and needs a reboot at the end of the operation. With this ENG HBOOT, a S-OFF user could simply flip the real bit with "fastboot oem readsecureflag" and "fastboot oem writesecureflag" and no reboot will be needed probably.

If it works and if the @secu_flag is really on the NAND, comparing the before/after dumps will be as easy as ABC. :D

I didn't find any infos about the ENG HBOOT 0.81.2000 however. I don't know where *se-nsei. got it and I saw nobody here reports it working good. :-/
[HTC Wildfire S] theq86:
An S-OFF user checked the eng hboot thing. Result was: we have the diag tool (which is copied to the sd card from the xtc clip) but not the eng hboot itself.
[HTC Wildfire S] :
That's good to know.

Are you working on the kernel to, theq86? Or are you trying a different approach? I'm sticking with my Doctor Who story, that's for sure!! :D

When you get a stock S-OFF phone, is it just a coincidence?
[HTC Wildfire S] no.human.being:
No it is not.

You are explicitely allowed to disassemble/decompile utilities, e. g. in order to inspect them for backdoors, etc. Of course you aren't allowed to use the implementation in your own software (the implementation is protected by copyright), but you may create your own code that functionally does the same (the "principle" can only be protected by patents and there are no software patents in Europe).

Many EULAs prohibit reverse engineering, but EULAs are not considered legally binding contracts. You may just hit "accept", it's not a thing you are in any way bound to. It's different if you use the software in conjunction with a "service" (e. g. an online game), as the "terms of service" are legally binding, but the EULA itself is not.

But there's a different thing that makes me concerned and it's the fact that we're patching the HBOOT and this software is protected by copyright. I'm not sure whether creating a software that patches it is already considered "creating a derived work" (which we would NOT be allowed to do) or if that "derived work" is only created "on the phone" and therefore by the person running the patch (after all the patch itself doesn't contain HBOOT code at all).

From my point of view I'd say that we're not creating a "derived work", but I'm not sure if jurisdiction shared my view. I really don't want to infringe any "intellectual property". It's one of the worst things you can do as a computer scientist. Could we port this one over to the phone and get rid of HBOOT entirely?

Btw, since so many asked why I didn't post for some time. I'm a bit busy at the moment and we still haven't got a functioning kernel.
[HTC Wildfire S] BeciMester:
Is it still illegal if you do the modification only for yourself on your own phone and do not distribute the modified code? Also: do you legally have to restore everything to stock if you sell the phone or give it away?

(I'm on my phone...)
[HTC Wildfire S] eoghan2t7:
its not illegal to modify your phone as it your property for example when apple took George Francis Hotz aka geohot to court about him breaking the iphone bootloaders etc the courts dropped the case because its not illegal to do ;)
[HTC Wildfire S] theq86:
Well, as long as you sell it for private purpose it doesn't matter.

However, nhb is right. Even if the exploit does not contain hboot code, we can not just patch hboot and distribute it.

distribute the exploit, however is leading us into a shadow corner of right.

The approach of getting uboot to work may not infringe copyright, but it would surely need some bricked wildfires before being usable.

---------- Post added at 09:42 PM ---------- Previous post was at 09:39 PM ----------

At least in my country, anything cracking the SIMLOCK IS illegal
[HTC Wildfire S] :
Yeah, we could use UBOOT. Stupid idea, but if we can recreate software from our own code, that performs the same stuff another software does, maybe we can write our own HBOOT, pre-patched. (Please don't kill me!!!)

I'm sorry. I'm so sorry.
[HTC Wildfire S] :
I hate the law!

Sent from a Time Lord, via his TARDIS.
[HTC Wildfire S] MrTaco505:
Ugh..u fry my brain with those long comments :D
[HTC Wildfire S] a.s.j:
That is what is called "the German perfection" :D

Indeed I agree with all NBH said (even not being German). I asume, that without precise analysis of whole the "problem" we can not go on, but we still try again and again. I am into it also, and I must say, that I doubt, that anyone would sue us for breaking HBOOT while they break the GPL license too ;)

@NBH: Do you think, that you would be able to create HBOOT like program, that would do it for us without using the original one?

And also, if the NAND write protection is within the kernel... how come that on the other devices (like my DZ) it was enough just to get temp root an dd the image to NAND with using psneuter utility? Would that be possible, that this one and possibly some part of gFree is overcoming this security? Or is it just so, that the kernel in WFS is different, than the one in DZ? I'd guess the kernel is being fairly the same and differs only in driver modules, or ma I wrong?
[HTC Wildfire S] no.human.being:
Certainly not. Too much knowledge about the controller's internals required. Porting UBOOT will be hard enough.

The important thing with the Desire Z (Vision) is that it uses an MSM7230 processor and a NAND chip from SanDisk of part number SDIN5C2-4G, which has an integrated controller (so called "eMMC-module"), that is much more complex than the memory controller that resides on the MSM7227 processor on the WFS. The DZ's memory controller is doing wear-levelling and bad block management on its own and, on the kernel side, is controlled by the "mmcblk" driver, not the "mtd" driver. We assume that the restriction that prevents us from erasing the Radio partition on the WFS resides in the "mtd" driver. On the DZ, it's not the "mtd" driver that is used for storage, but the "mmcblk" driver, since that's the protocol that this memory controller is speaking.

I don't know what psneuter does, never heard of it. Always thought that GFree was doing the entire S-OFF.

GFree is open-source, so we already know what it's doing. First it runs this strange "needle and haystack"-algorithm. I think that this "maps" the partition 7 (Radio partition?) while the system is already running (we "map" it during boot using kernel parameters, that's why we don't need an exploit for mapping). Then it dumps partition 7, patches a bit (secu_flag gets patched at address 0x00000a00, it's the least significant bit, CID and SIM-lock are also patched at some other addresses) and writes it all back. No need to erase the memory on the DZ before writing it back, since the memory controller supports in-place overwriting, doing the "read-modify-erase-write"-cycle by itself so that it's transparent to the kernel.

We can't do what GFree did, since we couldn't find the secu_flag in the WFS NAND. It's either strongly obfuscated or in some "special storage" outside the "normal" NAND area.
[HTC Wildfire S] a.s.j:
Well, that what I was affraid of. Well then, I am not able to help much, I can only throw some ideas, cause I do not own WFS. I am following this thread because my girlfriend has one and she is getting mad from suffering low internal memory space :D

Anyway, if I can help somehow, I am willing to do so even though I have not much spare time (to busy working :( )

I just thought, that it may be possible to map unmapped memory on running device and not be relaying on the bootloader... Would that be possible or impossible too?