yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] BeciMester:
The misc exploit (the one iuss was talking about with the buffer overflow) would still work on 0.90 but is definitely fixed in 1.08 and newer. I haven't had a look at 1.03 but it's likely fixed too.

I'm one of those people. :D I never update anything before knowing for sure that I won't lose advantages (my HOX is still on the first hboot/firmware too). I haven't reported back about testing your chainload method because I'd need 1.08 or newer to use it, but I didn't want to lose 0.90 and the possibility of the buffer overflow attack. And now this. Why have I not heard about this RUU thing? I must look it up, like, right now. :laugh: Oh, and could we all use this method to downgrade to 0.90?

I'm hard at work finding the exit point of hboot where it hands over control to the kernel. (Is it the kernel, by the way?) I think it'd be helpful to know what changes are made at that point. I'm also looking out for clues regarding how hboot checks for keypresses, where and how does it check for the sdcard being present, and why it locks up if there's no sdcard in the phone. On stock hboot if there's no card there's no check for PGxxx.IMG. Somewhere around that point we'll find why the chainloaded hboot locks up.

BTW I'm still not convinced that there is a specific "check myself and if I don't check out I'll replace myself" thing in hboot. If there's such a thing it's likely done by a "higher power", or does it have something to do with re-mapping the memory maybe? Haha we know so little about it...

We still wouldn't have write access to the radio partition...? If I understand it right, MMU is just for virtual memory management in RAM, not NAND.
[HTC Wildfire S] BeciMester:
HAHAHA it worked! :laugh: :highfive:

FWIW what I did was, I had the two rom.zip files extracted for a long time, even attempted a comparison of the two radio images at one stage. Now I removed SIM and sdcard, booted into fastboot, and did

fastboot oem rebootRUU
fastboot flash zip rom_01.zip

Didn't even have to rename it. When it finished I did a battery pull, booted into hboot and bam! S-OFF.

This will make my job sooo much easier! :D

If I flash a newer hboot unmodified, will it revert to s-on?
[HTC Wildfire S] no.human.being:
YES definitely! Don't do that! The S-OFF does not come from the Radio, it's just that Radio and HBOOT don't "fit together" now, since Radio has been updated ("rom_01.zip" installed) but HBOOT has not ("rom_02.zip" not installed). Remember that HBOOT queries the Radio for the status of the secu_flag and it seems that the function has moved to a different address and "old" HBOOT is now querying another function (as it's designed for "old" Radio so it calls function at address where "old" Radio "check secu_flag" routine was) and this is one that does probably something entirely different, but returns 0 so HBOOT thinks "ok secu_flag is zero". Basically the APIs of your bootloader and Radio are now "incompatible" and HBOOT thus thinks that the Radio is S-OFF, while it actually is not.

If you update to a newer HBOOT, it will be designed to work with the "new" Radio and will thus call the "actual check secu_flag" function again, reverting to S-ON with no possibility for going back (unless you find a way to downgrade HBOOT).

Remember that this will only work on VERY old devices that still shipped with an HBOOT-0.90.0000 bootloader and pre-7.54 Radio and have NEVER installed an OTA update (as this will update HBOOT and Radio).

And WTF?! HBOOT-0.90.0000 has Fastboot support? o.O
[HTC Wildfire S] rezo:
What about running DIAG and cleaning S58 data now? Shouldn't BeciMester get superCID then?
[HTC Wildfire S] mstfkaratas:
Yes, but it doesn't have full 'fastboot flash' commands like flashing boot, recovery, system, data images, and doesn't boot from external kernel like htcdev hboots as far as i know

Wildfire S A510e cihazımdan Tapatalk 2 ile gönderildi
[HTC Wildfire S] schlund:
if you are s-off now you can set flag in htc partition for "real" s-off, that should make it possible to upgrade to whatever hboot you want to with still having s-off!
[HTC Wildfire S] munjeni:
Guys, this story is going in circles again and again, you must to know s-off mean nothing without hacked hboot (if hboot is not patched - mean signature check bypassed...etc you are unable to install an radio or hboot...etc, allso diag is unusable too!) if you remembered I had true s-off and I tested these things without any any any posibility to install custom radio or custom hboot...all fail on signature checking! You wasting your time because s-off + stock hboot mean nothing!!! Patched hboot is only thing that you need if you want to have posibility for installing custom radios, customhboots!

N.H.B I have an idea! I know why hboot fail to boot! ;) I got jtag connected when my phone was "on" and have dumped ram (offset 0 to 0x200000) using jtag and found something very interested about hboot! In these ram dump:

hboot size is 0x80000

but hboot have extra data after these offset :cyclops: and now if you disasemble hboot you will see some functions "looking" for offset that is bigger than 0x80000!!!!! For example see this (etra data dumped from ram):

ROM:9D082DF0 DCB 0
ROM:9D082DF1 DCB 0
ROM:9D082DF2 DCW 0
ROM:9D082DF4 DCD 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
ROM:9D082DF4 DCD 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
ROM:9D082DF4 DCD 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
ROM:9D082DF4 DCD 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
ROM:9D082DF4 DCD 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
ROM:9D082DF4 DCD 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
ROM:9D082DF4 DCD 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
ROM:9D082DF4 DCD 0, 0, 0, 0, 0
ROM:9D082FE4 dword_9D082FE4 DCD 0 ; DATA XREF: sub_9D0240B8+ACo
ROM:9D082FE4 ; sub_9D0240B8+B0w ...
ROM:9D082FE8 dword_9D082FE8 DCD 0 ; DATA XREF: sub_9D023FD8+ACo
ROM:9D082FE8 ; sub_9D023FD8+B0w ...
ROM:9D082FEC dword_9D082FEC DCD 0 ; DATA XREF: sub_9D0240B8+B8o
ROM:9D082FEC ; sub_9D0240B8+BCw ...
ROM:9D082FF0 dword_9D082FF0 DCD 0, 0, 0, 0, 0, 0, 0 ; DATA XREF: sub_9D023F64+14o
ROM:9D082FF0 ; ROM:off_9D023F94o ...
ROM:9D08300C dword_9D08300C DCD 0x1000B8FA, 0xBCD08E, 0xB8B0, 0xC08ED88E, 0x7C00BEFB
ROM:9D08300C ; DATA XREF: sub_9D029898+8o
ROM:9D08300C ; sub_9D029898+34o ...
ROM:9D08300C DCD 0xB90600BF, 0xA4F30200, 0x621EA, 0x7BEBE00, 0xB750438
ROM:9D08300C DCD 0x8110C683, 0x7507FEFE, 0xB416EBF3, 0xBB01B002, 0x80B27C00
ROM:9D08300C DCD 0x8B01748A, 0x13CD024C, 0x7C00EA, 0xFEEB00, 0, 0, 0
ROM:9D08300C DCD 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
ROM:9D08308C unk_9D08308C DCB 0 ; DATA XREF: ROM:9D029978o
ROM:9D08308C ; ROM:off_9D0299ACo ...

so "an XFER just for example - there is many other!" example offset 0x82DF4 maybe not exist in ram (empty?) because your hboot loaded to ram have only size 0x80000 and I think thats reason why hboot freze (needed data after 0x80000 is emty)! So maybe you need to create new exploit with order:

exploit + hboot + extradata to get hboot working by exploit... what you think?
[HTC Wildfire S] no.human.being:
Great finding! Does that "extra data" come from consecutive pages in NAND? (So right after the HBOOT image in the Radio partition?) Does it even come from NAND or is it "generated" by another firmware component before HBOOT is loaded? (By SPL?) How much data is it? Yet another 512 KiB?
[HTC Wildfire S] munjeni:
I don't know, I not dumped whole ram just only an part! Its physical ram dump (not nand dump) by jtag...yes its after hboot, hboot is on phys ram offset 0x0 to 0x80000 as we expect and than extra data after him! I am sure extra data is part of hboot because links from disasembled hboot+extra data is linked to hboot hboot functions! I dont know if it is generated by hboot or not!
[HTC Wildfire S] no.human.being:
As far as I know the xtc-clip does not patch anything inside the HBOOT. It emulates an "engineering SIM" and then runs the DIAG file, which is LEAKED ORIGINAL HTC SERVICE SOFTWARE. Think about that. Why should HTC create a tool that "patches" (hacks?) HBOOT? Don't you think there would be a "more elegant" way to "officially" disable security for servicing devices?

You may not write a "patched" HBOOT to NAND as long as the Radio is still S-ON. Someone found that modifying A SINGLE BIT in HBOOT will completely brick some devices (completely refuses to turn on when you press the power button) and if you use JTAG to restore "stock" HBOOT it will boot again.

Remember that HBOOT is completely contained within the "Radio area" in NAND. There's Radio code BEFORE and AFTER the HBOOT image, so from the Radio's point of view, HBOOT is not treated as "code" but as "data". The Radio probably somehow moves it over from mARM to aARM memory and then aARM is released from halt and begins executing HBOOT. The Radio will probably check the HBOOT against some kind of "whitelist" of known hashes or whatever and not move it over to aARM and execute it when the hash doesn't match and instead power the processor down again so basically all you should see when you modify HBOOT in NAND is a device that will appear as if it would no longer power up. So the only possibility is either patch the Radio to "true" S-OFF or only run the "patched" HBOOT from RAM until the Radio is also patched.

Running a "patched" HBOOT in conjunction with a "stock" Radio has resulted in bricks on some devices due to the Radio verifying HBOOT signature in NAND before loading it. I'm not sure if the WFS Radio will do this, since all the reports are about newer devices and the WFS Radio might not yet have this security measure in place but this is the reason why I'm VERY careful about doing anything to HBOOT in NAND. (Messing with the HBOOT in RAM should be perfectly ok. At least if anything goes wrong you can pull the battery and you're back on stock so the chance of bricking something is low unless you "abuse" your S-OFF power to flash an unsigned HBOOT BEFORE you have successfully turned the Radio S-OFF.)

You could verify the "modified HBOOT won't boot" thing on your Aria if you like (unless you've already tested it). Just modify something "unimportant", say a string that HBOOT displays - e. g. make "SHOP" out of "SHIP" or somthing like that) and then report back whether it still boots.

Could you take a look whether this "extra data" is also directly after HBOOT in NAND? (Or even "anywhere in NAND" - could you run a binary comparison over a full NAND dump obtained via JTAG?) If not, it's obviously "generated" by some component (either by HBOOT itself or by the Radio and then "moved over" to aARM).
[HTC Wildfire S] munjeni:
Heyyy, see this:

C:\Documents and Settings\Desktop\adb>fastboot oem listpartition
INFO[hboot]:(RAW, 0) block start=288, size=6 [COLOR="Red"](768 KB)[/COLOR]

768kb is hboot partition!!! That mean hboot+extra_data mean/must be 768 kb ? So maybe uncoplete partition is only problem!?
[HTC Wildfire S] no.human.being:
I'll make a dump of the WFS Radio area and take a thorough look at the pages beginning from where HBOOT starts again. Let's see what comes beyond those 512 KiB and if it looks somehow familiar!
[HTC Wildfire S] munjeni:
6 * 131072 = (dec)786432 == (hex)0xc0000 == hboot partition == hboot is not only 0x80000 len == hboot is hboot+extradata?

---------- Post added at 09:25 PM ---------- Previous post was at 09:23 PM ----------

Dude, you forgot that we have only offset for radio flag and not for hboot flag?
[HTC Wildfire S] no.human.being:
I don't understand why should they use two different flags. It doesn't make sense.
[HTC Wildfire S] munjeni:
I am not sure if wfs have these check but I am sure aria have no these checks because my device have stock radio + custom hboot! Allso on emmc device (my new phone - desire c) I found these hboot checks is inside hboot (hboot byself have these checks + hboot lies signed in emmc memory and fail byself signature match if is edited, so its reason why device have brick when 1 bute is edited!)! I am not sure if radio have these checks!

I allso not understand why but from my tests hboot is all times locked but radio was true s-off...

---------- Post added at 09:47 PM ---------- Previous post was at 09:28 PM ----------

No but some part match! See diference:

- ram (phys offset 0x821c0):

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000821C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000821D0 02 00 00 00 2B 00 00 00 02 00 01 00 37 36 58 58 ....+.......76XX
000821E0 54 2D 34 37 33 35 2D 54 53 4E 43 4A 4F 4C 59 4D T-4735-TSNCJOLYM
000821F0 00 00 00 00 00 00 00 00 00 00 00 00 C0 03 00 00 ............Ŕ...
00082200 02 00 00 00 00 00 00 00 01 00 EE CC 00 00 00 00 ..........îĚ....
00082210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00082220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00082230 00 00 00 00 00 F8 24 01 00 00 00 00 00 00 00 00 .....ř$.........

- nand (nand phys offset 0x21fc30) ... its like part of what? Hboot is on 0x2400000! ...:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0021FC30 E3 EB 15 2D 54 F6 D4 29 79 26 A9 C5 CE 3B 68 C1 ăë.-TöÔ)y&©ĹÎ;hÁ
0021FC40 17 1D 2B CC A0 00 EA C8 A5 50 AD D6 12 4D 6C D2 ..+Ě*.ęČĄP*Ö.MlŇ
0021FC50 CB 6B 2F DF 7C 76 EE DB C1 CB A1 E3 76 D6 60 E7 Ëk/ß|vîŰÁËˇăvÖ`ç
0021FC60 AF F0 23 EA 18 ED E2 EE 1D BD A5 F0 AA A0 64 F4 Żđ#ę.íâî.˝ĄđŞ*dô
0021FC70 73 86 27 F9 C4 9B E6 FD 09 FD B8 89 BE E0 79 8D s†'ůÄ›ćý.ý¸‰ľŕyŤ
0021FC80 67 C6 3A 80 D0 DB FB 84 D5 8B BC 9A 62 96 7D 9E gĆ:€ĐŰű„Ő‹Ľšb–}ž
0021FC90 BB B0 3E 93 0C AD FF 97 B1 10 B0 AF 06 0D 71 AB »°>“.*˙—±.°Ż..q«
0021FCA0 DF 2B 32 A6 68 36 F3 A2 6D 66 B4 BC DA 7B 75 B8 ß+2¦h6ó˘mf´ĽÚ{u¸
0021FCB0 03 5D 36 B5 B4 40 F7 B1 37 36 58 58 54 2D 34 37 .]6µ´@÷±76XXT-47
0021FCC0 33 35 2D 54 53 4E 43 4A 4F 4C 59 4D 00 00 00 00 35-TSNCJOLYM....
0021FCD0 EC 02 00 00 08 00 00 00 47 33 2A 00 60 33 2A 00 ě.......G3*.`3*.
0021FCE0 00 00 00 00 00 00 00 00 00 00 08 00 00 03 03 03 ................

For sure I will try exploit with hboot+extra data in next few days
[HTC Wildfire S] rezo:
Maybe that would be helpful. It's a fullflash from Wildfire S 4K pagesize. http://www.mediafire.com/?tmmr2ib0tl0jeri
[HTC Wildfire S] no.human.being:
I've just had some "fun" poking around in the "Radio area" of my phone as well as in an RUU.

HBOOT starts at 0x02b00000 physical at my phone. Starting at 0x02b738a4 physical everything's erased. At 0x02c40000 physical Radio appears to continue. So "extra data" (IF it's present on the WFS) does not stem from consecutive NAND pages.

Just for completeness, starting at 0x02c80000 everything's erased again. At 0x02d40000 physical Radio appears to continue. At 0x02da0000 everything's erased again. At 0x02e80000 Radio continues. Starting at 0x02ebeeb2 erased again until 0x02fbffff (end of Radio area). At 0x02fc0000 boot partition starts.

Also in the Radio you'll find the strings "LEGEND", "ESPRESSO", "TERA", "PHOTON", "MARVEL", "CHACHA", "ICONG", "ERROR" close to each other, respectively. Most of these are code names for phones. All of these presumably use identical firmware, what do you think?

What's also very interesting is that when you compare the "radio.img" from the RUU with what is actually written to NAND, they don't match. The first word of the "radio.img" does not appear at offset zero in NAND. The Radio is not written as a "consecutive image". There's a 0x20 byte "prefix" in the "radio.img" that's nowhere in NAND and the first 4 bytes also don't match. This is the beginning of both images, compare.

RUU:

07 4e 91 8a 4b 36 55 ec
a2 08 84 4f f1 03 00 00
00 00 74 01 c0 0b 00 00
00 00 71 22 00 01 4a 3a
d1 dc 4b 84 [COLOR="Red"]34 10 d7 73
5a 43 0b 7d ff ff ff ff[/COLOR]

NAND:

ff ab ff ff [COLOR="Red"]34 10 d7 73
5a 43 0b 7d ff ff ff ff[/COLOR]

Where are the first 4 bytes in NAND from? They don't appear in front of the red "matching" byte sequence in the RUU image. Where did the first 36 bytes from the RUU go to? Not to NAND page zero.

The further you get into the Radio image the more divergent they become. For example this is at 0x00041020 inside the RUU image while it's at 0x00082000 in NAND.

RUU:

9c [COLOR="Red"]12 0f fa c9 b6 8f 5a
01 00 00 00 30 3a 4f 45
4d 53 42 4c 31 00 00 00[/COLOR]

NAND:

3b [COLOR="Red"]12 0f fa c9 b6 8f 5a
01 00 00 00 30 3a 4f 45
4d 53 42 4c 31 00 00 00[/COLOR]

Why is the first byte different?

Likewise what starts at 0x42020 in the RUU ends up at 0x84000 in NAND, what starts at 0x00044820 ends up at 0x00089000. (So "<phys_offs> = 2 * (<ruu_offs> - 0x20)" for the beginning of each "section"? What determines how large a "section" is?) And then there are always bits and pieces (bits and pieces is good, a bit of statistical "grab some random byte string out of the RUU image and seek it in NAND" revealed that it's actually A LOT of stuff) that are either in the RUU but nowhere in NAND or the other way round while others are principally there but have small differences between RUU and NAND and of course everything is "relocated" and "shuffled around". Whatever HBOOT does with the images that are inside an RUU (or therefore a PG76IMG.zip), it does NOT write them to NAND unmodified.
[HTC Wildfire S] BeciMester:
This "extra data after hboot" thing is wrecking my head since January. :confused: There were a few posts about it then but it was mostly disregarded. One of these:

There are a lot of addresses read from that area, a prime example is the secu_flag query function. I can't figure out where the data comes from yet, but now I suspect it might have something to do with the MMU so I'll look into that a bit further.

Also I'm learning how to patch the extended fastboot commands back into hboot, but reading n.h.b's concerns makes me a bit wary of flashing it.
[HTC Wildfire S] no.human.being:
Can you find out which physical page corresponds to it?

Remember that the ARM is a 32-bit processor so it has an address space of 4 GB, but it only has 512 MiB of RAM. That doesn't mean that the rest is "unused" though. In fact, almost the entire address space is used, for example for NAND access, inter-processor communication (shared memory for communication between mARM and aARM or for communication with coprocessors and DSPs), GPIO, busses, communication with the processor's "micro program", access to boot ROM and other stuff.

If the physical address it accesses is above 0x1fffffff it WILL be accessing some sort of "special function", since the "actual RAM" begins at zero physical and has consecutive addresses so all that's above that threshold is NOT RAM. If we know the physical address, I'm gonna look up for which purpose it is used.

In my opinion still more interesting is that HBOOT also seems to access addresses OUTSIDE the 0x9d00000 to 0x9d08000 range. These DEFINITELY do not belong to HBOOT anymore, since HBOOT is only 0x8000 in size.
[HTC Wildfire S] rezo:
From WildFireS_Full_alive.bin:

D1 DC 4B 84 34 10 D7 73
5A 43 0B 7D FF FF FF FF

It's the same as in RUU. How do you dump your NAND? Look at http://www.mediafire.com/?tmmr2ib0tl0jeri
[HTC Wildfire S] BeciMester:
I'll try my best.

In the page tables there is an entry for 0x9d000000 that's 0x100000 long, so from 0x9d000000 to 0x9d100000 that's one page. Dunno if it's relevant.

How was that file dumped? :confused:
[HTC Wildfire S] no.human.being:
JTAG (I hope)?

Software (as I'm not having JTAG access to the processor). WHY does the NAND content that the operating system sees ("my" dump) seem so different from what's actually in NAND (JTAG dump)?

I mean I'd be ok if there's "information missing from the OS that's present in the JTAG dump at regular intervals" (operating system hides "out of band" area). I'd also be ok if there's "whole page A from JTAG appearing under different address when read from OS" (there's an MMU between the OS and the NAND, who knows what it's configured to do?) but "being offset by 0x20 bytes" (0x20 bytes is "nothing" and an MMU can only think in terms of "pages", it's not designed to do such small offsets) or "some bytes being different" (and like I said there are MANY different) I just can't explain. There's just so much that doesn't maky ANY sense.

If what JTAG sees is "physical NAND" (and that's what I'd expect), then where does all that data come from that the operating system "reads" from NAND but that just doesn't appear ANYWHERE? Radio image is 25 MiB, Radio partition (for the OS) is 50 MiB, DOUBLE THAT SIZE so there's another 25 MiB !!! of data that's "read from NAND" by the OS but not "physically stored in NAND"? WHERE the hell is that data stored? I mean the Qualcomm people can't just make their MMU "retrieve data from nothing" or from "an area that's not backed by physical storage" it doesn't make sense. :D
[HTC Wildfire S] munjeni:
Dump by jtag and dump by software have big diference... I allready compared and this question is ansfered many times. I dumped some offsets after 0x20000000 and there is allso something but I not analysed that but for sure there must be something because nand size is 4gb...

About extra data after hboot... maybe its part of shared ram between hboot and radio?
[HTC Wildfire S] no.human.being:
But software reads "more" than is available. How can they put a 50 MiB Radio (software sees 50 MiB of Radio in NAND) into an image that's 25 MiB physical in NAND? I mean they could use compression, but it doesn't look compressed. For example you can read clear text in both images and you will find correlations between the two but some bits and pieces are different and what's similar all appears in other locations. How does that work? Where is that information stored that software sees as "stored in NAND" when it's not actually stored in NAND? I mean this 50 MiB Radio that software sees must be somewhere, right?

No, NAND cannot be that large on this architecture, no way! The entire address space of the processor is 4 GiB! RAM is 512 MiB (but actually there's 1 GiB reserved for RAM since the ARM11 core supports that much, it's just that the MSM7227 doesn't have it), NAND is 512 MiB. The remaining 2.5 GiB of address space (4 GiB - 1 GiB RAM - 0.5 GiB NAND) are used for inter-processor communication, I/O, boot ROM, etc. It's all used "somehow" but it doesn't mean that it's actually memory. For example to query the status of a GPIO pin, you must perform a "memory fetch" operation at some special address. That doesn't mean that there's "actual memory" behind that though. The processor "traps" the instruction and performs I/O operation instead. But the addresses that are used for this purpose are then "gone" and cannot be used for RAM or NAND. So RAM + NAND + I/O + Boot ROM + "everything" is 4 GiB. That means that any of these alone (e. g. NAND alone) can never be 4 GiB as then there would not be enough addresses left for the others (e. g. if NAND were 4 GiB, then the processor could not have ANY RAM and not have ANY I/O which obviously doesn't make sense).

Memory page that HBOOT resides in (0x9d000000 - 0x9d0fffff virtual) is mapped via MMU to 0x00000000 to 0x000fffff physical. Shared RAM (IMEM) is at 0x80000000 to 0x8003ffff physical (256 KiB). No, "extra data area" is not shared RAM.
[HTC Wildfire S] davidang:
any1 interested

link:http://xdaforums.com/showthread.php?t=1457992