[DEV][THE S-OFF CAMPAIGN] We need electrical engineers & experts in JTAG, OpenOCD!

Search This thread

seaskyways

Senior Member
Feb 13, 2012
574
344
beirut
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
Code:
[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]

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 ----------

So this information is good as well. So we can lock our BL like it is before we have unlocked?

Sent from my HTC Wildfire S using XDA App

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

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

It is said that if you are s-off you can type in
Code:
fastboot oem eraseconfig
would fix your misc partition , well i am willing to try it just after you guys finish the s-off thing !
 

rezo

Senior Member
Nov 17, 2007
111
105
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.
 

theq86

Senior Member
Jan 6, 2009
951
729
37
Nuremberg
Nothing Phone 2
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...)

I posted my conclusions above in the code sheet :D

But, again. the mtdtools provided with the cwm recovery (dump_image, erase_image, flash_image, nandwrite) are workig fine, as long as we are targetting "normal" partitions.

here e.g. the output if I want to dump_image the radio:
Code:
mtd
 ECC errors (0 soft, 64 hard) at 0x00000000.mtd
 ECC errors (0 soft, 1 hard) at 0x00020000.mtd
 ECC errors (0 soft, 64 hard) at 0x00040000.mtd
 ECC errors (0 soft, 64 hard) at 0x00060000.mtd
 ECC errors (0 soft, 64 hard) at 0x00140000.mtd
 ECC errors (0 soft, 64 hard) at 0x00160000.mtd
 ECC errors (0 soft, 64 hard) at 0x001c0000.mtd
 ECC errors (0 soft, 64 hard) at 0x001e0000.mtd
 ECC errors (0 soft, 64 hard) at 0x00200000.mtd
 ECC errors (0 soft, 60 hard) at 0x00220000.mtd
 ECC errors (0 soft, 64 hard) at 0x00280000.mtd
 ECC errors (0 soft, 64 hard) at 0x002a0000.mtd
 ECC errors (0 soft, 64 hard) at 0x002c0000.mtd
 ECC errors (0 soft, 60 hard) at 0x002e0000.mtd
 MEMGETBADBLOCK returned -1 at 0x00340000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00360000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00380000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x003a0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x003c0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x003e0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00400000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00420000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00440000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00460000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00480000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x004a0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x004c0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x004e0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00500000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00520000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00540000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00560000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00580000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x005a0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x005c0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x005e0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00600000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00620000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00640000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00660000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00680000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x006a0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x006c0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x006e0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00700000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00720000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00740000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00760000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00780000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x007a0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x007c0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x007e0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00800000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00820000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00840000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00860000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00880000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x008a0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x008c0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x008e0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00900000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00920000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00940000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00960000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00980000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x009a0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x009c0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x009e0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00a00000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00a20000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00a40000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00a60000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00a80000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00aa0000 (errno=5).mtd
 MEMGETBADBLOCK returned -1 at 0x00ac0000 (errno=5).mtd
 MEMG............................................
If the mtdtools can not read the partition, it's unlikely they do writing. So we just have to "hope" that at least erase_image radio works.

And if we would not erase the partition before writing it, we would heavily screw the radio, turning our phone unuseable.

this is also the reason why I still have not touched the radio in a writing manner. Because I'm not the guy with the JTAG :D

Good news instead is, that cat and dd managed to dump the image without problems, so I guess they also work well writing.

we just have to be sure to erase the radio. For that I have found no other way than erase_image.
 
Last edited:

no.human.being

Senior Member
Oct 29, 2011
981
987
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?

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.
 

theq86

Senior Member
Jan 6, 2009
951
729
37
Nuremberg
Nothing Phone 2
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...)

2.1 What is QPST?
QPST is a set of Windows tools designed to interface with, control, and test CDMA phones that
contain QUALCOMM ASICs.
So, unfortunately not :(

We could then supply a shell script which does something like:
Code:
#!/bin/ash
mount -o rw /dev/block/mmcblk0p1 /sdcard
dd if=/dev/mtd/mtd7 of=/sdcard/radio.img bs=2k
exploit /sdcard/radio.img /sdcard/radio-patched.img
erase_image radio
dd if=/sdcard/radio-patched.img of=/dev/mtd/mtd7 bs=2k
shutdown -r now
What do you think?

I changed your nand_erase command with the right equivalent. But this seems to be the way to go.
 
Last edited:

theq86

Senior Member
Jan 6, 2009
951
729
37
Nuremberg
Nothing Phone 2
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
 

theq86

Senior Member
Jan 6, 2009
951
729
37
Nuremberg
Nothing Phone 2
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
 
  • Like
Reactions: MrTaco505

theq86

Senior Member
Jan 6, 2009
951
729
37
Nuremberg
Nothing Phone 2
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.
 
  • Like
Reactions: MrTaco505

no.human.being

Senior Member
Oct 29, 2011
981
987
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
 
Last edited:

Top Liked Posts