Google Taking Aim at Device Modders in Android 4.4 KitKat
xda-developers.com
xda-developers.com
The Wiimote cannot enter a code and hit enter, but apart from that it's a normal Bluetooth device. Pre-Android 4.2, it was perfectly fine to connect it. Bluetooth uses the code '000000' for this and a third party application can hook through.
With Android 4.2 and 4.3, the ability to connect Bluetooth devices to connect without using a code determined by the phone was removed. It was possible to root the phone and set it to a specific MAC address for the Bluetooth interface, from which the Bluetooth code was generated, so that this Bluetooth code would be '000000' and the Wiimote would connect correctly.
Now with Android 4.4 the answer is going to effectively be 'forget it'...
I'm sorry but if what seems to become the most ubiquitous operating system out there cannot connect to probably the most ubiquitous gamepad in recent memory (and quite a few others that exhibit the same problem), using a standard that both of these devices support, then that's just a tad ridiculous. Especially if it's something as simple as this that was supported in the past.
And that's just one example.
Sure, I'm also going to complain about the fact that "it's my device, I want to use it as I want". But when you actually see the reasons coming through behind this you might understand why rooting might not be such an unreasonable request - it makes things like that, things that should work, work.
The former can only be done by you (the device owner), but in theory the latter can be done by any manner of malicious applications. dm-verity only addresses the latter.
You should still be free to unlock and flash your own ROM to your hearts content. This includes flashing rooted images that have whatever bluetooth functionality.
Also, at least on ChromeOS unlocking the bootloader disables playback of DRMed content.
There is another advantage of using a locked down file system --- you may not be able to use a rootkit to break root and then modify the file system, but some unfriendly adversary, such as the FBI or the NSA, won't be able to do it to your phone without your knowledge, either. I would think that's worth the inconvenience of making sure you buy a phone with an unlockable bootloader. (Since unlocking the phone requires a wipe of the disk, you don't have to worry about the FBI/NSA doing this to access your data on the phone without your knowledge.)
There's always the baseband. The baseband lives on its own cpu and often shares RAM with the "main" cpu. It runs closed-source, proprietary firmware that has unknown security bugs, exploits, and backdoors. It's reasonable to assume that anyone within reach of your cellphone tower has root to your device, and the NSA and LE almost certainly do. The mobsters John Ardito and Peter Peluso were caught when the FBI turned on their cellphones using the baseband and used them as microphones to pick up nearby conversations.
Re needing to wipe the disk:
1) Modern Android has 'adb backup' so if your phone is not locked, someone who got ahold of your phone can use it to dump your data from a non-rooted phone.
2) Law enforcement and intelligence organisations may or may not have tools to dump your data directly off a (desoldered) flash memory chip. You need to enable disk encryption (* ) to protect against this.
(* ) I'm assuming a disk encryption that's not rigged, i.e. has no key escrow available to law enforcement.
If your phone is locked, and there aren't any available root exploits for the system (why is why I'd agree with tytso about getting an unlockable phone -- less incentive for the community to collaborate on what are essentially weaponizeable root exploits) then a physical compromise that installs a persistent rootkit must wipe the device beforehand. (Which gets rid of your data, and is easily noticeable)
The Nexus 5 is $350-$400. The Nexus 4 was even cheaper. I got mine for $200 when the sold off their remaining inventory.
Also most of us don't need Verizon.
Well, yeah, right.
1. a) "Evil Google Tries to Take Control of Android"
b) "Google Tries to Standardize Android and Fix Fragmentation"
2. a) "Google Taking Aim at Device Modders in Android 4.4 KitKat" b) "Google Trying to Make Android as Secure and Unhackable as ChromeOS"
Doesn't it make sense for Google to try and stop rooting through vulnerabilities, just like Apple tries to stop jailbreaking with every update?From what I understand, rooting should still be possible if the bootloader is unlockable (which it is for Nexus devices, HTC's devices, and I think Sony's too). Samsung and a few others, on the other hand, don't let you unlock the bootloader. So maybe we should take it up to them, and demand unlockable bootloaders, so we can modify our devices, instead of asking Google to turn a blind eye to Android exploits.
The problem is that Apple doesn't position iOS as 'open'. Google does. That's been one of their big selling points for years.
As another poster said, we should be taking this up with the Samsungs who ship devices with non-unlockable bootloaders.
The remark about the script-kiddie able to find vulnerabilities is ridiculous for a wide variety of reasons. Script-kiddies are not able to find vulnerabilities in any kind of system. Computer hackers obsessed with security do that and (most of the times) it's not easy by any means, i.e. Saurik.
In addition, I'm not sure what Saurik, the creator of Cydia, has to do with this discussion at all.
Finally, and most importantly, you don't seem to understand the current mobile market. Most users are the end-all-be-all of end users. Many people I know think that most of the apps on the iOS App Store are developed by Apple. People install apps without thinking. Tons of personal information is stored on your phone and in these apps, such as contacts and banking information.
Google/Android is open in the sense that Android is open source, so hypothetically anyone can hack on it.
You are the person who is half-pregnant. You want the normal end user experience, where you don't have to worry about compiling the operating system yourself, but you want it to be "hackable". That is not the definition of open. That is the definition of insecure. Because most Android users are not sophisticated computer users like yourself, a hackable operating system is just a bad idea.
If you want an OS that you can do whatever you want with, and is incredibly insecure, then fork Android and have at it. Do that, instead of complaining whenever Google makes changes that you don't understand and affect your somewhat specific and not very common use case.
He has found various security bugs in Android (most recent example: http://www.saurik.com/id/19 from the other day) and he is also the developer of http://www.cydiaimpactor.com
atmosx's point was that it isn't 'skiddies' who are finding these security holes, it's experienced developers and security researchers.
What utter piffle.
That's ridiculous. Openness, unlike pregnancy, is a spectrum. And intent matters.
The remark about the script-kiddie able to find vulnerabilities is ridiculous
Script kiddie, random malicious hacker person, whatever. Yes, people like Saurik and other white hats are capable of finding these sorts of vulnerabilities, but certainly other kinds of black hats are capable as well.
Not really sure what you're trying to say here... seems like you're just spouting nonsense and nitpicking.
But I think a middle ground can be created between super open/fragmented/anyone can fork and do whatever they want with it and super-closed/nobody can do anything with it except its vendor. However, Google could probably achieve the same thing, if they treated Android, like they do with Chromium and Chrome. Keep Chrome/some version of Android for themselves - while keeping Chromium/AOSP as open as possible.
As for this rooting issue, I don't really see what it has to do with being "open". They're just trying to secure it. And as I said, they can still allow bootloaders to be unlocked by the user. It's up to companies to do so, or they can take Samsung's route and try to lock them down as much as possible, even at the region level (which I disagree with, because in this case, there's zero benefit for both consumers and hackers. The benefit is only for the company).
The problem is not "we" -- we are the ones who buy the unlocked devices already. The problem is that people who don't know any better end up buying millions of devices that they only later discover have unreasonable restrictions and become landfill shortly after the manufacturer stops issuing new updates (which is often immediately).
What we should be demanding is that Google not allow the Google apps to be installed on devices with a locked boot loader.
Company 1 has a history of monopoly abuse (including giving OEMs financial incentives to not ship computers with competing OSes pre-installed).
Company 2 has let at least two (probably more) new mobile OSes bootstrap themselves using parts of its ecosystem.
Which company do you think is going to get the benefit of the doubt when introducing security features that make device modification more difficult?
That being said, I think the biggest issue with UEFI secure boot isn't the idea, it's the implementation. People have reported things like confusing, hard-to-use key enrollment interfaces (that sometimes don't work or even don't exist at all) and other crazy, undocumented restrictions (e.g. only allowing OSes with certain names). And there's a lot of concern that these issues won't be fixed in a timely fashion, because installing an alternative OS is a corner case use for most OEMs. And then there's the issue that there's no shared authority (across most OEMs) for signing off on bootloaders other than Microsoft. Add past history into all of that...
Meanwhile, on the Android side, there's a clear, standard unlocking process, implemented on the Nexus devices of each generation (worth noting that the Nexus 5 support was added to a well-known rooting tool within minutes of the tools developer getting the device). Yes, there's still potential for problems and abuse (e.g. bootloaders locked by manufacturers, usually by carrier request), but the issues and pitfalls are relatively well-understood, including ways of avoiding them (buy from manufacturers that offer a bootloader unlock process, avoid AT&T and Verizon-specific devices and so on). And these issues need to be balanced against the security benefits. There are certainly still issues to watch out for, but past history suggests that they will be balanced appropriately.
This just guarantees that on a locked, signed device (i.e. you haven't unlocked it to flash custom ROMs), the filesystem there is the one that's supposed to be there. Things that would be caught by this are (as the original documentation says[2]) rootkits and other persistent exploits.
You should still be able to unlock and flash your device; this is supposed to make it harder for a malicious app to root and own your (locked & signed) device persistently without you knowing.
[1] http://www.chromium.org/chromium-os/chromiumos-design-docs/v...
[2] http://source.android.com/devices/tech/security/dm-verity.ht...
Normally the latter involves modifying the base filesystem. If I understand it right, this will prevent the normal rooting procedure and force the need to install a different kernel just to get root. Which isn't great, as I have no desire to run a non-stock kernel; they come out later with stable builds, they may have issues finding all the right drivers for the phone, etc.
I may be mistaken, and if root can still be gotten without switching the kernel, then everything is OK. Otherwise, this is a big dent in the desireability of Android to me; root is incredibly useful for doing things outside the constrained sandbox, like mounting encrypted file systems, or syncing the clock to an NTP server (!).
I'd still love to see a significant kernel contributor step up to the plate and force the issue that locked bootloaders violate even GPL2. Of course all of these issues would be more straightforward if Linux had simply moved to GPL3 while it still could have.
This goes for manufacturers as well.
Except Google is doing the exact opposite. The Nexus 5 is the best off-contract phone out there hands down AND comes with an unlockable bootloader.
Google made the N5 and other kitkat devices more secure out of the box with this change AND continues to let you go nuts with your own hardware, best of both worlds.
Of the last two, you'll get no argument from me, but I would argue this is not "anti-consumer". Consumers do not care about the things developers and hackers care about. All the exploits allow for disabling security procedures that can be activated over the air.
A consumer wants a non-hackable phone, so if it lost they can lock, track, and erase it.
Does this mean we cannot have both ownership and security? No, but Google doesn't look like they are interested in that.
It's also separate from the question of being able to install your own OS build, which is of far greater importance.
See, "security" in this context is really about securing the carrier from users and those who might threaten users.
Boy was I wrong :(