yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
Of course I could do the math, but I probably won't be able to respond soon enough. Don't forget that I'm currently employed and not supposed to spend my time at work doing Android hacking stuff and/or checking communities about that topic. :D

And I really really hope that you have permission to do this from the owner of the phone. Don't forget that the Radio firmware does contain identifying information. I'm not liable should you distribute other people's personal data on the internet without their permission.
[HTC Wildfire S] heavy_metal_man:
I have their permission. And all going well I will only distribute you. Or any other you recommend via pm.

Well all going well I will upload the cat /proc/mtd info and then try to do the math myself and see if we come up with the same :D
[HTC Wildfire S] *se-nsei.:
OP updated to attract more help/advice. :) Best of luck, will stay more tuned.
[HTC Wildfire S] heavy_metal_man:
OK here we go. Let me know if and when you come up with anything pal

:D off to work :cool:
[HTC Wildfire S] no.human.being:
Topic is not so good. At the moment we're actually down at the electrical level. What would come in handy would be electrical engineers who can design and build circuits e. g. for level-shifting (or tell us that we're wrong and this is not the problem :D ) and test them (yes, we've actually come THAT low) and/or developers/testers for embedded systems that have experience with JTAG and OpenOCD (they use this for programming, debugging and boundary scanning). I'm afraid the number of people contributing will become very very low soon. :D

Btw, has theq86 left this community? Haven't seen him posting for a while.
[HTC Wildfire S] heavy_metal_man:
Would it be possible to dump the whole nand in one if we issued the fastboot command to tell the phone the whole nand was one mtd?? Would it be worth it?
[HTC Wildfire S] no.human.being:
I'm quite certain that it is possible. Just add "0x20000000@0x00000000(entire)" in the end instead of the addresses for Radio partition. I don't think that the kernel checks that the partitions don't overlap (although I haven't tried yet). However, you will still have to figure out the partitioning since CWM won't be able to operate without mtd0 - mtd6 mapped.

No it won't be worth it. Obviously the visible partitions (especially "userdata", but possibly also "cache" and "devlog") will contain very sensitive data (browser cache, history, phonebook, call history, SMS and e-mail messages, WLAN keys, account data, etc.). It may even contain sensitive data after the data has been "cleared", since this will probably only remove the file system information but leave the actual data intact until blocks are "reclaimed" by the file system.

Only thing that might be interesting (and will quite certainly not contain any sensitive information) is mtd0 ("misc") since some low-level and security-relevant information is stored here, but we already have "misc" dumps from a phone before and after xtc-clipping and know that the first 32 or 64 bit (not sure anymore) will be erased (changed to 0xff) by the clip software, but that's not what turns the phone S-OFF (or is it? has anyone tried? :D ).
[HTC Wildfire S] heavy_metal_man:
Btw nbh, my window Of opportunity will be at 2.30 am British time. Would that give you enough time. I know your in work, don't put yourself into a right situation like. Just hoping you could manage it :D worst come to worst could I use the other pre made command? It cannot be that different surely?!
[HTC Wildfire S] heavy_metal_man:
Also, if that deletes the first 32bit will u have to reunlock the bootloader to do fastboot commands again?
[HTC Wildfire S] pihug12:
I wrote a small tool for Windows some time ago that does the maths. I never finished it, but I see it can be useful today, so here it is.

Just edit the proc_mtd.txt file with the infos of your phone. Keep it in the same folder of the mtd_layout_v0.01.exe executable.

Launch the program and keep the "512 MB" value in the beginning.
[HTC Wildfire S] :
Hey guys ive been working on the ATT HTC One X S-off and i found some interesting things. What if its not the kernel that isnt letting us write our new hboot but the hardware itself. For instance the one x is a emmc phone so you use dd. we dd'd the partition with the soff flag and got 0 in 0 out meaning it didnt write. We preform a hardware level glitch and then it managed to write to that partition. (But still it was over written on boot by even more security) So basicly my idea is, what if it really isnt the kernel what if it is the hardware. If someone is OOW here, can they disassemble the phone entirely and take and post pictures of the insides, the board ect all in high res of course. Someone may find the jumpers that you can short out to allow writeing to protected partitions. And if you can do that, you may as well do true radio soff so that you can be perminately radio soff. I dont think anyone has mentioned this, and i just kind of found all this out with my work on the one x
[HTC Wildfire S] :
What's OOW? And I don't think shorting out the board will help. I once shorted out my RAM, and then my motherboard was dead...... I fixed it eventually, but it was scary.

Sent from my TARDIS
[HTC Wildfire S] :
Its like the soff exploit ... um jumpnobear ? i think thats the name. Its one of the only times you want to short out the phone. And OOW means Out Of Warranty
[HTC Wildfire S] no.human.being:
It is

never

actually hardware, but it might be lower-level firmware. There is a lot of processor-specific firmware from ARM Ltd. and Qualcomm that's running "beneath" us and that might do all sorts of stuff. It cannot be a hardware write protection since HBOOT can write to the Radio area when installing an RUU and the DIAG tool can write to the Radio area to S-OFF a phone when used with an xtc-clip. Both HBOOT and the DIAG tool run on the aARM (ARM11 / applications) processor so if HBOOT can do it, a kernel can do it as well. It's just that an Android kernel won't do it, since it never needs to do it and all sorts of stuff (say "authenticating" to the Radio for disabling the protection) is missing from it. I think that msm_proc_comm is the key to software S-OFF.

I'm certainly OOW since I've completely disassembled the phone and grinded the insulation off the traces on the circuit board to establish a JTAG connection. I think more OOW is impossible. :D

The problem is that on the board of the WFS (every WFS or just some? if just some then we could try finding a person that has one where this is not the case) there is thick opaque insulating coating over the area where the JTAG traces are. I needed to penetrate this insulation in order to establish a JTAG connection, but I did only pierce it enough to get an electrical contact. I'm not actually willing to take all of it off. I'm afraid that I might damage some traces in the process or that the traces will corrode over time when exposed to the oxygen in the air.

OOW = out of warrenty.

This looks exactly like the page tables in top of this post so take the first of the two kernel command lines.

mtdparts=msm_nand:0x000a0000@0x1ff60000(misc),0x00500000@0x026c0000(recovery),0x00340000@0x02bc0000(boot),0x10d60000@0x02f00000(system),0x02300000@0x13c60000(cache),0x09600000@0x16960000(userdata),0x00a00000@0x15f60000(devlog),0x026c0000@0x00000000(radio)

So in entirety this will be something like ...

./fastboot boot -c "mtdparts=msm_nand:0x000a0000@0x1ff60000(misc),0x00500000@0x026c0000(recovery),0x00340000@0x02bc0000(boot),0x10d60000@0x02f00000(system),0x02300000@0x13c60000(cache),0x09600000@0x16960000(userdata),0x00a00000@0x15f60000(devlog),0x026c0000@0x00000000(radio)" recovery.img

... considering "recovery.img" is an image of CWM recovery that lies in the same folder as the Fastboot utility.

After you have booted CWM recovery with this command line, mount the SD card on the phone, then connect via adb.

./adb shell

Verify that "mtd7" is mapped using.

cat /proc/mtd

Execute the following command on the device.

cat /dev/mtd/mtd7 > /sdcard/radio_s-on.img

This will dump the Radio to a file on the SD card. Now shut down the phone from within CWM, S-OFF the phone using xtc-clip, then boot into CWM with the custom Fastboot command line again, establish adb shell session, then enter.

cat /dev/mtd/mtd7 > /sdcard/radio_s-off.img

Then you will have a Radio dump of the phone before and after applying the xtc-clip on its SD card. It'll be really interesting what will have changed.
[HTC Wildfire S] heavy_metal_man:
OK so I've talked with my friend and she is uncomfortable with us trying to do all of this within a half hour period. So we are going to do it when she comes back from holiday (she leaves today after work ffs) but when she is back we do it Nd I will post up my results. I will dump the misc as well just for the interest. Gutted it won't be tonight but its her device.:rolleyes: sorry guys no today.
[HTC Wildfire S] w()$k:
Anybody try to dump original recovery and research how it unlock nand for write new firmware?
[HTC Wildfire S] theq86:
atm my work is eating a lot of my resources. and since we are now on a level where my experience ends (jtag and electrical stuff) I saw no sense to spam around :D

But I'm alive and reading here ;D

---------- Post added at 12:28 PM ---------- Previous post was at 12:24 PM ----------

First bytes of misc are for something called BackupCID (and also this is the cid which is checked by a ruu)

---------- Post added at 12:30 PM ---------- Previous post was at 12:28 PM ----------

No, the unlock state information is beyond 64 bit offset from the start

---------- Post added at 12:36 PM ---------- Previous post was at 12:30 PM ----------

stock recovery is able to pass a firmware.zip to hboot, which treats it as an PG76IMG.zip.

the recovery itself does not unlock whole nand ti be writeable.

some time ago I found out that the /system write protection is on the kernel/filesystem layer of a live android os. but in recovery softwares like stock or cwm, /system and others are not write protected.

All major security comes from hboot.
[HTC Wildfire S] no.human.being:
Yes and this is the fact that we should always keep in mind. I think it's the weakest point in the system we've come across so far. All major security (in the sense of cryptography) comes from HBOOT and HBOOT is running on aARM and on aARM we can execute custom code via Fastboot. Radio is running on mARM and all that it sees is aARM talking to it via RPC, but it has no way to reliably determine if it is HBOOT that is executing on aARM or some other software that is immitating it.

In this sense, software running on aARM cannot be "reliably authenticated" by the Radio, since, as far as I understand, mARM cannot directly read aARMs memory and any authentication performed by an "official" HBOOT can be faked by custom system-level code running on aARM. Even if say Radio generates a random key, sends it to HBOOT on the aARM and asks it to calculate an HMAC (the symmetric-key equivalent of a signature) of its own code, our code that's "impersonating" HBOOT could just calculate the HMAC over a known valid HBOOT image instead of its own code and return that. How will the Radio know that the HMAC is actually generated from the code executing on aARM?

It's easy to see that, without looking into aARMs memory, the Radio, running on mARM, has no way of knowing whether the software running on aARM is authentic or not. This is the major weak point in the system and it's what we should exploit. Remember that the Radio is the piece of firmware that is actually in control of, say, memoy protection (mARM can actually access the I/O, aARM cannot, it can only communicate with mARM), but it relies on HBOOT (running on aARM) to do the decisions.
[HTC Wildfire S] munjeni:
Any one tried to port:

- lk bootloader to android phone (its for wince devices only now, its ussed for boot android from nand, have its own fastboot, ussed for switching between boot, boot-recovery, fastboot mode, and its sucesfully ported to htc hd mini !!! Thanks sp3dev !) -> https://gitorious.org/lk-bootloader-photon/lk-bootloader-photon

- jumpspl to android phone (thats for loading htc hd mini patched spl into memory and execute it from memory) -> https://gitorious.org/jumpspl-photon

Maybe you can load patched hboot like we load patched spl? I tried to port but fail to port some parts of code because these parts of code is only for windowsCe and not for android, but I think some one with programing skills can port it from wince to android! Allso I have an kernel module in my kernel for loading an boot code (maybe you can port it to boot hboot?) -> https://gitorious.org/ics-cyanogenm...aria/ics/trees/master/drivers/staging/splboot
[HTC Wildfire S] no.human.being:
I'd try porting UBOOT to our chipset in the long run and have it load Android to get entirely rid of HBOOT, but it's for after we broke the security on the phone. For now I'd suggest loading patched HBOOT via JTAG and later "chainloading" it via Fastboot form within the "stock" HBOOT. Once the patched HBOOT is chainloaded, we can make it permanent via some "fastboot flash hboot hboot.img", since the patched HBOOT will have signature verification disabled.

But one step after the other. First I'd like to load a patched HBOOT into RAM via JTAG, then make it permanent via Fastboot and verify that this all works. And then we can focus on "wrapping" that image up so that it can be chainloaded by a stock HBOOT. The latter will only be a "logistic" problem. Finding out how we can wrap the code so that it gets loaded to the correct addresses and executed. And I think the on-chip debugging capability will be very very useful in this step, so let's get that working first.
[HTC Wildfire S] munjeni:
Ok, but jumpspl we used to load patched spl from ram, so I had idea to post you link to jumpspl code that is used for htc hd mini. Jumpspl is tiny part of code ported from haret. I think splboot kernel module have the same way like jumpspl have, so you can try one of these 3 links to run your hboot from ram...

---------- Post added at 12:51 PM ---------- Previous post was at 12:17 PM ----------

Any one dumped ram memory? Spl on wince device (htc hd mini) runing in ram at 0x0 adsresse... any one tried to find where hboot runing?
[HTC Wildfire S] no.human.being:
I think RAM is inaccessible when Android is booted because it is a POSIX-compliant operating system and as such makes use of memory virtualization. Each process has the illusion of being loaded to the same memory address and having the entire address space for its own use.

In addition, RAM content will change very rapidly, so if you tried dumping it while the system is running, most of it will already have changed. Therefore only chance of dumping RAM is putting the processor in debug mode, which halts execution, then dump RAM via JTAG. Of course the contents will heavily depend on the time when halting occurs, as processes and libraries may be loaded by demand and swapped in and out by the operating system over time and so on.
[HTC Wildfire S] munjeni:
I'm not surre if it is possible in android, but we dumped memory under wince with pmemdump (I'm not surre if we done it by pmemdump or by haret memdump) ... see source -> http://nah6.com/~itsme/cvs-xdadevtools/itsutils/src/

Hey, inderested functions for nand that is still in msm_nand.c but commented... (nand_get_lock_status, nand_lock, nand_unlock) ... found it in u-boot :eek: -> http://git.denx.de/?p=u-boot/u-boot...c;hb=613913fbe2827d16a351fbeef56a9c23f83efb16
[HTC Wildfire S] Tera Tike:
After I XTC-clip my device the BackupCID was deleted, not sure it that info is help full.

I also have a question about two of the RUU flash files; tp_MAL_CYP340G15.img and tp_MAL_HM8526A0A.img. Since I have S-off I have flashed the newer HBoot(hboot_1.08.0000_7c2ddb69cf.nb0) and the other files in the RUU PG76IMG.zip and noticed that the tp_MAL_HM8526A0A.img file is not used. Has anyone noticed if this file is used on a S-On phone? The other file tp_MAL_CYP340G15.img does update but what is it updating??
[HTC Wildfire S] mstfkaratas:
These files are touchpanel related, i think tp_MAL_CYP340G15.img for touch screen calibration data but i don't know what tp_MAL_HM8526A0A.img updates
[HTC Wildfire S] theq86:
one may be the calibration, the other may contain touchpanel firmware updates (since they have their own firmware)
[HTC Wildfire S] Tera Tike:
Thank you for the information!

If the tp_MAL_CYP340G15.img is a firmware update could it be the reason the CWM is no longer working the newer phones?
[HTC Wildfire S] kalaker:
Not to be off-topic or rude, but whatever happened to the guy who made maybe 5 posts here and promised a miracle S-OFF? Have we heard back from him?
[HTC Wildfire S] theq86:
No. He was stating he would need a month or so. But I did not take him serious by the beginning. too much "promises" and too less real effort ;-)
[HTC Wildfire S] *se-nsei.:
Not that easy. This challenge is difficult to comprehend. :p
[HTC Wildfire S] :
You mean paul.robo? His account was disabled. Probably because of his rage symptoms. He's also having spine surgery. He did however make an S-OFF exploit. It fixed a WFS, but you need to buy a USB to flex cable. You connect to the software and the phone, the software does it's stuff, and you have S-OFF..... Any questions?

Sent from my TARDIS
[HTC Wildfire S] csoulr666:
I have one....... there was this other guy who promised an S-off...... I think his name was "broken worm" or something like that..... do you have some news on him...... he outlined the fine he got for hacking some digital receiver keys.....
[HTC Wildfire S] kalaker:
I don't remember his time. I remember that he said he'll need about a month, but hasn't it been about that long? I'll look back a few pages (well, a few meaning 30-50 or more) to see if I can find his name.

Edit: Bad-Wolf was correct. I was talking about paul.robo. And as he said, his account is disabled so we probably won't be hearing from him for awhile.
[HTC Wildfire S] munjeni:
I will s-off wildfire with clonkenkunted doftenhanzle :D soon... hehe I'm kidding :) ... its not so simple so I think that guy 'only" thinked that he will do it, but after truing something he know allso that its not easy as he thinked?
[HTC Wildfire S] :
Well actually, his idea of S-OFF was simple, because we were taking different approaches on how to do it.

Sent from my TARDIS
[HTC Wildfire S] kalaker:
I don't know if this helps, but I did fastboot oem listpartition 1 and the output was:

(This is from Marvelc so...)

$ fastboot oem listpartition 1
...
(bootloader) [radio]:(OTHER, 0) block start=0, size=181 (0 KB)
(bootloader) [hboot]:(RAW, 0) block start=181, size=5 (1280 KB)
(bootloader) [mfg]:(RAW, 0) block start=186, size=4 (1024 KB)
(bootloader) [sp1]:(RAW, 0) block start=190, size=5 (1280 KB)
(bootloader) [wifi]:(RAW, 0) block start=195, size=5 (1280 KB)
(bootloader) [recovery]:(RAW, 0) block start=200, size=20 (5120 KB)
(bootloader) [boot]:(RAW, 0) block start=220, size=13 (3328 KB)
(bootloader) [system]:(YAFFS, 0) block start=233, size=1051 (277464 KB)
(bootloader) [cache]:(YAFFS, 0) block start=1284, size=140 (36960 KB)
(bootloader) [devlog]:(YAFFS, 0) block start=1424, size=20 (5280 KB)
(bootloader) [userdata]:(YAFFS, 0) block start=1444, size=600 (158400 KB)
(bootloader) [misc]:(RAW, 0) block start=2044, size=4 (1024 KB)
(bootloader) [cpld]:(OTHER, 0) block start=0, size=0 (0 KB)
(bootloader) [microp]:(OTHER, 0) block start=0, size=0 (0 KB)
(bootloader) [rcdata]:(OTHER, 0) block start=0, size=0 (0 KB)
(bootloader) [tp]:(OTHER, 0) block start=0, size=0 (0 KB)
(bootloader) [nv]:(OTHER, 0) block start=0, size=0 (0 KB)
OKAY [ 0.101s]
finished. total time: 0.101s
[HTC Wildfire S] kalaker:
Hey now, let's be a little nicer. He's just trying to get his 10 posts so he can post in the dev section and make off-topic posts there, too!

(That was sarcasm, by the way. It's hard to detect on the interwebz.)
[HTC Wildfire S] benjamingwynn:
Haha your post is pretty upset :D

Edit: almost forgot, if you need any tests for me to run on my phone I'm quite happy to do them. My phone is S-OFF via xtc clip ;)
[HTC Wildfire S] davidang:
look like u have xtc clip,can u loan it to me?????:D:D:D:D:D:D:D:D:D:D:D
[HTC Wildfire S] munjeni:
Check secuflag in htc aria hboot:

sub_3F2C0	; CODE XREF: sub_4363C+4p

var_4	= -4

STR	R4, [SP,#var_4]!
LDR	R3, =0x9D080B24
LDR	R4, [R3]
ADD	R4, R4,	#0xFC000
ADD	R4, R4,	#0xE0
LDR	R0, [R4]
LDMFD	SP!, {R4}
BX	LR
; End of function sub_3F2C0

should be (maybe?) readable kernel side:

static int check_security(void)
{
unsigned *pa;

pa=ioremap((0x9D080B24 + 0xFC000 + 0xE0), 4096);
printk("Check security from (%X)\n", (int)pa);
if (!pa) {
printk("unable to realloc pa!");
return -EBUSY;
}
printk("SECURITY = %X\n", pa[0]);

iounmap(pa);
return 0;
}

:) if this working, I think reversing that function will allso working:laugh:

edit:

Yes, my device curently is s-off so I will try what I will get while s-on, currently I got 0 from dmesg :cyclops::

<4>[19131.433868] memdump: module license 'unspecified' taints kernel.
<4>[19131.446624] Check security from (D30A0C04)
<4>[19131.447174] SECURITY = 0

edit:

Got 0 while s-on :(

What is 0x9D080B24... maybe its not right offset that I need to lookup, maybe its msm_shared_ram_base?

So maybe readb(MSM_SHARED_RAM_BASE + 0xFC0E0) will give something?
[HTC Wildfire S] no.human.being:
No. This is not what the code is doing. If I understand it correctly, it loads the constant 0x9d090b24 into register r3, then loads the value at the memory address in r3 into r4 (that's why r3 is in brackets - I think it's a dereference operation), then adds 0xfc000 and 0xe0, then loads the value that r4 points to into r0. Then it cleans up the stack (I think that's what the LDMFD instruction does - I didn't actually look it up?!) and returns.

So it's more like this ...

int check_secuflag(void)
{
int r3 = 0x9d080b24; /* load address 0x9d080b24 into r3 */
int* r3_ptr = (int*)r3; /* turn the content of r3 into a pointer */
int r4 = *r3_ptr; /* dereference that pointer and put result into r4 */
r4 += 0xfc000; /* add 0xfc000 to r4 */
r4 += 0xe0; /* add e0 to r4 */
int* r4_ptr = (int*)r4; /* turn the content of r4 into a pointer */
int r0 = *r4_ptr; /* dereference that pointer and put result into r0 */
return r0; /* return that value */
}

So it doesn't query the address 0x9d080b24 for the flag. Instead, it looks what is at address 0x9d080b24. The value that it finds there is another address that it treats as a pointer to a data structure. The secu_flag lies at offset 0xfc0e0 into that data structure. I remember that in our HBOOT there's similar (identical?) code.

The problem is that all the processor's load/store operations access volatile (RAM) memory, not persistent (NAND) memory. So even if we knew what value is at 0x9d080b24, we won't know where the secu_flag is in NAND, just where a copy (that the Radio crafts?) is in RAM.
[HTC Wildfire S] munjeni:
Decompiled function:

sub_3F2C0:
/* push R4 */
/* pop */
return * (* 0x9d080b24 + 0xfc000 + 0xe0);

Why complicating because it returning an int from addrese (0x9d080b24 + 0xfc000 + 0xe0) .. but maybe I need to mask it like (0x9d080b24 + 0xfc000 + 0xe0) & 0x000000ff so its maybe rerason why I got 0 in s-off and s-on mode? I'm not surre if 0x9d080b24 is an addrese or its maybe adresse in memory (my local computer that runing hboot analyse) ? Or maybe I can not need to iomap it kernel side... maybe its an physical addrese so I simple need to look inside that addr with an simple kernel readb() ?