yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
I'm really convinced that Revolutionary's answer was a straw man. They looked into this for at most 3 (!!) days. They got access to the first WFS phone on the 30th of June and claimed on the 2nd of July that it "does not work" due to "problems with the chipset".

Well, given they tried an exploit that was designed for the MSM8255 (probably something based on GFree?), then of course it won't work on the MSM7227 due to the different memory controllers. Just look at how long we're fiddling around here and we've no idea how close we actually are to the solution (well, actually we are now, since we know what's still missing, but we don't know how long it will actually take to perform these last steps).

They could never seriously have tried to design an exploit for the MSM7227 within 3 days of remote (!!) access to a WFS. Impossible! They just took an existing one, saw "oh, it doesn't work" (well, quite obvious, huh?) or maybe "uh the memory is unmapped on the WFS, while it is not on the phones we've hacked so far" (the second implication is just guessing) and then "gave up". I used to have quite some respect for these developers, but the further I dig into this S-OFF stuff, the less impressed I've become. Sure you have to be a skilled developer, sure it's laborious, but it's not "magic".

The biggest problem we've ran into is getting a custom OS booted on the device and that's simply because we have no idea how a configuration looks like that can be run on the device, so we're basically on a "trial and error"-route now. Well, obviously this takes time. Once we have an OS booted, we'll have unlimited read/write access to the device NAND (including "unmapped memory") and then we'll have to find the secu_flag in it (either by reverse engineering or by dumping the memory, including "unmapped" regions, before and after an S-OFF via xtc-clip, then comparing these dumps), finally write a program that patches the relevant pieces in memory and integrate it into an initrd and publish this OS image.

S-OFF then works by grabbing the OS image, booting the phone into Fastboot mode, connecting it to the PC, then doing "fastboot boot exploit.img" and be done... hopefully. :D

EDIT: Ok, back to our testing now.

- Booting the CM7.2 boot image via fastboot works! So the problem seems not to be with the fastboot method and also not with the kernel supplied with CM7.2 (well, obviously the kernel's alright, CM7.2 really works like a charm, thanks Alquez :D ).

- Splitting the boot image into kernel + initrd, then reintegrating them again and trying to boot them via fastboot doesn't work (device locks up with white screen)! So we're doing something wrong while creating the boot image. I'll try googling a bit about creating boot images.
[HTC Wildfire S] theq86:
I will try to separate/integrate a boot image with help of a kitchen. if it works I will give you the steps needed.

:( For some reason the reintegrated boot.img does not boot. something's missing ...
[HTC Wildfire S] no.human.being:
The differences between the "original" and the "reintegrated" boot image are:

Difference 1:

0x00000000 41 4e 44 52 4f 49 44 21 18 b5 28 00 00 80 c0 12
0x00000010 20 48 02 00 00 00 c0 13 00 00 00 00 00 00 b0 13
0x00000020 00 01 c0 12 00 08 00 00 00 00 00 00 00 00 00 00

0x00000000 41 4e 44 52 4f 49 44 21 00 b8 28 00 00 80 00 10
0x00000010 00 50 02 00 00 00 00 11 00 00 00 00 00 00 f0 10
0x00000020 00 01 00 10 00 08 00 00 00 00 00 00 00 00 00 00

Difference 2:

0x00000240 d6 8a b5 a9 76 c4 d3 f3 31 af 5a d6 4f 8c 45 03
0x00000250 8b 9b 78 37 00 00 00 00 00 00 00 00 00 00 00 00

0x00000240 3a 26 00 aa dd 6c 59 61 3e aa a3 e9 39 0c 33 35
0x00000250 38 dd 69 cc 00 00 00 00 00 00 00 00 00 00 00 00

Top is original and boots, bottom is split and reintegrated and locks the device up. All the rest is identical. It's probably some "meta information" that's stored in the image. Now it would be useful to know the internal format of an Android kernel image.

Btw, I didn't use the kitchen, I split it with the help of ghex and dd and reintegrated them again using standard mkbootimg from the Android SDK.
[HTC Wildfire S] mstfkaratas:
Hi no.human.being do you think your future solution can revert xtc s-offed devices back to s-on state for warranty issues, because as far as i know xtc clip isn't able to S-ON it back.
[HTC Wildfire S] no.human.being:
It depends on what xtc-clip does behind the scenes. If it only flicks the secu_flag, we should be able to flick it back. If it patches CID, we won't be able to restore it as we don't know the original CID value. If it patches SIM-lock, we won't be able to restore it as we don't have the original SIM lock code. If it patches around in some other places in the Radio firmware, well, what should we do?

For "our" S-OFF solution we could create a backup copy of the memory pages we modify in the Radio firmware on the SD card and restore from there at a later point in time.

For Revolutionary I think you can get S-ON again by flashing an original HBOOT.
[HTC Wildfire S] *se-nsei.:
With XTC-clip S-OFF you theoretically still have your warranty. They can never know if it shipped S-ON or S-OFF. No point in making it S-ON again.

If you unlock it via HTCdev they will know because you download a token by agreeing to their terms.
[HTC Wildfire S] no.human.being:
You're right! You can just claim that the device was shipped S-OFF. Forgot that there's such a thing. :D
[HTC Wildfire S] :
This just got me thinking. Probably a stupid idea though. BUT!

If someone can get their hands on a shipped S-OFF device, we can compare it to a stock S-ON and see what's different.
[HTC Wildfire S] intel007:
I actually called HTC UK support a few days ago not for my wildfire s but my sons, it has a dodgy power button really hard to press and sometimes no response, hitting the side of the phone helps lol

Anyway they asked if it was rooted or had been s-off as if it was they would not do the repair without a charge of £50-£60 and stated the engineers will check for this before any work is carried out.

I also argued that the problem was hardware related and not software/firmware and it should be covered but they dissagreed.
[HTC Wildfire S] no.human.being:
We already know that the difference lies in the Radio firmware. However, we cannot access the memory where the Radio firmware resides (we have absolutely no access, not even read access), because it is "unmapped memory" (this means the pages where it resides aren't having a virtual address assigned). We have to set up different page tables for accessing it.

Page tables can only be accessed from code running in "supervisor mode" (kernel code). That's why we're currently trying to get a custom kernel booted on the device. However, there seems to be a problem with the final "composition" step so all the kernels we compose lock up the device.

---------- Post added at 10:29 PM ---------- Previous post was at 10:19 PM ----------

Well, this is really bad treatment of customers imho. Just don't buy HTC devices anymore. I'll also refrain from their devices, since I don't want to support a company that locks their firmware.

Next device is definitely going to be a Samsung one. Their "Exynos" processors are much better than the Qualcomm Snapdragons anyways. Also Samsung is the only manufacturer that's already using AMOLED panels afaik, the rest is still with "plain old" TFT technology. So Samsung is currently miles ahead in technology, especially regarding the display. And when the Galaxy S3 comes out, prices for the predecessor device Galaxy S2 are expected to drop like crazy. I'll probably grab an S2 then, just because of the AMOLED panel. It's just so much better. Not that you really require it for a smartphone, I mean it's not like you're going to watch movies on the device (at least I don't :D ), but if you've ever seen it, it's just absolutely stunning.

Hope the technology scales well to the "large diagonal" monitors too, so that we may see computer monitors with AMOLED panels to hit the market within the next say two years or so. It's just so much superior. TFT --> AMOLED is almost like CRT --> TFT was.
[HTC Wildfire S] :
So basically, the radio is hiding, as if in a secret room in a house, but we know where it's hiding. But to get into that room, we must make a set of keys (addresses/page tables). Then we call in The Doctor. Then using his TARDIS (which is actually the main application) he gets into the secret room, because he inserted the keys in his TARDIS, which transfers the identifier codes (addresses) to the TARDIS. Then, The Doctor steps out of the TARDIS. The Doctor is actually part of the main application. He then uses his Sonic Screwdriver, which is actually the main method, on Mr.Radio (actually working for Area 51), therefore brainwashing him and making him a renegade Area 51 officer. Therefore, achieving S-OFF. Did I mention this "universe" is coded in C, by another very clever Time Lord, who goes by the name of......... NHB. NHB is also being assisted by other Time Lords......... Se-nsei, and Bad Wolf.

Thank you for taking your time to read my story.

I'm a Doctor Who addict, I really can't help it.

Sent from a Time Lord, via his TARDIS.
[HTC Wildfire S] benjamingwynn:
Dw is filmed near where I live. :)

Off topic much? :D

Sent from my Wildfire S powered by .sense using my fingers.
[HTC Wildfire S] no.human.being:
Could we please get back to the time where one only posted to this thread for contributing to the development efforts? The last post that brought new insights is already 10 (!!) posts back.

Sorry, but you're really killing a lot of our effort by posting so much off-topic stuff. All the "development-related" posts just get drowned in "noise". Just think about someone coming to this thread, knowing about the internals of an Android kernel image. Do you think he goes some pages back? He probably reads the most recent posts, then says "oh well they're not taking it seriously" and moves on.

I really don't want to be a poor sport, but I'd really ask you to consider posting the off-topic elsewhere, leaving this thread for stuff that's related to (kernel) development. This is also not the support thread for Revolutionary/xtc-clip/etc.

Thank you very much for your appreciation.
[HTC Wildfire S] theq86:
feel free to remove, was just off-topic ;)
[HTC Wildfire S] benjamingwynn:
Sorry, I just thought the guy would want to know, xda is after all a social network and not JUST for devs.

I'm not saying you moan but I make .sense but I don't moan if somebody has a little talk. I just say "have you read this above guys (link here)?"

If a kernel dev came here then he or she would be smart enough to look at through for what he (or she) had to do and to talk to the right person.

No kernel dev in their right mind would look and leave because of 1 off topic post.

- Benjamin

Sent from my Wildfire S powered by .sense using my fingers.
[HTC Wildfire S] no.human.being:
I'm also not moaning, usually. However, in the last days it's been a bit too much OT for my taste. There's a reason why the software this community is running on groups stuff into different threads and not just displays all posts on a contiguous timeline. ;)
[HTC Wildfire S] benjamingwynn:
I haven't been active on this thread for a while so sorry if I added to the clutter (was there lots?)

Oh and good work so far btw.

Sent from my Wildfire S powered by .sense using my fingers.
[HTC Wildfire S] no.human.being:
I can convince you, my comment wasn't supposed to be directed against you. :D

Thanks. :D
[HTC Wildfire S] *se-nsei.:
Alright already, enough with this gooey ****. Lets develop people. :D
[HTC Wildfire S] MrTaco505:
LOL.....so what's the plan again because I got lost after the off topic stuff :D
[HTC Wildfire S] theq86:
[STEP 1]

The plan is to get a plain linux kernel to work on the device.

the plain kernel will not unmap any memory area on the nand and give us full control over all the data.

[STEP 2]

if the kernel and ramdisk boots our next step is to locate the secu_flag on the device's nand.

[STEP 3]

if we found the secu_flag, we need to modify the minimal os image to

a) save a backup copy of the current page(s)

b) delete the area

c) rewrite the page with an unset secu_flag.

then we will have S-OFF and a backup possibility.

even though we will not be able to completely revoke the changes of an already xtc-clipped device, because the clip does not backup anything.

Current Status: stucking at [STEP 1]

Reason: Because of probable wrong metadata we are still not able to extract a bootimage and put it together again (the new image will not boot)

If we get behind that, we will have a chance to run a minimal custom OS on the phone.
[HTC Wildfire S] no.human.being:
Yes, step 3a is optional however. Well kinda ...

Of course we have to "backup" the page into RAM before erasing it, so that we can write it back later. However, a "true", "persistent" backup, say on SD card, is optional. I'll publish an OS image as soon as we have the possibility to S-OFF, even if we don't have any backup facility yet, as people are eagerly waiting for this and most are probably willing to S-OFF even without having the possibility of reverting to S-ON at a later point in time and I'm fine with that.

If it's really just the secu_flag we're modifying and nothing else, then we won't require any backup utility at all, as the flag has exactly two valid states so we can just build the OS to "flip" it instead of "disabling" it. So you boot the OS image on an S-ON device, it gets S-OFF. You boot it on an S-OFF device, it gets S-ON.

However, if we have to patch more than just the flag for whatever reason, this probably won't be revocable without a backup of the original Radio firmware (at least the modified pages).
[HTC Wildfire S] sythe179:
If its a timestamp, or if its a few bytes different, but its the same original file, why not hexedit and make it the same?
[HTC Wildfire S] m1ndh4x8r:
I feel dumb reading your posts. lol.
[HTC Wildfire S] theq86:
"symmetric signature" well this is a contradiction in my opinion. but maybe the implementer did not care :D

You say this exists in some implementations. Are there multiple implementations for android? if yes, maybe a different mkbootimg would help
[HTC Wildfire S] no.human.being:
It is not a "signature", it is a so called HMAC (Hashed Message Authentication Code). However, it is the "symmetric cryptography equivalent" to a digital signature, as both provide message integrity against modifications in transit. It works like this.

Like with any symmetric cryptography, you got to have a "shared secret" (K) established between the two contributing parties first. You also have to agree on a cryptographic hash function (say SHA1). Afterwards, the sender can calculate the HMAC of his message M by doing.

H = SHA1(K . M)

Where "." is a concatenation operator. He sends the HMAC along with the message and the receiver can verify the HMAC by doing the same calculation the sender did. He has the same secret K, he received a message M and he received the H value the sender appended to the message and then checks if his H value is the same.

If someone modifies the contents of M in transit, the HMAC will no longer match and the receiving end will notice and drop the message. The adversary can't forge a valid HMAC for the modified message either as he doesn't know the secret K.

So it's almost like a digital signature in that it prevents unauthorized modifications to a message in transit. However, contrary to digital signatures, both "signer" and "verifyer" of the HMAC use the same key K (symmetric cryptography). This means that, contrary to a signature, an HMAC provides plausible deniability to the sender of a message, as the receiver cannot prove that the sender sent the message in this way. The receiver posesses all the information that's required to "forge" a message, but no one else has it. So the receiver himself can be sure that the message came from the sender, as long as he knows he didn't forge it himself. However, he cannot prove this to a third party, as the sender could just claim that the receiver has forged the message. This is the key difference between digital signatures and HMACs.

So for transportation of messages over a network, HMACs make sense. However, for the purpose of "signing" a file they do not, as the symmetric key could be extracted from the verifying application and then used to create valid HMACs for arbitrary messages. So for Android, the HMAC doesn't make sense (and it's not verified either), but there are use-cases where this is a good and proven method.

Just search for "mkbootimg.c". There are lots of Git repositories on the net hosting their very own version of it. :D

And no, a different mkbootimg won't help. We just have to know how to parametrize it for the respective kernel.
[HTC Wildfire S] theq86:
maybe we should stick with a reference mkbootimg from google, if such exists.
[HTC Wildfire S] gauravjuneja01:
Incresed Internal Memory a little bit.....

I used MTD custom Partition with the help of a topic of Wildfire(buzzz).....

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

It change my Data Partition to 160 MB.... (increased 10 MB) ....

May it help you for change partioton........ Good Luck.....
[HTC Wildfire S] theq86:
Sorry, but that has nothing to do with our project here ;)
[HTC Wildfire S] gauravjuneja01:
I know about your product very well.... Bt the System partitions is also the goal.... (Mentioned 1st Post)....

So i thought that any code from Wildfire(Buzz) may help you.... Coz that is cracked.....

By the way, Sorry for disturb you......
[HTC Wildfire S] pihug12:
Do we only need the "-base" parameter or are there any others settings to set up ?

Maybe you can find some infos here : http://lyncd.com/2011/03/android-kernel-mkbootimg-base/

I don't know if it's useful but maybe we can add an "initlogo.rle" picture to check if the new OS is booting well if nothing can be shown on the screen after that. http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images

I don't know if it can work on a custom OS however.
[HTC Wildfire S] no.human.being:
I already knew about that one, but thanks nonetheless. The "mkbootimg" only takes one address which is "--base". I'll try out with the right kernel/initrd lengths extracted and correct "--base" and see if this gives us exactly the same header structure that the original boot image has.
[HTC Wildfire S] m1ndh4x8r:
9f9fdadde3b59b3060e78cbf837631cf - crack this baby.
[HTC Wildfire S] :
Cool. Can someone please tell me what this is.

BTLOI, I think it's a signature or hask key, etc.

Not sure if it's useful, but Cain and Abel is good with working with this stuff. When you download it, configure your AV to accept it.

Oh, and where are we now?
[HTC Wildfire S] hahahafr:
Not to break your dreams or anything but this very well looks like a sha1 hash. Unlike md5, the sha algorithm cannot be attacked, at least not bruteforced.

Edit: It's like trying to solve the world hunger problem before taking your breakfast, it doesn't make sense.
[HTC Wildfire S] no.human.being:
It's probably MD5, as it's 128 bits long. Definitely not SHA1, which is 160 bits long. No matter what it it, it's OT. :D
[HTC Wildfire S] :
No ideas. Says dedicated K devs are needed.
[HTC Wildfire S] benjamingwynn:
Okay, if I'm right wouldn't this exploit apply to every current HTC Android device? :eek:
[HTC Wildfire S] no.human.being:
Well yes and no. The principal idea should work everywhere. However, the address of the secu_flag in non-volatile memory will probably vary. And you'll have to build separate kernels for devices with different CPUs.

I couldn't find reliable information about the kernel's base address by grepping for it. If I understand the kernel source correctly, it expects base address of zero for devices without an MMU. Remember we built the kernel for the MSM7201 processor, as MSM7227 is not directly supported. Supported are MSM7201 and MSM7230 and we decided to go with the older chipset as we expected the chip to be backwards-, rather than forwards-compatible. Now I've selected "MMU support" during kernel configuration, but the only "MMU type" that can be selected for the MSM7201 is called "---", which to me sounds much like a "placeholder". :D

So I've built a kernel with base address zero. When I boot it, the phone will vibrate one time while booting the kernel, then it will vibrate again, indicating it is rebooting. After vibrating for the second time, the stock firmware (so in my case CM7.2) will boot.

Then I've built a kernel with base address 0x12c00000, which all the other kernels (Alquez' kernel, the kernel that comes with CWM recovery, etc.) seem to use. It will lock up with a white screen.

When I don't supply a "--base" parameter, it seems to default to 0x10000000, but as you know this will also lock the device up with a white screen.

The most fundamental problem is that I'm currently not 100 % sure whether the base address is a characteristic that is device dependant or rather a characteristic that is kernel dependant. So is it right to say "it must be the same address as with all the other kernels for the WFS no matter on which Linux version they are based" or is it rather "it must be the same address as with all the Linux 3.2.5 kernels no matter on which device they run"?

I think it's rather the latter. If I understand correctly, the information is stored in the header of the kernel image and HBOOT reads it and then loads the kernel into the RAM address that's supplied. So HBOOT is the part that's "flexible" and adapts to the kernel. And the kernel is the part that is "inflexible" and only supports being run from exactly one RAM address. So HBOOT loads the kernel whereever the kernel requires it. Now the question is, how to find out where Linux 3.2.5 wants to be loaded?
[HTC Wildfire S] theq86:
the exploits principle would be the same on all HTC devices implementing the security flag like the Wildfire S.

For example, the way to go on the Desire S and newer high end-phones is a different, because the memory location where the secu_flag resides is mapped (thus accessible via android and without a special kernel)

On our devices, the secu_flag is unmapped. That means it resides on a memory location we can not access within the android context.

You can imagine it that way:

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

so this exploit would only be necessary on our device and devices with a similar layout as wildfire S.

and even then it would differ in memory addresses.