yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
My HBOOT is untouched. I'd say the kernel's mtd drivers pretend to be erasing and writing when in reality they're not. When I do it to an image file (say on the SD card) instead of the device file, it gets patched exactly as I'd expect, but the mtd is not touched.

It's a kernel problem. The exploit is doing it all right, but the kernel is cheating us. So we'll need a custom kernel. Either true Linux (would be the best) or Android built from source with the "security" restrictions removed.

And no it can't be mtdutils problem as if mtdutils didn't erase but kernel did write, the phone would be dead now. Writing to NAND without erasing first leaves nothing but total garbage in the memory. :D

So now I'd say we're definitely stuck at a kernel level problem and that's where most of my skills end.
[HTC Wildfire S] theq86:
That's poor :/

I'm not familiar with kernel development, either. it's a chapter on it's own

---------- Post added at 04:54 AM ---------- Previous post was at 04:52 AM ----------

Okay, for you guys a conclusion:

* None of your hboots got patched

* Nothing on your hboots was changed

* You are still S-On
[HTC Wildfire S] no.human.being:
But you come to the same conclusion right?

Dump the HBOOT to SD, then run "./inject --disengage-the-safety /sdcard/hboot.img" and it'll patch just fine.

What it does internally is fopen(..., "rb") the device, fread(...) it completely into a buffer in memory, fclose(...) the device again, analyze the buffer to make sure it's what we expect, then patch the buffer in memory, "flash_unlock ..." the device, "flash_erase ..." the device, then fopen(..., "wb") the device again and fwrite(...) the buffer back, then fflush(...) and fclose(...) the device.

So when it claims that everything went right (the calls didn't return failure values) then it'll say "[ OK ] Done!", otherwise it will throw some "[ERROR] ...". So obviously all the calls succeed, but the kernel just "pretends", and in reality does nothing.
[HTC Wildfire S] theq86:
well, do you think it could be the f* functions?

well no, forget it. If only the f* functions had failed the hboot would have been at least erased.

So yes, I come to the same conclusion. We can not write to this freaking mtd7.

A plain kernel may do it.
[HTC Wildfire S] gauravjuneja01:
So at all....

What for now?????

Kernel?????????//

Where from it come??????//////

I think that we have to wait........ for S-OFF....
[HTC Wildfire S] mobilescooby:
guys i'm led in bed trying to understand with my limited knowledge whats going on and thought i'd just tidy my laptop up and came across logs related to RUU.

doesnt the RUU temporarily turn S-OFF? couldnt we look at the logs and see what commands are issued?

probably a dumb idea but it's 4am and i probably should go sleep
[HTC Wildfire S] no.human.being:
Right. I think we could leave the exploit "untouched" (I'm actually very sure that it does the right thing) and stick a GNU/Linux system in and it'd probably do its job just fine. However, I couldn't get GNU/Linux working on the device. Do you think we could ask Alquez (I think he built the CM7.2 kernel right?) to build a modified kernel for us with the security removed from the mtd driver (which is where it would be most logical to implement this sh*t)?
[HTC Wildfire S] theq86:
No, a RUU never does S-OFF. A ruu sends it's rom.zip to the hboot which then reads the contents, checks the signature, flashes is the signatures match and gives return values about the status back to the RUU.

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

if it's in that driver we just have to find out how alquez built his kernel. A driver from kernel view is either a statically linked or a dynamically linked kernel module. So we just had to exchange this module with an untouched one.

edit: interesting resources:

you can seek, read write on NAND

http://www.linux-mtd.infradead.org/faq/nand.html#L_nand_srw

mtd driver sources:

http://www.linux-mtd.infradead.org/source.html
[HTC Wildfire S] mobilescooby:
Yep okay i should go bed then cos i'm just making stuff up now.

am having fun throwing random commands at this phone tho, in ruu download mode atm i think lol
[HTC Wildfire S] gauravjuneja01:
Yes.... Alquez can do it.....

and his xams are over.... also... i think...

Bye.. m going to college... 9.40 am here...

Bt i have tapatalk...
[HTC Wildfire S] no.human.being:
Ok I'll do a backup of my code and then I'll go to bed too.

Thank you guys so much for your testing. I think I'm gonna ask Alquez on this issue, especially what we'll need to build "his" kernel from source and where the mtd drivers reside. And perhaps if he already has a clue where this "quirk" could be implemented or perhaps he even has a "clean" kernel that already has it removed. :D
[HTC Wildfire S] mobilescooby:
Anytime, just sorry my phone wouldnt run the exploit
[HTC Wildfire S] theq86:
going to bed, too. there comes a time when it's 1:0 for us vs htc :D
[HTC Wildfire S] seaskyways:
Working exploit , No S-OFF

Guys , your expliot can "Do its thing" but , the hboot needs to be more patched cuz after executing the inject command , it worked , it got through ! but NO S-OFF , you are very close guys !! check my thing down :

EDIT : Thanks for the "inclusion" guys !!
[HTC Wildfire S] Lt.Win:
Oh yeah.

Wow, real close.

Little more patchy-patchy and we have our exploit! :D
[HTC Wildfire S] no.human.being:
No, I'm quite sure that the exploit patches the correct instructions in the HBOOT image. It's a kernel-level problem. The changes are probably correct, but they never really hit the NAND, the kernel just tells our exploit that it has written to NAND, while in reality it has not. The HBOOT is still original when you dump it from the NAND after the exploit has run. It's a kernel-level problem. We do "ioctl(...)" calls, the kernel says "yeah done it", while in reality it just discards the calls. The exploit is doing fine, but the kernel is "bad".
[HTC Wildfire S] seaskyways:
why won't you contact revolutionary about the update , i am sure they will participate since they have done a lot !!! And the thing is the kernel ? you have to build a special kernel for this operation ?? why can't we just flash hboot through hboot ? more like hboot detects PG76IMG's , can't you get it working from hboot to "think" this is a true thing ??

EDIT : I felt something was wrong , the thing just dashed to DONE ! Shouldn't it take at LEAST 10 seconds ?? cuz here it didn't ...
[HTC Wildfire S] no.human.being:
LOL@Revolutionary. These guys are acting like if they were the greatest hackers of all times, while in reality they're absolutely clueless. They've "tested" an exploit that was designed for the Desire S on the Wildfire S (which of course didn't work due to differences in the memory controller), then told us that our phones are crappy and they won't support.

It's the main thing that's currently preventing me from publishing the exploit source. I want to prevent Revolutionary from taking and expanding it and then claiming it's "theirs".

Not a "special" kernel, but a "vanilla" (unrestricted, built from the sources from kernel.org) one. I think the kernel in CWM is no "vanilla" Linux, but also an "Android" kernel (with custom Google and HTC code in it) and it's probably "designed" to ignore the ioctl(...) calls that our exploit does. They probably "knew" (or at least "could imagine") that such an exploit would be possible and then designed the kernel to "misbehave" intentionally.

We can't directly "inject" code into HBOOT. We can only run our code once an "operating system" is booted up. Currently this "operating system" is CWM recovery (with custom page tables that map the memory area in, where HBOOT's code resides, as this is normally "unmapped memory"). And our exploit is more or less an application process running on top of that operating system which performs changes in that memory.

Now the operating system (at least the kernel) is probably "bad". We ask it to do special I/O calls, it says that they succeed, and in reality it just discards them, probably knowing that this is an area we shall not perform changes in.

No it really is that fast, it just reads HBOOT from NAND, patches it, erases it, writes it back. HBOOT is incredibly small. It's only 512 KiB. (HBOOT's disassembly is actually LESS CODE than the exploit itself is, so HBOOT is extremely small, it's probably no more than 400 lines of code in C, given the exploit is only 530 lines and it's disassembly is larger.) It's literally takes no time to be read/patched/written on the ARM. It really is that fast. We've tested it on an HBOOT image (instead of the true mtd) where it is equally fast and the image is patched correctly.
[HTC Wildfire S] seaskyways:
Then good luck with your "cake" kernel :p :D i am a tester here , and for sure try to port roms with failure :p

---------- Post added at 06:02 PM ---------- Previous post was at 05:29 PM ----------

Guys , revolutionary did a quite nice job , so why can't you take a look at the kernels they used , they surely have ones ! I am sure it may help , unless you are building your own vanilla kernel , then do what you have to do !;)
[HTC Wildfire S] no.human.being:
I've contacted Alquez on the issue, told him what we're trying to do, how far we've come, why we need his contribution and asked him whether he could either ...

- ... provide us CWM kernel sources, instructions how to build them and point us at the mtd driver sources (since we think that's where the restrictions reside).

- ... provide us with instructions on how to build a "vanilla" Linux kernel that runs on the device (since that obviously won't be restricted).

- ... remove the restrictions from the CWM kernel's mtd drivers and build a custom CWM recovery image for us which has the restrictions removed. (This would obviously be our preferred method. :D )

---------- Post added at 05:06 PM ---------- Previous post was at 05:04 PM ----------

Revolutionary are selfish! They require you to request a key for each unlock process, so obviously they plan on going commercial at some point, otherwise they wouldn't do such a thing. And obviously they won't publish any sources for this reason. :rolleyes:
[HTC Wildfire S] seaskyways:
I guess that is what will Alquez do , because that is what he is good at !

---------- Post added at 06:09 PM ---------- Previous post was at 06:06 PM ----------

i know i know , but finally we need our s-off ! if we used there stuff at ours , then surely we can show they are stupid that

THEY

used their tools and got nothing , while

WE

use their tools and accomplish a big thing !
[HTC Wildfire S] no.human.being:
Yeah but they don't release any sources, so we'd have to "reverse engineer" their utility, which...

... 1st I don't want to do, since that would be a copyright infringement.

... 2nd I don't know we even can do, since they probably obfuscated the code like hell.
[HTC Wildfire S] seaskyways:
Get it !

Then we got no other options than the ones have Alquez and Alquez will be the "Active Ingredient" right now ?
[HTC Wildfire S] theq86:
Got the sources for the mtd drivers.

http://git.infradead.org/mtd-2.6.git/tags

btw:

revolutionary claims that:

* it's closed source only to prevent htc to fix the vulnerability

* their final releases will not need beta keys.
[HTC Wildfire S] no.human.being:
Ok, then they're doing something different than what we do. How will HTC "fix" the "vulnerability" of a custom kernel (= system level code running in supervisor mode) writing to HBOOT area? :D

It's not a vulnerability. As long as you're having "physical access" to a system you can overcome any "security" (if you have physical access you can also JTAG the system, it's just that you need more sophisticated equipment for the latter :D ).

And as long as you don't have "physical access", the "vulnerability" is not critical since you can't "remotely Fastboot" a custom kernel on the device.

So it's not a vulnerability and they won't do anything about it. Only thing they could do is remove support for the Fastboot protocol, but that would prevent almost all development work on their handsets. If they did this, they'd lose all their developers and if there's no development for their handset going on, they're going to lose all their customers. It's just a total no-go. Never ever will they do that. :D
[HTC Wildfire S] theq86:
Well, I also think rev. does not bother with mtd drivers and tools. they found out something different which was not portable to us.

I checked out alquez github where htc kernel source is. gonna look at the mtd drivers source and maybe I can find out how security is implemented or at leas where.
[HTC Wildfire S] no.human.being:
Sure I'm gonna take a look at this as well.
[HTC Wildfire S] theq86:
would need a whole dev team and weeks to get into it in detail :D
[HTC Wildfire S] seaskyways:
What is the prognosis ??

---------- Post added at 08:07 PM ---------- Previous post was at 08:05 PM ----------

would you please upload a image of the patched manually 1.09.0099 hboot ? i wanna see it please :D
[HTC Wildfire S] no.human.being:
I'm not doing anything "manually". I've written a software (namely the exploit) that automates the patching.

No need to upload patched images. Just do the same as you did while running the exploit (so boot CWM recovery via Fastboot with the same parameters and mount SD card).

Then you do ...

~# cat /dev/mtd7 > /sdcard/hboot-original.img

This will image your HBOOT as is on NAND to the SD card. Then you create a copy of that.

~# cp /sdcard/hboot-original.img /sdcard/hboot.img

Then you "cd" onto the SD card.

~# cd /sdcard
/sdcard #

Then you let the exploit patch the image on the SD card.

./inject --disengage-the-safety /sdcard/hboot.img

This will patch the "hboot.img" file on the SD card while of course the "hboot-original.img" remains untouched.
[HTC Wildfire S] theq86:
try at HTC. "Hey, I cracked your lousy bootloader. I can make it better, employ me" :D
[HTC Wildfire S] m1ndh4x8r:
I can feel you could do this to bf35da7552624b63413eb7a1f3909fdf on S-off phones. cause Im a m1ndh4x8r.
[HTC Wildfire S] mobilescooby:
Okay I have an idea its probably rubbish but hear me out ill sit quietly in corner again!

We can dump hboot - correct?

We can patch hboot on sd-card -correct?

During the ruu update to unlock the bootloader we had to update the hboot - know that one is right lol

Can we not get fastboot to flash the modded hboot whilst in ruu mode! Cos I know how to get into that mode!

Or is this in principle what the injection exploit is trying to achieve! Excuse my ingorance I am unfortunately a winblows chap and trying to think outside the box!

Probably a pile of cack! Just tell me to shush and I will

Regards
[HTC Wildfire S] no.human.being:
No we're overwriting the HBOOT while an operating system is booted. We just map the HBOOT area as a partition ("/dev/mtd7"), then we dump what's inside, modify it a bit, erase its contents, write it back. The "modified" version is designed to return "S-OFF" as secu_flag status no matter what the Radio says. That's basically all.
[HTC Wildfire S] seaskyways:
seems interesting ... i will try what you said !

---------- Post added at 09:33 PM ---------- Previous post was at 09:06 PM ----------

This is me trying to flash the cracked bootloader via fastboot ... :

Another try :
[HTC Wildfire S] BeciMester:
Erm... The last fella who tried that (hacked into the Marriott Hotel chain's system, then contacted the hotel and asked for a job) got 30 months in prison. :D Serves him right - WTF was he thinking?? :eek:
[HTC Wildfire S] *se-nsei.:
There's so many different posts, I may as well just leave the OP as it is as I'd have to keep changing it. Just continue with what you're doing people ;)
[HTC Wildfire S] seaskyways:
You gotta change your first post to something up-to-date MAN !
[HTC Wildfire S] no.human.being:
Lol, this is an entirely different case. He has broken into a foreign system (that alone is a criminal act, like breaking into someone's house is a criminal act, even if you don't steal anything), has subsequently stolen sensitive information and then threatened to publish it. So it's at least three laws that he's broken. (And it's been an extremely silly action I must say. :D )

On the other hand, we're providing an exploit to perform modifications to the firmware of a device that is one's own personal property. Some US court (and they've got quite "strange" views with regards to intellectual property) has decided that jailbreaking the iPhone to overcome the restrictions that Apple imposed on the phones is legal, so I don't see why we'd be doing anything illegal here. Greatest concern would be copyright, but as we do not ship a significant amount of HTC code with our exploit, I'd expect it to be ok. It's just "mtdutils" (which are GPLed) and the exploit itself, which is an entirely clean-room implementation. The only HTC stuff that it contains are a few "signatures" that HTC put into the bootloader and 3 (!!) machine instructions from the "original" HBOOT images per supported HBOOT version (for a total of 6 (!!) machine instructions now, since we support HBOOT-1.08.0099 as well as 1.09.0099) to make sure that the code we patch is currently unmodified.

We really did care not to infringe copyright, as that's absolutely not our intention. Our goal is not to harm HTC or Google or anyone else, we just want to make sure people can use their own property for whatever they want.
[HTC Wildfire S] BeciMester:
To the best of my knowledge they didn't even go after Alpharev who host hacked hboot's on their site. Seeing that your program modifies the user's own hboot and doesn't contain proprietary code, I think we're in the clear. :) 3 machine instructions in a particular order are hardly a representative of a copyrighted work.

Edit: the only thing one might be concerned about is the reverse-engineering part...
[HTC Wildfire S] MrTaco505:
Why not look on how the CDMA version of the wfs was cracked s-off. Isn't the GSM and CDMA basically the same radio and hboot?
[HTC Wildfire S] theq86:
the cdma wfs has no sim slot as far as I'm concerned. this is the reason why it does not look after an eng sim. however, gsm wfs has a sim slot. and we can not just change it ;)
[HTC Wildfire S] XDA_h3n:
I have a feeling HTC are looking at this, and keep on updating the bootloader unlock hboot with the version with same number..

Or some type of dirty hboot...
[HTC Wildfire S] m1ndh4x8r:
I know early this march is the releasing date by no.human.being.

Everybody be prepared. :D

Features are

able to S-OFF

able to re S-ON

Thanks so much great h4x0r, but I am already S-OFF so can't use your exploit, also I don't like to S-ON my phone again

Congrats. S-ON users will be happy with this.
[HTC Wildfire S] Lt.Win:
Okay I tried the exploit but this comes up:

*************************
* Cold opcode injection *
*************************

An S-OFF exploit for HBOOT: 1.08.0099, 1.09.0099

(C) 2012 no.human.being

Project coordination, Fastboot and Radio analysis, exploit development and boot
image integration.

Thanks to the all the contributors from xda-developers, especially ...
... *se-nsei. for initiating the quest and keeping the community informed.
... heavy_metal_man for the '/system' dumps.
... seaskyways, MrTaco505, mstfkaratas and pihug12 for the Radio image.
... theq86 for the mtd tools analysis and Radio image.
... BeciMester for the HBOOT analysis and Radio image.

Other contributors and fellows from xda: d33ps1x, Bad-Wolf, benjamingwynn

Thanks to Cyanogen, Alquez and Drowningchild for their work on the kernel.

Thanks to the bands Kampfar (Fredrikstad, Norway) and Trivium (Orlando, Florida)
for their inspiring music!

[ LOG ] Step 1: Reading from mtd ...
[ LOG ] Step 2: HBOOT analysis ...
[ LOG ] Incorrect base signature for HBOOT-1.08.0099
[ LOG ] Incorrect base signature for HBOOT-1.09.0099

[ERROR] Failed to detect HBOOT!

I followed all the steps and my phone is in CWM mode. it got something like E:Bad Boot message "1".

Whats the problem?
[HTC Wildfire S] heavy_metal_man:
not really relevant but yay for me :D never been thanked in a hacking program before :P

ok noob moment over :P
[HTC Wildfire S] no.human.being:
At least under the legislation of my country, reverse-engineering is definitely not an illegal act.

The implementation is protected under copyright law, the method may only be protected by patents (however, no patents for software-only solutions according to EU law).

And EULAs (that might contain statements prohibiting reverse-engineering) are not considered legally binding contracts, since the customer doesn't have to accept it prior to purchase, but only after and then the contract has already been concluded and that one obviously didn't include the EULA.

I'm absolutely certain what I'm doing here. I'm close to completing my studies of computer science and before beginning my studies I've worked as a developer. If unlocking phones were illegal, then all the phone shops offering commercial unlocking services would be doing illegal things. And if reverse-engineering were illegal, then NTFS-3g (file system reverse engineered), LibreOffice (Microsoft Office formats reverse engineered) and lots of other software would be illegal.

---------- Post added at 12:14 PM ---------- Previous post was at 11:56 AM ----------

You probably have the partition mapping wrong. Every HBOOT image we've seen so far begins with the 32 bit word 0x120000ea (when read as "big endian"). That is what I'm calling the "base signature". The mtd device (or image file) you specified didn't begin with this word.
[HTC Wildfire S] theq86:
However, there seem to be exceptions as we have seen in the testings before.

Some people have a HBOOT version looking totally different from the "normal" hboots. These - from me so called "garbage" hboots - do indeed work, but are not detectable by the exploit yet.

I do not know why these exotic hboots exist and what the reason is they look so.
[HTC Wildfire S] BeciMester:
Did I mention that those 4 bytes form an instruction? :o It's a jump (B) to 0x9d000050, where the initialization begins.
[HTC Wildfire S] Lt.Win:
So what do I do? I am so NOT into this stuff lol. Tbh, I didn't understand anything you said. :P

Sent from my HTC Wildfire S powered by .sense
[HTC Wildfire S] seaskyways:
shut up !

Man , may you stop posting "future" stuff , cuz nhb is here and he can tell us for any updates , release dates , details blah blah blah... and nobody really needs any help from a talker ... If you could build kernels then help ! Otherwise , talk normally , and stop making such comments ... No offence and am sorry for any of it ...
[HTC Wildfire S] no.human.being:
Then you know more than me. I only know that release date is not before we get an "unrestricted" kernel running.

Well, obviously.

Well, indirectly. Like with Revolutionary just flash a stock HBOOT image to get S-ON again. :D

Not so sure that's what I am. :D
[HTC Wildfire S] *se-nsei.:
I have no idea what's going on, but seems great. NHB or soemone else please link me to a post(s) I can display on OP. Very busy lately, keep it up though. :)
[HTC Wildfire S] mhrsolanki2020:
request

hey OP make a new thread and close this. in new thread mention the progress..

a new person wont be able to recognise the progess you are making.. and neither can me.. can you tell me if your tries are getting to ny sucesss?