yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
I'm not sure how they have done it, but basically device security is something like a "bitflag" inside the radio image. First we have to locate it, which means find its address inside the phone's ROM. We could make use of JTAG for this purpose and I'd also like to set it via JTAG to test whether it actually turns the phone S-OFF. I will reset it again afterwards, so that the phone becomes S-ON again, and then work out a way to set it through software from the stock S-ON Android install.

For this, I'd try to get write access to this memory area somehow. There are two scenarios then, one "easy" and one "hard".

1. The "easy" one: If the device security flag resides inside a memory area, which is accessible via one of these "/dev/mtdblock*" devices, S-OFFing will be easy after we have located the flag and the phone has been temprooted, which we can already do using the zergRush exploit. The "/dev/mtdblock*" devices will serve as a high level interface to the memory, which can be handled like a simple file through these block devices. This means we'll simply "fseek" to the correct offset and then "fwrite" to set the flag. Reboot the phone afterwards and it'll be S-OFF. That's basically all. Sounds easy, but implementing this will still be some quite hard work actually.

2. The "hard" one: If it is not accessible, well ... then things certainly don't look as good and we'll have to resort to other means. Not sure yet what this means though.

Luckily, case one doesn't seem all that unlikely, so the hardest part will probably actually be locating the security flag inside the phone memory, as this will probably involve all this low-level stuff like dumping the phone memory using JTAG (which by itself is not a simple procedure, as this is very specific for the controller you're operating), disassembling the firmware, searching for the portion which checks the device security and get the address of the security flag from there.
[HTC Wildfire S] insink71:
question

Could one perform a memory dump, xtc clip s-off & do another dump and then use a bot to seek any differences [memory adresses changed] in the two dumps? Also if qualcom diagnostic software is what is switching [or erasing] the security flag information, wouldn't that give us some [address] info if we logged the figurative experiment? I have often went with the known method [xtc clip] before I would endevour to do this much work, but if I buy a cheap Tmo [gsm-A510a], I'll do the dumps and logging for you if it would help. Once the s58 [secrity flag] data is cleared, its gone. Be nice to be able to identify & extract it [then could switch back and forth for OTAs]. I am definately not an embedded memory expert though.

Rob
[HTC Wildfire S] no.human.being:
Will xtc-clip only S-OFF or will it replace the entire recovery? In the latter case, your proposal could be impractical because replacing the recovery will change a lot of memory locations.
[HTC Wildfire S] island3r:
I think you need to look at this in a more simple way, because tbh flashing modified radio images and jtagging are no easy tasks. Unless of course you feel comfortable with them :)

I think we should start with basic stuff. Like dumping stock hboots and hex comparing them with eng-hboots. First of all I used this command to dump an image of the stock hboot (0.90.000):

fastboot oem saveprt2sd hboot -n hbootpart.img -a

This command dumps the hboot into an img file. Then I took the diag files from this forum and hex compared them. Both seem to be genuine hboot images, but they had a lot of differences as well (I also compared the nb0 file from the RUU to be sure).

That's what stopped me from trying to flash the eng-hboot (or even checking if that was possible). You can flash using the "dd" command, but a bad hboot flash equals a bricked phone.

Which brings us right back to jtagging :mad:
[HTC Wildfire S] ONeill123:
What u mean with "dd" command.

If it is possible with this command to flash a new radio.img with s-on

If this is possible and the secruity flag is in the radio, then we can edit the secruity flag with an hex editor and flash this custom radio.
[HTC Wildfire S] no.human.being:
I just got a bit further, but running into problems now.

On the Desire S, the device security flag seems to be 2560 bytes into partition 7, as this is the location GFree writes to when turning the device S-OFF. It seems to be a single-byte value with either all of its bits reset or only its least significant bit set. Not sure which value is S-OFF and which is S-ON though, as GFree only toggles the bit, not set it to a specific value and I don't know in which state it is before GFree is run for the first time.

The Wildfire S only has partitions 0 through 6, so no partition 7 here. However, I'd guess that's just due to the partition layout being different and the flag is still somewhere on (and possibly also 2560 bytes into) one of the partitions.

So I opened a root shell on my WFS, in order to read that exact location from the "/dev/block/mtdblock*" devices. However, I wasn't exactly successful.

# dd bs=1 skip=2560 count=1 if=/dev/block/mtdblock6 of=/data/local/read.bin
/dev/block/mtdblock6: read error: I/O error
0+0 records in
0+0 records out
0 bytes transferred in 0.002 secs (0 bytes/sec)
#

It's the same with all the other "/dev/block/mtdblock*" devices. What am I doing wrong here? Even "cat /dev/block/mtdblock6" won't work, complaining about "mtdblock6: invalid length". The same with all the other "/dev/block/mtdblock*" devices here as well.

Are these devices somehow "broken" in Android? If they are, how come they can be mounted as file system?
[HTC Wildfire S] island3r:
The partition layout is indeed different. Try this
[HTC Wildfire S] no.human.being:
"df -a" does not work (the Android version does not support the arguments that "standard df" does), but simple "df" does.

/dev: 214176K total, 64K used, 214112K available (block size 4096)
/mnt/asec: 214176K total, 0K used, 214176K available (block size 4096)
/mnt/obb: 214176K total, 0K used, 214176K available (block size 4096)
/app-cache: 8192K total, 0K used, 8192K available (block size 4096)
/devlog: 10240K total, 8432K used, 1808K available (block size 4096)
/system: 266240K total, 254580K used, 11660K available (block size 4096)
/data: 153600K total, 90372K used, 63228K available (block size 4096)
/cache: 35840K total, 2312K used, 33528K available (block size 4096)
/mnt/sdcard: 1926460K total, 673676K used, 1252784K available (block size 4096)
/mnt/secure/asec: 1926460K total, 673676K used, 1252784K available (block size 4096)

Still doesn't explain, why these devices cannot be accessed. Executing "mount" command after obtaining temproot through zergRush shows something like this.

/dev/block/mtdblock6 /devlog yaffs2 rw,nosuid,nodev,relatime 0 0
/dev/block/mtdblock3 /system yaffs2 rw,relatime 0 0
/dev/block/mtdblock5 /data yaffs2 rw,relatime 0 0
/dev/block/mtdblock4 /cache yaffs2 rw,nosuid,nodev,relatime 0 0

So obviously the file system driver can access the devices. Why can't I?

This has nothing to do with privileges. One of my fellow students has an HTC device, which is already permarooted, and he can't open the "/dev/block/mtdblock*" devices either. Is this a "bug" in Android? If it is, how come the file system driver doesn't stumble upon this? Does it access memory on a lower level, bypassing the block device layer? This would be really weird and "non-POSIX-conformal" though.
[HTC Wildfire S] island3r:
Wait, about the bit you talked about in desire's partition 7, are you sure it is about s-off? I'm asking because gfree is set to configure both s-off and supercid as well as stock recovery. Maybe what you found was the powercycling bit.

(I'm asking just to clarify)

EDIT:

Ok, about the problem at hand. Use

and then

to check what partition 6 is.

Then use dump_image to save the partition in img format.
[HTC Wildfire S] no.human.being:
Actually it is doing the following.

1. Writing 0x3131313131313131 (this is ASCII '11111111') at 0x00000200 to 0x00000207. This is the SuperCID.

2. Writing either 0x00 or 0x01 (depending on the old value) at 0x00000a00. This is the actual S-ON/S-OFF.

3. Writing 0x7856f3c9 at 0x00080000 to 0x0080003, then writing zeroes from 0x00080004 to 0x000807fb, then writing 0x4953f47d from 0x000807fc to 0x000807ff. This seems to have something to do with the SIM-lock.

All modifications are performed on partition 7. The powercycling code doesn't seem to write to the ROM at all.

# cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00040000 "misc"
mtd1: 00500000 00040000 "recovery"
mtd2: 00340000 00040000 "boot"
mtd3: 10400000 00040000 "system"
mtd4: 02300000 00040000 "cache"
mtd5: 09600000 00040000 "userdata"
mtd6: 00a00000 00040000 "devlog"
# ls -a -s /dev/block/mtd*
0 /dev/block/mtdblock0
0 /dev/block/mtdblock1
0 /dev/block/mtdblock2
0 /dev/block/mtdblock3
0 /dev/block/mtdblock4
0 /dev/block/mtdblock5
0 /dev/block/mtdblock6
#

The second command is of no use. Device files are just a gateway to the underlying device driver. They are purely virtual (just a piece of API) and don't have a "file size".

I'm not sure what you mean. "dump_image" is not a command that is supported on the shell of a stock Android device.
[HTC Wildfire S] island3r:
Yes sorry, the -s switch was unnecessary, I think -l checks permissions.

About dump_image you have to download the binary, push it to the same location with busybox, chmod them to 755 and then run the command. Something along these lines:

Both files are in the zip.

Edit: I suggest /data/local/tmp
[HTC Wildfire S] Lt.Win:
Okay, so I've heard from various sites that using the identifier token of the Desire [not Desire S or HD] on HTCDev, you can unlock the WFS bootloader.

So, anyone with an identifier token? I want to test it out.
[HTC Wildfire S] ONeill123:
Hmm, i think its impossible. After typing an identifier token you become an email with an unlock_code.bin

This file you push via fastboot to phones memory.

Then fastboot execute and the .bin writes a line of code in hboot over the first lines, so in your hboot stands UNPOCKED

but the wfs don't have this first line. And the unlock_code inly works with the real devices identifier token of the device.

But if u find an desire unlock_code then try it. Maybe.

@no.

I think you are on the right way. Have u chmod 755 or 777 the mtblock folder to access them?
[HTC Wildfire S] no.human.being:
Ah ok. That's what you wanted to do. I've already checked, but here's the output.

# ls -a -l /dev/block/mtd*
brw------- root root 31, 0 2011-12-26 22:25 mtdblock0
brw------- root root 31, 1 2011-12-26 22:25 mtdblock1
brw------- root root 31, 2 2011-12-26 22:25 mtdblock2
brw------- root root 31, 3 2011-12-26 22:25 mtdblock3
brw------- root root 31, 4 2011-12-26 22:25 mtdblock4
brw------- root root 31, 5 2011-12-26 22:25 mtdblock5
brw------- root root 31, 6 2011-12-26 22:25 mtdblock6
#

Nothing unusual here. I don't think it's a permissions problem. Seems to be more like a "quirk" in the Android kernel block device driver. A very unusual one though.
[HTC Wildfire S] island3r:
I thought you wanted to check permissions? I could be wrong though it was 5am when I read your post :)

Ok, so did you dump mtd6? Although I doubt that's the one we need. How did you end up with mtd6 anyway? If other htc devices are any indication, /dev/block/mtdblock7 is /system.
[HTC Wildfire S] no.human.being:
The problem is that I cannot open the mtd devices. The fopen fails with any of them. It fails with "mtdblock0" to "mtdblock6". "mtdblock7" seems to be "/system" on the Desire S. However, the Wildfire S has a different partition layout which only has "mtdblock0" to "mtdblock6" for a total of 7 mtd block devices and "mtdblock3" seems to be "/system" on the Wildfire S.

The fopen failing on them is not a permissions problem though. I am root (temproot with zergRush) and it still fails. The "mtdblock6" was just a random example, it fails with any of the devices. And yes, "mtdblock3" is probably the one we need.

Opening the "mtdblock*" devices also fails on the HTC phone of my fellow student. I'm not sure what exact phone model he is using, but his is already S-OFF and permarooted and has a Custom ROM installed, so this seems to be more of a "bug" in Android than a security measure, so privilege escalation won't help here.

It is a very "obscure" bug though, because normally, on a POSIX-compliant system (Android is based on Linux) the file system drivers itself (e. g. the yaffs2 drivers) make use of the underlying block device layer for accessing the storage itself. Obviously, "mtdblock3" can be mounted as "yaffs2", so the file system driver can access it. How will the file system driver access the persistent storage, when the corresponding block device layer is corrupted?

The dumping I haven't tried yet. I just tried getting access to the device layer via software, but it fails without any obvious reason.
[HTC Wildfire S] island3r:
Ok why do you need to mount it though? Just dump it and then look what's in it. There are at least 3 different ways to dump a partition.
[HTC Wildfire S] no.human.being:
I don't want to mount it. Mounting works, it is already mounted. I want to dump its raw contents via the device file, patch the dump to a ROM that's S-OFF, then put the dump back on the mtd device. I just put down some code for doing this.

/*
* S-OFF for HTC Wildfire S
* To be applied after temprooting the device via zergRush exploit
*/

#include <stdio.h>

int main()
{
FILE* fdRead;
FILE* fdWrite;
char c;
unsigned long unOffset;

/*
* 1. Dump the "/system" partition from NAND to SD-Card
*/

fdRead = fopen("/dev/block/mtdblock3", "rb");
fdWrite = fopen("/sdcard/dump.img", "wb");
c = fgetc(fdRead);

do
{
fputc(c, fdWrite);
c = fgetc(fdRead);
}
while (!feof(fdRead));

fclose(fdRead);
fclose(fdWrite);

/*
* 2. Patch the dump with S-OFF, SUID set and SimLock unlocked
*/

fdRead = fopen("/sdcard/dump.img", "rb");
fdWrite = fopen("/sdcard/patch.img", "wb");
c = fgetc(fdRead);
unOffset = 0;

do
{
fputc(c, fdWrite);
c = fgetc(fdRead);
unOffset++;

/* Super CID */
if ((unOffset >= 0x00000200) && (unOffset <= 0x00000207))
c = 0x31;

/* S-OFF */
if (unOffset == 0x00000a00)
c ^= 0x01;

/* SIM lock */
if (unOffset == 0x00080000)
c = 0x78;
if (unOffset == 0x00080001)
c = 0x56;
if (unOffset == 0x00080002)
c = 0xf3;
if (unOffset == 0x00080003)
c = 0xc9;
if ((unOffset >= 0x00080004) && (unOffset <= 0x000807fb))
c = 0x00;
if (unOffset == 0x000807fc)
c = 0x49;
if (unOffset == 0x000807fd)
c = 0x53;
if (unOffset == 0x000807fe)
c = 0xf4;
if (unOffset == 0x000807ff)
c = 0x7d;
}
while (!feof(fdRead));

fclose(fdRead);
fclose(fdWrite);

/*
* 3. Write the patched dump back to NAND
*/

fdRead = fopen("/sdcard/patch.img", "rb");
fdWrite = fopen("/dev/block/mtdblock3", "wb");
c = fgetc(fdRead);

do
{
fputc(c, fdWrite);
c = fgetc(fdRead);
}
while (!feof(fdRead));

fclose(fdRead);
fclose(fdWrite);
return(0);
}

Please don't try this out yet. It is completely unverified and might brick your phone. I do not provide any warrenty for this one. Chances are it will simply not work as I expect the device cannot be opened. If the device can be opened, chances are it might S-OFF your phone, but like I said it's completely untested yet. In fact, I haven't even found a way to compile C code for Android yet. :D

What compiler do you use? I guess you need one of those that come with the Android NDK, right?
[HTC Wildfire S] island3r:
Actually I was never interested in compiling stuff, so I can't help there :)

About the script, you can definately do step 1, you might be able to do step 2, but step 3 is impossible since that's what s-on is made to prevent.

Besides, I don't think that the /system partition is responsible about that stuff because the phone is already s-on way before /system gets mounted.
[HTC Wildfire S] ONeill123:
I think step 3 is impossible too. But idk, maybe it works, that is great, if it works.

To compile for Android:

Like this guy said:

http://xdaforums.com/showpost.php?p=8115556&postcount=5

you need the Android NDK:

http://developer.android.com/sdk/ndk/index.html

to compile C-code for the embded system. Hope that u find a way!
[HTC Wildfire S] no.human.being:
You think Android prevents writing to a device file? :eek:

I'd expect the "fopen" to fail, as no program seems to be able to open the "mtdblock*" device files, but this has nothing to do with S-ON, it also fails on an S-OFF phone.

I have never ever heard of anyone who has enforced a write protection on the device layer under Linux. I don't think it's even possible, but at least it's "unusual". Permissions are handled on the file system layer.

Remember you have to run this as root (zergRush) and Android itself can definitely write to the ROM, even when the device is S-ON. It needs to write to "/system" when performing over-the-air updates and these can be performed on S-ON devices. So unless there is some really great amount of "black magic" and trickery done, I'd say S-ON is definitely not protecting the block device itself. Also S-ON is definitely not the "ROM protection" that some embedded systems offer.

Does anyone know which tool I could use to compile this for my phone? I guess it's some of the compilers coming along with Android NDK, but I'm not sure. The "/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc" fails.

In file included from test.c:1:
./../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/stdio.h:50:23: error: sys/cdefs.h: No such file or directory
./../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/stdio.h:51:24: error: sys/_types.h: No such file or directory
In file included from test.c:1:
./../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/stdio.h:163: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'extern'
./../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/stdio.h:232: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__BEGIN_DECLS'
./../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/stdio.h:382: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__BEGIN_DECLS'
./../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/stdio.h:393: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'static'

What am I doing wrong here?
[HTC Wildfire S] ONeill123:
Maybe this thread helps for the work to compile the code:

http://android-dls.com/wiki/index.php?title=Compiling_for_Android

I can't help you while compiling for android, i must learn it like u ;)
[HTC Wildfire S] island3r:
No, what I'm trying to say is that android takes no part in this at all. It's all in the hboot. The hboot has the built-in protection to disable the user to mount /system as r/w. That's why I don't think that tampering with /system is going to help us.

Also, some things I found out:

During the 2.1 days unrevoked did the s-off by "granting root access to the radio/nvram image" = permanent s-off (needless to say this has been patched)

In 2.2, Alpharev ignored the radio and flashed the patched hboot.

BUT, I'm not saying you are wrong, you might be on to something.
[HTC Wildfire S] ONeill123:
How alpharev can flash a custom hboot with s-on?

Anything know that? Maybe we can do the same with wildfire s. Then we can flash one file to update the secruity flag to s-off?!
[HTC Wildfire S] island3r:
I don't know and there isn't any documentation on it either. :(
[HTC Wildfire S] ONeill123:
hmm, then i hope, that no.human.being find a way
[HTC Wildfire S] no.human.being:
Afaik HBOOT is only a bootloader. It's a very simple and stupid program. I don't even expect it to understand what a file system permission is, so how would it enforce them? It just loads the Android kernel and gives it control. When Android boots, the code of HBOOT is not executing any more. How would it interfere with Android writing to a memory device?

I think it's different. The security flag is located somewhere in the radio. HBOOT checks it and disables certain things (like flashing unsigned ROM images) when the flag is set. Android checks it and disables other things (like writing to "/system") when the flag is set. I don't expect HBOOT to excert any control over the handset as soon as the actual operating system is booted.

Android itself can definitely write to "/system" (or rather to "/dev/block/mtdblock3", which is the device where "/system" is located), even on an S-ON device. That's how over-the-air updates are performed. It's just that there's some protection inside Android preventing you from writing to "/system" on an S-ON device. But it would be very "weird" for a POSIX system when this protection was still in place for a UID 0 (root) process. That's why I'm so after the "temproot with zergRush, then escalate further to S-OFF"-approach. You also see that "/system" is mounted as "rw" after the zergRush exploit was run. It's just that this doesn't give you anything, as the file system is probably exactly aligned in memory and any writes to it will corrupt it. You can see files suddenly disappear from the directory listing when writing to "/system" on a temprooted device.

So writing to "/system" is not the way to install custom ROM, you have to install them via HBOOT and it will only let you do when the device is S-OFF. That's why I want to S-OFF by writing to "/dev/block/mtdblock3" (which is the block device "/system" is on). You will then have a fully S-OFF phone just like if you used xtc-clip on it and can use HBOOT to install custom recovery or however you continue after you got the device S-OFF.
[HTC Wildfire S] Lt.Win:
The security flag IS somewhere in the radio. I read it somewhere, the flag is enabled, and writing to system is disabled.
[HTC Wildfire S] *se-nsei.:
But where in the radio, exactly?
[HTC Wildfire S] XDA_h3n:
Again, supertool is for virgin media. Edit: wrong place, let me look at my Desire HD radio s-off

Compare with a another HTC nand memory.
[HTC Wildfire S] no.human.being:
Don't know where it's in the radio, but it seems to be the least significant bit of the 2560th byte of "/dev/block/mtdblock3" on a stock WFS. Haven't got a way to compile the code I posted on page 12 for the device though.
[HTC Wildfire S] XDA_h3n:
Hmmm. That means we can access it with r/o access via root explorer (with temp root)? But can't we use r/w with temp root or not? Since I couldn't get round with temp root on my wfs.
[HTC Wildfire S] m1ndh4x8r:
Maybe a sim card cloner can clone xtc clip contents or does it have jumper cables to ground sim slot then goldcard will do its job. we need electronician to study xtc clip.

edit: it ain't in radio cause I have flashed new radio and it still s-off.
[HTC Wildfire S] BeciMester:
I don't mean to rain on anyone's parade, but: have you guys considered the possibility that HTC engineered those blocks like this on purpose? That they did it a non-standard way exactly so we can't do what we're planning to do?

Another thought: if Android can indeed access these blocks, it has to be in the source somewhere. Is the WFS source up on HTCdev? (Edit: it is)
[HTC Wildfire S] m1ndh4x8r:
if you want to hack soff you need some tools e.g - 1.exploit the phone admin need some open ports or holes or kill its AV, 2. some sort of md5 password cracker to get in super setting. 3. a serial key generator to make it permanent s off save and change password so nothing can make it s on. Or upload some sort of shell or a Trojan horse to run some commands upload a pic or mp3 whatever to make it s off.
[HTC Wildfire S] ctt812:
Sorry that I know nothing about programming.

I come across a thread in another forum on the production schema of the XTC clip, I post it up to see if there is of any use to you dev.

http://forum.gsmhosting.com/vbb/f83...duction-details-hex-schematic-gerber-1361027/
[HTC Wildfire S] XDA_h3n:
S-off hacking should be c+++ and adb and Linux and jtag.
[HTC Wildfire S] m1ndh4x8r:
contact zulea he is the programmer of xtc clip to make usb software.
[HTC Wildfire S] ONeill123:
I think he wouldn't help us, bc it is his money, that anyone buy xtc clip.