yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
I'm already trying for some time now, building an operating system around a "vanilla" Linux 3.2.5 kernel for the MSM7227 (well actually for the MSM7201, as "vanilla" Linux doesn't have support for the MSM7227 itself). However, it always locks up the device.

So the other idea was extracting the kernel from the CWM recovery image and then build an OS around that. It's not as "nice and clean", as we're actually taking a "black box" as kernel here, but it may be faster than trying to resolve the problems with the Linux 3.2.5 kernel.
[HTC Wildfire S] theq86:
acually the recovery is a very good skeleton os. I think there is not that much to change. a minimal gnu system is also included.
[HTC Wildfire S] no.human.being:
I tried booting the recovery with a "messed up" partition table and it threw lots of error messages. I actually want something that is self-contained and doesn't "require" anything that's installed to the phone's NAND.

Or is it just the "recovery utility" (the "shell" that's running after the OS has booted) that throws these errors and if we take that one out and put our own in, then it'll be running fine?

Well .. I'll try it out. :D
[HTC Wildfire S] rezo:
Read this http://xdaforums.com/showthread.php?p=23061916#post23061916. Maybe you find it interesting.
[HTC Wildfire S] MrTaco505:
So does this mean that cwm has a working kernel?
[HTC Wildfire S] theq86:
cwm is a fully working minimal gnu image with ignores restrictions, yes.

so either we alter the cwm img or pack an own ramdisk along with the kernel.

but the kernel is working
[HTC Wildfire S] no.human.being:
Is the kernel source available somewhere? Just out of curiosity. I just love being able to look inside. :D
[HTC Wildfire S] theq86:
Well, I don't think so.

CWM recovery comes from RomManager (which APK is HEAVILY obfuscated :D )

But feel free to have a look at http://clockworkmod.com/ and http://developer.clockworkmod.com
[HTC Wildfire S] no.human.being:
Yes it is. I can't find a kernel however. But since it's in the CM repositories, possibly it uses the same kernel as CM? :confused:

Now it gets weird ...
[HTC Wildfire S] theq86:
if that is true, cyanogenmod should also be able to bypass the restrictions. unless there is really nothing restrictive that is loaded after the kernel. I'll give it a try and use cm7 on a locked device.
[HTC Wildfire S] no.human.being:
What if the restriction is implemented on the file system layer and not on the block device layer? We always tried writing to "/system" on a locked device and that fails. However, I can tell you it also fails on an unlocked device. It has nothing to do with S-ON/S-OFF, it's just that "/system" is mounted as read-only and you cannot mount it as read-write since the file system is obviously in use while the system is booted.

Probably it's just that the file system driver refuses to write but the mtd device drivers do write. :eek:
[HTC Wildfire S] theq86:
Well, there's a mistake in your logics. On my stock htc rom I can write on /system because it can be mounted r/w.

when I relocked I was not able to write there anymore.

after re-unlocking I could write again on /system even if it was "busy"

remember, you can remount a partition without losing access to it.
[HTC Wildfire S] no.human.being:
No I can't. The command "mount -o rw /dev/block/mtdblock3 /system" will fail on a root shell under CM7.2.

You cannot even mount it to a second mount point (while keeping the original read-only mount at "/system") because "mount" says the file system is "in use".
[HTC Wildfire S] theq86:
well, I don't know how, but I'm on cm7 now, downloaded ES File Explorer and set the root options.

I can write on system. even the root explorer app can remount / and /system r/w

I don't know what internal command the programs execute but you can do it
[HTC Wildfire S] no.human.being:
Ok then you just can't do it via "/bin/ash" right?
[HTC Wildfire S] theq86:
Well, I don't know what is your problem.

So here is what I did and the outputs

On the devices Android Terminal (CM7.2)

I now test if it works locked.
[HTC Wildfire S] d33ps1x:
@NHB

Would access to my XTC Clip help?:)

Did you get your jtag converter?
[HTC Wildfire S] no.human.being:
Ok, your firmware seems to be "different" than mine. :D

$su
# pwd
/
# mkdir test
mkdir: can't create directory 'test: Read-only file system
# cd /data/local
# pwd
/data/local
# mkdir test
# mount /dev/block/mtdblock3 /data/local/test
mount: mounting /dev/block/mtdblock3 on /data/local/test failed: Device or resource busy
#

And now? :D

---------- Post added at 06:21 PM ---------- Previous post was at 06:17 PM ----------

Yes, but only after we got the unmapped memory mapped in. We just "wasted" one S-OFF by dumping the entire "mapped" memory before and after the progress and haven't seen lots of changes.

Only visible changes were that the first few instructions on the "misc" partition were "NOPped out" and a lot was changed on mtd3 (which is "/system") but the changes to "/system" were just "collateral damage". They had nothing to do with the S-OFF itself.

Yes, but I first want to try the "less invasive" methods before shooting the phone braindead. :D
[HTC Wildfire S] theq86:
Okay, you are right. consider my snipped to be executed after making es file explorer the partition r/w

without I get same messages like you.

I will try to disassemble the explorers apk and find out how exactly he does it.
[HTC Wildfire S] no.human.being:
No, no, no. Don't waste your time. It's not neccessary. We won't have the file system "mounted" while doing the S-OFF and the "read-only file system"-thing is obviously a POSIX file system permissions problem. We'll do the S-OFF via the mtd device only. The file system permissions won't intervene.
[HTC Wildfire S] theq86:
okay, but fact is: it can be mounted r/w unlocked, but not locked.

so I will find out if the cyanogenmod kernel can mount while locked. then we know if the cm kernel ignores restrictions, too
[HTC Wildfire S] no.human.being:
Not being able to mount rw sounds like a restriction that's built into the file system driver. We won't use the file system driver. The Radio firmware doesn't live inside a file system.

BTW, I've just found out that the Radio firmware was originally developed by University Karlsruhe. Shall we contact them for a backdoor? :D
[HTC Wildfire S] theq86:
Okay, cm7 behaves like normal roms. unlocked = write to /system, locked = readonly

however, there cwm does indeed has no restrictions even locked it should still be our first place to go.

btw for everyone interested in how /system can be mounted on an unlocked phone:

mount -o force,remount,rw /dev/block/mtdblock3 /system
[HTC Wildfire S] no.human.being:
I think different things were tested on both. We tested writing files to "/system" (yaffs2 driver, restricted) on CM7 and wiping partitions (mtd driver, unrestricted) on CWM. We'll work on the mtd driver (unrestricted) for patching the Radio, as the Radio is a raw binary (like the boot/recovery images) that doesn't have a file system and it probably works with either kernel.

What will this command return on a locked phone?

I'll go "stripping the recovery image" now.
[HTC Wildfire S] theq86:
I thought the radio is out of the mtd partitions range, how can the mtd driver be the solution?

no error until here, but then
[HTC Wildfire S] no.human.being:
There's no way to access NAND other than the mtd driver (unless you're willing to write your own driver :D ).

Now the Radio is "unmapped memory", which means it is not accessible via the "default" mtd partitions. However, the mapping can be changed by passing parameters to the kernel. The parameters are "mtdparts=msm_nand:" followed by "[HEXADECIMAL_SIZE]@[HEXADECIMAL_PHYSICAL_ADDRESS]([PARTITION_NAME])" for partition mtd0, then a comma (","), then the same for mtd1 and so on. Supply as many partitions as you like.

So on the Wildfire S, the partition layout was:

[COLOR="Red"]0x00000000-0x02fbffff : "radio" ("unmapped")[/COLOR]
0x02fc0000-0x034bffff : "recovery" (mtd1)
0x034c0000-0x037fffff : "boot" (mtd2)
0x03800000-0x13bfffff : "system" (mtd3)
0x13c00000-0x15efffff : "cache" (mtd4)
0x15f00000-0x168fffff : "devlog" (mtd6)
0x16900000-0x1fefffff : "userdata" (mtd5)
0x1ff00000-0x1fffffff : "misc" (mtd0)

Now we don't need beginning and end, but beginning and size and size is "(end - beginning) + 1", so let's calculate the sizes:

[COLOR="Red"]"radio": 0x02fc0000 ("unmapped")[/COLOR]
"recovery": 0x00500000 (mtd1)
"boot": 0x00340000 (mtd2)
"system": 0x10400000 (mtd3)
"cache": 0x02300000 (mtd4)
"devlog": 0x00a00000 (mtd6)
"userdata": 0x09600000 (mtd5)
"misc": 0x00100000 (mtd0)

Now we assign the radio to the device "mtd7" and order it by ascending partition numbers.

mtd0: size 0x00100000, address 0x1ff00000 (misc)
mtd1: size 0x00500000, address 0x02fc0000 (recovery)
mtd2: size 0x00340000, address 0x034c0000 (boot)
mtd3: size 0x10400000, address 0x03800000 (system)
mtd4: size 0x02300000, address 0x13c00000 (cache)
mtd5: size 0x09600000, address 0x16900000 (userdata)
mtd6: size 0x00a00000, address 0x15f00000 (devlog)
[COLOR="Red"]mtd7: size 0x02fc0000, address 0x00000000 (radio)[/COLOR]

So if we wanted to have the standard mapping and include the Radio firmware as mtd7, we'd supply the following parameters to the kernel:

mtdparts=msm_nand:0x00100000@0x1ff00000(misc),0x00500000@0x02fc0000(recovery),0x00340000@0x034c0000(boot),0x10400000@0x03800000(system),0x02300000@0x13c00000(cache),0x09600000@0x16900000(userdata),0x00a00000@0x15f00000(devlog),0x02fc0000@0x00000000(radio)

This will give us a new mtd device called "mtd7" which will map the Radio firmware. We then take a kernel (say the one that comes with CWM) supply the above parameters, put a utility into the initrd that dumps the mtd7 partition to a file on the SD card and do that before and after applying S-OFF via xtc-clip, then we'll know where the secu_flag resides. And then we build a utility that patches our "new" mtd7 and supply the whole as a firmware image. Whoops, S-OFF! :D

That is if there's nothing "evil" in the kernel that prevents us from doing it. With a "vanilla" kernel it would definitely work, but we didn't get one running on the system, so let's see how the CWM kernel does.
[HTC Wildfire S] theq86:
and did you try to map the partition using a standard kernel? what happened?
[HTC Wildfire S] no.human.being:
No I didn't. The idea is quite ... eerm ... recent. :D

Unless there's really "bad" trickery and "black magic" going on it'll probably work on every kernel. :D

However, if we run into problems at some point we should really consider that there might be something in the kernel and we should consider going back to our plan with the "vanilla" kernel.

I'll definitely try this out tonight. :D
[HTC Wildfire S] theq86:
so actually the only difference between other HTC devices is that in there is the mtd7 mapped.

Some time weeks ago, we discussed why htc would have made the wfs harder to crack or to strengthen security. we found no reasonable answer, remember?

maybe htc did not built in so many restrictions as we thought until now.

so let's hope that adding the radio partition to the map is all the way :D
[HTC Wildfire S] no.human.being:
Remember that we found out the Desire S has a partition 7 and that the secu_flag is patched there (at address 0x00000a00)? :D

If a "standard" kernel (CM or CWM) will map this f***ing Radio partition, then I'll laugh at all of them .. at HTC .. at Revolutionary .. at everyone for the "ultimate unbreakable extra security" of removing a parameter from the kernel command line. :D
[HTC Wildfire S] theq86:
That would start a new chapter in computer security.

security through removeability :D
[HTC Wildfire S] heavy_metal_man:
if this is true would we be able to do this with the old wildfire? i know many might say why, but true s-off is always better than *forged* s-off in my opinion;)
[HTC Wildfire S] theq86:
isn't wildfire(buzz) supported by revolutionary?
[HTC Wildfire S] no.human.being:
Yes it is, but Revolutionary works by patching HBOOT, not the Radio. Some people prefer to have the Radio patched since the Radio will persist flashing other HBOOTs.
[HTC Wildfire S] theq86:
if we get a radio comparison from standard to xtc clip and only few changes are made, we maybe will be able to even set super cid or remove sim lock.

right?
[HTC Wildfire S] heavy_metal_man:
indeed. also, me and some others have been trying to get simunlock as well, and we tried using the xtc clip diag file to do it, and were met with defeat as it didnt have true s-off, or because we didnt have the xtc flexy cable. i spoke to sieempi (the guy who made the htc desire simunlock) and he said that the file will only work when the cable is in or if the device is radio unlocked. sooo :rolleyes: if it works on your wildfire s, after s-off running the file to give simunlock and supercid then we (buzz) might have some luck as well. ive been looking into trying to edit the file to make it run without the flexy cable but i cant find any programs that can edit it :(
[HTC Wildfire S] no.human.being:
Right.

The "Super CID" might even be in "misc" however. The first 8 bytes are the CID. After xtc-clipping a phone, the first bytes will be the word 0xffffffffffffffff.
[HTC Wildfire S] theq86:
you mean edit the diag file? well, you'd need a hex editor and had to know the file format to be able to change it. but if you are s-on editing the diag would screw the signature. so that's not the way to go.
[HTC Wildfire S] heavy_metal_man:
something to note, we found that the diag file would run on the rev. hboot and say it was successful but the only thing it changes is the backup cid file. but we couldnot get it to become the main one. even by factory resetting the device.

also theq86, it should run on the rev bootloader as it believes that it is s-off ;)
[HTC Wildfire S] no.human.being:
Well I'm having a remote shell on the CWM recovery now with "custom" kernel parameters.

~ # pwd
/
~ # 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
boot init sys
cache init.rc system
data proc tmp
datadata res ueventd.goldfish.rc
default.prop root ueventd.marvel.rc
dev sbin ueventd.rc
emmc sd-ext
etc sdcard
~ # mount /dev/block/mtdblock3 /sdcard
~ # cd /sdcard
/sdcard # ls
app build.prop fonts lib media usr xbin
bin etc framework lost+found tts vendor
/sdcard # echo "hello" > test.txt
/sdcard # ls
app build.prop fonts lib media tts vendor
bin etc framework lost+found test.txt usr xbin
/sdcard # rm test.txt
/sdcard # cd ..
~ # umount /dev/block/mtdblock3
~ #

So writing to mtd3 file system is no problem here. However, as you can see from the cat there's no mtd7. Probably the kernel can have 7 (0 through 6) mtd devices at maximum. I'll try mapping the Radio as mtd6 (it's devlog, which is probably not so important) and see if that works. If it doesn't work, we probably have to go back to the custom kernel thing.

EDIT: No it doesn't work. The "/proc/mtd" always remains the same no matter what parameter you supply to the kernel.
[HTC Wildfire S] theq86:
remote shell? you mean you booted cwm and use adb shell?

how did you add the kernel parameters, I also want to have a look.
[HTC Wildfire S] no.human.being:
I used a CWM image loaded into device's RAM via fastboot (as you can't supply parameters when you boot it from NAND).

Command line was:

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

Of course you got to have an image of CWM recovery in your fastboot folder named "recovery.img".

EDIT: And yes, I used an adb shell to the CWM recovery. I don't understand why it's not working. Some weeks ago I booted CWM via fastboot and supplied some "bogus" parameters for "mtdparts" and CWM went crazy throwing error messages all over the screen. So I thought manipulating the mapping of mtd pages would work. But now I try it in a "controlled way" and it doesn't appear to have any effect at all.
[HTC Wildfire S] theq86:
maybe fastboot refuses kernel parameters.
[HTC Wildfire S] theq86:
well, then back to vanilla, yummie.
[HTC Wildfire S] no.human.being:
Baaah, I got the impression that we'd already have at least one workable solution if we had a kernel dev here. :(
[HTC Wildfire S] theq86:
or a kidnapper willing to get us an htc dev...
[HTC Wildfire S] heavy_metal_man:
hey guys, just thought id post saying that i opened the htcdiag file using hxd hex editor and from what i can make of it it doesnt seem to ask the radio to "flick the switch" for the s-on as it were. seems to be saying lot about writing to the nand itsself....... not sure if im reading it right but thought id bring it to your attention. can supply the wildfire s file if needed.
[HTC Wildfire S] no.human.being:
Haha it works! :D

~ # 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"
mtd7: 02fc0000 00040000 "radio"
~ #

I had a fastboot image of unknown origin that probably couldn't do it for whatever reason. I now used the fastboot that ships with the Android SDK and this one does it. :D

So yes people, we have access to the Radio! :D

~ # cat /dev/mtd/mtd7 > /sdcard/radio.img

Succeeds so I'm now having the Radio firmware right on my SD card! :D

So victory I'd say! We just have to find the flag now. Memory protection is gone! The rest is "good programming work" and "finding out how APIs work" for programming the Flash via mtd devices. It's not that trivial as you have to do quite sophisticated "ioctl" calls to explicitely erase pages before programming them again, otherwise the memory won't be writable. But like I said this is just coding skills and API knowledge. We have passed the challenge, Radio protection is dead! :D
[HTC Wildfire S] theq86:
Great pal !!! What a **** I can thank you just 1 time and 8 times per day :D

where did you get the fastboot ?

Hell and I was already a little bit upset about it :D
[HTC Wildfire S] no.human.being:
The one that works is just the plain that ships with the SDK. The other one I got from a forum claiming it to be "ultra special h4xx00r fastboot" lol. Probably I've a trojan horse installed to my system now. :D
[HTC Wildfire S] theq86:
a win or linux binary?

could you upload? my data plan is out of volume :D

edit: I know why my fastboot would not work. I downloaded it on the htcdev site. LOOL
[HTC Wildfire S] :
GERONIMO!

If HTC Devs knew about this, they'll piss themselves!

Can you do me a favour, NHB, and post the fastboot you used. Thanks!

Can you also explain what exactly you did to get here?

And does this mean we have no need for a kernel dev?

Sorry for the questions! Excited. Is there any way I can help? I'd love to!

I got Fedora recently.
[HTC Wildfire S] theq86:
Okay, I switched to Windows and had a fastboot downloaded earlier from an sdk.

And I got the radio.img now, too. :)

Edit

radio checksum: (md5) bdc2d43c8bb3a1845caf5ec2198b8e02 *radio.img

radio size: 50.069.504 Bytes

what about you nhb?

Of course I don't expect our radios to be the same, but maybe we get surprised.

BTW:

I looked for my unlock code or device token inside the radio. I found nothing. either the img is compressed, or the unlock token is not flashed permanently :D
[HTC Wildfire S] no.human.being:
When you're working under Linux you first got to make the system give you permissions to access the phone's device special file. For this purpose, create a file using:

sudo gedit /etc/udev/rules.d/11-android.rules

Put in the following content:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bb4", MODE="0666", OWNER="myusername"

Replace the "myusername" with the account of your Linux user. This is required for fastboot to access the device. I think you have to reboot the Linux machine to take advantage of that.

For the toolchain just download this for Linux obviously, untar it somewhere, open a shell, cd into "/your/untar/directory/android-sdk-linux/tools", then do "./android", install the entire "Tools" folder.

Then you'll find the "fastboot" and "adb" utilities under "/your/untar/directory/android-sdk-linux/platform-tools". Put a CWM "recovery.img" there, cd into it, then do:

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

Device will boot into CWM (but not the CWM installed on NAND but the CWM that you just supplied via fastboot and that is now executing from the device's RAM). Then do the following.

$ ./adb start-server
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
$ ./adb shell
~ # 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"
[COLOR="Red"]mtd7: 02fc0000 00040000 "radio"[/COLOR]
~ #

You see that the Radio is now visible as "mtd7". Now remember the phone is in CWM recovery, so use the Vol+/- and Power keys to navigate to "mounts and storage" --> "mount /sdcard". Back on the adb shell, you should now see the SD card mounted.

~ # mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
[COLOR="Red"]/dev/block/mmcblk0p1 on /sdcard type vfat (rw,nodev,noatime,nodiratime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)[/COLOR]
/dev/block/mtdblock4 on /cache type yaffs2 (rw,nodev,noatime,nodiratime)
~ #

Afterwards you can just "cat /dev/mtd/mtd7 > /sdcard/radio.img". This will dump the contents of the "unmapped memory" to a file called "radio.img" on the SD card. If you're finished, just shut down CWM on the phone and read the file from the SD card. You'll see that it doesn't look like a Radio image. It's much larger, so there's probably a lot more in it.

Not sure. Obviously, XTC-clip would be nice to have now. :D

Btw, the idea with the CWM kernel that bypasses security was just killer, thank you so much theq86!!!! :D
[HTC Wildfire S] theq86:
:) I'm glad I found out.

BTW just tried

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

with the standard htc kernel and the functioning able fastboot.

now guess: bootlock.

so my idea with the cwm kernel was really good. stock kernel will not allow this.
[HTC Wildfire S] :
The obviously bit makes me embarassed, 'cos I am still learning. And, eeeeerm..... What's a toolchain?

I'm going to use fastboot to flash that ROM_01 maybe.

So, how close are we now? And do I look at the radio with HxD or something. I still have no idea about memory addresses etc.

Could you give me a basic overview of memory addresses (about them, etc.) and the ones we're focusing on.

Thanks.
[HTC Wildfire S] theq86:
If you are on cwm 5.0.2.8 just use the sensor soft buttons instead of wearing down the good old volume keys :D
[HTC Wildfire S] heavy_metal_man:
i still have mine ;) anyone one in scotland thats willing to help, if nbh can write a solid plan that can go on windows (no linux terminal) the i will clip for free:D

and it only took 115 pages :P
[HTC Wildfire S] MrTaco505:
HOLY ****.....I can't stop celebrating on what the help nhb just did. Cheers :):):):):):):):):):D