yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] BeciMester:
Well it's better than nothing. Whatever floats the boat...:D

I'm fairly positive about the subroutine. It gets called a lot, and more importantly it's very very similar in behaviour to the one in the old 0.90 hboot, and that hboot is nearly plaintext compared to the new one. :D Check for yourself: objdump the newest 1.09.0099 hboot with offset 0x9d000000.

The secu_flag checker routine starts at 0x9d008b58. A good example that uses it is some sort of a command interpreter which actually prints "security on" or "security off" in a tricky way. The start of this routine is 0x9d0029f0, the part in question is at 0x9d002e74: it loads a pointer to the word "security", then I presume does some checking (call to 0x9d020f68, probably to compare the word with the user input) and gets the result back in R0. If R0 is not 0, moves on to the next word, otherwise calls to 0x9d008b58 (our flag-checking sub), and also gets the result in R0. If R0==0, loads a pointer into R1 that ultimately points to 0x9d066c34 ("off"), loads #4 into R2 ("off"+0x0, 4 character null-terminated string), calls what I presume is some printf routine and quits. If R0 was not 0, loads a pointer into R1 that points to 0x9d0653bc ("on"), loads #3 into R2 ("on"+0x0, 3 characters this time), calls the printf thing and quits.

Now. The actual checker part: calls a subroutine that returns some value in R0, if it's not 0 then loads #1 into R0 and quits. But if R0 is indeed 0, it does some additional checking by calling 0x9d007af0, gets a value, takes the 5th bit and returns that.

Ultimately, the parts that call this sub check R0 for 0, and if it's not 0, assume the flag is set. Therefore: all we have to do is make it return 0 without doing anything else.

Now, sleep. :o
[HTC Wildfire S] no.human.being:
Should be ...

ANDROID!

... when unchanged and ...

AFFEAFFEAFFE

... when flash succeeded, right?

---------- Post added at 05:37 AM ---------- Previous post was at 05:33 AM ----------

Do you also know where it's on the 1.08.0099 HBOOT? It's what I'm having on the phone.
[HTC Wildfire S] theq86:
exactly. then I tried to flash boot.img again

nandwrite -s 0 /dev/mtd/mtd2 boot.img

Here comes no error, but ... looking at the so produced boot.img there was again to read:

41 46 44 40 41 40 44 01 40 42 06 00 00 00 00 00 | AFD@A@D.@B......

Interesting are also the outputs of flash_image and nandwrite when writing the boot.img

here flash_image

flash_image boot /sdcard/boot.img
flashing boot from /sdcard/boot.img
mtd: successfully wrote block at c7e0400000000
mtd: successfully wrote block at c7e0400020000
mtd: successfully wrote block at c7e0400040000
mtd: successfully wrote block at c7e0400060000
mtd: successfully wrote block at c7e0400080000
mtd: successfully wrote block at c7e04000a0000
mtd: successfully wrote block at c7e04000c0000
mtd: successfully wrote block at c7e04000e0000
mtd: successfully wrote block at c7e0400100000
mtd: successfully wrote block at c7e0400120000
mtd: successfully wrote block at c7e0400140000
mtd: successfully wrote block at c7e0400160000
mtd: successfully wrote block at c7e0400180000
mtd: successfully wrote block at c7e04001a0000
mtd: successfully wrote block at c7e04001c0000
mtd: successfully wrote block at c7e04001e0000
mtd: successfully wrote block at c7e0400200000
mtd: successfully wrote block at c7e0400220000
mtd: successfully wrote block at c7e0400240000
mtd: successfully wrote block at c7e0400260000
mtd: successfully wrote block at c7e0400280000
mtd: successfully wrote block at c7e04002a0000
mtd: successfully wrote block at c7e04002c0000
mtd: successfully wrote block at c7e04002e0000
mtd: successfully wrote block at c7e0400300000
mtd: successfully wrote block at c7e0400320000
mtd: successfully wrote block at c7e0400000000

here nandwrite:

nandwrite -s 0 /dev/mtd/mtd2 /sdcard/boot.img
Writing at 0x00000000
Writing at 0x00020000
Writing at 0x00040000
Writing at 0x00060000
Writing at 0x00080000
Writing at 0x000a0000
Writing at 0x000c0000
Writing at 0x000e0000
Writing at 0x00100000
Writing at 0x00120000
Writing at 0x00140000
Writing at 0x00160000
Writing at 0x00180000
Writing at 0x001a0000
Writing at 0x001c0000
Writing at 0x001e0000
Writing at 0x00200000
Writing at 0x00220000
Writing at 0x00240000
Writing at 0x00260000
Writing at 0x00280000
Writing at 0x002a0000
Writing at 0x002c0000
Writing at 0x002e0000
Writing at 0x00300000
Writing at 0x00320000
[HTC Wildfire S] no.human.being:
0xc7e0400000000 = 3.516.255.365.496.832 in decimal. So our phone has at least 3.5 Petabytes of Flash. Now that's interesting! :D

Both utilities fail to restore the boot image? So now you're stuck with a corrupted boot partition? :eek:
[HTC Wildfire S] theq86:
well, have you any clue how nandwrite works? :D

---------- Post added at 05:54 AM ---------- Previous post was at 05:52 AM ----------

naah mate, only nandwrite produces crap

flash_image works fine

and even if, a corupted /boot partition is nothing serious. think of if I immediately tried nandwrite on mtd7 :D that would have been serious :D
[HTC Wildfire S] no.human.being:
I also thought so, after all you can image it back from within recovery. However, in CWM there's some "never ever do this under normal circumstances"-kind-of-warning for the "format boot partition" option. Don't ask me why. I also thought that anything could be restored as long as the Radio partition is untouched.

Then at least we wouldn't have purchased the JTAG interface without a reason. :D

I'll go to sleep now. We've actually achieved a lot. :D
[HTC Wildfire S] theq86:
Never press the red button ... oooops

yes. and days of finding out how to attach the interface and how to use it to restore the radio :D

good night, gonna sleep, too,

And tomorrow, brain, we will get the world leadership (or at least find out how we can make nandwrite write what we tell it)
[HTC Wildfire S] no.human.being:
And then we'd have to pull the Radio from another device (probably mine) and then you'd have my IMEI. Then you use your phone for arranging the next big drug deal. Next day the police arrests me and searches my house. :D

Right. Let's hope BeciMester knows where the "flag checking" routine sits in HBOOT 1.08.0099. If he does, I'm gonna offer my phone for testing the exploit.

I'm gonna go to sleep as well.
[HTC Wildfire S] mstfkaratas:
hi nbh and theq86, i have an idea for finding s-off part of radio dumps without xtc clip. i have a xtc-clipped wfs and i can freely change my hboot by extracting hboots from rom.zip and packaging to pg76img.zip with androidinfo.txt, and i can change radio firmwares without loosing s-off, this shows us flag checking parts of radio dumps are independent from radio and hboot versions. And cant changable by any ruu.

To sum up if we compare nhb's, theq86's and my radio dumps, the security value should be the same between nhb and theq86, and different from mine.

And there is one more thing, i think your mtd7 dumps dont contain only radio firmware, and security thing should be some where outside of radio firmware but inside of mtd7 dumps, because s-off doesnt affected by radio changes.

I tried to tell you my thoughts with my bad english i hope you understand what i want to say.
[HTC Wildfire S] pihug12:
That's what we said some pages ago. Many thanks if you are willing to do that for us !

I see you're from Turkey : is your phone working without problem with the European stock firmware ?

If yes, you're ready to go !

0- Backup all your data.

1- Launch RUU_Marvel_S_HTC_Europe_2.13.401.3_Radio_47.23c.35.3037_7.54.39.28M_release_236989_signed.exe

http://www.shipped-roms.com/index.php?category=android&model=Marvel

2- Launch PG7610000_Marvel_hboot_1.09.0099_2.13.401.3_0210_R.exe

http://www.htcdev.com/ruu/PG7610000_Marvel_hboot_1.09.0099_2.13.401.3_0210_R.exe

Then, you should have HBOOT-1.09.0099 + RADIO-7.54.39.28M.

I don't know if you have to go through the HTCDev procedure however.

3- Use these steps to dump the radio.img :

http://xdaforums.com/showpost.php?p=23082656&postcount=1143

You have to use recovery-clockwork-5.0.2.8-marvel.img available here :

http://download.clockworkmod.com/recoveries/recovery-clockwork-5.0.2.8-marvel.img

You will have to use this fastboot command :

fastboot -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)" boot recovery-clockwork-5.0.2.8-marvel.img

4- Zip your dump and send it on mediafire.com. You should use a password and give it to the people you trust the most in this thread (no.human.being, theq86, BeciMester, ...).

*se-nsei. should update the title and the first post of this thread.
[HTC Wildfire S] heavy_metal_man:
goodmorning gentlemen! time to win lol

if this was the case then how could the xtc clip work on multiple hboots and REGARDLESS of the radio version? hell the xtc clip even does these new htcdev unlock hboots. i think it has to stay in a solid location. it would have too.

and as he said he wouldnt need to run the ruu since he is s-off. just extract the update.zip, remove everything aside from the radio and the hboot rename it to pg76img.zip (i think thats it, i use pc49img.zip, on the old buzz lol) and then just flash it in hboot ;)

that being said you could just dump every radio and hboot and we could compare them all to see if a solid area shows up the collaborates with the s-on hboots. then we would have the key!
[HTC Wildfire S] BeciMester:
I do know where it is, I'll let you know tonight. It's actually very close to the one I posted above.

(I'm on my phone...)
[HTC Wildfire S] theq86:
He was meaning, if we concentrate on HBOOT patching first.

Then we do have to provide images for every radio, because the size and the offsets of the radio parts change.

Of course, if we get the real secu_flag offset, we will not need to make one exploit for every radio :D
[HTC Wildfire S] heavy_metal_man:
see now im confused, if that was the case why does revolutionary for the wildfire only have one hboot and people can flash any radio they want without it changing??

lets just hope for radio information eh?;)
[HTC Wildfire S] BeciMester:
They can flash any radio because the hboot doesn't bother with the flag, it's modified to report that the flag is off. It doesn't even care if the flag ceases to exist. Same with the xtc-clip I believe, it does not mind the radio version coz it asks the radio via a radio command to switch the flag off for it. And, since the ribbon cable is attached, the radio is fooled into thinking the clip is a HTC fella, and it fulfills the request.

(I'm on my phone...)
[HTC Wildfire S] no.human.being:
No it doesn't have to. It's just that a pointer to its location. Or a pointer to a pointer. Or a pointer to a pointer to a pointer. Or any possible level of indiretion has to remain in a fixed location.

I'm just thinking about how file systems work. They work with so-called "inodes" (intermediate nodes).

Some inode in a fixed place points to an inode of the root directory, which in turn points to inodes of subdirectories and so on. This goes on and on until you reach an inode which discribes a "file".

This one then points to inodes, which point to inodes, which point to inodes, which point to inodes, ... (this tree structure goes VERY deep, especially for large files) ... which AT SOME POINT point to 4 KiB large pages of file content. :D

Now when you change a byte in a file, modern file-systems do not overwrite in-place since that would be too dangerous in case of a power failure for example. Instead, they just read one page from the drive, modify it and then write it somewhere into free space.

Now if the system crashes after doing that, then some junk has been written into free space and the changes are not visible since nothing points to them, but at least the file system is still in a "consistent state" (if you follow the pointers you'll still see the old tree structure pointing to the old data pages which are totally untouched).

However, if the write really is to "succeed", the file system is going to "update" the tree structore from bottom to top (in the same "write the new inode somewhere else, then update the parent node by writing it somewhere else, ..."-like fashion) until it reaches the "pointer to the root of the tree". Realize that if the system crashes BEFORE that pointer is updated, you still see all the old structures, you just have one page and lots of inodes written to free space. However, if you update the pointer to the root, you have the file system in the "new state". This is how changes to the file system are made "atomic" nowadays.

If you were to observe a modern POSIX file system (say Ext4) writing, you'd see the drive writing all over the place in a totally random manner (new inodes are allocated at random addresses and new data blocks are too, Unix doesn't try to keep fragmentation low, it rather tries to "fragment as much as possible" and it's actually rather good for performance I can tell you, especially on modern SSDs since these have fast random access speed) as it updates these endless "pointers to pointers to pointers to ... data"-structure which essentially consists of hundreds of millions of pointers scattered all over the drive's surface.
[HTC Wildfire S] heavy_metal_man:
f**K.:( well, gonna need more dumps then :P
[HTC Wildfire S] MrTaco505:
I could provide a dump but idk how to do it
[HTC Wildfire S] heavy_metal_man:
it was like 1 page back man....
[HTC Wildfire S] no.human.being:
And please provide details whether you are on Radio 7.53.x/7.54.x, S-ON/S-OFF, Locked/Unlocked? Thanks!
[HTC Wildfire S] seaskyways:
i will try to dump my thing , i am working on it ! hboot 1.09.0099 , radio 7.54.39.28M , and by the does the USB brick cause a radio problem ? cuz i have a Usb brick :(
[HTC Wildfire S] no.human.being:
Please also provide the information whether you are S-ON/S-OFF and Locked/Unlocked. Thanks.

I'm already setting up "prototype frameworks" for the exploits.
[HTC Wildfire S] seaskyways:
ok ok ! just dumped my radio thanks nhb ! it seems to be big which means i will uploud it at night since our down/uploads are very limited , so wish it benefits !

s-on , unlocked bootloader , tried it while on locked , doesn't work to boot the thing , it gives an error + I took my radio via adb pull see :
[HTC Wildfire S] MrTaco505:
Im:

***UNLOCKED***

MARVEL PVT SHIP S-ON RL

HBOOT-1.08.0099

MICROP-0354

RADIO-7.53.39.03M

Nov 28 2011, 19: 09:21

im now going to make the radio dump
[HTC Wildfire S] no.human.being:
Ok, same configuration as mine so I can compare against my own handset.
[HTC Wildfire S] seaskyways:
Guys does this mean anything of pointer of somekind , true it is a "string" but i dunnow , i wanna help :D
[HTC Wildfire S] MrTaco505:
will this work on windows 32-bit? because the instructions show its for linux.
[HTC Wildfire S] seaskyways:
my hboot specs

*** UNLOCKED ***

MARVEL PVT SHIP S-ON RL

HBOOT-1.09.0099

MICROP-0451

RADIO-7.54.39.28M

FEB 8 2012,18:29:31

this is my stuff thing , i think you can compare it to some others ! by the way the radio is 40 MB , which is very :eek: (at least for my connection) expcet this radio to be uploaded tomoroow or today !
[HTC Wildfire S] no.human.being:
This here is going to work on Windows.

Just omit the "editing /etc/udev/..." part (not relevant for Windows), download Android SDK for Windows instead of Linux to install the toolchain, and don't write "./fastboot", "./adb", but only "fastboot" and "adb". Rest should be the same (obviously on the remote shell with the handset you can use "Linux" commands since an Android kernel is running and Android is more or less "Linux").

---------- Post added at 04:12 PM ---------- Previous post was at 04:11 PM ----------

Compress it! It compresses extremely well. Also you might want to use password protected archive and give us the password, if you don't want everyone to steal your IMEI.
[HTC Wildfire S] seaskyways:
:eek::eek::eek::eek::eek: HAHAH it was 48 MB after compresses it is 8 MB !! i will upload it to xda directly !! I will secure it by some code and I will pm nhb and theq86 the pass and any other dev that wills to help cuz i am dieing to have S-off and partition my PHONE !! I WILL RULE !!
[HTC Wildfire S] heavy_metal_man:
i got interested in this method and tried to do it on my buzz, just to see what it said :P currently trying it on a windows system and when trying to execute the 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 command it says

downloading 'boot.img'...

OKAY [ 0.900s]

booting...

FAILED (remote: not allowed)

finished. total time: 0.900s

any ideas?
[HTC Wildfire S] seaskyways:
you're sure you have an unlocked bootloader ?? cuz while it is on locked bootloader you'll get that error
[HTC Wildfire S] heavy_metal_man:
i have s-off by xtc clip. i just wanted to see if this would map out the partitions on the buzz as well. the pramiters are probably wrong for my device but i jut wanted to see if it worked like.

additional. i am using the correct cwm recovery image for my device :)

additional 2. tried to run this from just hboot as opposed to fastboot and it says failed (status malformed (1 byte))
[HTC Wildfire S] no.human.being:
Yes Buzz has entirely different page tables. But Buzz bootloader probably doesn't support booting from RAM via Fastboot. HBOOT 0.90.0000 for Marvel also doesn't support. Only the HBOOT 1.08.0099 and HBOOT 1.09.0099 do support it on Marvel, so I think Buzz firmware is way too old.
[HTC Wildfire S] heavy_metal_man:
bummer. so its very unlikly this method would work for the buzz even if tweaked then?
[HTC Wildfire S] seaskyways:
My Radio.img

here is my radio since it doesn't exceed the limit i upload it just here ! Here it is devs , find the password in your PM box !
[HTC Wildfire S] MrTaco505:
@nhb

after i start the adb sever i went ahead to "adb shell" command but it gives me an error that device is not found

i have all my drivers installed any ideas?
[HTC Wildfire S] no.human.being:
Fastboot utility finds the device but adb shell does not?

Just to check: You must have the recovery already booted (via Fastboot) before you can open the adb shell.
[HTC Wildfire S] theq86:
this may be in case of disabled usb debugging. adb needs it, fastboot does not.

forget it, I did not read that happens in recovery mode :D
[HTC Wildfire S] seaskyways:
simply turn on USB debugging and if you do then unplug and replug ...

---------- Post added at 06:11 PM ---------- Previous post was at 06:10 PM ----------

LOL , me too :D now i remembered :P
[HTC Wildfire S] MrTaco505:
ok after i place the command "cat /proc/mtd" i get this

C:\Users\user\Downloads\download\android-sdk_r16-windows\android-sdk-windows

\platform-tools>adb start-server

adb server is out of date. killing...

* daemon started successfully *

C:\Users\user\Downloads\download\android-sdk_r16-windows\android-sdk-windows

\platform-tools>adb shell

~ # cat /proc/mtd

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"

~ #

wheres mtd7?
[HTC Wildfire S] no.human.being:
Did you supply the entire fastboot command line including kernel parameters?

You're on the HBOOT 1.08.0099, so this one is the Fastboot command for you:

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-clockwork-5.0.2.8-marvel.img
[HTC Wildfire S] MrTaco505:
ohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh ok thanks il try again:D

EDIT: Im not sure if this is the secu_flag but i opened up a radio.img and this is what i got
[HTC Wildfire S] no.human.being:
No, thanks. I'm having HBOOT 1.08.0099 on my phone and know how to extract it from the Radio dump.

No it's not. We already knew about that one. :D
[HTC Wildfire S] theq86:
News from nandwrite. I still could not figure out how to write changes. I tried several things. writing text files, binary files and never anything shows up as flashed.

But I found out that nandwrite will write in 2K blocks. So when I have found out how to write properly we have to cut out a 2k block around the secuflag and just have to give nandwrite the correct start address.
[HTC Wildfire S] MrTaco505:
@nhb heres my radio, i finnaly got it :D

im going to PM you the link
[HTC Wildfire S] no.human.being:
radio-nohumanbeing: 50.069.504 bytes
"standard sized" RADIO-7.53.39.03M, UNLOCKED, S-ON

radio-mrtaco505: 50.069.504 bytes
"standard sized" RADIO-7.53.39.03M, UNLOCKED, S-ON

radio-mstfkaratas: 50.069.504 bytes
"standard sized" RADIO-7.53.39.03M, UNLOCKED, S-OFF

radio-seaskyways: 40.632.320 bytes
"standard sized" RADIO-7.54.39.28M, UNLOCKED, S-ON

radio-pihug12: 40.632.320 bytes
"standard sized" RADIO-7.54.39.28M, UNLOCKED, S-ON

radio-theq86: 40.632.320 bytes
"standard sized" RADIO-7.54.39.28M, UNLOCKED, S-ON
[HTC Wildfire S] theq86:
I'm S-ON, BL Unlocked, HBOOT 1.09.0099 RADIO-7.54.39.28M
[HTC Wildfire S] pihug12:
Same config as theq86 for me.

I made a topic to get an unmapped memory dump of a S-OFF phone with HBOOT 1.09.0099.

The bootloader must be unlocked to be able to use the fastboot command, right ?

Is it possible to get the dump of a phone with a locked bootloader ? Anyway, it will be useless for us.
[HTC Wildfire S] MrTaco505:
i did a redo and this is exactly what i did

Microsoft Windows [Version 6.0.6002]

Copyright (c) 2006 Microsoft Corporation. All rights reserved.

C:\Users\Owner>cd C:\Users\Owner\Downloads\download\android-sdk_r16-window

s\android-sdk-windows\platform-tools

C:\Users\Owner\Downloads\download\android-sdk_r16-windows\android-sdk-windows

\platform-tools>fastboot -c "mtdparts=msm_nand:0x00100000@0x1ff00000(misc),0x005

00000@0x02fc0000(recovery),0x00340000@0x034c0000(boot),0x10400000@0x03800000(sys

tem),0x02300000@0x13c00000(cache),0x09600000@0x16900000(userdata),0x00a00000@0x1

5f00000(devlog),0x02fc0000@0x00000000(radio)" boot recovery-clockwork-5.0.2.8-ma

rvel.img

downloading 'boot.img'...

OKAY [ 1.643s]

booting...

OKAY [ 0.001s]

finished. total time: 1.644s

C:\Users\Owner\Downloads\download\android-sdk_r16-windows\android-sdk-windows

\platform-tools>adb start-server

adb server is out of date. killing...

* daemon started successfully *

C:\Users\Owner\Downloads\download\android-sdk_r16-windows\android-sdk-windows

\platform-tools>adb shell

~ # cat /proc/mtd

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"

~ # mount

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)

/dev/block/mtdblock4 on /cache type yaffs2 (rw,nodev,noatime,nodiratime)

/dev/block/mmcblk0p1 on /sdcard type vfat (rw,nodev,noatime,nodiratime,fmask=000

0,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed

,errors=remount-ro)

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

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

~ #

the radio is 47.7MB in size idk why the file size changed
[HTC Wildfire S] no.human.being:
Now what you've sent me is exactly 50.069.504 bytes, like mine. Thanks a lot, this one looks right! :D

Now I got 5 radio partitions flying around. Now this will certainly keep me busy for some time. :D

Just let us know whether you're S-ON/S-OFF and LOCKED/UNLOCKED MrTaco505.