yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] :
I know how to build kernels, and add in features. I could build from AOSP or Sense source. The only problem would be that implementing it into recovery would mean we need a good, solid device folder. then just replace recovery_kernel with the one I build. I cant really do that as I dont have time. I can build a kernel though if I get the source or features we need to enable. I assume its just something low level. But what Im wondering is, since we are using CWM in the first place we have to unlock the bootloader. I wonder how Alpha-Rev does it. If we unlock, and then install custom recovery, this could work, with a kernel with proper low level drivers. I have the source infront of me. Next week is my spring break. So I could deffinately look into this. I was thinking that, maybe we can find out what that maybe we can replace HTC's unlock bianary with the one out of the bootloader tool aromazip in the dev section. That may just work. Im soff and unlocked (CDMA) so i cant test it. I know that since Unlocked is controlled from MISC. After we fake SOFF, we take the misc for gsm and for cdma from a unlocked donor. Then we just take that and do flash_image misc /path/to/donor/misc.img That would then unlock the bootloader without data loss as far as I know. Maybe we can boot CWM from the Sd like on a nook. What do you think? Im going to stop rambeling for a while... lol
[HTC Wildfire S] :
@NHB, thanks for the info. Have you read my other questions? Go back a page. Also, when I downloaded the cross compiler from Code Sourcery, I got a bin file. Is that meant to happen?

I'm out of ideas in getting S-OFF. All I can say is, pretend that you have to get S-OFF as quickly as possible, or else something bad happens, like the world blowing up, or your house blowing up, or your sister breaking a nail. Are you making a kernel it mtdblock driver?

EDIT: I think I was being stupid again. Forget the bin file question.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] SeeKai:
You'll probably will have to 'chmod +x path-to-bin-file' and then execute it (just type 'path-to-bin-file' e.g. /home/user/downloaded.bin) to get it installed.
[HTC Wildfire S] :
It's OK now guys. I deleted it and instead got the TAR Package, and I extracted it and added the bin FOLDER to my PATH. Getting ready to compile. NHB, you have read my kernel questions, right?
[HTC Wildfire S] :
Thanks that actually helps a lot. The whole donor idea was mostly just that its really easy to flash_image one misc.img pre-unlocked. I want to unlock the bootloader without htcdev. I can easily S-off now, but its not as automated and cdma has no leaked radios or hboots, so unlocked fits most users just fine. The CDMA side has the PG76DIAG.zip and nbh files, so really im throwing some help towards GSM if I can help.

I did have one S-on user test flashing a misc img with temp root. It worked and since it was my MISC partition, it was UNLOCKED like you said. Im just trying to figure out a way right now that also can pull the misc, like you mentioned, and patch it. Included in this, I want to change the version back to 1.0.0 in misc so I can dowgrade later on if they want S-off, and then upgrade back to updated hboot to be soff and unlocked (with fastboot commands)

Im going to try running the bootloader tools in shell. Will report back to share if it works.
[HTC Wildfire S] pther:
No i didn't yet. I already modified the kernel driver some more, but i want to run some more tests before actually putting it online.

In the meantime i'm suffering from this condition called 'social life' which seems to be tainting all my free time :D
[HTC Wildfire S] :
Well I tested the bltool and guess what, it worked. I am the first to get unlocked without HTC at all. first I ruu'd to stock. Then i took my batch script, ran it, which updates bootloader, then reboots into the rom. Then i used temp root, and ran dump_img. I got this and modded misc with bltool. Then flashed it. Booted back into bootloader to check, and there it was. My shiny unlocked bootloader with no data wipe and no htc connections. Can you refer me to the thread where there trying to do this? I want to tell them about it. Im going to finish up here and make an exe and publish. One for CDMA and one for gsm
[HTC Wildfire S] :
Well done! You will be remembered. Contact theq86 (PM) and tell him ASAP. You've saved thousands of warranties. Well Done.
[HTC Wildfire S] :
Thanks, I PM'd him with some details. Expect a cdma release then universal release with a prequisite of unlockable hboot already installed
[HTC Wildfire S] :
Too bad for those who have already lost their warranties. Your next project is to hack HTC and delete all token records.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] MrTaco505:
Quick question, do you think an exploit executed via fastboot be more efficient than via adb shell like revolutionary for example?
[HTC Wildfire S] :
Well, fastboot is meant for this stuff. ADB is for other things, just generally monitoring the device.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] :
Adb shell is just like using the terminal in linux. A fastboot method wouldnt work as it wiped data. And does exactly what im doin. The only prequsite is the stock recovery and sense
[HTC Wildfire S] seaskyways:
Actually last night I was thinking to do that thing before you do it :D because i simplified the temp rooting (check my signature) ... And which could be applied on any phone status including S-ON+Locked BL , that will give us enough previliges to flash the misc which is responsible for the BL unlock , which will result a FULL unlocked bootloader ! perhaps this could be a universal exploit ! good one NHB and simonsimons ! now I want to check the bootloader batch you made , cuz I might need it , is the bootloader 1.09 , or 1.08 ??
[HTC Wildfire S] :
Non specific. Works for any HTC phone. Well, any unlockable phone. Just update your bootloader to any unlockable and let my tool work.
[HTC Wildfire S] sythe179:
so, if you can not use the HTCdev method first, you cant s-off with this method?.

australian telstra users left again..
[HTC Wildfire S] *se-nsei.:
Can your method provide s-off permissions? For example, can you set custom mtd partitions successfully when installing a new rom?
[HTC Wildfire S] heavy_metal_man:
from what i can tell this method will unlock the bootloader like the htc unlock does, only difference being that it * shouldn't* wipe your phone and you wont be on htc`s data base.

so by using this, in-turn with the s-off exploit (when it is finished and working) will give you full s-off without htc`s knowledge :cool:
[HTC Wildfire S] :
I'm going to work with the soff developers and eventually add in that soff. One for cdma doesn't work. But you can try
[HTC Wildfire S] no.human.being:
Why an exe? Build your tool to run on the handset itself, not on the computer. Computers are different (x86, x86-64, PowerPC, SPARC, ..., Windows, Linux, BSD, OSX, Solaris, ...), handsets are not (all ARM). If you need to run code on the computer, you're going to be more ristrictive than you need to. Our exploit runs on the handset only, requiring only Android SDK tools on the host machine (and these are ported to lots of platforms). Unlocking the bootloader should be also possible using ARM code only and without any code running on the host. Try doing it that way.
[HTC Wildfire S] theq86:
@simonsimons34

nhb is right. it even makes it more easy for the end users. your whole batch file could be ported to a native executable. (like e.g. zergRush or my bltool)

To get you started have a look at some pages back in this topic. nhb explained the steps how to set up a toolchain to develop native linux executables for arm.

then have a look at my github repo: https://github.com/theq86/bltool

I released the sources of my bootloader controller. it contains:

* the update.zip package of my bootloader controller. After first unlock and installing it you can control the bootloader state by this

* the bltool sources (the tiny application that patches the misc image)

You can use the bltool.c file as a skeleton for your application. I even permit you to integrate the source into your own application (which would then make you independant of having the bltool executable)

Just use it as you wish. If you have any questions regarding the programming stuff and how something is done just ask me.
[HTC Wildfire S] no.human.being:
Can the tool be directly used on an mtd device or do you have to dump "misc" to an ordinary file, then run the tool on that file, then flash the file back to "misc"?

I ask since you use "fseek" on the file handle and I always thought that an mtd only supports sequential, but not random access.
[HTC Wildfire S] theq86:
Well, I sticked to the unix philosophy. one tool, one task.

you have to dump the misc to an image file, modify it and reflash it.

I did not test it directly on /dev/block/mtdblock0 so I don't know if that would work. it definately does not work on /dev/mtd/mtd0 since it is not seekable.
[HTC Wildfire S] no.human.being:
Just asked since the S-OFF tool loads the HBOOT into a buffer in memory, then patches that buffer, then erases the entire mtd, then writes it all back.

If one could seek on the mtd, I wouldn't have to write the entire HBOOT back, but only the portions that were modified, saving write cycles on the NAND cells that aren't changed. But since you have to write the entire partition back anyhow, my approach already seems to be the least invasive way of doing it.

EDIT: Forget it. HBOOT is only 4 pages "large" anyhow. So even if one could write each page individually, it probably wouldn't save anything, after all you can't write anything smaller than 128 KiB on the NAND. :D

EDIT2: I wonder how the file system (yaffs2) driver is doing it, after all it won't write the entire partition on any change. So it seems not to use the mtd driver, which interesting, since it's a violation of the "layering" concept in the kernel. On "desktop" kernels, the file system drivers are required to use the device drivers for accessing storage, but obviously that can't be how it's done here.
[HTC Wildfire S] theq86:
well, as you know an mtd partition is accessible via 2 methods:

raw access via /dev/mtd/mtd*

block access via /dev/block/mtdblock*

When mounting any yaffs2 partition, the mount call refers to the mtdblock driver. e.g. mount /system writeable would be:

on GSM variants:

mount -o rw,remount /dev/block/mtdblock3 /system

on CDMA variants:

mount -o rw,remount /dev/block/mtdblock5 /system

I don't know if it only works with "file-systemed" partitions like system, cache, userdata

Never tried it with a raw partition.

Edit: I bought a 50€ smartphone at Tchibo (Huawei Ideos X3) which also uses mtd partitions and nand. I will try on this phone before destroying my misc partition again :D

But It'll take till after easter. I',m at my girlfriend's appartment and have no dev environment here :D
[HTC Wildfire S] no.human.being:
All "Android" kernels I know ("stock", CM and CWM) are built without "mtdblock" driver support. Try fopen("/dev/block/mtdblock3", "rb") on any of them and it fails. There's just the device special file created with "mknod", but no driver in the kernel that would handle them. No idea why you can mount them. Seems like some real obscure black magic, but the "mtdblock" driver is not there. :D
[HTC Wildfire S] theq86:
ok, didn't know that. but they MUST have a reason, cannot be just dummy files since access to the yaffs partitions is implemented.
[HTC Wildfire S] no.human.being:
Yeah, probably there's some "in kernel" interface that's not working via fopen(...). That's what I mean with "black magic". :D
[HTC Wildfire S] :
What is a bootloader controller?

---------- Post added at 08:14 PM ---------- Previous post was at 08:09 PM ----------

WHAT? How did that happen? I thought it was forbidden by the phsyics that define the universe that a geek simply cannot have a GF!?!?! :eek:

That is impossible!

And it's not fair! I don't have a GF!! :mad:

Then again, I don't have time to create quotas for the use of my lovey-dovey resources! And right now my lovey-dovey CPU can't be overclocked! It's at 1Mhz. All my lovey-duvey resources are being used for the creation of my kernel!

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

Forget I said all that.

NHB, have you read my kernel questions?
[HTC Wildfire S] seaskyways:
There's a noob question here , sorry ...

Can't we mount the mtd7 (hboot) by uploading our ROM kernel to it , which will boot a full android interface with the hboot there ? then we could modify the hboot at will , can't we ??
[HTC Wildfire S] :
The reason I made an exe is so there isn't any error in extraction. Everything is ran in Adb shell. Really of the utility doesn't work, then soon you can open up a sh script and follow its directions. I do want to say this, its a universal HTC tool for unlocking. I will be modifying and improving. It's only a beta ;)
[HTC Wildfire S] theq86:
it is a tool flashed with cwm that can easily change the state of your bootloader to locked, relocked or unlocked, as well as changing the phone's main version to 0.0.0.0 to flash any ruu that has a lower version.

well, a professional programmer is not necessarily a geek. but if you only spend all your lifetime with a computer then it's probable you get no gf :P they need as much attention as a computer. and one wrong command/word can brick everything :D
[HTC Wildfire S] :
Lol so true. On topic, I looked throut a few pages (not going to look through 200 though) and cant find where you posted your exploit. Can I have a link to it, precompiled or in source. I want to look through and see exactly what its doing before i start kernel work this weekend.
[HTC Wildfire S] :
I think I know what I'm doing wrong. Don't get me wrong though. I do have a peripheral life (see what I did there, if you didn't understand, it means "external") that is enjoyable but has its ups and downs. Do you think that bootloader controller works on girls too? There is someone who I very well know that could do with some...... Um...... unlocking.

And can someone answer ny kernel questions please! They are about two or three pages away. I really need to compile that kernel.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] rockdev:
I used this method below for my telstra phone worked well.

http://xdaforums.com/showpost.php?p=21231962&postcount=2

I would like to thanks all you guys for your great efforts at trying to achieve s-off keep up the good work fella's.

cheers
[HTC Wildfire S] inconn:
Whaddya mean? You got S-off?!
[HTC Wildfire S] heavy_metal_man:
one he used that as a work around for his phone not being able to update to do htc dev.
[HTC Wildfire S] ShadowAS1:
He doesn't, he just unlocked the BL :P
[HTC Wildfire S] no.human.being:
Exploit (including full mtdutils build and documentation) is here.

Source is currently not provided due to intellectual property concerns.
[HTC Wildfire S] *se-nsei.:
You wanna s-off a girl?? Well we better start another campaign ;) haha.
[HTC Wildfire S] no.human.being:
@simonsimons34: Since I didn't provide any source yet, I want to give you some insights. Basically what it does is ...

1. Open a file handle (file name you provide via argument, usually "/dev/mtd/mtd7" since that's where we map the HBOOT area to).

2. Load its contents completely into RAM.

3. Verify that it's a valid HBOOT image and that it's not already patched. If any of the assumptions fail, abort with a suitable error message which states what exactly failed.

4. Locate the HBOOT's "pivoting area".

5. Use the information from the "pivoting area" to locate the routine that asks the Radio for the secu_flag. (This should allow us to "adapt" to changing HBOOTs, as long as this area stays at the same location and in the same format.)

6. Overwrite that routine with the machine instruction equivalent of "return 0;" (the calling functions check for zero = S-OFF or non-zero = S-ON, so we always return S-OFF).

7. Update the "pivoting area" to reflect the changes and leave a little "mark" in this area that we can later use to check if it was our exploit that did the changes, should we ever have reason to do so.

8. Call "flash_erase" on the file handle.

9. Write the patched image back to the partition via the file handle.

10. Flush, synchronize, cleanup, exit.

Step 8 is the one that fails and due to this, step 9 also fails. If you do it on a file holding an HBOOT image instead of an mtd, step 8 is not neccessary and the changes are successfully performed. If you don't supply the "--disengage-the-safety" parameter, step 8 and 9 will be skipped, so that no write-operations occur on the partition (useful if you want to test, whether the tool COULD patch your HBOOT, without actually performing any changes to the phone's firmware).
[HTC Wildfire S] :
Guys my exploit source is up now. Im looking through the soff exploit. I really wish source was out, lol. I think I may know where to start. Pulling things back on topic. What has universal support? Ubuntu. So why not make a kernel from its config, but just modify it to be bootable. Then we use CWM, but with this modified kernel from ubuntu. We could TRY removing all the main recovery features except adb. I want to take a look this weekend if i can. I put this project, my unlock, and kernel building top on my list right now. We are gonna get this thing done.

EDIT:

Looking at the post above, Erasing the HBOOT Is dangerous is it not? Something you dont want to fail I know that for sure. But since the flash_erase is whats failing, could we make a kernel, and OS (very basic, it boots to a screen and says what we are doing. basically stripped down CWM with a new kernel, and of course maybe some modifications to what tools are present.) I have a bunch of ideas with this. I think ill throw a go at my custom "recovery" idea.
[HTC Wildfire S] *se-nsei.:
Sounds good
[HTC Wildfire S] :
Yes, we could get the config from Ubuntu, but I think NHB would prefer to get it from Fedora, because he has Fedora.
[HTC Wildfire S] :
Hey se-snei, I think you should update the OP. If you've used htcdev, your warranty is already gone. If your phone breaks and you take it to the service center, then you can only hope that he believes your phone got shipped with S-OFF or something like that. They still got your token. Maybe after this S-OFF thing is done, we can start another campaign that can have something to do with tokens. Maybe this time you can put "Calling all hackers! HTC is being hacked!". Back to the point, instead of saying "you can get your warranty back" say "don't have lost your warranty for nothing!" or something along those lines. Don't wanna get peoples hopes up to high. ;)
[HTC Wildfire S] theq86:
Well, I would not recommend taking a desktop distribution kernel as source. These kernel sources have so many dependencies, most of them architecture-specific for x86/ia64/amd64 etc (normal pc platforms)

If we'd to use that code we would really have to strip it heavily down to be compileable for arm.

Getting a vanilla kernel compiled is not the problem we are encountering. The problem is to properly pack it into a valid and bootable boot.img.

There is a tool called mkbootimg which does this packaging for us. But somehow those generated bootimages are not able to boot. Since the kernel is never booted up properly we can not say it's the kernel which fails.
[HTC Wildfire S] :
True. We do not want to waste our time doing that. This whole thing has been going on for long enough, a year at least (including before bootloaders were unlocked).
[HTC Wildfire S] einstein.frat:
off topic Im Soff through clip but when I upgraded to 2.14 hboot theres this useless text in hboot that says LOCKED but I can still flash roms have root etc. Does this mean I still have warranty, hmm? So anything happens to it Ill just flash a stock RUU and recovery. Unless I get a brick it would be useless.
[HTC Wildfire S] aigaming:
I have that same text when upgraded but everything is working,so personaly i don't care;)

But, i would like also to know do we lost waranty...
[HTC Wildfire S] heavy_metal_man:
Hey guys, just a quick thought. I've been talking to a friend of mine ( who works as a repair man for PC world and is quite into development :D) and I talked to him about all our efforts and has asked are we sure the blocks are bad, or will the mtd not write because its in a different language? If so mabe we just need one that can understand that language :D:D

sent from my android powered beast!
[HTC Wildfire S] heavy_metal_man:
As long as you haven't filled in the htcdev website information then you should be ok, but stock hboot is always best for warranty ;)

sent from my android powered beast!
[HTC Wildfire S] no.human.being:
They are not bad in the sense that the transistors are malfunctioning. They seem to have a different "format" (flags have different meaning and/or are in different places) for the "out of band area". The "out of band area" is the part of memory that's not accessible using "normal" reads/writes on the device handle and is usually handled by the operating system, so whenever something (e. g. our exploit or the file system driver) writes a block to NAND, "appropriate out-of-band content" is automatically generated and written by the kernel to match the "payload" that has been written to the "visible" area of that NAND block. Remember the "out of band data" is mainly to correct errors in the "normal" data area, so the "out of band data" will mainly consist of error-checking and error-correction information for the "normal" data, as well as usage statistics for "wear levelling" by the file system, etc.
[HTC Wildfire S] *se-nsei.:
just a quick question OT: how much does your friend get paid for that job? :D
[HTC Wildfire S] heavy_metal_man:
So still stuck at the kernal? Bummer :(

sent from my android powered beast!
[HTC Wildfire S] heavy_metal_man:
No idea bud, but he has a nice house :D

sent from my android powered beast!
[HTC Wildfire S] :
Hum good point on the kernel. I can make a boot.img that will work for sure if you create a proper kernel.
[HTC Wildfire S] :
I'm not sure, but I think you only lose your warranty when submitting your token. Continue using your phone like that.
[HTC Wildfire S] MrTaco505:
Can someone give me a short basic summary on what is going on :confused:
[HTC Wildfire S] :
I knew you couldn't resist the urges of OT!

---------- Post added at 11:29 PM ---------- Previous post was at 11:27 PM ----------

AFAIK, we either need to create a mtdblock kernel, or we can create a kernel that has something to do with mtd. I think we're making a kernel. Better if some1 else answers this.
[HTC Wildfire S] Antagonist42:
More info if it's useful

Translated a few docs I downloaded and uploaded a couple that may be of interest right here ;)
[HTC Wildfire S] :
Anymore updates?
[HTC Wildfire S] csoulr666:
Found this on the Portal..........maybe a better way to communicate to the phone???
[HTC Wildfire S] theq86:
not really. there are at least 3 .NET wrapper libraries for fastboot and adb. I also programmed one some time ago.

There's nothing now we can benefit from that.
[HTC Wildfire S] Antagonist42:
Something I have come across is with pc drivers for USB more specifically as to communicating to mARM, fastboot etc as I found running qpsd gave differing com ports in recovery, fastboot, use, would maybe seem if we connect as normal may be seen as a 'normal' user, maybe using same process id's and ports (as with WudfCoinstaller driver maybe 005 as with my acer not standard 007) could maybe be seen as 'supervisor' if we have to fastboot the devices :confused: as read in files to do with communicating directly with fastboot, certain com with a pid set could set a register for read/write:confused:
[HTC Wildfire S] SeeKai:
That would be a very 'obscure' method since a program does not determine which pid it gets. The kernel does.
[HTC Wildfire S] MrTaco505:
Quick question, what is HBOOT PLUG USB?
[HTC Wildfire S] SeeKai:
In which context? Probably starting the phone in bootloader with the USB cable connected!?