http://www.phonearena.com/news/The-Pixel-and-Pixel-XL-will-be-rootable-Google-confirms_id86575 for all the naysayers...google did not let us down
I did not doubt it but it is good that it is confirmed
Confused - That doesn't really make sense - While Google can (and thankfully will) make the bootloader unlockable, they don't make it rootable. They have never done that. Root is usually achieved when developers find exploits (that are unpatched by Google), and root using that.
For Google to say that the device will be rootable is like saying "we left some exploits unpatched", or "we will provide you a means of rooting" - I don't think either is true. (yes, I read the exact verbiage on the article - and saw what you are referring to)
The bootloader being unlockable is making it rootable.....that's the "exploit"....
Sent from my XT1096 using Tapatalk
tacosrdelicioso said:
The bootloader being unlockable is making it rootable.....that's the "exploit"....
Sent from my XT1096 using Tapatalk
Click to expand...
Click to collapse
Technically, no.
Regardless, glad Google confirmed that the bootloader will be unlockable (as we were expecting/hoping)
jj14 said:
Technically, no.
Regardless, glad Google confirmed that the bootloader will be unlockable (as we were expecting/hoping)
Click to expand...
Click to collapse
My point is it gets us 95% of the way there
Sent from my XT1096 using Tapatalk
The expliot is modifying the kernel. Google knows this as we do. In order to have a modified kernel you must have a unlocked bootloader. While only time will tell i believe the verizon version will never be rooted because of this new security,cause only unlocking the bootloader will allow it, hence what i believe google was getting at, sometimes people read too deep and miss whats on the surface
I think we are having a war of definitions here, so let me say a few things that I believe will clear things up:
In this context an exploit, by definition, means taking advantage of a feature in a given software or hardware platform. The word has a stigma associated with it that implies that this feature allows an unintentional effect, and that taking advantage of it gains something for the one who exploits it. E.G. a buffered array that doesn't properly safeguard writing past the allocated memory for that array would be an exploitable software feature. The exploit that takes advantage of such a feature is known as a buffer overflow exploit, which would allow an attacker to overwrite code or data at a known location in device memory, potentially allowing for arbitrary code to be executed in the context of whatever software exposes that feature.
So, an unlockable bootloader could be exploited to allow a custom kernel to run, but it would not really fit the context of "an exploit", because the feature is there to be used for that purpose. Nor, really would building a custom kernel be an exploit for the very same reason: the kernel source is provided so that it can be built and modified by anyone.
Fenny said:
I think we are having a war of definitions here, so let me say a few things that I believe will clear things up:
In this context an exploit, by definition, means taking advantage of a feature in a given software or hardware platform. The word has a stigma associated with it that implies that this feature allows an unintentional effect, and that taking advantage of it gains something for the one who exploits it. E.G. a buffered array that doesn't properly safeguard writing past the allocated memory for that array would be an exploitable software feature. The exploit that takes advantage of such a feature is known as a buffer overflow exploit, which would allow an attacker to overwrite code or data at a known location in device memory, potentially allowing for arbitrary code to be executed in the context of whatever software exposes that feature.
So, an unlockable bootloader could be exploited to allow a custom kernel to run, but it would not really fit the context of "an exploit", because the feature is there to be used for that purpose. Nor, really would building a custom kernel be an exploit for the very same reason: the kernel source is provided so that it can be built and modified by anyone.
Click to expand...
Click to collapse
Yeah what he said lol...thanks for the explantion i guess exploit is the wrong word cause it does have a negative implication
yes, even HTC devices that are unlocked and rootable is not SOFF, and you had to pay for it. Does anyone know if there is any such restriction that is "hidden"?
Is it really as "open" as the nexus devices?
Has there been any confirmation on whether or not source will be released...
Sent from my ONEPLUS A3000 using XDA-Developers mobile app
Related
Vulnerability Allows Attackers to Modify Android Apps Without Breaking Their Signatures
This might be the reason why the new MF2 and ME6 are not downgradable and why the 4.2.2 update was delayed.
Source->http://www.cio.com/article/735878/V...ndroid_Apps_Without_Breaking_Their_Signatures
IDG News Service — A vulnerability that has existed in Android for the past four years can allow hackers to modify any legitimate and digitally signed application in order to transform it into a Trojan program that can be used to steal data or take control of the OS.
Researchers from San Francisco mobile security startup firm Bluebox Security found the flaw and plan to present it in greater detail at the Black Hat USA security conference in Las Vegas later this month.
The vulnerability stems from discrepancies in how Android apps are cryptographically verified, allowing an attacker to modify application packages (APKs) without breaking their cryptographic signatures.
When an application is installed and a sandbox is created for it, Android records the application's digital signature, said Bluebox Chief Technology Officer Jeff Forristal. All subsequent updates for that application need to match its signature in order to verify that they came from the same author, he said.
This is important for the Android security model because it ensures that sensitive data stored by one application in its sandbox can only be accessed by new versions of that application that are signed with the original author's key.
The vulnerability identified by the Bluebox researchers effectively allows attackers to add malicious code to already signed APKs without breaking their signatures.
The vulnerability has existed since at least Android 1.6, code named Donut, which means that it potentially affects any Android device released during the last four years, the Bluebox researchers said Wednesday in a blog post.
"Depending on the type of application, a hacker can exploit the vulnerability for anything from data theft to creation of a mobile botnet," they said.
The vulnerability can also be exploited to gain full system access if the attacker modifies and distributes an app originally developed by the device manufacturer that's signed with the platform key -- the key that manufacturers use to sign the device firmware.
"You can update system components if the update has the same signature as the platform," Forristal said. The malicious code would then gain access to everything -- all applications, data, accounts, passwords and networks. It would basically control the whole device, he said.
Attackers can use a variety of methods to distribute such Trojan apps, including sending them via email, uploading them to a third-party app store, hosting them on any website, copying them to the targeted devices via USB and more.
Some of these methods, especially the one involving third-party app stores, are already being used to distribute Android malware.
Using Google Play to distribute apps that have been modified to exploit this flaw is not possible because Google updated the app store's application entry process in order to block apps that contain this problem, Forristal said. The information received by Bluebox from Google also suggests that no existing apps from the app store have this problem, he said.
However, if an attacker tricks a user to manually install a malicious update for an app originally installed through Google Play, the app will be replaced and the new version will no longer interact with the app store. That's the case for all applications or new versions of applications, malicious or non-malicious, that are not installed through Google Play, Forristal said.
Google was notified of the vulnerability in February and the company shared the information with their partners, including the members of the Open Handset Alliance, at the beginning of March, Forristal said. It is now up to those partners to decide what their update release plans will be, he said.
Forristal confirmed that one third party device, the Samsung Galaxy S4, already has the fix, which indicates that some device manufacturers have already started releasing patches. Google has not released patches for its Nexus devices yet, but the company is working on them, he said.
Google declined to comment on the matter and the Open Handset Alliance did not respond to a request for comment.
The availability of firmware updates for this issue will differ across device models, manufacturers and mobile carriers.
Whether a combination of device manufacturers and carriers, which play an important role in the distribution of updates, coincide to believe that there is justification for a firmware update is extremely variable and depends on their business needs, Forristal said. "Ideally it would be great if everyone, everywhere, would release an update for a security problem, but the practical reality is that it doesn't quite work that way, he said."
The slow distribution of patches in the Android ecosystem has long been criticized by both security researchers and Android users. Mobile security firm Duo Security estimated last September, based on statistics gathered through its X-Ray Android vulnerability assessment app, that more than half of Android devices are vulnerable to at least one of the known Android security flaws.
Judging by Android's patch distribution history so far, the vulnerability found by the Bluebox researchers will probably linger on many devices for a long time, especially since it likely affects a lot of models that have reached end-of-life and are no longer supported.
Click to expand...
Click to collapse
I really thought more people would be interested in knowing this. I would really like to know what you guys think about this.
Key phrase here is "for apps not installed through the google store". Hence not an issue for a large fraction of users. Total case of FUD. Someone must be wanting to sell some av software.
Sent from my GT-N7100 using Tapatalk 4 Beta
Kremata said:
I really thought more people would be interested in knowing this. I would really like to know what you guys think about this.
Click to expand...
Click to collapse
Well, X-Ray scanner either does not detect this latest security flaw or N7100 (as of DM6) is allready patched.
Kremata said:
I really thought more people would be interested in knowing this. I would really like to know what you guys think about this.
Click to expand...
Click to collapse
This is the first link I found for XDA on this.
I think it's not that interesting because it's old, old news and exactly why it's being touted as a "new" discovery is beyond me, it's far from new.
We here at XDA have been using this method for years to modify stock Android and OEM system apps with great success. Here's an example by me from 2011: http://forum.xda-developers.com/showthread.php?t=994544 there's a literally hundreds of examples all over XDA.
The real question here is how Bluebox security got everybody to act as a PR machine for them. If they turn up at Black Hat with this "amazing discovery" they're going to get laughed off the stage.
djmcnz said:
This is the first link I found for XDA on this.
I think it's not that interesting because it's old, old news and exactly why it's being touted as a "new" discovery is beyond me, it's far from new.
We here at XDA have been using this method for years to modify stock Android and OEM system apps with great success. Here's an example by me from 2011: http://forum.xda-developers.com/showthread.php?t=994544 there's a literry hundreds of examples all over XDA.
The real question here is how Bluebox security got everybody to act as a PR machine for them. If they turn up at Black Hat with this "amazing discovery" they're going to get laughed off the stage.
Click to expand...
Click to collapse
Ahh! Thats the answer I was waiting for (and from a Recognized Developer). I knew XDA Devs were using this method. My new question is.. If they fix it will it be harder to create Mods? Will it slow down development?
Shouldn't this be posted in the generals forum?
Kremata said:
If they fix it will it be harder to create Mods? Will it slow down development?
Click to expand...
Click to collapse
I suspect so. If they fix it properly it would become impossible to change any aspect of the app without signing it again. If you wanted to maintain compatibility with the original then you'd need the developer's keys.
At the moment really only the manifest and some metadata within the apk is signed, if they extended that to the entire contents of the apk many mods (think themes for stock Google apps etc) are screwed unless users are happy to relinquish Play Store links and updates (i.e. backward compatibility).
Google may not go this far and may only choose to authenticate the code (smali) rather than all of the apk contents (graphics, strings etc), this approach would leave room for some mods to survive. Remains to be seen.
Quite a few of us xda lurkers are itching to get root on our devices, but the DRM-debacle of the Sony phones has made many, including myself, hold off with unlocking the bootloader. Instead, we've put our hopes to new exploits that would allow root while keeping the bootloader locked, thus making it possible to keep all DRM functions in place, and also to restore the phone to factory conditions with the bootloader intact.
However, as Chainfire explains in the post below, the chances of any such exploit surfacing are slim. He says it's more important than ever to buy phones with unlocked bootloaders if we want to keep root.
Sadly, I'm afraid he's right and that the official bootloader unlock is the only way we'll be able to get root in the foreseeable future.
What do you guys think? Worth it or not?
Check out Chainfire's post on G+:
https://plus.google.com/113517319477420052449/posts/VxjfYJnZAXP
Fruktsallad said:
Quite a few of us xda lurkers are itching to get root on our devices, but the DRM-debacle of the Sony phones has made many, including myself, hold off with unlocking the bootloader. Instead, we've put our hopes to new exploits that would allow root while keeping the bootloader locked, thus making it possible to keep all DRM functions in place, and also to restore the phone to factory conditions with the bootloader intact.
However, as Chainfire explains in the post below, the chances of any such exploit surfacing are slim. He says it's more important than ever to buy phones with unlocked bootloaders if we want to keep root.
Sadly, I'm afraid he's right and that the official bootloader unlock is the only way we'll be able to get root in the foreseeable future.
What do you guys think? Worth it or not?
Check out Chainfire's post on G+:
https://plus.google.com/113517319477420052449/posts/VxjfYJnZAXP
Click to expand...
Click to collapse
Well it's @Chainfire talking, who are we to doubt him? I'm only waiting for a way to backup my TA-Partition (DRM keys), I wouldn't mind losing some features. Even tho I must agree that losing some camera quality is really annoying, but Android is pretty open source so I have no doubts that people will find something to reverse the algorithm loss or create their own.
And also when the occasion occurs that I need to send my device out for repair, that they don't refuse it due to an unlocked BL
I'm sure that's true in the long run, just not sure if it's true now.
It's economics. The security bugs are going to get fewer and further between, but they will arguably never be eradicated. You should expect it to take longer and longer to find new exploits, but I wouldn't bet a wooden nickel that there are no exploits left.
More likely, we will reach a point where the cost of finding an exploit is so great that they're no longer worth looking for to a critical mass of hackers.
On the bright side, the implementations get better all the time, and I see very little about my z3c that I would like to change if only I had root.
And I do think Sony should find a way to make the early rooters whole again. I feel terrible that so many people's $500 phones have been seriously degraded by a completely reversible software change.
Dsteppa said:
Well it's @Chainfire talking, who are we to doubt him? I'm only waiting for a way to backup my TA-Partition (DRM keys), I wouldn't mind losing some features. Even tho I must agree that losing some camera quality is really annoying, but Android is pretty open source so I have no doubts that people will find something to reverse the algorithm loss or create their own.
And also when the occasion occurs that I need to send my device out for repair, that they don't refuse it due to an unlocked BL
Click to expand...
Click to collapse
True, but as I'm sure you're aware, backing up the TA-partition requires said exploit to be found in order to get root. So I think it'll be a looong wait. [emoji20]
He still thinks root will be achievable in the early editions of Android L so I think it's safe to say root will arrive for this device under a locked bootloader, it will just take a bit longer than it has in the past to find an exploit.
Sent from my D5803 using XDA Free mobile app
This is really disheartening. It's kinda ironic that Sony, who in recent times has been raised in its support of the developer community of its phones, and even won XDA's OEM of the Year, has such a downer in its phones.
I know this doesn't work for everyone but I'm hopeful that the new AOSP L camera API will mean that AOSP custom roms have some native low light enhancement processing. Maybe...
Chances improve with new software so I t could happen with android L too.
pricey2009 said:
He still thinks root will be achievable in the early editions of Android L so I think it's safe to say root will arrive for this device under a locked bootloader, it will just take a bit longer than it has in the past to find an exploit.
Sent from my D5803 using XDA Free mobile app
Click to expand...
Click to collapse
Yup, but we're still looking at about five months wait considering Sony won't ship L until Q1 2015. Even then, there's no guarantee an exploit will be found.
Maybe I'm overly pessimistic about this. I do, however, have high hopes for the new camera API's regarding camera quality and post processing.
Personally, every day without root is a little painful, so I'll never last all those months. As soon as there are custom kernels available and a ROM like CM or PA, my locked bootloader goes bye-bye.
Chainfire is talking about the su daemon and problems running it (on Android L). He does not say anything about a root exploit. It seems you misunderstood his post.
zxz0O0 said:
Chainfire is talking about the su daemon and problems running it (on Android L). He does not say anything about a root exploit. It seems you misunderstood his post.
Click to expand...
Click to collapse
Let's hope Sony make or have made some little security mistakes.. To quote his post:
" Of course, this is all dependent on OEMs implementing everything exactly right. If a certain OEM doesn't protect one of their services correctly, then we can leverage that to launch the daemon without kernel modifications. While I'm fairly certain this will be the case for a bunch of devices and firmwares, especially the earlier L firmwares, this is not something you should expect or base decisions on."
Here's hoping they have missed something.
Sent from my GT-I9300 using XDA Free mobile app
pricey2009 said:
Let's hope Sony make or have made some little security mistakes.. To quote his post:
" Of course, this is all dependent on OEMs implementing everything exactly right. If a certain OEM doesn't protect one of their services correctly, then we can leverage that to launch the daemon without kernel modifications. While I'm fairly certain this will be the case for a bunch of devices and firmwares, especially the earlier L firmwares, this is not something you should expect or base decisions on."
Here's hoping they have missed something.
Sent from my GT-I9300 using XDA Free mobile app
Click to expand...
Click to collapse
Let's wait until January for the first android L release then :crying:
I've rooted two weeks ago and still enjoying the phone
zxz0O0 said:
Chainfire is talking about the su daemon and problems running it (on Android L). He does not say anything about a root exploit. It seems you misunderstood his post.
Click to expand...
Click to collapse
This.
The post was mainly aimed at Android L...
Google hired one of our very own (Towelroot) and iPhone's pioneering hacker so it's going to get tougher. I hope they hired him only for NSA purposes.
That move by sony is just stupid. if they wanted to protect their code, why not store it into the camera firmware (referring to the camera algorithms)?
Why do they have to kill Miracast?
Obviously that is the other side of the medal. investments on security = far less exploits available. we are gonna wait a while, but as a developer I really really miss Xposed. Each time I look at my G2 a little tear drops.
No way I'm gonna root loosing DRM keys. The camera is already weak (to be honest I would be used a word beginning in shi but let's be polite) so I'm not in any way gonna make it worse.
zxz0O0 said:
Chainfire is talking about the su daemon and problems running it (on Android L). He does not say anything about a root exploit. It seems you misunderstood his post.
Click to expand...
Click to collapse
Yes he does:
"As stated above, it seems for now that modifications to the kernel package are required to have root, we cannot attain it with only modifications to the system partition.
Combine that with a locked bootloader (and optionally dm-verity) and a device becomes nigh unrootable - exactly as intended by the security guys.
Exploit-based roots are already harder to do thanks to SELinux, and now because of the kernel requirements for persistent root, these exploits will need to be run at every boot. Exploits that make the system unstable (as many do) are thus out as well."
Then he goes on to say:
"Of course, this is all dependent on OEMs implementing everything exactly right. If a certain OEM doesn't protect one of their services correctly, then we can leverage that to launch the daemon without kernel modifications. While I'm fairly certain this will be the case for a bunch of devices and firmwares, especially the earlier L firmwares, this is not something you should expect or base decisions on. It is now thus more important than ever to buy unlocked devices if you want root.
It might also mean that every firmware update will require re-rooting, and OTA survival mode will be broken. For many (but far from all) devices we can probably automate patching the kernel package right in the SuperSU installer ZIP. We can try to keep it relatively easy, but updating stock firmwares while maintaining root is probably not going to work as easy and fast as it did until now."
zxz0O0 said:
Chainfire is talking about the su daemon and problems running it (on Android L). He does not say anything about a root exploit. It seems you misunderstood his post.
Click to expand...
Click to collapse
How can anything be a root exploit if it doesn't result in a functional su? I read Chainfire's post as Google making it impossible to elevate privileges from within Android, necessitating kernel level exploits which in turn will require unlocked bootloaders to install.
Once we get to where the bootloader has to be unlocked it's really not a root exploit anymore, is it?
michyprima said:
Why do they have to kill Miracast?
Click to expand...
Click to collapse
Because they don't want to support Miracast without HDCP. Remember that Sony is also a content provider. While that may be as annoying for a normal user as the degradation in camera quality, their approach actually still is developer friendly. Request a code - get full control over the device, at the cost of losing some functionality (software functionality). It's as simple as that. CM and other roms work perfectly fine on Xperia devices, and if you want to implement an equivalent camera algorithm, you're free to do so.
Iruwen said:
Because they don't want to support Miracast without HDCP. Remember that Sony is also a content provider. While that may be as annoying for a normal user as the degradation in camera quality, their approach actually still is developer friendly. Request a code - get full control over the device, at the cost of losing some functionality (software functionality). It's as simple as that. CM and other roms work perfectly fine on Xperia devices, and if you want to implement an equivalent camera algorithm, you're free to do so.
Click to expand...
Click to collapse
Can only agree to that. If you buy a Sony phone to act like a Sony phone (most people do!) then one should leave it as it has been delivered by Sony. If you can't agree to how it is, Sony gives you the option to unlock the BL and do whatever you want to do with the HW, but don't expect it to work/act as before. Personally, I have no issues with that at all.
On a different note, Linux/Android is comprised of x million lines of code. There're bugs in this code, there're bugs in the compiler, bugs in Java, bugs even in the Hardware etc. etc. There's no reason to believe (or fear) that Linux/Android would ever be perfect or non-vulnerable. Root will come, it's only a matter of effort and time...
I know its too early but what do you guys this about rooting/custom roms for venice?
BB ceo said (something along the lines) that they will only make an android device if it is secured enough. WOuld that mean a locked bootloader etc? Moreover, it is using a much more secure kernel (http://berryflow.com/2015/09/blackberrys-android-slider-using-hardened-linux-kernel/) and i've read that some beginner's tools (eg enabling developer's options, sideloading apps etc) are blocked.
So what do you guys think? As for me, I believe in this community and i know one way or another, we will be able to install our favourite custom roms/apps on venice. Although I dont know if it would happen 2 days after launch of 2 years after the device reaches the market!
Btw cant wait for the device! I hope blackberry becomes a force again after this phone. I'll buy it the day it's bootloader gets unlocked + root is acheived
Do you have a source on the Priv blocking sideloaded apps? That would be very unfortunate. Locked bootloader is a given but I would still like to be able to install my favorite apks.
I can't see things like developer options/USB debugging etc being outright blocked. That just seems like a great way to alienate the majority of the userbase that a device like this is targeted towards.
This is my main concern... I want this phone, badly. But after having a G4, having to wait for root and still not having any decent roms I won't get the Priv if it doesn't at least get root. It's stock-ish android so I can deal with lack of roms but no root, no sale.
Sent from my LG-H811 using Tapatalk
No idea why anyone here thinks they would do that. Even on BB10 devices installing apks is allowed - and they sure wouldn´t do otherwise on an Android device - that would be crazy.
and yes, bl will be locked and encrypted - root - well that will be something to wait for.
:good:
Bootloader WILL be locked, that's a no brainer. But locking out sideloading, developer options is not possible without TOTALLY killing interest and sales. Blackberry desperately needs Priv to succeed. This is their last chance to avoid becoming the next Nokia. So no, we will have at least sideloading available. Honestly, it doesn't matter if they lock out all these essential features, if they release at least the kernel source and device tree day-and-date with the phone. If you have these, we're better off building a CM 12 (or 13:fingers-crossed ROM for the Priv.
Zer0.exe said:
Do you have a source on the Priv blocking sideloaded apps? That would be very unfortunate. Locked bootloader is a given but I would still like to be able to install my favorite apks.
Click to expand...
Click to collapse
sorry I cant give you a source. I read this on reditt or a blog post
MSF Jarvis said:
Bootloader WILL be locked, that's a no brainer. But locking out sideloading, developer options is not possible without TOTALLY killing interest and sales. Blackberry desperately needs Priv to succeed. This is their last chance to avoid becoming the next Nokia. So no, we will have at least sideloading available. Honestly, it doesn't matter if they lock out all these essential features, if they release at least the kernel source and device tree day-and-date with the phone. If you have these, we're better off building a CM 12 (or 13:fingers-crossed ROM for the Priv.
Click to expand...
Click to collapse
hmm. So do you think it would be possible to unlock the bootloader or it can never be unlocked?
btw slightly offtopic, but is there any phone which has a completely locked bootloader (ie has never been unlocked)?
Welp a leaked pic about the security settings confirms developer options can be enabled, so sideloaded apps is probably a go to. False alarm, peeps!
Zer0.exe said:
Welp a leaked pic about the security settings confirms developer options can be enabled, so sideloaded apps is probably a go to. False alarm, peeps!
Click to expand...
Click to collapse
Link?
HyperM3 said:
Link?
Click to expand...
Click to collapse
http://n4bb.com/blackberry-priv-64-bit-4k-video-confirmed/
The beautiful glass weave is also shown off. I love it on my Z30.
pluto7443 said:
http://n4bb.com/blackberry-priv-64-bit-4k-video-confirmed/
The beautiful glass weave is also shown off. I love it on my Z30.
Click to expand...
Click to collapse
Thanks for that! I am really looking forward to this device. Im all or nothing on this with my Nexus 6 right now.
rollerdyke44 said:
hmm. So do you think it would be possible to unlock the bootloader or it can never be unlocked?
btw slightly offtopic, but is there any phone which has a completely locked bootloader (ie has never been unlocked)?
Click to expand...
Click to collapse
there must be some poor phone that didn't get a bootloader unlock, and I firmly believe the Priv is gonna join their ranks as soon as it gets released.
Sent from a Cool Phone stuck with crappy KingUser
rollerdyke44 said:
btw slightly offtopic, but is there any phone which has a completely locked bootloader (ie has never been unlocked)?
Click to expand...
Click to collapse
Look at the recent crop of AT&T and Verizon Samsung phones. Their bootloader are locked up tighter then...... Well we will just say their locked down [emoji1]
Sent from my Nexus 6 using Tapatalk
http://i-cdn.phonearena.com/images/...aked-hands-on-photos-plus-official-images.jpg In fact, this image outright confirms that you can sideload/ use developer options.
I wouldn't count on too much. The developer options could have easily been changed and some removed. As BB main selling point is security I expect this device to be one of the harder ones to crack.
As for the bootloader questions. Yes there have been a few that were uncrackable, a dirty hack to by pass has worked on some.
I imagine root is just a matter of time. Unless they lock the system partition, which other manufacturers have done in the past (Looking at you HTC). Even so, it has been done and s-on/off has been cracked before. Alternatives to locking include e-fuses, like in legacy motorola devices.
Bootloaders on the other hand, we're probably going to have to get some concrete evidence. It is most likely locked in my personal opinion.
This is all just speculation. Hopefully Blackberry can find a good balance.
htko89 said:
I imagine root is just a matter of time. Unless they lock the system partition, which other manufacturers have done in the past (Looking at you HTC). Even so, it has been done and s-on/off has been cracked before. Alternatives to locking include e-fuses, like in legacy motorola devices.
Bootloaders on the other hand, we're probably going to have to get some concrete evidence. It is most likely locked in my personal opinion.
This is all just speculation. Hopefully Blackberry can find a good balance.
Click to expand...
Click to collapse
The efuze us still used in many devices and if I know blackberry they will have it check against its servers for security. Once it detects root it will most likely disable the device. Or most of the functions that use BB servers. Remember everything is routed through Blackberrys servers in Canada so if their servers go do so does the device.
zelendel said:
Once it detects root it will most likely disable the device. Or most of the functions that use BB servers.
Click to expand...
Click to collapse
I would be completely fine with them locking out the BB services when root is discovered. But locking down the hardware would be overstepping their bounds. It's our hardware, not theirs. I know that doesn't mean they couldn't still do it, I just think it would be a jerk move.
It would be like if Microsoft bricked xbox machines that have been modded. They don't, they just ban you from XBox Live if they detect it. I think it should be the same approach.
Yes but even MS has locked the bootloader on Many of their 32 bit machines now. Also I have a link that you might want to read where is passed then modding our devices at all will become illegal.
https://www.eff.org/issues/tpp
QuadRooter allows attackers to take complete control of Android devices, potentially exposing your sensitive data to cybercrime.
However, there is no evidence of the vulnerabilities currently being used in attacks by cyberthieves.
"I'm pretty sure you will see these vulnerabilities being used in the next three to four months," said Michael Shaulov, head of mobility product management at Checkpoint. [BBC News]
Click to expand...
Click to collapse
Play Store link:
Check Point QuadRooter Scanner
Alternative: QuadRooter Scanner (less intrusive permissions)
CM (and other AOSPs) will get patched, but Stock 5.1? I suspect the only hope is that Motorola will release something for Moto G (2nd Gen) Stock 6.0, meaning Identity Crisis 6 can be made secure.
Why does a vulnerability check app require permissions for accounts and contacts?
Also, has anyone already created a universal rooting tool based on this vulnerability?
_that said:
Why does a vulnerability check app require permissions for accounts and contacts?
Also, has anyone already created a universal rooting tool based on this vulnerability?
Click to expand...
Click to collapse
I don't know, but an alternative is available: QuadRooter Scanner.
It's early days, nothing so far - but maybe there is now hope for those CDMA users who want root.
So I'm vulnurable to 5 "things" according to that app. This is a general situation and not device specific, right?
Penemue said:
So I'm vulnurable to 5 "things" according to that app. This is a general situation and not device specific, right?
Click to expand...
Click to collapse
Google have said it's not really a big deal - more a case of a company (Checkpoint) scare-mongering to sell their software.
The Android feature 'Verify apps' essentially protects against malicious software if not ignored.
To answer your question, it depends on the device - the degree of vulnerability - but generally speaking most handsets are 'affected.'
So what realistically are the time frames on getting a new root and BL unlock for the snapdragon chipsets?
I ask since now the leak that happened means keys and other information are public.
Here's the thing about real security that has been properly implemented: a source leak doesn't compromise the security of the system. Thus, there is no realistic time frame, because there is no guarantee that a source leak will even result in a bootloader unlock method. A source leak will give insight into how the system works, and it might even expose a vulnerability, but even if revealed, it doesn't mean it will translate into a practical bootloader unlock method.
Imagine for example this purely hypothetical speculation: the persistent state of the OEM unlock bit, in the steady partition or wherever it is stored, is not encrypted or protected by a secure hash. While such a hypothetical vulnerability represents an attack vector, it would likely still be problematic to activate, possibly even requiring direct physical access to the device's eMMC IC.
I've seen said leak. If you're hoping for such access, I'd recommend disabling updates for a while. As far as phones are concerned, the leak goes deep. We're talking certs, signing apps, source code, even qualcomm source.
I dont imagine it will be long.
FesterCluck said:
I've seen said leak. If you're hoping for such access, I'd recommend disabling updates for a while. As far as phones are concerned, the leak goes deep. We're talking certs, signing apps, source code, even qualcomm source.
Click to expand...
Click to collapse
There is a lot there for sure. That said, the Snapdragon (cinammon) bootloader trees seem a lot lighter than the Exynos (strawberry) bootloader trees.
On the Exynos side, "SATURN/bootloader/lib/sbl_security/ddi.c implements get_oem_unlock_val() which is called in a variety of places. I'm still trying to understand the relationship between the two instances of the OEM Unlock flag, that is FROM_RPMB vs. FROM_PERSISTENT. In the case of the latter, this seems to simply be stored in the clear as the last byte in the PERSISTENT partition, where 0 means locked, and 1 means unlocked. As such, it can probably be readily written via JTAG or directly to the eMMC in a matter analogous to how the PERSISTENT partition is deleted to clear FRP state in many YouTube videos, though admittedly these both require special tools and invasive physical access.
I assume there exists at least conceptually similar implementation on the Snapdragon side, but so far I have not found it.
@Badger50 if there is a better place for this development-oriented discussion please advise or move the thread as (a) there does not seem to be a lot of development-oriented discussion in this forum and (b) it is likely not very specific to S20 devices--it is likely to apply to many recent Samsung models.
sjevtic said:
@Badger50 if there is a better place for this development-oriented discussion please advise or move the thread as (a) there does not seem to be a lot of development-oriented discussion in this forum and (b) it is likely not very specific to S20 devices--it is likely to apply to many recent Samsung models.
Click to expand...
Click to collapse
I'll move it to the "Guides and News" section since that would be the more appropriate section. Thanks for the shout out.
I'd be happy to donate to make progress. Just bought a new S20 and of course it has v2 BL. So lmk if there is anything needed.