yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
Will the token used for the first unlocking work another time or will I have to request a new one?

Ok, so we probably need to go with the "vanilla" kernel. I guess the CM kernel won't ever let us touch the Radio, even on a device that's unlocked via HTCdev. HTC explicitely stated somewhere that unlocking via HTCdev will keep the Radio firmware protected. They are probably required to handle it this way since the Radio firmware is what communicates with the phone network and you could possibly wreak havoc with the network or sniff on traffic or whatever one could do if one could replace the Radio firmware and then they'd probably get into serious trouble with the mobile providers.

Well, getting to understand it this far was already pretty challenging. So things we'll have to do in order to get this done.

1. Get a "vanilla" kernel booted on the handset.

2. Find the physical address of the secu_flag (via JTAG?).

3. Write some code that does the patching.

4. Glue it all together into a nice and convenient firmware image. :D

There's an alternative to 2 which is: Find the physical address of the HBOOT code that checks the flag (remember BeciMester has found it in an HBOOT image that was provided in an RUU) and then patch that in step 3. This is how Revolutionary does it. Disadvantage is that this kind of S-OFF won't survive flashing HBOOT. (Is this the only disadvantage?)
[HTC Wildfire S] theq86:
You can use the same unlock token, because your device token will never change. so if you still have the file, just do:

fastboot flash unlocktoken Unlock_code.bin

after re-locking and your device will be unlocked again.
[HTC Wildfire S] no.human.being:
Well actually we may just try it with Alquez' kernel, provided we get a version that can actually be built.

If we run into some weird permission problems we can always replace it with a "vanilla" Linux later on, provided we build our entire operating system around the kernel so that it doesn't make use of any "Android-specific" APIs.

But .. well .. I haven't got it to build so far, see here for the problem.

"Vanilla" Linux builds after lots of adjustments. The source code is just faulty as hell, as it is with every kernel I've come across (time to get quality assurance right guys), but most corrections are quite obvious and straight-forward, sometimes as simple replacing some nonesense like ...

int, i, =, 10;

... with ...

int i = 10;

... no joke! The kernel sources are that bad!

Then I bundle it together with an initrd using "mkimage" and boot it via fastboot, but it locks up the device.

For the moment just give me any POSIX-compliant kernel that has sources that will build and boot on the device and I'll start "tinkering around". I haven't found any yet.
[HTC Wildfire S] MrTaco505:
quick question, if the handset is s-off will the kernel from that device still protect or unmap the NAND Memory?

Also have you heard when your JTAG is coming in?

Sent from my badass overclocked HTC Wildfire S.
[HTC Wildfire S] no.human.being:
Yes, it will protect the "controller initialization code" (all the firmware from ARM Ltd. that's run at the very beginning, initializes the controller and loads the Radio and HBOOT into RAM), the Radio and the HBOOT. Obviously I haven't skimmed through all the kernel code, but I think so.

Keep in mind that both Radio and HBOOT are already "loaded" before the Radio starts executing, but the HBOOT code is "halted" and only executed when the Radio "allows" it to do so. So there's some very very low level firmware on the device that is from ARM Ltd. and does processor-specific stuff, then loads Radio and HBOOT into memory and passes control to the Radio, which has full control over the Flash. At some later point the Radio "gives up" control over the Flash and "signals ready" to the processor firmware. When this happened, the processor firmware will configure Radio and HBOOT to run "in parallel", like two operating systems on a virtual machine monitor. HBOOT will take full control over the Flash and use it to load a kernel into RAM and pass execution to it. After this has happened, HBOOT is "gone". It will never execute again until the device is rebooted. Radio will of course continue running, so that at this point Radio and Android run in parallel and communicate with each other via shared memory, while Android has full control over Flash and Radio uses RPC (remote procedure calls) to Android when it needs to access anything from Flash, since it has "given up control" and thus can no longer directly access the Flash.

I don't think that the page tables are set up depending on the status of the secu_flag. The page tables are required to have an address space set up which the operating system can later use for working, for accessing volatile and persistent storage, for communicating with the Radio and with "peripherals" via shared memory mechanisms. So the address-space is quite critical, I don't think that they set it up differently depending on whether the device is S-ON or S-OFF.

As far as I know you can perform Radio updates when the device is S-OFF, but I think these are not performed with one of the "big" kernels ("main" or "recovery" kernel) booted up.

No. I've issued the payment and haven't heard from them since that. However, they mention on their website that international shipping will take a while.
[HTC Wildfire S] MrTaco505:
If we locate the secu_flag on the s-off handset are we able to use the same address on an s-on handset. I keep getting a feeling that we need to be s-off to look through that partion. But if we are able to read the NAND we can look for the secu_flag and know where we need to go.

I'm just thinking from the top of a 14 year old head. :)

Well hopefully you'll get it soon or maybe you got jacked! :)

Ahhhhh you edited your post right before I posted this but thanks for the info.
[HTC Wildfire S] no.human.being:
Yes. However, depending on the S-OFF method used it might be difficult to locate the flag. Revolutionary patches the HBOOT (which contains the code that actually checks the value of the flag) not to look for the actual value but simply return "S-OFF". Remember that the actual value of the flag resides in the Radio firmware, so think of it something like that ...

/* 1 */ int secu_flag = 1;
/* 2 */ int* secu_ptr = &secu_flag;
/* 3 */
/* 4 */ int check_secu_flag()
/* 5 */ {
/* 6 */ return *secu_ptr;
/* 7 */ }

Line 1 and 2 are part of the Radio firmware, lines 4 to 7 are part of HBOOT. In reality, it's actually even more difficult. HBOOT only has an address where a pointer to a data structure lies, which contains (among lots of other stuff) the secu_flag. The data structure is definitely part of the Radio firmware and the pointer most likely is also (the pointer is definitely not part of HBOOT, we've already confirmed that, so we think it's also part of the Radio firmware).

When the controller initializes, both Radio and HBOOT get loaded into RAM, probably to "adjacent address ranges". The Radio has the actual value of the secu_flag and it has a pointer to that value, while the HBOOT has a pointer to that pointer. And Android itself, well ... I'm not sure but it either calls that "check_secu_flag()" function of HBOOT (provided HBOOT remains in memory when Android is booted) or implements it on its own. I wouldn't be too surprised if it actually did the former. Kernel developers are some quite perverted people. :D

Now when you S-OFF with xtc-clip, it basically changes line 1 to:

/* 1 */ int secu_flag = 0;

However, when you S-OFF with Revolutionary, it rather changes line 6 to:

/* 6 */ return 0;

So after you obtained S-OFF via Revolutionary, it might be difficult to locate the flag in memory, as the value is unchanged, but the "pointer" to it is gone. On the other hand, if you S-OFF via xtc-clip, the pointer is still there but the value is changed, so this would be better for reverse-engineering.

If we manage to boot a Linux kernel on the device, we can definitely read/write everywhere, even on an S-ON device. We should even be able to see that "processor specific initialization code" by ARM Ltd. that Qualcomm put on the chip even before HTC touched it for the first time.
[HTC Wildfire S] MrTaco505:
So if we are able to open up a radio.img we can check for the value of the secu_flag from which the radio points to? If so after the build of a functional "vanilla" kernel we just patch the HBOOT?

I'm actually not focusing on the kernel process because I have no idea what to do with the help of building one.

I'm on my phone...........
[HTC Wildfire S] no.human.being:
The image will only show what's in persistent memory. The controller firmware loads Radio and HBOOT from persistent memory into "adjacent areas" in volatile memory, then runs both in parallel. We probably need to see both Radio and HBOOT "lying next to each other" in volatile memory in order to understand what's really going on. All the addresses we see in the Radio and HBOOT code are going to be addresses in volatile memory and we currently have no idea which part of the persistent storage gets loaded to which part of the volatile storage by the controller firmware. We just see that HBOOT "touches something that lies outside its own code segment" and we have strong hints that this "somthing" will be part of the Radio, but we actually have no idea what exactly it is touching. We won't see this relationship from the two firmware images alone as long as we don't know the code which loads them into memory and how they interact.

It depends. If it's "easy" to find the secu_flag inside the Radio, why shouldn't we patch the Radio? I'm not sure if there are substantial differences between the two methods, it's just that patching the Radio seems more like "the right way to do it" and it'll also persist HBOOT updates, which a patched HBOOT obviously will not, so why not patch the Radio?
[HTC Wildfire S] MrTaco505:
Yea i think patching the Radio is the right hing to do. I thought HBOOT was the key for s-off after reading the past posts.

So this something is also a target we need to look forward on finding what it is and does?
[HTC Wildfire S] no.human.being:
Well...

First thing we need to do is get a kernel running anyhow, as the thing with "locating the flag" is more or less "blocked" until I got all the hardware that's neccessary to access the phone via JTAG.

The entire "building the kernel + initrd" as well as the programming of the patching code by itself can all be done without actual knowledge of the location of the flag. If we were fast, we could get it all done before the JTAG adapter arrives so that the only thing we need to do with it is put the right address in in the end. :D

Not that I really expect us to be that fast. Just want to mention that there's enough work to be done. Not knowing where the flag resides shouldn't "block" us at all.

No, basically we think of it as some kind of "jump table". It holds lots of references, including one that points to a data structure that contains (among other stuff that we also don't know and care for) the secu_flag. We don't really have to "understand" what it does. All we have to do is follow the pointers until we've found the secu_flag in volatile memory (this is probably the easier part) and then find out from which part of the persistent memory this all stems from, since what we see while the code is running is all volatile (this is probably the more difficult part). We'll know that in the end we'll have a pointer to a machine word which has the secu_flag as its least significant bit, so we read the entire page from Flash, flip the bit we identified, then erase the page and write the content back (Flash can only be programmed in entire pages, so we can't overwrite a single bit or byte, but we'll have to write the entire page back), reboot the device and be S-OFF.

Of course, after we have identified where the flag resides, we can first try to flick it via JTAG and confirm that the device is S-OFF afterwards before we put the address into our code, but well ...

HBOOT is the starting point for locating the flag as it contains the routine that is called when the flag needs to be checked and it could be a "fallback" if "patching the Radio" should turn out to be too difficult somehow.

EDIT: Patching HBOOT could also turn out to be quite difficult. I've identified 18 functions inside HBOOT, which do more or less the same (following the same pointer to the "jump table", but then fetch a different "target pointer" from a different offset from within that table and read the value to which is points) and there are probably many more of a similar kind, possibly with different "jump tables", etc. This really ain't as obvious as it seems. BeciMester has identified one of these functions to be "special", however, since it is called before the HBOOT prints "S-ON" or "S-OFF" (remember the first line when you boot HBOOT says "MARVEL PVT SHIP S-ON"), so this is probably the right one. :D
[HTC Wildfire S] MrTaco505:
You should check this out no.human.being

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

I'm on my phone...........
[HTC Wildfire S] theq86:
I wrote it in a different thread for some reason. It has nothing to do with the permanent s-off solution on which is worked here ;)

If it works what I wrote, the S-OFF will be gone as soon as a different bootloader is flashed. so it is no "one time and forever" solution.
[HTC Wildfire S] :
Damn!

Damn! I have done some experiments with that ROM though, b4 you made that post.

This bloody S-OFF business is deteriorating my brain cells (not that I had much to start with anyway :D)

I've been thinking..... Let's work from the top.

So, the smart guy around here (I'm thinking no.human.being) can pretend he's an HTC guy. He already has Android with Sense on it. Now he has to think of how to get the phone to work with it. Then he has to think of a way to make the secu_flag and turn it on, therefore making S-ON. Then, we could use those steps in reverse, and get S-OFF. Also, we should think about what XTC-Clip does.

Also, we could hack/RE those unlock tokens, and use them.

Also, since we're focusing on Kernels, instead of vanilla, let's make chocolate (nice word i made for this stuff). We could get the original HTC Kernel and RE it or modify it for S-OFF. Also, this may be of some use:

http://www.htcdev.com/devcenter/downloads

Look for HTC Wildfire S (Globalive WWE) - GB MR - 2.6.35 kernel source code

There are lots more of those.

Sorry if these are crap suggestions, but the thing is, this stuff is still very complicated.

I am learning Java though, see:

package second.project;

public class SecondProject {

public static void main(String[] args) {

int number1 = 10;
int number2 = 2;
int answer = number1 + number2;

System.out.println("Hello. Bad-Wolf wrote this. 10 add 2 is: " + answer + "." + " My age, by the way!");
System.out.println("Hoped you liked it!");

System.out.println("Goodbye!");

//This is just beginners code by the way. Probably very obvious, especially for people like no.human.being. Feel free to use this code!

}

}
[HTC Wildfire S] no.human.being:
Why would I pretend that? :confused:

I have Cyanogenmod 7.2 with Alquez' kernel on the phone.

I have to do what? :confused:

My phone is S-ON.

We already know what it does. At least in principle.

You have to put a MicroSD into the clip, which is turned into a Goldcard (special boot sector containing a "key" that depends on the CID). It also puts a special diagnostic utility onto the SD card which was designed for internal use by HTC engineers but was somehow "leaked". This utility is signed with an HTC key so HBOOT will load and execute it when it finds it on the SD card.

The utility checks the phone's SIM card slot for a special "engineering SIM card" to be present and asks the Radio to turn security off when all the "credentials" on the SIM were successfully validated. The xtc-clip emulates this SIM card via a microcontroller that's integrated into the clips housing and programmed with a firmware for exactly this purpose. If we were to modify the diagnostic utility not to verify the engineering SIM, it would no longer execute since the signature would no longer match.

The goal is to obtain S-OFF, not to obtain an unlocked bootloader without resorting to HTCdev.

Why should I? I'm interested in booting entirely different firmware on the handset, that is not in any way based on anything that's from HTC. Not even

indirectly

.

How would I use this code? We're doing

kernel-level development

here and system code is written in

C

, as this is a

compiled language

which means the compiler generates

native

or

machine code

out of your C source. Java is an

interpreted

language with

automated memory management

running inside a

virtual runtime environment

. It is

completely unsuited

for programming exploits.

I don't want to be impolite, but unless you're both able and willing to do

kernel development

here, your contributions are definitely off-topic so please don't post them in this thread.
[HTC Wildfire S] MrTaco505:
DAMN!! LMAO
[HTC Wildfire S] no.human.being:
:eek:

Please don't quote it all ... ;)

People are reading this with mobile devices.

I have the impression that this thread gets far too much attention. Could xda-developers.com please move our device back to the "low activity" area? It wouldn't attract that many trolls if it were there. :D
[HTC Wildfire S] theq86:
after reading bad-wolf's post I got the thought he might be drunk.:D

Let's first go through the vanilla kernel theory. if we're goddamn failing with it we have enough time to reverse engieneer everything bad wolf likes to do. :rolleyes::D
[HTC Wildfire S] Mazer.one:
i learned programming TURBO PASCAL, if you need some help for your kernel, don't hesitate.

LOL. :D
[HTC Wildfire S] theq86:
okay, we had some fun. but now back to serious business. this is still a working thread which does not profit from jokes and "blue sky ideas"

@nhb:

how do you determine if the kernel is booting or not? if you can see no output how would you know?
[HTC Wildfire S] no.human.being:
It's called alcohol, not S-OFF. You could try dropping the phone into a glass of whisky and see if it's S-OFF. I wouldn't suggest that though. :D

Well. I have compiled the kernel with bootsplash support. So we should see some image (probably an image of Tux :D ) getting drawn to the screen when the kernel is loaded and probably also some message like "Loading Linux 3.2.5 ..." and "Loading initrd ..." (at least I see such messages when booting Linux on my computer), but it's not happening. The phone just completely locks up and will no longer respond to anything, so the only thing you can do is pull the battery.

Furthermore, I've built a minimal GNU system into the initrd, so after the kernel has booted up completely, it should start init (which also prints a lot to stdout while booting the system) and bring up a Unix shell on the device's screen. Obviously this ain't happening either.
[HTC Wildfire S] d33ps1x:
Love it. Nice and clean.
[HTC Wildfire S] :
I wasn't intending for it to be of any use, and like I said, my suggestions are crap, and I'm trying to keep up and understand what's going on; and be a helpful member of society. I'd be happy to do kernel development, I just need to know what to do (language to learn, etc.) and how to do it. Due to the fact that I'm only 12, it's amazing how I already have technical knowledge that most other 12 year olds don't have, but I am still trying to learn more and keep up.
[HTC Wildfire S] no.human.being:
Ok, so I'll probably withdraw the alcohol argument.

However, I have the impression that for the moment there's not much you can do other than staying in the background and watching the magic happen. I don't want to withdraw you from getting involved, but you'll need quite specialized skills to contribute (especially machine-oriented and system-level development) and we're already quite deep into the matter. This is not a beginner's thing. If you have the impression that you can actually contribute some of your ideas, feel free to do so. But most of the time you're probably going to kick back and enjoy watching others doing the heavy lifting.
[HTC Wildfire S] :
Yeah. I contribute because I want to have a part in what's happening, no take the end result for granted not having a clue how it works. It is probably difficult to understand, but I am a very unusual person.
[HTC Wildfire S] heavy_metal_man:
Perfect ;-)
[HTC Wildfire S] hahahafr:
@nhb Have you tried using a 2.x kernel? Kernel compiling is mystery for me, but in an earlier post you said the 2.x didn't compile at all, maybe there's something here.
[HTC Wildfire S] no.human.being:
I've tried both "vanilla" Linux 2.6.35 and the CM-7.2 kernel from Alquez (which is based on Linux 2.6.35.10) and both had very serious problems that I could not overcome, like "#include"-ing files that were just entirely missing from the source packages and stuff like that. I don't think I'm supposed to take these files from another (older?) release that might still carry them around or simply remove the include statement, so this is a dead end.

I could just download lots of releases and see which of these will build, however this will be quite an effort as even the 3.2.5 release (which DID build in the end) required LOTS of work on the code to finally get it through, so it's not just "try to compile and if there's an error forget it". Instead, you have to review every error and see if there's a rational way of fixing it and in the end you get all of the problems solved or get stuck on one that is a blocker. This is why I'd rather stick with the 3.2.5 (which seems to be a good candidate) and get it running on our target.
[HTC Wildfire S] theq86:
what about the reverse way? take a working kernel and see which part causes the restrictions?
[HTC Wildfire S] no.human.being:
The kernels are open-source. I don't want to take a "black box" (binary), I want to build it from source. If we want to modify it, we'll need to build from source anyways. The CM7.2 kernel (binary) is obviously "working", but it doesn't build from the source that is provided. Or do you want to take the "working" binary that ships with CM7.2, disassemble it and take the restrictions out? *lol* :D

It's bad enough that we have to reverse engineer the proprietary HBOOT and Radio firmware. I really don't want to start reverse-engineering software that's principally open-source. In addition, such a kernel is far too complex to reverse-engineer. The current release of UBOOT (an open-source bootloader for embedded Linux) is 124k LOC (lines of code) in C, HBOOT is probably far less since UBOOT is much more universal than HBOOT is and has some quite advanced features. In comparison, the Linux kernel currently has about 15M LOC. This really ain't something that you'd consider a good target for reverse-engineering. :D

The most reasonable way of doing it is to get "vanilla" Linux working on the device, preferably Linux 3.2.5. It's designed to run on the ARM platform, we're just doing something wrong.

BTW if someone's interested, we could try to get UBOOT running on the device after we're done with this S-OFF thing to replace HBOOT. This could be the path to entirely free firmware for our devices. It's a much bigger effort though, so it's not something we'd consider an alternative to cracking HBOOT. Porting UBOOT will probably be a real long-term project, but it could be a fun activity if we'd want to remain busy after we're done with the exploit.
[HTC Wildfire S] MrTaco505:
Remember when you said that the handset would pick up when you flashed your kernel? Don't you think there would be another security part that made the phone lock since it saw that the NAND was not being protected? I'm just thinking from my knowledge.

BTW this is my 100th post I should add a lot of smiles :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :D