yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
Revolutionary does not support the MSM7227 chipset but only MSM85xx or something like that. It's the reason why we have to go through all this. There is currently no working software S-OFF for our devices. Revolutionary didn't even try, they just let some exploit for another chipset run, recognized that it failed and then gave up. These guys are completely clueless when it comes to our chipset. They have no idea what they're doing.

Does anyone know how I can create "raw" machine code (not relocatable code like ELF) using GNU assembler for ARM? I'm trying to translate some exploit code but I always get an ELF, which is not what I want. I need a literal translation of my assembly instructions into machine code.
[HTC Wildfire S] beaups:
I'm aware of that. My point is that even on old devices, like revolutionary exploited, they weren't able to just flash in place a modified hboot all by itself. And on newer devices, like HOX and Evo LTE, we know for certain you can't do it either. So it's safe to say that flashing an unsigned hboot all by itself is a dead end here. That's all I'm trying to say. You guys have some very bright people working on this, it's a shame to see all the attention focused on a known dead-end.
[HTC Wildfire S] no.human.being:
We currently try to find a way of writing to the HBOOT partition in NAND. Even if you need to do more than that, I don't think it's a dead end. I think the ability to write there could turn out to be very useful, even if it turns out that you have to do some other stuff as well. Don't you think that as well?
[HTC Wildfire S] munjeni:
No.human.being, you can use vibration to test your exploits, for example you can test vibration but first you need to find what is gpio for vibration and find his virtual adress... than you can write shell code to misc partition like iuss say and execute it by fastboot getvar mainver.

ldr r0, gpio_base_addr @ bank3_out - virtual adress in htc hd mini for vibration
ldr r1, [r0]
orr r1, r1, #0x1000000 @ vibration time
str r1, [r0]

gpio_base_addr:
.word 0xa9200808
[HTC Wildfire S] heavy_metal_man:
Time for me again :D the xtc clip does not install any new hboot, it just asks for the radio to turn off the security. Then the diag file comes into play as the device is then s-off and it runs to clean the s58 data. Which is the sim unlock and super cid. Once you are s-off running a diag file will always give sim unlock and super cid. I was once clipping a wfs and I had to restart before I could clean the s58 data and when I rebooted it was s-off. I believe that the clip sends the commands and uses its flex cable to confirm that its legit, then diag goes. After that any hboot can be fashed ect. Something to note though. In order yo enable fast boot on the wildfire afaik revolutionary had to "unlock" the hboot with another patch to enable fast boot commands. So for the buzz they were doing both a patch for the security and for the boot loader unlock ;)
[HTC Wildfire S] no.human.being:
So you think that just the presence of the engineering SIM or clip disables security and DIAG comes into play

after

Radio security was disabled? I always thought that DIAG sent a command to Radio to disable security, then Radio queried for the engineering SIM (which btw. also uses cryptography to prove it's legit) which is what the clip emulates. If what you claim is right then you should be able to S-OFF a device just by inserting the clip, but not the SD card where DIAG is on. I've never heard of that before.
[HTC Wildfire S] heavy_metal_man:
Well I think that it s-offs the device before you wipe the s58 data. At least that is what happened to me. I think it does it between jumping to diag and showing the clean s58 data.
[HTC Wildfire S] Root-Maniac:
Well if you guys get bored theres a near $1000 dollar bounty for s off in the AT&T HTC ONE X thread.. :) http://xdaforums.com/showthread.php?t=1819238
[HTC Wildfire S] Antagonist42:
That kinda make sense to me, a bit like running an EUU/RUU it isn't simply executed then flashed i'm sure certain code maybe set for booting/rebooting phone into fastboot to enable writting, it would seem that you set info into the phones 'always on' data then on reboot the data is there then you write your data and the always on data is picked up and you write the new data in.

This could make more sense of the 'it rebooted x2 or x3 times before android booted' if you got your code to take after you initially flashed it in, the always on data may change, thus data to the rest of the system may change that would require a reboot thus explaining why you have 2x or x3 reboots possibly an update to various non-user partitions
[HTC Wildfire S] gordo79:
Another challenge http://xdaforums.com/showthread.php?t=1651742
[HTC Wildfire S] csoulr666:
I always thought of putting a bounty for the wildfire S as well....... But majority of the users(including me) are underage or do not trust online payments

Bounties might bring some skilled people who are bounty hunters as well but we have what we need here
[HTC Wildfire S] artturnip:
We already have some really committed developers working on our device. :D We don't really need a bounty... do we???
[HTC Wildfire S] Antagonist42:
Doing it because we want to, doing it because we can, honestly really don't need a 'bounty' to do it either, be better off 'offering to donate' if it does get done.

Me personally, I couldn't tell you if my phone is S-ON or S-OFF (suspect it's S-ON) even so I got my teeth into it so i'm doing it in either case - Bounty - not bothered :laugh:

Besides it'll work different on other CPU as well
[HTC Wildfire S] gordo79:
Adb reboot bootloader. Will give you he info of security state, radio version and what hboot you have
[HTC Wildfire S] no.human.being:
All that an RUU does is push an "update.zip" to the phone via Fastboot. There's no magic here. The images inside the "update.zip" are signed. That's why they flash on an S-ON device.

Btw @munjenji: As you changed the Radio secu_flag your HBOOT was stock, right? You said that you couldn't flash unsigned images. Did HBOOT claim "S-OFF" when the Radio was S-OFF or did it still claim "S-ON"? This is important information, since the HBOOT we want to "chainload" will claim "S-OFF". So if there's really separate flags for HBOOT and Radio, our "chainloaded" variation will certainly disregard the one concerning HBOOT.

Did anyone read this question, as this is where I'm stuck:
[HTC Wildfire S] iuss:
arm-eabi-gcc -nostdlib -Ttext=0xLOADADDR -ocode code.s
arm-eabi-objcopy -Obinary code code.bin

You could start even simpler than vibration.

- Jump to 0x0, it should reboot to Android; then try an infinite loop..

- Find set_bootmode and call set_bootmode(2), reboot -> reboot to bootloader.

- Then add actual payload.

Pack your payload in an Android image or use the exploit (but it might very well be fixed).
[HTC Wildfire S] munjeni:
Ideal exploitable thing is version string located in misc partition... I will play with this for sure for future devices, now I understand better that before how to exploit something :) ... proncipe is not so hard as I thinked, just we need to disasemble hboot, to find memory addresess where hboot runing, than to find interested functions that will be used for exploit and finally create exploit code...
[HTC Wildfire S] no.human.being:
I assume you mean "arm-none-eabi-as" and "arm-none-eabi-objcopy". The "arm-none-eabi-" is the cross compiling toolchain prefix and "as" and "objcopy" are the respective utilities. The former ("as") doesn't seem to have options like "-nostdlib" and "-T" though.

Iirc, the kernel code in the boot image gets loaded to 0x12c08000. The second stage bootloader gets loaded to 0x13b00000, the initrd to 0x13c00000 (and kernel tags to 0x12c00100 - what's that btw?). So it seems that we're allowed to put up to 15.695.872 bytes of code into the "kernel" itself, which is actually quite a lot. If we exceed this amount, we will overwrite the second stage bootloader in memory, which may or may not be allowed. But like I said, it's quite a lot.
[HTC Wildfire S] iuss:
You can specify the load addresses in the boot image, can't you?
[HTC Wildfire S] no.human.being:
Yes. But there is a special "mkbootimg_wfs" ("make boot image for wildfire s") utility that's a variation of the standard "mkbootimg" utility from the Android SDK and this has these addresses hardcoded. And there is a reason that there is this special utility. The standard "mkbootimg"-images that the Android SDK generates use other addresses and "for some reason" didn't work, thus this special utility was created for the Wildfire S. I don't know what was the problem with the images created by the Android SDK utility though but it was something load-address related. Perhaps alquez can tell us what the problem was, since he's probably the most advanced kernel dev for the WFS. Until we know for sure I'll let the kernel load to 0x12c08000 just in case. I don't think you can load it "anywhere" since some memory addresses are probably reserved on the MSM7227 for memory mapped I/O and stuff.

See here. Pther found it out and built the utility.

Still don't know how you generate raw code from assembly though. "arm-none-eabi-as" doesn't have options like "-nostdlib" and "-T" and when you just supply it with a source file, it will generate an ELF with relocatable code.
[HTC Wildfire S] iuss:
That's correct. Then use objcopy to copy just the code (see my initial post, edited it).
[HTC Wildfire S] no.human.being:
Thanks, could you tell me why you use "gcc" and not "as"?
[HTC Wildfire S] iuss:
Plain 'as' should be fine for simple shellcode, gcc enables preprocessor macros and some silly optimisations (single-intruction far branches if the .text base is specified, instead of a 'ldr r3, f_addr; blx r3'.

tl;dr you're probably fine with just 'as'.
[HTC Wildfire S] no.human.being:
I currently have a binary called "jump_hboot.bin" that is 4 bytes (one instruction) long for testing and just sets program counter to zero. This is the disassembly by "arm-none-eabi-objdump":

0:	e3a0f000	mov	pc, #0

Then I build a boot image out of that together with an "empty" (0 byte) ramdisk.

./mkbootimg_wfs --kernel jump_hboot.bin --ramdisk empty --board marvel -o jump_hboot.img
./fastboot boot jump_hboot.img

Locks up the device. Display shows HTC logo. Boot procedure doesn't continue. Can only pull the battery out.
[HTC Wildfire S] munjeni:
Yes hboot was stock and yes I tried allso with htcdev unlocked hboot and allso relocked hboot... still no way to flash unsigned...

I allready said that s-off is confirmed that is the true s-off (at@simlock?aa said 0... fastboot getvar said security off...etc, but can not flash unsigned...

Hboot not looking for radio "s-flag" (I can tested it and I can confirm that!)... there must be another flag in nand that hboot read !

---------- Post added at 06:53 PM ---------- Previous post was at 06:51 PM ----------

you forgot to set --base ?
[HTC Wildfire S] no.human.being:
No it's not the "mkbootimg" from the Android SDK. It's "mkbootimg_wfs" from xda-member "pther". It has all addresses for the Wildfire S hardcoded.

You cannot get the addresses right with the "stock mkbootimg" from Android SDK, because you can only set a "base" and "mkbootimg" will "align" the segments around that base address. However, WFS requires a different "delta" between the segments, so no matter what "base" you supply to the "stock mkbootimg", you will never get them right. This is why pther created a "fork" of "mkbootimg" called "mkbootimg_wfs" and this one has all addresses hardcoded. I don't think that this makes a difference if you just want to load "simple code" (not a complete kernel with initrd) but it shouldn't do much harm either.

The values are as follows:

kernel_addr: 0x12c08000
ramdisk_addr: 0x13c00000
second_addr: 0x13b00000
tags_addr: 0x12c00100

I cannot verify those (could only compare them to what, say, Alquez CM kernel uses) I hope that the utility is correct. However, since all the test code currently does is set program counter to zero, it should be quite location-independant, don't you think? :D
[HTC Wildfire S] munjeni:
try to add "emty data to the begining of your shell code, for example add 0xff datas with len 0x7fff than add you code to 0x8000... maybe because kernel_addr = 0x12c08000
[HTC Wildfire S] no.human.being:
But kernel_addr means HBOOT should start writing the kernel beginning at 0x12c08000, doesn't it?
[HTC Wildfire S] munjeni:
Uh sorry, yes you are right, hboot write it to 0x12c00000, but try, why not?
[HTC Wildfire S] no.human.being:
HBOOT should write it to 0x12c08000 (at least that where I request it to write) not 0x12c00000. However, when I prefix my code with 0x8000 bytes of zeroes, then load this via Fastboot it shows "HTC" logo, turns display off, turns display on, shows "HTC" logo a second time, then boots into ROM. Now it gets interesting. :D

Now I'm gonna build an infinite loop by jumping to "self" instead of jumping to zero, of course with code also with starting at 0x8000 offset and check if that locks the device up. If not, then we're causing some "fault" which initiates a fresh reboot from NAND. If it does lock up, I think we got it.

Ok, "mov pc, #0" (jump to HBOOT) shows HTC screen twice, then boots into ROM and "sub pc, pc #4" (infinite loop - didn't know how to do a program counter relative branch) locks up. So I think we're almost there. We must prefix our exploit code with 0x8000 (= 32.768) bytes of "junk". I'm currently using zeroes, however no ops would be nice since the instruction pointer would "slide down" when hitting on them. I will now work on the "useful" exploit code that serves to load arbitrary shell code to zero physical, overwriting HBOOT in place, then branches into it.
[HTC Wildfire S] artturnip:
Wait! So are we hopefully there now? :D
[HTC Wildfire S] no.human.being:
Removed.
[HTC Wildfire S] ONeill123:
The compiled code hasn't got an extension. Delete the ".apk"

Then push to your phone:

adb push downloaded-file /data/local/tmp

Then enter shell:

adb shell

Chmod file

chmod 755 /data/local/tmp/*

Then run the script

/data/local/tmp/download-file

I can try it today evening maybe, but its dangerous!
[HTC Wildfire S] pihug12:
According to no.human.being, it's not read-only. He explained it very well and I agree with him :

_____________________________________________

That's what I thought. I just added an extension to be able to attach it with my post on this vBulletin forum.

I don't know what an apk file is exactely. Is it always an installer ?

I suggest you to not run the full script. If you want to make some tests, compile only the step 1 and 2 (the dumping and the patching). Then, if it works, post the "dump.img" and "patch.img" here. I think this can be done safely.

Then, we can see if we can apply step 3 (the writing to NAND) or not.

If I'm not mistaken, the patch proposed by no.human.being is based on the changes that are done on another HTC device (the Desire ?) while S-OFFing. Maybe the offsets aren't the same on the Wildfire S. Then it would be significantly more difficult...
[HTC Wildfire S] mansmith:
/*
* 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);

I tried the first part of the code. I tried only to dump the mtdblock3, but it gave me a file filed with yyyyyyy.... (so probbably nothing was read from the device)

So I reprogrammed the code to get some more error messages to find the problem. I came up with the following:

/*
* S-OFF for HTC Wildfire S
* To be applied after temprooting the device via zergRush exploit
*/
#include <stdio.h>
#include <stdlib.h>

// number of chars to read into memory
#define BLOCKSIZE 5120	// 10 * 1024 bytes / 2 = number of chars

int main () {
FILE* fdRead = NULL;
FILE* fdWrite = NULL;
long lSize = 0;
char* buffer;
size_t rresult;
size_t wresult;

// open files
fdRead = fopen ( "/dev/block/mtdblock3" , "rb" );
if (fdRead==NULL) {fputs ("Unable to open /dev/block/mtdblock3 device.",stderr); exit (1);}
fdWrite = fopen("/sdcard/dump_mtdblock3.img", "wb");
if (fdWrite==NULL) {fputs ("Unable to open /sdcard/dump_mtdblock3.img file.",stderr); exit (1);}

// obtain file size:
fseek (fdRead , 0 , SEEK_END);
lSize = ftell (fdRead);
rewind (fdRead);
printf("Size of mtdblock3: %i Mb\n", (lSize * 2 / 1024 / 1024) );

// allocate memory to contain blocksize chunk of file:
buffer = (char*) malloc (sizeof(char) * BLOCKSIZE);
if (buffer == NULL) {fputs ("Memory error",stderr); exit (2);}

// copy the file into the buffer:
rresult = fread (buffer,sizeof(char),BLOCKSIZE - 1,fdRead);
printf("%f bytes read to memory\n", rresult);
while(BLOCKSIZE == rresult)
{
rresult = fread (buffer,sizeof(char),BLOCKSIZE,fdRead);
printf("%d Kb read to memory", (rresult / 1024));
wresult = fwrite(buffer,sizeof(char),BLOCKSIZE,fdWrite);
printf("%d Kb written to memory", (wresult / 1024));
}

/* the whole file is now loaded in the memory buffer. */
printf("Whole file written!\n");
// terminate
fclose (fdRead);
fclose (fdWrite);
free(buffer);
return 0;
}

This gave me the correct size of the rom memory(512mb). It however did not read anything from it. The rresult I got back from the first fread contained a zero, so zero bytes were read.

It seems that it is possible to open the blockdevice, but not read from it.

PS: I compiled the with program with the CodeSourcery toolchain.
[HTC Wildfire S] pihug12:
Nice attempt ! The result is very weird. :confused:

Could it be because of the zergRush exploit ? Maybe it isn't fully compatible with the Wildfire S. It's so strange we can't read it byte by byte.

ieftm already tried an attempt with this device and gave it up (in June/July). He already adapted his exploit for new devices. If you can confirm zergRush could be in cause (it's just the only supposition I have ATM), maybe we should try to contact him again and show him these last posts (on irc.freenode.net #alpharevx).

This idea could be all wrong, but with my rookie skills, I don't see other explanations. Wait for an expert opinion (mansmith or no.human.being) before annoying him.
[HTC Wildfire S] Tectas:
An apk got nothing to do with an installer, the installation is done from the android system if it's not present, the apk is not much more then a zip file containing a AndroidManifest.xml file, a rsa key and a set of .dex, resource and maybe also .so files.

A .dex is a for dalvik compiled (or costumized) .java file (a .java file is a .class file that is compiled for the javavm [a .class file is a textfile that contains the java code]), the resources i think i don't have to explain and .so files are compiled c/c++ shared libraries (that means compiled .c or .cpp files) that can be used using jni (java native interface) at a java class.
[HTC Wildfire S] island3r:
I still don't understand why you are waiting for a script to dump the /system partition. There are many ways to dump it yourselves, do the "patching" and reflash it on top of the old one.

Not that I believe patching anything in the /system partition will disable security but anyway. Any try is welcome.
[HTC Wildfire S] mansmith:
I don't think it is because of the Zergrush exploit, although it may be possible. I don't know how the exploit escalates into root.

I think that the bootloader checks the security flag and restricts writing to the nand memory and somehow tells the OS that it is S-ON(probably through the filesystem driver). But this is just speculation, not sure if it really is setup like that.

The /dev/block/mtdblock3 contains the whole rom image. If we can dump it, patch some bytes in it and dump it back, it is should be possible to get s-off.

If you know a way to dump the block device, not the /system folder, you can make me very happy.
[HTC Wildfire S] ONeill123:
maybe anyone can compile the three steps, step by step in a whole file, so we become

step1

step2

step3

and then we can see, if the steps work or not, like anybody said in this post:

http://xdaforums.com/showthread.php?t=1374926&page=28
[HTC Wildfire S] no.human.being:
We're not exactly willing to dump "/system", but "/dev/block/mtdblock3", which is the device which is mounted as "/system" on the file system layer. This must not neccessarily be the correct device, it was actually more of an educated guess. Like I said, it could actually be any of the "mtdblock*" devices, but "mtdblock3" seems most likely, so I started with this one. The offsets and values for the "patch" are from the Desire S and CID, SIM-Lock and secu_flag are all located on partition 7 (!!) on this phone, but the Wildfire S doesn't have the same partition layout as the Desire S. It doesn't have a partition 7, it just has 0 to 6, so we'll probably have to find the equivalent to the Desire S partition 7 on the Wildfire S and my guess was that it's partition 3.

However, make sure you understand the difference between raw access on the block device level ("/dev/block/mtdblock3") and access on the file system level ("/system"). They are actually quite different. The secu_flag is probably not part of a file, but floating around somewhere in "unallocated space", so writing on the file system level won't help. It will actually corrput the file system, as it seems to be exactly aligned in memory and the file system driver will probably write to different blocks when performing changes to a file as it is NAND memory and the file system attempts to spread out writes over the entire address range to prevent some blocks to be written more often than others, preventing them from failing early. That's we we've gone one step deeper and try to do the patching on the block device layer.

Even though the partition layout of the WFS and the DS are different, I'd expect the partition's inner structure to be very similar, so I assumed that only the partition number was different, but the offsets are the same as with the DS. This is quite a strong assumption, which may or may not be true. Anyways, we'll most likely need to get access to one of these devices for obtaining S-OFF and I think if we manage to read/write from/to any one of them, we'll also manage to read/write from/to the others so opening "mtdblock3" and actually reading from it would be a big step forward in our quest for S-OFF.
[HTC Wildfire S] island3r:
Well then prepare to be happy because if you issue a "df -a" command in adb you can clearly see that mtdblock3 is mounted on /system.

@no.human.being

The only why I can't think of is the dd comand, but sadly the dd version included in the busybox lacks the nessecary options to perform the task. That's why you get I/O errors.
[HTC Wildfire S] mansmith:
If we are able to dump the partition 3 from the WFS and partition 7 from the DS (both S-ON), we could compare the data at the mentioned offsets. If for the SIM-LOCK and secu_flag these are the same. It maybe be that the offsets are correct. (Or it maybe coincidence.) However if the data is different, we know that the offsets are wrong for the WFS.
[HTC Wildfire S] *se-nsei.:
woooaahh, so much going on today.

will try update campaign post when I get a bit of time !
[HTC Wildfire S] XDA_h3n:
I know, Sooo much :rolleyes:

I'm still searching out for any places which HTC forgot to patch up. So far nothing :mad:
[HTC Wildfire S] ONeill123:
I have dump my mtdblock3, but at the offset 0x00000a0

Are only yyyyyy

I think the secruity flag isn't saced there. Maybe we need someone with xtc s-off and see the differents, or someone can say where the flag is.
[HTC Wildfire S] mansmith:
Could you also take a look at the rest of the dump? For me it were all yyyyy's. So the dump wasn't succesful for me.
[HTC Wildfire S] ONeill123:
After many lines with yyyyyy comes another text, but i can't interpret and to upload is too big, i must wait a long time, i will try it tommorow, if anyone can say me what i must search, i will do.