yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] theq86:
It is also possible, that even a vanilla kernel will not lead us the way.

I spent the last days comparing the firmware mtd driver with an untouched driver.

I have found no changes that would implement an extra security based on reading the secu_flag.

It is still possible, that HTC "obfuscated" or treated the radio area in a way that not even the mtd driver will be able to overcome. Because no reference to any secu flag is in the mtd drivers and they do not really differ from the vanilla mtd drivers I probably think the security lies not in the S-ON/S-OFF flag, but in the way the mtd driver works. It would take us forever to find out why exactly the mtd driver does not write the nand.

Remember, we got no error messages. And never when any radio or hboot is flashed, a Linux kernel is involved.

I think the low level OSes write the data in a special way, corrupting them afterwards.

Would it somehow be possible to mimic a write process of the low level OSes in the radio using the linux kernel? I really don't think the mtd driver is able to do our work.

---------- Post added at 03:01 PM ---------- Previous post was at 02:59 PM ----------

this is what we tried. we were on a minimal Android/Linux system. All the radio stuff has been executed long time ago at this stage. so we ARE not relying on the bootloader @this time.
[HTC Wildfire S] ratafak_plachta:
mtd driver

I compared Android kernel 2.6.39.4 and Linux 2.6.39.4 mtd driver and also found no relevant difference. Just thinking whether it is not just a bug you are getting result code 0. This could be because of insufficient capabilities? Maybe trying kernel with capabilities disabled would help.

The

ret = (erase->state == MTD_ERASE_FAILED)?-EIO:0;

in the case MEMERASE in mtd_ioctl look very suspicious.

I could not find erase method implementation of struct erase_info so I cannot verify what other result codes are possible....

I am not a kernel developer, so I may be wrong. Just thinking about...
[HTC Wildfire S] a.s.j:
But from what I understood, you still need the HTC Dev unlocked one to even boot the fastboot way to get there right? And this is what I am wondering about... :(
[HTC Wildfire S] Lt.Win:
Reading all this, I'm guessing HTC guts are geniuses of some sort. Also, I'm trying to find kernel developers over at other sections like aria, buzz, etc. They could help us. :D
[HTC Wildfire S] humzaahmed155:
I dont think the Buzz/Wildfire would help so much since the hardware is quite old on that phone, i dont know maybe the aria could help you guys.
[HTC Wildfire S] theq86:
Thanks for clearing up the reason. So maybe we need only to compile another custom version of mtdtools.
[HTC Wildfire S] no.human.being:
This is the source of flash_erase (what we're currently using for erasure). I'm currently not understanding all of it, but the loop at line 237 is doing the erasure.

You see that it performs lots of checks and breaks the cycle (moving to the next block with "continue;" without erasing the current at hand) or even aborts the complete erasure ("return;") when any of these checks "fail".

int ret = mtd_is_bad(&mtd, fd, eb);
if (ret > 0) {
verbose(!quiet, "Skipping bad block at %08"PRIx64, offset);
continue;
} else if (ret < 0) {
if (errno == EOPNOTSUPP) {
noskipbad = 1;
if (isNAND)
return errmsg("%s: Bad block check not available", mtd_device);
} else
return sys_errmsg("%s: MTD get bad block failed", mtd_device);
}

So when the mtd_is_bad(...) call returns something other than 0, then it aborts. If the return value is greater than zero, it just skips the current block, if it's lower than zero, it completely aborts the erasure.

if (unlock) {
if (mtd_unlock(&mtd, fd, eb) != 0) {
sys_errmsg("%s: MTD unlock failure", mtd_device);
continue;
}
}

When the mtd_unlock(...) call returns something other than zero, it skips the block as well.

if (mtd_erase(mtd_desc, &mtd, fd, eb) != 0) {
sys_errmsg("%s: MTD Erase failure", mtd_device);
continue;
}

Here it actually tries to erase. Now what I don't understand is, why is it trying to "unlock" the block first and only when the "unlock" succeeds it erases it? Wouldn't it be more logical to try to erase the block first (if it's not marked "locked" the erase will succeed) and when the erasure fails then unlock it and erase again after unlocking (then it will certainly succeed). The way it's written here probably will only erase blocks that were marked as "locked" before. I could imagine that the unlock call returns an error when the page is not locked and then the utility just moves on without erasing, wtf?! :D

However I'm not sure. This is all not very well documented you see? :D
[HTC Wildfire S] :
If HTC was a person I'd punch them in the face!!!!

Let's sue 'em for theft.
[HTC Wildfire S] schlund:
@NHB: Where does it skip now ? What is the error message ?
[HTC Wildfire S] heavy_metal_man:
Gentlemen, about your legal concerns. Are we forgetting that revolutionary do what we aim to do, on somewhat a commercial scale.( even if we do not have to pay currently) they seem to be fine....
[HTC Wildfire S] :
That's actually true!!

Has anyone ever had the thought that HTC/XTC-Clip is watching this thread, deliberately putting us down, or something.
[HTC Wildfire S] XDA_h3n:
I'm back from gaming to this campaign.

I did mention HTC may be looking at this thread; since anyone random has access to this forum...

I'm just wondering how did the XTC-Clip get access to radio, it must have booted XTC clip before the boot process, or something. Im not trying to reverse engineer XTC-Clip due to copyright reasons, but if I

can

I'd decompile it.

But I'm wondering something, revolutionary at the end would steal our s-off exploit because they couldn't do it, is there a way to "seal" our source code so they won't.
[HTC Wildfire S] theq86:
It doesn't. Everything important makes the diag tool the clip copies to the sd. the actual thing the clip does is to mimic an engineering sim from htc to make the diag tool do the work.

Remember, while S-OFFING the clip is not connected to the phone (only to the sim slot)
[HTC Wildfire S] XDA_h3n:
So that how it works, its basically a test-sim emulator which runs a DIAG file at bootloader. Its just how I sent my desire HD to repair last year and I noticed it was s-off instead of me trying to s-off it with a HTC Ace Hack Tool kit program.

Now since we can't mimic a sim due to the fact we cant exploit the sim area. If only I knew how to write kernel's instead of customization and to stop useless programs coding.

Um I'll be thinking of theorys and reading the thread since I left, and see if I can come up with a theory.

EDIT: Would the kernel at HTCDEV help for s-off at any chance since I want to compare some kernels with other HTC phones.
[HTC Wildfire S] theq86:
at first we should concentrate on the mtd driver/tools. I think we really do not need a new kernel compiled.
[HTC Wildfire S] XDA_h3n:
Okay I'll research on mtd driver/tools then.

---------- Post added 10th March 2012 at 12:02 AM ---------- Previous post was 9th March 2012 at 11:41 PM ----------

Didn't find out that much, just some company names like onenand is from Samsung. And how some of the mtd-tools work from the kernel source on htcdev website for the marvel europe kernel, I'm going to research a bit more in the morning; I just liked how much of the files were C Source files open-able in Microsoft Visual Studio on windows.
[HTC Wildfire S] bingzz:
I'm not sure that Microsoft Visual Studio is the best program to use when dealing with Android/Linux Kernels.
[HTC Wildfire S] XDA_h3n:
I know, ubuntu wasn't booting up got to get it fixed.
[HTC Wildfire S] :
The last thing we want to do is use anything HTC based. It's meant to be Vanilla.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] mstfkaratas:
There is a script called custom MTD to resize system, cache and data partitions, it patches recovery and boot for resizing, i think it is the same as what you do to map radio, but you can look at it at here and here
[HTC Wildfire S] oldirty918:
use root explorer or something like to check file name make sure there are no hidden extensions like .img.img or try to rename file .zip to change extension then rename back to .img Idk if this will help but ive had it not work cause of this

Dirt

Sent from my SuperSonic iVG on my WiFi network
[HTC Wildfire S] seaskyways:
So you guys are trying to exploit the mtd drivers or make a kernel ??
[HTC Wildfire S] :
I think you need S-OFF to do that.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] Lt.Win:
Yes, you need S-OFF for that.

Sent from my HTC Wildfire S powered by CyanogenMod 7.2
[HTC Wildfire S] :
Finally!!!

I was right!

LOL
[HTC Wildfire S] MrTaco505:
I think this s-off campaign isn't going well anymore :(
[HTC Wildfire S] theq86:
don't lose hope. the last weeks brought us so many new insights and took us really far forward in our progress.

There's nothing bad about some days where not every developer out here is posting all day long.

nhb is busy and has a real life, too. There is a way and we gonna find it. This campaign is not dead just because developement slowed down.

the best learning is learning by failure. it's the failures leading us the right way and let us understand what is going on.

Embrace Errors, they're your best friend ;)
[HTC Wildfire S] :
Well I tried your advice on making an Android app, hello android, and it worked.

BUT.....

Turns out it's not as simple, I have to learn the Android library thing, and I have to learn XML to design the GUI.

Damn it!!!
[HTC Wildfire S] theq86:
Did you expect it to be so simple that you can learn it all on a day? Sorry, it's not that easy.
[HTC Wildfire S] *se-nsei.:
isn't that a little off topic? this isn't a wfs cafe thread.
[HTC Wildfire S] :
Na, I was just up for the challenge, lol. Perhaps, when im done with java, ill take interest.
[HTC Wildfire S] *se-nsei.:
that's enough, thanks.
[HTC Wildfire S] seaskyways:
Well then , we'll have to wait ... what's up with Alquez , he didn't show up on this thread yet , exclaiming any updates ....
[HTC Wildfire S] MrTaco505:
@nhb or theq86, do you have a fastboot command that would allow me to load a recovery into RAM with hboot 1.03.0001?
[HTC Wildfire S] seaskyways:
1.03 ?? that is not for the Wildfire S ??
[HTC Wildfire S] Lt.Win:
There is an hboot 1.03.0000, when I got my motherboard replaced, I had that hboot version.

Sent from my HTC Wildfire S powered by CyanogenMod 7.2
[HTC Wildfire S] theq86:
Unfortunately, no. Only the unlocked bootloader accepts the fastboot boot command :mad:
[HTC Wildfire S] :
1) What are you planning to do, I'd love to know!

2) It's gonna be something like:

fastboot boot (kernel addresses or something) (ram addresses to load recovery into) (name of recovery image, that you have navigated to)

I really wish I knew more about memory addresses, starting to feel really unwanted aroud here, lol.
[HTC Wildfire S] MrTaco505:
I have downgraded to hboot 1.03.0001 with S-ON. I made a tutorial on how to do so.

I wanted to try the fastboot command and load the recovery into RAM and get the radio.ing for nhb or theq86 to look at.
[HTC Wildfire S] theq86:
A lil bit :D

Don't get me wrong, I understand that you like to contribute your ideas and be one of the guys who get credit for this s-off campaign. It's even no personal matter. But you lack the skills and knowledge to understand what's going on. The ideas which you meant to help us sound mostly like nonsens, especially if you put it together with some Doctor Who related stuff. I also like Doctor Who, but it has nothing to do with reality and will not help us.

I know, my words sound frustrating, but your time hasn't yet come.

But maybe later on you can get credits for entertaining us :D
[HTC Wildfire S] no.human.being:
Their domain is registered in "British Indian Ocean Territory". They might only be fine since they're so hard to pursue.

Right. It were only about 48 hours where I didn't post here, as I'm only having access to my development ressources when at home and that's enough for everyone here to go crazy and start wondering whether I'm still alive and working on it. :D

I mean of course it's one of the biggest appreciations you can get, but seriously, remember I'm doing this as a "spare time activity". It's not my full-time job. :D
[HTC Wildfire S] einstein.frat:
here's how the soff exploit works. as I understand.

flash custom kernel. installs custom hboot. runs custom exploit. done. s-off achieved next step

is to install a custom rom. custom radio. custom splashscreen. and custom partitions. or ported custom roms. or add a custom xploit to wildfire s to hack a ps3.
[HTC Wildfire S] theq86:
Not exactly.

1. We don't flash a custom kernel, we load it into the ram and add some special parameters to map the hboot as a mtd partition.

2. We don't install a custom HBOOT. We read out the hboot and flash the same hboot again, just patched with a few values.

3. The exploit is no more than a program that changes bits and pieces of the hboot in RAM.
[HTC Wildfire S] :
Fine then. I understand that everyone hates me for my suggestions, so, therefore, nobody will hear a word from me unless I think it's important. And no, I don't want credit, the last thing I want is credit. I hope everyone is very happy now that I have decided to go away. And thank you to the 5 people who clicked the Thanks button; I now have a very good idea of who doesn't like me for being me.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] heavy_metal_man:
Dude nobody hates you. Your blowing that comment way out if proportion. We are all egar to help out and all want a steady s-off exploit but at this stage we need to sit back and let the pros do their work. Don't take it to heart but your comments can be off topic and confusing. I think what theq86 is trying to say is that we need to stop filling the thread with off topic stuff and let them talk about the main issues we face. There is no need for us to start pointing fingers and arguing with each other. We are all on the same team with one goal! Just take the time to read over your posts before you post them and ask yourself is this on topic :) we'll get there in the end guys, but lets leave it to the pros now eh?:cool:
[HTC Wildfire S] ratafak_plachta:
kernel/utilities

The difference in Android mtd driver is that the panic_nand_write was replaced by nand_panic_write method. One of the differences between the two is

ret = nand_do_write_ops(mtd, to, &chip->ops);

is missing. Could be relevant. But due to comments this function is used only for writes while interrupt handling.

Probably better way would be tweeking with mtd utilities and removing bad block checking from them.
[HTC Wildfire S] MrTaco505:
Faatboot commands work on hboot 1.03.0001 but does anyone have a command that would load the cwm recovery into RAM?
[HTC Wildfire S] theq86:
Yes, of course some fastboot commands work. but not the one needed to load a kernel into ram.

just try for example:

* open a shell or cmd window

* take a recovery.img into the current directory

* activate fastboot mode

* type: fastboot boot recovery.img

What does it say? ;)
[HTC Wildfire S] MrTaco505:
The new xda premium app is buggy o_O
[HTC Wildfire S] MrTaco505:
Well I was hoping for the long fastboot command that nhb made for hboot 1.08 and 1.09

EDIT: Didn't work but I had a good try :)
[HTC Wildfire S] theq86:
if you want this "long command" please don't be too lazy to go some pages behind :mad:

it would also not havethe expected effect. Even if you'd be able to boot a recovery via fastboot with 1.03.0001 this hboot and radio version would have totally different memory addresses.
[HTC Wildfire S] Will32:
What will it say? I don't have a wildfire s yet, I'm expecting it Friday maybe and I've trying to read up so I won't have too many questions. On my EVO 3d (htcdev unlocked s-on) "fastboot boot recovery.IMG" works perfectly so that I can write to boot.
[HTC Wildfire S] theq86:
@xcpefrmreality

On an S-ON device with locked bootloader the fastboot boot command is not allowed.

On an unlocked phone this command works.
[HTC Wildfire S] Will32:
Gotcha, I'm gonna wait till I have the phone before I ask any more questions, I think having it will answer some for me.

Thanks for the reply.
[HTC Wildfire S] hahahafr:
By the way, has nhb already received the JTAG interface to the WFS?
[HTC Wildfire S] theq86:
ages ago. but has not been useful by now.
[HTC Wildfire S] no.human.being:
Exactly. I wanted to use it to check if there's anything "hidden" on the device, but since we already found the "unmapped memory" area (as well as a way of accessing it through software) "ages ago", I didn't have any reason for making use of it.
[HTC Wildfire S] Will32:
Tried chad.goodman?
[HTC Wildfire S] MrTaco505:
so since the secu_flag in the radio for the wildfire s is not actually printed as secu_flag, how was the "secu_flag" in the desire s and evo 3d found, was it exposed as secu_flag in radio?

EDIT: I got a feeling that we should look at mtd6 (devlog) because it mounts mtd5, mtd4, and mtd3
[HTC Wildfire S] theq86:
Reverse Engineering. Even if the flag has no label "Hello, Here I am, I'm the secu_flag!" you can still find it out, just harder.

devlog is not mounting anything. the mtd partitions are mapped at kernel boot time. the kernel parameters determine where on the nand the partition starts and how large it is. You could even map 512 mtd partitions which are 1 MiB large. Or the nand as whole being called mtd0. But only in the partitioning that HTC determined the phone works.

There is, however a big difference in mapping and mounting. Mapping is done at the very beginning of kernel boot. First when partitions are mapped they can be mounted.

The first one being able to mount a dev partition is the kernel after mapping the memory. And the kernel is also the one mounting /system, /data, /devlog and so on.

So you see, devlog is not mounting anything. It's just a log partition
[HTC Wildfire S] einstein.frat:
Maybe you could make an exploit with downgrade and flash the Rom_01 trick to achieve S-off.
[HTC Wildfire S] theq86:
You can downgrade to any hboot different from 0.90.0000. Flashing 0.90.0000 will lead hboot to bypass the installation because it has known security leaks (especially the so called rom_01 trick making s-off)

So you can not downgrade to 0.90.0000 to gain S-OFF.

Making an exploit to turn off the bypassing would be impractical. Because when we have write access to the radio we have the ability to turn s-off immediately without making any detours.
[HTC Wildfire S] heavy_metal_man:
Sorry bud :D
[HTC Wildfire S] theq86:
Okay guys,it's time to make a split here.

I've created a new thread: HTC Wildfire S Internals - Questions and Answers

This is where all your questions regarding the phone's internals should go from now on. It is meant to be a Q&A thread where I try to answer as many questions as I'm able to.

You can ask questions there about how everything works and stands in connection with each other.

The plan is to seperate your questions and interests from the real developing progress.

@sensei: please cut out below and append to OP, thx

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

Q: When am I supposed to post here?

* you know where we stand in progress at the moment

* you know what the plan and the roadmap is

* you can contribute an idea how to solve the current problematic

Q: When I am not supposed to post here?

* you don't know what exactly is going on

* you can not reproduce or understand the steps made until now

* you want to make a "suggestion" which other way or detours we could take to s-off (means basically to propose a completely new plan)

IMPORTANT:

I know it is MUCH to read. But I recommend EVERYONE wanting to REALLY contribute n.h.b and the rest of the active developers to read from the beginning. Almost every question I read here was regarding some matter spoken about several pages ago. If you really plan to contribute you must know where we are and not wondering how this and that works.

If you have problems understanding what is going on, post here and I will try to get you a light :D

---------------------------------------------------------------------------------
[HTC Wildfire S] :
Well, when you do get your WFS, I'm sure you'll make a good part of the team. You're doing exactly what I should of done. When I got my WFS, and realised all this S-OFF stuff, I wasn't happy. But thankfully the bootloader was unlocked and now we got a good team of devs that are getting closer to S-OFF, and have successfully killed radio protection (by making an mtd7 partition) and a BIG bunch of other stuff.

Well, if we get the ROM_01 and instead of using fastboot, maybe we can "directly" flash it in the mtd7 partition. I don't mean JTAG. But considering it flicks the flag, maybe if we look into it we can find the pointers.

But there's one thing I don't understand:

Are we patching HBOOT or trying something else?

Yes, what he said. But before, he said he would like to try a less "invasive" method. So he didn't have to open it up and detach all the peripherals (touck keys, lights, speakers, etc.). Get one thing wrong, and your phone goes ka-put!! Turns out, that was a pretty good move! :D
[HTC Wildfire S] theq86:
Well, it is no problem to flash rom_01.zip over a non 0.90.0000 bootloader. this will work. but only on the 0.90.0000 bl it will do s-off.

what would probably work is to flash the 0.90.0000 bootloader if we can write hboot. Then afterwards flash the rom_01.zip. But even therefore we need to know how to write to the radio.

So when we found out that, we can patch the hboot immediately to report s-off.

so no reason to first install 0.90.0000.

WAIT:

We could surely try this as a backup idea. We know that there's a configuration that makes S-OFF.

To be exact, the combination is:

HBOOT 0.90.0000

+ the rom_01.zip of the HTCDEV RUU Package for 2.13.401.2. It it not available anymore, but I kept a mirror of all RUUs for WFS :D

Because of the "special kind" of the hboot the phone is (hboot)S-OFF then.

We could not only avoid copyright infringement (since we do not modify any copyrighted stuff)

we could also stop investigating what to change in hboot > 0.90.0000 to make S-OFF.

the only disadvantage would be, we all needed to keep 0.90.0000 as bootloader. no fastboot functions. if we upgrade hboot, s-off would be gone. so this is not a so neat solution as patching newer hboots, especially the fastboot-enabled htcdev ones.
[HTC Wildfire S] :
Cool! I made a good suggestion!

Perhaps, a willing tester (me, perhaps) could downgrade to 0.90.0000 and curity do the ROM_01 flashing, then make a dump. Then we have a better idea about the secu-flag and all that. Then, somehow we can lock the memory addresses that make S-OFF, and bypass the HBOOT upgrade security checks, so they won't notice.

Also, is the memory arrangement the same in newer HBOOTS, only to have the extra features added at the end or something like that?

What's REALLY bad is that we have no fastboot functions afterwards! So, for now, let's call this plan B. We need to find a way to get fastboot and all the new trendy stuff on 0.90.0000 so it works nicely. Or we could "integrate" two HBOOTs together; although upgrading the HBOOT would be a DISASTER!!!

How far are we?