yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] Tera Tike:
Would one of the partitions contain the S-Off and CID information.

Why can we not dump an already S-Off device partition and fastboot flash that one partition the a non S-Off phone.

Which partition holds that information and how can I get a dump of that partition?

Sorry if this was ask before.

Here is some information that I got from my phone.

Version:

OEMSBL VERSION: 7.53.39.11M
OEMSBL Build Date: Nov 11 2011 11:37:50
PLATFORM: MARVEL
PID: 112
PLATFORM ID: 0
CPU revision: 0x203C10E1
CPU ID: 0x10002 - 7227
Get UNLOCK status: 0x8

SetInfo:

SetHTCRegionInfo:
block=8,
CID=11111111,
PID=00000112,
IMEI=xxxxxxxxxxx,
SECU_FLAG=0,
UNLOCK=0x19860720

McpValue:

RAM
EBI_COL_ROW_SIZE_CFG CF3
EBI_SDRAM_INTERFACE_CFG1 30C8
EBI_SDRAM_INTERFACE_CFG2 30CF
EBI_SDRAM_MEM_DEVICE_PARAMETER_CFG1 75E9
EBI_SDRAM_MEM_DEVICE_PARAMETER_CFG2 96E9
EBI_SDRAM_MEM_DEVICE_PARAMETER_CFG3 4480
EBI_SDRAM_MEM_DEVICE_PARAMETER_CFG4 9217
EBI_SDRAM_CONTROLLER_CFG F77
EBI_SDRAM_IO_DRVR0 FFFF
EBI_SDRAM_IO_DRVR1 FFFF
EBI_SDRAM_IO_DRVR2 FFFF
EBI_SDRAM_IO_DRVR3 FFFF
EBI_SDRAM_IO_DRVR4 FFFF
EBI_SDRAM_IO_DRVR5 AA5F
EBI1_AXIMEMC_CFG AA0
NAND
NAND_DEV0_CFG1 A6476
FLASH_XFR_STEP1 E00080
FLASH_XFR_STEP2 49F04999
FLASH_XFR_STEP3 85E08580
FLASH_XFR_STEP4 C000C000

Partition:

MIBIB: 0
QCSBL: 10
OEMSBL1: 14
OEMSBL2: 19
HTC: 24
AMSS: 34
AMSSEFS2: 126
FOTA: 166
RESERVED: 170
APPSBL: 172
MISC_MFG: 177
SPLASH_1: 181
SPLASH_2: 186
DEBUG: 191
APP: 211
EXTENDED_ROM: 224

Available monitor commands are:

? [command]
h [command]
mb [StartAddr [Count [Filler]]]
mh [StartAddr [Count [Filler]]]
mw [StartAddr [Count [Filler]]]
setboot [0/1/2/3]
setatcmd [0:SIO/1:UART/2:USB/3:DPRAM]
setsmdloop [0:disable/1:enable]
setmpatch [0x1: CPU Freq/0x2: acoustic/0x4: simdoor/0x8: RTC]
setiot [0:Disable/1:Enable]
setoffmode [0:Enable/1:Disable]
setfaketemp [1:Enable/0:Disable]
eraseall [erase all setting flags]
setdiag [0:USB/1:UART/2:DPRAM/3:SIO]
partition
checksum
format
setinfo
readadc
cego
setgpio
getgpio
gpio
version
powerdown
platformid
pcbid
radata
rcdata
i2ctest
videoamptest
ram_test [n]
Headsetpullhigh [n]
oscchk
battchg
ledtest
rtcchk
wskuid
rskuid
mcpvalue
pwrkeychk
mpu_nand_acpu_rw
clock_config
setunlock_unlock
setunlock_relock
setunlock_lock
setunlock_status
wpmic [PM_VREG] [0/1]
[HTC Wildfire S] no.human.being:
Well of course I have to "modify" it. I have to patch it to S-OFF, that's the first "modification". Then I have to prefix it with a small loop that copies it over from <address_where_kernel_image_gets_loaded> to 0x00000000 and jumps into it. Then I have to build a kernel image from it that can be loaded via Fastboot.

HBOOT runs from 0x00000000 physical. I want to run it from 0x00000000 physical. Basically we NEED to run it from that address, since otherwise we need to adjust ALL addresses that are hardcoded into it. So the "memory offset" is not changed. We load the modified HBOOT code to another address to avoid overwriting in-place. Then we copy it from that address to 0x00000000 (at this point, the "original" HBOOT is no longer running). Then we jump into it and it finds itself at the correct offset.

I'd imagine that most "phone peripherals" are either turned on by the Radio (which does it BEFORE HBOOT is executing) or by the operating system kernel. Why should a bootloader turn "phone peripherals" on? All it has to do is load the actual OS (kernel) code into memory and execute it. That's it! The operating system will do the rest.

Wait wait wait, you're way too fast! I'd be glad if I successfully managed to wrap a small assembler program into an "mkbootimg" boot image and load it via Fastboot. I first want to see that we can execute arbitrary code via Fastboot without booting a full-fledged Linux kernel.

Do you have any idea what kind of "feedback" we could generate from a small piece of assembly code that indicates that it successfully executed?

Printing something to the screen is probably way too complex as it involves interaction with the framebuffer device. Writing something to a file is way too complex because you need a file system driver for that. How complex is it to turn the vibration unit on and off? Or the LCD backlight? Just want to get some kind of feedback that my code is executing. Of course if there's any "easy" way to get characters printed to the LCD that would be perfect, but I think the framebuffer handling is way too complex right?
[HTC Wildfire S] Antagonist42:
I'd look to maybe using 'LED' for charging as it's already up and installed and used to notify if (for example) battery is removed, charging, entering fastboot etc, LCD output I think requires more knowledge of the system ( I'm still trying to figure out what 'John' is with my LCD :confused: ) I think a Flashing Sequence is probably easier...or even the 'Backlight' flashing, the fewer things to program the less things to interfere ;)
[HTC Wildfire S] iuss:
How did you get this? rtask?
[HTC Wildfire S] Tera Tike:
I access this with a Windows 7 computer using Hyper Terminal.

Steps to make it work...

Install the 32 bit Windows driver (scp8600_setup_x86.msi) or 64 bit Windows driver (scp8600_setup_x64.msi)

Press and HOLD Volume UP then press Power. (You should get 3 vibs)

Plug in WFS wait for drive to install then go into the Device Manager Port(COM & LPT)

- Under "SANYO Diagnostics Interface" Change Port Settings - Bits per second to 38400.

Launch Hyper Terminal and set it to the correct COM port and Baud rate.

Here is a zip file I did with all the drivers and Hyper Terminal in case you are using a Windows 7 box too.
[HTC Wildfire S] Antagonist42:
From Initial boot to fastboot/recovery/system running the USB PID and speeds change, this is how I think the mARM and PM7540 keep aARM in a suspended state until SBL etc finish, speed is kept down and keeps aARM with the WDOG_EN as they call it 'patted' or stopped from booting and stops PM7540 from reboot/shutdown, so if you got the wrong speed/PID fastboot is just commercial/end-user fastboot and not say Supervisor/QCOM/HTC fastboot with maybe more commands/peripherals at your disposal
[HTC Wildfire S] no.human.being:
Is it actually called "HTC partition"? Like "fastboot flash htc htc.img"? :D

If this is actually true, after achieving temp S-OFF, couldn't we dump this partition via Fastboot, change the flag, then flash it again via Fastboot? (Or probably we cannot since HBOOT is running on aARM, which probably has no access to it. You probably read all 0xff when reading that offset from within Android, right? I think so, since we didn't recognize this as a difference when comparing memory dumps of S-ON and S-OFF phones.)

You have JTAG access to the device, right? Can you dump the NAND page where this is in, then change the value of what you think is the secu_flag, erase the page and flash the modified version back? Given that this is actually the secu_flag, doing so should toggle the device between S-ON and S-OFF.
[HTC Wildfire S] vbhtt:
These guys are also looking for S-OFF for their phones.. maybe we can join up?

http://xdaforums.com/showthread.php?t=1604300
[HTC Wildfire S] davidang:
i dont think so,cause of our processor
[HTC Wildfire S] munjeni:
Changing 0x01 to 0x00 on emmc bassed devices gives permanent s-off (I am still unsucesfull now to edit htc desire c mmcblk0p7 because partitions is write protected, but good news is I succesfully found a way to generate sim unlock codes and that feature is inplemented in my new cwm touch recovery that is only for desire c... Yes, I will try on aria to change 0x01 to 0x00 and to see if that will give me s-off! But I must to say I have read imei (not tried to read secu-flag) kernel side, sec flag is ~0x20 bute after imei in htc partition, but imei I can read from MSM_SHARED_RAM_BASE + 0xfc060, see how I maded unique bluetooth mac ip and unique wifi ip for htc hd mini (that was missed in hd mini because we had staticaly defined ip that was the same for every device, so I fixed that by reading imei and ^ with some values = final unique ip for every device -> https://gitorious.org/ics-cyanogenm...c25f94e5e329c98415924c94af32a9366ed0aa9/diffs so maybe s-flag lies allso in msm shared ram ? Just for idea you can dump for example 0x20000 butes from msm shared ram by printk to dmesg! You can make that in htc_wifi_nvs.c because nvs code is driven only one time or you can make an simple kernel module that will be used for dumping msm shared ram... I am surre s-flag is after t2T string, if you folow hex dump from emmc devices you can see it is 98 FE 32 54 00 00 00 00 than you can see 0xff (mean empty or mean skip that because its nothing) than you can see 0x01 or 0x00, but you can see 0x00 4 times after t2T, so now if you compare that with nand based devices you can see 98 FE 32 54 00 00 00 00 than 0x01 or 0x00 so that thing about s-flag is the same like on emmc based devices (after 4 times 0x00), I think definitelly that is s-flag... will try :)
[HTC Wildfire S] Tera Tike:
Thank you for that information!!

Since that partition is write protected can we chain load it with a image file that has to security key, ie hboot to over-write it? I hope you get what I am trying to say.
[HTC Wildfire S] munjeni:
I don't know, maybe or maybe not... only I know how revolutionary s-off doing that... you can see revolutionary hboot have extra data before hboot image (see my post in this thread about that, I decompiled that extra data and found that is for moving hboot to right location?), he somehow bypassed signature check (how? Is it special fastboot/adb inside?) and executed extra data while phone was in fastboot mode, than phone was s-off including new hboot installed... it is still mistery :(
[HTC Wildfire S] no.human.being:
Ok, so in principle we could "Radio S-OFF" the device now if we had physical JTAG access because JTAG can directly access NAND and we could read the NAND page containing the secu_flag, change it to zero, erase the page, then write it back all via JTAG that much is sure.

We cannot access this area from Android, since access to it is blocked by the MSM7227 NAND MMU. Therefore it's most likely also inaccessible for HBOOT. Android and HBOOT are both aARM so if it's inaccessible for one, it's almost certainly inaccessible for the other as well. This means that even if we achieved HBOOT S-OFF (like Revolutionary), we still couldn't access the partition where the Radio secu_flag is stored because aARM has absolutely no access to these NAND pages, right? So HBOOT is not gonna have access to this NAND area, so "escalating" HBOOT S-OFF to Radio S-OFF by letting HBOOT write to that partition is not an option because HBOOT probably can't access this partition either, only the Radio can.

So it seems we got two options now. We can achieve Radio S-OFF via JTAG and we can achieve HBOOT S-OFF via software. Basically with HBOOT S-OFF you should be able to do everything you can do with Radio S-OFF. It's just that you're gonna lose HBOOT S-OFF when flashing a stock HBOOT (either explicitely or via RUU), while Radio S-OFF will always stick since you can't differentiate a device that was Radio S-OFFed from a device that was shipped S-OFF.

What's more, I believe that we could also achieve some kind of HBOOT S-OFF that is entirely volatile, which means that we could perform an exploit that will "chainload" an S-OFF HBOOT and the phone then behaves as S-OFF and on the next reboot, S-ON is restored. Remember that we basically do a two-step process. We boot code via Fastboot that "chainloads" another (patched) HBOOT image. Then we use that patched HBOOT image to flash the patched HBOOT to NAND via Fastboot. If we omit the second step, we should have something like a "temporary S-OFF". The device should be S-OFF until the next reboot and then revert to S-ON. This kind of S-OFF can most likely be achieved without ever writing to NAND so that it's almost impossible to prove by HTC. This might turn into an interesting option. I haven't heard of anything like this before for the other devices.
[HTC Wildfire S] Tera Tike:
Humm...I understand most of what you are saying, but I have a problem the HBoot can not access that partition.

When I use my XTC-clip it run a special diag file on the microSD card(Goldcard) and does some logic/security check thru the SIM card port. So then the NAND can be accessed via HBoot, right???
[HTC Wildfire S] munjeni:
About "true" s-off (not patched hboot with disabled s-on) we have permanent s-off because I think htc partition will newer be overwriten while we flash an ruu because there is unique imei and a lot of other things like device sn ...etc, so if ruu overwrite htc partition we will have losen unique phone things...etc I am not surre, but I am surre permanent s-off stay permanent whenewer we flash something, its still permanent and will not be overwriten by flashing an stock hboot or radio! First time when I connect my old aria to jtag I will change 0x01 to 0x00 and will let you know! Any one researched in hboot for (offset ~0x480820) maybe hboot have part of code for disabling/enabling security?:D

---------- Post added at 04:18 PM ---------- Previous post was at 04:08 PM ----------

Yes, that principe we used in htc hd mini (sspl), we goot temporally overwriten spl in memory and had temporally security-off spl runing, but we was still unsucesfull to overwrite stock spl (maybe unsucesfully patched hboot, or maybe perfect spl?)... still some well known guys from xda like Cotulla (he made an bootloader that is abble to boot android, wince 6, windows 7 ...etc)htc hd2) say its not possible to htc hd mini and say spl inside that phone was perfect spl still un-overwriteable...I tried everything to overwrite stock spl but was totaly unsucesfull with a lot of bricks and a lot of jtaging again again again, so I leave that phone...
[HTC Wildfire S] no.human.being:
No I think that all the DIAG file does is ask the Radio to turn security off.

If you send "AT@SIMLOCK?AA\n" to the Radio, the Radio will return the string "@secu_flag: 1\n" on an S-ON device and "@secu_flag: 0\n" on an S-OFF device, along with a success code. This is the actual Radio secu_flag, so on a device that was S-OFFed by say Revolutionary it will still return "@secu_flag: 1\n" since the Radio is still S-ON on such a device, only the HBOOT is S-OFF. In contrast, on a devie that was S-OFFed by xtc-clip, it will return "@secu_flag: 0\n" since XTC-Clip achieves true Radio S-OFF. The same goes for devices that were shipped S-OFF.

If you send "AT@SIMLOCK=7,0\n" (or "AT@SIMLOCK=8,0\n", the information available is inconsistent so I'm not sure which one it is, but it seems like "AT@SIMLOCK=7,0\n" is mentioned more often so I assume that it is correct) to the Radio, the Radio will return an error code. The xtc-clip emulates some kind of engineering SIM card that the Radio checks to be present before turning security off on request. I think that if you were to send "AT@SIMLOCK=7,0\n" to the Radio while having an xtc-clip connected to the device, the Radio will return success and the phone will be Radio S-OFF.

I have already verified "AT@SIMLOCK?AA\n" returning "secu_flag: 1\n" and "AT@SIMLOCK=7,0\n" returning an error code on my phone's Radio. So I don't think that the DIAG file checks for the engineering SIM. I think the Radio does (mARM has direct I/O access while aARM has not, so DIAG running on aARM cannot query the SIM at all, it can only RPC the Radio). And I think all that the DIAG file does is sending "AT@SIMLOCK=7,0\n" to the Radio and the Radio only does this when the engineering SIM is present. You can also see that on CDMA phones, you can achieve S-OFF with the DIAG file and a goldcard alone without a need for the clip. This is because the Radio is different on CDMA phones (however the DIAG file is the same!) so it's probably that, contrary to the GSM Radio, the CDMA Radio requires no authentication on that operation. I'd imagine that sending "AT@SIMLOCK=7,0\n" to the Radio on a CDMA phone will immediately turn the phone S-OFF and I think that sending it on a GSM phone with an xtc-clip attached will do the same.
[HTC Wildfire S] munjeni:
AT@SIMLOCK?** is not only to achieve s-flag its allso for achieving sim lock type, sim lock type have many diferent locks types like simlock?10, simlock?20 ...etc... I am now very curious about 0x01 to 0x00 thing, I think I will try that now :laugh: first I will install stock hboot and will patch htc partition to see if I can get true s-off
[HTC Wildfire S] kalaker:
If we move or edit the HTC partition, even if that doesn't stay forever, the device will be S-OFF, so at that point, we can get 100% true radio S-OFF, couldn't we? Can we use S-OFF to become more S-OFF?
[HTC Wildfire S] munjeni:
News for you. Now I can confirm changing 0x01 to 0x00 will give s-off, but bad news is I'm unable to install another hboot or radio...etc (not allowed)... its still no.human.being is right about "locked" hboot, so hboot have allso lock? So question is whats use of radio s-off :confused: You can see that I have s-off with stock hboot:

C:\Documents and Settings\adb>fastboot getvar all
INFOversion: 0.5
INFOversion-bootloader: 1.02.0000
INFOversion-baseband: 7.13.35.13
INFOversion-cpld: None
INFOversion-microp: 031b
INFOversion-main: 2.37.709.4
INFOserialno: HTxxxxxxxxxx
INFOimei: xxxxxx
INFOproduct: liberty
INFOplatform: HBOOT-7227
INFOmodelid: PB92******
INFOcidnum: 11111111
INFObattery-status: good
INFObattery-voltage: 3888mV
INFOpartition-layout: HTC
INFOsecurity: off
INFObuild-mode: SHIP
INFOboot-mode: FASTBOOT
INFOcommitno-bootloader: dirty-45bf9871
INFOhbootpreupdate: 11
INFOgencheckpt: 0
all: Done!

Its still like I need enginering hboot to have full s-off ? Maybe I can get something with htcdev unlocked bootloader... I still want to have posibility for flashing unsigned code, radios...etc but I was tried everything without luck.

Edit:

After installing revolutionary and again stock hboot, s-off is still there, so I have permanent s-off! Hmmm, maybe radio have unlocked commands now like at@security ...ideas?

Edit:

Hey, what I not tried is: maybe nand is unlocked now with radio s-off ? :)
[HTC Wildfire S] Tera Tike:
Very Good indeed. Question can you run the diag.nbh file to see if that would reset the rest of the security flags?
[HTC Wildfire S] munjeni:
No one found diag.nbh for htc aria... is that file for every model whatever it is aria or wfs or that file is only for "one" phone ?

Edit:

I think hboot have nothing with radio s-off (like no.human.being sayd that hboot runing in aarm and have nothing with radio...), I think hboot looking for another "flag" (for sure its not this flag that I changed to 0) in order to get unlocked by self?
[HTC Wildfire S] Tera Tike:
Ok I think it is different for each. I will run the XTC-clip tonight and see if it generates the file for you, and upload it tomorrow.
[HTC Wildfire S] no.human.being:
S-OFF and stock HBOOT should allow you to flash e. g. an unsigned Radio via "PG76IMG.NBH" (that's how it's called for WFS, don't know how it's called for Aria since it's model-dependant) on the MicroSD.

Fastboot access to HBOOT ("fastboot flash recovery ...", "fastboot boot ..." etc.) is only possible with an unlocked bootloader (e. g. an HTCdev bootloader).

When you combine both, unlocked bootloader and S-OFF, you should be able to do flash unsigned Radio and bootloader via Fastboot (e. g. "fastboot flash radio ...", "fastboot flash hboot ...").
[HTC Wildfire S] kalaker:
From my experience with the marvelc, the best thing to do is to unlock your boot loader which shouldn't be an issue, as I do not think the unlock RUU touches the "htc" partition, which from what I've read is where your S-OFF is currently located.

Then execute "fastboot flash hboot <hboot>.nb0 and you will have a new HBOOT. The same goes for the radio.

Also, if you don't want to do fastboot commands, it's best to put it in a PG76IMG.zip which a radio and rcdata and android-info.txt.
[HTC Wildfire S] no.human.being:
The RUU which installs the unlockable bootloader only flashes a newer HBOOT which supports more Fastboot commands. Then you do a "fastboot oem get_identifier_token", which generates a cryptographic key that you pass to HTC. Then HTC will send you another key file called "unlock_code.bin" via e-mail. To complete the unlock process, you put the phone into Fastboot mode again with the unlockable bootloader and do "fastboot flash unlocktoken unlock_code.bin". The bootloader will verify the code (probably using public-key cryptography) and unlock.

The procedure involving HTC and the device token can be fully bypassed using a tool developed by theq86. Basically, it writes the word "HTCU" to a specific offset in the "misc" partition. Afterwards, the bootloader is considered unlocked. All the registration and public-key cryptography performed by HTC will be bypassed. Just writing "HTCU" to the right address does the trick. :D

Yes, but I do actually prefer Fastboot over the PG76IMG.nbh methods.

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

I think HBOOT queries the Radio using "AT@SIMLOCK?AA" and if Radio responds "@secu_flag: 0" it is S-OFF and if Radio responds "@secu_flag: 1" it is S-ON. However, you can also achieve S-OFF in HBOOT without actually turning the secu_flag in the Radio off if you patch the subroutine that queries the Radio so that it doesn't query the Radio at all, but always reports S-OFF. The latter is exactly the modification that our "inject" exploit performs (and also the one that Revolutionary performs). The problem is that we cannot flash the patched HBOOT due to signature fail. You'd need JTAG to flash it or Radio S-OFF, which can also only be achieved via JTAG. This is why we're searching for a way of "chainloading" the patched HBOOT replacing it in RAM without requiring it to be flashed. The phone should then behave S-OFF and then you can talk to the "chainloaded", S-OFF HBOOT and make it flash itself because it will no longer verify signatures.