yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
I could imagine that one can access the ROM directly from within Android after you have gained sufficient permissions. If this is possible, we just have to find the exact location of the flag and overwrite this ROM address from within our privileged process.

The "/dev/block/mtdblock*" devices inside Android seem to be ROM-related. One might be able to access the device security through one of these. Must be possible to set this flag somehow from within Android, as this seems to be the way Revolutionary is doing it on almost any HTC phone (but not on the WFS, as the exploit is probably CPU-dependant or probably rather dependant on CPU-specific differences inside the stock Android kernel and they aren't willing to support the MSM7227 processor that powers our phones).

First step however will be locating the flag, setting it via JTAG (see this thread), verifying device is S-OFF. Next we need to find a way to obtain temproot on the device, as we will never be able to access the device security flag without root access. Preferably, we will achieve this without relying on proprietary code (this could be difficult). Last step is finding a way to write the security bit from a privileged process and packaging it all together into a hopefully user-friendly package. All steps may turn out to be complicated, but my first guess would be that the first one is the hardest (I have specialized on IT security and penetration testing, but I am probably not that good at performing all this low level stuff :D ).
[HTC Wildfire S] ONeill123:
The script for temproot i using is very simple ;)

It uses the zergRush exploit to get root acces, but before restarting as rout the batch file remount the system partition an a restart is cancelled.

The zip file with all files are here in forum i think:

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

there u find the sequence of commands the batch will go. Unhappily i don't know, how to create a script, that sets the secruity flag to off :(
[HTC Wildfire S] :
Today, I've let s-offed my wfs with xtc clip. I can say, the clip is connected all time to pc so it needs internet (xtc clip servers). Furthermore there are a lot of screens with 6 checksums and other stuff.

But now I'm happy, I can take screenshots without need for pc etc.
[HTC Wildfire S] no.human.being:
I will be away from tomorrow till sunday. I'll check the ZergRush exploit again when I'm back. I've already discovered the associated C-code within some git (if I remember correctly) repository some days ago. However, I couldn't get it to compile, since a lot of headers/libraries seemed to be missing.

If we really have a version of the exploit that runs on our phones (and it seems we have, considering what ONeill123 was saying), the second method sould be easy to achieve from within a privileged debug console and it could also be the base for the first (and preferred) method I mentioned.

Like I said, check back some days after the coming weekend. I'll try to get access to a JTAG debugger afterwards. JTAG can write to ANY ROM address and it does the access without the device being booted, so security systems don't have any chance to intervene. When we manage to find the exact location of the device security flag, I'll reset it using JTAG and verify that the device is S-OFF afterwards. We will move on from there. Don't try to get it all done in one attempt. This seems to be a complex procedure. Let's break the problem down into as many small, isolated steps as possible and solve them one after the other.

If this is true, then method 5 is definitely out (not that I really considered doing it anyways :D ).
[HTC Wildfire S] infected85:
Screw their copyrights bro. Doing step 4 is the same as using the zergrush exploit. They gave up on us saying we have ****ty phones...
[HTC Wildfire S] *se-nsei.:
You're happy with S-OFF now, mainly because you can take screenshots more easily now?

LOL

@no.human.being

I think the first two options sound the most clear and promising. I don't think number 4 would be too much of an infringement, especially because we have found a way to use the zergRUSH exploit, but not so sure.

Go for the first or second options. :)
[HTC Wildfire S] :
That's only one example. Of course I'm going to install CM7 and customize things.

I've already installed a custom rom and installed screenshot from market.

Just shake to take a screenshot, super easy :D
[HTC Wildfire S] *se-nsei.:
I know I'm only joking. :p

GOOD NEWS ! We have moved back to the main XDA forum !!

I can sense a little glimmer of light at the end of a very long, bumpy, and dark tunnel.
[HTC Wildfire S] No.12:
We are there for some time,you are not following closely. ;)
[HTC Wildfire S] *se-nsei.:
eheh, I'm a busy guy!
[HTC Wildfire S] ONeill123:
Puh, that was time, that this better phone go up in xda hirachie :D

I hope, that we find more devs, that we find fast a way to software unlock our good phones :D

They are cheap, but better then the unlocked wildfire :D
[HTC Wildfire S] MindBurn010:
Very nice but we cannot do 2nd way - I have tried already and others did but no one managed to get System RW, I thing S-On is some kind of locking the system and it is located on other partition or part of the memory... BTW sensei is right and zergrush is working for temproot the WFS - already checked by several persons + me, I have succesfully gained root access but couldnt write to system

Where did you get the JTAG, can you post or send me the el. schemas or something ? (I am super busy and for the comming 3-4 weeks I wont be able to search the internet and try lots of ways to do it, so i am sorry that I am asking you to give info to me without searching it but...)

Thanks in advance
[HTC Wildfire S] imlgl:
That is untrue, I xtc clipped my WFS by using a 9v battery instead of it being connected to the pc. So how would it be able to check the servers etc?
[HTC Wildfire S] ONeill123:
It doesn't check the servers, how? This is only a electrical built. No operating system or something else which can sent data through the cable to pc in the internet.

The cable is only for the power supply if u don't have a 9v battery ;)
[HTC Wildfire S] :
Ok to make things clear, on mine it was a xtc pay and go clip.

A special one without battery supply.

BTW: if contacts aren't good placed on simcard, device is still s-on. We have done it a second time, first time it was still s-on.
[HTC Wildfire S] BeciMester:
ROM:9D008B68 STMFD SP!, {R4,LR} // push registers
ROM:9D008B6C BL sub_9D03A4AC // call sub
ROM:9D008B70 CMP R0, #0 // is R0==0 ?
ROM:9D008B74 MOVNE R0, #1 // if not, load #1 into R0...
ROM:9D008B78 LDMNEFD SP!, {R4,PC} // ...and return (pop registers)
ROM:9D008B7C BL sub_9D007B34 // if R0 was 0, call sub
ROM:9D008B80 MOV R0, R0,LSR#5 // bitwise shift R0 to the right 5 times (*)
ROM:9D008B84 AND R0, R0, #1 // keep the last bit
ROM:9D008B88 LDMFD SP!, {R4,PC} // ...and return (pop registers)

That's it. That's the 'mother'. I'm 100% positive we've got it. I'll post further proof in a minute.

(*) This is actually interesting. It shifts the register to the right 5 times so bin 00100000 will become 00000001. Now look what you've posted a while back:

0x30 = bin 00110000

0x10 = bin 00010000 ...

and the strings with the numbers from above "30" and "10"...

...strange coincidence? :confused:
[HTC Wildfire S] no.human.being:
mtraco505 is also S-ON. It was mstfkaratas' image that was S-OFF. I just did a comparison of no.human.being vs mrtaco505 since I wanted to know all the differences that are certainly not secu_flag related. :D

EDIT Aaah, the "LDMFD" returns. Ok, I didn't know that instruction at all. I was just looking for "bx lr". :D
[HTC Wildfire S] theq86:
Sounds good

Yes, push me, hit me, give me bad names :D

I did not try dd yet, but I will go on working on a method to write your image

if dd works, yes. doing it via /dev/mtd/mtd7 and nandwrite is too dangerous in my opinion.

makes sense and is noob friendlier. :D

then htc would laugh et us at last :( :D
[HTC Wildfire S] BeciMester:
I know. It's probably just a coincidence. But an odd one nonetheless. :o And remember, it's just the second check, after the first one passed.

Edit: what does mstfkaratas' image have there?
[HTC Wildfire S] no.human.being:
Yep. Stupid idiots spending months searching for something in the NAND that ain't in the NAND at all. :D

They're probably reading this thread and laughing like crazy. Well, at least we could build an IMEI-changing app now, lol. Wreaking havoc with the mobile networks. :D
[HTC Wildfire S] theq86:
Super IMEI 11111111111111 :D

hey, we could earn a lot of money. wfs would be the new drug dealer's phone.

f***ck

~ # dd if=/dev/mtd/mtd5 of=/sdcard/datadump.img bs=2k
76800+0 records in
76800+0 records out
157286400 bytes (150.0MB) copied, 35.383454 seconds, 4.2MB/s

~ # erase_image userdata
~ # dd if=/sdcard/datadump.img of=/dev/mtd/mtd5 bs=2k
76800+0 records in
76800+0 records out
157286400 bytes (150.0MB) copied, 29.774475 seconds, 5.0MB/s

that worked, but ...

again, the partition was not correctly restored. -.-
[HTC Wildfire S] no.human.being:
So the kernel has bad mtd drivers?

Btw, I found out something interesting. Revolutionary is a "merge" of the developer teams from AlphaRev and Unrevoked right?

Now see what AlphaRev claims about the secu_flag in the Radio ...

Now see what Unrevoked claims about the secu_flag in the Radio ...

?!?! :eek:
[HTC Wildfire S] theq86:
actually not. look.

md5sum /dev/mtd/mtd5 && md5sum /sdcard/datadump.img
fc6980bca09d768903d387b270989596 /dev/mtd/mtd5
fc6980bca09d768903d387b270989596 /sdcard/datadump.img

what irritates me is, that when I boot again the phone behaves as if a factory reset was done.

I tried dd'ing boot partition to sd and back. that worked. let me do some tests. somehow it MUST work and I gotta find out :D (I hope :D)

Yes, I know.

We have 2 things that make sense:

1st. alpharev first did not find it, we haven't found it yet.

2nd. desire S is easy to crack and we still have no 1-phone-dump
[HTC Wildfire S] no.human.being:
Yep, but Unrevoked have found it. Now if Revolutionary is a collaboration between AlphaRev and Unrevoked, why did they "fallback" to the (inferior?) "patching HBOOT" method when Unrevoked already knew how to patch the Radio?

EDIT: Aaah ...

Ok makes sense. So they've probably found it on some devices and on others they have not. And our WFS was even so hardcore that they gave up straight. :D
[HTC Wildfire S] theq86:
did they fall back? but I don't think they're very active either.

gonna dd system image now. then get it back and see if it worked out. that nand makes me headache. especially knowing that cwm seems to use the tools right. but it does nothing different than me. :D

---------- Post added at 05:20 AM ---------- Previous post was at 05:16 AM ----------

No, doesn't work, too...
[HTC Wildfire S] no.human.being:
This is the nandroid source. Don't know if that helps.

I'll go to bed now. Gonna go hard on the HBOOT patching stuff after getting some sleep. :D
[HTC Wildfire S] theq86:
thx, I'll have a read.
[HTC Wildfire S] theq86:
Ooookay friends,

As long as we flash the whole radio we should get no problem.

# Get the radio image
dd if=/dev/mtd/mtd7 of=/sdcard/radio.img bs=2k

# Now it depends on how "smart" the mtdtools are. Normally you can
# dump any partition with dump_image <file>. But in case of the radio
# we will get ECC and read errors. However, dd just does it fine.
# But now we must erase the radio with erase_image <partition>
# And there's the big question. Does erase_image work on radio?
# And if not, does writing a bunch of 00 (in the size of the radio)
# is the same as deleting the blocks? So hoping erase_image works
# this will erase the radio image
erase_image radio

# Now we must write back the exploited radio. Again there would be
# a tool called flash_image, which would also do the erasing for us.
# But if dump_image does not work, flash_image would probably neither.
# So, we have to dd it back again.
dd if=/sdcard/radio_exploited.img of=/dev/mtd/mtd7 bs=2k

# That's it. If flashing goes well, and if the hboot exploit is correct then
# the phone will boot. otherwise ... :D
[HTC Wildfire S] a.s.j:
Hey, guys, didn't someone stated few days ago, that dd is not the tool to use? :D

Anyway... I know, that the hw differs, but I was trying to point out what I've done to my Vision just as one of the possibilities and now you are tying just that ;)

BTW: they are using some more tools to get access, temproot, map and mount the image rw, dd pathed HBOOT or whatever was needed etc...

Maybe it is not that bad idea at all to check how others did what we want to achieve here, because then for example we would be able to do it in adb and temproot (zergs work afaik) as I did even with locked HBOOT...

I am just thinking, I am more of a manager last days then real developer, so I am using my brain in different ways ;)

So only 2 cents from me... I am really happy for your progress...
[HTC Wildfire S] theq86:
Okay guys. here some VERY IMPORTANT piece of information.

Under all circumstances we have to !!!erase!!! the radio partition before writing to it.

I was so stupid and tried what happens if we do NOT do. I wrote a misc.img back without erasing is before. I should have done it with /boot because this is easy to recover.

I ended up with an almost bricked phone

* No USB anymore

* Phone only boots if cable is attached, otherwise bootloops (took me hours to find out -.-)

* I was BL locked again (and funny, I was LOCKED, but not RELOCKED, so the information about that IS in the misc partition)

* SD Card was not working anymore

* No Adb possible

The last 5 hours I spent reading and finding a solution ...

I'm still sitting here trying to fix my phone somehow.

I'm confident I can fully recover my phone (hopefully)

but if that would happen to anyone's radio ... DEATH !

EDIT: I was successful.

So, what have I done?

At first it seemed to be a hard brick. The phone did not boot any kernel. It just rebooted. And I was on a locked bootloader. I managed to install a RUU. My luck was, that it installed, because the phone's software version constisted of whitespaces. So I installed it, unplugged the cable and my hopes were destroyed :D (I hoped the RUU would recover the misc partition, but it does not.)

So I hung in Bootloops. Then I installed the htcdev hboot again and unlocked my phone. I flashed cwm recovery.

So I wanted to go to recovery. Haha, bootloop ...

Well, a couple of time later I had my cable attached to the device. Then it booted up. yeaaaaaah I thought. Until I noticed it would reboot again when I pull the cable ... oh crap.

Next thing: the SDCard was not recognized, the usb connections did not work (no drive mode, no adb) and I was on an unrooted system again.

Ok I thought. Download zergRush, flash misc, etc. But how to put the files to the phone? The phone's browser would only let download on a sd. Great !

So I tried to boot my recovery again (this time with plugged cable !) woaaaaaaaaaah it booted :D

But still ... no adb ... no sdcard ... Hell i was pissed :D

Then I found out I got into something called USB brick. I was lucky, there was a command that enables at least the sdcard again

[COLOR=Black]fastboot oem enableqxdm 0

Then I could do my nandroid backup and were on my rooted rom (still with cable attached :D)

And in the end I could flash my misc partition again, which I had a backup of.

Got no sleep, but repaired my phone.

[/COLOR]
[HTC Wildfire S] ONeill123:
So this information is good as well. So we can lock our BL like it is before we have unlocked?
[HTC Wildfire S] theq86:
Seems so. But my misc partition was so messed up, I could not even make a comparison and find out which bit or byte indicates the status.

And I will not mess up my misc again just to find out :D
[HTC Wildfire S] heavy_metal_man:
Well done man, at least it wasn't totalled :p also, back to what you were saying about the xtc clip file, would that actually work? Sort of make the boot think it was s-off so it would run any file then edit the xtc file to think the flex cable was always there to force it to run?

sent from my ice cream sandwich powered HTC WILDFIRE B-)
[HTC Wildfire S] theq86:
Well, making hboot think it's s-off is our current goal. the hboot has a function that is always called when someone wants to know the secu state. if we make that function always reporting s-off then we have basically s-off.

so I think it could be possible to tell the diag that the eng sim is present. but therefor we would have to know how exactly the diag is testing it. that's just theory for now.
[HTC Wildfire S] heavy_metal_man:
im willing to have a look, just to keep our options open ;) also how did you guys find out how the partitions are mapped?
[HTC Wildfire S] seaskyways:
Finalllyy !! somebody gets more like my USB brick ! I am partially USB bricked too ! if you ever have full functionality again please tell me how , i am dieing to know how !!!!!

---------- Post added at 01:59 PM ---------- Previous post was at 01:54 PM ----------

Yup , if you try flashing a new misc it will instantly lock your bootloader , not relock it , you will just find ***LOCKED*** ...

It is said that if you are s-off you can type in

fastboot oem eraseconfig

would fix your misc partition , well i am willing to try it just after you guys finish the s-off thing !
[HTC Wildfire S] rezo:
Good work guys. I also try to gain o-ff. I'm focused on misc partition. IMHO somehow it is important to achieve our goal.

My observation:

1. Dumped radio is really weird. It contains too small amount of data! Radios in the official RUUs are full of data and our dumps are almost empty.

2. If you want ***LOCKED*** you must just change HTCU or HTCL to anything different, ex. AAAA or better erase it (00 00 00 00).

3. You can dump partitions by using nanddump. You can see a lot of oob data then.

4. Can anybody tell me how to write mtd7 without errors? Idea is to modify hboot inside radio dump to dirty 0.900000. Then flash radio from rom_01.zip. If it is true what people say then the phone should be s-off. Then it would be easy to find secu_flag.
[HTC Wildfire S] BeciMester:
If we knew that we'd have published our stuff by now. :) theq86 is hard at work on the issue.

(I'm on my phone...)
[HTC Wildfire S] no.human.being:
No it is not, for two reasons.

1. Erasing NAND will turn all bits "on" (that's why there's so much "ff ff ff ..." on the partitions, the memory has never been written there) and "writing" (aka "programming") can only turn 1's to 0's. In fact on simple NANDs that don't have ECC, you can e. g. "program" the value 0x2b over a byte that's currently 0x3f without erasing, since you're only turning ones to zeros, but not the other way round. On "our" NAND this won't work since this has ECC in an OOB area and we'll never know how these ECC bits change (is hardware-specific), so we better always erase before writing.

2. "Some" memories (but these are really high-end ones with high capicity, throughput, reliability, ...) turn their blocks "tristate" ("neither 1 nor 0") when erasing them. "Usually" these will "settle down" to 0, but there's no guarantee, so if we really "want" them to be 0, you explicitely have to overwrite them with 0 again after erasing, otherwise you might find that the "tristate" (which "reads like 0" most of the time) begins "floating around" and "changing".

Number 2 is definitely not the case for some "cheap embedded NAND", but either way for "solid state" (semiconductor) memory, "erasing" is definitely not the same as "writing". No matter what value you "write", it'll definitely have a different effect on the memory as "erasing", that's why there are distinct API calls for erasure.
[HTC Wildfire S] BeciMester:
Would the Qualcomm tools be any help?

http://forum.ppcgeeks.com/windows-mobile-software/46873-updated-06-14-2011-qpst-qxdm.html <-- end of first post, QPST 2.7.366 seems to be the recommended minimum version

User manual: http://sxg.spssoftware.cz/80-v1400-3_h_qpst_ug.pdf

(I'm on my phone...)
[HTC Wildfire S] theq86:
I will have a look.
[HTC Wildfire S] Lt.Win:
You guys have come too far. Good luck theq86, nhb, and becimester! :)
[HTC Wildfire S] theq86:
So, unfortunately not :(

I changed your nand_erase command with the right equivalent. But this seems to be the way to go.
[HTC Wildfire S] BeciMester:
I understand it won't be able to test the phone, but not even good for NAND management?

(I'm on my phone...)
[HTC Wildfire S] theq86:
No, I could not establish a connection to the NAND.

The tools we need are already there (see the revised code from nhb)

these commands work for raw partitions. it's just important to delete it beforehand
[HTC Wildfire S] MrTaco505:
Has anyone tried loading GFree into RAM?
[HTC Wildfire S] theq86:
isn't gfree device-specific? anyway.

the last step now is the exploit itself.

nhb is working on it. since he wants to support as many radios as possible he has quite an amount of work. so we're waiting for the exploit now.

when it is ready we have to write it into the radio and hope it doesn't screw it :D
[HTC Wildfire S] MrTaco505:
So the secu_flag is found?
[HTC Wildfire S] theq86:
Not the one in the radio. We're now focussing on patching the hboot to think it was s-off. nhb could not find the real secu_flag. Therefore some had to do an xtc clip and dump his radio directly before and after.

Plus, we are not even 100% sure if the real flag resides on the nand at all.
[HTC Wildfire S] no.human.being:
Yes, I'm actually putting a lot of "intelligence" into the exploit, since I ultimately want to avoid patching in the wrong locations on Radios that we haven't seen yet.

So I'm trying to abstract as much as possible from the "concrete examples" and let almost everything stay "variable" so the exploit literally "adapts" to the specific Radio as best as possible (or finds out that it's too different to adapt and aborts).

This is quite some amount of work and requires a bit of "guesswork" and lots of testing (by slightly modifying the Radio dumps and seeing how the exploit adapts). We're literally doing "brain surgery" on the phones, I really want this to be rock solid.

First testing shows that it perfectly adapts to all the "real" images we have. Now I want to test with slightly modified ones. Even though there's probably no such Radio on any phone yet, it will make the exploit more "future proof" so that we don't need to run around shouting "Stop using the old exploit version!!!!" should HTC release new firmware at a later point in time.

When this is done, I'll take on the actual "patching" part. For now it's only been "detecting where to patch" in a bit of a sophisticated manner.

Oh and we're already past 400 LOC, just for information. :D
[HTC Wildfire S] theq86:
Thanx for your enormous effort. :)
[HTC Wildfire S] MrTaco505:
So once nhb completes the exploit, we got s-off?
[HTC Wildfire S] Lt.Win:
More or less, yes.
[HTC Wildfire S] chuchusweet:
nice share...
[HTC Wildfire S] no.human.being:
I'll go to bed now after a 15-hour programming session. :D

I think I'm gonna finish it today. I'm gonna execute the shell commands from within the C program with "system(...)", since I can then do the "dangerous" stuff (especially erasing the NAND!) conditional on whether all the patching that happened before went well.

So probably no shell script, just a single program invocation with lots of parameters. :D

Then we'll need some daredevil who wants to test. *lol*

I already see the magic smoke coming out of the NAND. :D
[HTC Wildfire S] Lt.Win:
Okay, Now I'm Scared. :D :D :D :D