yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] mansmith:
ls -a -l /dev/block/*

brw------- root root 254, 0 2012-01-04 11:10 dm-0
brw------- root root 254, 1 2012-01-04 11:10 dm-1
brw------- root root 254, 10 2012-01-04 11:10 dm-10
brw------- root root 254, 11 2012-01-04 11:10 dm-11
brw------- root root 254, 12 2012-01-04 11:10 dm-12
brw------- root root 254, 13 2012-01-04 11:10 dm-13
brw------- root root 254, 14 2012-01-04 11:10 dm-14
brw------- root root 254, 15 2012-01-04 11:10 dm-15
brw------- root root 254, 2 2012-01-04 11:10 dm-2
brw------- root root 254, 3 2012-01-04 11:12 dm-3
brw------- root root 254, 4 2012-01-04 11:10 dm-4
brw------- root root 254, 5 2012-01-04 11:10 dm-5
brw------- root root 254, 6 2012-01-04 11:10 dm-6
brw------- root root 254, 7 2012-01-04 11:10 dm-7
brw------- root root 254, 8 2012-01-04 11:10 dm-8
brw------- root root 254, 9 2012-01-04 11:10 dm-9
brw------- root root 7, 0 2012-01-04 11:10 loop0
brw------- root root 7, 1 2012-01-04 11:10 loop1
brw------- root root 7, 10 2012-01-04 11:10 loop10
brw------- root root 7, 11 2012-01-04 11:10 loop11
brw------- root root 7, 12 2012-01-04 11:10 loop12
brw------- root root 7, 13 2012-01-04 11:10 loop13
brw------- root root 7, 14 2012-01-04 11:10 loop14
brw------- root root 7, 15 2012-01-04 11:10 loop15
brw------- root root 7, 2 2012-01-04 11:10 loop2
brw------- root root 7, 3 2012-01-04 11:10 loop3
brw------- root root 7, 4 2012-01-04 11:10 loop4
brw------- root root 7, 5 2012-01-04 11:10 loop5
brw------- root root 7, 6 2012-01-04 11:10 loop6
brw------- root root 7, 7 2012-01-04 11:10 loop7
brw------- root root 7, 8 2012-01-04 11:10 loop8
brw------- root root 7, 9 2012-01-04 11:10 loop9
brw------- root root 179, 0 2012-01-04 11:10 mmcblk0
brw------- root root 179, 1 2012-01-04 11:10 mmcblk0p1
brw------- root root 31, 0 2012-01-04 11:10 mtdblock0
brw------- root root 31, 1 2012-01-04 11:10 mtdblock1
brw------- root root 31, 2 2012-01-04 11:10 mtdblock2
brw------- root root 31, 3 2012-01-04 11:10 mtdblock3
brw------- root root 31, 4 2012-01-04 11:10 mtdblock4
brw------- root root 31, 5 2012-01-04 11:10 mtdblock5
brw------- root root 31, 6 2012-01-04 11:10 mtdblock6
drwxr-xr-x root root 2012-01-04 11:06 msm_sdcc.2
brw-rw---- root root 179, 1 2012-01-04 11:07 179:1
brw-rw---- root root 179, 0 2012-01-04 11:06 179:0

I ran the above command and got this listing. I am not sure what the 4th and 5th column mean. I looks like the 5th column gives the sequential number of the blocks on the same device, I think. But what interests me is the 4th column, the only blockdevices I am able to cat, like SDcard(179:1) and the RAM mmcblk0 both have the number 179 is this significant? Does it mean it is readable or is it just a number for the type of memory?
[HTC Wildfire S] ONeill123:
I have execute the command too, same list like you post.

The number 179 isn't the right i think, the rights are in the first column, if i'm right. Have u tried the tutorial for the DHD? It is very risk.
[HTC Wildfire S] MindBurn010:
brw------- root root 254, 0 2012-01-04 11:10 dm-0

for example

179 is not the rights, I won't get further in it to explain how to use the numeric rights...

anyway

b [rw-|user] [---|group] [---|everyone else]

the rw in front sais that the owner can read and write / next to it is the owner user (root)

179 i think is blocks, try to use "-h" for human readables -> bytes

the 5th column must be the partition allocation

What are those:

brw-rw---- root root 179, 1 2012-01-04 11:07 179:1

brw-rw---- root root 179, 0 2012-01-04 11:06 179:0

:(

just to clear something:

179:1

179:0

is a block device not related to the mmcblk..., is anybody able to mount it and check for its real sizes ?
[HTC Wildfire S] mansmith:
I tought the 179 had something to do with the hardware specifics(like hardware readable or writable or something). Not related to the OS privileges.

The 179:1 is your sd card. You can mount it with

mount -t vfat -o rw /dev/block/vold/179:1 /sdcard

I did a partial dump(about 400mb) of the mmcblk0 and it contained some html code wich looked like running code. So I guess it is your RAM. But that is just speculation.
[HTC Wildfire S] ONeill123:
can u dump the mmcblk0p1 plz?

I can at evening :(
[HTC Wildfire S] sythe179:
tell me how, and i'll do it asap.
[HTC Wildfire S] mansmith:
I used Zergrush for temproot and then cat /dev/block/mmcblk0p1 > /sdcard/dump.img.

It however kept dumping till my SD card was full. (about 1.8 Gb).
[HTC Wildfire S] MindBurn010:
but whats the reason the dump the mmcblk0p1 ?
[HTC Wildfire S] sythe179:
k...doing it now..

but beter not loop...16GB card..

/edit

ok...turns out..it just dumps all your files on your sd card into a single file...

not very important...
[HTC Wildfire S] no.human.being:
No it doesn't, it has NAND (memory controller resides in CPU package). The eMMC devices (memory controller resides in memory package) have "mmcblk*" ("multimedia card block"?), while the NAND devices have "mtdblock*" ("memory technology device block") device files for their partitions. The WFS has the latter, so it is NAND.

Nope, the "mmcblk*" files of the WFS are the device handles for the MicroSD card inserted into the slot. The "onboard" memory is handled through the "mtdblock*" devices.

The 4th column basically tells which kernel module (device driver) has registered for the device file and the 5th column tells which exact device of this particular driver it is (as the same driver may handle multiple devices). So all the devices that have the same number in the 4th column are handled by the same device driver and can thus be considered "identical hardware".
[HTC Wildfire S] sythe179:
agree, same driver as the mmcblk0p1, so maybe, the other is a virtual partition?...like, the cards read-only partition?...

/edit

in the mean time, im doing a dump of "/dev/block/* > /sdcard/dump.img"

...see what turns up...
[HTC Wildfire S] ONeill123:
Why it is so difficult to locate the secuflag on wildfire s?

Which htc device has NAND memory too. Maybe we find a device that is very similar like wildfire s and is unlockable. So we can start at to search around the same memory adress?

It is right, that the hboot has an own secuflag? And in which mtd block the radio is stored in which we think to find the secuflag?
[HTC Wildfire S] sythe179:
first questions answer :

we tried that, but HTC have blocked the method that the other phones where done with, and memory locations change...not just a little bit..

second questions answer :

no, it uses a varible of the secuflag located someware....

third questions answer :

last i heard it was on the p3, or the radio.img
[HTC Wildfire S] sythe179:
just playing around....dont know if these mean anything but..

becouse simple commands work, thought i might just grab a few random files,

and look whats inside...

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

init.txt - system/init.rc

system.txt - random file, grabbed it, looked interesting.

goodies.zip - well, more random stuff, named goodies.

(from random locations including system/framework/ and system/)
[HTC Wildfire S] ONeill123:
If i want to cat every of this files, every time invalied length ;)
[HTC Wildfire S] no.human.being:
Yes, the "/dev/block/mtdblock*" devices fail to open. Someone suggested CodeSourcery toolchain here. I'll download that one and see if I can get started.
[HTC Wildfire S] d33ps1x:
Gibberish to me but looks interesting...

Found some text in HxD of HTC Clip gold card's diag file PG76DIAG.nbh

Starts at offset 00093600

Also a load of stuff between 00094BF0 and 000ACB00 including references to a CDMA routine at 000AC200

Also found this thread on how to extract the contents of an .nbh file...

Unfortunately it didn't work on the DIAG file:

Wonder if there is an updated version...Nope checked

Found this tutorial...

Also some stuff about the S58 clean at offset 000A1280 on
[HTC Wildfire S] meanmug:
Hboot dosen't have its own secuflag, hboot is just a compressed file that contains all the phones images(radio, recovery, boot, system, ect..)
[HTC Wildfire S] djpc:
hboot does not contain any images, it is a bootloader/preboot environment
[HTC Wildfire S] *se-nsei.:
Haven't we already been informed that the actual secuflag is located in the nvram of the radio. No off track stuff.
[HTC Wildfire S] d33ps1x:
All kinds of references to radio, Security flags, etc in this file.

Sure we can't change it to skip the SIM check on GSM phones?

"Please input Security Flag(01 or 00, 0 or 1):...Security Flag Len NG!...If Lock Flag = 0 , No need to input MCCMNC and GID1.....If Lock Flag = 1 , Need to input MCCMNC ,but no GID1....If Lock Flag = 2 , Need to input NSL ,but no MCCMNC and GID1....If Lock Flag = 4 , Need to input GID1 , but no MCCMNC and NSL.......If Lock Flag = 5 , Need to input GID1 and MCCMNC....If Lock Flag = 6 , Need to input GID1 and NSL.......If Lock Flag = 7 , Need to input MCCMNC , GID1 and NSL......"
[HTC Wildfire S] sythe179:
need to change the hboot or install a custom hboot to do that...
[HTC Wildfire S] wildfiresuser:
http://tjworld.net/wiki/Android/HTC/Vision/HbootAnalysis

I can successfully connect serial over usb using this procedure by tj. AT@SIMLOCK?AA command answers "@secu_flag = 1" but AT@SIMLOCK=7,0 restarts phone but does not change security flag. Maybe we can try to catch on this hint, try to figure out the right bit instead of 7?

(Or I took sim card and SD card out, maybe I should've kept the sim in place? I will try that one tomorrow.)
[HTC Wildfire S] meanmug:
It works with the phone powered on, we need it to work in hboot.
[HTC Wildfire S] BeciMester:
Great stuff, it verifies that at least the query command works on the WFS. At the same time, be very careful, I suspect it's pretty easy to brick your phone this way!

I think we won't be able to change the flag this way, but if we figure out the right command, maybe we can write a program that we push to the phone and execute with root rights...?

Desire-Oxygen2.3.2 | WFS-stock
[HTC Wildfire S] sythe179:
AT command list

(not sure how many are combatible)

AT+CMEE=1
AT+CRC=1
AT+CR=1
AT+CREG=1
AT+FCLASS=0
AT+CMGF=0
AT+CSCS="HEX"
AT+CSSN=1,1
AT+COLP=0
AT+CCWA=1
AT+CMUT=0
AT+CLIR=0
AT+CNMI=1,2,2,2,0
AT+CGREG=1
AT+CUSD=1
AT+CPPP=1
AT@v;+RADIOVER
AT@v;+RADIOVER
AT@HTCCSQ=1;+ENCSQ=1
AT@HTCDIS=1;@HTCSAP=1
AT+CREG=2
ATE0
AT+CSCA?
AT+CGSMS=%u
AT+CPPP=%u
AT+GTKC=%u
AT+HTCAGPS_AUTOCS=%d
AT+HTCENS=%d
AT+GIMG=%u,%u,%u,%u
AT@HTCDORMANCYSET=%u
AT+CGEQREQ=%u,%u,0,0,0,0,2,0,"0E0","0E0",3,0,0
AT+HTCmaskW1=%u
T+HTCmaskW1=%u
AT+HTCmaskW1=%u,%u
AT+HTCCNIV=%u
AT+HTCCTZR=%u
AT+HTCAGPS=%u
AT+HSDPA=%u
AT@ICF=%u
AT@HTCPDPFD=%u
AT+CMEMFULL=%u
AT+3GNCELL=%u
AT$FTM=%u,%u
AT$FTM=%u
AT+GTKT=%d
AT+GTKD=%d
AT+CMUT=%d
AT+CSSN=%u,%u
AT+CMGW=%u,%u
AT+CMGD=%u
AT+ENCSQ=%u
AT+BANDSET=%u
AT+CLIR=%u
AT+CPBS="%s"
AT$VTS=%c,%c
AT+VTS=%c
AT+CNMA=%d
AT+CMMS=1;+CMGS=%d
AT+CMGS=%d
AT+CREG=%u
AT+CFUN=%d
AT+HTCAGPS_AUTOCS?
AT+CSAS=%u
AT+CSAS
AT+CSCB?
AT+CGAATT=2,2,0
AT+CGAATT=2,1,1
AT+CGAATT=2,2,2
AT+CGAATT=0,2,0
AT+CPMS="SM","SM","SM"
AT+CMEMFULL?
AT+Q3GNCELL
AT+Q2GNCELL
AT@ACOUSTICINITED
AT$3G_DL_TF_COMB_ST_3?
AT$3G_DL_TF_COMB_ST_2?
AT$3G_DL_TF_COMB_ST?
AT$3G_RESEL_EVENT?
AT$3G_AGC_STATUS?
AT$HSDPA_CQI_STATUS?
AT$3G_UL_RLC_AM_ST?
AT$3G_DL_RLC_AM_ST?
AT$3G_UL_TF_STATUS?
AT$3G_DL_TF_STATUS_3?
AT$3G_DL_TF_STATUS_2?
AT$3G_DL_TF_STATUS?
AT$3G_BLER_STATUS?
AT$3G_NEIGHBOR_ST_2?
AT$3G_NEIGHB
AT$3G_DCH_STATUS_D?
AT$3G_DCH_STATUS_M?
AT$3G_DCH_STATUS_A?
AT$PRACH_RACH_INFO?
AT$L3_RRC_SIGNAL?
AT$WCDMA?
AT$3G_RESEL_STATUS?
AT$3G_RESEL_PARA?
AT$2G_RESEL_STATUS?
AT$2G_RESEL_PARA?
AT$AMR?
AT$GPRS?
AT$GSM?
AT$FTM?
AT+CMUT?
AT+BANDSET=?
AT+CLIP?
AT+CLIR?
AT+CPBS?
AT+SIMTYPE
AT@SDLOG?
AT+CGSN
AT+CIMI
AT+COPS=?
AT+COPS=3,2;+COPS?
AT+CGREG?
AT+CREG?
AT+CSQ
AT+CLCC
AT+CPIN?
AT+GTKR=%s
AT+GTKE=%s
AT+CSCB=%d
AT+CSCB=%d,"%s"
AT+CSCB=%d,"%s","%s"
AT@SIMLOCK=%u,%u,%s
AT+HTCNV=%u,%u,%u
AT@SYSTEMTIME=%d,%d,%d,%d,%d,%d
T+CHLD=%d%d
AT+CHLD=%d
AT+CPIN="%s","%s",%s
AT+CPIN="%s","%s"

also, what are at these mem locations on the nvram, radio.img and hboot while running?..:

0x61

0x200
[HTC Wildfire S] wildfiresuser:
As far as I know, we don't need more because this might me the lowest level access so I don't think we will need any more authentication if this interface is capable of achieving this purpose.

Sorry but I did not actually get that. I'm doing that already at hboot.
[HTC Wildfire S] meanmug:
Thats great I could only get them to work in adb shell/temproot with the phone fully booted in os. If we change the value of secuflag just breifly to load the diag file we can s-off.

---------- Post added at 07:49 PM ---------- Previous post was at 07:45 PM ----------

@wildfiresuser, are you using windows and can you explain how you managed to get the at commands to work?
[HTC Wildfire S] sythe179:
Is there a way of telling hboot to run its firstrun script?...

There's a way of setting everything we want if we can...
[HTC Wildfire S] pjakma:
write protect disable kernel module

Been reading through this thread, as I also have a Wildfire S that I want to S-Off. I have tried the rtask-C trick to get the USB serial connection switched over to the Qualcomm radio host, and tried some AT@SIMLOCK=... commands without joy. Further googling led me to this:

(gah, can't include URL: google "wpthis.c" and go to first result, which should be tmzt/g2root-kmod on github)

which is a kernel module to reprogramme the memory controller to remove the write-protect it's applying. This presumably is for the HTC Desire Z / G2, so a Qualcomm 7230. The Wildfire S' MSM7227 likely is similar. A look at the programming manuals should show what exactly needs to be changed. I havn't managed to find any useful documentation on developer.qualcomm.com yet though to check this. The 7227 and 7230 are different product families though (Snapdragon s1 v s2), so there's almost certainly some differences. NB: I wouldn't run the above code on a Wildfire S!

With that done, if my understanding is right, it should be possible to update the flash from within Linux. Including the S-Off bit in the radio partition, if it can be found. Though, then it might also suffice to just hack HBoot to ignore S-Off, if that's easier to do (and it seems to be?).
[HTC Wildfire S] no.human.being:
I have just signed up for Sourcery CodeBench, as someone mentioned that he successfully compiled C code for our devices here with this toolchain. However, still no luck here.

[andre@andre-notebook bin]$ ./arm-none-eabi-gcc -o test test.c
/home/andre/Downloads/arm/arm-2011.09/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/bin/ld: warning: cannot find entry symbol _start; defaulting to 00008018
/home/andre/Downloads/arm/arm-2011.09/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib/libc.a(lib_a-fstatr.o): In function `_fstat_r':
fstatr.c:(.text+0x1c): undefined reference to `_fstat'
/home/andre/Downloads/arm/arm-2011.09/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib/libc.a(lib_a-openr.o): In function `_open_r':
openr.c:(.text+0x20): undefined reference to `_open'
/home/andre/Downloads/arm/arm-2011.09/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text+0x18): undefined reference to `_sbrk'
/home/andre/Downloads/arm/arm-2011.09/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib/libc.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text+0x20): undefined reference to `_write'
/home/andre/Downloads/arm/arm-2011.09/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib/libc.a(lib_a-closer.o): In function `_close_r':
closer.c:(.text+0x18): undefined reference to `_close'
/home/andre/Downloads/arm/arm-2011.09/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib/libc.a(lib_a-isattyr.o): In function `_isatty_r':
isattyr.c:(.text+0x18): undefined reference to `_isatty'
/home/andre/Downloads/arm/arm-2011.09/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib/libc.a(lib_a-lseekr.o): In function `_lseek_r':
lseekr.c:(.text+0x20): undefined reference to `_lseek'
/home/andre/Downloads/arm/arm-2011.09/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib/libc.a(lib_a-readr.o): In function `_read_r':
readr.c:(.text+0x20): undefined reference to `_read'
collect2: ld returned 1 exit status
[andre@andre-notebook bin]$

I'm just about to give up. I've spent hours trying dozens of compilers for ARM and every single one of them failed. I just followed the instructions of the "Getting started" guide for this CodeBench toolchain and it fails to compile. The compilers from the Android NDK fail too. I can work with "standard" Linux GCC for my x86-64, no problems here, but I just can't get any embedded compiler to work. Probably there are some "magic" tweaks with environment variables or command line switches I'm just missing, but I've read the available documentation and I just don't get it. Does anyone know what's the problem here?
[HTC Wildfire S] djpc:
This seems to be the best method i have seen so far, we should be able to load kernel modules if we have root however i have no experience with writing them. Im not sure but i think the write protect is done via hboot checking the flag and then passing this as an argument to the android kernel as it loads to enable write protection to the NAND. We cant change the hboot or the s-off flag unless we have s-off so it seems the only way to do this is to load a kernel module which makes the kernel stop the write protect so we can change the s-off flag
[HTC Wildfire S] pjakma:
Ah, digging further, it seems that the kernel's MMC block device additionally filters out writes to certain addresses, and this needs to be patched out of the kernel. The gfree utility does that.

---------- Post added at 04:01 AM ---------- Previous post was at 03:39 AM ----------

Reading IRC logs of how Scotty2, Guhl, tmzt, etc. figured this out for Desire Z / G2 on the G2ROOT channel, my understanding of what they discovered is that it's like this:

- the secu_flag is stored in radio specific memory

- which is a partition on Flash on at least some devices (like the HTC Desire Z, partition 7), but we don't know where it is on Wildfire S (hopefully still on the flash).

- the status of this flag can be queried with the AT@SIMLOCK?AA command to the radio host (e.g. by flipping the USB serial connection over using rtask c, as documented on the tjworld site).

The secure boot goes like:

- HBoot reads the state of the flag (does it read it directly or does it send an AT@SIMLOCK command to the radio host??)

- HBoot will only allow updates of signed images if the flag is on

- Either HBoot or the kernel programmes the flash controller to write-protect required regions (I'm guessing HBoot does it, also if the kernel does it I guess it always does so - never any need for official HTC code to update from the running image is there?)

- Additionally, the kernel's MMC driver may contains a second security device, to filter out writes to certain block ranges. At least, the Desire Z's kernel does.

So then Scotty2, guhl and tmzts' code needs to be adapted for Wildfire S. Required:

- get a copy of a Qualcomm MSM7227 programming manual and make the required tweaks to the wpthis kernel module, so that the MMC controller write-protect can be disabled.

- If that still doesn't allow writing, disassemble the kernel and look for the mmc_blk_issue_rq request filter and adapt gfree.c if required.

With that done, as per scotty2, guhl & tzmt's work, there are at least 2 ways to enable HBoot updates:

1. Figure out if the S-Off flag is stored on flash, and change it

2. Disassemble hboot, find where it checks the flag and patch it

2 is sufficient, but would be undone if hboot were updated. 1 would work with standard hboot.
[HTC Wildfire S] djpc:
It could be worth reaching out to these guys for some help, i think they are still active in the DZ community. This would make things far quicker.

You can download the kernel source off htcdev, ive never done it before but i assume you get the code so you dont have to reverse engineer anything.

EDIT: here on xda guhl is called guhl99 make sure we are speaking to the right guy :p
[HTC Wildfire S] sythe179:
Sent an email to Scott aswell.

btw, can somebody msg xda and ask em if they can increase the max filesize of 7z files?....dont wana have to create like 16 files to upload something....

might have to go with a mediafire link...
[HTC Wildfire S] ONeill123:
i think, youse mediafire, or rapidshare ;)

The filesize limit has a reason :)

And here is the link to the wpthis.c code (thanks to pjakama)

https://github.com/tmzt/g2root-kmod/blob/master/scotty2/wpthis.c

Maybe it is possible to rewrite the code. What is when anyone run the code on a wildfire S? Give it a built version of it?
[HTC Wildfire S] Siss:
hi guys....this guys said that he got HTC Wildfire S and it was shipped as S-off ...is it possible?

htcwildfiresforum.com/htc-wildfire-s-updates-and-rooting/htc-wildfire-s-marvel-shiped-as-s-off/msg8679/#msg8679
[HTC Wildfire S] ONeill123:
This is possible. HTC has delivered some devices, that are shipped s-off. But it give not many of them :(
[HTC Wildfire S] Siss:
so is it possible to get those guys device documentation, so that we can S-off all WFS?
[HTC Wildfire S] ONeill123:
what you mean with the device documentation?

The devices are the same like our s-on, only they are shipped s-off.

Plz don't forget my post:

i think, youse mediafire, or rapidshare ;)

The filesize limit has a reason :)

And here is the link to the wpthis.c code (thanks to pjakama)

https://github.com/tmzt/g2root-kmod/blob/master/scotty2/wpthis.c

Maybe it is possible to rewrite the code. What is when anyone run the code on a wildfire S? Give it a built version of it?

----------

is it possible, that we can use gfree after prep phone with tacoroot?
[HTC Wildfire S] ONeill123:
I don't know, what you mean, but i hope anyone know it and can help u ;)

What is with the wpthis.c

Is it possible, run the code on ws?
[HTC Wildfire S] pjakma:
If anyone's interested in more direct discussion, I'm on #wildfiresroot on freenode.
[HTC Wildfire S] sythe179:
apparently it disables write-protection on the emmc chip. (i think)

and im not sure if i can run it, but if no.human or somebody else can get an embedded compiler to work, and knows what to change in it, it might.
[HTC Wildfire S] mansmith:
If you don`t use any dynamic linking(like .dll in windows), you could use this command:

arm-none-linux-gnueabi-gcc -o test [U]-static[/U] test.c
[HTC Wildfire S] b02:
I just wanted to add that unlocking in Serbia and Montenegro costs 10 to 20(MAX) euros...I did some research and have found ~10 shops... I will make thread on that one... if anyone is interested pm me.
[HTC Wildfire S] pjakma:
If that question is to me, by device documentation I mean register level documentation for the memory controller which wpthis.c is programming. The defines are from msm_sdcc.h andproc_comm.h, which appear to be from Linux driver sources, and seem to indicate these are generic to MSM7k chips - so wpthis might actually work as is for either hardware (once you can get it compiled for your target kernel), so it mightn't be needed. However, I'd prefer tor read a proper manual first before running something like that ;).
[HTC Wildfire S] ONeill123:
Yes, and then we need someone who can compile this script. We had one who compiled the old code at first post.
[HTC Wildfire S] no.human.being:
It is for eMMC devices, so the names of the device-files (and offsets?) are gonna be different and the power-cycling thing is moot (possibly even counterproductive?) for NAND devices. No point in trying out all the existing exploits again. There is none for the WFS yet, so we'll need to build our own. Anyone in this forum who got a working toolchain for ARM/ELF/ANDROIDEABI and can point at a download source and explain how to set it up?