yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] Antagonist42:
Roughly but not quite, don't forget that mARM processes most of the peripherals that are on the LSB (Low Speed Bus or EBI2) aARM is on the FSB (Fast Speed Bus or EBI1) dealing with user space running apps and the NAND'S DDR memory, both systems of ARM have access and relevant control for either EBI1 / 2, as you say aARM has control excusively over NAND (is that in a boot mode or full system running mode? or makes no difference?) this I think is partially true as to access or writing 'Except' which part of the NAND memory is 'Spin-Unlocked' which I think is controlled via either mARM or registers set through mARM to IMEM (verified with the access of Q-Fuses/Signature) to reboot the system with access to write to NAND 'And to spin the lock' {protected memory} to write to AMSS say at which time the 'system' area is protected as the lock is spun.

With the Micron NAND you can 'SET' how the pull-up to write on the NAND is done, either by Soldering a pin (or not - can't remember off the top of my head) and software programming the pull-up or it is only software doing the pull-up so previous systems may only have had NAND chips without this facility and maybe with the advent of NFC being rolled out it is being used now, which protects the NAND RADIO etc from being read whilst the Android system is running or unable to gain access because the spin-lock is not operated so no read/write or false reporting of read/write success.

And you maybe right that Revolutionary etc may have found out how to make the system 'pull-up' the write access but are ignoring the protected NAND areas so NFC may (I think) become vulnerable if there is nothing to stop it like passing a signature/Q-Fuse key.
[HTC Wildfire S] no.human.being:
Sure that you really mean spinlock? It's a mechanism for thread synchronization.
[HTC Wildfire S] Antagonist42:
Not specifically but found several points .bin reading with spinlock to do with NAND, there is also the lock and unlock which the whole thing is 'spun' and also using spinlocks to deliberately 'tie up' ports.... If I'm confusing things then my apologies as it's what I've been reading and come across myself and it could be two acronyms meanings for different things lol (just my luck ;) )
[HTC Wildfire S] heavy_metal_man:
Hey guys random thought. Does the enghboot have a kernal built into it? Or flashed with it? The phones have to have a way to write to that partition natively. Is there no way to find and utilize this?

sent from my android powered beast!
[HTC Wildfire S] theq86:
hboots do not have a kernel. the simple task it has to do does not require one.
[HTC Wildfire S] no.human.being:
Yeah, HBOOT runs "on the metal" (no operating system beneath). Now as far as I understand there are two possible scenarios and we don't know for sure which one is implemented.

1. HBOOT sends "unlock" commands directly to the memory controller before booting the kernel. If this was the case, we'd have to modify the kernel to send more "unlock" commands after it has been booted.

2. HBOOT tells the Radio what to unlock via RPC and only Radio can talk to the memory controller. If this was the case, we may not only need to find a way of RPCing the Radio from within Android, but also a way of making it believe that we are HBOOT.

Case 1 is the "good case" and it's the case for e. g. the HTC Vision, where the NAND lock has already been broken, so I hope it's the case for the WFS as well.

Case 2 is much much worse, since the Radio could actually make use of cryptography to ensure that the HBOOT is authentic before fulfilling its requests. I think we'd be pretty much doomed if that was the case and there probably wouldn't be a way of breaking security other than xtc-clip or faking the signature of a patched HBOOT (which is infeasible when implemented correctly and private keys not leaked) or directly programmiing the chip via JTAG. :(
[HTC Wildfire S] heavy_metal_man:
Bummer. Any luck with getting a kernals to go?

sent from my android powered beast!
[HTC Wildfire S] :
****. I don't like Case 2. How does XTC do it. Directly changing the byte or by patching HBOOT? Come on! If XTC can do it, so can we! Can someone please summarize what is happening at the moment.

I've lost track. And should the OP update the OP?
[HTC Wildfire S] theq86:
even case2 is not unbreakable. the keys needed must be stored somewhere.

to come back to the clip: it does no magic. it mimics a probably leaked htc service sim and flashs the diagnostics tool. that does s-off. once s-off you can write supercid.

the most important thing is the sim emulator.
[HTC Wildfire S] einstein.frat:
There is a possiblity that dopounutbear wire method works on ws, open the ws you will see contacts, let dopounutbear do its thing and its s off like the xtc clip style.
[HTC Wildfire S] Antagonist42:
Directly programming which chip? the MMU or mARM via Jtag?

Qualcomm make specific use of protecting access to areas mARM stores security so Jtag can only access 'indirectly' via authentic software or have the keys/signature (forcing use of Jtag blows remaining Q-Fuses making finding the original Q-Fuse sequences even harder), aARM you can use Jtag on but even then to get in that way to mARM you still need the keys/signature to get into mARM's protected areas (if I remember rightly more specifically a 64kB section in IMEM's 256kB area in mARM) which mARM sets up during PBL and then has no direct access to it.

This is where I think using Official updates that we could alter may at least offer the best way in without crippling or destroying security, which to a certain extent helps protect the whole phone from being exposed to being hacked from outside sources other than the user (if you made use of the NFC and you have a rogue app that copies data and transmits it, essentially we'd have exposed our bank details for them :confused:)
[HTC Wildfire S] heavy_metal_man:
Well again I have a xtc clip in Scotland if anyone is willing to provide a phone we can do the dumps and see :cool:

sent from my android powered beast!
[HTC Wildfire S] einstein.frat:
You need an ARM rompatcher, patch Hboot to S-off set to autorun on boot also custom keyboard so you could write to Data also System and other partitions except hboot where rompatcher running you can only use it when its booted to android.

Can write files to rom, with su, can flash roms, can flash kernels, cant and no flash splashscreen, and cant and no make custom partitions.

Download
[HTC Wildfire S] theq86:
JuopunutBear will probably not work. The so called wire-trick seems to work only on eMMC based devices which have a special qualcomm download mode. The WFS has no pins to connect to. it has several "holes" where a wire would fit in, but no contact pins. I don't think this will ever come to mtd devices.

We should come back to it later, when we succeeded writing to the radio area and our hboot exploit does not work out.

I don't think the rompatcher will help us flashing a hboot ;-)
[HTC Wildfire S] Antagonist42:
The problem we have is the section 'Block Lock Feature' (p42 of the NAND chip), essentially we can write to NAND with updates, the AMSS or Radio data is write protected on NAND (and I think n.h.b. may have read same things that say the S-OFF is in the Radio or mARM system data as I have) even at boot time whilst the APPS/kernel aARM is not write protected so we can freely install things to a certain degree, if we could find out what, where and how the NAND is 'inverting' the Block Lock we can write in whatever we wanted and possibly simply 'turn' S-ON to S-OFF.

Seeing as you have to register with HTC to get the hboot updated (which I stripped it out and is hboot_1.10.0000.img) so as you can install roms etc there must be a difference between that and original hboot's that maybe 'pull's down' the lock enabled NAND on boot to make it writable seeing as there isn't an update for the AMSS/Radio of the system...... going to find a few hboot's to compare them and see what's what >:)

This is what we may need to know how to get at the S-ON/OFF as to how to turn the NAND's Block Lock on and off.
[HTC Wildfire S] *se-nsei.:
226 pages of pondering. Whoever engineered this phone better have had a legitimate reason for this.
[HTC Wildfire S] bobdamnit:
Its obvious the reason for this is to prevent users just like us from hacking the crap out of HTC's phone lol.
[HTC Wildfire S] Antagonist42:
Document update

Recent Docs I grabbed and hopefully more to come ;)

--->> AMSS <<--- This is a MUST!!!

--->> Build your own CPU <<--- If you got the gear :D

--->> Qualcomm Auto Test <<--- Unknown source and no documentation Beware!
[HTC Wildfire S] alc027:
True? I'm fairly sure this has happened to me is the reason.

The device bootloops before before passing to the kernel UNLESS charging power is supplied to it, then it boots fine.

It understands that it is connected via USB by neither UMS nor ADB will work. Recovery cannot see the sdcard.

I'm fairly sure that it's a USB brick. Would it be possible to flash somebody else's misc.img if they gave me one?
[HTC Wildfire S] theq86:
Strong indication for misc brick

Right. Also indicator of misc usb brick

Yes. Depending on which device CID you have. I can only give you the misc.img of HTC_EU Devices.

However, if you are able got get a misc.img according to your country you can fix your misc brick. this is what I've done: http://xdaforums.com/showthread.php?p=23175308&highlight=enableqxdm#post23175308

So, basically all you need is a working misc.img for your phone. if you have it I can tell you how to exactly unbrick. because this is a bit tricky depending on several things
[HTC Wildfire S] alc027:
!!Yes please!!. I've been trying to get this thing working for 3 weeks. The only place it can do any good is in my car as a music player. I feel like an iPhone user stuck with tethered jailbreak.

If you gave me your misc.img would I be able to hex edit my CID (or super CID it) before flashing?

Thanks again

EDIT: I also did enableqxdm but not having a valid misc to flash I remained USB bricked
[HTC Wildfire S] :
Does this work on the A510e?
[HTC Wildfire S] seaskyways:
Hey , please , I tried whatever methods , because i have a mini-usb brick over here and once i got this mini-usb brick on my brother's wife phone so i knew it is in the misc , but i reflashed the bootloader and it was okay , whereas mine is wierdo , so if you may please make a Thread for it in the general or even in the Desire S :p just that we need it here ! because you may have done something tricky as you said ...

For the S-off i have been watching everything , and i am learning more from what i read :D thanks Theq (pressed) :)
[HTC Wildfire S] theq86:
I attached my misc.img.

What you have to do is: make sure your sdcard works (should do after enableqxdm), go into your rom (must be rooted), get the flash_image tool (it is inside one of the attached files in this thread) and then do: flash_image misc /mnt/sdcard/misc.img
[HTC Wildfire S] seaskyways:
i have sold my WFS :D thanks for any help guys , i will be going to desire Z :D:D or Incredible S !
[HTC Wildfire S] no.human.being:
Don't know about the "flash_image" tool, but the "nandwrite" tool from "mtdutils" is part of our exploit. I think "flash_image" is part of CWM recovery.

I probably wouldn't go for an HTC again. I'd go with a Samsung. Galaxy S2 or Galaxy Nexus. I'll probably get one of those after the successors are out and prices have dropped.

So you claim that there's STILL more memory than what we can see at this point? Remember that the NAND is specified to have a capacity of 512 MiB (plus a bit of out-of-band area for error correction) and that we can access addresses 0x00000000 to 0x1fffffff physical if we pass kernel parameters. Where will that "protected" area be and what do you expect it to store? We have already gained access to the "Radio partition" containing the code running on mARM (including Pistachio, Iguana, AMSS) some time ago. It starts at 0x00000000 physical (at least what aARM sees as "physical" .. if the read/write commands are intercepted by the Radio it might actually do another address translation) and is contiguous (or at least looks contiguous from the aARM's point of view). However, its size (and obviously content) varies among different builds of the Radio firmware.

You're obviously much more into this than I am. Thank you very much, this was extremely informative! I'm gonna click "thanks" as soon as I have more thanks available. :D

Well, as long as aARM has direct access (meaning it can directly put commands on the memory bus instead of having to ask the Radio to put a command on the memory bus), there won't be anything that could prevent us (with our kernel running on the aARM) from unlocking the entire NAND and then writing to the Radio area. If we can write to the Radio area we can patch the HBOOT and obtain S-OFF. This means that, as soon as we have a kernel which can issue "unlock" commands to the NAND, our exploit will just work.

However, if the Radio is acting as a "man in the middle" between NAND and aARM, meaning all memory requests muss pass through the Radio firmware, they could easily have integrated a filter that blocks requests that are affecting the protected memory areas, making our solution intractable. It basically makes our most fundamental assumption of our exploit, namely that our kernel has actual physical memory access, wrong and I'm not sure whether we will come up with a solution for this case as well, since there is basically now a higher-privileged instance below us that can control what we're doing.
[HTC Wildfire S] *se-nsei.:
Traitor.

Joking, bye bye, I'd also advise a Samsung.
[HTC Wildfire S] no.human.being:
Yeah, but even the Nexus phones have proprietary components in their firmware that are locked down, right?

Btw, is there any completely open firmware build for an Android device yet or will our attempt of porting UBOOT and building Pistachio/Iguana from source be the first?
[HTC Wildfire S] Antagonist42:
Darn dang and piffle... stuffed my PC again lol

Think my.next move is see if the 'CHECKHTC.exe' can be made executable without being run as part of an EUU/RUU and see if can gain access to NAND without anything else except adb and fastboot.

Woohoo 10 mins and still loading windows personal settings lmao I gotta get around to sorting myself out a Linux system:rolleyes:

ROOTED ACER E320/C6 ;-)
[HTC Wildfire S] no.human.being:
I think RUUs only transfer a "ROM.zip" to the phone and let HBOOT flash it.

Btw, I've just been skimming through the UBOOT sources. Man that bootloader is awesome! You can even boot and flash kernels over a network (WiFi?) connection! :D

It also has a "remote shell" with a full-featured command line interpreter behind that lets you change the processor configuration, dump and program volatile (RAM) and persistent (NAND) storage, lock and unlock pages (by default the pages holding UBOOT itself are flagged as "locked", but this is just to prevent "accidents" and can be disabled via the shell with a simple "protect off <range of sector numbers>" command) and much much more. It can do a lot more than HBOOT can, but it's gonna have its own utilities and will not support Android SDK utils like Fastboot.
[HTC Wildfire S] :
You have go to get that UBOOT on my phone right now! And add ADB and fastboot support, of course! It's a shame. You have a brilliant bootloader, but it doesn't support basic Android utils. Can't have the best of both worlds.

I've been wondering what would happen if all the devs suddenly ditched us. By the way, you remember the first exploit? The one where you have that zip you flash in HBOOT, that you leave on the root of the SD card? What did that actually do, other then brick the camera?
[HTC Wildfire S] alc027:
Is that DAS BOOT?

!!!!THANKS!!!!
[HTC Wildfire S] no.human.being:
It's "Das U-Boot". It's a play on words. U-Boot is short for "Universal Bootloader", but it is also German for "submarine" and "das" is the definite article, like "the" in English, so "Das U-Boot" means "the submarine". :D
[HTC Wildfire S] alc027:
Lol... I didn't know UBOOT was a real thing, just a misspelling of HBOOT, and made a joke about it. In particular it stands for unterseeboot which means literally Undersea Boat.
[HTC Wildfire S] no.human.being:
Lol! UBOOT is the bootloader for embedded Linux. It's GPLed software and boots practically all "non-smartphone/tablet/pda" embedded devices, like routers, satellite receivers (in fact it also boots the actual satellites themselves :D ), printers, etc. :D
[HTC Wildfire S] alc027:
All good mate, thanks heaps. No ADB or UMS made root challenging. I used Wifi Sync Manager and Terminal Emulator (it's painful as hell trying to find underscores and overloading operators on the stock HTC keyboard). All sorted now.

Thanks again!

EDIT: Any ideas how we went wrong in the first place? And how did you have the foresight to back up your misc partition?
[HTC Wildfire S] Antagonist42:
ALWAYS back it up before if you can as you're essentially entering deep water with flashing or you can leave your BRICK in the water lol

Unlike MY phone which I tried CWM Titanium and dd and a few dump apps but ended up with nothing but finally found Xakep on Club-Acer.ru who managed to work out a Rom Flash to get root on ACER C6 .... all I have to do now is work out how to regain my Radio version back up to 1.013.0000 from 1.008.0000 (although the actual Radio is still 1.013 I think) seeing as now neither Xakep update or ACER EUU will NOT complete now :D
[HTC Wildfire S] Antagonist42:
Here's a list of all the NAND chips I've come across mentioned within files for updates for HTC devices (including this bleeding ACER :p) and I think if I remember rightly the one that least shows up is probably your chip (as that's how I found out mine before actually confirming it was that one....kinda a hunch)...

MICRON	MT29F4G16ABC

MT29F2G08ABD

MT29F2G16AAD

SAMSUNG	KA100H002G

NUMONYX	NAND02GR4B2D

NAND04GR4B2D

SAMSUNG	K524G2GACB

HYNIX	H8BCS0UN0MCR

MICRON	MT29F1G08

MT29F1G16

KFW4G16Q2M-DEB8

KFN4G16Q2M-DEB6

KFM4G16Q2A

Let me know which you may have and I'll see what I can find on them, not sure how much space is on them but mine is the MT29F4G16ABC so whatever the 4G comes to in real Mb (4G is Giga bit NOT Bytes).....

.....:rolleyes: found it lol 512Mb (that's why 512Mb of Ram runs out so fast loading so much into it :rolleyes: that's why my old LG GT540 has about as many apps as this ACER before it's full :D) right where's my adb and hex edit? I'm having this!
[HTC Wildfire S] theq86:
I'm a professional application developer. I'd even make a backup of my girlfriend if it were possible. That's Rule1 before you touch anything. Backup, Backup, Backup!
[HTC Wildfire S] heavy_metal_man:
LMFAO legend!!:D:D:D:D:D
[HTC Wildfire S] no.human.being:
Right, that's one reason why I like Linux. Just backup all files under "~". The other files are system-specific and will be restored (or replaced) on a reinstall. Backups of "~" are performed on a daily basis and stored on an external drive.

When I don't have copies of my data on at least two completely independant media I'm gonna start panicking. :D
[HTC Wildfire S] theq86:
spaam ^^

ordered an htc one x today :-D
[HTC Wildfire S] no.human.being:
Are there already good Custom ROMs for that device? I mean it's shipped with ICS, but Sense sucks bad. :D
[HTC Wildfire S] theq86:
I belong to those people who like HTC Sense. There are some great custom roms. One X is already htcdev unlockable. But still no S-OFF. But comes time, comes S-OFF, you know? At least for eMMC devices :D

I also suppose that some day cm9 will be officially available for that beast :D

I just hope I get an unfaulty one. statistically 28% of all Endeavours (great codename btw) have screen flickering and overheating. But if that's the case I will give it back until I have a good one.
[HTC Wildfire S] no.human.being:
It's not specifically HTC Sense. I just dislike all modifications by handset manufacturers. I must say that Sense is probably one of the less invasive ones, but I still prefer to get it off. :D

Well for the others as well. It's just that the WFS seems unpopular. The Legend (also MSM7227 and NAND and HVGA screen, but bit older Firmware, shipped with Froyo) is already S-OFF.

Well sooner or later it will be available for almost anything. They said they will support "all devices with a newer chipset than Google Nexus One". That would even include the WFS. I think the Nexus One is still on a QSDxxxx chip. The MSM7227 of the WFS is a real powerhorse against what the Nexus One is using lol! :D

Well I'd go with a Samsung. I just love AMOLED. I'd even go and grab an AMOLED as computer monitor if 24" panels were available. True contrast ratio of 1 Mio. : 1 and reaction times of around 100 microseconds. Yeah, display 10.000 FPS! :D
[HTC Wildfire S] theq86:
I don't care about screen technology. I'm not the one who even recognizes a big difference between e.g retina (iphone) SAMOLED+ or SLCD2

But the real HD resolution of the one x is really heavy :D
[HTC Wildfire S] no.human.being:
Well it's not that you really NEED it, I mean you're not gonna watch movies on the phone but the contrast ratio is really stunning and AMOLED is almost completely agnostic to viewing angles, so it's quite easy to tell TFT and AMOLED apart if you can take a look at the screen when active. As long as a high-contrast image (e. g. white font on black screen) is displayed, you can usually tell them apart right away from the contrast ratio. And if not, you just tilt the display a bit and then you're gonna see contrast ratio dropping on the TFT while it will stay constant on AMOLED so it's quite easy to tell the two apart.

It's 720p. Like Galaxy Nexus (which I'd love to get if it dropped another say 50 €). Galaxy S3 will even be FullHD (lol, total overkill for a phone :D ). And that on AMOLED. OMFG! :D
[HTC Wildfire S] MrTaco505:
The One S has S-Off if I could remember
[HTC Wildfire S] sythe179:
Topic...strolling off?..
[HTC Wildfire S] no.human.being:
Well we can't do much productive work right now. We still need someone who knows how to build a kernel. Then we need to modify the mtd driver so that it can pass "unlock" commands to the NAND/Radio (actually we're no longer sure what we're effectively talking to .. it "behaves like a NAND chip", but it could actually be the Radio "emulating" one :D ) and see whether we can erase the protected area afterwards.

If we can, we are most likely directly talking to the NAND chip, since the Radio would probably intercept unlock requests. Our exploit will then either "just work" or we can achieve S-OFF by dumping the HBOOT image into a file, then run the exploit on the file instead of the mtd device, then use mtdutils to erase the NAND and write the modified image back. Either way should turn the phone S-OFF.

However, if we cannot erase even after our mtd driver passing the "unlock" command, we're probably talking to the Radio instead of the NAND itself. In this case we need to figure out how the HBOOT "authenticates" with the Radio to get permission to erase the protected area and then replicate HBOOT's behaviour in the mtd driver of our kernel to make the Radio "think" that we are HBOOT and give us write permission to the protected area.

In either case we will need assistance from an experienced kernel developer in order to accomplish these tasks. It's simply that currently no one seems to have the skills that we require for the next (and most likely last) step. Kernel devs are rare!
[HTC Wildfire S] *se-nsei.:
We are so close, yet so far away. :)
[HTC Wildfire S] no.human.being:
Yes. The modification of the mtd driver will probably be the last thing we'll have to do, but it's so damn hard to find devs that are able to do it. We could really use Alquez' help here. It would probably be an easy task for him, wouldn't it?
[HTC Wildfire S] seaskyways:
yes it would , but i guess alquez comes to xda once a year :p as if he is a Co-Bill Gates :p come on guys , keep it up , best wishes !
[HTC Wildfire S] kalaker:
What if we try to get on the portal? Surely a Kernel Dev would see...