yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] theq86:
HEUREKA

We can now write to NAND whatever we want, wherever we want. As long as we provide a 2K block written to the NAND.

The reason for the awkward behavior on the boot.img was, that the bootimage (if it is wrong or corrupted) is altered during the boot process.

I then turned my attention to the data partition, as it is not touched during the boot process.

I was able to write data to the partition and could read exactly the written data in the hex editor.

To be able to write on offsets > 0 we must provide a 2k file and the start address must be the address of a block beginning.

However, it's not yet ready for use. After changing the /data partition I noticed that it grew smaller. I have to investigate first.
[HTC Wildfire S] MrTaco505:
Nice and Im:

***UNLOCKED***

MARVEL PVT SHIP S-ON RL

HBOOT-1.08.0099

MICROP-0354

RADIO-7.53.39.03M

Nov 28 2011, 19: 09:21

also on stock ROM
[HTC Wildfire S] no.human.being:
You mean your "/data" got smaller by writing to it?

Could be that the block got corrupted by you writing to it (remember overwriting without erasing first might be illegal) and the NAND "mapped it out" physically (is the NAND chip that intelligent?).

Can someone investigate the mtdutils? I think they handle bad blocks "somehow". We can possibly find out how to map all of them in (at the physical layer, so this is not the "partition mapping" but rather something the NAND chip itself is doing) before writing.

Now, all dumps are from UNLOCKED S-ON. Well not so great variability but well, we just have to live with what we get ... :D

EDIT: Yeah, post #1337. Now that's certainly "elite". :D
[HTC Wildfire S] theq86:
I will have a look at the mtdutils source and see if it handles bad blocks
[HTC Wildfire S] no.human.being:
Yes it "marks block bad", however, I didn't think that this would change the address space. :eek:

I mean, imagine that. You write somewhere, then the block is just "pulled out" and everything gets "one block lower" in addresses? Doesn't make sense, right?
[HTC Wildfire S] MrTaco505:
so where are we now in achieving s-off?
[HTC Wildfire S] theq86:
This thing behaves so untrustfully.

Try 1:

Changed data -> size changed

Try 2:

Changed data -> size was ok, but the written block contained bits I did not set.
[HTC Wildfire S] no.human.being:
But size got back to the original value? Glad we didn't destroy a block. *peeew* :D

I was so afraid we'd have "bricked" the NAND chip or the memory controller. :eek:
[HTC Wildfire S] theq86:
Yes, sizes are okay.

I still think the error is on my site. I will test further until we have a best practice that alsways works.

I actually do not think the tools malfunction, as I never had problems with CWM.
[HTC Wildfire S] no.human.being:
Yes, however you might have to explicitely erase a block before you can write to it. Is there a utility for this?
[HTC Wildfire S] theq86:
yes, nandwrite is a two-step utility. it must be, because it really writes the changes and even keeps the rest of the partition intact. maybe something went wrong with cat and only my dumps are corrupt.

---------- Post added at 08:33 PM ---------- Previous post was at 08:11 PM ----------

nhb and me are working on different frontlines atm.

he is comparing the radios and tries to find the offset of the flag, or the hboot function that pretends S-OFF

while I figure out how we can patch the radio and write the changes.

we can be ready tomorrow or it will take us even more time, who knows.
[HTC Wildfire S] seaskyways:
Nice work guys , wish you get a nice easy time ! And I really want to work and get educated as linux programming or such a thing , what do you say guys ? Do you advice me to ? cuz i like this thing and i wanna learn it !
[HTC Wildfire S] mstfkaratas:
Hi i have s-off wfs with unlocked bootloader 1.09.0099 and radio 7.46.35.08

i can dump with different radio versions if it helps

here is my fastboot command and full device info

theq86 and nhb if you want my radio dumps just let me know and i upload them for you

fastboot -c "mtdparts=msm_nand:0x00100000@0x1ff00000(misc),0x00500000@0x02fc0000(recovery),0x00340000@0x034c0000(boot),0x10400000@0x03800000(system),0x02300000@0x13c00000(cache),0x09600000@0x16900000(userdata),0x00a00000@0x15f00000(devlog),0x02fc0000@0x00000000(radio)" boot recovery-clockwork-5.0.2.8-marvel.img

radio.img size= 50.069.504 byte

(bootloader) version: 0.5
(bootloader) version-bootloader: 1.09.0099
(bootloader) version-baseband: 7.46.35.08
(bootloader) version-cpld: None
(bootloader) version-microp: 0451
(bootloader) version-main: 11.33.401.2
(bootloader) serialno: -----------
(bootloader) imei: ------------
(bootloader) product: marvel
(bootloader) platform: HBOOT-7227
(bootloader) modelid: PG76*****
(bootloader) cidnum: 11111111
(bootloader) battery-status: good
(bootloader) battery-voltage: 4105mV
(bootloader) partition-layout: HTC
(bootloader) security: off
(bootloader) build-mode: SHIP
(bootloader) boot-mode: FASTBOOT
(bootloader) commitno-bootloader: 510e562c
(bootloader) hbootpreupdate: 12
(bootloader) gencheckpt: 0
[HTC Wildfire S] pihug12:
Please, update your radio.

There are only two possibilities for S-ON users :

With HBOOT-1.08.0099 & RADIO-7.53.39.03M, you should have a dump of 50 069 504 Bytes (47,75MB).

With HBOOT-1.09.0099 & RADIO-7.54.39.28M, you should have a dump of 40 632 320 Bytes (38,75MB).

If you can have these two dumps, it's the best thing we can have right now. :D
[HTC Wildfire S] theq86:
Well, no I think the mistake is the cat command.

I tried cat'ing my /data from android, from recovery with standard params and from recovery with radio mapped.

the last both were identical, but the one cat'ed from android was different.

wasn't cat designed for text data? also what could cause so many errors?

Then I noticed another curiosity. Look at a cwm backup of the data image. it's 111 Megs for me, but 150 is the partition size. I feel fooled of my phone -.-
[HTC Wildfire S] seaskyways:
hey , you can just simply use adb pull as I did , in recovery adb pull the radio to the adb folder !
[HTC Wildfire S] theq86:
also my cat outputs of /data are 157 MB large. but data is 150 MB...
[HTC Wildfire S] mstfkaratas:
That looks normal, as i know cwm doesnt write free space to backups

that looks abnormal :confused:
[HTC Wildfire S] theq86:
I found out why.

Look: 157,3 MB (157.286.400 Bytes)

157.286.400 Bytes = 150 MB (using 1024 as kilo base)

but my file manager uses 1000 as kilo base

I'm using nautilus -.-
[HTC Wildfire S] seaskyways:
after S-off can i use fastboot oem eraseconfig ???
[HTC Wildfire S] mstfkaratas:
bad nautilius :mad:

lets go back to radio dumps, which radio-hboot match do you want me to dump, if s-offed phone is useful for you

why dont you try and see:confused: i think you have to upgrade your hboot and unlock it to use fastboot oem commands
[HTC Wildfire S] theq86:
useful are the radios that ship with the HBOOT 1.08.0099 (from htcdev)

and the radio that shipped with 2.13.401.3 with htcdev hboot 1.09.0099
[HTC Wildfire S] seaskyways:
Which exactly means the one i deposited , hboot 1.09.0099 , 2.13.401.3 full RUU upgrade including the radio !

i already tried a lot on my hboot but nothing , i read somewhere that guys with s-off executed that command , so would you try it for me please , it may fix my usb brick !

EDIT : here you go :
[HTC Wildfire S] mstfkaratas:
http://www.filefactory.com/file/c24...35.3037_7.54.39.28M_release_236989_signed.exe

This shipped ruu has hboot 1.08.0000 not 1.09.0099, but i am updating hboot to 1.09.0099 manualy now

@seaskyways i will try that command for you
[HTC Wildfire S] no.human.being:
Removed ..
[HTC Wildfire S] MrTaco505:
So is this a good thing that the two dumps are not similar?
[HTC Wildfire S] no.human.being:
At least it helps finding out a lot since obviously I'll just "skip over" all the stuff that's equal and not look into it much.

Now I've compared my Radio with that of seaskyways, but they didn't match at all. Then I though "maybe he has the new Radio, but dumped with the kernel parameters that were for the old". Comparison with theq86's Radio (who already has the new one) has shown that I was right. So seaskyways has the new Radio, he simply dumped too much. :D

However, no need for you do dump again, seaskyways, since you just dumped "too much" so I could simply "trim" the file with dd and now it matches with the other "short" (= new) Radios.
[HTC Wildfire S] theq86:
Has anyone a hammer? my phone sucks -.-
[HTC Wildfire S] MrTaco505:
But if I update to the new hboot, will you need another dump to compare?
[HTC Wildfire S] mstfkaratas:
cat /dev/mtd/mtd7 > /sdcard/radio.img gives me different radio dump every time i use command

i used 4 times without rebooting and here are my file sizes

radio.img 50.069.504 byte
radio2.img 50.069.504 byte
radio3.img 46.669.824 byte
radio4.img 46.616.576 byte

fastboot command:

fastboot -c "mtdparts=msm_nand:0x00100000@0x1ff00000(misc),0x00500000@0x02fc0000(recovery),0x00340000@0x034c0000(boot),0x10400000@0x03800000(system),0x02300000@0x13c00000(cache),0x09600000@0x16900000(userdata),0x00a00000@0x15f00000(devlog),0x02fc0000@0x00000000(radio)" boot recovery-clockwork-5.0.2.8-marvel.img

S-OFF
Unlocked 1.08.0099
RADIO-7.53.39.03M
[HTC Wildfire S] no.human.being:
I think I've seen enough! :D

There's a site on the net that describes how you can talk to the Radio (!!) via a tty device on the HTC Desire Z (Vision). You could use this process for querying CID, secu_flag, SIM-lock, serial number, IMEI and other device-specific information. However, I tried it on the Wildfire S (Marvel) and it didn't work. The "mighty" tty device is not there, just the "standard" ttys that lead to terminal sessions.

Sounds like there's something wrong with your cat utility (or the mtd driver?). As long as the "radio.img" and "radio2.img" are the same (load them to the computer and to an md5sum), either of those will do. The size looks "right", the other sizes look "crap".
[HTC Wildfire S] mstfkaratas:
radio.img and radio2.img are identical, they have same md5, i uploaded radio.img and sent a pm, i hope it helps.
[HTC Wildfire S] no.human.being:
Ok, we got an S-OFF Radio now! Thank you very much mstfkaratas! :D
[HTC Wildfire S] theq86:
Here some test writings

Beginning
d88ec5ab40e527a59bc176714efdde64 /dev/mtd/mtd5

After cat /dev/mtd/mtd5 > /sdcard/userdata.img
d88ec5ab40e527a59bc176714efdde64 /dev/mtd/mtd5
d88ec5ab40e527a59bc176714efdde64 /sdcard/userdata.img

after /userdata format
b8006069c6898e53556b201796869306 /dev/mtd/mtd5
d88ec5ab40e527a59bc176714efdde64 /sdcard/userdata.img

after flash_image userdata /sdcard/userdata.img
d88ec5ab40e527a59bc176714efdde64 /dev/mtd/mtd5
d88ec5ab40e527a59bc176714efdde64 /sdcard/userdata.img

after /userdata format
b8006069c6898e53556b201796869306 /dev/mtd/mtd5
d88ec5ab40e527a59bc176714efdde64 /sdcard/userdata.img

after nandwrite /dev/mtd/mtd5 /sdcard/userdata.img
d88ec5ab40e527a59bc176714efdde64 /dev/mtd/mtd5
d88ec5ab40e527a59bc176714efdde64 /sdcard/userdata.img

after nandwrite /dev/mtd/mtd5 /sdcard/testdata.img
5887689bae6c1a64cea10ee8ddb13157 /dev/mtd/mtd5
d88ec5ab40e527a59bc176714efdde64 /sdcard/userdata.img
b97c1af4c6380d8971fd939d677734cd /sdcard/testdata.img

after cat /dev/mtd/mtd5 > /sdcard/newdata.img
5887689bae6c1a64cea10ee8ddb13157 /dev/mtd/mtd5
d88ec5ab40e527a59bc176714efdde64 /sdcard/userdata.img
b97c1af4c6380d8971fd939d677734cd /sdcard/testdata.img
5887689bae6c1a64cea10ee8ddb13157 /sdcard/newdata.img

after nandwrite -s 0 /dev/mtd/mtd5 /sdcard/userdata.img
5887689bae6c1a64cea10ee8ddb13157 /dev/mtd/mtd5
d88ec5ab40e527a59bc176714efdde64 /sdcard/userdata.img
b97c1af4c6380d8971fd939d677734cd /sdcard/testdata.img
5887689bae6c1a64cea10ee8ddb13157 /sdcard/newdata.img

after flash_image userdata /sdcard/userdata.img
d88ec5ab40e527a59bc176714efdde64 /dev/mtd/mtd5
d88ec5ab40e527a59bc176714efdde64 /sdcard/userdata.img
b97c1af4c6380d8971fd939d677734cd /sdcard/testdata.img
5887689bae6c1a64cea10ee8ddb13157 /sdcard/newdata.img

Although /dev/mtd/mtd5 was restored successfully (according to md5sum) the data is corrupt

Still all this is strange...

The dumps have the correct size. 150 MB as the partition

The data that I want to write is not written the same way to the partition.

I have no idea anymore. There also was no tool to erase blocks to check your assumption, nhb.

perhaps we need a different way to patch the radio.

maybe you can test something, too and find out more than me after you're tired of reading radio images :D
[HTC Wildfire S] mstfkaratas:
now you can compare while i am sleeping :D it is 3 am here and i have to get up early, good night :)
[HTC Wildfire S] BeciMester:
OK, in hboot 1.08.0099 the secu_flag checking subroutine starts at offset 0x8b68 from the beginning of the hboot.

Edit: to patch, find the byte sequence

10 40 2D E9 4E C6 00 EB 00 00 50 E3

and replace it with this:

10 40 2D E9 00 00 A0 E3 10 80 BD E8

No need to worry about the rest. What the above does is

- push registers to stack (acknowledge that it's a subroutine)

- load 0x0 into R0

- pop the registers from stack and returns

Let us know how it goes. ;)
[HTC Wildfire S] theq86:
and 1.09.0099 ?
[HTC Wildfire S] no.human.being:
Bad news! Nothing unusual in the S-OFF Radio.

All differences which appear will also appear between two S-ON devices. So either it's absolutely perfectly hidden (as one of the bits of a value that's supposed to be different for all the devices or as a "set of multiple bits scattered among the Radio", which together represent "S-ON" by having even parity and "S-OFF" by having odd parity or whatever) or it's not in the Radio, which also means that it's not in the NAND at all.

It might be the state of some "dedicated hardware device", e. g. a QFuse attached to a GPIO pin of the controller that can be "checked" and "blown". I know this sounds extremely unlikely, however it would explain why no one has ever "S-ONed" an xtc-clipped device again.

Any ideas left? If not, then I'd suggest we do it the Revolutionary way. I'd say we modify the opcode at 0x9d0439f0 from 0xe2000001 to 0xe2000000. If I understand the ARM opcode format correctly, that should be "and r0, r0, #0", which takes the value in register 0, does "bitwise and" with value 0 (so result should always be 0) and stores the result in r0. So basically it should set r0 to value 0. Should be the "least invasive way of doing it", what do you think BeciMester? :D
[HTC Wildfire S] BeciMester:
Oops, edited post above before I saw your answer.

I'm talking about the subroutine that calls yours. It's important because your code above is not the only check done! The 'mother' calls 0x9d0439d8 first, and if it returns 0, it still does another check which also has to return 0 for the hboot to report 'S-OFF'. So I thought we'd kill two birds with one stone and just get the 'mother' subroutine to load 0x0 into R0 and return. Simple as. :) Once we overwrite stuff, we might as well go all the way. :D

Edit: in other news, I got a lend of a copy of IDA Pro today! :D It's not the newest version (5.5) but man this **** is awesome!! :eek: It can do graphs of the program flow which is dead handy! I kinda see why it costs so much, it makes objdump look like stone age stuff! Haha I feel like a kid on Christmas morning! :p (Yes I know, only now when we're nearly done... And I'll have to give it back in a few weeks... but still :D)
[HTC Wildfire S] no.human.being:
Are you sure that the "mother" is the only one that calls the "child"? :D

Don't want to have inconsistencies. A few callers getting "S-ON" because they call the one, a few others getting "S-OFF" because they call the other, why not? :D
[HTC Wildfire S] MrTaco505:
So we are now sticking with patching HBOOT?
[HTC Wildfire S] theq86:
Today I thought about what the rev team wrote. About not being able to patch the real flag. To patch hboot they obviously had radio access as we do. Maybe they did their decision at the same stage as we.

But still ... How to write the changes. Every try with the tools included in cwm failed ...
[HTC Wildfire S] BeciMester:
Yes I'm sure. With my shiny new toy (see edited post above) I can do cross-references now, I mean it can tell me all the places a certain sub is called from.

0x9d008b68 calls -> 0x9d03a4ac, which calls -> 0x9d0439d8, your bit above. Now, the 3rd is only called by the 2nd, and the 2nd is only called by the 'mother' (0x9d008b68). The 'mother' on the other hand is called from 21 different places in the hboot. :eek:

(Man I love this program, I should start saving up and get it, it's worth having around)
[HTC Wildfire S] theq86:
We have the pg76diag btw. If hboot thinks it's s-off it may load the diag. If we find the routine checking for the eng sim we could do a virtual clipping.
[HTC Wildfire S] no.human.being:
But actually 0x9d008b68 is huge. It returns at 0x9d00a098 if I see correctly.

0x9d03a4ac is also not that small. Seems to return at 0x9d03aab0.

0x9d0439d8 on the other hand is tiny. Just 9 machine instructions.

Yes, they said it was "inaccessible". It's either not on the NAND but in some other "obscure" device or it's actually in the Radio, but they were extremely good at obfuscating its presence.

I'm just wondering why it's so f***ing easy on the Desire S. Just open partition 7 for reading, seek to 0x00000a00, read the byte, do xor 0x01 to flip the least significant bit, close partition 7. Then open partition 7 for writing, seek to 0x00000a00 again, write one byte, close partition 7. Reboot, done. That's actually what GFree does.

I think with GFree a lot of "effort" went into getting the partition "mapped", so what we do by supplying parameters to the kernel they seem to do "at runtime" which is obviously much more difficult and that's what most of the code (this totally obscure "needle and haystack"-algorithm) is for if I read the exploit code correctly. Once they got partition 7 open it's plain simple and they dump the entire partition 7 (Radio?) to the SD card, then patch it, then write it back. In their case, overwriting the entire partition not be neccessary though. The memory controller in the MSM8255 can overwrite in-place with random-access behaviour and without prior deletion.
[HTC Wildfire S] BeciMester:
In that hboot, you're looking at offset 0x8b58 from the beginning of the hboot.

The byte sequence you're replacing looks like

10 40 2D E9 BD C6 00 EB 00 00 50 E3

The bytes you're inserting are the same as above.

10 40 2D E9 00 00 A0 E3 10 80 BD E8
[HTC Wildfire S] theq86:
Well, it would still be helpful to have a before and after dump from the same phon just before and just after clipping. Because then we had the xtc changes isolated.
[HTC Wildfire S] no.human.being:
Ok, I'll create the "main exploit code" today. I'll just expect the Radio to be dumped to a file that you supply as a parameter, then I'll try to detect which Radio version it is, find where HBOOT begins, detect HBOOT version as well (as an additional security measure), then find the code in HBOOT, patch it, done.

I'll probably put lots of checks in to make absolutely certain that we're on the right Radio and HBOOT version, that everything's mapped correctly and that what we're patching is actually part of the HBOOT code.

Then I'll test this on all the Radio images.

And you should better get an image written. :D Or at least the NAND erased. Doesn't "dd if=radio.img of=/dev/mtd7" work for writing after the NAND is erased?

We could then supply a shell script which does something like:

#!/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
nand_erase /dev/mtd/mtd7
dd if=/sdcard/radio-patched.img of=/dev/mtd/mtd7 bs=2k
shutdown -r now

What do you think?

EDIT: Or even issue all the commands from within "exploit", since the "nand_erase" should obviously NOT be performed when e. g. the dumping failed. So we'll have to check whether the dumping created a file of the expected size and then we'll patch it and only then we'll erase the NAND and write it back.

Right. And then if the dumps were exactly identical we'd know for sure that secu_flag is NOT in the NAND. :D
[HTC Wildfire S] hans3103:
Use a clip,safe,fast and simple. I have one my own and its worth the money!
[HTC Wildfire S] no.human.being:
It's expensive and difficult to acquire (only distributor is located in the UK afaik?!). There are softroots available for almost any phone you can imagine, but not for the WFS (because it is not considered "widespread enough"). That's a pity. Need to change that situation. Plus I'm specializing on IT security and the locked bootloader is a (pretty simple) "security system". Figuring out a method for bypassing those is great fun. :)

I am very determined to keep this development up. I'd do so even if someone offered me an xtc clip for free. I'm going to buy a Galaxy S2 in a few months and you can flash these using Heimdall. I'm not doing it primarily for unlocking my phone. I'm doing it for the challenge. :D
[HTC Wildfire S] *se-nsei.:
Maybe we could try using (something like) one of these to transport the files successfully?

http://www.ebay.co.uk/itm/X-SIM-Unl...im_Cards_CV&hash=item35b7bef36d#ht_5289wt_932

Any ideas?
[HTC Wildfire S] no.human.being:
Ok. I didn't have the opportunity of getting access to a JTAG interface yet, but I do see 5 different approaches to getting S-OFF.

1. Perform a privilege escalation exploit inside Android in order to get temporary root access, then use these privileges in order to reset the "device security" flag, turning the phone S-OFF. Same effect as Revolutionary / xtc-clip, only that (unlike xtc-clip) it will be free and (unlike Revolutionary) it will support the MSM7227.

2. Perform a privilege escalation exploit inside Android in order to get temporary root access, then mount "/system" as "rw" and set permissions to "drwxrwxrwx". This will enable apps to perform modifications on the "/system" directory, so that you can install new kernels for example. It will not turn the phone S-OFF. You won't be able to install ROMs via the bootloader using this method and you won't be able to flash the radio.

3. Cracking the signature mechanism, enabling us to sign custom ROMs as "official" and enable them to be installed using stock S-ON HBOOT. This may require modifications to be performed on the ROMs before they can be flashed. If the signature uses a strong, proven algorithm (e. g. RSA) with adequate signature key length this probably won't be successful.

4. Getting the "Revolutionary" people to disclose their exploit and port it over to the MSM7227 processor they are unwilling to support. They probably won't disclose their exploit so we would have to resort to reverse-engineering, which I wouldn't want to do as this would be infringing their copyrights.

5. Reverse engineer the xtc-clip and construct either an equivalent software-only or a hardware solution that is cheaper to build. Again, this might be unlawful, so I will refrain from doing this.

From my point of view, number 1 seems to be the best and we have descending quality down to number 5, which in my opinion would be the worst. Any other ideas/suggestions?
[HTC Wildfire S] aparici:
I think that the nº 1 is the best and most coherent. If you are able to find the exploit to getting temporaly root, and then make the script to set the flag security to s-off.

But one cuestion. If we have tmp root but we are s-on, how we can set the flag to s-off?