Saw this yesterday on xda tv and found article at UK info site concerning Chainfire.
Apparently Chainfire has come up with a whole new different approach to rooting once marshmallow becomes the standard.
At this point in time we will wait and see after we get marshmallow.
http://www.ibtimes.co.uk/supersu-v2...-marshmallow-without-modifying-system-1526678
Pp.
I wonder if it'll mean we can avoid tripping knox.
From what I read it sounds like this method circumvents firmware and security protocols.
It could be a knoxless process.
Pp.
The latest scoop, Chainfire has gone to the dark side.
He has sold out to some big entity (no name mentioned) and is pouring his recourses into this entity.
This is one way to stop tampering with your product, hire the person with the smarts to hack your product and make him work for you.
Rooting is going to have to wait for the next root savant.
Pp.
PanchoPlanet said:
The latest scoop, Chainfire has gone to the dark side.
He has sold out to some big entity (no name mentioned) and is pouring his recourses into this entity.
This is one way to stop tampering with your product, hire the person with the smarts to hack your product and make him work for you.
Rooting is going to have to wait for the next root savant.
Pp.
Click to expand...
Click to collapse
Where'd you see this?
The Root said:
Where'd you see this?
Click to expand...
Click to collapse
Reading in the link I posted in op, followed some comments and links I came across what appeared to be a disgruntled modder.
Read for about 15min before I can across the post.
Edit***
It was in the Nexus 6 link taking you to xda.
Pp.
I do not see what you're talking about. Can you be more specific? Maybe supply the link?
njdevils28 said:
I do not see what you're talking about. Can you be more specific? Maybe supply the link?
Click to expand...
Click to collapse
Will find and post, it could have been a link to the Nexus 6 thread where I read it .
》》》 Edit 《《《
Here's something else I found, not the same article but it spells it out for you.
http://www.androidpolice.com/2015/0...n-involved-in-the-project-for-two-more-years/
Pp.
Here's a link and a copy of op where I found info on Chainfire defection.
WARNING: This is not a place for you to come to say how great you think Chainfire is. I'm not calling his character into question, only his methodologies and the character of the outfit he sold out to (and I don't question the act of selling out, that's business, pays the bills, and puts kids through college). The debates about what people prefer and why are as old as the first software. And of course, I will not tell you what to do, no matter how much I disagree with you. If you UNDERSTAND what I have to say, then THIS software is for you. If you don't, you are probably better off with binaries.
The root situation on Android 5.x left a lot to be desired. There was basically just one distributor of a functional substitute user command (su), and it was binary. Recently, ownership of that binary and all of its history has become the property of a previously unknown legal entity called "Coding Code Mobile Technology LLC". While it was presented as a positive thing that that entity has a great involvement with android root control, this is actually a VERY frightening development.
There are precisely two motives I can imagine for buying up all the root control software for Android;
1) monetizing it, which is contrary to the user's best interests,
2) something very frightening and dangerous involving the potential exploitation of everybody's devices.
You don't know the owners, and they are distributing a binary, so who the heck knows WHAT is going on.
Now a few important considerations with respect to your security and privacy;
1) Obfuscated binary cannot be sanely audited.
2) Function of this binary depends on the ability to manipulate selinux policies on the fly, including RELOADING the policy altogether and replacing it with something possibly completely different. Frankly, I've never heard a single reason why this should be necessary.
3) While a root control application may give you nice audits over other software that is using its service, it can *EASILY* lie about what it is doing itself. It can delete logs, it can share root with other applications that they have made deals with, it can directly sell you out to spammers, etc.
That is WAY too dangerous, and not worth the risk.
Frankly, you are safer if you disable selinux AND nosuid, and just run the old style of root where you set a copy of sh as 6755. And that is FRIGHTENINGLY dangerous.
So not satisfied with this state of root, and especially now with a new unknown entity trying to control the world, we bring you the rebirth of the ORIGINAL Superuser:
https://github.com/phhusson/Superuser
https://github.com/lbdroid/AOSP-SU-PATCH (this one is mine)
From the history of THAT Superuser:
http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html
Yes, look at the Superuser repo above and see whose space it was forked from.
Note: This is a work in progress, but working VERY well.
Use my patch against AOSP to generate a new boot.img, which includes the su binary.
Features:
1) selinux ENFORCING,
2) sepolicy can NOT be reloaded.
3) It is NOT necessary (or recommended) to modify your system partition. You can run this with dm-verity!
The source code is all open for you to audit. We have a lot of plans for this, and welcome suggestions, bug reports, and patches.
UPDATE NOVEMBER 19: We have a new github organization to... "organize" contributions to all of the related projects. It is available at https://github.com/seSuperuser
UPDATE2 NOVEMBER 19: We have relicensed the code. All future contributions will now be protected under GPLv3.
*** Regarding the license change; according to both the FSF and the Apache Foundation, GPLv3 (but not GPLv2) is forward compatible with the Apache License 2.0, which is the license we are coming from. http://www.apache.org/licenses/GPL-compatibility.html . What this means, is that it is *ILLEGAL* for anyone to take any portion of the code that is contributed from this point onward, and use it in a closed source project. We do this in order to guarantee that this VITAL piece of software will remain available for EVERYONE in perpetuity.
http://forum.xda-developers.com/showthread.php?p=63436951
Pp.
i want a 5.1.1 root without tripping knox.
ourfear said:
i want a 5.1.1 root without tripping knox.
Click to expand...
Click to collapse
Don't think it's possible after last update.
Back in the beginning with 502 and first 511 update it was possible but updates patched exploits in kernel , not now. You either windup with tripped Knox or brick.
I'm a diehard rooter but have learned to live /like factory stock on this super phone.
With over 20 disable junk apps I get fenomenal battery life and trouble free functions on my phone the way root would make it in the past.
And that's all I want from this device.
Pp.
Related
This is a new feature for WP7. An API will be provided for external services to validate that a call is coming from a Genuine Windows Phone. This will be accomplished by a requirement that every phone have a unique certificate applied during manufacturing process (similar to an IMEI, but more than a simple number, an actual .cer)
The certificate is to be stored in the "Device Provisioning Partition" during the manufacturing process and is to be destroyed upon completion of manufacturing. Any time a reflash occurs, a new certificate is to be issued.
This represents a significant change from the existing paradigm as your phone will be instantly uniquely identifiable through this method.
Bump for visibility
Is that going to make flashing custom ROMs an issue?
i think it gonna make flashing difficult..
if you flashed with custom, your WP7 would not be taken as genuine hehehe like Windows 7 lol
maharz said:
i think it gonna make flashing difficult..
if you flashed with custom, your WP7 would not be taken as genuine hehehe like Windows 7 lol
Click to expand...
Click to collapse
lol then you have to mod your bios.
On the bright side, we may have fewer reasons to flash custom ROMs on WP7. What are our current reasons for flashing?
1. We need new OS versions on our devices when OEMs don't provide that. Well, this is supposed to be taken care of by centralized update mechanisms for all devices. WP7 will also support partial updates where you don't have to change everything but rather update certain components. Also, firmware files should be replaceable - otherwise OS updates wouldn't work. We'll be less dependant on HTC or whomever.
2. We need components from other devices (newer versions of Manila etc.). Well, these won't exist anymore.
3. We want light ROMs. WP7 will need things added, not removed, for the most part, and crapware will be very limited.
vangrieg said:
On the bright side, we may have fewer reasons to flash custom ROMs on WP7. What are our current reasons for flashing?
1. We need new OS versions on our devices when OEMs don't provide that. Well, this is supposed to be taken care of by centralized update mechanisms for all devices. WP7 will also support partial updates where you don't have to change everything but rather update certain components. Also, firmware files should be replaceable - otherwise OS updates wouldn't work. We'll be less dependant on HTC or whomever.
2. We need components from other devices (newer versions of Manila etc.). Well, these won't exist anymore.
3. We want light ROMs. WP7 will need things added, not removed, for the most part, and crapware will be very limited.
Click to expand...
Click to collapse
Very true. With the OTA MS updates and such it will make life easier for updating the OS.
That could also bring a pitfall - hacking attempts that once worked get blocked.
Da_G said:
This is a new feature for WP7. An API will be provided for external services to validate that a call is coming from a Genuine Windows Phone. This will be accomplished by a requirement that every phone have a unique certificate applied during manufacturing process (similar to an IMEI, but more than a simple number, an actual .cer)
The certificate is to be stored in the "Device Provisioning Partition" during the manufacturing process and is to be destroyed upon completion of manufacturing. Any time a reflash occurs, a new certificate is to be issued.
This represents a significant change from the existing paradigm as your phone will be instantly uniquely identifiable through this method.
Click to expand...
Click to collapse
1. Project Echelon, lol.
2. End of dev'n'hacking, lol.
(now, remove both lol's)
M$ REALLY thinks it may compete with iphone(and apple stupidity), can you believe...
The "uniquely identifiable phone" feature is probably the major reason for this. Face it, outside of these forums, how many "non-genuine" WM builds are there?
What this provides is a token-pair for secure message encryption and a single point of origin/destination for all those notifications.
Thank you for the information, Da_G.
So it seems this will also affect us being able to port a WM7 ROM to another mobile?
So this means evry phone has a unique certificate
They will look for a way around that. For instance...who's to say microsoft are even implementing the certificate etc on prototypes...that would be darn impractical since there's so much chopping and changing in this developer stage, and do we know the servers are up and running? We should cross this bridge when we/Da_G come to it, and look for a bypass if not.
I do not think this money will be wasted if we dont port it to HD2, the fact is I will be the first to donate when pre-orders for the first HTC WP7 handset is outed so that Da_G can use his tools for that too. The JTAG test point will be useful to the community and I know Da_G will use it for the community...actually there's very little personal stuff he could do, and I doubt he would anyways, since all the uses will be of benefit to the community.
We should definitely start look at alternatives to the marketplace now, like Cydia. I'm not sure how the guy's doing it, whether he has servers etc, whether we could use them for multitasking/social networking or other uses. Depends how far microsoft go. Anyways, we all know that if m$ close it down and we cant jailbreak etc, then the community will have to migrate to android.
if i understand the situtation. If every phone is uniquely identifyable it means that imei may be part of cert calculations which means update code would have to be able to generate a cert or request a cert from the update server.
But if the phone checks the certs validity reverse engineering the check could help us fake cert files
EDIT:
after reading on rom deployment it seems that it cert files would need to be faked in order to port to other phones and updates will also involve trickery of its own
Unless somone does something even more awesome
About 2 weeks ago, I took johnkussack's advice (I think it was him) and went to LinkedIn to try t be friends with anyone who came up on the search for "kin phone". In the invite email, I just said that I noticed they worked on the Kin phones and would like to ask them a few questions on how one could write to the phone. I have had 3 responses in the last 2 days.
Guy1: didn't know because he worked on the UI for the Kin Studio
Guy2: kindly told me he couldn't release an unauthorized build and that he would be breaking the law by doing so.
Guy3: This guy worked on the phone for over a year. He first told me I was breaking the DCMA by hacking/reverse engineering Kin, regardless of intent. Then he said this important thing:
"You are absolutely right in assuming that the device is locked; in fact, it has a hardware lock that is common to many such devices. When the devices roll of the manufacturing line the programming fuses are blown (literally) preventing any further programming of the device. This is all handled by hardware so unless you find a flaw with that you are out of luck."
So if this is true (sounds like it is), the "dream" is over. Hopefully there is some way that someone out there can find.
If I get more responses, I will post them here. Don't ask me to go back to these three who already replied and asked them more questions, I think I made some of them mad.
Hmmmm... I don't know whether or not the KIN models will accept OTA updates so that's a good question to ask. If OTA updates are possible then it's inherently possible to change the software. I wonder...
Yes, it was me the one who said about "linkedin".
But i also said "in one word NDA". You should known even before ask that the signed NDA are also legal contracts, so i prevented before asking them.
On the DCMA, yes.. on the USA. Outside the big country, the legal question is different and may not operate with that law. (if ever). If they provide a normal (legal?) way to unbrick my factory mode here, or to use the phone options, then i wait for the cost for it.
And everyone knew that hardware was not the way, just at the moment where first flash attempt failed. "Dream" is doable by software, if anything is to be done.
What i don't get is why to ask for rom rom roooooms, where we need drivers drivers driveeeeers... or sdk's. We won't get it anyway from MS, but no flashing means a rom is futile, non useful,crap pack of bytes.
But i also said "in one word NDA". You should known even before ask that the signed NDA are also legal contracts, so i prevented before asking them.
Click to expand...
Click to collapse
I figured I just take a shot in the dark; hope for the best and expect the worst. Since the phone and suuport from MS was discontinued, maybe the NDAs would be voided.
And everyone knew that hardware was not the way, just at the moment where first flash attempt failed. "Dream" is doable by software, if anything is to be done.
Click to expand...
Click to collapse
Good to know you still think there's a way.
What i don't get is why to ask for rom rom roooooms, where we need drivers drivers driveeeeers... or sdk's. We won't get it anyway from MS, but no flashing means a rom is futile, non useful,crap pack of bytes.
Click to expand...
Click to collapse
I just asked if "there is a way to get around the write lock". Had I known ahead of time to ask about drivers or SDKs, I would have put that in the msg.
I strongly believe that we could operate with the device,softwarewise. there is proof that the kin NAND memory (for now on, called "Storage" as label) is writeable. Not sure on the Rom part.
Of course, i mean.. just use it as a normal writable storage memory.
I posted how it could be done and would do it myself but, again, i bricked my phone, and available ones (through bidding sites) are so expensive to buy another one just for this (+ $150). Don't see a way to get it internationally again.
And even doing it, i'm not sure about what could be done just writing on the storage mem....
If the fuse byte is burn't should not it have prevented you from bricking?
kintwouser said:
If the fuse byte is burn't should not it have prevented you from bricking?
Click to expand...
Click to collapse
Nvitem bricked, not flashing bricked. You can succesfully write to the NVItems memory. But i guess it's just configuration memory and not the one "fused".
I just want to mention that jailbreaking a phone is NOT illegal in the United States! Geohot hacked the iphone... Apple went after him... Apple lost.
Also blowing the programming fuses seems a little fishy to me actually. No other phone does that. The majority of other phones have been flashed. I just think it would be pretty odd for a company to do that so that they no longer could update it. I am not sure I believe him. If this really was true... then why wouldn't Apple or Sony be doing it? This also doesn't make sense since Microsoft actually originally intended on putting WP7 on this as well as allowing apps for it. Check this article out:
http://www.intomobile.com/2010/05/12/kin-windows-phone-7-a-lot-closer-than-we-thought/
you must understand, its not possible to blow fuses in the hardware, it would be a top news story if they were able to keep the OS running in complience with the flash memory without it crashing. Obviously that was a lie to discourage us, and i dont even think that was a real kin developer, because microsoft clearly stated that all kin developers would be moved to WP7 or another programming section. And it doesnt matter if its legal or not to jailbrake phones, if we are porting a new OS, we wouldnt have modified the original OS, which is what jailbraking means. Most likely the OS is hidden deep in the flash memory with a write - protection. If you think its saying access denied because they said the fuses were blown, its wrong. They must just have a password or code that needs to be sent continuasly to the phone to access files. If the fuses were blown, then nothing would be able to be accessed by zune, because it would be impossible to reach the memory.
soninja8 said:
Most likely the OS is hidden deep in the flash memory with a write - protection. If you think its saying access denied because they said the fuses were blown, its wrong. They must just have a password or code that needs to be sent continuasly to the phone to access files. If the fuses were blown, then nothing would be able to be accessed by zune, because it would be impossible to reach the memory.
Click to expand...
Click to collapse
Not my expertise field, but this mobiles can (and in fact they do) have several memories, storing the OS in the ROM memory and all the data on the NAND memory (our "8gb" storage).
Zune software has protocols to query for available storages (requiring its label/id) and is allowed to write/read to it. If you dare to click on update version (at least in the 1st version I tried) it expressed that the option was not "available" to that device without web requesting data, apparently.
So.. in the nand flash we may only have the equivalent of a SD Card. And my last wince PDA showed that as /Storage too, apart from main wince ROM.
You can format the nand memory using win explorer if in fact it is the 8gig storage. I did this and it deleted all pics,albums etc. It was interesting to note that we cannot copy or view these pics without an access error but it does let me delete them.
I just wan't to be able to get my pics off this piece of crap without emailing them.
I posted it once. You are able to:
- Query storage properties (label, size, id,...)
- Query storage folders
- Query folder files.
- Query tracks / albums / playlist / images / anyZuneSupportedFile
- Delete * file (whatever)
- Format the storage
You are "unable" to:
- Upload (create) a file into the device
- Download a file from the device.
MTP protocol tools allows you to do so, from command line (not quite sure if they are available on Win32 OS's), but... fails to operate with this device when it comes to the "unavailable" operations.
I am curious as to which former developers you contacted?
I was doing some research and noticed that Microsoft acquired the company Danger, Inc. After Microsoft purchased them, the former president of Danger went to develop Android (later acquired by Google). One thing I read was that most of Dangers employees left after being purchased by Microsoft. Apparently these people don't like Microsoft all that much! I also looked into it a little more and found one of the founders of Danger who had a twitter account. Of course all of his tweets were via a "KIN". Thought that was interesting. It seems to me that these former Danger employees would be interested in helping out if they don't hold to high of an esteem for the big "M".
seems like this is your first "inside the move" trying-to-hack/reverse a thing, so i will say:
people involved doesnt wanna risk through legal issues, even if they were pissed off, just for "some kids" to have a driver or rom. NDA are strong there, and they could either sign them or leave (if leaving, they don't have the interesting things).
At most you would get bad-mood or good-luck comments, and ocassionaly (very uncommon), leaks (wont happen here).
yeah, they purchased danger for an amazing 500 million dollars, which they later developed the kin with it, they were planning to put windows phone 7 on it, but they were to behind and released it with the old windows CE, then the former developer moved to work on a free source OS, later called android. Google wanted to get android while it was cheap, so they bought that company, and made the old developer as 2nd engineer.
Maybe not worth yet, but we should get more *info* about the SBL mode (aka "Ms Pink Bootstrap), as coinflipper said that it was the way to flash OS or parts (like radio's).
I have been trying even OMA wap WBXML bootstrap examples with it, but as we dont know if our phone is standard, it's like looking for a water drop in the sea of possibilities.
We do not need a guide on how to do something, but what-to-do with it.
Maybe, JUST MAYBE, we could design a program like bitpim. I am a mac user and when I used bitpim with my enV touch, I used to edit all sorts of files. Examples would be phone info, server info etc. We could make a program like that to get the info. I know programming may be hard, but its worth a shot. I hate the OS on this phone, ESPECIALLY WHEN YOU PIN APPS! THEY LOOK HORRIBLE
Kinuser1 said:
Maybe, JUST MAYBE, we could design a program like bitpim. I am a mac user and when I used bitpim with my enV touch, I used to edit all sorts of files.
Click to expand...
Click to collapse
We can't. If we have not the protocols or the supported phone features (protocols, drivers, documentation,...) you cannot guess it and put it into visual basic (or Xcode) and then by *magic*get the program you want.
i will admit that i know very little about protocols and drivers but i would like to point out that bitpim is open source, and that the code can be found here ->
http-//sourceforge.net/scm/?type=svn&group_id=75211 (change "-" to ":")
i seem to recall bitpim already having limited support for the kin, but perhaps with a little research and a little code tweaking we can find ways to improve it? i'm not sure how feasable it is as i have very little experience with programming for phones/usb devices, but it's just a thought.
slimeq said:
i will admit that i know very little about protocols and drivers but i would like to point out that bitpim is open source, and that the code can be found here ->
http-//sourceforge.net/scm/?type=svn&group_id=75211 (change "-" to ":")
i seem to recall bitpim already having limited support for the kin, but perhaps with a little research and a little code tweaking we can find ways to improve it? i'm not sure how feasable it is as i have very little experience with programming for phones/usb devices, but it's just a thought.
Click to expand...
Click to collapse
We can't. If we have not the protocols or the supported phone features (protocols, drivers, documentation,...) you cannot guess it and put it into visual basic (or Xcode) and then by *magic*get the program you want.
Click to expand...
Click to collapse
The above applies to any software you want. Unless you magically found documentation or files (like OP), there's no way to. So f#cked.
The thing is always the same, tweaking tweaking... what to tweak, huh?
LiveLibs is an SDK that you can use in your apps. It allows you to have automatically updating code written in JavaScript. And yes, it'll even pass Marketplace approval. For more info, go here:
LiveLibs.com
Alpha 2 changes:
- Completely changed over from IronRuby to Jurassic (JavaScript) engine
- Improved security (hints and libraries are signed; lib.xml contains more verification data)
(Reserved)
Even though I do respect all the effort you may have put in this project, I'm still not too sure about it. As we've already seen and learned from Android and even iOS there's always the risk of a misuse of such an updating method as unauthorized code can be injected. I rather wait for updates to pass the official certification ways than let my apps update on their own and not knowing what exactly was downloaded.
You are right. With alpha 1 there is a risk of a MitM attack causing apps to download something they shouldn't. However, the framework is already in place to mitigate that - I just haven't had time to implement it fully.
All library ZIP files are signed on the server side with the LiveLibs private key, and the signature is checked by the SDK upon download. Starting with alpha 2, hints will also be signed, which will ensure that erroneous updates are never downloaded.
Also, you don't have to trust the LiveLibs.com site to do the updating. The SDK lets you specify alternate URLs for hints and for libraries.
Just stumbled across this link from your sig. Very cool idea. However, I want to know: have you tested it on a developer-locked phone? Dev-unlock allows the phone to execute code that doesn't have a Microsoft signature (Marketplace apps receive this on all DLLs) but user-replaced or self-compiled binaries won't have that signature. I don't know exactly how your libs worked, but from the look of things (based on your choice of languages) you're looking at monkey-patching the code in place. That's a cool idea, and may well get through Marketplace ingestion, but as soon as the patching is used, you'll have a file without a valid Marketplace signature, and the app won't run anymore...
At least, that's my guess on what would happen. If you can get around that, it would be incredible. That would provide a way to run homebrew code on dev-locked Windows Phones...
The way it worked with IronRuby is the Ruby code was interpreted on the fly. With Jurassic, the JavaScript is compiled into anonymous classes (IIRC from docs/forums on Jurassic.codeplex.com) and executed w/o ever creating separate assemblies. In other words, there's no monkey patching - just live emitted code via Reflection.Emit and similar methods. I'm in the process of getting alpha 2 ready for release now, actually.
Hmm, it's sounds quite interesting! However it's not a way to get an interop-unlock. Also (from the marketing side) it has another cons: an official updates via marketplace for some reasons are increasing number of app customers/downloads (so, good idea - if you have ads-based app - to publish updates at least monthly) but silent, "self-update" I afraid will not.
There's no reason to stop doing proper Marketplace-based updates. The biggest benefit of LiveLibs is the ability to quickly crush bugs instead of having to wait for Marketplace approval while your users complain and give your app bad ratings because of some simple bug.
Arktronic said:
There's no reason to stop doing proper Marketplace-based updates. The biggest benefit of LiveLibs is the ability to quickly crush bugs instead of having to wait for Marketplace approval while your users complain and give your app bad ratings because of some simple bug.
Click to expand...
Click to collapse
Agree. But your code also may have a bugs so it's still not an easy decision: should I add that app's overhead or better to spend more time/money for beta-testing
That, my friend, is entirely up to you
LiveLibs alpha 2 is out. Also, here's a little demo app I wrote using LiveLibs: Rando!
i just wanted to share this article for everyone to see!
http://privacy-pc.com/articles/bypassing-the-android-permission-model.html
what do you guys think about this? and about android as a whole (security wise)?
jamcar said:
i just wanted to share this article for everyone to see!
http://privacy-pc.com/articles/bypassing-the-android-permission-model.html
what do you guys think about this? and about android as a whole (security wise)?
Click to expand...
Click to collapse
I wouldn't say that the permissions system is "completely flawed," though it does lack significantly in key areas. Some of the permissions would be better served if they were split into multiple sub-permissions (eg. phone ID), but I'm relatively content with the current status quo.
Additionally, using Facebook, or heck, a mobile device on it's own even, means that you already thrown away any claims to your own data and privacy. While there is always room to better the system, it is important to remember that we've all signed clauses with a bold BUYER BEWARE heading. It is the user's job to take additional steps to secure all that, rather than waiting on Google to clean up their act IMO.
If you have any concerns about privacy on an Android device, I highly suggest using this app LBE Security Master http://forum.xda-developers.com/showthread.php?t=1422479 (there's a hint of irony there, as the app is from China with root and internet access). That one works on JB unlike the previous released with worked up to ICS.
Out of curiosity why isn't root allowed out of the box on the Nexus 7?
I mean I get that no one should use superuser access/root privileges on anything more than a "need to use" basis and honestly, I'll even admit that with the way the ecosystem has evolved, root isn't really entirely "needed" but, it still boggles my mind that there is no way I can just open up a terminal, type in a code, and get root.
I've tried googling the issue but, I generally get a bunch of responses about things which aren't quite related.
Snow_fox said:
Out of curiosity why isn't root allowed out of the box on the Nexus 7?
I mean I get that no one should use superuser access/root privileges on anything more than a "need to use" basis and honestly, I'll even admit that with the way the ecosystem has evolved, root isn't really entirely "needed" but, it still boggles my mind that there is no way I can just open up a terminal, type in a code, and get root.
I've tried googling the issue but, I generally get a bunch of responses about things which aren't quite related.
Click to expand...
Click to collapse
I think its fine the way it is. its jailbroken out of the box so you can use your device how you wish and that is what matters. You can't expect a company to support users to change everything about it. Then people complain about bricked devices or contact them for support for some custom rom.
However I believe they made it pretty easy to root. They certainly could have made it a lot harder. Anyone who has the skills (or patience to learn how) to use root certainly can root a device based on the tutorials given. And other users who don't want to worry about it don't ever see it. The little bit of effort helps weed out the people who would mess things up for themselves.
firesoul453 said:
I think its fine the way it is. its jailbroken out of the box so you can use your device how you wish and that is what matters. You can't expect a company to support users to change everything about it. Then people complain about bricked devices or contact them for support for some custom rom.
However I believe they made it pretty easy to root. They certainly could have made it a lot harder. Anyone who has the skills (or patience to learn how) to use root certainly can root a device based on the tutorials given. And other users who don't want to worry about it don't ever see it. The little bit of effort helps weed out the people who would mess things up for themselves.
Click to expand...
Click to collapse
I don't expect a company to support me changing anything I want about it. If I misuse root privileges, then I don't expect to have a lifeline when I call asus/google. I don't expect say Dell or HP to cover my PC if I try to install ubuntu and I botch something up.
However, refusing to let me have root because "might" mess something up is also flawed logic. I may also for one reason or another need root access.
While I am glad they make it easy to root, the reality is there is they are being counter productive. Honestly, just leaving in root access would decrease the chances of me bricking my device at this point. As of now to get root access I'll have to flash a custom recovery compared to just giving the ability to go into a terminal and type in "oem -su enable" or something.
If the flashing issue is really that big of a deal, then why force users to flash to get what they want in the first place?
Snow_fox said:
I don't expect a company to support me changing anything I want about it. If I misuse root privileges, then I don't expect to have a lifeline when I call asus/google. I don't expect say Dell or HP to cover my PC if I try to install ubuntu and I botch something up.
However, refusing to let me have root because "might" mess something up is also flawed logic. I may also for one reason or another need root access.
While I am glad they make it easy to root, the reality is there is they are being counter productive. Honestly, just leaving in root access would decrease the chances of me bricking my device at this point. As of now to get root access I'll have to flash a custom recovery compared to just giving the ability to go into a terminal and type in "oem -su enable" or something.
If the flashing issue is really that big of a deal, then why force users to flash to get what they want in the first place?
Click to expand...
Click to collapse
Root can cause problems. It can cause security problems if not used right and can brick not only while rooting but while flashing custom roms and things.
while you and I don't go asking for support, a lot of people do. People try to pass things off as warrenty problems and do call and email asking for support for things not originally on that phone.
And it hurts them in other ways. Google makes pretty much all their money from ads. Rooting makes it easy to block ads and you average rom might have it built right in. The only reason google bothers with android was for the ad money. So there is no incentive for them give root out of the box. They already are more open and free than their main competitions.
You could look at samsung. THey make their money of the hardware and so have been more open with rooting with odin, thought they still don't really care for it (probably because of the support issue)
And the carriers are even worse because rooting allows for things like wireless tethering for free and data is their biggest costs. Their certnaly isn't any reason for carriers to push for root.
I honestly don't know the true answer; only Google would know.
But in my opinion, it's because Android is an open source OS, and giving users root access allows them to alter .apk's very easily. This is bad for developers, because most developers make money from advertisements or in-app currency, and allowing users to alter their .apk to easily block ads or change in-app currency would thwart developer interest.
In Windows for example, the OS is not open source, but users have "root" access because they can always get to the root of every program/file. BUT users CANNOT EASILY alter the programs installed on Windows - if they want a hacked version, they usually have to download a hacked version that someone else hacked.
Whereas in Android, it's very easy for me to download any .apk I want, run my hack app that says "Search for this value and change it to this" and BAM it's now hacked in literally seconds.
firesoul453 said:
Root can cause problems. It can cause security problems if not used right and can brick not only while rooting but while flashing custom roms and things.
while you and I don't go asking for support, a lot of people do. People try to pass things off as warrenty problems and do call and email asking for support for things not originally on that phone.
And it hurts them in other ways. Google makes pretty much all their money from ads. Rooting makes it easy to block ads and you average rom might have it built right in. The only reason google bothers with android was for the ad money. So there is no incentive for them give root out of the box. They already are more open and free than their main competitions.
You could look at samsung. THey make their money of the hardware and so have been more open with rooting with odin, thought they still don't really care for it (probably because of the support issue)
And the carriers are even worse because rooting allows for things like wireless tethering for free and data is their biggest costs. Their certnaly isn't any reason for carriers to push for root.
Click to expand...
Click to collapse
I'm not going to deny adblocking is one of my many vices. While many people have many views on it, all I can say is until ads no longer break my experience completely, I'll be stuck using adblockers. While this is becoming less of a problem with phones/tablets that have faster processors I've had my entire phone lock up before because of certain types of ads my phone couldn't handle. On top of that many are frustrating to deal with as there is no "x" visible for me to tap and I have to back out of whatever I was doing because the phone can't handle the discrepancy in size and find some way to navigate around the ad.
While this is only one example there have been other issues. Hell I had to use a script that required root back when I had my captivate just to get it it to work on my schools wifi. There were a number of issues and I imagine there are still a number of issues that make the lack of root almost a deal breaker.
Sure you can argue from a support issue point of view but, realistically as I already said, I wouldn't have to flash anything if I had access to root... I guess they just chalk it up to "some people are going to do whatever it takes anyway...." but, that just doesn't make much sense to not let people have it anyway.
Geodude074 said:
I honestly don't know the true answer; only Google would know.
But in my opinion, it's because Android is an open source OS, and giving users root access allows them to alter .apk's very easily. This is bad for developers, because most developers make money from advertisements or in-app currency, and allowing users to alter their .apk to easily block ads or change in-app currency would thwart developer interest.
In Windows for example, the OS is not open source, but users have "root" access because they can always get to the root of every program/file. BUT users CANNOT EASILY alter the programs installed on Windows - if they want a hacked version, they usually have to download a hacked version that someone else hacked.
Whereas in Android, it's very easy for me to download any .apk I want, run my hack app that says "Search for this value and change it to this" and BAM it's now hacked in literally seconds.
Click to expand...
Click to collapse
This is actually one of the best reasons I think I've ever heard and I've actually asked this question a lot in different places over the years. That's a pretty feasible answer.
Geodude074 said:
I honestly don't know the true answer; only Google would know.
But in my opinion, it's because Android is an open source OS, and giving users root access allows them to alter .apk's very easily. This is bad for developers, because most developers make money from advertisements or in-app currency, and allowing users to alter their .apk to easily block ads or change in-app currency would thwart developer interest.
In Windows for example, the OS is not open source, but users have "root" access because they can always get to the root of every program/file. BUT users CANNOT EASILY alter the programs installed on Windows - if they want a hacked version, they usually have to download a hacked version that someone else hacked.
Whereas in Android, it's very easy for me to download any .apk I want, run my hack app that says "Search for this value and change it to this" and BAM it's now hacked in literally seconds.
Click to expand...
Click to collapse
Rooting has nothing to do with decompiling apks. apk hacking is bad but thats a whole other thing. Anyone can get a hold of pretty much every apk easliy, no need for root.
Windows doesn't really have root, its pretty different. You can give programs administrator privileges I guess, but not exactly the same. Decompiling apks is only easier because its java, it has nothing to do with the os or root privileges.
Don't expect any of these companies support to support root until they have a reason to.