yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] :
It's just a string saying that the USB is plugged in and HBOOT can detect it. Maybe HTC engineers have a way to communicate with HBOOT, like we can communicate with fastboot.

If anyone is wondering where einstein.frat's (the asshole) and me and *se-nsei's replies are, they have been deleted, because I reported his post, the mod looked at it and removed the post and warned this "einstein" genius.
[HTC Wildfire S] Antagonist42:
Running through fastboot and adb works fine although I ran malez on it's own and no joy, ran it after starting EUU and managed to get something on the phone, now after sticking files in IDA came across that my phone ACER E320 and the ACER Iconia Tab share same coinstaller settings an no other phones, if say settings for writing to nand are set before reboot on reboot handset would be given a random pid from pc but if drivers are 'still' running phone would be set to see that com port and pid to expect otherwise you would connect with just user rights and unable to write. Other than that I can't see why you'd have different pid's and com ports and be specified for different handsets if it's just a basic connection through USB :confused:
[HTC Wildfire S] :
well im back from vaction everyone. Dev week!
[HTC Wildfire S] no.human.being:
Same here. Back from vacation too. Was attending a concert in London, together with a colleague. It was just totally awesome, you guys certainly know how to rock! :D

EDIT: Post #500 btw. :D
[HTC Wildfire S] *se-nsei.:
welcome back devs :)
[HTC Wildfire S] :
YOU WERE IN LONDON! WHY DIDN'T YOU TELL ME! I LIVE IN LONDON! :mad:
[HTC Wildfire S] *se-nsei.:
Lol me too. Lol that post sounds so wrong.
[HTC Wildfire S] hahahafr:
Welcome back devs. We are still all following this thread.
[HTC Wildfire S] :
Now that I've read it, I just realised that the last sentence is messed up. I should really pay attention when typing. I am deleting that sentence.
[HTC Wildfire S] Antagonist42:
Welcome back ... and my next thought lol

Glad you enjoyed the time off guys ;) and welcome back :D

Ok now .... SMEM_SPINLOCK_ARRAY .... only thing I've come across to do with these is basically to 'tie-up' system addresses or make them inaccessible, now reading this doc under - 5.1.1. Allocating custom data types for sharing - I'm not sure if this is part of boot procedure (suspect it is) you get the SMEM_SPINLOCK_ARRAY then SMEM_MEMORY_BARRIER_LOCATION and then SMEM_LAST_FIXED_BUFFER = SMEM_MEMORY_BARRIER_LOCATION. Now this is where I'm going to have to do a shed load of reading again to find it but I'm almost 100% positive that I have read that there are specific com/or/pid's that you communicate 'directly' with fastboot so my idea is - if you ran EUU while phone is running android, opened ports etc with authentic software com/pid could be lodged into smem, system reboots into fastboot, bootloaders pickup the com ports and if have matching com/pid to connection you gain supervisor access, if it doesn't match you only get user access and are unable to flash.

Seeing as there are checks all over the place for serial numbers, CRC/SHA model/radio/kernel checks you wouldn't need to be extreme to keep people out, only not to let those who don't know what to 'peek and poke' here and there from gaining access..... even to the point that I can't even get an img dump out of my phone :mad: and dd don't work, can get size etc. but a dump I get denied permission :(
[HTC Wildfire S] Antagonist42:
Updates

More NAND datasheets, MSM sheets and other odd bits and pieces there ->O<-
[HTC Wildfire S] :
Most of the time I have no idea what you guys are saying. I'm like a newborn baby.

Anyway, today my SATA to USB enclosure came. Using it now. I had a 500GB HD from a computer that broke a while ago. It's actually 465-466GB. I had unscrew the HD casing, connect the adapter thing (carefully, easy to snap the connector of (I nearly did that, I bent it)), put the whole thing into the rest of the metal casing, screw it nice and tight, and plug it in. The drivers installed automatically. Then came the dirty work (ish). I deleted the two partitions, easy. Then came the EISA config. You can't delete that from the GUI, and if you wanna do it from the CMD, then you need the knowledge. It's quite simple. First, do this:

diskpart

Wait for it to load.

list disk

check which disk number is your HD's. I'm assuming it is 1.

select disk 1

list partition

there should only be one partition, the EISA config.

select partition

I think you might need a number, if there are multiple partitions.

delete partition override

the override parameter is there to override the safety (since it's a EISA config, and is protected), but theq86 or NHB might say "disengage-the-safety".

Then you assign a letter from the gui and format it if you wish. Maybe now I can do some more developing, cos I got the space!
[HTC Wildfire S] jimworm:
Revert?

Question, just a noob one. will this process reset or revert my installed ROM or will just update my HBOOT and then proceed to my desktop and behave as usual with nothing untouched? thanks :)
[HTC Wildfire S] theq86:
When we are ready we will only patch the hboot. and even just some byte of it. it will not touch your rom, kernel, recovery or any other area.
[HTC Wildfire S] CyanogenMod.90:
Hope that you guys find a way to s-off :)
[HTC Wildfire S] :
Have you been on holiday too?
[HTC Wildfire S] no.human.being:
Right. However, I'd still do a nandroid backup just in case, even though the chance of damaging your data is fairly remote. Bricking your phone is more likely and a nandroid backup may come in handy after you got your phone back from repair. Remember that we're patching around in the Radio partition and damage to the Radio requires hardware methods (JTAG) to fix most of the time. Even though I've got the equipment for such a repair, I do not have the skills, so let's just hope that we don't f*ck up anything lol. :D
[HTC Wildfire S] :
Haven't those embedded devs at your Uni told you how to operate OpenOCD?
[HTC Wildfire S] Antagonist42:
C'mon now, they probably talk a virtually different language, it's like Devs answering our questions.... thinking DOWN to our level for too long gives you a headache :D :p

n.h.b. hope that addy gives you some insight if you can understand it? :confused:

**Updates** MSM7627 Chipset Training Baseband, How Dalvik VM Works, Qualcomm USB Host Driver.
[HTC Wildfire S] :
Guess you know how I feel then, getting an answer as long as an essay, that hardly makes sense.
[HTC Wildfire S] heavy_metal_man:
Any updates guys? Things seem to have slowed down somewhat .... if you guys are struggling to find the time could you put up instructions on how to try build the kernals with the edited mtd so others could try??

sent from my android powered beast!
[HTC Wildfire S] *se-nsei.:
Devs, does the first post need updating at all? If so, please pm me with a summary or post a good summary post for me. :D
[HTC Wildfire S] :
I'm gonna make a guide saying how to build a basic kernel, once I've finished making mine. Someone's probably gonna beat me to it. It is true though. This thread has slowed down considerably since the beginning of April. Despite this, I still understand why. We wanna take vacations and stuff, because this is hard work. This has been going on for at least a year. We're all tired of this. Is this our downfall, and XTC's victory? Maybe not. We need expert driver writers or something.

I know it's already happened, but let's get this thing back on the portal, stating our problem. Maybe we can get some more fresh blood. Click the Submit to Portal button. I'm willing to do almost (well, considerably less then almost, depending on what it is) anything for us to get S-OFF. So, click the Submit to Portal button!!!!
[HTC Wildfire S] no.human.being:
Some ideas.

1. Instead of writing directly to the Radio partition, we might consider letting some firmware component (HBOOT itself?) write to it.

1.1 Some time ago, I've come across a site which stated that an HBOOT image written to the "misc" partition of the device ("/dev/mtd/mtd0") will get flashed by HBOOT on the next reboot. I don't have this reference anymore though, so I can't check exactly what they stated. Remember that an RUU can flash the HBOOT. This might be the way they're doing it. Anyhow, an HBOOT image (!!) certainly won't be signed, right? After all, the definition of an image is that it contains exactly what's supposed to end up on the storage medium and the signature is not in NAND, so if it's really just a memory image, then it won't be signed, so we can write our patched HBOOT to "misc" and have the "stock" HBOOT flash it.

1.2 Can the HBOOT be flashed via Fastboot?

2. Does anyone have a hint where exactly in the kernel's mtd driver the OOB is checked for the "locked" state etc.? It expect it to be quite a simple decision in the style of ...

if (!check_locked())
erase();

... pseudo code of course. :D

The change will be quite easy. Just comment out the condition statement and rebuild the kernel. Then we "just" have to either integrate our modified kernel into the CWM image and be fine. Of course our kernel will write "Linux OOB format", not "Radio OOB format", but somehow I have a feeling that this is uncritical. After all, an Android kernel can read the Radio partition (which is in "Radio OOB format") and if it works this way round, why should we suppose that it won't work the other way round?
[HTC Wildfire S] theq86:
That's too vague. Plus, hboot is 512 KiB, misc is 640 KiB. Where to put it? It would maybe affect the content of the misc partition, thus causing a so called USB brick. Can't imagine it to work, either. This would mean htc left us a direct way to inject the bootloader? No way.

Remember, I stated the RUU does not do anything than uploading the rom.zip to the phone and let the bootloader do it's update stuff. An xda member now reverse engineered the proces of a RUU.

http://xdaforums.com/showthread.php?t=1585060

this proves my thought

Well, at least the ENG HBOOT is definately signed. It's not sure to say stock hboots are not.

On S-OFF phones, yes. On S-ON, no due to signature fail.

If signature fails because

a) the signature is wrong

or b) not existent

can not be proved.

Somebody already posted the section in this thread some time ago.
[HTC Wildfire S] no.human.being:
Size of "misc" varies. It's either 1 MiB ("old layout") or 640 KiB ("new layout").

"USB brick" means? USB controller not functioning anymore?

Right.

You can expect bootloader unlocking to disable at least some signature checks, otherwise you couldn't flash a custom recovery. Is the recovery partition the only memory area for which the signature check is disabled?

Also where is the phone's partition table stored? Remember that you can pass the "mtdparts=..." parameter to the kernel, but if you don't pass anything, you will still get some "default" mapping. The kernel has to get it somehow. Is it "hard coded" in HBOOT? How does it get to the kernel? Will the HBOOT pass a "default command line" to the kernel if nothing else is specified? If we could modify the partition table, we might trick HBOOT into thinking the recovery partition lies where actually HBOOT is, then we could save a patched HBOOT as PG76IMG.nbh and have it flashed by HBOOT. But likely the partition table is in the HBOOT code itself, so we probably can't touch it.
[HTC Wildfire S] theq86:
Good to know

Yes. In the beginning of the misc partition there are some values referring to usb and stuff. they are VERY important. Screwing these values will make the device not accepting usb connections anymore (within android, of course. bootloader will still work with usb) and also makes the system not recognizing the external storage. on a locked device without misc backup you are probably doomed then :D

Yep.

no check: misc, system, userdata, cache, boot, recovery

with check: splash, hboot, radio, radiocust, tp1, tp2, unlocktoken

I bought an Huawei Ideos X3 at tchibo because it was only 50 € ^^

It's a similar device according to using mtd drivers and stuff. radio partition is marked bad there, too. However, it was possible on the devices boot.img to inject kernel parameters by hex editing the boot image. On WFS it seems not to work :/

I also think the "partitioning" is somewhere in the radio or hboot. From it's point of view we have a 512 MiB memory and hboot flashes to specific memory addresses according to a "partition string"

Actually, there is no partitions, since there is no real partition table. only the mtd driver is able to "separate the access" according to virtual boundaries (mtd map)

Even if we could do your recovery trick, hboot would assume it flashes a recovery and would probably not try to bypass the oob locks (why unlock a not locked recovery area)

But maybe oob is just checked by the kernel?
[HTC Wildfire S] no.human.being:
Lol, "unlocktoken" is not actually a partition. The token is not written to NAND. HBOOT checks it and writes "HTCU" to "misc" on a match. :D

So the things that have signature checks in place are the same as the ones that aren't accessible via mtd under normal circumstances, which makes sense.

This is also how I understand it.

Remember that recovery is also locked unless you're bootloader unlocked. And probably in the NAND the "locked" flag will stick until you actually flash a custom recovery, since I don't expect the "bootloader unlock" procedure to "walk over the recovery area and remove the 'locked' flag". I think it only writes the "HTCU" string to "misc" and then HBOOT won't check signatures for the recovery any more and HBOOT is "unbothered" by the "locked" flag.

So in this sense, the HBOOT doesn't have to "bypass" a lock, it rather just "ignores" it. If we have "supervisor mode" (kernel level) code that issues an erase command to the NAND, it will get erased. The erase command will clear all out-of-band data as well, so after an erasure, a page is never locked, so after the erasure we will be able to write to it. The meaning of the flag is "locked" because the mtd driver interprets it as "locked". For the NAND chip it's just "2048 bytes of normal data and 64 bytes of out-of-band-data" per page. The HBOOT doesn't interpret the flag as "locked". Actually, it probably doesn't check for it at all, which is why it can write to the Radio area, e. g. when flashing an RUU. So why should it check "locked = 0" when flashing a recovery? I don't think it does. But as we can't alter the partition table, this won't be of much use actually.
[HTC Wildfire S] theq86:
What I don't get is:

HTC made the effort to produce a brand new bootloader with the ability to check a "flag" and disable sig check on various partitions to provide us an unlocked bootloader.

Why the hell writing HTCU to an accessable location instead to the radio area? That's dumb :D Like quick and dirty
[HTC Wildfire S] no.human.being:
Yeah! I also don't get it. They basically put their key in an envelope and placed it near (but not inside) a vault. :D

What's also very interesting is that, apart from this "out of band 'locked' flag", the NAND itself also has a volatile (!!) "locked" state (volatile means it does not reside in NAND, but in some "volatile storage" in the "controller logic" on the NAND package, so it will be lost when the chip is power-cycled).

Initially, when the chip is powered up, all blocks are locked and read-only from the view of this facility. Then, a special "unlock" command has to be issued to the NAND device to unlock blocks for write access. We have no idea, whether this facility is used by HBOOT to protect the Radio, since we haven't got that far. We're still stuck at the mtd layer not issuing the "erase" command to the NAND so we have no idea whether the "erase" would succeed if it was issued. However, since the NAND is always completely locked to begin with and HBOOT explicitely has to unlock pages anyways to enable the kernel to write, it's quite obvious that it will only unlock what really needs write access (which means certainly not the Radio area :D ) when a kernel is booted and the Radio area will probably only be unlocked when e. g. an RUU is to be flashed.

So this will probably be the next layer of protection. Technically, it's not difficult to overcome, as you can always issue more "unlock" commands to the chip to unlock further pages, so "unlocking more pages after HBOOT is through" is technically possible. However, I'm not sure whether the mtd driver has the facilities that are required to issue such commands to the NAND module.
[HTC Wildfire S] theq86:
but hboot has to unlock the radio nand areas because it writes to the nand while upgrading the software.
[HTC Wildfire S] no.human.being:
It doesn't have to. All pages start out locked when the device is powered. For every page that is not supposed to be locked, some firmware component (and I'm sure that HBOOT will do this as it is the first component that needs write access to NAND, the Radio is booted before HBOOT, but I think it does only read!) has to issue an "unlock" command to the NAND. You don't have to "unlock" pages in order, so you can always "unlock" more pages "on demand" at a later point in time.

So HBOOT can do the following.

Boot boot boot, then do a decision.

Possibility 1: I need to flash an RUU. "Unlock" all pages that are affected by the RUU and write to them.

Possibility 2: I do not need to flash an RUU. "Unlock" just pages that are accessible for the ROM/Recovery, then load and boot the kernel.

So the ROM/Recovery kernel will probably find the NAND device in a state where only the "visible area" (which means not the "Radio area") has been "unlocked". Now of course the kernel-level ("supervisor mode") code could issue more "unlock" commands to unlock the Radio pages as well, since there is nothing the HBOOT can do to "disable the unlocking" (well, technically there is a "lock_tight" command, which disables the "unlock" command, but this can also be reverted without rebooting the device, so it doesn't actually change a lot, it's just more work :D ). However, I'm not sure whether the mtd driver is "smart enough" to do so. Note that "flash_unlock" utility returns "operation not supported", indicating that the NAND device doesn't support locked pages. But it might be that the actual device supports them, but the driver for this device is lacking support for these commands. If this is so, we require even further modification of the mtd driver to enable it to issue "unlock" commands to the NAND chip.
[HTC Wildfire S] theq86:
Well, It seems that if we do not coincidently find a security leak in the current configuration we will have to write any low level component ourselves. that will be hard and long time taking.

Gonna catch a Sensation next month. I know you want a SGSII but I really don't like it :D

Later on I'd like to have hands on HTC One X although it has no sd card.

so if we got further I'l be much more brave with my wildfire S xD
[HTC Wildfire S] no.human.being:
Yeah, I'm eagerly waiting for SGSII prices to drop. Any new rumours about SGSIII release date? I'm confident that prices will drop like crazy once the successor is out. :D
[HTC Wildfire S] theq86:
Well, the latest I know is that article: http://www.computerbase.de/news/2012-02/samsung-galaxy-s-iii-wird-erst-mitte-2012-praesentiert/

But don't expect prices to drop hard. Now it's over 415 € at all stores, but I doubt it will fall below 380
[HTC Wildfire S] bobdamnit:
I just found a SGS2 in my local Taco Bell's parking lot lol.

ESN is bad, so I'm almost positive the phone is stolen, but the thing looks brand new lol. No scratches anywhere. Also, its never had service as far as I can tell. Usually even if it had service, it still has a phone number attached to Android. (In the About Phone settings.) This does not.

I'm holding it for a while. (With the battery out lol) Then its getting sent to a dev as a donation. (Kudos, Simon. You owe me lol)
[HTC Wildfire S] no.human.being:
I rather expect it to fall to a bit above 300, say 320. It's been released in April 2011 and it's still over 400 €, which is just far too much for a one-year old smartphone.

The WFS was released in May 2011. I bought it shortly after the release and paid 280 €. Now (April 2012) you can get it new for 180 € from Amazon, which is almost a drop of 36 % from the original price over the period of a bit less than a year. Also note that "higher end" components (which the GSII is) usually lose value much more quickly than "lower end components" (which the WFS is), since they get outdated very fast.

Grab a Radeon HD (x)970 and it'll probably be half the price when the Radeon HD (x+1)970 comes out, as the ones buying "high end" will always be in for the latest and greatest, no matter how much it costs, so demand for the "old series high end" model just won't be there. Grab a Radeon HD (x)670 or (x)570 and it won't drop nearly as much. Grab a Radeon HD (x)470 and it will barely drop, as the "MS Office user" doesn't care whether the device is from the newest generation or not. :D

Now the GSII was certainly "high end", it's a year old and it's still freakin' expensive, since there's no real "successor" out yet. But that doesn't mean that the GSII ain't dated. It's just delaying the price drop, since currently there's nothing the Samsung fans can migrate to. But once there is, I expect the drop to be very sharp, as there's now a huge gap between an April 2011 and, say, a June 2012 device with just nothing in between.
[HTC Wildfire S] theq86:
Well, that makes me hope my Sensation drops, too now after One X has been released :D
[HTC Wildfire S] :
Hey guys JUST had a great idea, based on reading this, and working on my unlock tool. You know how we are patching the nbh file. Why not take that file and add to a zip like we do with the recovery. Heres the catch, we do this on a goldcard. Hboot should pick it up and let us use it and update even on a goldcard. Someone care to comment on my idea?
[HTC Wildfire S] theq86:
hboot checks the signature on everything inside a zip package. it does not matter which way we try to flash something. Goldcard will not work. It does not bypass signature check, it only allows flashing of different CID packages. So that won't work :/
[HTC Wildfire S] :
Hum.. Could we mount HBOOT as something else and confuse hboot? Like mount it as recovery? Then we could update it if we renamed the contents of patched hboot recovery.img ? I dont know how dangerous that is though lol
[HTC Wildfire S] theq86:
well, we could map hboot as "recovery" but if we try to flash it the write protection will still be on place because physically we write to the radio area.

as we have discussed above we can unfortunately not change the hboot "partition table" so we can trick hboot directly.
[HTC Wildfire S] :
Hum, other ideas of mine involve JTAG, and using this kernel i have.. Its a sense kernel, which should allow writing to radio. If you want i can PM you this kernel in boot img form if you wish to try it (dont know if its gsm ready either)
[HTC Wildfire S] theq86:
what have you changed in your kernel to make the radio writeable?
[HTC Wildfire S] Lt.Win:
Awesome, making progress! If you need any testers, i'm here!
[HTC Wildfire S] *se-nsei.:
@no.human.being & anyone else working on a solution:

you have testers all over the forum, don't be scared to ask them :) !
[HTC Wildfire S] matt5eo:
I need also a tester,

Wildfire S cmda version can be unlocked with the diag files, and the xtc have to use a cable for the sim slot. So we can guess that it sends any data to the sim slot. I read that a user flashed the virgin ruu onto his gsm wildfire s. We are trying to get this work. But we need tester.! Would anyone work with us.?

Sent from my nearly brilliant HTC Wildfire S
[HTC Wildfire S] :
CDMA and GSM Wildfire S' have different Phone ID though. Not sure how that would work.