yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] pihug12:
I have some really silly questions :

About heavy_metal_man's dumps before/after XTC-Clip (posts #791, #822 & #823) :

we only asked him to dump mtd0, mtd1, mtd2 and mtd3. Too bad we missed the unmapped memory (which we didn't know of at this time). But what about mtd4, mtd5 and mtd6 ? I know it sounds very unlikely and I'm 99,9999% sure it's not in mtd4 (cache) and mtd5 (userdata). But can the informations in mtd6 (devlog) be interesting ?

About mstfkaratas's dump with his S-OFF phone (posts #1347, #1364 & #1372) :

was he stock S-OFF or he used the XTC-Clip ? Are we sure that the XTC-Clip flips the real secu_flag without doing the tricks we are trying to apply right now ?

I hope someone with HBOOT-1.08.0099 unlocked & RADIO-7.53.39.03M or with HBOOT-1.09.0099 unlocked & RADIO-7.54.39.28M can do a full NAND dump before/after XTC-Clip.

It would be full of win to find the real secu_flag. ♥_♥ :D
[HTC Wildfire S] BeciMester:
That lucky person would be the one wielding the JTAG, which means... erm... you. :D

Seriously though, thank you for doing this. :)
[HTC Wildfire S] theq86:
+1 exactly my thoughts :D

the jtag-guy should test.

For the sake of security: I know you guys are all waiting for this to come. And some people like BeciMester, me, the contributers of dumps and knowledge of the past 48 pages and especially no.human.being, who is the hero and protagonist of our S-OFF-Story want to deliver it to you.

But even the phone-nerds don't easily want to risk the bricking of the phone and we also want you not to end up in a brick because of our negligence.

So my idea: When the exploit is written, we should wait until nhb found out how to restore the phone via JTAG. That would enable him, if the exploit goes wrong to immediately recover his phone. I think this would be just a fair gesture.

Otherwise, if someone is really rich or has the wfs not as primary phone, that person can volunteer for testing :D
[HTC Wildfire S] mstfkaratas:
I used XTC Clip for S-OFF. I think XTC clip flips real secu_flag which is outside of nand memory. This explains why OTAs and RUUs cant revert it to S-ON, if XTC clip does its thing by changing nand memory HTC would easily patch it, because HTC has full control in nand memory by OTAs and RUUs.

Maybe Flex cable on XTC Clip is some kind of jumper which gives access to a physical write protected chip on board. Remember the write protection switches on SD-cards.

Correct me if i am wrong, theese are just my thoughts
[HTC Wildfire S] theq86:
That's possible, yes. But it's also possible , that the flag is on the NAND.

No. Neither RUUs, nor OTAs have full NAND access. (Well, not directly)

I studied the behavior of a RUU. It just sends the rom.zip to hboot, which then proceeds as if it was a PG76IMG.zip. HBOOT then gives the ruu some return values about the status.

Yes, HBOOT has full nand access, but the real reason a RUU would not affect secu_flag even it it was on NAND is: Because the radio and hboot files of a RUU do not overwrite ALL of the radio area. There are still some megabytes of code never touched by HBOOT flashing the ruu files. So it is still possible to find the flag inside the NAND.

An OTA is just an update.zip package (like those we everyday use). The reason, why an OTA needs stock recovery is, that the stock recovery is able to inform HBOOT of a file called "framework.zip" which is sent to HBOOT and is executed the same way as PG76IMG.zip and rom.zip.
[HTC Wildfire S] MrTaco505:
So there's a "working" exploit that just patches hboot?
[HTC Wildfire S] theq86:
Please, read just a couple of lines above ...

http://xdaforums.com/showpost.php?p=23206760&postcount=1423
[HTC Wildfire S] MrTaco505:
Sorry i tried removing post but didn't work
[HTC Wildfire S] seaskyways:
Hey , try that app Wireless File Explorer , through FTP you can ACCESS the WHOLE PHONE to it's tiny bit , of course not the non-mapped mtd7 , but everything is visible :D it may truely help !
[HTC Wildfire S] :
So basically we could patch HBOOT now, but it would only last until the phone is rebooted. So we're trying to make a patch that makes it permanent, and can survive HBOOT down/upgrades?

I'll consider testing, but I'll need *very* clear instructions and support throughout (in case of brick)

I sent NHB my radio dump.

---------- Post added at 05:47 PM ---------- Previous post was at 05:44 PM ----------

Aaah.... TTY......

I remember using TTY back when I was using my HTC Hermes. What commands would we use to query CID, secu_flag, SIM-lock, serial number, IMEI and other device-specific information?
[HTC Wildfire S] *se-nsei.:
Some exciting **** going on or what! Will update the op later today, PC's acting up a little. :D
[HTC Wildfire S] no.human.being:
Your Radio is extremely weird. It says 7.53.39.03M but the memory layout is clearly that of 7.54.39.28M. At least the exploit recognized that something was not the way it's supposed to be and aborted.

So seems HTC released different Radio builds with the same version number. Not sure how we shall support all that. Too much variety. :confused:
[HTC Wildfire S] mstfkaratas:
With an OTA with an updated hboot which is able to write untouched megabytes, it would be easily patched, for example adding a parameter to hboot to detect removesoff.img within rom.zip and write it to NAND. HTC loves to limit us, and they will do whatever to limit us. That is why i think secu_flag value is outside of NAND with a physical write protection.

Theese are just my guesses, so they might be wrong
[HTC Wildfire S] no.human.being:
Seems the xda forum software is freaking out. I can't quote posts. I get notifications on every click about private messages that aren't there. I'll leave it alone a bit until it settles again. :D
[HTC Wildfire S] :
Yeah. There's something wrong with mine to! LOL.

Anyway, what's wrong with my radio? I don't understand.

---------- Post added at 07:07 PM ---------- Previous post was at 07:01 PM ----------

I think there is seriously something wrong. I think XDA's been hacked!

It's acting up, and my AV detected Chrome downloading a trojan!!!!!!!!!!

We're doomed!

I think it was hacked via a ad.

One more thing!

There is something wrong with my radio dump. Windows claims it was created at 06 ‎January ‎1980, ‏‎00:05:09

Damn! HTC has spent 32 years doing this S-OFF prevention scheme!
[HTC Wildfire S] no.human.being:
Well the Radio is a "raw partition". It doesn't have a file system. It only contains the Radio code as it was produced by the linker when the Radio was built by HTC, nothing else. Think of it like "an executable file", just that it's an entire partition, not only a file. So there's only one program (the Radio) on the partition, nothing else. (Well, of course there's also HBOOT on the partition, but from the Radio's point of view HBOOT is "data", not code. :D )

Now the linker creates a memory layout, which determines which pieces of code are where. So far we have seen two different Radio versions, 7.53.39.03M (which is 50.069.504 bytes large) and 7.54.39.28M (which is 40.632.320 bytes large). They also have two very distinct "memory layouts", so the functions and data are at different places in memory.

Now your Radio, according to its version string, is 7.53.39.03M. However, it seems to be smaller than 50.069.504 bytes. Your dump is exactly 50.069.504 bytes, since that's the amount of memory we made the kernel map in, however, your Radio firmware "ends" before the end of the dump and then there's stuff that's no longer part of the Radio. Also your Radio has a memory layout like it was 7.54.39.28M, so the code and data resides at addresses like if it was a 7.54.39.28M Radio, however its version string says 7.53.39.03M. Now what should we do with it?
[HTC Wildfire S] theq86:
Of course you can reboot the phone without losing s-off. but not update hboot.

Even if an update overwrites it, we can still patch it again. HTC can not prevent us from mapping the radio.

lol, HTC is DDOS'ing xda to prevent us from ruling our phone :D
[HTC Wildfire S] MrTaco505:
I think my phone got a virus :( because my security revealed that this app was not safe and the security app closed xda. :(
[HTC Wildfire S] no.human.being:
Right, the only thing they could do is remove support for the "fastboot boot" command. I think HBOOT 0.90.0000 doesn't support it yet so we can't S-OFF the pre-1.x HBOOTs.

I don't think it's DDoS, I think the database is f***ed up. It can't quote, it shows different posts in the "Topic Review" on the "Reply to Thread" page than in the thread itself.

EDIT: Oh it might well be an attack. CyanogenMod website is completely down.
[HTC Wildfire S] theq86:
some mins ago the site was unreachable so I thought maybe a script kiddie was at work.

but may be that a forum software update was installed and now there are incompatibilities.

Even if htc would lock the boot command we still had the old versions where it works.

And I somehow doubt we see another update from HTC just for fixing an exploit 1 person found out.

What should come? ICS? Sense4? :D I think HTC has done for the Wildfire S. Especially because new phones are coming soon.

---------- Post added at 07:44 PM ---------- Previous post was at 07:29 PM ----------

It's Apple :D They try what Jobs was dreaming about - destroying Android :D
[HTC Wildfire S] no.human.being:
Well. I'm currently testing with the latest CWM v5.0.2.8 and it went not so well.

~ # dd if=/dev/mtd/mtd7 of=/sdcard/radio.img bs=2k
dd: /dev/mtd/mtd7: Invalid argument
~ # dd if=/dev/block/mtdblock7 of=/sdcard/radio.img bs=2k
dd: /dev/block/mtdblock7: I/O error
~ # cat /dev/mtd/mtd7 > /sdcard/radio.img
~ # cat /dev/block/mtdblock7 > /sdcard/radio.img
cat: read error: I/O error
~ #

So "cat" can access the mtd device (but not the mtdblock, I think the driver for the block device translation layer is simply missing from the kernel), but "dd" can't access either (I think the "dd" utility for Android is simply broken).

Well, "cat" was not actually designed for "imaging drives". I have no idea how it acts e. g. when an ECC error occurs, probably it'll just abort. So I think it might be best to build a "dd-equivalent" functionality into the exploit itself (loop that freads 2k blocks from one file descriptor into a buffer, then fwrites it on another file descriptor and moves on).
[HTC Wildfire S] theq86:
that's weird, nhb. On my phone dd'ing the radio works just fine ...

invalid argument? are you sure you did it when mtd7 was mapped?
[HTC Wildfire S] no.human.being:
Which OS image? I'm on CWM v5.0.2.8, official build from clockworkmod.com.
[HTC Wildfire S] theq86:
I have right the same. No errors. Maybe it's your radio?

---------- Post added at 08:09 PM ---------- Previous post was at 08:01 PM ----------

btw "invalid argument" is no error usually describing the content but the form. but your command is written right ...

Here mine

USERNAME@qlap:~/Android/SDK/platform-tools$ ./adb shell
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
~ # cat /proc/mtd
dev: size erasesize name
mtd0: 000a0000 00020000 "misc"
mtd1: 00500000 00020000 "recovery"
mtd2: 00340000 00020000 "boot"
mtd3: 10d60000 00020000 "system"
mtd4: 02300000 00020000 "cache"
mtd5: 09600000 00020000 "userdata"
mtd6: 00a00000 00020000 "devlog"
mtd7: 026c0000 00020000 "radio"
~ # dd if=/dev/mtd/mtd7 of=/sdcard/radio.img bs=2k
19840+0 records in
19840+0 records out
40632320 bytes (38.8MB) copied, 17.890533 seconds, 2.2MB/s
~ #
[HTC Wildfire S] no.human.being:
Yes, I thought it may be since "dd" only works on block devices and not on mtd devices, so in some sense it would be a "formal" error. It's a "formal error", even though the "spelling" is correct. However, I'm supplying a device of a type that the utility is not expecting. One could consider it "formally wrong" (like spelling the variables right in a funtion call but supplying the wrong types is still a "syntax error", even though one would not see that if one only had the function call alone and not the lines where the variables were declared).
[HTC Wildfire S] seaskyways:
Guys , don't focus on minor errors , just bypass them somehow , or just unite your project so the one having the errors give his thing to the other ... By the way , need any help ??
[HTC Wildfire S] theq86:
dd works on mtd devices, too. try to reboot, be sure mtd7 is mapped and try again. For me it works. Makes no sense it doesn't for you.

---------- Post added at 08:23 PM ---------- Previous post was at 08:22 PM ----------

in this case "bypassing" could be the source of a BIG trouble. You can not just ignore errors, not even tiny ones.
[HTC Wildfire S] seaskyways:
Cuz were playing in radios ? I can't get the true danger of playing with the hboot since it can be reflashed anyways ...
[HTC Wildfire S] BeciMester:
@nhb: do you have a chance to try different cwm versions? Do you have access to the cwm source code? These fine folks here are talking about the same problem, also using cwm I believe, there are even some code snippets in this post. I dunno if it's any help/new info to you (although I do believe I've posted this before).

Also: if there's an odd radio in someone's phone, can't you just get them to update to one of the supported versions? It's impossible to be ready for every situation that may occur.
[HTC Wildfire S] no.human.being:
It has nothing to do with the Radio, it works on none of the mtd devices. Even without kernel parameter supplied (so standard partitioning) it doesn't work on any of them.

I'm writing my own "dd" implementation. Shouldn't be too difficult. :D
[HTC Wildfire S] MrTaco505:
Anyone need help testing or something?
[HTC Wildfire S] theq86:
False!

The HBOOT is loading into the ram at boot time. Then it will take the hboot image from the ruu and flash it to the radio area. HBOOT updtes itself literaly.

If we screw the hboot or any other radio part it will not be properly loaded to RAM and will not be able to bootup the device.

---------- Post added at 08:32 PM ---------- Previous post was at 08:31 PM ----------

but WHY does it work on my phone?

It works for my raw partitions for reading and writing ... this is very strange !
[HTC Wildfire S] seaskyways:
woowww !! then the phone will be total crap ! Okay i get it now ! So , what about plan 2 , Unite ??
[HTC Wildfire S] theq86:
I think it would work if you had my recovery. Because I get the invalid argument error when I try to use a different recovery or try that on android.

http://www.mediafire.com/?e4z74rfem95hrhh
[HTC Wildfire S] seaskyways:
That's what am talkin' about man ! ;) go on guys , if you get it completed , you'll be the kings of WFS !
[HTC Wildfire S] :
How can you tell it's 50.069.504 bytes by looking at the version which is a completely different!

Bad-Wolf no understand!
[HTC Wildfire S] theq86:
great success nhb. which way you would erase the blocks first? this is extremely important. you will be able to write without deleting, but the output will be garbage :D
[HTC Wildfire S] no.human.being:
Yes, NAND (or every form of EEPROM) is not designed to be overwritten in-place and neither the memory controller itself nor the kernel-level drivers are "intelligent enough" to do the "read-modify-write" so you have to explicitely do this yourself.

I don't know how to erase pages manually via ioctl(...). The API is not really designed for use by a third-party application. The mtdutils seem to be really tightly integrated with the kernel mtd driver itself by sharing header files etc. so I'll let them do the work by calling ...

system("nand_erase radio");

... and hope that the "nand_erase" utility is doing it right. Afterwards I obviously have to write the entire Radio partition back, even though only very little is actually changed in the entire progress. :D
[HTC Wildfire S] theq86:
I hope so, too. But remember, this way you must flash the whole radio back. I believe you know that and thought about it, but I was a little confused about your patch statement where you say you will write the changes you like.
[HTC Wildfire S] no.human.being:
Yes it would be great if we could somehow be "less invasive" by only erasing certain NAND pages, but I haven't found any way yet. The kernel itself does this intensively (e. g. the yaffs2 driver does it, of course), but the APIs that are exposed are very much "internal", requiring you to link against kernel headers and object files and stuff like that. Probably not what we want. :D
[HTC Wildfire S] theq86:
I thought about using the android emulator from the sdk as a test victim. But I have the strong feeling it is too far away from the htc configuration and won't be able to give us insight if the exploit is running.

since the emulator is an x86 port I also doubt that a full arm cpu and a nand is emulated, too. so we need someone real :(

---------- Post added at 02:04 AM ---------- Previous post was at 01:52 AM ----------

btw: it must be

system("erase_image radio");
[HTC Wildfire S] no.human.being:
Yes, it was right in the code, just wrong in my post. :D
[HTC Wildfire S] theq86:
Good, otherwise this would have been the reason for a 100% brick chance :D

EDIT:

I would say we do a test run on an unimportant mtd like mtd2 (boot)

can you pass me an exploit executable that does not patch the file but only flashes an image?
[HTC Wildfire S] :
Right. Considering I've got an exotic memory map thingy and a messed up rdio, I'm gonna see if I can flash a new one. Which one shall I get NHB, 1.53 or 1.54?
[HTC Wildfire S] no.human.being:
Attached. I called it "ee". You know "dd" was originally called "cc" (carbon copy). Then for the successor utility they just incremented the letters. That's why I called it "ee" since it's so similar in concept to "dd". :D

It works fantastically, expecting two parameters, first is source, second is target. See yourself.

$ ./fastboot boot recovery-clockwork-5.0.2.8-marvel.img
downloading 'boot.img'...
OKAY [ 1.620s]
booting...
OKAY [ 0.000s]
finished. total time: 1.621s
$ ./adb push ee /ee
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
1319 KB/s (660842 bytes in 0.489s)
$ ./adb shell
~ # ls
boot etc sdcard
cache init sys
data init.rc system
datadata proc tmp
default.prop res ueventd.goldfish.rc
dev root ueventd.marvel.rc
ee sbin ueventd.rc
emmc sd-ext
~ # ./ee /dev/mtd/mtd0 test
~ # ls
boot etc sdcard
cache init sys
data init.rc system
datadata proc test
default.prop res tmp
dev root ueventd.goldfish.rc
ee sbin ueventd.marvel.rc
emmc sd-ext ueventd.rc
~ # md5sum /dev/mtd/mtd0
04bca5797de8553755027bd8981db2f0 /dev/mtd/mtd0
~ # md5sum /dev/mtd/mtd0
04bca5797de8553755027bd8981db2f0 /dev/mtd/mtd0
~ # md5sum test
04bca5797de8553755027bd8981db2f0 test
~ # rm test
~ # exit
$

EDIT: Important! The utility is really just a dd-equivalent. It does not erase. So if you want to use it for writing to the mtd, you'll have to erase_image first.
[HTC Wildfire S] theq86:
thx.

I can confirm it working on my device. I assume

./ ee $1 $2

does the following:

dump $1 to $2

(patch $2) not implemented in above test version

erase $1

flash $1 from $2

right?
[HTC Wildfire S] no.human.being:
No, as I said it's a dd-equivalent. So "./ee $1 $2" basically does what "dd if=$1 of=$2 bs=4k" would do.

Might publish the source as well. Really nothing spectacular. :D

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>

const int C_PAGE_SIZE = 4096;
const int C_B_TRUE = -1;
const int C_B_FALSE = 0;
const int C_SUCCESS = 0;

int file_exists (char* path)
{
FILE* fd;

if ((fd = fopen(path, "r")) == NULL)
return C_B_FALSE;
else
fclose(fd);

return C_B_TRUE;
}

int main (int argc, char* argv[])
{
FILE* fsrc;
FILE* fdst;

if (argc != 3)
{
printf("Usage: %s <source> <target>\n", argv[0]);
return -1;
}

if (!file_exists(argv[1]))
{
printf("[ERROR] File \'%s\' does not exist!\n", argv[1]);
}

fsrc = fopen(argv[1], "rb");
fdst = fopen(argv[2], "wb");
char* buf = (char*)malloc(C_PAGE_SIZE);
fseek(fsrc, 0, SEEK_SET);
fseek(fdst, 0, SEEK_SET);
uint32_t length = fread(buf, 1, C_PAGE_SIZE, fsrc);

do
{
fwrite(buf, length, 1, fdst);
length = fread(buf, 1, C_PAGE_SIZE, fsrc);
}
while (!feof(fsrc));

fwrite(buf, length, 1, fdst);
fflush(fdst);
free(buf);
fclose(fdst);
fclose(fsrc);
return C_SUCCESS;
}

So you can use it to dump via "./ee /dev/mtd/mtdX /sdcard/file", then you'll have to "erase_image", then you could write it back using "./ee /sdcard/file /dev/mtd/mtdX".

EDIT: Already found an error. If the file you're reading does not exist, it says "does not exist", but doesn't abort. Well. I put this together in 1 minute so just supply a source that exists. It'll be alright for what we're testing. :D The writing is the only thing we'll have to test. Erasure is done by a system utility (well, if that one's faulty then we're doomed obviously) and the patching is already extensively tested on the images.
[HTC Wildfire S] theq86:
does it have any impact to use bs=4k instead of 2k?

---------- Post added at 03:31 AM ---------- Previous post was at 03:27 AM ----------

xxx@qlap:~/Android/SDK/platform-tools$ adb shell
~ # ./ee /dev/mtd/mtd2 /sdcard/bootimage
~ # erase_image boot
~ # ./ee /sdcard/bootimage /dev/mtd/mtd2
~ # reboot

Works like a charm!
[HTC Wildfire S] no.human.being:
Don't think so. The memory in the phone itself has 2k "pages" and I think 128k "blocks" physically. The difference is that you can randomly write to any "block", but must write to the "pages" inside the same "block" sequentially (e. g. you cannot write the second page of a block if the first page in the same block has not been written yet) and when you want to modify what's already in a block, you must write the entire block again, not just the page you modified. But we're always writing sequentially, so we should be ok as long as we're writing in multiple of 2048 bytes.

I've just gone 4k since it's a "standard page size" for Linux. When I "malloc(...)" 2k, it'd probably allocate 4k internally and we probably get slightly higher throughput with larger buffers. (Not that this matters though. :D )

It's just "programmers habit". Want a page? "malloc(4096);" :-D

Great! So taking on the challenge today? Oh man, I'd love to, but I can't live without a smartphone. :D
[HTC Wildfire S] theq86:
I'd do it for the sake of science, but I'm also depending on my little companion :D

but you at least have a jtag equipment. :D
[HTC Wildfire S] no.human.being:
Yep, I don't know how to use it though. :D

We have some ARM experts at university, but it'd probably take more time to get it done this way instead of just sending it to HTC. I don't think they're going to "investigate" much when they receive a "hard brick", so they'd probably not notice what I did, or if they did they'd have a hard time proving, but of course it'd probably take too long. :D

If the Galaxy S3 was already released, this would be less of a problem, as once the S3 is out, I'll grab the predecessor. :D I expect prices for the S2 to drop dramatically with the release of the S3, after all the S2 is almost a year old. I'll definitely grab an S2 when the successor is out (AMOLED is just lovely :D ). For the moment it's just far too expensive (420 € :eek: ). However, I expect prices to drop to somewhere around the 350 € region once the S3 is out. I've paid 280 € for the WFS and it's at 170 € now. Prices just drop like crazy once that newer devices are out. But sadly, Samsung doesn't release as often as HTC does, so you'll have to wait much longer until prices drop. :D
[HTC Wildfire S] heavy_metal_man:
Good luck good sir, if all goes well we shall all remember on this day when a collection of determined people, a low budget phone and balls of steel made history and s-off the marvel!:cool::cool::cool::cool::cool:

sent from my ice cream sandwich powered HTC WILDFIRE B-)
[HTC Wildfire S] theq86:
perhaps we try first to reflash our extracted radio images. that will at least tell us that we can really flash the radio this way.

can we find a volunteer?