yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
Ok, the main thing the exploit would change on my Radio is it turns this ...

2b08b6c:	eb00c64e	bl	0x2b3a4ac
2b08b70:	e3500000	cmp	r0, #0

... into this ...

2b08b6c:	e3a00000	mov	r0, #0
2b08b70:	e8bd8010	pop	{r4, pc}

(Addresses are physical NAND addresses.)

So the patching itself is perfect, really no doubts about that. Only thing that might go wrong is the writing to NAND. So whenever we're sure that we can write to NAND, I'll run the exploit. I really do trust my code, I just don't trust the mtd drivers. :D
[HTC Wildfire S] theq86:
yes. the worst would be erase_image works and the writing fails :D
[HTC Wildfire S] no.human.being:
Yeah, think "erase_image" works and then we can't write anymore since the Radio is required for this (remember for the phone the Radio is a bit like the "BIOS" is for a PC).

Or we "erase_image" and the phone turns black. Obviously it won't boot without a Radio (Radio is what even loads HBOOT into memory, so HBOOT is actually pretty "high level software" compared to Radio :D ). Probably it won't even turn on, since Radio is what polls the "power on" button. (Not sure about that, but could actually be the case. :D )

Well it's all pretty unlikely, especially since the Radio is said to be completely loaded into RAM and never access the NAND again after HBOOT began executing. But nonetheless what we're doing here remains some sort of "brain surgery". :D
[HTC Wildfire S] theq86:
Unfortunately I can't just go to media markt and do all the exploits on a testing device :D
[HTC Wildfire S] rezo:
Unfortunately:
[HTC Wildfire S] theq86:
:(

is your phone still alive?
[HTC Wildfire S] no.human.being:
What did you do? "erase_image radio"? Wh00t .. you daredevil! :D
[HTC Wildfire S] rezo:
Yes, nothing bad happened.
[HTC Wildfire S] no.human.being:
Ok, so this most likely means that CWM kernel respects security, doesn't it?

I'll look into this later, but in this case I think we have no option but getting "vanilla" Linux running on the device.

So the device topic finally gets its meaning back. We need kernel devs here.
[HTC Wildfire S] theq86:
I also found out, that the mtdtools ignore "known bad blocks" which are manufacturer and device specific. If these information is in the compiled mtdutils binaries for wfs or generic for htc devices, probably not even a vanilla kernel would help.

I really don't think it is the kernel.

And i'm sure. it's mtdutils which refuse access, not ioctl.

And the bad blocks are not really bad. it's just a kind of "blacklist"

@rezo: Many Many thanks, you've got balls man!

---------- Post added at 05:00 AM ---------- Previous post was at 04:55 AM ----------

off_t mtd_erase_blocks(MtdWriteContext *ctx, int blocks)
{
// Zero-pad and write any pending data to get us to a block boundary
if (ctx->stored > 0) {
size_t zero = ctx->partition->erase_size - ctx->stored;
memset(ctx->buffer + ctx->stored, 0, zero);
if (write_block(ctx, ctx->buffer)) return -1;
ctx->stored = 0;
}

off_t pos = lseek(ctx->fd, 0, SEEK_CUR);
if ((off_t) pos == (off_t) -1) return pos;

const int total = (ctx->partition->size - pos) / ctx->partition->erase_size;
if (blocks < 0) blocks = total;
if (blocks > total) {
errno = ENOSPC;
return -1;
}

// Erase the specified number of blocks
while (blocks-- > 0) {
loff_t bpos = pos;
if (ioctl(ctx->fd, [B][COLOR=Red]MEMGETBADBLOCK[/COLOR][/B], &bpos) > 0) {
fprintf(stderr, "mtd: not erasing bad block at 0x%08lx\n", pos);
pos += ctx->partition->erase_size;
continue;[B][COLOR=SeaGreen] // Don't try to erase known factory-bad blocks.[/COLOR][/B]
}

struct erase_info_user erase_info;
erase_info.start = pos;
erase_info.length = ctx->partition->erase_size;
if (ioctl(ctx->fd, MEMERASE, &erase_info) < 0) {
fprintf(stderr, "mtd: erase failure at 0x%08lx\n", pos);
}
pos += ctx->partition->erase_size;
}

return pos;
}
[HTC Wildfire S] no.human.being:
I know they ignore "factory marked bad blocks". There's a bitflag in the out-of-band area of the NAND for each block which allows the manufacturer to mark some blocks as "bad". Usually this is used for marking blocks which are really broken (this happens when manufacturing memory) and making the operating system "avoid" them, so that the memory can still be used.

So we think HTC programs the NAND and then marks the Radio area "bad" in the OOB? But that would mean that reading from a "bad block" produces a meaningful value, after all the Radio can be loaded from the "bad blocks" and we can also read them through the mtd.

EDIT: Aaah, now I see it...

MEMUNLOCK Unlock flash to allow changes

You can supply a "MEMUNLOCK" command via ioctl. We probably need to run over the device calling this at every block first, then erase the device, right?

So we'll probably need to get into all this ioctl stuff ...

... or does it just mean we need to build the mtdutils from source, since the ones in CWM are somehow ... "crippled"?

EDIT 2: No, it's not the thing you marked in the source, it's the lower one.

if (ioctl(ctx->fd, MEMERASE, &erase_info) < 0) {
fprintf(stderr, "mtd: erase failure at 0x%08lx\n", pos);
}

It's this one that fails, since the message is "mtd: erase failure at ...", not "mtd: not erasing bad block at ...".
[HTC Wildfire S] theq86:
Yes, I think so, too.

But if we are in it once, it has the great advantage, that then we can really just write the bits we want to change.

---------- Post added at 05:10 AM ---------- Previous post was at 05:07 AM ----------

Well, we had to at least modify them in order to hack the block protection. but this would us also get invlved into the ioctl stuff. so why not build a minimal solution without the mtdtools overhead?

EDIT: you are right. but that cannot be real bad blocks... that's a crappy thing
[HTC Wildfire S] no.human.being:
Yeah, it's "locked" blocks (the second check), not "bad" blocks (the first check).

The utility does the following: It first checks whether a block is marked "bad". If it is, it does not even attempt to erase that block, but skips right ahead ("continue;"). When it is not, it attempts to erase the block (see the call to "ioctl(...)" with MEMERASE supplied) and then it checks the return value of that "ioctl(...)" for failure (since it's "if (ioctl(...))" so it "ioctl(...)"s first, then conditionally prints out the error message based on return value, but when that's printed the "ioctl(...)" has already occured).

So the "ioctl(...)" command really gets out, but "ioctl(...)" says "nope, that's not what I'm gonna do, since that block is locked and you shall not write there".

It would probably work if we'd "ioctl(...)" with UNLOCK first, then "ioctl(...)" with MEMERASE. The "UNLOCK" will reset the "locked" flag for the block and then the "MEMERASE" will succeed.
[HTC Wildfire S] theq86:
If that's right that would be a little effort. Just add that line, compile again.

... and probably find another one with balls :D
[HTC Wildfire S] no.human.being:
Sooner or later, I'll be the one with balls. Really want to get this done! :D

However, I'm gonna catch some sleep first before trying to build mtdutils from source. :D
[HTC Wildfire S] theq86:
so sometime within late summer 2012 :D

Okay, I'm going to bed now. Would have been too nice if it just worked :D
[HTC Wildfire S] MrTaco505:
Alright I got the balls tonight :D
[HTC Wildfire S] seaskyways:
What's wrong with "balls" ?? And what are the "balls" ???
[HTC Wildfire S] heavy_metal_man:
the balls

heh, its a phrase my friend, as in the testicals, balls :P its like saying who is tough enough, who has the balls ;) who is brave enough ect. nothing to do with the phone lmao XD
[HTC Wildfire S] humzaahmed155:
Although i have another phone (Nokia E5) Testing is a No-Go for me because my Digitiser has been completly destroyed and it wont respond to my touch anymore :(
[HTC Wildfire S] mobilescooby:
Dont know if this is any help to the Team

First of all i just wanna say i've been silently reading in the wings about the possibility of us finally getting S-OFF (which will be sodding awesome, Keep up the good work)

Right well i went out over the weekend and cutting a long story short my screen got cracked (meaning no touch input) so i went out and bought another WFS. What i'm basically saying is that i believe most of the stuff we are doing is via the command line so i dont believe the touch is actually that important....

If you want me to text any of the erasing/flashing that could (BRICK) the phone completely i'm willing to put it to use as i'm gonna be Mazumaing the old WFS anyway so it makes no difference to me....

I dont know if this is any use to you guys but i thought i'd just offer.....i cant provide kernel support but i dont mind doing some of the donkey work......

I'd much rather sacrifice my (broken) phone in the process then one of you guys loosing yours

Regards

Scoobs
[HTC Wildfire S] theq86:
That's great of you. Once we have the modified mtdutils compiled we shall come back to you. In fact for this procedure you will not need the touchscreen.
[HTC Wildfire S] mobilescooby:
Yea, just give us a shout when needed.... As i said i'd rather sacrifice the damaged one than some other person loosing there working phone!

That was a very expensive weekend out with the lads :(
[HTC Wildfire S] pihug12:
There's one thing I don't get. When we are at this stage :

What is preventing us from running a script like the one no.human.being wrote three months ago ?
[HTC Wildfire S] theq86:
@phiug12, I will explain.

1. This is no script, this is the source of an executable. Scripts are not compiled, but interpreted. Executables or commonly Applications are compiled and linked. Result is a native application.

2. The functions used in this source are High Level functions. HL functions call Low Level functions in order to achieve their goal. Opening a file seems trivial, but the deeper you go, the more complex it gets. You have to talk to the devices, open streams, delete and set bits and bytes etc. So an fopen issues several lower level commands to open a file or device.

We are stuck at the low level.So we also have to deal with the low level layer.

On that low level, the radio memory has been marked LOCKED. That also means, that we cannot bypass this lock with the help of high level functions.

We have to unlock this area before we can write on it.

@nhb:

Which toolchain to you use to create the arm binaries? I have the android NDK but there are so many tools. Is there a libstdc for arm?

I'd like to write my own patch tool to unlock the bootloader and lock it again (without leaving a trace that it ever has been unlocked :D, I found out how)
[HTC Wildfire S] m1ndh4x8r:
nbh already cracked s-off not so long ago through terminal emulator. I'm a m1ndh4x8r that's why I know. :D next project making custom roms.
[HTC Wildfire S] theq86:
that's totally rubbish mate ;)

We are still working on it. There has been no functional s-off exploit yet.
[HTC Wildfire S] seaskyways:
So what is the current status ??
[HTC Wildfire S] no.human.being:
Correct. I'm still S-ON. If there was a working exploit, I'd sure be the first to S-OFF. :D

The Android NDK has some "glitches" that might get in your way when doing system-level stuff. The toolchain I'm using is CodeSourcery from Mentor. It's based on the GNU Compiler Collection. However, it's a commercial toolchain. But as long as you're not using it for commercial purposes, you don't have to pay for it. However, you'll have to register with your full name and address.

There are several different "flavours" of this toolchain. The one we're needing is obviously under "ARM processors" and then the "GNU/Linux Release". This just means that it creates code for GNU/Linux (and Android is GNU/Linux, basically), so you'll need to select "GNU/Linux Release" at this stage even if you plan on building on a Windows machine.

Then you'll be taken to a registration form, that you're going to have to sign up. After registration, they will send you an e-mail which contains a download link. Then it asks you for the release you want to download, you take the topmost one (the one in the box which says "Recommended Release") and then you get the choice which architecture the compiler should run upon (select "GNU/Linux" or "Windows" here, depending in your operating system). There's an "installer" and a "TAR" version. I've downloaded the "TAR" as I don't want it do actually "install" anywhere, I just put it into some directory and then put the subdirectory "bin/" into my $PATH.

The toolchain is complete with e. g. "as", "gcc", "gdb", "ld", "objdump", etc. The tools are named "arm-none-linux-gnueabi-*" in order to differentiate the "cross-compilation" tools from your host's own toolchain. So you can put this into your $PATH and still use "gcc" when compiling for your host, while you'll need to use "arm-none-linux-gnueabi-gcc" when compiling for the embedded system.

I've found that the binaries that the toolchain produces "normally" are not executable on Android. I think Android doesn't have a "glibc". However, you can statically link against the "glibc" from Mentor by using the "--static" option at compile, so e. g. ...

arm-none-linux-gnueabi-gcc --static -o myexecutable mysource.c

Yes, overwriting a 4-byte value in "misc".

I'll dig into the "ioctl(...)" stuff now. :D
[HTC Wildfire S] :
I want a S2. My dad has one! and an S1.

---------- Post added at 05:57 PM ---------- Previous post was at 05:55 PM ----------

I might consider volunteering.

We haven't had some OT for the last like 60 pages!

Here's mine!

I've been working on my Java programming! I've written this:

import java.util.*;
import java.lang.*;

import java.util.Scanner;

class Main
{
public static void main (String[] args) throws java.lang.Exception
{
Scanner user_input = new Scanner( system.in );

String first_name;
system.out.print("Enter your first name: ");
first_name = input.next();

String surname;
system.out.print("Enter your surname: ");
surname = user_input.next();

String full_name;
full_name = first_name + " " + surname;
System.out.println("You are " + full_name);
}
}

Cool, eh!

I wish I could write an Android version of this!
[HTC Wildfire S] no.human.being:
I'm sure there's more than one S2 on the market, so I think we may as well both get one once that prices dropped due to the S3 release. :D

You'll need the Android SDK and you'll need to use a different API. Finally, you'll have to compile the resulting bytecode further into Android's own bytecode format with .. eerm .. "dex" I think was the name of the tool.
[HTC Wildfire S] :
OKAY! Enough with the balls. It's starting to sound perverted! If HTC are looking at this, they'll give us some clue's, only for it to be a porn app!

Soon someone's gonna say that they got so many balls, solar eclipses exist!!!!!

Blimey!

---------- Post added at 06:01 PM ---------- Previous post was at 05:59 PM ----------

My dad's super strict!!!! Not a chance ill get a S2.

---------- Post added at 06:03 PM ---------- Previous post was at 06:01 PM ----------

Can someone explain this to me more Bad-Wolf friendly! I don't understand. I understand the SDK bit, some of the bytecode bit, and that's pretty much it. I'll have a go, though, and if it works I'll say!
[HTC Wildfire S] no.human.being:
I haven't done Android development for Java yet, but I also think you'll have to create a GUI for your tool. I think under Android stdin and stdout channels are inaccessible from Java, so no chance to interact with the user through a terminal from within a Java program. Only native code (C) can do this.
[HTC Wildfire S] theq86:
@BadWolf:

go to developer.android.com

the Android SDK Documentation is REALLY good. Try to start with a HelloWorld example. Everything you need can be found there.

@nhb: thanks, it works. now I'll pack my patcher in an update script with AROMA installer and we will have a graphical BL unlocker without unlock token. :D
[HTC Wildfire S] no.human.being:
Lol, cool man.

Does it mean we can unlock without the token from HTCdev? Or does it just mean we can toggle between LOCKED/UNLOCKED after unlocking once via the token from HTCdev?

Btw, I've built "mtdutils" from source. However, I had to change a lot in the source, as (of course :D ) it didn't build in the form it was released. Now let's see whether these utilities work. They include the "flash_unlock" utility that's required for removing the "locked" marking from the protected memory pages.

EDIT: Of course they don't work. They require a standard Linux "glibc", to which Android's libc is not compatible. So forget "mtdutils", we gotta make it without them. Adjusting them to the other libc is ...... errm .. just forget about that, it's the absolute overkill. :D
[HTC Wildfire S] theq86:
so just ioctl stuff? :D

if it also unlocks without the token will have to be tested.
[HTC Wildfire S] no.human.being:
Either just ioctl() or the CM7.2 developers give us complete "mtdutils" sources for Android. Obviously they have source that is adjusted for the Android API, after all "some" utils are included in CM and CWM. It's just that "flash_unlock" is missing from them, but I think they could quite easily port that to Android as well, given that they already ported other utilities from the same set.
[HTC Wildfire S] no.human.being:
Does it work on your device? I don't think it will. I think you can't "fseek(...)" on an mtd device (mtds have to be programmed from sector 0 purely sequential, no random access allowed) and you should not write before erasing the partition, so the only option is as always...

- Dump the entire partition into a file

- Patch in the file

- Erase the partition

- Write everything back

... btw I might get mtdutils running on Android. I've found out some things that might make it work on Android when these are modified.
[HTC Wildfire S] theq86:
Yes, this is the way the tool works.

I don't fseek in the mtd. the gui dumps, patches, flashes.

and this works

---------- Post added at 08:44 PM ---------- Previous post was at 08:18 PM ----------

http://www.mediafire.com/file/s36vgr6vjh25rdh/bltool-signed.zip

here the update-zip with gui.
[HTC Wildfire S] pihug12:
It should work only with HBOOT 1.08.0099 or 1.09.0099, right ?

I'm already unlocked, but it sounds very interesting for the people who don't want to lose their warranty. Great job ! :D
[HTC Wildfire S] theq86:
right. if you have cwm and one of these hboots you can easily switch between locked(warranty mode), relocked and unlocked.
[HTC Wildfire S] no.human.being:
I don't think they even boot the phone into HBOOT. They'll just check against their database whether an unlock token has been issued for the device via HTCdev. It should be totally irrelevant whether the bootloader has actually been unlocked or not.

And you can run GUI applications under CWM? Interesting. Didn't even know CWM has the GUI libraries, since the actual recovery application itself only uses a text interface.
[HTC Wildfire S] XDA_h3n:
Just saw this thread again. Intresting... This would be how touch recovery be possible with GUI libs. Seems like htcdev has side effects, I'd wonder if the Sony bootloader unlock also removes/pays extra for warranty.

Sent from my Desire HD runing ICS, I like learning lua and C.

EDIT: I'm going to custom the framework-res to a custom skin, I'm looking forward to find out I've done my 3rd framework-res skin, or first skin for wfs. Also I'm going to be active on the wfs forums until they patch the camera bug on my ice DHD
[HTC Wildfire S] theq86:
the AROMA installer is an executable that has touch and framebuffer drivers. it is called by cwm. this is the way a UI is generated.
[HTC Wildfire S] seaskyways:
Man , you guys rule, it worked for me!! Nice touch input, now go up to the s off exploit guys, it shouldn't be so far!

SENT FROM XDA ETC .....
[HTC Wildfire S] theq86:
Wow, your conclusion is exactly the thought I had yesterday.

All areas that are not flashed by a RUU either are bad blocks.

The blocks where the radio parts are, are good blocks.

I didn't pursue this approach because nand_erase failed on all blocks.

But, yes. we could extrapolate the hboot offsets, thus having only the hboot. e.g. /dev/mtd0 hboot

we actually need nofurther partitions to load.

---------- Post added at 11:39 PM ---------- Previous post was at 11:15 PM ----------

HBOOT 1.09.0099 on the 54er Radio is 512k large

starting @0x02400000

ending @0x0247FFFF

size: 0x00080000
[HTC Wildfire S] no.human.being:
Ok, I just found out that HBOOT is not 256 KB. It actually goes from 0x02b00000 to 0x02b7ffff physical on my phone, so it's 512 KiB.

Mapping just HBOOT would be ...

... for RADIO-7.53.39.03M:

mtdparts=msm_nand:0x00080000@0x02b00000(hboot)

... for RADIO-7.54.39.28M:

mtdparts=msm_nand:0x00080000@0x02400000(hboot)

I'll adapt the exploit so that it doesn't expect the entire Radio to be mapped but just the HBOOT. Should actually slim it down a lot, so lots of code wasted at the moment that handles all the Radio-specific stuff and now we're disregarding the Radio completely. :D
[HTC Wildfire S] theq86:
matches exactly my calculations !

adb shell
~ # cat /proc/mtd
dev: size erasesize name
mtd0: 00080000 00020000 "hboot"
~ # mount /dev/block/mmcblk0p1 /sdcard
~ # dump_image hboot /sdcard/hboot
~ # exit

Original HBOOT from PG76IMGzip: 645ee7e5e1507c21ef6d047efefe467a

NAND Hboot extracted via hex editor from radio: 645ee7e5e1507c21ef6d047efefe467a

NAND hboot extracted from hboot mtd device: 645ee7e5e1507c21ef6d047efefe467a

confirmed right settings ;)
[HTC Wildfire S] no.human.being:
Perfect. I'm adjusting the exploit. Most of the code was designed to deal with the Radio, so probably there's not much left in the end. :D

EDIT: Remember the HBOOT is only 512 KiB. So no need to dump to SD card any more. Holding 512 KiB in RAM is no problem at all. Damn the new exploit gets small! :D
[HTC Wildfire S] theq86:
We should mount all standard partitions, too. I noticed cwm crashing when some partitions are not there. We should stick to our standard mapping and mtd7 will then be just hboot. crashing cwm would be a bad thing during flashing

edit: thread statistics :D

http://xdaforums.com/misc.php?do=whoposted&t=1374926
[HTC Wildfire S] no.human.being:
Ok, I've modified the exploit to work only on the HBOOT, instead of the complete Radio partition.

I've put the exploit (with custom mtdutils) onto the SD card and run it from there, of course working on an HBOOT dump on the SD, not on the real mtd. It seems to work perfectly and it's blazingly fast (of course, it only reads/writes 512 KiB).

I've also tested it in its "read-only mode" (where it does everything except erasure and writeback) on the actual mtd and it also successfully detected HBOOT and patched it in RAM (but did of course not write the patched image back, since I disabled that).

Now "someone" (yeah I know it's gonna be me! :D ) has to test it on a real phone. If it works, I'll provide a complete package for download, containing the exploit and mtdutils. Then you'll just extract this onto your SD, then boot into CWM via Fastboot with the right kernel parameters and run.

I can almost see the line "MARVEL PVT SHIP S-OFF RL" appearing on my screen. :D
[HTC Wildfire S] theq86:
rezo, you daredevil? here again tonight? :D
[HTC Wildfire S] mobilescooby:
I offered to be Guinea pig on any testing as I have a spare wfs but touch screen is gone! Apparently that shouldn't be problem!

Just let me know what I have to do

Hope I can assist
[HTC Wildfire S] theq86:
does your screen work? so the view part, not the touch part :D
[HTC Wildfire S] MrTaco505:
I'm willing to test, just hope it works :)
[HTC Wildfire S] gauravjuneja01:
Yes, I want to....

I am willing to test....

I am dying for S-OFF...

Bt i need to complete instructions.... coz i have not any experiences,,

Thank You.....

---------- Post added at 07:22 AM ---------- Previous post was at 07:19 AM ----------

Sounds extremely very nice... Very Nice Really...
[HTC Wildfire S] mobilescooby:
Yea screen is fine just the touch not working! As I said I'm mazumaing it anyway so I don't care if it bricks! Just gives us a safety net if anything goes wrong
[HTC Wildfire S] theq86:
Okay, we have 2 testers. We now have to wait fore no.human.being providing a package and detailed instructions how to test.

Before, please post your HBOOT and Radio versions