Do we rlly need S-OFF?

Lately there has been a lot of confusion about if we - users - rlly need S-OFF on our devices. I think it's time to make this case as clr as possible, and clr up any remaining doubts.
First of all, S-OFF stands for "Security OFF" and S-ON for "Security ON". It's a term specific to devices (and refers to digital signature checking on the bootloader "hboot"). Retail devices always come with SHIP S-ON locked bootloaders. Hboot can also be found in an engineering version (ENG as opposed to SHIP), but it's not sy to get such a device.

You should also know the "fastboot" term: it is a diagnostic protocol used primarily to modify the flash filesystem via a USB connection from host computer. After enabling the protocol on the device itself (entering "fastboot" mode from inside the bootloader), it will accept a specific set of commands sent to it via USB using a command line, for example "fastboot flash boot boot.img" or "fastboot erase cache".

What's the main difference between S-ON and S-OFF from the end-user point of view?

With S-OFF you can:

Flash in fastboot original parts of the firmware like: Trust Zone (tz.img), Resource Power Manager (rpm.img), Advanced Digital Signal Processor (adsp.img), bootloader (hboot.img), Radio Config Data (rata.img), Splash Screen and others, very often device specific firmware like Consumer IR (cir.img) for the television remote controller in One.Flash in fastboot custom parts of the firmware above, however I've never seen in my life anyone compiling custom rpm.img or tz.img. I've seen custom bootloaders and Splash Screens only. You can also flash modified radio.img but there is rarely anyone out there who does this.Use more advanced fastboot commands, for example you can change the CID (Carrier ID) of your device or even MID (Model ID). And this one is the most important one in the context of this article.Reset the Tampered flag, so your device does not show up as "Relocked" if you relock your bootloader.
For about 2 yrs you have been able to unlock bootloaders of selected devices on the htev.com webpage. your bootloader results in an "UNLOCKED" message in the bootloader screen, and allows you to use some of the fastboot commands. For example system, boot and recovery partitions are no longer locked and you can flash a custom boot or recovery onto your device. This doesn't mn S-OFF, but it does give you some more control over your device.
Sometimes there are differences specific to the SoC ("System on a Chip") of ch device. Both One X and One X+ (nVidia Tegra 3) have locked out the capability to flash the boot partition from inside recovery, even if your bootloader is unlocked. It is possible to flash the boot partition only via the "fastboot flash boot <boot name>" command. On the newest smartphone - One (Qualcomm Snapdragon S600) you can use either fastboot or adb shell (dd if=/... of=/...) to write the boot partition.
Do we rlly need S-OFF?

No, we don't. So what do we need? Because we surely need something. But to understand what we need, it's important to rlize where the problem is first.
First of all, comparing devices with devices is a pointless activity. Never do that. Why? Because they are all S-ON (they call it Secure Boot), and updates for devices contain the following (based on my experience with Galaxy ):
bootloader.imgrecovery.imgGSM radioMA radio (in case of MA device)That's all. On device you can flash the original bootloader or radio using the "package_extract_file" command in the updater-script.When relses a major update, however, you will get:
adsp.imgcir.imgdzdata_16g.hdrdzdata_16g.imgdzdata_32g.hdrdzdata_32g.imgdzdata_64g.hdrdzdata_64g.imgbootloader.imgradio.imgrecovery.imgrpm.imgsbl1-1.imgsbl1-2.imgsbl1-3.imgsbl2.imgsbl3.imgtp.imgtz.imgmore...See the difference? This firmware s (if updated) are stored inside firmware.zip inside the OTA update. And without S-OFF you can manually update (using fastboot commands or command shell) only recovery, boot, system and sometimes radio. Other partitions are locked and you can't update firmware s other way then only with signed firmware.zip.
Content of OTA update
However, very often, flashing only the content of the system and boot partitions is not enough to have the device fully working. For example, in the One X it was necessary to use the new bootloader together with the official Jelly Bn update, otherwise your device wouldn't boot with an older bootloader. This is why flashing a custom ROM for an device is nowhere the same as flashing a custom ROM on a device. Apart from having the latest system files, you need to have the latest firmware.zip package flashed as well.
Because sells their devices to different carriers around the world, they need to accept some requirements. For example carrier branding. Because of carrier branding, has more than one version of the RUU (ROM Update Utility) for ch device. To indie the difference between the branded and un-branded versions of the same device, used so called "CID" s.
To find out your current CID (together with some other useful info) you can use the "fastboot gear all" command. Also, keep in mind that every OTA update checks CID/MID s before it will start to your system:



ifelse( is_ship_bootloader(getprop("ro.bootloader")) == "t" ,
assert(check_cid(getprop("ro.cid"), "00000000" , "11111111" ,
"22222222" , "33333333" , "44444444" , "55555555" , "66666666" ,
"77777777" , "88888888" , "99999999" , "__001" , "__E11" ,
"__102" , "__203" , "__405" , "__Y13" , "__304" ,
"__032" , "__A07" , "__J15" , "__016") == "t"););
ifelse( is_ship_bootloader(getprop("ro.bootloader")) == "t" ,
assert(check_mid("full", "PN0710000") == "t");,
assert(check_mid("simple", "PN0710000") == "t"););

Obviously "check_cid"includes also SuperCIDs (00000000, 11111111, ...).Content of android-info.txtIt's all in updater-script, so it can be sily edited anyway. But the rl problem is different. As mentioned alrdy, every OTA update contains firmware.zip - package with bootloader, radio, touch panel drivers, trust zone and other parts of important firmware. It also contains the "android-info.txt" file, where CIDs/MIDs are listed, so your S-ON bootloader won't let you flash an original firmware.zip if your CID is not listed there. Yes, I'm not talking here about custom radio, bootloader or anything custom at all. Original, untouched firmware.zip from an OTA update can't be flashed onto the device if the CID doesn't match. Is it a problem? Yes, this is the rl problem we're dling here with. Not S-ON/S-OFF, but CID restrictions and an inability to change the CID .

How this can be resolved? "android-info.txt" is a plain text file, so it can be edited sily. If your CID is not on the list, just add one more line with your CID. However, as long as your device is S-ON, you won't be able to flash it, because every firmware.zip is signed with a special . Once firmware.zip is modified, the signature is and the bootloader will reject the request to update it. But there is a different method: you can change the CID on your device with a fastboot command "fastboot oem writecid <cid >". The best CID to use is one of the WWE CIDs (for instance __001). But wait - you can't use this particular fastboot command without S-OFF.

Is this problem a rl one, or just some sort of users ill-informed craving? It's very rl, because without the ability to flash firmware.zip from a WWE OTA update, every user from any carrier or different world region is forced to wait months to receive OTA updates customized to his CID. Everyone can de-brand his device sily by flashing a stock system , but it won't be enough: because firmware.zip with corresponding parts of the firmware is needed at the same time. This isn't about the OTA itself, it's about the firmware.zip inside that OTA update.
Dangers:
So what are the dangers of obtaining S-OFF on your device? Some of the partitions in the device are extremely sensitive and can result in your device being bricked if they are even slightly corrupted. With S-OFF you can access all of these partitions and the slightest corruption during transfer (whether that be a power spike or you jiggled the cable slightly) can result in a bricked device as it does not check for signatures.
Here’s an example which has almost happened to me once on an S-OFF device: I was flashing a boot.img via fastboot, the command is: "fastboot flash boot boot.img". However I had made a small but significant typo: "fastboot flash hboot boot.img", simply by mis-hitting the B ; this command would be rejected by a device with S-ON as it is a protected partition, but would be accepted on a device with S-OFF. If I had pressed enter without checking the command, my device would have turned into a paperweight in seconds.One of the most popular protected partitions the community enjoy flashing is the radio partition. This is also a partition where the slightest corruption will cause your phone to brick. The FCC guidelines state the the radio must be booted with a separate processor (I guess to decrse the risk of it being tampered with), so what happens in a phone when it turns on is: radio is booted via a dedied processor by the first stage loader, initialising the radio hardware (Wifi, Data, Bluetooth, etc.). Radio successfully boots and initiates the first stage loader to use the main CPU to load the second stage loader into RAM (also known as the SPL). Depending on the boot operation, it will either initiate the system or recovery. So without a functioning radio, the main CPU will not kick on and boot the phone.
Some other facts:You don't need S-OFF to root your device.You don't need S-OFF to be able to run Titanium Backup or other appliions that requires root access. You just need root privileges for that.You don't need S-OFF to flash custom recovery onto your device.To summarize:

We don't need S-OFF, but we do need the ability to edit the CID on the device (let's say at lst on officially UNLOCKED devices), or the firmware.zip packages inside an OTA update should not be signed, so that "android-info.txt" can be sily edited, or the CID restrictions from android-info.txt should be removed (MID is enough to ensure that the right firmware gets to the right devices).

Something to re-think?

Even if we don't need S-OFF I'm quite worried about the policies of mobile companies and carriers. Their philosophy is "the more you are locked down, the more you are protected". That mns Police should not fight with criminals, but everyone should just lock down their doors, and stay at home instd. It's far sier and cer to lock down mobile devices and not allow root access rather then improving the security in other ars.
Can you imagine that you just bought a brand new notebook for $3000 and:you can login only as a Guest (no Administrator account available by default),you can't change your operating system,you can't use appliions that requires Administrator privileges,you can't browse freely the content of your hard drive.You would say "Where the hell is my freedom?!" Here comes the answer from your notebook manufacturer - "For your own security, you don't have any freedom". Sounds like a George Orwell story to me.

I want the same freedom on my phone that I have on my PC.

This article was written in a cooperation withShen Ye

Have any questions or comments? Feel free to share!Also, if you like this article, plse use media sharing buttons (Twitter, G+, Facebook) down this post!

PS. I want thank to Tom Kelsall, my Elevate companion for his help in a proper grammar redaction of the review! Thanks Tom!