[RESEARCH] Samsung Knox: Warranty Void Behavior

As you may already know, the latest Samsung firmwares came with a new secured bootloader. You can recognize it in download mode easily. It states: Knox warranty void: 0x0 or 0x1.

As for now, there is no way to reset that flag from 0x1 to 0x0.

Then I read in a comment of Chainfires post concerning that flag, that as long as you do not try to downgrade to a non secured bootloader, this flag will not change. He claims to have that information directly from Samsung.

https://plus.google.com/u/0/+Chainfire/posts

Jeffery Butler said:

FYI...Samsung told me that Knox warranty becomes 0x1(void) when the device with secured bootloader attempts to have non-secured bootloader. MH1 is the very first binary with secured bootloader. If MH1 is attempted to be downgraded to lower version(i.e. MGD) which has non-secured bootloader, then Knox warranty becomes void forever, and this means that the device can be used only for non-Knox device(no container can be created).

Click to expand...

Click to collapse

Has anyone already experience with rooting an "untouched" S4 which has the secured bootloader and can confirm or decline that?

- - - - - - - - - -

Conclusions and Facts about KNOX-enabled firmwares (based on statements from chainfires post and it's comments above, ans based on this thread)

• Not possible to downgrade to KNOX-disabled firmwares/bootloaders (An attempt sets 0x1) (even though some people state, downgrade is possible when omitting the bootloader file in a firmware package: see http://xdaforums.com/showthread.php?t=2444671, not confirmed)
  
• Even if you flash a KNOX-enabled firmware via odin (e.g. the latest fw) knox will be set to 0x1
• Flashing unsigned or modified images via odin will set knox to 0x1
• Samsung stated, resetting the flag is impossible
• KNOX is mandatory and can not be completely removed
• Warranty Void is no counter, it is a flag (0,1) it was never seen 0x2 or so
• Mirroring all partitions from a clean 0x0-Device to a 0x1-Device via JTAG produces an unfunctional device (reversible by restoring the 0x1 partitions on the phone)
• KNOX bootloader verifies signatures of kernels and recoveries. No custom ones possible without voiding the knox warranty
  

Assumptions on how KNOX flag in bootloader works:

• Some experts think, an eFuse is involved. (http://en.wikipedia.org/wiki/EFUSE). An eFuse is mostly only incremential. Even unwriteable by low level tools or JTAG. But it is still not proven, that eFuse is used.

Knox technical information:
https://www.samsungknox.com/overview/technical-details

Hi guys, here is a copy of my conclusions i'm writing in another thread.

I'm going to post them here as well, it might help someone….

Hi guys.

I don't know if this helps or not but here are some of my conclusions on the subject:

I have a Jtag Box (Riff Box) and i tested several different things on several S4 With Knox 0x0 and 0x1.

1st Conclusion - Clone or Change the Boolean to 0x0 its not possible since the phone will put counter back to 0x1 again in the first full boot

2nd conclusion - There is a 3rd bootloader (kind of a bootloader) on this new firmware (latest 4.2.2 and on) that creates a secure container using the trust zone, and sandbox security keys and checksums communicating with the PBL (Primary bootloader) and SBL1 (Secondary Bootloader).

3rd conclusion - This container is created not on the first boot after the upgrade (as some say) but in the firmware upgrading process.

4th conclusion - The 3rd Bootloader is not read or write permitted not even with Jtag (At least i didn't found it after 3 full dumps in different phones)

5th conclusion - Once you upgrade to knox secure bootloader you can't downgrade to a un-knoxed bootloader because the security checksum between the 3 bootloader will fail and odin won't flash.

6th conclusion - This is far away the most advanced and secure operating system ever made by Men, but it as is faults. Last week the world found a huge bug in the knox containers that allows data to be exchanged from insecure boot mode to secured sandbox in knox app…

The theory :

The only way to reset knox counter is to "convince" the phone bootloader that it still's in 4.2.2 un-knoxed bootloader and flash a 4.3 knox firmware. This way, all the secure containers in trust zone and boot loaders checksums will be recreated, flags inclusive.

I tried unsuccessfully "kill" a knoxed bootloader with Jtag and recover it in a 4.2.2 un-knoxed one but Jtag won't write the new bootloader 'cause apparently this specific address (Bootloader address) is write protected ….

I hope this helps anyone, i'm done with this. I'm not a bootloader specialist and i'm pretty sure someone will find the way to reset this.

For now still Samsung 1 - 0 Rest of the World

I'm giving up on this but since i have a Jtag and 198 voided S4 in my office, i'll be available for testing anything on those.

Good luck researchers,

By the way, if it helps click thanks

Maybe only 1% root their android phones (I think its more but anyway) but these people have made xda community which have made Samsung and android what they are.
Dont forget that samsung leaked firmwares to us, the 1%, to test and improve any issue...
No custom, no xda, no android...Thats the power of 1%...

Sent from my GT-I9505 using Tapatalk 4

Compilation

Hey folks. I don't know how much it's worth, but I've kept a notepad compilation of all the information and reasonable concepts that I've come across while digging through the better part of a thousand pages. I'm sure there have been developments and promising avenues that I've missed, but I hope these notes might save others some time in sourcing so many different posts and threads.

From everything I've read so far, it sounds to me like the KNOX Warranty bit actually behaves a bit differently on older devices than on newer devices when it's flagged. On the older devices, it sounds to me like the counter may trip before it burns out an eFuse and that it's only permanently burned out if a failed attempt to reset is made. On newer devices, however, it sounds like there are instances where the simple act of tripping the flag results in an immediate burn. What they all appear to have in common is the way in which KNOX protects itself. Multiple bootloader layers stacked with hardware protection, in order to prevent the flag from being reset at any single stage. (I could be unclear on that last bit, if I am please feel free to correct me.)

Anyhow, I've gone through a lot of material at this point and I'm afraid it's left my brain pretty well putty. Here's hoping this compilation helps someone reach that "Eureka!" moment.

--------------------------------
Knox Flag Notes:

How the Knox system works on Samsung devices:
Secure Boot is a security mechanism that prevents unauthorized boot loaders and kernels from being loaded during the startup process. Firmware images, such as operating systems and system components, cryptographically signed by known, trusted authorities, are considered authorized firmware. Secure Boot is a component that forms the first line of defense against malicious attacks on devices with KNOX.

Samsung KNOX uses systematic security checks to ensure that only valid kernels are used by the device. On the hardware level, the Primary Boot Loader confirms a PKI certificate to verify the integrity of the Secondary Boot Loader 1. Similarly, the Secondary Boot Loader 1 verifies the integrity of the Secondary Boot Loader 2, and the Secondary Boot Loader 2 verifies the integrity of the Android Boot Loader. The Android Boot Loader will only load a Samsung-authorized kernel with a Samsung certificate as its Root-of-Trust.
https://www.samsungknox.com/en/overview/technical-details


One reported solution, that I have not been able to verify or corroborate, is related to the S4 Mini:
Originally Posted by SandeepEmekar View Post
My S4 Mini's Knox Status was reset when I flashed different region firmware on it.

Confused with the status of this thing, "CSB-CONFIG-LSB: 0X30" . (page 45)

The reporting user has stated that his/her KNOX flag was 0x1 and returned to 0x0 upon flashing to a different region's firmware.

"Old was India Region then I switched to latest one of Brazil (I9192UBUBMK4_I9192ZTOBMK2_ZTO.zip)" (page 46)
http://xdaforums.com/showthread.php?t=2486346&page=45

The above has not been verified, to my knowledge, and someone else subsequently reported attempting a regional change from the UK to Madagascar or somesuch place and reported no change to the bit counter.


There is also information for removing the KNOX bootloader from the Note 2, though apparently this only works if the flag has not already been tripped from 0x0 to 0x1. If the flag has been tripped, this technique still works to remove KNOX and the flag's notification from the Download Mode; However, if the bootloader is restored to KNOX then the flag is once again displayed as 0x1.
http://xdaforums.com/showthread.php?t=2500823


There have been several reports of people having their phone serviced by an authorized technician, in which their device was repaired and returned within around 10 minutes. Accordingly, when the device was returned, their KNOX flag had been restored to 0x0. This suggests the possibility of a software fix, or at least the existence of a software/hardware fix that can be implemented by connecting the device to a specialized diagnostic and recovery computer (some reports claim it is a handheld device).

It should be mentioned that several of these reports state that this fix is possible on devices which are older than the Note 3, which it seems cannot be reset. This suggests the existence, and initial utilization, of an eFuse for the Note 3 but not for devices from earlier generations (which seem to still utilize eFuses but not in the initial tripping of the flag. These devices, reportedly, will only burn the eFuse if a failed or incorrect attempt at resetting the flag occurs).

This exception for the Note 3 is contradicted here, however:
http://xdaforums.com/showthread.php?t=2504258

One user has stated that he knows where the eFuse, which KNOX utilizes, physically resides:
Originally Posted by iankellogg View Post
THe knox flag is an EFUSE, you will NEVER be able to reset it back to 0. It is PHYSICALLY destroyed in the S800 chip and there is no way to change that fact. The best you can hope for custom bootloader that fakes the flag. But they will always be able to check the flag... The speculation is that KNOX is using an E-FUSE. chainfire has said everything he can tell its an e-fuse. The S800 has at least 1 E-FUSE register that I know of and I think maybe 4 total... So I was wrong about the number of Efuses (which qualcomm calls QFuses) THere are over 100 of these QFuses. THey can be used for pretty much anything the manufacture wants (from what I have read all manufactures use QFuses for disabling Debugging). All Qualcomm chips and pretty much any CPU or FPGA on the market has at least 1 EFuse. It is up to the company to determine how those are used. LG decided against using EFuse checks in their bootloader. Samsung decided it was the only way to make Knox secure.
http://xdaforums.com/showthread.php?t=2486346


There is also discussion which indicates that the KNOX flag and notification are stored either in the eMMC or in the RPMB.
http://xdaforums.com/showthread.php?t=2504258&page=29


There was some more in-depth discussion, which I've misplaced the link to, which described the process of replacing "mmcblk*" as having reset the flag's display to 0x0. The catch is that once the device goes through one full boot cycle, the flag consistently reverts to 0x1. This corroborates the discussions regarding both software and hardware redundancies.

aboot.mdn has also been implicated with the KNOX flag.

eMMC Specs:
http://www.jedec.org/sites/default/files/Victor_Tsai.pdf

QFuses in MSM8960, which may also be relevant to identifying the active efuses used by KNOX:
http://xdaforums.com/showpost.php?p=31622172&postcount=9


Another potential avenue was suggested in the Note 3 thread, as follows:
Originally Posted by yashade2001 View Post
@Chainfire I have good news. I found a way for reseting counter on new KNOX devices. So you know KNOX' s information is stored in an emmc symlink file. Some people says it is storing in mmcblk0boot0, some people says that is same with mmcblk0 and some people can't find mmcblk0boot0. Actually I have not got a KNOX enabled device but I have testers for KNOX counter reset tool ( Making for S4 currently ). One of my tester opened that symlink ( He's not my tester now and I don't know which symlink is that. ) and edited with a hex editor and he saw a flag which shows counter status ( Hex value ). He edited that to 0x0 and rebooted the device. We saw 0x0 in bootloader screen. But when we rebooted the device it gone to back. So I know there is a hardware protection ( Special thanks to @gokhanmoral ). I think harware protection provided by eFuse chip. So there are two ways for reseting counter.

1) Rewrite kernel and undefine the eFuse chip. eFuse chip is defined in the kernel. Then there should be no hardware protection and we can edit that emmc symlink to reset counter. Shortly, we can modify bootloader.

2) Modify an Odin flashable tar as you want. But you need Samsung's special key to sign. If you sign that with Samsung's special key, counter will not be changed. But it's hard to get Samsung's special key. We can find it in an official flashable tar. It's not impossible but it's near to the impossible I think.

I'm going to make an app for doing first way automatticly.

Cheers. Waiting for your answer.
http://xdaforums.com/showthread.php?p=47765738

I seem to recall the above person having said something about giving up the ghost, but I can't recall a direct link. At any rate, he may or may not have hit a dead-end in his efforts.


Then, there's the discussion on Chainfire's G+ page where someone says:
Andrew Williams02/nov/2013
+Chainfire, I think +Mathew Rennie is correct. My GT-i9505 came with an NZC carrier branded ROM. Using PC ODIN, I flashed a later pre-Knox BTU stock version and had this rooted with CF-Auto-Root. I later attempted flashing a Knox enabled BTU ROM with Mobile ODIN, but upon finishing flashing I had no wifi, calls didn't work, etc. Did a factory reset and then used PC ODIN to flash this same Knox enabled BTU ROM and everything was fixed and remained at 0x0. Obviously this is because Mobile ODIN doesn't flash the bootloader whereas PC ODIN does. The point of all this is that I'm at 0x0 on a BTU ROM when my GT-i9505 came with an NZC ROM. Maybe that's because the bootloader was updated to BTU prior to the Knox enabled ROM being flashed and since I flashed another BTU ROM (albeit Knox enabled), it remains at 0x0. I even just did an OTA update to XXUEMJ7 and still at 0x0. But...I'd really like to have root back! 
https://plus.google.com/+Chainfire/posts/LCfF5A9fsTG?hl=it


Posted by ace_of_spades021
I asked some one who work at samsung agency about this and he told me they do it with BOX RIFF and ORT ......
http://xdaforums.com/showthread.php?t=2504258&page=7


Someone who appears to have changed the way the Warranty Bit displays on the Download screen:
http://xdaforums.com/showthread.php?t=2510867


Lastly, Chainfire's brilliantly informed analysis which mentions potential options for downgrading from KNOX bootloader (which would prove perfect if you've not already managed to trip the KNOX Warranty bit.
http://xdaforums.com/showthread.php?t=2504258&page=12

That page also has another informative post (which I also recall seeing somewhere along the way in this thread):
Originally Posted by .NetRolller 3D View Post
What we know so far:
-The Knox flag is physically stored in the eMMC, not in the SoC. Replacing the eMMC resets the flag.
-Some phones with Knox have Toshiba eMMCs supporting only eMMC v4.5, meaning, a standard eMMC 4.5 feature is being used (not a Samsung extension or something new to eMMC 5.0). This alone excludes an efuse - eMMC 4.5 doesn't have efuse support.
-Samsung can reset the flag using software only. This also rules out an efuse.
-Restoring a full eMMC backup (including boot and user partitions) doesn't clear the flag, even if done via JTAG or direct eMMC programming. So, the flag is not in the user or boot areas of the eMMC.

That leaves only the RPMB or the eMMC partition table.
--------------------------------

szczeslaw said:

But KNOX bootloader is not locked. You still CAN root your phone, install custom recovery or custom rom. There's lots of people on this forum, that prove it's possible. So no - KNOX bootloader is not locked, it "just" voids your warranty once you flash something without Samsung signature. Oh - and after flag is tripped you're no longer able to use KNOX, but since for some people "it's just corporate c..p", why do they even care?
It's not like Samsung never tried to void your warranty when you breake their rules. Remember binary counter? It's the same. The difference is, that thanks to Chainfire we are able to reset binary counter, but we are not able to reset KNOX YET. So what really changed? Only the fact, that for now we can't reset KNOX flag, as we could/can reset binary counter. Once we learn how to reset flag, the situation will be exactly the same as it was.
Most of other major manufacturers have done that for the past few year, and i have never seen such histery.
KNOX doesn't trip the flag when you install some software. It only does that when flashing something without Samsung signature. Period.
So the user that doesn't modify the phone has the choice: not to use KNOX if he doesn't care or protect his privacy by using KNOX and it's encrypted container.
User that modifies his phone doesn't have this choice (actually he does - he can choose not to modify phone), but since majority of such users doesn't give a damn about KNOX software, it's ok. They also loose warranty, but officially they always lost warranty. We were just able to cheat Samsung. Now we don't know how to do it yet.
Does it sound like a choice? It does to me.


System is not locked. You're only mad, because you cannot cheat Samsung now, by telling them "hey, i have never modified my phone".
And everything points to conclusion, that KNOX flag is not an e-fuse, but most probably some certificate thing (like in Sony, where when ulocking BL, DRM certificates are deleted from the phone). Samsung CAN reset the flag, so it cannot be an e-fuse.
Employer cannot make you use your private phone for work. In most cases it's employees choice, as in many cases people are not happy with phones they get from company. So this is a way to secure such devices. Ever heard of BYOD concept?
I think you have already sentenced Samsung and you want THEM to prove you wrong. And when they do not answer your questions, you treat it as a proof. THAT IS faulty logic.
Sorry - it's you that have to proove them spying, before you call S4 a "spy-phone", and before you say KNOX is a malicious software.
Not guilty until prooven. That's the way it goes - not the other way around. I know you're from EU, just like me, so you may be confused - yes, in EU often it is other way around. But that's just not right and not fair.
So until you (or anybody else) prooves that KNOX is malicious, it's spying on us etc., KNOX is just a (for me nice) feature. And you are just angry because you lost your warranty, and don't know how to cheat Samsung.

Click to expand...

Click to collapse

Sorry for my absence and a late reply. There are things that are more important then Knox in my life.

Jeez... Where to start? I'm sorry that I have to go a bit "deep technically" but I think I need to explain my concerns and why you must act if you don't want
to have an integrated Knox-chip in your Samsung Galaxy S5.

Since I write long posts, get some coffee, and meanwhile try thislink, GeoIP Locator, and tell me if they where close or not? As an illustration.

About your assumptions
I have FULL warranty with a written permission that I can flash my phone 1337 times or trip my Knox from my cell provider. They don't care!
Only invalid if I happen to brick my phone because of software. They also asked me don't want me to mess with the modem (except for official upgrades)
so it doesn't mess up their network. My warranty is between me and my cell provider, not Samsung. That is something between them and Samsung if my
phone would get faulty hardware. I don't have to care about that. I will get a new phone. I can basically have CM on it and turn it in. Hell I can even have
IOS on it (and live in shame).

So I don't have any warranty "anger" but very strong concerns about my privacy and this time a huge attempt to invade it since I carry and have my phone
with me all day and night. Also, I don't think you really see the wide implications here and I don't think you really know SELinux.

SELinux it's pretty straight forward. You just have to write out rules, "directives" what to restrict or not. How much control you want to give the user of the
system.
But you are totally in the hands of those who write those rules and what they let you. *BSD has something similar with security levels. Will leave that out of this.
And the ones are Samsung. They write the rules, in more then one way here..

I didn't saw there is an option to turn off "updates" so I got an "SELinux update #16" on my Note 3 yesterday (plain vanilla, not rooted). Anyone else got it?
Can you tell me what was included in that one? Only if you work at Samsung.

It's REALLY good when it comes to mission critical computers that should not be tampered with, especially if exposed to the internet.
It's REALLY bad when you are enforced to have it in your own private phone since there is NOT A SINGLE REASON for what purpose you need it.

I saw the new nice updated webpage, with a little cure girl and all, they did a few days ago. Protection. So nice. Are you really so naive?
Isn't it YOUR choice to have a virus killer installed on your PC or is it Microsoft that should decide that for you? What more should they then decide?

This is not a criminal case. Innocent until proved?? Do you work at Samsung? If not, have you tried to talk to them about Knox at all?
Did they give they any info? At all?

If this was so innocent, why the secrecy? That you can hack it? You have a flag for it. Apparently it's so strong that they got governmental approval to use
it in USA. So it must be considered as something really hard to hack, right? And it is. I doubt that we will be able to crack it. Only if we find a weakness.
That is what they are waiting for. Us to try to circumvent it. They sit here and read it (Hello! Calling you tomorrow, btw!) so they can perfect it.
So no, in this case they are the ones that have to prove. This is not a criminal court-case. Even if it should be.

I took this from their on webpage (with that cute girl). It's from their own white-paper (highlighted the important things for your pleasure):

Secure Boot requires the device boot loader, kernel, and system software to be cryptographically signed
by a key verified by the hardware. Secure Boot uses X.509 certificates and public keys which are embedded
into the boot loader of the device. A secure hash of the certificates is fused into hardware Read-Only
Memory (ROM) at the time of manufacture. The Secure Boot loader will only continue if the authorized
secure signed binaries are present. Next, Secure Boot verifies the cryptographic signature of the Linux
kernel and system image before handing control to the OS.

So this has been planned. For a long time.

Take a look at X.509.
As you see it's a standard SSL-certificate (wonder if it's signed and how to get it and see the top signer).
Until today SSL has not cracked more then by brute force. There was some alarming scare a few months back, during Snowden that NSA might have
found a weakness in it and could crack it. But it was never verified and it's still considered as "safe".

This is the basis of all internet security today. So let's hope that NSA didn't succeed in that...
If it WOULD be hacked, the whole damn Internet security falls apart. Everything has to be rewritten. The implications of this would be enormous.

Off topic
I worked with Y2K. After that passed people said "Oh, see. That was a crying for wolfs". No it wasn't. If there wouldn't have been that HUGE investments,
new hardware, rewriting of code, millions of man (and women) hours spent it would have been bad. Really bad. We worked day and night in the end.
I saw all that. I worked with it. I consulted for several corps, like pharmaceutical etc. The nice is was that I'm a Unix specialist so I don't have to worry
until Y2047 when those clocks turn around (32-bit int, seconds since 1970-01-01). I hope I will still have time to be moved into The Matrix,

That is why Y2K didn't had more serious implications (except for an emergency shutdown of 6 nuclear reactors in Japan (that should have been
an wake up call to see over the security....). Developing countries had problems. Of course. But that drowned in the "It was a big scam". news.
Some "funny" things like a someone older then 100 year old started to get commercial for baby products.

A bit on topic
We have now a successor that will replace X.509 and that is AES.
It's much stronger then X.509. It's so strong that it is the approved standard to the highest classified documents "Top secret" in USA and basically all
over the world.

Today's CPU's (younger then 5-6 years) has a special instruction for calculating it (AES-NI). It doesn't slow down your machine much (think it takes just 5
or 6 clock cycles compared to 69 in the software implementation in the Linux kernel). Using Truecrypt? You should.
This is a magnitude stronger and it wouldn't surprise me is the Knox-chip will not replace scramble it with AES as well in the Galaxy S5.

Get to the point, dammit!
So what does it mean? Every phone has an UNIQUE certificate for each phone. Think they have a list corresponding to the serial number? You bet.
When you buy your phone, do you sign the paper for your "plan"/warranty with the phones serial number written out? Of course you do. You want your warranty.
But this means also that they can MATCH you and your phone. Serial -> You. Easy. Same with everything. No big deal, right?
It would not be if you didn't have Knox on it. This is the KEY here.

And you are WRONG. The system is indeed locked.

SELinux can do this (among other things)

• You have a MAC-implementation in the kernel. The rules can deny access to different parts of the kernel.
• You can hook on ANYTHING to it. It's a matter of config. That is their framework we see in the /system etc.
• It controls running programs, file systems, files, sockets, network interfaces etc.
• And it can run whatever application it wants, without disclosure to the user, hooked on 3rd party implementation with FULL network access.

If's sandboxing you in in user space, with limited access to system space, just like jalis but worse. You are locked out on SYSTEM level.
Basically you have total visualization of your machine and all you do is like being in a virtual machine.

Oh, look, how nice of NSA to help out: SEAndroid
They even implement it with Xen.

So you might think you are in your phone but you are in the Matrix. You are never in your phone.

And that means that you don't know what it's going on in your REAL phone. You don't know what your phone are sending for information since few can
afford their own base station and build a Faraday's cage to really see what it does.

They have you through your serial, and they can install what they want on your phone. Nice to target people, not? I'ts not only about general population
control anymore. It's about that they can know that YOU have this phone with unique id and who you are. They can start to track people, groups, whatever.

You can compare it with Windows. Windows desperately tries to contact to the 192.88.99.1 that is the standard "6to4 any cast" (RFC 3068), but from
there where? There are pages with people who try to figure out why "SYSTEM" really wants that and where it goes. Please, take a look yourself. Google.

Turn on Skype. It tries to make a tunnel through ICMP. A bit sneaky but I CAN see this because I have full access to my network.
But I don't have a base-station and I'm betting nor does you.

So where is my faulty logic? You have a phone that you are sandboxed in. You have no control because you are locked inside user space.

I'ts so strong the government in USA can use it. They have already a flag that warns if it's tampered with.
There is many unanswered questions about Knox and why doesn't Samsung disclose them if it's so innocent? To protect from tampering that you can't?

So if there will be no pressure and people will not get the finger out of their butts S5 will have a Knox-chip in it. That I'm 100% certain of.

Knox is way more the a bootloader that people tries to circumvent for their warranty situation, well, good for them. I see that part as insignificant
since Knox is a whole framework that nobody really knows what it does.
Read the white paper. Many pretty words but sift through the purpose to why you should have it, why it's enforced on your phone so desperately?
There is none.

And as soon as you trip it, the phone is NOT the same as it was before if I compare how it was before the Knox. It acts differently. I can't say what really,
but having experience, now 20+ years of Unix you get a "feel in your guts" that something is not as they should be. I can't (yet) put my finger too it but
it's a subtle change. Not the same phone. But probably it's because the thing I wrote. I'm not in my phone. I'm in a virtual space.

Now they rushed and released that i9506 that has replaced the i9505. You can get that anymore. With the new phone, that has so much more in common
with Note 3 that I think it's the same production line and that they fork quite late to the two platforms. I have not seen the inside of it so I can't check but
it can be a cost-saver or it can be that you don't have any other choice for a boot loader that isn't from the "pre-Knox".
Get a rocket phone but make it incompatible with any pre-Knoxed firmwares. Nice move, Samsung!

I haven't tried it yet, as said, a bit much IRL right now but I'm pretty sure that no bootloader that isn't "pre-Knox" will work on the '06 but that also, that
firmwares from Note 3 will boot. Are there some pre-Knox there?

You compare it with other companies. Where do they have the lockup?
You can unlock your HTC FULLY. You couldn't make an S-OFF in the HTC One X but you can that in the HTC One.
Sony has similar solutions.
Only Samsung goes the other way and close up. Possibility of a remotely controlled phone? 100%!

If you think it's ok that you have a phone that can run applications that you don't even see, don't know what it does, who it communicates with then it's fine
with me. I don't accept it, since I think it's sinister. I don't buy that Samsung want to protect me. If so, write a free virus killer instead.
Don't make my phone a virtual machine!

So yet again. I don't whine over warranty since that is not an issue. The issue is that your phone is totally controlled by a 3rd party at their discretion.

SELinux rules update #16

I'm curious. What did they "perfect" this time?

If you or anybody else doesn't have concerns after this I will stop writing about it, because it takes up my time and I will buy a HTC next year instead. But
is you all ARE concerned you have to start to voice that and spread it all over the user forums, not this special place, but the ones where the masses sit
and read. If not, Samsung Galaxy S5 will have a Knox-chip integrated. Maybe they even smack AES on it for fun.
Then we don't even have to start a forum about it. We can just link them over to some of those user ones....

• When Intel made it's unique ID on each CPU there was a huge outcry. They withdraw it.
• When Microsoft tried to do a chip called Palladium that would only allow certified programs to run there was a huge outcry. They withdraw that.
• When Samsung takes over your phone, can control it 100% or sell that control to some government you sit and talk about bootloaders and warranty....

So THINK for a moment. And hopefully act.

/Abs